81–90 of 123 posts
Earlier quoted context omitted.
IPv6 is very badly supported at the low end of the market. Cheap webcams, doorbells, etc. And that not counting already old equipment... If we had a nuclear war, we could start over. But for now, we are stuck. Blame it on Cisco for inventing NAT.
man this sounds so realistic, a system administrator saying "yes! Now we can migrate to the IPv6" after the 99.9 percent of the world population is killed
Earlier quoted context omitted.
The problem with talking to a telco, is you have to talk with not just one but any your customer may use. And if at the customer location there’s multiple routers in between the cameras and that telco router, it’s a shitshow trying to configure anything. Much easier to drop some router on site that is telco neutral and connect back to your telco neutral dc/hq.
That's all true, but you can also, you know, like, talk to people without buying your whole solution from them :) (btw, have you actually read past the first 7 words? I'm much more interested what people think about the latter parts.)
Need to provide support access to 10k-50k locations all with the same subnet (industry standard equipment where the vendor mandates specific IP addressing, for better or worse). They are always feeding in data into the core too.
Much easier to just VPN+NAT.
Earlier quoted context omitted.
The problem with talking to a telco, is you have to talk with not just one but any your customer may use. And if at the customer location there’s multiple routers in between the cameras and that telco router, it’s a shitshow trying to configure anything. Much easier to drop some router on site that is telco neutral and connect back to your telco neutral dc/hq.
The Metro Ethernet Forum standardized a lot of services telcos can offer, many years ago
May as well pick a single solution that works across all Internet connections and weird setups, be an expert in that, vs having to manage varying network approaches based on telco presence, local network equipment, operating country, etc.
Earlier quoted context omitted.
I wouldn't be surprised if a lot of the hardware under management (e.g. IP cameras, NVRs, cable modems) lacks support for IPv6, and/or the customer networks that it's resident on don't have working IPv6 transit.
The solution is to run ipv6 on the overlay and have the customer site gateway thing they have to translate it to target ipv4. Conveniently you can do the translation it more or less statefully and very easily because you can just embed the ipv4 addr in ipv6. For example you could grab a /64 prefix, assign 32 bits to customer/gateway id and other 32 bits to target ipv4 addr.
Earlier quoted context omitted.
I just use /24s in the lower-middle range of 172.16. Very unlikely to have a conflict there.
Do you run Docker? Because I remember having to VPN out to a client that used that range, and it caused conflicts where our docker containers couldn't reach the client side to fetch data. Docker defaults to 172.16.0.0/16.
It was pretty easy to cause myself problems with Docker compose. Eventually I run out of subnets in the 172.16 range and it happily created subnets in the 192.168. range. Some of them overlapped with subnets on my LAN.
> But the moment two sites share the same address range, you have an ambiguity that IP routing cannot resolve. Writing PF or nft rules to NAT these hyper-legacy subnets on the local side of the layer3 tunnel is actually super trivial, like 20 seconds of effort to reason about and write in a config manifest. Like written the article, a device on the customer site is required. At that point you might as well deploy a r…
Why not IPv6? Pretending that it doesn't exist?? https://en.wikipedia.org/wiki/List_of_IPv6_transition_mechan...
Shameless plug - this is exactly the same problem that our team had when we had to maintain a bunch of our customer's servers. All of the subnets were same, and we had to jump through hoops just to access those servers - vpns, port forwarding, dynamic dns with vnc - we've tried it all. That is why we developed https://sshreach.me/ - now it's a click of a button.
The best strategy might be to maintain the ability to easily reassign the network for a site. If every site is non-overlapping the problem does become trivial. I'd much rather fight a one time "reboot your machines tonight" battle than the ongoing misery of mapping things that do not want to be.