Hacker News new | past | comments | ask | show | jobs | submit login

This is in no way criticism against LE, where I work _nothing_ is IPv6 and we do not even have it on any agenda.

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.




AWS still has no native IPv6 support. It's sad really. It's pointless for a project like LE to make IPv6 a first-priority feature when massive providers running the backbone of the internet don't support IPv6 without a ton of fiddling-around.


It's not in AWS business interest to support IPv6. As long as they only support IPv4, they need to own an address for every VM in their cloud. As they grow, they purchase more addresses, shrinking the pool of available IPv4 on the secondary market, increasing the price for their competitors. This makes it more expensive to compete with AWS on a large scale if you want to support IPv4.


Sorry, but I don't see it. While they are busy buying up IPv4 addresses, I'll just be over here moving everything to IPv6 only and not have to care about any of that.


Until almost the entire Internet has IPv6 at the endpoint, you're making your stuff unreachable to most people. You will still need an IPv4 gateway.

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.


An IPv4 endpoint is fine and for some situations way cheaper than having every single host be assigned a public IPv4 address. I am not saying that we are there yet, but I can't see a situation where Amazon putting pressure on the market by buying every available IPv4 address resulting in a response of "Let's give all our money to AWS" and not "let's finally make IPv6 happen."


Good point, but the problem is that the companies responsible for "making IPv6 happen" are not necessarily the same companies who want to compete with Amazon. There's very little incentive for ISPs to roll out IPv6, especially when the biggest cloud providers don't support it. It's a bit of a catch 22.


Yeah, what about the hundreds of carriers that don't yet support IPv6?


Don't we have, for example, a Teredo client baked in into every relatively recent Microsoft OS?

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.)


And it works out of the box? Doesn't Teredo necessitate using a relay (someone to translate to native IPv6) – does MS just have one set up somewhere, and preconfigured?


Yes, out-of-box. Haven't ever did anything IPv6-related by myself on that machine.


That curl command doesn't connect on my OSX El Capitan.


> Yeah, what about the hundreds of carriers that don't yet support IPv6?

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.


Nearly all the "second tier" clouds support IPv6: Digital Ocean, Vultr, Linode, SoftLayer, etc.

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.


DO's v6 needs work. They block port 25, and they don't even assign an entire /64 to a machine, which breaks SLAAC and whole bunch of useful ways of using v6.


My ISP doesn't even seem to give me one, which is kind of annoying since I would love to be able to have direct access (through something secure) to all my computers, especially my NAS, no matter where I am. Without a lot of customers on ipv6, why would they support ipv6 on the servers?


My ISP offers it, but you have to buy a special $100 IPv6 PPPoE device and stick it between your IPv4 NAT router and your WiFi router...


This is 100% why my site is not ipv6


We slowly edged IPv6 into ${COMPANY} by a concerted effort to refer to IPv4 as 'deprecated protocol',unilaterally adding IPv6 support questions to our RFP questionnaires, boldly printing DOES NOT SUPPORT CURRENT IP PROCOTOL across design documents. All basically long-term psychological conditioning to raise awareness at the Director+= level.

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.


I'm glad their Prio-1 feature was free, automated TLS certificates, not IPv6.


Of course, so am I. But pretty much the same reasons we can bring up why IPv6 was not super important for LE are the reasons everybody else has to procrastinate on that. It's just a statement of overall sadness that accompanies my personal ~15 year wait for IPv6 adoption.


We would have had it a long time ago if it had been backwards compatible, so that a server with an ipv6 address could talk with a server with an ipv4 address and vice versa. Then it would only have required software upgrades, but since ipv6 is more than twenty years old, most software that used it would have supported it by now, if only because it would have been written a long time after ipv6.


I've heard this argument before … but how could that have possibly worked? An IPv4 client is only going to be able to address 2 ^ 32 addresses, and it seems like the pigeonhole principle implies that the client can't possibly address the entire IPv6 space with that address format.

How would an IPv4 client, with this hypothetical backwards-compatible IPv6, connect to an IPv6 server?


A special flag in the ip packet that indicates which type of address it should be interpreted as, really that should be all, the rest of the work is drivers for software and routers.


If you need to change software on all machines and routers, what have you gained vs IPv6 as it is? being backwards-compatible would mean that it would work with unchanged old machines, which doesn't work since that wasn't planned in IPv4. IPv6 could be simpler, yes, and has accumulated quite a bit of well-meant baggage, but you don't get out of updating everything if you want to completely switch.


It is fairly easy to introduce a proxy for IPv4 only networks. Like a NAT gateway, but even easier since you can do this at the application level (and get real firewalling).


I have several back end servers that are IPv6 only. Since they are just used by our front-end servers it doesn't matter that much.

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.


Eventually people might be able to infer things that help them reduce the space to scan a lot: https://arxiv.org/abs/1606.04327

(may not apply to every allocation strategy)


