4 ms·

Isn't that completely crazy? IPv6 has been ready for production use for ... about ten years? And yet, people still build (and ostensibly are willing to buy) pro

Isn't that completely crazy? IPv6 has been ready for production use for ... about ten years? And yet, people still build (and ostensibly are willing to buy) products that only exist in order to work around the shortcomings of IPv4?

jo909 11y ago
Of course you are right. But if you want to build a comparable architecture with IPv6, where a private Network is fully isolated from the public Internet except for a very controlled gateway, you would still need a Firewall/Router capable of handling all the traffic. Isolated (to a certain degree), private networks will not go away with IPv6, as they are a convenient security mechanism. So the name for the box will change, but not it's fundamental duty of allowing controlled traversal over network boundaries.
- NetStrikeForce 11y ago
  And you are right, too. But isolation doesn't mean translation. It is crazy that we have to use translation to overcome problems with IP space scarcity, but I guess we all got used already.
  - themartorana 11y ago
    I don't know. I LIKE NAT. It's easy for me to reason about, easy to read and understand. I know it has a litany of shortcomings, and I'm not in a huge corporate network, but I'm going to miss it when it's gone.
    - EvanAnderson 11y ago
      You would like stateful packet filtering w/o NAT even more, I suspect. You've probably never gotten a chance to work in an environment where that's possible. It's nice to have one layer of complexity (NAT) removed from the equation and to work with only packet filters. (It's nice not to have to worry about split-horizon DNS, for example.)
    - zAy0LfpBZLC8mAC 11y ago
      Why would you miss it when it's gone? I pretty much wish it had never been invented, so I'd be curious if there is any big advantage that I am missing ...
    - iigs 11y ago
      I also strongly like NAT. In roughly descending order: 1) It fails safe. Virtually all device misconfigurations result in failure to pass traffic, rather than being passed accidentally. 2) You get full control of your external signature (at that protocol level). When Comcast and AT&T realize that they can charge for more than a single /128 on their consumer networks we'll see a lot of wailing and gnashing of teeth on /r/technology, and it will be completely inane to those of us that saw the same companies attempt the same BS with NAT detection in the late 90s. 3) I would like to be able to implement dual stack in networks that I'm responsible for with as much similarity as possible. Having to reason independently more than needed about how IPv4 and IPv6 behave is needless difficulty. 4) IPv6 allocations today are asininely large. We're going to have 30-45 years of overallocation and then be out again, and in the interim we'll have a whole host of new braindead protocols in the manner of FTP and VOIP. The collective lessons we've learned about NAT will have (for all intents and purposes) been lost and we'll get a bunch of new shoddy hacks for dealing with them (passive FTP and NAT-T). 5) If it's a useful tool, by the user's estimation, why can't I have it? The internet grew up on what amounted to "be a good peer and we can all get along", but on this specific topic it quickly dissolves into STOP LIKING THINGS I DONT LIKE, YOU CAN'T HAVE IT, I'M TELLING THE IETF.
      - zAy0LfpBZLC8mAC 11y ago
        > 1) It fails safe. Virtually all device misconfigurations result in failure to pass traffic, rather than being passed accidentally. I don't see that, nor that it would even be an advantage. > 2) You get full control of your external signature (at that protocol level). When Comcast and AT&T realize that they can charge for more than a single /128 on their consumer networks we'll see a lot of wailing and gnashing of teeth on /r/technology, and it will be completely inane to those of us that saw the same companies attempt the same BS with NAT detection in the late 90s. How do you prevent people from coming up with stupid ideas by implementing some stupid ideas yourself? Is that a general rule you follow? Wherever companies could conceivably some day screw up some product, you do it for them now? > 3) I would like to be able to implement dual stack in networks that I'm responsible for with as much similarity as possible. Having to reason independently more than needed about how IPv4 and IPv6 behave is needless difficulty. So, you prefer to keep things broken forever if that means that things don't change? > 4) IPv6 allocations today are asininely large. We're going to have 30-45 years of overallocation and then be out again, What's your evidence for that? Seems like a completely baseless claim to me. > and in the interim we'll have a whole host of new braindead protocols in the manner of FTP and VOIP. So, NAT is good because protocols that don't work well with NAT are braindead because they don't work well with NAT? I mean, I see your point if there is any risk that we might run out of addresses, but if we don't, what exactly is braindead about those protocols? > 5) If it's a useful tool, by the user's estimation, why can't I have it? You obviously _can_ have it. Just as you _can_ cut your head off if you think that's useful to you. But all things considered, do the advantages actually outweigh the disadvantages.
    - NetStrikeForce 11y ago
      I like NAT, too; but just because I like solving the problems it creates. It gets especially funny when you're overloading the public IP address with a one-to-many ratio with internal IP address for outgoing traffic and then you add PAT for incoming traffic. It gets even better when you're only using one IP address for that one-to-many NAT (and it usually is the firewall's external interface IP address because, well, we're lazy), all your internal users are requesting the same external and you run out of ephemeral ports without even realizing. I also like when someone architected an application where the server running it has to request different resources from different external sites and, for some weird reason, has to present itself with different IP addresses. Oh the joy. So many NATs and so many scenarios. It is lovely how different vendors come up with all sorts of names and acronyms: NAT, PAT, SNAT, DNAT, DIP, MIP, you name it! If we didn't have NAT we would have to invent it :)
