Don't pick weird subnets for embedded networks, use VRFs
27 points by jmillikin
27 points by jmillikin
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.
Wait until this person learns that link-local addresses are not routable [1] and in fact the Linux kernel (iptables) will silently refuse to apply NAT MASQUERADE to addresses with scope “link”[2] (all of this applies to both IPv4 and IPv6, where IPv6 often enforces these constraints more strictly). At the boundary between your device and the external world, you wanna have one externally facing IP using MASQUERADE and it doesn’t work with link-local IPs. And God forbid you want to have an externally facing link-local IP while your internal network is already running on link-local IPs. Next level hell, this stuff is a mine field. I’ve been down the exact same road, and I have yet to find a good solution.
[1] https://datatracker.ietf.org/doc/html/rfc3927#section-2.7
[2] https://superuser.com/questions/1785242/nat-masquerade-refuses-to-work-on-link-local-network
It might help to explain that “VRF” stands for “virtual routing and forwarding”, and not “verifiable random function”, for instance, or something else.
This is a good idea, but only if your device supports VRF. I’d be interested to know how many common ones do.
There is a hidden link in the first mention of VRFs to https://en.wikipedia.org/wiki/Virtual_routing_and_forwarding.
The text is not underlined though, just bold, so it’s easy to miss. I only noticed cause I read your comment first and wondered if the bold was for a tooltip or something.