4 ms·

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 w

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.

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.