- zAy0LfpBZLC8mAC 11y ago
  > But if you want to build a comparable architecture with IPv6, where a private Network is fully isolated from the public Internet except for a very controlled gateway, you would still need a Firewall/Router capable of handling all the traffic. Nope, you wouldn't. You might still want to think abstractly in terms of a network boundary, but you absolutely do not necessarily need one point where it's all implemented. Depending on the architecture and your needs, you could also, for example, have an instance of the same packet filter on each machine. I am not saying that there is no place for that kind of architecture, but the current state of affairs with IPv4 severely limits the options as to how to implement what you actually need. In a way, even the concept of "a private network" is a bad idea. Sure, you may want to limit access to some services for some clients and such--but really, the mere distinction of "inside" vs "outside" causes many problems in today's network operations. What if you interconnect you "internal network" with some other "internal network" because someone "external" to you needs to access some service that's "internal" to you? That becomes pretty hairy pretty fast, with NAT in particular--when it's actually pretty easy conceptually when you have a globally unique address space.
  - jo909 11y ago
    That is not the same level of isolation. What you describe is of course possible and exactly how non vpc ec2 works, but nobody recommends that for serious setups. Im not saying that nat is good, but isolation is.
    - zAy0LfpBZLC8mAC 11y ago
      I guess I wasn't necessarily talking just about EC2, but network setups in general, where more distributed firewalls might often be a good choice, were it not for the problems that NAT brings. Actually having a packet filter per machine would be an extreme case, obviously, but the same problem occurs when you have multiple gateways to different networks, or maybe you are multihomed, or you have multiple locations with their own internet uplinks ... having to maintain NAT state and generally ensuring reachability despite the NAT tends to get complicated fast if you have multiple independent filters/NAT gateways, while that's reasonably easy to maintain without NAT.
jusssi 11y ago
https://www.google.com/intl/en/ipv6/statistics.html https://www.google.com/intl/en/ipv6/statistics.html As long as significant part of the net is only reachable by IPv4, most businesses can't walk away from it. Not to mention, AWS still doesn't have IPv6 support (except for ELB).
- clinta 11y ago
  That's the point. It's crazy that instead of getting IPv6 working in AWS, Amazon chose to build a NAT gateway service instead. The forward thinking way to deal with IPv4 shortages would be for Amazon to support IPv6 end to end, and offer IPv4 connectivity via ELB or a NAT64 Gateway so that the non-IPv6 internet can reach your servers.
  - devonkim 11y ago
    A relative few of the biggest elephant customers of theirs are deploying IPv6 or even have it on a roadmap. There is a gigantic amount of money that can't be ignored by catering to these lumbering giants of Faustian bureaucracy that will be multiple decades behind current technologies and continue to fall even further behind despite any "cloud transformations" that they spend a small country's GDP on. This is a potentially dangerous path for AWS as they need engineers to work on both up to date technology and other engineers on outdated, obsolete legacy technologies that few engineers would prefer to work on. The good news about outdated technology should be that every competent engineer should understand something about why it's obsolete in some respect, but the truth is that few engineers on even HN understand the shortcomings of, say, COBOL and Fortran 77 over Java 7 and C# 5.0.
  - bbayles 11y ago
    I don't think it's that crazy. Switching to IPv6 is painful. It's a fine standard, and better than IPv4 in most every way, ignoring transaction costs. But IPv4 + NAT persists because it's a smoother path - the same reason why HTML 5 won out against XHTML 2.0.