It was more of an ops issue (lack of IPv6 connectivity at the DC) rather than a software issue:

https://github.com/letsencrypt/boulder/issues/593


Why should they have waited if they got it to work over ipv4, which is where the majority of their requests right now were going to come from. Release early, release often and all that.

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?


Just a note on IPv6 adoption: A couple of weeks ago people made fun of axle counter limitations of swiss railway SBB, however they are running IPv6 already for some months…

  ;; ANSWER SECTION: www.sbb.ch.	14400	IN	AAAA	2a00:4bc0:ffff:ffff::c296:f58e
reply


And yet LE added IPv6 support a mere 2.5 months after it left Beta. It's not that bad!


As soon as an IPv4 address becomes expensive and IPv6 is not, all of that will change.


It's getting to be time for us to admit what the holdup is—IPv6 hasn't been deployed because IPv6 NAT ("NAT66") isn't a thing.

There 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.


> 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

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.


OVH's cheap dedicated servers, Kimsufi, only provides a single /126 IPv6 address, instead of the recommended /64 block :(.


I have heard rumours that, although this is what they state, they actually in practice do assign the entire /64 to the machine. Not sure if this is true and I have not tested it myself.

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...


Well, it does work (just have to allocate the IPs statically) but since you're kinda not supposed to do that, I assume it will either stop working one day, or get my machine voided as a TOS violation or whatnot.

It really is unfortunate. Not having to use a proxy for the sole purpose of sharing the 80 port would be nice...


> But they're used on IPv4

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.


HN uses Cloudflare (a YC company) and could turn IPv6 on for free with a single click.

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.


> 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.


Well, all the IPv6 privacy mechanism does is rotate the /64 suffix. My /64 prefix hadn't changed. From a reputation/risk modelling standpoint, it's usually correct to view a /64 of v6 as a /32 of v4 (i.e. a single address).


I talk to a lot of people who think lack of NAT "exposes everything" and is a big security problem. I try to explain that firewall is not NAT and NAT is not firewall but people do not seem to be willing to hear or understand this. "NAT equals firewall equals security" is tattooed on the inner eyelids of an entire generation of developers and IT people. It borders on religion.

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.


Yeah, I'm not disagreeing with any of that. But the people who don't actually understand how networks work are the people who are reluctant to deploy IPv6. Do you want to teach them all how networks work before IPv6 gets deployed?


What I've seen is that the vast majority of even top developers don't understand much about how networks work. It's a big barrier.


Why? They're top developers, they've written networked apps that work.

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.


Even Apple got bit by this issue. They sold an Airport home router which by default provided full v6 connectivity. They were promptly lambasted in the press for "putting their users at risk by not having a proper firewall!". :(

There was a time when perimeter security was seen as an adequate and acceptable technique.


Yeah, that's where the discussion gets confusing. I will totally agree that a world without NAT would be better, but I will not agree that a world without home routers that drop all inbound connections would be better. If the ISP gives out /64s, the right behavior for the home router is to assign addresses in that /64, but keep doing stateful tracking of outbound connections just like a NAT would, and drop everything else on the floor.

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


"but keep doing stateful tracking of outbound connections just like a NAT would, and drop everything else on the floor"

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.


Hole punching still exists in the V6 world if you want an app to do P2P from behind stateful V6 firewalls. It requires a three party handshake just like V4 NAT traversal. But unlike NAT traversal it nearly always works since there are no symmetric NAT nightmares.

V6 should make all this cruft go away but it doesn't.


Did it have a proper firewall with sensible defaults? (I wouldn't be surprised if some vendors shipped IPv6-enabled routers without a firewall for IPv6)


There's a reasonable argument to be made that router-based firewalls shouldn't be necessary for a home user to have a secure configuration.

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.


De-facto they are necessary, because people expect their networks to be safe, run all kinds of not-great things in there and sort-of got used to configuring port-forwarding. Attacks that can go from inside the network are in practice quite rare (AFAIK), and are a reason to add more security between network devices, not to expose them to the public net.

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 ...


> Attacks that can go from inside the network are in practice quite rare (AFAIK)

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.


I really passionately hate clueless security FUD.


Nearly 30% of the US traffic is now IPv6: https://www.google.com/intl/en/ipv6/statistics.html#tab=per-...


IPv6 NAT exists on Linux, OpenBSD, Cisco, perhaps others. However you would better not use it.


NAT66 implementations exist, and you don't need anyone's permission to use them. But I think it would be more productive to pursue smarter ways to share a /64, than to modify packet headers in flight.

For most purposes, ND proxy is the new NAT.


And there are actually some use cases where NAT66 may make sense (various multi-homing and re-numbering avoidance scenarios). I think the jury is still out. I think we'll see lots of NAT66, but for completely different reasons than we've seen v4 NAT.

I do think those uses will tend to involve 1-to-1 prefix translation rather than many-to-1 mapping.




Applications are open for YC Winter 2020

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: