10 ms·

It seems obviously against AWS incentives to offer working v6 - all their influencing tools ("well architected" criteria, certificates) strongly herd you toward

It seems obviously against AWS incentives to offer working v6 - all their influencing tools ("well architected" criteria, certificates) strongly herd you towards building mazes of ambigously addressed 10.x RFC1918 networks, and not internet style architectures with end-to-end addressing. In the world of their recommendations, even the concept of a "public ip address" is a red flag, and AWS even recommends (for an added cost of course) tooling to flag and "mitigate" them. These provide a strong lock-in effect when customers spend effort to build the complex infrastructure for them in the name of security, even though in reality they hurt security through unnecessary complexity, addressing ambiguity, etc.

beoberha 3y ago
I work in Azure, but my experience is that customers want this - and for good reason. Customers want their own private network to prevent intrusions and exfiltrations, just on machines they don’t own. Or even better, put the nice fancy batteries included PaaS services in these networks too.
- jojobas 3y ago
  Right, cause customers are too stupid to manage their own IPv6 firewalls, it's for their own good! /s
  - rad_gruchalski 3y ago
    I’m pretty confident that this statement is mostly true without sarcasm, and that you are in the minority.
    - pantalaimon 3y ago
      How is managing a NAT easier than managing a firewall?
      - ninkendo 3y ago
        I’m one typo away from accidentally allowing IPv6 access to every machine in my network with my pf config on my home router. (I know this because I’ve done it one time, and didn’t notice for about a week.) There is no such typo i could make with my single shared public ipv4 address because it’s just one address. Saying “allow” by accident isn’t enough, I’d have to somehow accidentally configure the particular ingress port to NAT to a particular internal machine, and even then it would only affect that machine and no other. (Full disclosure, i actually like IPv6 and am in full favor of everything moving to it. This is in spite of the above, but i at least recognize that the above is the case.)
  - thebytefairy 3y ago
    I work with Fortune 50s in cloud, and they can barely manage ipv4. If you're in a digital native it's different, but in my experience most behemoths do not inspire confidence with how on top of their network infrastructure they are.
    - amluto 3y ago
      This is a bit like saying “customers can barely manage driving a stick shift with a manual choke — we shouldn’t let them drive automatics!” IPv6 isn’t amazing, but it makes many of these problems simply disappear. Of course [0] networks should be isolated, but this should be achieved with a firewall that, by default, disallows connections between the public Internet and private networks. And that’s about it — every VM has a globally unique address, routing just works, one company (if permitted) can connect to another company’s endpoints, firewalls can be deployed where they make sense instead of being forced to exist exactly where inconsistently-addressed networks meet, etc. The entire mess of designing and negotiating allocation of extremely limited IPv4 addresses for private systems simply disappears! [0] Beyond corp has something to say about this.
  - vasachi 3y ago
    Well, I wouldn't put _any_ service on a public network, unless it is explicitly required. Firewall is all well and good, but security in depth is even better. Private networking is good. IPv6 doesn't help here at all.
    - solatic 3y ago
      The easiest firewall in the world is one that is set up to deny all traffic from all sources. Which is how any decent firewall is configured by default anyway. I'm not saying that running a private network doesn't provide genuine security value, only that it drastically complicates your networking architecture for very little security benefit. Organizations can decide whether that trade-off is worth it, for organizations with deep threat models like militaries and banks, it's probably worth it. For 99% of the private sector, it's folly.
    - MayeulC 3y ago
      "Private networking" as defined by assigning private-range IP addresses are only private as long as there is no route to your network, or as long as it's isolated on a dedicated vlan (even then, there could be some rogue machines). In the first case, you need a firewall for IPv4 anyway. In the second case, that would also work with IPv6. Disclaimer: I know nothing about Azure/AWS internals.
    - Shorel 3y ago
      Therefore job security of old school network administrators is the main factor against IPv6 coverage. Hopefully one of the big cloud providers figures it is in their best interest to have a much bigger address space and make all this busywork sinecure obsolete.
      - vasachi 3y ago
        Good luck administering IPv6 networks, they are so much easier to understand.
    - fulafel 3y ago
      This phrasing is really problematic. Using internet addressing (vs ambiguous addresses) does not make your network "public". Just like using unique MAC addresses doesn't. Confusing global addressing with public reachabiliy is exactly the rhetoric used by AWS, Azure etc to scare people into building mazes of ambiguously addressed 10.x networks.
- throw0101b 3y ago
  > Customers want their own private network to prevent intrusions and exfiltrations, just on machines they don’t own. If your (default) gateway from one network segment to another network segment only has one rule, default-deny, then it's not a problem. If you think that's not enough, then use IPv6 ULA (fd00::/8). But why should the incompetence of some customers limit what all customers can do?
- xnyanta 3y ago
  I see this at work, being within such a customer. People driving these mandates barely understand IPv4, let alone know what IPv6 is. They're software developers after all, not CCIEs. There's nothing preventing you from having a private network using unique address space that's either blocked from accessing the internet via a firewall on a router or just plain not even routed. You could even use ULA networks with stateless prefix translation to avoid using GUA addressing for your private network. The sad part is that IPv6 support is abysmal on every cloud so just migrating to it imposes serious limitations as addressed by the blog author.
jiggawatts 3y ago
Azure is copying this wholesale. I've lost track of all of the "Private Endpoints", "Private Links", "Service Endpoints", "Private Resolvers" and "Virtual WAN" products they've introduced... all to make IPv4 work at scale. Literally none of those products would be required if they had just made IPv6 work properly. Instead, they NAT IPv6, so you can't even use it to avoid the NAT forced upon you by IPv4. They also release new products -- in 2023 -- that don't support IPv6 and likely never will. There is still an entire page[1] of listed limitations in the docs: https://learn.microsoft.com/en-us/azure/virtual-network/ip-services/ipv6-overview#limitations https://learn.microsoft.com/en-us/azure/virtual-network/ip-s... Think about how insane it would be if this was the IPX -> IPv4 transition. Imagine if this page said "IPv4 limitations: All VMs must include at least one IPX address, etc..." Sounds nuts, right? I was migrating customers to IPv4 from IPX in 1999, and IPv6 support materialised in about the 2001-2003 timeframe. It's been decades, but it still feels like 1999 and migrating Novell NetWare where we had to have IPX+IPv4 because "not everything supports IPv4 yet". [1] This is definitely not all of the limitations. Most of their PaaS products don't support IPv6. Hence, any IaaS+PaaS solutions must use (mostly) IPv4.
- benterix 3y ago
  Wait a second. A private link means that a service endpoint is public so a part of your traffic goes through the Internet, which is supposed to be insecure (even if you have encryption in transit?), so you don't want to do that and they will happily route your traffic internally so it is not exposed to the bad Internet - for a fee. All these VPC Endpoints etc. cost money and you are charged by the our. I don't think IPv6 would change anything here, they would find a way to charge customers for "security" anyway.
  - jiggawatts 3y ago
    That's what I thought at first, but that's not quite right. Service Endpoint: Allows a PaaS service (that itself uses public addresses) have firewall rules for overlapping private vnet addresses. E.g.: You can have have two VMs both on 10.0.0.123 addresses (in separate VNets) using individual "Allow" rules to the target service. Essentially Azure tags the traffic at the VXLAN level with the source network ID on top of the IP address, making it a "fat IP address" that is unique within Azure and can be used in firewall rules. Private Endpoint: Makes a PaaS service appear on a private network address range instead of the default public range. This allows your on-prem firewalls to isolate your specific PaaS instance from other customers -- otherwise the traffic gets "blended in" with everyone else in the same public service tag ranges. This also allows you to use your ExpressRoute fibre links to route traffic from on-prem to the public service. In all scenarios, the traffic goes over Azure networks and/or Microsoft's private backbone. You have to go out of your way to route traffic "via the Internet". Remember: Network addresses are just numbers! Routing rules determine how they flow, and public addresses can be used on private networks. Fundamentally, all this exists just to enable the ability to firewall things. With overlapping IPv4 addresses and small shared blocks of IPv4 addresses with NAT behind them, it would be impossible otherwise. With IPv6, using firewalls would be much simpler because overlapping addresses aren't needed any more. Similarly, PaaS services could trivially allocate IPv6 addresses per customer instance, so that customers could apply selective firewall rules.
benterix 3y ago
I'm not convinced these 2 are related. If AWS wanted, they could start promoting IPv6 as a panacea to all internal network problems (if they had it working, that is), and the competition would have a hard time catching up. My guess is the reason is more mundane: supporting IPv4 is just easier, especially if you take into account the number of their services.
- 9dev 3y ago
  While this is probably exactly the spin the AWS sales team head in mind, it conveniently glosses over all the IPv4 related products customers won’t need anymore if they use IPv6, and thus pay a lot less for their simplified network infrastructure. AWS has no incentive to support IPv6 from a sales perspective.
  - supriyo-biswas 3y ago
    In addition, IPv4 addresses are an asset that has monetary value; and there’s no reason AWS would want to drive down the value of the asset by helping customers migrate to IPv6.
    - ttegloma 3y ago
      Sure there is. AWS has a vested interest in the value of IPv4 going down as much as possible. Owning IPv4 addresses is a requirement of AWS’s core business. Unless people stop using IPv4, then AWS cannot sell those addresses. There is no incentive for the addresses to increase in value. Further, if people continue to use IPv4, then AWS has to continue to acquire even more IPv4, and AWS wants the price of those to go down so that acquiring them is cheaper (or wants people to stop using IPv4 so that they can stop spending money on them altogether).
      - jen20 3y ago
        > Unless people stop using IPv4, then AWS cannot sell those addresses. There is no incentive for the addresses to increase in value. But if people stop using IPv4, the asset (billions of dollars by some accounts) becomes worthless... AWS are passing on the cost for public IPv4 addresses now, so there's even less incentive.
rewmie 3y ago
> These provide a strong lock-in effect when customers spend effort to build the complex infrastructure for them in the name of security, even though in reality they hurt security through unnecessary complexity, addressing ambiguity, etc. How do you hurt security by preventing external access to your internal services?
- 9dev 3y ago
  By making it necessary to use automated tooling and even obtain certifications just to set up everything required for private networking. The complexity of a properly configured service mesh in AWS is staggering, extremely hard for newbies to get right, and easy to fuck up big time down the road. That hurts security.
  - vasachi 3y ago
    Are hundreds of publicly addressable services better?
    - amluto 3y ago
      Yes, because publicly addressable does not mean publicly accessible. Set the ACLs to deny by default. In the v4 world, one can easily accidentally allow access by inadvertently sending traffic toward the wrong group of colliding addresses or otherwise messing up any of a number of things that ought not to be necessary in the first place.
      - otabdeveloper4 3y ago
        You need both firewalls and private addresses, of course. Anything else is amateur hour madness.
        amluto 3y ago
        Why do I need private addresses? Okay, in real life I need private addresses because I connect to things that are only available over IPv4. So there’s some negotiation to make sure that my private network does not have an addressing conflict with the other network, there are NATs in the way, and traceroute gives output that is every bit as bad as you would expect. The ACLs that everyone (arguably quite reasonably) sets up suck are fiddly because the clients don’t have well defined address ranges. When people allocate /24 subsets out of IPv4 private space, the probability of collision is annoyingly high. Amateur hour indeed. I would take globally unique but “private” IPv6 addresses, over private links, with private routes (dynamic or static), and ACLs that actually make sense any day. Heck, I would happily go IPv6 only!
bushbaba 3y ago
Maybe just maybe. Customers don’t really want IPv6 but are forced onto it. Ipv6 is not human usable and gets rid of a bunch of network design norms.
- supriyo-biswas 3y ago
  This “human usable” argument gets trotted out so much on here and elsewhere, but the same people would be surprised to know about HTTP/2, TLS and the like, which by that definition, isn’t human usable either because of binary formats and encryption. People never interact with these protocols directly and use a layer of indirection such as a HTTP/2 client for HTTP, and the same applies for IPv6: use DNS (or your hosts file).
  - butlerm 3y ago
    There are a number of relevant issues here, including the general problem that DNS is not trustable and is not reliable or not reliable enough to use for configuring routers and firewalls. It is not even necessarily accessible or usable for reverse lookup at all. DNS wasn't really designed for common cases where network administrators enter IP address prefixes. That could probably fixed to some degree using a name system that was designed for security use, including operation when the network is partitioned or wildly malfunctioning. And of course the need to maintain two sets of IP addresses and two sets of IP address prefixes - even and especially in DNS itself - is probably the number one factor slowing down the deployment of IPv6. That and far too many places, far too many interfaces, far too many protocols, and far too many APIs (notably Berkeley sockets) that are not transparent to which network layer protocol is being used or what the address format is. The wire format, transfer format, configuration format, and administration of DNS address records is a case in point.
    - supriyo-biswas 3y ago
      Adding another DNS record or changing a socket listener is hardly the issue though. Most sysadmins are unfamiliar with IPv6 networking concepts such as NDP, DHCPv6 and so on, and having to learn a new system is what hinders its adoption. Unfortunately, such changes are quite common in networking; Linux networking has many moving parts these days, there was the move to iproute2 and nftables, and the like, so one can only try to best keep up with the changes.
cameronh90 3y ago
It's not just AWS. Microsoft, security auditors, penetration testers, cyber insurance companies, etc. also largely insist on not having publicly addressable endpoints. I don't understand why, but until some large tech company starts pushing for end to end addressability as best practice, I have no choice but to follow the conventional wisdom to avoid throwing up red flags.
- throw0101c 3y ago
  > Microsoft, security auditors, penetration testers, cyber insurance companies, etc. also largely insist on not having publicly addressable endpoints. > I don't understand why […] Excluding Microsoft, all the others find it easier to have as a checkbox to make it easier to confirm that "internal" hosts are actually (theoretically) internal since RFC 1918 isn't allowed outside. Of course most companies' firewall and NAT rules are probably all sorts of complicated once you get to a certain size (never mind stale open-rules which were never cleaned up), so a bunch stuff is probably accidentally exposed. Also, most attacks are probably from compromised clients nowadays, so even internal hosts need to be locked down as the castle-and-moat security model isn't (as) valid. But having "internal-only" hosts is low-hanging fruit on the security checklist.
- otabdeveloper4 3y ago
  > I don't understand why I will resist the urge to be snarky at your expense and politely point out that exposing your LAN to public routing tables is madness, from all perspectives. It brings no benefits and carries huge risks.
  - tremon 3y ago
    Is IPv6 Unique Local Addressing still a thing (or again)? Just because a machine has an IPv6 address does not mean it is automatically routable over the entire Internet.
  - fulafel 3y ago
    Using global addresses is not, of course, "exposing your LAN to public routing tables", or any charitable interpretation thereof. Reachability != addressing.
NovemberWhiskey 3y ago
>not internet style architectures with end-to-end addressing. The inside of my service is not the internet, even though my service may be exposed on the internet; why would I want internal implementation details externalized?
emodendroket 3y ago
I'm not seeing how security is harmed by making things inaccessible to the public Internet if you don't intend for services you do not control to ever access them directly.

beoberha 3y ago

I work in Azure, but my experience is that customers want this - and for good reason. Customers want their own private network to prevent intrusions and exfiltrations, just on machines they don’t own. Or even better, put the nice fancy batteries included PaaS services in these networks too.

jojobas 3y ago
Right, cause customers are too stupid to manage their own IPv6 firewalls, it's for their own good! /s
- rad_gruchalski 3y ago
  I’m pretty confident that this statement is mostly true without sarcasm, and that you are in the minority.
  - pantalaimon 3y ago
    How is managing a NAT easier than managing a firewall?
    - ninkendo 3y ago
      I’m one typo away from accidentally allowing IPv6 access to every machine in my network with my pf config on my home router. (I know this because I’ve done it one time, and didn’t notice for about a week.) There is no such typo i could make with my single shared public ipv4 address because it’s just one address. Saying “allow” by accident isn’t enough, I’d have to somehow accidentally configure the particular ingress port to NAT to a particular internal machine, and even then it would only affect that machine and no other. (Full disclosure, i actually like IPv6 and am in full favor of everything moving to it. This is in spite of the above, but i at least recognize that the above is the case.)
- thebytefairy 3y ago
  I work with Fortune 50s in cloud, and they can barely manage ipv4. If you're in a digital native it's different, but in my experience most behemoths do not inspire confidence with how on top of their network infrastructure they are.
  - amluto 3y ago
    This is a bit like saying “customers can barely manage driving a stick shift with a manual choke — we shouldn’t let them drive automatics!” IPv6 isn’t amazing, but it makes many of these problems simply disappear. Of course [0] networks should be isolated, but this should be achieved with a firewall that, by default, disallows connections between the public Internet and private networks. And that’s about it — every VM has a globally unique address, routing just works, one company (if permitted) can connect to another company’s endpoints, firewalls can be deployed where they make sense instead of being forced to exist exactly where inconsistently-addressed networks meet, etc. The entire mess of designing and negotiating allocation of extremely limited IPv4 addresses for private systems simply disappears! [0] Beyond corp has something to say about this.
