3 ms·

The disaster is that app developers can't rely on their users being on the internet in the sense of end-to-end addressability in developing new applications. Th

by zurn 11y ago

The disaster is that app developers can't rely on their users being on the internet in the sense of end-to-end addressability in developing new applications. This has major chilling effects on less centralised types of applications, and tilts the tables toward big content providers and "enterprise" users with "intranets" behind centralized firewalls. IPv6 deployment is massively late, users have already been conditioned into accepting NAT as internet access, even going so far as NAT boxes being called "routers"- even though NAT flatly contradicts the RFC definition of IP router, which are forbidden from doing port/address NAT along with other arbitrary traffic interference.

ghshephard 11y ago
It's been the case for at least 15 years that app developers couldn't rely on their users being on the internet. It's annoying, and I agree with you has a chilling effect on less-centralized applications, but doesn't rise to the level of "Disaster." One thing that people need to be precise about, particularly as IPv6 comes online, is the difference between NAT and PAT. I realize that 90%+ of the HN community understand the difference, (NAT changes your Address only, PAT changes your address to a single outbound address, and multiplexes a PORT) but with IPv6 it has a very real significance. Deployment of PAT in IPv6 is really quite frowned upon, but there a number of very real administrative reason why Network Prefix Translation (NPT, https://tools.ietf.org/html/rfc6296 https://tools.ietf.org/html/rfc6296 ) - which is really just stateless NAT, makes sense. With NPT, you convert the first 64 bits (the "Network"), but leave the last 64 bits (the "Interface") untouched. This gives the inside of your network really good ISP mobility - allowing you to switch to a new ISP at the drop of a hat, without having to worry about any internal renumbering, updating thousands of DNS records, etc... The only DNS records you would need to worry about would be for external connectivity (which is typically orders of magnitude less than internal hosts, and also typically more well documented. I expect that most forward looking enterprises deploying IPv6 will use some combination of RFC 4193 (Unique Local IPV6 Unicast, https://tools.ietf.org/html/rfc4193 https://tools.ietf.org/html/rfc4193, the IPv6 variant of RFC 1918) + RFC 6296 Network Prefix Translation.
- loup-vaillant 11y ago
  > It's been the case for at least 15 years that app developers couldn't rely on their users being on the internet. It's annoying, and I agree with you has a chilling effect on less-centralized applications, but doesn't rise to the level of "Disaster." My point is, it does. It is not an "end of the wolrd" disaster, but it is an Orwellian one. We're only beginning to realise the insanity behind centralised services such as Gmail. I personally suspected those dangers for a long time, (as did the FSF, the EFF, and many others). Edward Snowden only confirmed some of our worst fears. That said, the lack of public IP is only half of the catastrophe. The other half is asymmetric bandwidth.

by zurn 11y ago

ghshephard 11y ago

It's been the case for at least 15 years that app developers couldn't rely on their users being on the internet. It's annoying, and I agree with you has a chilling effect on less-centralized applications, but doesn't rise to the level of "Disaster." One thing that people need to be precise about, particularly as IPv6 comes online, is the difference between NAT and PAT. I realize that 90%+ of the HN community understand the difference, (NAT changes your Address only, PAT changes your address to a single outbound address, and multiplexes a PORT) but with IPv6 it has a very real significance. Deployment of PAT in IPv6 is really quite frowned upon, but there a number of very real administrative reason why Network Prefix Translation (NPT, https://tools.ietf.org/html/rfc6296 https://tools.ietf.org/html/rfc6296 ) - which is really just stateless NAT, makes sense. With NPT, you convert the first 64 bits (the "Network"), but leave the last 64 bits (the "Interface") untouched. This gives the inside of your network really good ISP mobility - allowing you to switch to a new ISP at the drop of a hat, without having to worry about any internal renumbering, updating thousands of DNS records, etc... The only DNS records you would need to worry about would be for external connectivity (which is typically orders of magnitude less than internal hosts, and also typically more well documented. I expect that most forward looking enterprises deploying IPv6 will use some combination of RFC 4193 (Unique Local IPV6 Unicast, https://tools.ietf.org/html/rfc4193 https://tools.ietf.org/html/rfc4193, the IPv6 variant of RFC 1918) + RFC 6296 Network Prefix Translation.

loup-vaillant 11y ago
> It's been the case for at least 15 years that app developers couldn't rely on their users being on the internet. It's annoying, and I agree with you has a chilling effect on less-centralized applications, but doesn't rise to the level of "Disaster." My point is, it does. It is not an "end of the wolrd" disaster, but it is an Orwellian one. We're only beginning to realise the insanity behind centralised services such as Gmail. I personally suspected those dangers for a long time, (as did the FSF, the EFF, and many others). Edward Snowden only confirmed some of our worst fears. That said, the lack of public IP is only half of the catastrophe. The other half is asymmetric bandwidth.