devonkim 11y ago
A lot of the need for this design is for backwards compatibility with existing corporate network designs that will likely be on IPv4 for perhaps another decade or two longer. Most corporate networks despise changes and seek to gain stability of their environment through minimizing changes. My current contract customer absolutely wants this and requires it, in fact, for compliance with internal security policies (nevermind the litany of security issues using IPv4 in the first place). The limitations of this solution include the fact that we're unable to get much control of these instances because we use third party software galore on these type of NAT instances like IDS, firewalling, caching / proxying, and traffic shaping. So unfortunately, all this new service does for us is let us separate out one of like 12 functions to a (granted, high availability) service and in the interest of saving money on not creating 25+ instances for these 12 services it's not unheard of to collapse these into 3-4 load balanced / distributed much larger instances for the sake of easier manageability. But for a lot of folks, I can imagine this is a great service that meets their needs sufficiently well.
tobz 11y ago
Most of the usefulness of this service is that you need a NAT gateway if you want instances to be created with private IPs only but also be able to access the internet. The IPv4 point isn't wrong but it misses the mark, I think. You could put them in super restrictive security groups, sure, but some people just want to say "these don't have a public IP, so it checks off this box" and those people are going to be super happy with this. There's also the comments about checking off other boxes like central points for IDS, etc.
- zAy0LfpBZLC8mAC 11y ago
  > [...] but some people just want to say "these don't have a public IP, so it checks off this box" and those people are going to be super happy with this. Which basically would mean that they are incompetent. A private IP address doesn't really do anything for you security-wise. An IP address being private is simply a convention adhered to by people assigning addresses--that does not in any way guarantee that one cannot send packets to those addresses from outside your network or forward packets from those addresses out of your network, so it doesn't obviate the need for you to filter at the borders of your network, and if you do filter, you might as well filter "public addresses". The only difference between private and public addresses is that private addresses are potentially assigned to more than one network/machine, which makes it difficult to make those networks/machines communicate with one another in case you ever need to, and to make the world communicate with them because the world in general can't distinguish between the multiple instances of the same address, and thus usually doesn't really know who to talk to.
  - kesor 11y ago
    For a network with several hundred instances where each instance has a public IP, the borders of your network become quite wide. You now need to audit several dozen security groups. When you setup a private subnet, there are a lot less security groups, and access points in general, which makes it much easier to audit and maintain reasonable security for. This is especially true where unprofessional people start and stop instances (say developers) and don't have the same security mind-set, making it a risk of human-error that causes services which normally should be protected to be open to the world.

jo909 11y ago

Of course you are right. But if you want to build a comparable architecture with IPv6, where a private Network is fully isolated from the public Internet except for a very controlled gateway, you would still need a Firewall/Router capable of handling all the traffic. Isolated (to a certain degree), private networks will not go away with IPv6, as they are a convenient security mechanism. So the name for the box will change, but not it's fundamental duty of allowing controlled traversal over network boundaries.