- vasachi 3y ago
  Well, I wouldn't put _any_ service on a public network, unless it is explicitly required. Firewall is all well and good, but security in depth is even better. Private networking is good. IPv6 doesn't help here at all.
  - solatic 3y ago
    The easiest firewall in the world is one that is set up to deny all traffic from all sources. Which is how any decent firewall is configured by default anyway. I'm not saying that running a private network doesn't provide genuine security value, only that it drastically complicates your networking architecture for very little security benefit. Organizations can decide whether that trade-off is worth it, for organizations with deep threat models like militaries and banks, it's probably worth it. For 99% of the private sector, it's folly.
  - MayeulC 3y ago
    "Private networking" as defined by assigning private-range IP addresses are only private as long as there is no route to your network, or as long as it's isolated on a dedicated vlan (even then, there could be some rogue machines). In the first case, you need a firewall for IPv4 anyway. In the second case, that would also work with IPv6. Disclaimer: I know nothing about Azure/AWS internals.
  - Shorel 3y ago
    Therefore job security of old school network administrators is the main factor against IPv6 coverage. Hopefully one of the big cloud providers figures it is in their best interest to have a much bigger address space and make all this busywork sinecure obsolete.
    - vasachi 3y ago
      Good luck administering IPv6 networks, they are so much easier to understand.
  - fulafel 3y ago
    This phrasing is really problematic. Using internet addressing (vs ambiguous addresses) does not make your network "public". Just like using unique MAC addresses doesn't. Confusing global addressing with public reachabiliy is exactly the rhetoric used by AWS, Azure etc to scare people into building mazes of ambiguously addressed 10.x networks.
throw0101b 3y ago
> Customers want their own private network to prevent intrusions and exfiltrations, just on machines they don’t own. If your (default) gateway from one network segment to another network segment only has one rule, default-deny, then it's not a problem. If you think that's not enough, then use IPv6 ULA (fd00::/8). But why should the incompetence of some customers limit what all customers can do?
xnyanta 3y ago
I see this at work, being within such a customer. People driving these mandates barely understand IPv4, let alone know what IPv6 is. They're software developers after all, not CCIEs. There's nothing preventing you from having a private network using unique address space that's either blocked from accessing the internet via a firewall on a router or just plain not even routed. You could even use ULA networks with stateless prefix translation to avoid using GUA addressing for your private network. The sad part is that IPv6 support is abysmal on every cloud so just migrating to it imposes serious limitations as addressed by the blog author.

jiggawatts 3y ago

Azure is copying this wholesale. I've lost track of all of the "Private Endpoints", "Private Links", "Service Endpoints", "Private Resolvers" and "Virtual WAN" products they've introduced... all to make IPv4 work at scale. Literally none of those products would be required if they had just made IPv6 work properly. Instead, they NAT IPv6, so you can't even use it to avoid the NAT forced upon you by IPv4. They also release new products -- in 2023 -- that don't support IPv6 and likely never will. There is still an entire page[1] of listed limitations in the docs: https://learn.microsoft.com/en-us/azure/virtual-network/ip-services/ipv6-overview#limitations https://learn.microsoft.com/en-us/azure/virtual-network/ip-s... Think about how insane it would be if this was the IPX -> IPv4 transition. Imagine if this page said "IPv4 limitations: All VMs must include at least one IPX address, etc..." Sounds nuts, right? I was migrating customers to IPv4 from IPX in 1999, and IPv6 support materialised in about the 2001-2003 timeframe. It's been decades, but it still feels like 1999 and migrating Novell NetWare where we had to have IPX+IPv4 because "not everything supports IPv4 yet". [1] This is definitely not all of the limitations. Most of their PaaS products don't support IPv6. Hence, any IaaS+PaaS solutions must use (mostly) IPv4.

