4 ms·

> When you're using a private network v4 address exhaustion doesn't matter much Until you start trying to connect to enterprise networks... This is seriously

by api 7y ago

> When you're using a private network v4 address exhaustion doesn't matter much Until you start trying to connect to enterprise networks... This is seriously ridiculous. It's 2020, and Google and now DO have no IPv6 in their cloud networks.

JonathonW 7y ago
DO has IPv6 on the public side of their network. Couldn't tell you why they've chosen not to use IPv6 for VPC networks, though. Probably just for management simplicity.
- jrockway 7y ago
  DO sort of has IPv6. Their load balancers don't do IPv6, and you can't use IPv6 in their managed k8s offering. (My guess, honestly, is that nobody asks for it. IPv6 is a problem for Some Other Day.)
  - caymanjim 7y ago
    They also only give you 16 addresses. 16! Most providers give you an entire /64 or sometimes even a /48.
    - RaitoBezarius 7y ago
      Wow. In France, home ISP give you a /64 generally (Free for example, known for Online/Scaleway). I think 80 % of their fiber deployments comes with IPv6 enabled now. And in few years, it should be 100 %.
      - lloeki 7y ago
        When I was a customer, Free gave you eight (or was it 16?) /64 (as it appeared in the UI[0], I seem to recall they may not all be contiguous), 7 of them you could use for prefix delegation (can't recall why using the first one caused issues, IIRC it was special cased in some way as the "main" one that the Freebox wants to manage). Also it was 6rd, not purely native IPv6. Hopefully they changed that because latency was bad enough the devices would often pick IPv4 through Happy Eyeballs and throughput was a half to a tenth of the v4 path. After that, I had a whole native /56 at Red by SFR. Currently I'm at Sosh by Orange and I have a native /56. [0]: https://lafibre.info/remplacer-freebox/freebox-erl-et-ipv6/?action=dlattach;attach=67928 https://lafibre.info/remplacer-freebox/freebox-erl-et-ipv6/?...
beagle3 7y ago
As a (former) network security guy, I shudder at the thought that you WANT to expose your internal routing details. That's a recipe for security disaster. It is also an administration problem - you've given out an internal IP network to someone else -- and now your ability to move it to a different IP address for whatever reason depends on the change processes at the other enterprise, which can take months -- or on the ability of your own network infrastructure to NAT it to the new location. It tends to work much better all around if you have a well defined "external" interface, that gets properly monitored and filtered with a network/app firewall, and gets routed to the right server -- and then internal change for your organization are decoupled from change processes in the others. And for that, v4 exhaustion really doesn't matter.
- api 7y ago
  I don't get this. IPv4's address space is so small I can trivially scan any internal network, and there are a ton of ways to gather that data covertly from behind the firewall via maliciously crafted web pages or apps, abuse of any number of P2P apps or protocols (VoIP, video chat, WebRTC, etc.), and so on. IPv6 actually makes scanning harder since the address space is massive. E.g. if I have a /64 routed internally I have to scan 2^64 addresses to find internal hosts! If knowing internal IP addresses is a security risk, then IMHO you have serious security problems. I used to do netsec too and the cornerstone was internal scans for unpatched or rogue systems and services and keeping systems patched and locked down. A network is only as secure as what is connected to it! We also had smart switches and APs where you could lock port to MAC and IP and thus could prevent rogues. My personal rule was: any system that would not be safe to directly connect to the Internet without a firewall is insecure and needs to be fixed. The only exception is backplanes for things like internal databases/services or testing/dev, and those were separate networks for that purpose only. Separation was either physical or virtual/cryptographic. Back then we didn't have stuff like ZeroTier so we did that with IPSec and it was ugly, but we did it. Those nets could sometimes access the Internet (with restrictions) but could not even see the controlled internal LAN. They accessed the net via a port to outside the DMZ. Next up was auditing software installed on internal systems. Next up was monitoring network traffic to detect anomalous activity. Firewalls are always the last line of defense. NAT is not a security feature at all. I never once worried about keeping internal IPs secret (why?) and we ran IPv6 internally without NAT because IPv6 NAT is dumb. We had two incidents when I was there. Both were the result of phishing to get malware onto personal PCs or phones. My very strong personal opinion is that security people worry about the wrong things. They worry about network security and firewalls when what should really terrify them is phishing, auto-updating software made by who-knows-who, popular apps and SaaS services that are invisible security dumpster fires (Zoom anyone?), and of course barbarous demonic evocations like "npm install ...". Your firewall will do very little to save you from any of that, and NAT won't do crap because once again NAT is not a security feature.

by api 7y ago

JonathonW 7y ago

DO has IPv6 on the public side of their network. Couldn't tell you why they've chosen not to use IPv6 for VPC networks, though. Probably just for management simplicity.

jrockway 7y ago
DO sort of has IPv6. Their load balancers don't do IPv6, and you can't use IPv6 in their managed k8s offering. (My guess, honestly, is that nobody asks for it. IPv6 is a problem for Some Other Day.)
- caymanjim 7y ago
  They also only give you 16 addresses. 16! Most providers give you an entire /64 or sometimes even a /48.
  - RaitoBezarius 7y ago
    Wow. In France, home ISP give you a /64 generally (Free for example, known for Online/Scaleway). I think 80 % of their fiber deployments comes with IPv6 enabled now. And in few years, it should be 100 %.
    - lloeki 7y ago
      When I was a customer, Free gave you eight (or was it 16?) /64 (as it appeared in the UI[0], I seem to recall they may not all be contiguous), 7 of them you could use for prefix delegation (can't recall why using the first one caused issues, IIRC it was special cased in some way as the "main" one that the Freebox wants to manage). Also it was 6rd, not purely native IPv6. Hopefully they changed that because latency was bad enough the devices would often pick IPv4 through Happy Eyeballs and throughput was a half to a tenth of the v4 path. After that, I had a whole native /56 at Red by SFR. Currently I'm at Sosh by Orange and I have a native /56. [0]: https://lafibre.info/remplacer-freebox/freebox-erl-et-ipv6/?action=dlattach;attach=67928 https://lafibre.info/remplacer-freebox/freebox-erl-et-ipv6/?...

beagle3 7y ago

As a (former) network security guy, I shudder at the thought that you WANT to expose your internal routing details. That's a recipe for security disaster. It is also an administration problem - you've given out an internal IP network to someone else -- and now your ability to move it to a different IP address for whatever reason depends on the change processes at the other enterprise, which can take months -- or on the ability of your own network infrastructure to NAT it to the new location. It tends to work much better all around if you have a well defined "external" interface, that gets properly monitored and filtered with a network/app firewall, and gets routed to the right server -- and then internal change for your organization are decoupled from change processes in the others. And for that, v4 exhaustion really doesn't matter.

api 7y ago
I don't get this. IPv4's address space is so small I can trivially scan any internal network, and there are a ton of ways to gather that data covertly from behind the firewall via maliciously crafted web pages or apps, abuse of any number of P2P apps or protocols (VoIP, video chat, WebRTC, etc.), and so on. IPv6 actually makes scanning harder since the address space is massive. E.g. if I have a /64 routed internally I have to scan 2^64 addresses to find internal hosts! If knowing internal IP addresses is a security risk, then IMHO you have serious security problems. I used to do netsec too and the cornerstone was internal scans for unpatched or rogue systems and services and keeping systems patched and locked down. A network is only as secure as what is connected to it! We also had smart switches and APs where you could lock port to MAC and IP and thus could prevent rogues. My personal rule was: any system that would not be safe to directly connect to the Internet without a firewall is insecure and needs to be fixed. The only exception is backplanes for things like internal databases/services or testing/dev, and those were separate networks for that purpose only. Separation was either physical or virtual/cryptographic. Back then we didn't have stuff like ZeroTier so we did that with IPSec and it was ugly, but we did it. Those nets could sometimes access the Internet (with restrictions) but could not even see the controlled internal LAN. They accessed the net via a port to outside the DMZ. Next up was auditing software installed on internal systems. Next up was monitoring network traffic to detect anomalous activity. Firewalls are always the last line of defense. NAT is not a security feature at all. I never once worried about keeping internal IPs secret (why?) and we ran IPv6 internally without NAT because IPv6 NAT is dumb. We had two incidents when I was there. Both were the result of phishing to get malware onto personal PCs or phones. My very strong personal opinion is that security people worry about the wrong things. They worry about network security and firewalls when what should really terrify them is phishing, auto-updating software made by who-knows-who, popular apps and SaaS services that are invisible security dumpster fires (Zoom anyone?), and of course barbarous demonic evocations like "npm install ...". Your firewall will do very little to save you from any of that, and NAT won't do crap because once again NAT is not a security feature.