NetStrikeForce 11y ago
And you are right, too. But isolation doesn't mean translation. It is crazy that we have to use translation to overcome problems with IP space scarcity, but I guess we all got used already.
- themartorana 11y ago
  I don't know. I LIKE NAT. It's easy for me to reason about, easy to read and understand. I know it has a litany of shortcomings, and I'm not in a huge corporate network, but I'm going to miss it when it's gone.
  - EvanAnderson 11y ago
    You would like stateful packet filtering w/o NAT even more, I suspect. You've probably never gotten a chance to work in an environment where that's possible. It's nice to have one layer of complexity (NAT) removed from the equation and to work with only packet filters. (It's nice not to have to worry about split-horizon DNS, for example.)
  - zAy0LfpBZLC8mAC 11y ago
    Why would you miss it when it's gone? I pretty much wish it had never been invented, so I'd be curious if there is any big advantage that I am missing ...
  - iigs 11y ago
    I also strongly like NAT. In roughly descending order: 1) It fails safe. Virtually all device misconfigurations result in failure to pass traffic, rather than being passed accidentally. 2) You get full control of your external signature (at that protocol level). When Comcast and AT&T realize that they can charge for more than a single /128 on their consumer networks we'll see a lot of wailing and gnashing of teeth on /r/technology, and it will be completely inane to those of us that saw the same companies attempt the same BS with NAT detection in the late 90s. 3) I would like to be able to implement dual stack in networks that I'm responsible for with as much similarity as possible. Having to reason independently more than needed about how IPv4 and IPv6 behave is needless difficulty. 4) IPv6 allocations today are asininely large. We're going to have 30-45 years of overallocation and then be out again, and in the interim we'll have a whole host of new braindead protocols in the manner of FTP and VOIP. The collective lessons we've learned about NAT will have (for all intents and purposes) been lost and we'll get a bunch of new shoddy hacks for dealing with them (passive FTP and NAT-T). 5) If it's a useful tool, by the user's estimation, why can't I have it? The internet grew up on what amounted to "be a good peer and we can all get along", but on this specific topic it quickly dissolves into STOP LIKING THINGS I DONT LIKE, YOU CAN'T HAVE IT, I'M TELLING THE IETF.
    - zAy0LfpBZLC8mAC 11y ago
      > 1) It fails safe. Virtually all device misconfigurations result in failure to pass traffic, rather than being passed accidentally. I don't see that, nor that it would even be an advantage. > 2) You get full control of your external signature (at that protocol level). When Comcast and AT&T realize that they can charge for more than a single /128 on their consumer networks we'll see a lot of wailing and gnashing of teeth on /r/technology, and it will be completely inane to those of us that saw the same companies attempt the same BS with NAT detection in the late 90s. How do you prevent people from coming up with stupid ideas by implementing some stupid ideas yourself? Is that a general rule you follow? Wherever companies could conceivably some day screw up some product, you do it for them now? > 3) I would like to be able to implement dual stack in networks that I'm responsible for with as much similarity as possible. Having to reason independently more than needed about how IPv4 and IPv6 behave is needless difficulty. So, you prefer to keep things broken forever if that means that things don't change? > 4) IPv6 allocations today are asininely large. We're going to have 30-45 years of overallocation and then be out again, What's your evidence for that? Seems like a completely baseless claim to me. > and in the interim we'll have a whole host of new braindead protocols in the manner of FTP and VOIP. So, NAT is good because protocols that don't work well with NAT are braindead because they don't work well with NAT? I mean, I see your point if there is any risk that we might run out of addresses, but if we don't, what exactly is braindead about those protocols? > 5) If it's a useful tool, by the user's estimation, why can't I have it? You obviously _can_ have it. Just as you _can_ cut your head off if you think that's useful to you. But all things considered, do the advantages actually outweigh the disadvantages.
  - NetStrikeForce 11y ago
    I like NAT, too; but just because I like solving the problems it creates. It gets especially funny when you're overloading the public IP address with a one-to-many ratio with internal IP address for outgoing traffic and then you add PAT for incoming traffic. It gets even better when you're only using one IP address for that one-to-many NAT (and it usually is the firewall's external interface IP address because, well, we're lazy), all your internal users are requesting the same external and you run out of ephemeral ports without even realizing. I also like when someone architected an application where the server running it has to request different resources from different external sites and, for some weird reason, has to present itself with different IP addresses. Oh the joy. So many NATs and so many scenarios. It is lovely how different vendors come up with all sorts of names and acronyms: NAT, PAT, SNAT, DNAT, DIP, MIP, you name it! If we didn't have NAT we would have to invent it :)
zAy0LfpBZLC8mAC 11y ago
> But if you want to build a comparable architecture with IPv6, where a private Network is fully isolated from the public Internet except for a very controlled gateway, you would still need a Firewall/Router capable of handling all the traffic. Nope, you wouldn't. You might still want to think abstractly in terms of a network boundary, but you absolutely do not necessarily need one point where it's all implemented. Depending on the architecture and your needs, you could also, for example, have an instance of the same packet filter on each machine. I am not saying that there is no place for that kind of architecture, but the current state of affairs with IPv4 severely limits the options as to how to implement what you actually need. In a way, even the concept of "a private network" is a bad idea. Sure, you may want to limit access to some services for some clients and such--but really, the mere distinction of "inside" vs "outside" causes many problems in today's network operations. What if you interconnect you "internal network" with some other "internal network" because someone "external" to you needs to access some service that's "internal" to you? That becomes pretty hairy pretty fast, with NAT in particular--when it's actually pretty easy conceptually when you have a globally unique address space.
- jo909 11y ago
  That is not the same level of isolation. What you describe is of course possible and exactly how non vpc ec2 works, but nobody recommends that for serious setups. Im not saying that nat is good, but isolation is.
  - zAy0LfpBZLC8mAC 11y ago
    I guess I wasn't necessarily talking just about EC2, but network setups in general, where more distributed firewalls might often be a good choice, were it not for the problems that NAT brings. Actually having a packet filter per machine would be an extreme case, obviously, but the same problem occurs when you have multiple gateways to different networks, or maybe you are multihomed, or you have multiple locations with their own internet uplinks ... having to maintain NAT state and generally ensuring reachability despite the NAT tends to get complicated fast if you have multiple independent filters/NAT gateways, while that's reasonably easy to maintain without NAT.