benterix 3y ago
Wait a second. A private link means that a service endpoint is public so a part of your traffic goes through the Internet, which is supposed to be insecure (even if you have encryption in transit?), so you don't want to do that and they will happily route your traffic internally so it is not exposed to the bad Internet - for a fee. All these VPC Endpoints etc. cost money and you are charged by the our. I don't think IPv6 would change anything here, they would find a way to charge customers for "security" anyway.
- jiggawatts 3y ago
  That's what I thought at first, but that's not quite right. Service Endpoint: Allows a PaaS service (that itself uses public addresses) have firewall rules for overlapping private vnet addresses. E.g.: You can have have two VMs both on 10.0.0.123 addresses (in separate VNets) using individual "Allow" rules to the target service. Essentially Azure tags the traffic at the VXLAN level with the source network ID on top of the IP address, making it a "fat IP address" that is unique within Azure and can be used in firewall rules. Private Endpoint: Makes a PaaS service appear on a private network address range instead of the default public range. This allows your on-prem firewalls to isolate your specific PaaS instance from other customers -- otherwise the traffic gets "blended in" with everyone else in the same public service tag ranges. This also allows you to use your ExpressRoute fibre links to route traffic from on-prem to the public service. In all scenarios, the traffic goes over Azure networks and/or Microsoft's private backbone. You have to go out of your way to route traffic "via the Internet". Remember: Network addresses are just numbers! Routing rules determine how they flow, and public addresses can be used on private networks. Fundamentally, all this exists just to enable the ability to firewall things. With overlapping IPv4 addresses and small shared blocks of IPv4 addresses with NAT behind them, it would be impossible otherwise. With IPv6, using firewalls would be much simpler because overlapping addresses aren't needed any more. Similarly, PaaS services could trivially allocate IPv6 addresses per customer instance, so that customers could apply selective firewall rules.

benterix 3y ago

I'm not convinced these 2 are related. If AWS wanted, they could start promoting IPv6 as a panacea to all internal network problems (if they had it working, that is), and the competition would have a hard time catching up. My guess is the reason is more mundane: supporting IPv4 is just easier, especially if you take into account the number of their services.

9dev 3y ago
While this is probably exactly the spin the AWS sales team head in mind, it conveniently glosses over all the IPv4 related products customers won’t need anymore if they use IPv6, and thus pay a lot less for their simplified network infrastructure. AWS has no incentive to support IPv6 from a sales perspective.
- supriyo-biswas 3y ago
  In addition, IPv4 addresses are an asset that has monetary value; and there’s no reason AWS would want to drive down the value of the asset by helping customers migrate to IPv6.
  - ttegloma 3y ago
    Sure there is. AWS has a vested interest in the value of IPv4 going down as much as possible. Owning IPv4 addresses is a requirement of AWS’s core business. Unless people stop using IPv4, then AWS cannot sell those addresses. There is no incentive for the addresses to increase in value. Further, if people continue to use IPv4, then AWS has to continue to acquire even more IPv4, and AWS wants the price of those to go down so that acquiring them is cheaper (or wants people to stop using IPv4 so that they can stop spending money on them altogether).
    - jen20 3y ago
      > Unless people stop using IPv4, then AWS cannot sell those addresses. There is no incentive for the addresses to increase in value. But if people stop using IPv4, the asset (billions of dollars by some accounts) becomes worthless... AWS are passing on the cost for public IPv4 addresses now, so there's even less incentive.

rewmie 3y ago

> These provide a strong lock-in effect when customers spend effort to build the complex infrastructure for them in the name of security, even though in reality they hurt security through unnecessary complexity, addressing ambiguity, etc. How do you hurt security by preventing external access to your internal services?

9dev 3y ago
By making it necessary to use automated tooling and even obtain certifications just to set up everything required for private networking. The complexity of a properly configured service mesh in AWS is staggering, extremely hard for newbies to get right, and easy to fuck up big time down the road. That hurts security.
- vasachi 3y ago
  Are hundreds of publicly addressable services better?
  - amluto 3y ago
    Yes, because publicly addressable does not mean publicly accessible. Set the ACLs to deny by default. In the v4 world, one can easily accidentally allow access by inadvertently sending traffic toward the wrong group of colliding addresses or otherwise messing up any of a number of things that ought not to be necessary in the first place.
    - otabdeveloper4 3y ago
      You need both firewalls and private addresses, of course. Anything else is amateur hour madness.
      - amluto 3y ago
        Why do I need private addresses? Okay, in real life I need private addresses because I connect to things that are only available over IPv4. So there’s some negotiation to make sure that my private network does not have an addressing conflict with the other network, there are NATs in the way, and traceroute gives output that is every bit as bad as you would expect. The ACLs that everyone (arguably quite reasonably) sets up suck are fiddly because the clients don’t have well defined address ranges. When people allocate /24 subsets out of IPv4 private space, the probability of collision is annoyingly high. Amateur hour indeed. I would take globally unique but “private” IPv6 addresses, over private links, with private routes (dynamic or static), and ACLs that actually make sense any day. Heck, I would happily go IPv6 only!

