But when an "we are going to change the future of the internet"-project makes IPv6 a Prio-2 feature (to be added later, not native from the start) it just shows that we are really not there yet.
I have IPv6 at home now but still don't have it at our tech-oriented co-working space, and I've never seen an IPv6 address get handed out at a coffee shop, airport, restaurant, etc.
My ISP doesn't support IPv6, but I've just checked and a Windows 10 machine was able to do `curl -6 https://ipv6.google.com/` just fine.
And I think I've heard OS X has something as well... not sure, don't have OS X or iOS devices at hand to try it out.
(On GNU/Linux and BSD machines there's a lot of choices, Miredo, 6to4, AICCU from SixXS - whatever one fancies. As usual on *nix systems, setup is manual, though.)
That's like focusing on supporting Internet Explorer 8. At some point IPv4 will become the legacy protocol and supporting it will be annoying and expensive.
That day maybe not be today, but switching protocols is not always trivial, and you should start yesterday.
AWS's services are great but many people just need compute. I don't understand why people who just need compute use AWS, since for compute only Digital Ocean and Vultr destroy it in virtually every way: ease of use, performance, cost, IPv6, etc.
Digital Ocean now has block storage too, which plugs one hole. Of course they don't have things like RedShift or S3, but like I said not everyone needs that.
Still took nearly a decade before the first internal servers began supporting IPv6 but what a cheer went up when that first IPv6-only e-mail arrived.
The amazing thing was that most network kit supported IPv6 out of the box, thanks to mainly to Government purchasing requirements that had hammered the big vendors into submission.
How would an IPv4 client, with this hypothetical backwards-compatible IPv6, connect to an IPv6 server?
It is nice to see 0 random port scans and SSH brute-force attacks. IPv6 space is so big it helps give some security through obscurity.
(may not apply to every allocation strategy)
They probably have other features in mind that haven't been released yet, does that mean that whatever those features are obviously are not important on the internet?
;; ANSWER SECTION: www.sbb.ch. 14400 IN AAAA 2a00:4bc0:ffff:ffff::c296:f58eThere are a million reasons NATs are terrible for the internet. But they're used on IPv4, and IPv6's technical goal of increasing the address space is tied up into the technical goal of killing NAT, immediately, and changing the way a lot of people think about networking. For instance, end-user ISPs are expected to give you a /64 or more instead of a single IPv6 address so that you don't need to NAT, but many of them don't, because that's not how people think about addressing. If you have a NAT-using site and you want to switch to IPv6, you have to pursue the political goal of convincing your ISP to think differently about addressing.
Meanwhile, IPv4 and IPv4 NAT works. I'm typing this from behind a NAT, you're probably reading it from behind a NAT. It's not ideal, but, rough consensus and running code.
As soon as we all put our collective feet down and insist on IPv6 NAT implementations, such that IPv4 sites can move without rearchitecting their environment (whether or not that rearchitecting would be a good thing), IPv6 will get deployed quickly.
Name one? I've been on Comcast and Sonic, and both natively provide /64 networks. I've never heard of an ISP providing a /128.
> Meanwhile, IPv4 and IPv4 NAT works.
No, it doesn't. It breaks a million things more than it solves and it makes the Internet worse (and vastly more asymmetric, but that's repeating myself). NAT needs to die in a fire, and there is zero political or technical motivation to inflict its brokenness on a new protocol that absolutely does not need it. Evidence: that many ISPs are providing native, un-NATed IPv6 to their customers. Perhaps some don't, but someone will manage to screw up any given feature. They need to fix their shit, not coerce the rest of the Internet to break itself for their convenience.
I see it largely as an attempt to do market segmentation and limit the usefulness of Kimsufi to push people towards their other brands. Unfortunate, but...
It really is unfortunate. Not having to use a proxy for the sole purpose of sharing the 80 port would be nice...
and they're not needed on IPv6, just the same as we don't require cars to have horseshoes, even though horses needed them before.
Anyway, I'm on HN right now over NAT because HN doesn't have a IPv6 endpoint, otherwise I would be here over IPv6. THAT is what is holding IPv6 back, there aren't the services on IPv6 so there is no user demand for it.
But that may not represent the full story for them. Internal moderation and anti-spam may need updating to be compatible with running on two different networks that each have different approaches to numbering.
Even companies that 'get' v6 sometimes have rough edges. E.g. Cloudflare - which has been a great supporter of v6 for a long time now - has been known to send 'log in from a new IP address!' notifications because my machine automatically rotated it's IPv6 privacy suffix.
Either you get that message or the IPv6 privacy mechanism is not working well enough.
On a deeper level this is because almost nobody actually understands how networks work. In my experience even really top developers often have absolutely no idea what happens on the wire. As a result they basically cargo cult netsec. Since they don't understand it, anything that deviates from "standard practice" gives them security FUD willies because they don't see the implications.
It's a barrier to deploying IPv6, yes, but I'm arguing that that's an entirely artificial barrier. You shouldn't need to understand why IPv6 folks dislike NAT in order to write software that uses the network.
There was a time when perimeter security was seen as an adequate and acceptable technique.
Of course, at this point you've broken end-to-end connectivity (P2P apps don't work, active-mode FTP doesn't work, etc.) so this may not actually resolve the reason people wanted to get rid of NAT. Maybe a good portion of the the no-NAT-in-IPv6 crowd wants inbound routes to people's homes so apps work, and the "but you don't need NAT for security" crowd is misunderstanding them
Here are two important behaviours which come with "just like a NAT would".
1) UPNP - a protocol which allows an application to request it be exposed to the internet
2) Hole punching. E.g. two hosts send packets with matching ip/port values to cause a direct connection to be established between them
Applications don't really do those things on v6...
And, FWIW, ISPs should be giving residential users at least a /56 - if not a /48. Sites should be able to have enough address space to route within the site and still use the features of IPv6 which require a /64. Route aggregation and routing table size is the constraint of the v6 world, not address space.
V6 should make all this cruft go away but it doesn't.
If it's not safe to expose a service to the internet, it's also not safe to have it exposed within your LAN without access controls.
NAT-based 'firewalls' can have holes in punched in them in a variety of ways - they are specifically designed to allow holes to be punched, because it's necessary for many applications to work.
It's also possible to take advantage of a user's browser as a relay. Combine that with the ability to use ad networks to target HTML to be served to the IP of an attacker's choosing, and the illusion that a perimeter firewall will prevent an attacker from initiating connections to your network starts to shatter.
I agree that in practice, in many cases today the stateful firewall-like functionality provided by a NAT device will provide a net security improvement. But that's not a situation we should continue to allow.
It's unrealistic to expect users to manually create firewall holes. That's why default configurations tend to include UPNP (which, naturally, introduce a new set of security and DoS concerns) - which will automatically open holes in the 'firewall'.
Google has published some of their thinking on this topic under the 'beyondcorp' moniker. The summary is there is no "safe" and "unsafe" - you need to do a risk evaluation of each attempt to access a service, and "this is coming from inside our network" in inadequate.
I'd love if we could trust most devices to be publicly exposed, but IMHO we can not. If router manufacturers could be trusted one could add all kinds of clever things there, but ...
This is not true. Most real world attacks I've seen begin by infiltrating malware via the web, e-mail, social media, or phishing. Once inside existing connections between existing internal systems are exploited to crawl around the network.
Remote attacks against non-DMZ things are fairly rare in practice.
The only way to stop this is to implement even more firewalling inside the network, which basically breaks LAN.
I very much agree with the parent and have been talking about Google's beyondcorp and deperimeterization for years. A device that can't be safely connected to a network is broken, and we should stop degrading our networks to support broken junk. If broken junk gets hacked, it is the fault of the makers of that broken junk.
It is not hopeless. I've been into this stuff since the mid-1990s and things have improved a lot since then. I would not be too afraid to hook up a Mac or a fully patched Windows 10 machine to the public Internet. In the 90s or early 2000s I would not even consider this. You'd get owned by a bot within an hour. I remember in 2000 hooking a virgin Windows machine up to a campus network and being able to watch it get infected within 5 minutes.
The trends for the future are positive. Safer languages like Go, Rust, Swift, etc. are getting more popular everywhere. Advances in OS security like W^X, ASLR, etc. are getting ubiquitous. Local app sandboxing and containerization is a thing almost everywhere. Devices security postures are improving.
For most purposes, ND proxy is the new NAT.
I do think those uses will tend to involve 1-to-1 prefix translation rather than many-to-1 mapping.