Don't pick weird subnets for embedded networks, use VRFs(blog.brixit.nl)
blog.brixit.nl
Don't pick weird subnets for embedded networks, use VRFs
https://blog.brixit.nl/dont-pick-weird-subnets-for-embedded-networks/
36 comments
I’ve encountered this issue with Docker. They randomly assign an RFC1918 subnet for internal services, and occasionally, this subnet clashes with a genuine corporate network or IP address. This can be quite frustrating to troubleshoot, especially if you’re not involved in Docker networking on a daily basis.
I've also run into this issue a lot, especially in AWS when developers with less networking experience start randomly picking VPC subnets (why they were doing that is a whole 'nuther issue). They wonder why connectivity in docker on their ec2 hosts doesn't work, by default docker chooses 172.17/16 which seems to be a common choice for VPC subnets. Annoying, but a teachable moment nonetheless.
It's still difficult to find equipment and ISPs that reliably work with IPv6. I'm sure it will be ready for prime time in the next decade or two, right when we get fusion power plants, self driving cars that don't require supervision, and the AI singularity.
I think that government intervention here is needed in order to coordinate people. We'll all be better off once ivp4 is dead and buried, but the incentive for each entity to do so is minimal. It could be some other powerful entity instead of government, for example tier 1 ISPs degrading ipv4 performance substantially or Google delisting websites that don't support ipv6 (and eventually delisting websites that do support ipv4).
> We'll all be better off once ivp4 is dead and buried
Doesn't IPv6 hurt anonymity? NAT is annoying, but hides the number of devices you have. ISPs assigning you different IPs at different times at least provides some measure of identity resetting.
To say nothing of how easy it is to keep IPv4 devices confined the local network
Or am I missing something?
Doesn't IPv6 hurt anonymity? NAT is annoying, but hides the number of devices you have. ISPs assigning you different IPs at different times at least provides some measure of identity resetting.
To say nothing of how easy it is to keep IPv4 devices confined the local network
Or am I missing something?
IPv6 has temporary addresses for privacy.
https://en.wikipedia.org/wiki/IPv6_address#Temporary_address...
https://en.wikipedia.org/wiki/IPv6_address#Temporary_address...
It's still strictly worse than the privacy you get with ivp4 + NAT. Even with privacy addresses, a device has its own unique (but rotating) address, so it can be uniquely identified. Contrast this with ipv4 + NAT where all devices share the same address, and the only identifying characteristic is the port, which changes on a per-connection basis. On a typical home networking scenario this is handy, because it means advertisers can distinguish traffic coming from your daughter's phone between traffic coming from your PC. With ipv4 they're mixed under one IP address, and you need to resort to various forms of fingerprinting to distinguish them. On a public VPN server this basically kills privacy, which is probably why all the VPNs I've encountered are ipv4 only.
The trick is in that rotating part, I believe. IPv6 is large enough devices could (can/do) rotate regularly. Sure every device is a unique snowflake, but it becomes a snowflake in a blizzard. Things like advertisers are going want to bucket things quickly and so they are still just as likely to use something like /64 subnet as the first pass identifier and your PC and daughter's PC are going to be hundreds or thousands of data points per month in different IPv6 addresses under that subnet. The Pigeon Hole Principle applies at least as well in that case of subnet hashing as NAT44 does. They are going to start with a "bucket" (your subnet) that resembles your whole household, and then filter from there.
The related flip side, though is that NAT44 isn't a privacy solution, it's an over-reliance on the Pigeon Hole Principle and hoping that's enough privacy. An advertiser already has way more data to work with than just IP Address: os/browser combos, user agent strings, cookies, timing habits (device hits website x first thing in the morning), and so much more. NAT44 is absolutely not sufficient for privacy. It is a defense in depth sure, but huge scale difference of IPv6 is a different defense in depth with similar Pigeon Hole Principle properties, it's not necessarily a loss of depth on its own.
The related flip side, though is that NAT44 isn't a privacy solution, it's an over-reliance on the Pigeon Hole Principle and hoping that's enough privacy. An advertiser already has way more data to work with than just IP Address: os/browser combos, user agent strings, cookies, timing habits (device hits website x first thing in the morning), and so much more. NAT44 is absolutely not sufficient for privacy. It is a defense in depth sure, but huge scale difference of IPv6 is a different defense in depth with similar Pigeon Hole Principle properties, it's not necessarily a loss of depth on its own.
If you really want to, you can NAT the v6 just like you do with v4
CGNAT exists which is "much privacy" by your logic. So anyone interested, starting with Google, is already fingerprinting you anyway, so the whole idea what "ipv4+NAT is more private than ipv6" is moot at best.
NB: your useragent already sends enough info to effectively distinguish your from the other users behind the same ipv4 address
NB: your useragent already sends enough info to effectively distinguish your from the other users behind the same ipv4 address
>CGNAT exists which is "much privacy" by your logic. So anyone interested, starting with Google, is already fingerprinting you anyway, so the whole idea what "ipv4+NAT is more private than ipv6" is moot at best.
It's still an extra fingerprinting signal, and all things being equal you'd want less fingerprinting vectors. Otherwise you fall into defeatist line of "google already probably knows my interests quite well, so I might as well not bother trying to obfuscate my advertising history".
It's an extra signal that's basically impossible to spoof
>NB: your useragent already sends enough info to effectively distinguish your from the other users behind the same ipv4 address
???
User-agent provides very limited set of information. Two chrome users on windows have the same user agent. Unless you think everyone in a household uses a different browser/OS combo, user agent isn't enough to distinguish users. You'd need to get into canvas/webgl fingerprinting to uniquely identify a device, and even then that can't distinguish identical devices (eg. two people using iPhone 16)
It's still an extra fingerprinting signal, and all things being equal you'd want less fingerprinting vectors. Otherwise you fall into defeatist line of "google already probably knows my interests quite well, so I might as well not bother trying to obfuscate my advertising history".
It's an extra signal that's basically impossible to spoof
>NB: your useragent already sends enough info to effectively distinguish your from the other users behind the same ipv4 address
???
User-agent provides very limited set of information. Two chrome users on windows have the same user agent. Unless you think everyone in a household uses a different browser/OS combo, user agent isn't enough to distinguish users. You'd need to get into canvas/webgl fingerprinting to uniquely identify a device, and even then that can't distinguish identical devices (eg. two people using iPhone 16)
> It's still an extra fingerprinting signal, and all things being equal you'd want less fingerprinting vectors
Yes, but it's value to the interested party is minuscule, precisely because it's not a permanent and distinguish enough signal. They already have a lot more stronger signals so ditching ipv6 for ipv4+nat would not improve your privacy in any meaningful way.
> User-agent provides very limited set of information
Yes. But if you have two 'users' in your ipv4+NAT network and the one is using an Apple device while the other uses some Android device - you already, without providing any 'extra fingerprinting signal' like a ipv6 address, gave a signal strong enough to distinguish between those users.
> You'd need to get into canvas/webgl fingerprinting to uniquely identify a device
No need for that to distinguish between different users behind a NAT. Your cookies, your UA, your logged in accounts, your requests to fonts.google.com for a fancy website - they all give enough information to do that already. I remind the original point about CGNAT - it's massive amount of users who are intermingled on the same IPv4 pool and even sometimes change the used address in process.
Ad platforms already need to work with an 'non-identifiable' IP:port combo datapoint in the first place, so they do their work to identify you from the every breadcrumb they can leave on your device.
And by the way, if you have any 'cloud enabled' app on your device the big boys already knows where and who you are. Eg: any app what uses Firebase, or Location APIs or bazillion of other 'cloud' things...
Yes, but it's value to the interested party is minuscule, precisely because it's not a permanent and distinguish enough signal. They already have a lot more stronger signals so ditching ipv6 for ipv4+nat would not improve your privacy in any meaningful way.
> User-agent provides very limited set of information
Yes. But if you have two 'users' in your ipv4+NAT network and the one is using an Apple device while the other uses some Android device - you already, without providing any 'extra fingerprinting signal' like a ipv6 address, gave a signal strong enough to distinguish between those users.
> You'd need to get into canvas/webgl fingerprinting to uniquely identify a device
No need for that to distinguish between different users behind a NAT. Your cookies, your UA, your logged in accounts, your requests to fonts.google.com for a fancy website - they all give enough information to do that already. I remind the original point about CGNAT - it's massive amount of users who are intermingled on the same IPv4 pool and even sometimes change the used address in process.
Ad platforms already need to work with an 'non-identifiable' IP:port combo datapoint in the first place, so they do their work to identify you from the every breadcrumb they can leave on your device.
And by the way, if you have any 'cloud enabled' app on your device the big boys already knows where and who you are. Eg: any app what uses Firebase, or Location APIs or bazillion of other 'cloud' things...
Really? The network protocol someone uses is so critical that it should be illegal to use the wrong one? What happens when IPv9 becomes the hot new thing, but everyone is stuck on IPv6, because of some outdated government regulation? Do Americans have the right to use whatever internet protocol they want, under the first amendment?
IPv6 has made enough progress that it's totally possible to run your network off of it, regardless of what everyone else is doing, and if all of your neghbors are using IPv4, it won't harm your IPv6 network.
Also, part of the delay in the switch to IPv6 is that some work is needed to ensure that home routers and IoT devices default to reasonable security settings, and the absolute worst thing to do is force them to switch first, and figure out security later.
The answer isn't to force everyone to use something before its ready; the answer is to address every impediment, so it's worth it for everyone to switch. Sure it's slower, but it's much better than making users worse off by switching, converting them to detractors instead of supporters.
IPv6 has made enough progress that it's totally possible to run your network off of it, regardless of what everyone else is doing, and if all of your neghbors are using IPv4, it won't harm your IPv6 network.
Also, part of the delay in the switch to IPv6 is that some work is needed to ensure that home routers and IoT devices default to reasonable security settings, and the absolute worst thing to do is force them to switch first, and figure out security later.
The answer isn't to force everyone to use something before its ready; the answer is to address every impediment, so it's worth it for everyone to switch. Sure it's slower, but it's much better than making users worse off by switching, converting them to detractors instead of supporters.
I don't see a reason why IPv9 would ever need to be a thing.
We will never get rid of ipv4. Apparently my country ISPs have more ipv4 than they need (they actually rent them to others), so they just don't bother with ipv6.
I guess when the world moves away from IPv4, your country will have the entire IPv4 space for itself, and massive headaches with NAT to route out, and the relative impossibility to route in.
I understand your pessimism but believe IPv6 is coming.
I worked on network management software, the kind of software that runs on out of band networks that are unlikely to ever need IPv6. In the beginning IPv6 was a required feature for sales but it was accepted that no one was going to use it so little effort was put into testing it. More recently, it HAS to work. It is being used in anger internally in large telecoms companies.
I expect adoption to proceed at a glacial pace until some tipping point. Consumer ISPs will be the last to adopt it.
I worked on network management software, the kind of software that runs on out of band networks that are unlikely to ever need IPv6. In the beginning IPv6 was a required feature for sales but it was accepted that no one was going to use it so little effort was put into testing it. More recently, it HAS to work. It is being used in anger internally in large telecoms companies.
I expect adoption to proceed at a glacial pace until some tipping point. Consumer ISPs will be the last to adopt it.
The real official answer is to register/allocate a new subnet, with no intention of putting it into the global routing tables. IPv6 only comes into play because doing that with IPv4 is mostly impractical these days.
The author lost me when they got into raw iproute commands. Not because I'm not acquainted (I run my own custom complex router using a standard Linux distro). But rather if someone knows enough to configure things at this level, then they would just come to this solution on their own. Most people trying to solve this problem will not - eg think that mobile video rack belonging to a touring musician.
Readily-accessible solutions I can come up with off the top of my head:
1. Two off the shelf routers and double NAT. The middle network can be changed if it conflicts with the outer network
2. One router/NAT, but two IP networks on the inner network - one statically assigned for devices to communicate with each other, and one assigned via DHCP for accessing the horizon through NAT. That second network can then easily be changed.
3. Play battleship more strategically using class E address space, DOD/BigCo address space, and/or smaller subnets in the middle of the customary size for a range (eg 192.168.1.160/27).
The author lost me when they got into raw iproute commands. Not because I'm not acquainted (I run my own custom complex router using a standard Linux distro). But rather if someone knows enough to configure things at this level, then they would just come to this solution on their own. Most people trying to solve this problem will not - eg think that mobile video rack belonging to a touring musician.
Readily-accessible solutions I can come up with off the top of my head:
1. Two off the shelf routers and double NAT. The middle network can be changed if it conflicts with the outer network
2. One router/NAT, but two IP networks on the inner network - one statically assigned for devices to communicate with each other, and one assigned via DHCP for accessing the horizon through NAT. That second network can then easily be changed.
3. Play battleship more strategically using class E address space, DOD/BigCo address space, and/or smaller subnets in the middle of the customary size for a range (eg 192.168.1.160/27).
Allocating a subnet is way further away from reality for most people than configuring one router feature on the router they're using.
There's also a lot of people that configure these devices (or linux routers) themselves but have never heard of VRFs, you got to learn about them somewhere so I just hope this helps some people :)
There's also a lot of people that configure these devices (or linux routers) themselves but have never heard of VRFs, you got to learn about them somewhere so I just hope this helps some people :)
I see your point if someone is at the level of tinkering enough to learn Mikrotik gear. I was loosely equating VRF with general Linux policy routing, where you end up owning a bit more of an overarching config with fwmarks etc. And then I reasoned that Mikrotik was more complex than that, because I personally avoid doing config on my Mikrotik devices in favor of the Linux router (which is the opposite if you're coming at it unopinionated). But if someone wants to understand just enough networking to copy and paste Mikrotik examples, I do think your post is good general suggestion for that.
If I can avoid Double NATing, I do because it tends to degrade network performance and can have interesting characteristics on some inbound traffic (although that depends on the use case).
But the third option honestly isn’t recommended enough. DoD space is rarely routable, and if you are on a private network already, even moreso. It’s also less common than RFC1918.
However, there is one caveat. Some large corporates do use it for just the same reason. Even though it is rarer than 10 or 172 space, you’d be surprised how many large orgs do run DoD internally.
(Disclaimer: I use DoD space for my travel router at hotels)
But the third option honestly isn’t recommended enough. DoD space is rarely routable, and if you are on a private network already, even moreso. It’s also less common than RFC1918.
However, there is one caveat. Some large corporates do use it for just the same reason. Even though it is rarer than 10 or 172 space, you’d be surprised how many large orgs do run DoD internally.
(Disclaimer: I use DoD space for my travel router at hotels)
can't they just put each port on it's own vlan and call it a day?
I've always been able to solve this problem more simply using IPv4 link-local addressing (https://www.rfc-editor.org/rfc/rfc3927), it doesn't matter if somebody abuses the same range because the outbound interface is explicitly specified in sin6_scope_id passed to connect() and bind().
But if you're writing code at a higher level than the bsd sockets api, it's a whole can of worms.
But if you're writing code at a higher level than the bsd sockets api, it's a whole can of worms.
Maybe I'm dumb, but how do hosts from different subnets address each other, when they get the same IP addresses?
In the VRF case they can't: "This comes with a tradeoff of course and in this case is that you no longer can reach devices on the venue network, which shouldn't be a problem if you're only connected there for internet connectivity."
Ok, but why want you to connect to local networks, when they can't reach each other, wouldn't you just then connect to the upstream router instead?
That's typically all you care about, the upstream router/gateway so you can get to the internet. But it's on the local network, so you need to connect to it.
I think most regular off the shelf consumer WiFi routers can already do this.
The "192.168.0.1" ip address being the internal network and the external network because you're chaining routers together is awfully common and consumers expect it to just work without needing to understand IP addresses like a nerd.
The "192.168.0.1" ip address being the internal network and the external network because you're chaining routers together is awfully common and consumers expect it to just work without needing to understand IP addresses like a nerd.
As a network engineer it was interesting to read about VRFs and routing from the perspective of an A/V engineer. Thanks
2 big address block that have few chances of conflict:
- CGNAT 100.64.0.0/10
- "Benchmark" 198.18.0.0/15
- CGNAT 100.64.0.0/10
- "Benchmark" 198.18.0.0/15
CGNAT is used by Tailscale and presumably in the wild for its intended purpose.
And `100.115.92.0/23` is used by ChromeOS for PatchPanel: https://chromium.googlesource.com/chromiumos/platform2/+/mai...
[deleted]