bushbaba 3y ago

Maybe just maybe. Customers don’t really want IPv6 but are forced onto it. Ipv6 is not human usable and gets rid of a bunch of network design norms.

supriyo-biswas 3y ago
This “human usable” argument gets trotted out so much on here and elsewhere, but the same people would be surprised to know about HTTP/2, TLS and the like, which by that definition, isn’t human usable either because of binary formats and encryption. People never interact with these protocols directly and use a layer of indirection such as a HTTP/2 client for HTTP, and the same applies for IPv6: use DNS (or your hosts file).
- butlerm 3y ago
  There are a number of relevant issues here, including the general problem that DNS is not trustable and is not reliable or not reliable enough to use for configuring routers and firewalls. It is not even necessarily accessible or usable for reverse lookup at all. DNS wasn't really designed for common cases where network administrators enter IP address prefixes. That could probably fixed to some degree using a name system that was designed for security use, including operation when the network is partitioned or wildly malfunctioning. And of course the need to maintain two sets of IP addresses and two sets of IP address prefixes - even and especially in DNS itself - is probably the number one factor slowing down the deployment of IPv6. That and far too many places, far too many interfaces, far too many protocols, and far too many APIs (notably Berkeley sockets) that are not transparent to which network layer protocol is being used or what the address format is. The wire format, transfer format, configuration format, and administration of DNS address records is a case in point.
  - supriyo-biswas 3y ago
    Adding another DNS record or changing a socket listener is hardly the issue though. Most sysadmins are unfamiliar with IPv6 networking concepts such as NDP, DHCPv6 and so on, and having to learn a new system is what hinders its adoption. Unfortunately, such changes are quite common in networking; Linux networking has many moving parts these days, there was the move to iproute2 and nftables, and the like, so one can only try to best keep up with the changes.

cameronh90 3y ago

It's not just AWS. Microsoft, security auditors, penetration testers, cyber insurance companies, etc. also largely insist on not having publicly addressable endpoints. I don't understand why, but until some large tech company starts pushing for end to end addressability as best practice, I have no choice but to follow the conventional wisdom to avoid throwing up red flags.

throw0101c 3y ago
> Microsoft, security auditors, penetration testers, cyber insurance companies, etc. also largely insist on not having publicly addressable endpoints. > I don't understand why […] Excluding Microsoft, all the others find it easier to have as a checkbox to make it easier to confirm that "internal" hosts are actually (theoretically) internal since RFC 1918 isn't allowed outside. Of course most companies' firewall and NAT rules are probably all sorts of complicated once you get to a certain size (never mind stale open-rules which were never cleaned up), so a bunch stuff is probably accidentally exposed. Also, most attacks are probably from compromised clients nowadays, so even internal hosts need to be locked down as the castle-and-moat security model isn't (as) valid. But having "internal-only" hosts is low-hanging fruit on the security checklist.
otabdeveloper4 3y ago
> I don't understand why I will resist the urge to be snarky at your expense and politely point out that exposing your LAN to public routing tables is madness, from all perspectives. It brings no benefits and carries huge risks.
- tremon 3y ago
  Is IPv6 Unique Local Addressing still a thing (or again)? Just because a machine has an IPv6 address does not mean it is automatically routable over the entire Internet.
- fulafel 3y ago
  Using global addresses is not, of course, "exposing your LAN to public routing tables", or any charitable interpretation thereof. Reachability != addressing.

NovemberWhiskey 3y ago

>not internet style architectures with end-to-end addressing. The inside of my service is not the internet, even though my service may be exposed on the internet; why would I want internal implementation details externalized?

emodendroket 3y ago

I'm not seeing how security is harmed by making things inaccessible to the public Internet if you don't intend for services you do not control to ever access them directly.