jusssi 11y ago

https://www.google.com/intl/en/ipv6/statistics.html https://www.google.com/intl/en/ipv6/statistics.html As long as significant part of the net is only reachable by IPv4, most businesses can't walk away from it. Not to mention, AWS still doesn't have IPv6 support (except for ELB).

clinta 11y ago
That's the point. It's crazy that instead of getting IPv6 working in AWS, Amazon chose to build a NAT gateway service instead. The forward thinking way to deal with IPv4 shortages would be for Amazon to support IPv6 end to end, and offer IPv4 connectivity via ELB or a NAT64 Gateway so that the non-IPv6 internet can reach your servers.
- devonkim 11y ago
  A relative few of the biggest elephant customers of theirs are deploying IPv6 or even have it on a roadmap. There is a gigantic amount of money that can't be ignored by catering to these lumbering giants of Faustian bureaucracy that will be multiple decades behind current technologies and continue to fall even further behind despite any "cloud transformations" that they spend a small country's GDP on. This is a potentially dangerous path for AWS as they need engineers to work on both up to date technology and other engineers on outdated, obsolete legacy technologies that few engineers would prefer to work on. The good news about outdated technology should be that every competent engineer should understand something about why it's obsolete in some respect, but the truth is that few engineers on even HN understand the shortcomings of, say, COBOL and Fortran 77 over Java 7 and C# 5.0.
- bbayles 11y ago
  I don't think it's that crazy. Switching to IPv6 is painful. It's a fine standard, and better than IPv4 in most every way, ignoring transaction costs. But IPv4 + NAT persists because it's a smoother path - the same reason why HTML 5 won out against XHTML 2.0.

devonkim 11y ago

A lot of the need for this design is for backwards compatibility with existing corporate network designs that will likely be on IPv4 for perhaps another decade or two longer. Most corporate networks despise changes and seek to gain stability of their environment through minimizing changes. My current contract customer absolutely wants this and requires it, in fact, for compliance with internal security policies (nevermind the litany of security issues using IPv4 in the first place). The limitations of this solution include the fact that we're unable to get much control of these instances because we use third party software galore on these type of NAT instances like IDS, firewalling, caching / proxying, and traffic shaping. So unfortunately, all this new service does for us is let us separate out one of like 12 functions to a (granted, high availability) service and in the interest of saving money on not creating 25+ instances for these 12 services it's not unheard of to collapse these into 3-4 load balanced / distributed much larger instances for the sake of easier manageability. But for a lot of folks, I can imagine this is a great service that meets their needs sufficiently well.

tobz 11y ago

Most of the usefulness of this service is that you need a NAT gateway if you want instances to be created with private IPs only but also be able to access the internet. The IPv4 point isn't wrong but it misses the mark, I think. You could put them in super restrictive security groups, sure, but some people just want to say "these don't have a public IP, so it checks off this box" and those people are going to be super happy with this. There's also the comments about checking off other boxes like central points for IDS, etc.

zAy0LfpBZLC8mAC 11y ago
> [...] but some people just want to say "these don't have a public IP, so it checks off this box" and those people are going to be super happy with this. Which basically would mean that they are incompetent. A private IP address doesn't really do anything for you security-wise. An IP address being private is simply a convention adhered to by people assigning addresses--that does not in any way guarantee that one cannot send packets to those addresses from outside your network or forward packets from those addresses out of your network, so it doesn't obviate the need for you to filter at the borders of your network, and if you do filter, you might as well filter "public addresses". The only difference between private and public addresses is that private addresses are potentially assigned to more than one network/machine, which makes it difficult to make those networks/machines communicate with one another in case you ever need to, and to make the world communicate with them because the world in general can't distinguish between the multiple instances of the same address, and thus usually doesn't really know who to talk to.
- kesor 11y ago
  For a network with several hundred instances where each instance has a public IP, the borders of your network become quite wide. You now need to audit several dozen security groups. When you setup a private subnet, there are a lot less security groups, and access points in general, which makes it much easier to audit and maintain reasonable security for. This is especially true where unprofessional people start and stop instances (say developers) and don't have the same security mind-set, making it a risk of human-error that causes services which normally should be protected to be open to the world.