4 ms·

> "screw it just disable ipv6 everywhere" Troubleshooting step #1. Sad (reasonable, but sad).

iso1631 3y ago
ipv6 doesn't give most people the business benefits. These are companies that are perfectly happy with on prem rfc1918 addresses and a bit of srcnat, and indeed are likely reducing that space requirement today as more stuff moves into 'the cloud' Why spend money trying to get ipv6 work when your laptops work fine with a 192.168.x.x range
- simoncion 3y ago
  On the other hand, even something as easy as ULAs would have saved a former employer of mine three+ months of effort in network renumbering (and other directly-related resource management activities (like, suchas, deciding "Is it more trouble to renumber this, or merely turn it off and deal with having a much, much shittier replacement?")) planning after a corporate merger.
  - iso1631 3y ago
    It's almost certain you'd have deployed a dual stack ipv4 and ipv6 internal network so you'd have to re-number the ipv4 part anyway, and still probably end up with a mess with ipv6.
    - simoncion 3y ago
      > It's almost certain you'd have deployed a dual stack ipv4 and ipv6 internal network... For the ones that needed Internet access, sure. But, a huge chunk of these machines were machines that never, ever, ever talked outside of the corporate intranet, so they never needed an Internet gateway, and NAT was never an issue. Assigning these boxes an address from a ULA would have worked just fine. > ...you'd have to re-number the ipv4 part anyway, As mentioned above, for the machines that did need to talk to the Internet (which required them to have v4 addresses) yeah, sure. > ...and still probably end up with a mess with ipv6. I don't see how this follows from what you said. The way you generate ULA prefixes means that you're highly unlikely to ever have to renumber ULA-using networks that you want to merge. Do you have specific addressing perils or pitfalls in mind? (Bear in mind that you're talking to someone who has been happily using IPv6 at home for twenty years, and someone who's quite aware that companies like Comcast, T-Mobile, and a bunch of other telecoms run IPv6 on their infrastructure (and often their customer-facing) networks, trouble-free, and have been for many, many years.)
    - kccqzy 3y ago
      Why would you make the internal network dual stack? Now you need to two sets of firewall rules, and devices have two protocols to reach each other making debugging unnecessarily difficult. Most traditional internal networks are IPv4 only. In larger tech companies where 10.0.0.0/8 isn't enough, internal networks are IPv6 only. Only a tiny number of Internet-facing servers (like your load balancer / reverse proxy for external traffic) should be dual-stack.

ipv6 doesn't give most people the business benefits. These are companies that are perfectly happy with on prem rfc1918 addresses and a bit of srcnat, and indeed are likely reducing that space requirement today as more stuff moves into 'the cloud' Why spend money trying to get ipv6 work when your laptops work fine with a 192.168.x.x range

simoncion 3y ago
On the other hand, even something as easy as ULAs would have saved a former employer of mine three+ months of effort in network renumbering (and other directly-related resource management activities (like, suchas, deciding "Is it more trouble to renumber this, or merely turn it off and deal with having a much, much shittier replacement?")) planning after a corporate merger.
- iso1631 3y ago
  It's almost certain you'd have deployed a dual stack ipv4 and ipv6 internal network so you'd have to re-number the ipv4 part anyway, and still probably end up with a mess with ipv6.
  - simoncion 3y ago
    > It's almost certain you'd have deployed a dual stack ipv4 and ipv6 internal network... For the ones that needed Internet access, sure. But, a huge chunk of these machines were machines that never, ever, ever talked outside of the corporate intranet, so they never needed an Internet gateway, and NAT was never an issue. Assigning these boxes an address from a ULA would have worked just fine. > ...you'd have to re-number the ipv4 part anyway, As mentioned above, for the machines that did need to talk to the Internet (which required them to have v4 addresses) yeah, sure. > ...and still probably end up with a mess with ipv6. I don't see how this follows from what you said. The way you generate ULA prefixes means that you're highly unlikely to ever have to renumber ULA-using networks that you want to merge. Do you have specific addressing perils or pitfalls in mind? (Bear in mind that you're talking to someone who has been happily using IPv6 at home for twenty years, and someone who's quite aware that companies like Comcast, T-Mobile, and a bunch of other telecoms run IPv6 on their infrastructure (and often their customer-facing) networks, trouble-free, and have been for many, many years.)
  - kccqzy 3y ago
    Why would you make the internal network dual stack? Now you need to two sets of firewall rules, and devices have two protocols to reach each other making debugging unnecessarily difficult. Most traditional internal networks are IPv4 only. In larger tech companies where 10.0.0.0/8 isn't enough, internal networks are IPv6 only. Only a tiny number of Internet-facing servers (like your load balancer / reverse proxy for external traffic) should be dual-stack.