We added support for IPv6 to Virtualmin projects about a decade ago. Even today, only a tiny percentage of our users ever enable it (this mostly includes our own sites, embarrassingly enough, even though some of our servers in colo do have IPv6 subnets available to them). I should work on making that a thing that happens more by default.
There's a lot of cool things you can do when you don't have to worry about running out of IP addresses. A lot of complex stuff people are doing with cloud meshnets and overlay networks and bridged private networks with port forwarding and such becomes mostly moot if every VM and container can have as many dedicated real IPs as it needs to do its job.
It's also funny/weird to think about how much development effort has gone into stretching IPv4. NAT, port forwarding, SNI (and some hacky other SSL tricks before that to fit multiple SSL sites on one IP), masquerading, tunneling, VPNs, etc. The list is incredibly long and the hours spent on development unfathomable.
One of the places I used to work had a large number of corporate acquisitions. And sure enough, all of the new purchases also used the 10.x.x.x private space. So to get the systems to integrate quickly and meet the schedule, they used NAT. They were likely one of Cisco's largest NAT customers...
In this scenario, NAT was required for them to merge their IPv4 networks because of the high chance (almost certainty!) of address space collision.
With IPv6, the chance of address ranges colliding are much lower because of the wider address space, and the upstream provider wasn't supposed to have been handing out duplicate blocks. IPv6 also has it's own private address prefix (ULA) - fdxx:xxxx:xxxx:.... and if two organizations were both using it for internal addresses, there's a increased non-zero chance of a collision if they merge networks.
Well, the good news is that IPv6 is winning. If Google's stats are accurate - and they probably are - IPv6 went from 1% usage to 16% usage in 5 years (January 2012 - January 2017). And in tech it's all about critical mass. We've passed innovators and early adopters and we're getting closer to early majority. I'd bet that once we're around 30-40% adoption will ramp up since few people want to be considered laggards.
And according to Google's graph I'd say we're about 5 years away from reaching 40%.
I can buy that argument, but I cannot buy IPv6. I mean that literally, my ISP doesn't offer it. Instead I am given two ipv4 addresses, but because of NAT I only need one - which is of course a total joke.
I would love a network where there are no bridges and every mote of dust (or VM) has an ip, but if I cannot buy the addresses, what good does it do me?
You may not be able to now, but the pressure GP mentioned will also apply to ISPs, and they'll soon start seeing IPv6 as a competitive edge, or at the very least, something to not lag behind in making them lose customers. Especially if there's a "killer app" that makes the switch and ONLY uses IPv6, e.g. say, google.com.
I imagine it accounts mostly for Africa and South Asia since they didn't get many IPv4 addresses. They got less addresses than Europe and they're at least 4 times more populated.
So I don't think we're gonna see adoption in Western countries that soon.
A big part of that is how quickly people upgrade their cell phones -- on T-mo at least, a device had to support IPv6 and 464XLAT in order to connect to the LTE network.
You could say the same for the effort expended on ipv6 when it was obvious in the 90's that given the explosion of consumer use of the internet that the lack of a migration path from ipv4 was a killer - and that they should have thrown away ipv6 and started again.
BT before you down vote me I used to work in international networking for BT so I know what I am talking about when it comes to interoperability
that the lack of a migration path from ipv4 was a killer - and that they should have thrown away ipv6 and started again
How is it a "killer"? IPv6 is gaining traction now and gaining it rapidly and looks to be a clear trajectory to become ubiquitous. And hacks like NAT allowed enough runway for this to happen. What exactly is the problem?
This post gives a very good explanation of what a sensible transition plan would have looked like. It mainly starts with IPv4 address space being a subset of IPv6, instead of a totally new address space: http://cr.yp.to/djbdns/ipv6mess.html
wth happened with that, in the original proposal it was 96 bits of zero, then that was deprecated, and then they added :ffff:0:0 with the same functionality
No, they have different functions. Sending to ::1.2.3.4 would send an IPv6-in-IPv4 packet to 1.2.3.4. Using ::ffff:1.2.3.4 tells the OS that you want to send a proper IPv4 packet and no IPv6 is used on the wire.
I don't know why the former was deprecated, but I think almost no OS supported it so might've been just that.
The old date of the article kind of proves my point. It's 14 years later, and we still get huge HN threads around the very-incomplete state of IPv6 transition.
For one, all IPv4 addresses could also be IPv6 addresses. There could be a straightforward translation between an IPv4 packet and an IPv6 packet and back just by prepending the address with 0s. You could enable backbone routers to speak only IPv6 and then translate those packets to IPv4 packets only when sending them to the endpoint devices. In short, IPv6 could have been designed as a backwards-compatible extension of IPv4, not a completely new network.
> For one, all IPv4 addresses could also be IPv6 addresses.
You have that today, all IPv4 addresses are also dualstack addresses, which is how IPv6 is normally deployed for the transition.
> There could be a straightforward translation between an IPv4 packet and an IPv6 packet and back just by prepending the address with 0s.
Which doesn't help you anything because it doesn't enable IPv4 hosts to communicate with IPv6 hosts.
> You could enable backbone routers to speak only IPv6 and then translate those packets to IPv4 packets only when sending them to the endpoint devices.
That's called a tunnel, you can have that today.
> IPv6 could have been designed as a backwards-compatible extension of IPv4, not a completely new network.
What exactly is the backwards compatibility if none of that allows IPv4 and IPv6 hosts to interoperate?
That still doesn't work though, because an IPv4 host still can't address an IPv6 host, and an IPv4 router still wouldn't be able to route to an IPv6 network (without hacks far uglier than NAT).
And they couldn't just upgrade every router in every backhaul network to the new protocol at once (assuming what you describe could actually work) - that took a decade, because lots of it used custom silicon for routing and switching.
> There could be a straightforward translation between an IPv4 packet and an IPv6 packet and back just by prepending the address with 0s.
I'm guessing you're unaware that this is what you do right now. The IPv4 address space has a map in IPv6 at ::ffff:0:0/96 for being able to listen to both IPv4 and IPv6 on an IPv6 address space. There's also a few other different maps of the entire IPv4 address space for other mixed IPv4/IPv6 schemes.
The problem with any addressing enhancement to IPv4 is you still have to change every software ever (at the very least, you need to know how to craft new addresses), and you still have to change almost all hardware as well. Maybe you can devise schemes that could let some of the hardware in the middle be IPv6-unaware, but you still have to route the resulting packets to the correct location, which means you'd want to update most of the middle hops anyways.
The ASCII->UTF-8 transition is arguably nearly as painful as IPv4->IPv6, and it's still nowhere near complete.
Switching to UTF-8 requires two major steps. The first was making software and interchange systems preserve the 8th bit (it used to be commonly used as a parity bit). For email, this was true only about the mid-to-late 90s--surprisingly recent. The second step, which is still incomplete today, is letting control mechanisms that used to speak only ASCII understand UTF-8 (or something else non-ASCII) reliably. You could only put UTF-8 in C++ or C code as of C++11/C11, for example. Non-ASCII domain names are still problematic, to say nothing of non-ASCII email addresses. In other words, trying to speak UTF-8 to someone who only speaks ASCII is still as problematic as trying to speak IPv6 to someone who only speaks IPv4. We just don't notice it as much because we keep advising people to only speak ASCII in key places.
> For email, this was true only about the mid-to-late 90s--surprisingly recent.
Actually, email still is not nominally 8-bit transparent (ESMTP 8BITMIME is optional and not supported by all MTAs), but it doesn't need to be, that's what quoted-printable and base64 are for.
The timeframe I'm using is the timeframe where you stop seeing servers mangle 8-bit email. 8BITMIME technically requires converting 8-bit bodies to QP and base64, which is generally not necessary nowadays, and some would argue that software that chooses not to implement that shouldn't advertise 8BITMIME.
> and some would argue that software that chooses not to implement that shouldn't advertise 8BITMIME.
Which is why I wrote that email still nominally isn't 8-bit clean :-)
Yes, in practice, you won't find an MTA that doesn't leave your 8 bit data unharmed, but you do find MTAs that don't advertise 8BITMIME, and so nominally noone should send them 8 bit data ... except everyone does anyway, of course ...
One of major blockers of UTF-8 transition is Windows world - the operating system itself, who stubbornly stuck with not even complete UTF-16 support, and also a big amount of software for this OS family without the proper UTF-8 compatibility.
The ASCII/UTF-8 backwards compatibility relies on (a) a large subset of data fitting within the constraints of ASCII and (b) most "upstack" applications being able to handle a few garbled/unrecognized characters. How does this map to routing packets on the internet, where the IP header contains time-sensitive metadata needed for delivery and the payload is largely agnostic of the differences?
Except UFT8 is not backwards compatible with ASCII!
An application written to only understand ASCII will not print non-ASCII UTF-8 characters. That is what you are asking here. It can't be done with ASCII/UTF8. It can't be done with IPv4/IPv6.
UTF8 is backward compatible with ASCII just fine - latter is a strict subset of former. It doesn't get more backward-compatible than that!
IPv6, on the other hand, is not at all backward compatible with IPv4 (was never a design goal - magic of OSI stack was supposed to do it's thing). One would argue that incompatibility is in large part responsible for the 6's slow start - even though afterthought bolt-ons eventually did see sunlight - ::ffff:x.x.x.x thing, cornucopia of tunnels and dual-stacks of various degree lite-ness, etc.
... which means that if of two parties only one understand UTF-8, they have to speak ASCII. ASCII being a subset of UTF-8 does not provide and benefit in that regard, just as IPv4 addresses being a subset of IPv6 addresses wouldn't.
Imagine two endpoints talking a backward compatible pair of standards: A only speaks ASCII, B only speaks UTF-8. Would you think they will be able to communicate at least something?
Now imagine two endpoints talking a not backward compatible pair: A only speaks IPv4, and B only speaks IPv6. Will they be able to communicate, at least something?
> Imagine two endpoints talking a backward compatible pair of standards: A only speaks ASCII, B only speaks UTF-8. Would you think they will be able to communicate at least something?
As long as they only speak ASCII, yes.
> Now imagine two endpoints talking a not backward compatible pair: A only speaks IPv4, and B only speaks IPv6. Will they be able to communicate, at least something?
That's why you deploy IPv6 dual-stacked with IPv4. That way, if two parties only speak IPv4, it's completely backwards compatible.
> See the difference?
Sure do I see the difference. What I don't see is how to apply any of that to the v4 to v6 transition in a way that would have any advantage over how it is being done now.
For example, introduce two special IP options that would act as "page selector" for source and destination addresses respectively. i.e.
SRC: 1.1.1.1, DST: 2.2.2.2, no options ->
from 1.1.1.1 to 2.2.2.2
(backwards-compatible packet, classic IPv4)
SRC: 1.1.1.1, DST: 2.2.2.2, opt.X: 1.1.1, opt.Y: 2.2.2 ->
from 1.1.1.1.1.1.1 to 2.2.2.2.2.2.2
(our faux-IPv6)
SRC: 1.1.1.1, DST: 2.2.2.2, opt.X: 0.0.0, opt.Y: 2.2.2 ->
from 1.1.1.1 to 2.2.2.2.2.2.2
("old" address communicating with "new" address)
Last example of three is impossible with IPv4/6 dichotomy, and is most important for backward compatibility here - yes, "old" IP holder needs to upgrade their software too[1], but they don't need to get a new IP address, and as a result you don't end up with two isolated "Internets", a.k.a. dual-stack.
Say, for ease of processing on router, require that X and Y would appear only together, in that order, preceding other options (which is a bit of an exception as far as IP options go, but again, a backward-compatible one).
Now, I'm not proposing this seriously of course, but you asked for example - here you go, a plausible, backwards-compatible "IPv4.1", if you like.
[1] All major desktop OS support IPv6 for last 10 years and major mobile OS for last 7. Let's face it - software upgrade turned out (surprisingly) not to be the biggest obstacle.
What advantage does that have over IPv6? From a backwards-compatibility perspective, it seems identical.
In order for two hosts to communicate over IPv6, both ends need to have: software that supports IPv6, and the entire network path between them needs to be able to route IPv6 packets. Your proposal is functionally no different: you call the extended address field an "option", but in fact every host is required to understand it.
> Last example of three is impossible with IPv4/6 dichotomy, and is most important for backward compatibility here - yes, "old" IP holder needs to upgrade their software too[1], but they don't need to get a new IP address, and as a result you don't end up with two isolated "Internets", a.k.a. dual-stack.
1. What would be a scenario where hosts using this mechanism could communicate where neither IPv4 nor IPv6 would work?
2. How do new internet participants get addresses under your scheme, if it only expands the number of addresses in existing allocations?
Tunnels are used for all sorts of things, including some that aren't IP-shortage related (but many uses are related to IP shortage; connections between devices on private networks, for instance, and connecting IPv6 networks to IPv4 networks). But, I wasn't saying that all of those technologies only have application in solving IPv4 IP shortages, but they often have had a lot of effort expended on making the work for that purpose, because it's such a pervasive problem.
My point is that the IPv4 IP shortage is like the ocean and we're all fish swiming around in it. We don't see the water because it's all around us. But, it's shaped our thinking about networks in real ways that most people working in the field today have never had an "every device has a unique address" mindset. The inventors of the internet and some of the greatest innovators of networking existed in a world where "every device is addressable". I think that's a major difference in mindset and I think it has consequences.
If you have or can get addresses at location A and need some at location B, you can tunnel. Or if you have BGP access you can publish a really long prefix. Both are brittle.
> NAT, port forwarding, SNI, masquerading, tunneling, VPNs, etc.
All that stuff is mostly done for security purposes, not because we ran out of IP addresses. (And before you reply: yes, it really works and is a valid security tool.)
The thing is, the security elements of those things are often only marginal and were not the purpose of their existence (in most cases), and they mostly (though not all) boil down to security-through-obscurity.
We're all mostly agreed that security-through-obscurity generally only provides a false sense of security and isn't the real deal. So, what if instead of working around an IP limit with all this complicated technology, the same folks had instead been working on good point-to-point encryption for everything all this time? And, what if all that complexity didn't have to exist in every device? Every line of code increases the likelihood of a security bug, and a network stack with all this extra stuff has a lot of extra lines of code. I dunno if NAT code has been responsible for exploits, but I'd be shocked if it hasn't.
NAT didn't come into common use for security purposes. It just didn't. It came into common use because not every company owns a big enough sub-network for every device to have an IP and no individual household does. It would require completely rewriting history to suggest NAT is and has been used primarily as a security feature.
Certainly, VPNs have a useful purpose other than dealing with the IP shortage of IPv4, but a lot of VPNs at the corporate level are used to tie two private networks together. And, a lot of development has gone into that purpose.
I'm just saying that in a world without a strictly limited set of IPs over the past decade or two, we would likely have a very different looking internet, and I think it'd be a better internet than what we have, because of how much effort has gone into dealing with the complexity of NATted/tunneled/VPNed/etc. networks.
VPNs are easy: you have all your services exposed, then you need to update every one stat when a bug is released and you are screwed if for some reason some of your services uses broken (or no) crypto, and it becomes more of a chore to decide which users gets access to what services.
With VPN you have more time in case of an attack, everything is encrypted by default and you only have to watch one basket of eggs.
Not being to address a corporate or home network computer from the outside is a feature, not a bug. Doubly so for the datacenter. Corporate IT doesn't want random internet hackers accessing sensitive information on the local corporate network.
Yes, you can theoretically migrate everyone to IPv6 and implement some sort of firewall system to block outside access, but now you're effectively duplicating NAT in IPv6. Worse, due to second-system effect you're bound to end up with something even stupider and nastier than the existing stupid and nasty NAT solutions.
NAT being a security feature is a myth[1][2][3]. Please stop saying this.
> but now you're effectively duplicating NAT in IPv6
No, you are not. If you set up a firewall there still is no translation in IPv6, and it's not needed because the network is end-to-end connected.
> even stupider and nastier than the existing stupid and nasty NAT solutions.
NAT is expensive for both memory and CPU usage, particularly when there is a large number of hosts, and it's not a security feature by itself. In no way can IPv6 with a simple firewall be worse than NAT.
It isn't. The arguments that it is a 'myth' boil down to arguments that it isn't perfect and doesn't protect against every attack. Well, guess what: no security measure is perfect and no security measure protects against every attack.
At the very least, a secure IPv6 network will need to hide end user addresses somehow, because giving everyone a unique, globally-addressable and trackable ID is a security showstopper.
At this point you're going to wonder if you considered all the contradicting requirements properly in your enthusiasm to roll out the next great shiny technology.
> It isn't. The arguments that it is a 'myth' boil down to arguments that it isn't perfect and doesn't protect against every attack. Well, guess what: no security measure is perfect and no security measure protects against every attack.
Except NAT provides absolutely no security, and complicates your network setup, thus making it more prone to configuration errors and other attack vectors due to complexity.
> At the very least, a secure IPv6 network will need to hide end user addresses somehow, because giving everyone a unique, globally-addressable and trackable ID is a security showstopper.
That is called privacy extensions. Also, it's pointless if you allow cookies in the browser.
Only Siths deal in absolutes. NAT has the side effect of behaving like a crappy firewall, so it gives you the added security of a crappy firewall. It's not much but it's something.
But in the end I agree that it's a bit silly to use that as an argument in favor of NAT, if you want a firewall then use a firewall. I guess the advantage of NAT is that while you could forget to setup a firewall and not notice, you'll definitely notice it pretty quickly if you have a few computers on your LAN and you don't have a NAT...
> NAT has the side effect of behaving like a crappy firewall, so it gives you the added security of a crappy firewall.
No, it doesn't. Unless by "crappy firewall" you mean "a firewall that doesn't firewall".
> I guess the advantage of NAT is that while you could forget to setup a firewall and not notice, you'll definitely notice it pretty quickly if you have a few computers on your LAN and you don't have a NAT...
... and you could then set up a NAT and still forget the firewall. Especially so if you mistakenly believe that NAT provides firewall functionality. There is absolutely nothing that prevents your ISP, and by extension anyone who happens to compromise your ISP('s router) from connecting to your RFC1918 addresses through your NAT gateway if you don't also have a firewall.
You're really splitting hairs here. A NAT prevents direct access from the outside to the LAN, except is certain situations. That's part of a firewall's functionality. It's actually probably the first rule you'd set up on most firewalls, then you'd open select ports as necessary (which you do with port forwarding on NATs). A firewall can do a whole lot more of course, but there is some overlap.
Anyway, I think we're in agreement on the core of the issue, it's just a matter of definition. Praising NATs for security is like praising a snowstorm because it makes it harder to steal my car. I guess some people really like to see the glass half-full.
> A NAT prevents direct access from the outside to the LAN, except is certain situations.
Well, an unreliable link prevents direct access from the outside to the LAN, except is certain situations!?
Yes, there are certain scenarios of remote access that are prevented by NAT. But they are a lot less than what people generally think. ISPs' networks not being configured particularly securely is not exactly unheard of, from default passwords on routers to broken VLAN setups in FTTC/B/H setups where people could talk directly on the same ethernet to their neighbours' routers. And even if that is all configured perfectly, you still add their network and their staff to your trusted base. That might not be a big concern for home networks, but this subthread was also and in particular about corporate networks, where targeted attacks are much more likely, and in that case, NAT is in no way a "good enough" solution.
Crossing a router that does NAT is not easy, here's the possible attacks I see:
1. Somebody on the inside is punching holes for you, then you're already inside and even a firewall would not protect against it.
2. You're hijacking existing connections or sending spoofed packets. That's a vector firewalls also have trouble protecting against.
3. The router NAT implementation might have a defect you can exploit. Because NAT isn't intended as a protection measure, it's implementation might be more likely to have flaws than comparable firewall implementations.[1]
In summary, flipping the NAT switch will give you basic protection much as a basic firewall does. That does not make NAT a good technology. But don't dismiss it just because you don't like it.
[1] Though actually in most cases if you fumble the NAT configuration, you won't have any connections at all. Whereas if you fumble your firewall configuration, your gateway might be open both ways and you don't notice. So NAT is easier to get right. It's not simple, it's ugly and easy!
I don't dismiss NAT because I don't like it, I am just stating the fact that it does not provide any security, despite what many people, including you, believe.
Your list is missing one point:
4. They just send you a packet addressed to the internal address of one of your devices.
NAT does not prevent inbound connections. A NAT gateway is just a router with additional NAT functionality. When an inbound packet arrives, a NAT gateway will do two things:
1. Check whether the packet belongs to a flow in the table of NATed connections. If so, rewrite the destination address/port to the internal values.
2. Check whether the destination is in the table of port forwardings. If so, add an entry to the table of NATed connections and rewrite the destination port address to the internal values.
Other than that, it's just a router. If it receives a packet from the WAN that is addressed to the LAN, that probable won't match either of those two cases, so it's simply forwarded unchanged.
The only reason why you cannot just send anyone who uses such a NAT gateway a packet to their LAN is because their ISP doesn't route the address range of their LAN to their router. But the ISP or anyone compromising the ISP can just do that.
That is, unless the same device also contains a stateful packet filter firewall. Which you can have without any NAT, with IPv6 just as with IPv4.
NAT first and foremost means using private address ranges as opposed to being reachable on a public address. Sure a properly configured firewall would protect against many scenarios where NAT does not. Still, when somebody asks me whether they should flip the NAT switch on their router at home, I will say "yes it protects you". And that's true.
A compromised upstream is a whole other league from most threats. At that point you've got to think about physically hardening your network equipment because the people who attack your ISP's network equipment would probably find it worthwhile to sneak into your home to compromise your network directly.
> At the very least, a secure IPv6 network will need to hide end user addresses somehow, because giving everyone a unique, globally-addressable and trackable ID is a security showstopper.
this is a solved problem now. All modern OSes either create short-lived temporary addresses or they hash some machine-unique information with the public prefix (that will change in the same frequency as your current V4 address changes).
But why use them when you don't have to? There's benefits to operating a network that handles as little state as necessary.
Running internal services on address space that's not routable on the public internet has its advantages. You can do this with IPv6, but not as easily as you can with IPv4.
- You can use IPv6 privacy extensions to randomize your IP address. Your computer can have a dozen IP addresses at a given moment, using a different one to access different services, as addresses are being rotated.
- Most corporate networks have static IPs. So while a specific IP might be shared with 100 devices, it's usually easy to fingerprint a visitor uniquely.
- There are tons of other ways to track people, other than their IP. Besides, you want to track them across networks, as they move around.
I'm also very sensitive to tracking, but I think at this point you have to start looking at how to improve your privacy with IPv6, sharing/encouraging good privacy-sensitive practices on IPv6.. not spreading FUD.
a) Do you provide privacy plugins to users' web browsers, and require they use them? If not, the concern is close to irrelevant, but there are privacy-minded ways to assign IPv6 addresses.
b) is a basic feature of the crappiest firewall (the free router from my ISP includes it)
c) is a standard feature of a business-level firewall; secure network access (e.g. with a VLAN) is orthogonal to the choice of IP protocol.
NAT66 is possible, in the sense that the protocol won't stop you from implementing or using it. But in practice it's relatively rare, because once you have a nearly-unlimited supply of addresses, NAT typically has more drawbacks than benefits.
The claim that SNI is a security feature is based on the assumption that it is more common to sniff the wire and collect the IP header rather than doing deep package inspection. I don't see this to be true with modern surveillance equipment and raw network taps.
Additionally, you could create a setup where every visitor dynamically get a ip address from a pool (shared between multiple websites) when asked over encrypted dns. This kind of setup would clearly be superior over SNI's plain text issue.
I run IPv6 only servers on Scaleway because IPv4 addresses are €1/month extra and my node costs €2/month. That's a 50% cost increase.
The biggest stumbling blocks for IPv6 are the fact that many prominent cloud services don't fully support IPv6. The biggest problems for me are Amazon S3 and Github. I end up having to pass traffic for those services through an SSH tunnel to a nearby node with both IPv4 and IPv6.
On an unrelated note, I'm happy to see that apparently my home country Belgium has one of the highest adoption levels worldwide, if not the highest.
Same here! Google-Cloud still doesn't really support IPv6 on public-facing nodes (?), and Github ... However, this encouraged me to self-host with Gitlab and to use other hosting providers (ex: OVH). Sometimes I will NAT the outgoing IPv4 connections on VMs (if I control the host, and the host has one IPv4 address).
A lot of internal services, such as logs, build systems, etc, don't need public IPv4 addresses, but giving them 10.x.x.x addresses quickly becomes a burden when dealing with multiple networks.
NAT64/DNS64 is supposed to work well for allowing IPv6-only networks outgoing access to IPv4. Servers are less likely to use software like Skype that only works with IPv4.
It would be nice if providers that support IPv6-only networking would provide NAT64 gateways and DNS64 DNS servers.
Hacker News used to have a GitHub repo somewhere on https://github.com/HackerNews/ where they hosted an issue tracker - several people raised this and their response was something along the lines of "we can't yet as our anti-spam code relies on accurate geolocation and some other things easier/possible in IPv4".
Unfortunately I can't find a link - I think they closed the issue tracker. Perhaps dang can comment? I'm typing from memory so it might be remembering incorrectly.
It's not possible on IPv4 either, your IP is one of the easiest thing for you to change...
Browser/device finger printing is probably the best option at the moment, but you'll get plenty of false positives amongst privacy aware users who block fingerprinting.
I think the rough IPv6 equivalent of a single IPv4 ban would be to ban a /64 subnet. This bans all users in that subnet which is the same as banning an IPv4 subnet hiding behind a single NAT address.
I'd say the same way you ban them with IPv4. IP bans are trivial to circumvent, so those who won't bother to/can't circumvent them with IPv4, also won't with IPv6.
If the user has a static IP address, in IPv4 you ban a /32 (i.e., one address, his own). In IPv6 you'd have to ban the entire range allocated to the user, usually a /64. (edited)
If the user has a dynamic IP address, well, you're on your own. :D
A /32 in IPv6 often is an entire provider, so that's not a good idea. A /64 is the closest to a single IPv4 address, (although some providers give each customer a /56 or so, for creating subnets).
HN has a system like that, but it fails because some people can still see the 'hidden' / dead posts, and for some reason they then go and point out "your comment shows up as [dead]", which defeats the purpose.
Can you explain to me what will happen if I don't turn on the AAAA record?
Like in theory of course I want to support IPv6, but in practice I've got a huge TODO list, and if there are present work-arounds that are doing good enough for now, I'd like to prioritise it correctly.
The two biggest arguments are Carrier Grade NAT and dodgy transitional stacks.
1) ISPs are increasingly deploying Carrier Grade NAT, which puts several people behind a single IP. This completely breaks end-to-end as you can't port forward but if you're running a website, the worst issue is if you ban an IP address, you could be cutting off several legitimate users to get rid of 1 person. It's like banning a whole country because of a few people which Wikipedia has done in the past by mistake: https://en.wikipedia.org/wiki/User_talk:82.148.97.69 see https://techcrunch.com/2007/01/01/wikipedia-bans-qatar/ This problem will only get worse as time goes on. The Internet is starting to feel broken when an entire country shares a single IP address.
2) In some cases, ISPs might address the shortage slightly differently, by serving up an IPv6 address that proxies back to your website over IPv4. To you it looks like Carrier Grade NAT, but you can actually do this yourself if you have an IPv6 enabled server (Linode, DigitalOcean work) and use nginx to reverse proxy. That way you can at-least set an X-Forwarded-For header that will give you better analytics and more precise blocking. Either you do it or the ISP will do it for you but give absolutely no data.
1) ISPs are increasingly deploying Carrier Grade NAT, which puts several people behind a single IP. This completely breaks end-to-end as you can't port forward
Carrier grade NAT breaks a lot of things in subtle ways. E.g. our ISP does DS-Lite to encapsulate IPv4 in IPv6. For months, our internet connection would sometimes seem dead for a couple of minutes. The router was fine and had uplink.
At some point I figured out that it often happened after a device woke from sleep and that IPv6 continued to work fine. It turns out that Bittorrent Sync was culprit. When a device woke up, BTSync syncs any changes and opens a boatload of connections through different ports. Apparently, the ISP's carrier grade NAT has some QoS where it starts dropping connections if too many ports are opened at the same time.
We shut down BTSync on all devices and never encountered the problem again [1].
At the time Bittorrent Inc. and later Resilio did not really seem interested to add IPv6 support.
[1] Of course, another theory is that they intentionally throttle Bittorrent traffic, but that doesn't explain why no IPv4 connections could be made while IPv6 worked fine.
> Carrier grade NAT breaks a lot of things in subtle ways.
All types of IP Masquerading[1] break the network in both subtle and overt ways. Without proper addresses, we've been s stuck for a couple decades having to work around "party lines" instead of developing real network software. Now that ISPs are starting to do this, some of the workarounds are no longer possible and the damage done to the network is becoming more obvious.
I hope we can successfully transition to IPv6 in the very near future, or the internet will finish transitioning from a powerful peer-to-peer network back into cable tv where we no longer have the ability to publish without an imprimatur[2].
I'm absolutely fucking amazed BitTorrent Sync, recently created peer to peer software, didn't have IPv6 since day one? IPv6 just makes P2P easier and more reliable as there's no NAT anymore. Why wouldn't you want that?
Mobile carriers here are bringing back NAT on ipv6 now. Wannacry fears? NAT for the sake of firewalling?
Phones still seem to get individual addresses.
Which one? Really curious. Another point to mention, that I've seen mobile operators sends you multiple /64s, thus if you run in adnroid shell 'ip addr' you see one /64 while if you connect say to ripe.net it shows completely different IPv6 address from different range, while still no NAT. Perhaps that was your case, perhaps not. Details would be very interesting.
If your address on ripe.net doesn't match any of your local interface addresses, then that's NAT (or perhaps a transparent proxy) by definition.
Well, in some environments, it's possible to bind() to an IP address that's not actually present on a local interface, but it's unlikely that your browser would support that.
On other side I can ping IPv6 address of the tethered laptop. And for tethered devices ripe reported IPv6 matches interface. Indeed, transparent proxy / media gateway could be the case for the phone itself.
Corporate networks with professional IT staff are where you'll find the legacy systems and equipment that get in the way of using IPv6. Home users have all been running operating systems with IPv6 on by default for years, and their routers are mostly new enough to make IPv6 work out of the box as soon as the ISP is ready.
Considering what's at stake if you accidentally make some part of your infrastructure routable it seems pretty reasonable corporate environments want to be very careful about IPV6 adoption. Personally I think they should still do it but if HSBC is in the news tomorrow after leaking customer details because of a routing woops there would be a lot of "they should have known better!" here and in the press. It's going to a take a long time for sensitive corporate environments to decide the rewards outweigh the risks.
I think any enterprise that fails in this way has way bigger issues, and I would expect to have already been compromised. Every single enterprise should already have the firewall rules on their edge routers that would prevent that set up even with IPv4 (remember, NAT is not intended as a security feature and only kind-of works like one. Any competent network engineer should not be relying on NAT to add any security).
Infrastructure that is "unroutable" is not usable. Whether you add a route from the outside world to your internal services is completely orthogonal to whether your protocol is IPv4 or IPv6.
my guess is that it's mobile phone traffic vs. laptops; I suspect a lot of mobile providers have been pushing ipv6 for their needs, as mobile device usage has been growing a lot faster than desktop usage in recent years.
Yep. I've had IPv6 at home since I moved in mid-2012 and got comcast (my existing Airport Extreme supported it, and I got a DOCSIS modem on the supported-for-ipv6 list).
At work, only parts of our network do IPv6, 5 years later. Enterprise stuff is slow to change. :(
I came here to ask exactly the same question. I can only assume that entertainment activities (console gaming, video on demand, etc.) can bring the traffic to make such a difference.
Because the dominant ISP (Telenet) has enabled IPv6 by default on all their residential gateways. And because they (possibly somewhat surprisingly) have some smart people working for them.
That's remarkable, since Telenet is part of Liberty Global, who owns so many ISP's. Eg. neighbouring country The Netherlands has Ziggo (also owned by Liberty Global). Adaptation in The Netherlands is only 9 pct. Makes me wonder if Belgium is used as a technical testing playground for Liberty Global or if it's just a smart move by Telenet.
Depending on where you are in the Netherlands Ziggo will give proper Dual Stack or DS-lite to new customers. It reflects the networks that Ziggo was cobbled together from. If you are in a former UPC area you probably want to call them and ask them to downgrade you back to IPv4 (they do this for free). Their DS-lite solution employs carrier grade NAT which blows dog chunks.
DS-Lite[0] means you have proper native IPv6 but only a tunnel on top of that for v4, so it's unlikely that IPv6 connections are negatively affected by this setup.
My understanding is that for historical reasons the newer ISPs (mostly cable providers) were running out of IPv4 addresses. They then switched their own networks over to IPv6, meaning that if you live in Belgium, there's a very high chance your router has an external IPv6 address and not an IPv4 one.
Because they were running out of IPv4 addresses and they are legally required to not have more than IIRC 16 customers behind one address at any time for law enforcement reasons, so they figured that CGN wasn't worth it and decided to adopt IPv6 instead.
Not all customers do. Professional contracts and people asking special stuff or modifying their (Telenet-managed) firewall settings automatically get one. Other consumers - which is the large part of their customer base - get IPv6 with CGN/NAT64 with maximum 16 clients NAT'ed behind a public IPv4 address for legal wiretap+privacy reasons.
Really? I've never seen anyone with a shared IPv4. Maybe because every time I look into it the first thing I do is modify their firewall settings slightly. Heh.
ISP's could argue that websites should be logging source port numbers of tcp connections. That would allow them to have thousands of customers behind the same IP, and still able to identify a single one.
BTW, I just noticed: No, you cannot realistically have thousands of customers behind the same IP. There are only 65535 TCP ports per IP address, just loading your typical website that loads resources from tons of domains can easily need a hundred ports at once.
No, they couldn't, because that would be illegal. An ISP cannot just record the communication of their customers because it makes thing cheaper for them.
Also, that easily generates petabytes of logs, so it's not really cheap either.
As an end-customer in Germany, 30.76% is a lie. Most big ISP don't even have any (public) plans to support at least a double-stack. However, as rumours say, internally it's all v6 now. The best you can hope for (providing you have a custom and not supplied router) is 6to4.
Just wondering about the data collection, -- why isn't it strictly monotonic over time?
Edit: Answered my own question -- it looks like the data specify access daily, not what I assumed was overall adoption. This does present some interesting patterns, however. For instance, noting that there's a peak weekly on Friday and bottom out on Monday, one might be able to make a conclusion about workplace adoption versus home usage.
Makes sense. I've had home IPv6 via Comcast for at least half a decade, and they're the largest ISP in the US.
They are an early adopter and innovator of IPv6, partly because they had more modems in their private network than the number of all possible 10.x addresses.
Yes. As an inventor of CG transition technologies like DS-Lite (RFC 6333), Comcast has really led in building the technologies that were needed for transition in the past decade.
I was on 6bone too, but there's a lot of difference between ping6'ing each other over tunnels and rolling out v6 to millions of customers without them noticing.
I dunno ... I had native IPv6 on DSL ~ 12 years ago. I mean, sure, they have actually developed technology in that area, so maybe innovator is somewhat appropriate, but early adopter?
I was surprised to see such a low level of adoption for Sweden, so I looked up the IPv4 assignments by country[0]. Sweden has the second highest number of IPv4 addresses per capita, at 3.3. I wonder if that is the reason why.
What is "more than rudimentary" support? AWS supports public IPv6 for virtual instances, all three support it for their load balancer products, and AWS supports it for a number of additional services (S3, CloudFront, WAF). Most of this support has been released within the last year, and I'm sure that this is work that's been in progress for a while and that improved support is coming. Cloud providers are ready for developers to build products accessible over IPv6. Are developers ready to build them?
Let me past something that I posted to Calico Slack about a week ago:
> Has anyone tried running IPv6 in AWS? It kinda seems like using it for containers is still very messy. IPs are assigned via DHCPv6 and you cannot actually turn off src/dest checking, so to assign public IPv6 address on each container, you would need to assign each IP address one by one on the interface via AWS API and use a hook in host's DHCPv6 client that adds the IPv6 address to NDP proxy (not 100% sure if this is required) and disables assigning it to interface. With this, you would get 10-30 IPv6 addresses per interface and with some additional hacks to use multiple interfaces you could possibly get 240 IPv6 addresses per instance on larger instances (or well, 16xlarge instances give 15*50)
Though admittedly even if there was a support for getting prefixes to instances, it would still take time for other things to get support for it (e.g. Kubernetes)
The main reason I haven't switched my networks to IPv6 is that I plainly don't want to support both protocols at the same time. If I could just switch over to IPv6 and leave v4 behind I would, but I just can't be bothered to do twice the work every time I setup a firewall or a router. Double the config, double the tests and on top of that you have to make sure everything inter-operates smoothly when IPv4 alone still just works.
As you mention in your other post it really is the "billion dollar mistake", it's obvious to me in hindsight that they should have made IPv6 completely backwards compatible with IPv4, no matter the cost. Have a deprecation procedure later on if you want to remove the hacks necessary to support IPv4. Have a clear and simple upgrade path, one step at a time.
Sure, having a clean new standard is compelling but clearly it's making things way more difficult that they ought to be. And that's how we end up more than 20 years after RFC1883 was released with "barely" 20% adoption. NATing was easier than IPv6, so people NAT'ed everything and the internet became the net.
> As you mention in your other post it really is the "billion dollar mistake", it's obvious to me in hindsight that they should have made IPv6 completely backwards compatible with IPv4, no matter the cost.
It's not a matter of cost, it's simply impossible.
IPv4 has a 32 bit field for the source address and a 32 bit field for the destination address, and every connection over IP needs to send packets back and forth between the two addresses. As soon as one party has a longer address, the other party has to know how to handle that, otherwise, they cannot possibly communicate.
The only point where compatibility would be possible to some degree is the network, but (a) that compatibility is in effect a tunnel, and there are lots of ways to tunnel IPv6 over IPv4 just fine, and (b) most of the global internet supports IPv6 just fine, and has been for a long time. The problem is the migration of the endpoints, not so much the network.
I actually started replying to your comment with my master plan to make an "IPv6 in IPv4" but I realized that I was probably going to make an ass of myself since plenty of much more clever people have worked on the subject for a long longer than I did.
But I guess my main issue with this is:
>(a) that compatibility is in effect a tunnel, and there are lots of ways to tunnel IPv6 over IPv4 just fine
I agree that no matter how you slice it, at some point if you want to transition you'll have to tunnel things. But why are there "lots of ways" to do it? Why isn't there one single, "it just works" way to add compatibility? IMO this should have been a core feature of the standard, bullet point #2, just below "add more addresses". Explain in details how the transition will be made, how you convert an IPv4 into IPv6 incrementally while not breaking anything. Sure it's hard to make a one-size-fits all, but all the corners you have to cut and just make it work.
Why isn't the IPv6 my ISP provides simply an extension of my IPv4? If my IPv4 is 216.58.213.174, why isn't the IPv6 216.58.213.174.[more stuff]? Why can I just concatenate my IPv4 public and NAT'ed LAN IP to get a valid IPv6? `ifconfig eth0 inet6 216.58.213.174:192.168.0.101/32` and here we go. It looks familiar, I understand what it means. You could even standardize it to make the IPv4 always be the low bytes of the IPv6 address or something like that, this way I don't have to worry about two sets of addresses.
Instead it's `ifconfig eth0 inet6 2001:41d0:000a:050d::1 prefixlen 128 accept_rtadv no_radr`. Ah. I'm sure there's a good reason to make those changes but I can't really be bothered to figure them out as long as IPv4 just works. I'll get around to learn it, eventually, maybe in a few months when I read an article on HN telling me that we're at 21% worldwide adoption.
> But why are there "lots of ways" to do it? Why isn't there one single, "it just works" way to add compatibility?
Well, for the same reason why there are lots of ways to tunnel IPv4 over IPv4? Some work through NAT, some don't, some encrypt, some don't, some allow for transport of packets that exceed the tunnel's transport PMTU, some don't, ... it's some form of tradeoff for different needs: If you are behind CGN of some crappy provider, you probably have to tunnel over UDP using small packets, if you are an ISP, that would be way too much overhead and you want to instead transport over raw IP in jumbo frames.
> Why isn't the IPv6 my ISP provides simply an extension of my IPv4? If my IPv4 is 216.58.213.174, why isn't the IPv6 216.58.213.174.[more stuff]? Why can I just concatenate my IPv4 public and NAT'ed LAN IP to get a valid IPv6?
Because that would not actually help anything. That would possibly make the user interface look a bit more familiar, but you would still need a completely new protocol underneath with all the same migration problems that we have now. And also, the differences at the user interface level are pretty minor, conceptually IPv6 really works much the same as IPv4, except with longer adresses. That they chose to use hex notation instead of decimal really is probably simply to make the notation shorter, and also the shorthand-notation for a run of zeros makes things a bit less unwieldy.
As for actually somehow reusing the existing address space, the existing global IPv4 routing table is massively fragmented with every larger ISP having tons of routes for disparate prefixes that they acquired over the years. That makes IPv4 backbone routers expensive. IPv6 is large enough that providers generally should never have more than one prefix, which makes the routing table a lot smaller.
But don't you think UI is extremely important in these situations? If you sold IPv6 as "it works like IPv4 but with 128 bit addresses" I'm sure it wouldn't seem nearly as daunting to make the switch. But when you start looking closely you realize that it's more than that.
Regarding the size of the routing table, is it really that much of a big deal? Is it significant in the ISP's expanses? I find that hard to believe.
Also, obviously the ISPs might want to use clever tricks to save on bandwidth and processing power but that's not really what I'm talking about. ISPs have the manpower and the knowledge necessary to deal with that difficulty.
The case I have in mind is what is, in my experience, 99% of the private networks today: you have a single public address, a NAT/Firewall/Router combo and then a handful of private subnets.
This is where the migration should be as simple, seamless, familiar and comfortable as possible. This is where people can't be bothered to spend one week understanding IPv6 and reconfigure everything and still not be certain that they won't break something. This is where having IP addresses that actually look like IP addresses matter.
> But don't you think UI is extremely important in these situations?
Well, yeah, that's why they invented a more compact notation than 207.170.223.70.213.170.133.129.131.136.235.244.33.54.210.133.
> If you sold IPv6 as "it works like IPv4 but with 128 bit addresses" I'm sure it wouldn't seem nearly as daunting to make the switch.
But ... it doesn't seem daunting? I mean, obviously, you seem to think so, but I didn't find anything daunting about it when I enabled IPv6 on my network and servers ~ 15 years ago.
> Regarding the size of the routing table, is it really that much of a big deal? Is it significant in the ISP's expanses? I find that hard to believe.
The current global IPv4 routing table has ~ 670,000 entries, the current global IPv6 routing table has ~ 41,000 entries, distributed over 58,000 and 14,000 ASes, respectively.
Mind you that a router has to do a routing table lookup for every packet, so tens to hundreds of millions of lookups per second for backbone routers. The CAM for routing table storage is one of the performance limiting factors of a router, and the larger it needs to be, the slower and/or more expensive it gets.
> The case I have in mind is what is, in my experience, 99% of the private networks today: you have a single public address, a NAT/Firewall/Router combo and then a handful of private subnets.
There were 6to4 or teredo, for example, which allowed for some of that. But part of the problem is that if you want to talk to IPv6 hosts over v4-only connectivity, you need to talk to some sort of gateway--the IPv6 host itself obviously doesn't have an IPv4 address (otherwise you could just as well speak IPv4), you yourself cannot directly speak IPv6, so ... you need some party that is connected to the IPv4 and the IPv6 networks to translate between the two. If that is supposed to provide good performance, your ISP needs to operate such a gateway. Which means it's not exactly an automatic solution either.
> This is where the migration should be as simple, seamless, familiar and comfortable as possible. This is where people can't be bothered to spend one week understanding IPv6 and reconfigure everything and still not be certain that they won't break something.
Well, for the most part, most end users really shouldn't need to do anything like that. Even less so that with IPv4, really: Your ISP assigns you a prefix, your router assigns addresses to your devices, and everything should just work.
If you actually want to do some fancy network setup or something ... well, really, it's not that difficult. Easier than v4, really.
> This is where having IP addresses that actually look like IP addresses matter.
But they look exactly like what IP addresses have looked like for the last almost 20 years! IPv6 IP addresses, that is ...
IPv6 could have done three things. First, embed the "legacy" address space. Second, have legacy-to-legacy connections use v4 on the wire. Third, strongly encourage existing user-maintained configuration (config file formats etc.) to remain perfectly valid as long as they don't use v6 addresses (or other v6 features.)
You are right, you'd still need a "legacy" address to connect to "true" v4 servers, but that address would be all you need, while most operating systems, routers, client and server software could be, technically, all-v6 all-the-time by now.
> software could be, technically, all-v6 all-the-time by now.
I started using v6 in the late 90s.
Software developed post-2000(-ish) should already be compatible. Unfortunately, there are a lot of developers that think this is hard/impossible (or they are lazy), and so we have software that is defunct by design.
> that address would be all you need
Regardless of how the address was represented, software would still need to be updated.
I stand corrected, RFC 4038 seems to be what I was looking for. But it seems to be a late addition, and OS support is optional. If developers think moving their apps to IPv6 is too complicated, I can't fault them.
> If developers think moving their apps to IPv6 is too complicated, I can't fault them.
I can. I'm a developer and it's easy to add support for IPV6 to apps.
Parsing and displaying IPV6 addresses? There are many libraries and articles for that. Connecting to a host name? Call one function and loop through the list of address structures returned and connect like normal with them skipping the ones that failed. Accepting connections? A little more tricky but since you're writing a server it's not difficult in comparison. The tricky part is figuring out what order you should bind to the socket or if you should use IPV4 mapped addresses.
And if you're using a higher level language or library then it becomes even easier. You just have to worry about the larger size of the address in both binary and text representation if you care about that at all (connecting to a host name you don't have to worry).
The only difficult bit is convincing management it's a good idea to support IPV6. But then the problem shifts from the technical to the political.
> Second, have legacy-to-legacy connections use v4 on the wire.
Just as IPv6 does?
> Third, strongly encourage existing user-maintained configuration (config file formats etc.) to remain perfectly valid as long as they don't use v6 addresses (or other v6 features.)
Just as is the case with IPv6?
> You are right, you'd still need a "legacy" address to connect to "true" v4 servers, but that address would be all you need
Just as it is now?
> while most operating systems, routers, client and server software could be, technically, all-v6 all-the-time by now.
If they implemented the extensions ... just as if they implemented IPv6 by now?
It sucks at being compatible with ipv4. The "billion dollar mistake" :-)
It also sucks at having software/hardware stacks nearly as well debugged as those for ipv4, which means running ipv6 at all is a security risk.
Nobody would switch for sundry technical advantages. The main driver for conversion is that ipv4 addresses are scarce. As soon as "we" seriously "move to ipv6", however, the scarcity driven pressure to convert is relieved. We're bound to reach an equilibrium that will include ipv4 for a long time, possibly forever.
> It sucks at being compatible with ipv4. The "billion dollar mistake" :-)
You cannot make it compatible. The whole point is address extension, and a legacy IPv4 endpoint cannot possibly talk to a new, extended-address endpoint.
> It also sucks at having software/hardware stacks nearly as well debugged as those for ipv4, which means running ipv6 at all is a security risk.
There is no "stack". The software above the IP layer is still UDP, TCP, HTTP, SMTP, ...
> Nobody would switch for sundry technical advantages.
Yeah, actually, lots of competent people do, because NAT and duplicate addresses just cause so many pointless problems.
> As soon as "we" seriously "move to ipv6", however, the scarcity driven pressure to convert is relieved.
Yep, the pressure to convert will be relieved because people simply won't bother setting up IPv4 in the first place at some point because it adds so much unnecessary complexity, so no need to convert. And once that happens, even the last holdouts will enable IPv6, at which point IPv4 will be a largely useless legacy protocol that just causes maintenance costs for nothing.
I've been writing all my socket code (this is embedded so plain C) to be automatically compatible with either IPv4 or IPv6 for, what, ten years? I thought everybody did that (it's best practice).
Don't most higher level languages also just do this by default under the hood?
- NAT and CG-NAT for big networks is complex, resource-intensive.
- Fragmentation on IPv4 requires more work/complexity from routers.
- Some of my friends seem to think that calculating /29 IPv4 networks is simple, but I don't deal with this often and it really annoys me (yes, even with ipcalc). Not to mention the number of addresses lost due to routing (I often use link-local addresses on IPv6).
Start moving now, progressively, or you'll be forced to do it in a rush later on. This isn't too different than https adoption. Those who minimized its importance ("oh, that's just internal communication, it can be plain http") got seriously bit.
Meh, not major problems. Those will inevitably go away as more and more people adopt ipv6.
However, I feel as though maybe developing countries might stubbornly stay on ipv4. They're already double-NATing right now, and it's likely that developed countries will sell off their ipv4 ranges once they've made the switch.
Brazilian here. Not sure if I'm part of the "developing country" category, but most major ISPs already give ipv6 for home users. I've been using ipv6 since a few years without even realizing until I entered the router and saw an ipv6 address along with an ipv4.
Here's a question, I know next to nothing about IPv6, but I imagine a big part of the problem is migration of IPv4 (of course). So, for new projects.. I don't have this issue, right? What are my options to implement proper IPv6 support for my new apps right from the start?
If you have to ask: Nothing, that is handled at lower layers.
Except you might want to actually configure IPv6 on any backend servers you run and add IPv6 DNS records so that your client software can actually use IPv6.
That depends. If you write your code using a high level abstraction you don't have to do anything, it should just work. High level could be as high as an http module (python), or as low as a wrapper (boost::ASIO). Odds are very good your language has one or more. In general this is the way to go choose something that handles the details for you in a language correct way.
If you write low level sockets you at least need to be aware of both when you connect the sockets. The easiest is a server as you just need to listen for connections on two sockets. When connecting you should be aware of cases where it seems like either protocol will work, but in fact one is broken (generally this means the local machine supports ipv6 but the network is not connected - it is common to ignore this, but you will get support requests because of it unless you implement a try both scheme). Either way once communication is established there is no real difference in the code.
The above is the common case. If you need to do more than communicate it can get complex quickly. In general I wouldn't use raw sockets unless you actually need to do something complex enough that no existing wrapper will work for you (performance alone is reason to use raw sockets if you have profile data to prove it). However since I don't know your domain I cannot suggest how complex your code will need to be to support both.
It really depends. I just started on a software project that use enet as a network library as an integral part of the project. Sadly enet doesnt support ipv6, but there is really not much I can do about it since its embedded and as such on a way lower level than the project itself. So it really depends on the core your software is built on is what I'm trying to say
If you want to see the percentage of requests from a website that are IPv6, my service https://urlscan.io supports both IPv4 and IPv6. A lot of similar services only scan via IPv4, which I believe is an oversight.
My original motivation was: "This website is slow as shit, let me fire up Chrome Devtools to see how many requests it is making." This doesn't scale and doesn't contain additional info such as GeoIP information, so I created https://urlscan.io. By now it has become a service that is heavily used by security researchers for detecting such things as phishing websites.
In my experience IPv6 support in home Wi-Fi routers is still hit or miss. I recently had to replace a new TP-link router because some wireless devices refused to get a IPv6 address due to failing duplicate address detection (it was some kind of multicast issue as far as I could see)
The router in question got several firmware updates where changelog mentioned an unspecified "IPv6 fix", but none fixed the issue for me. Finally I just gave up and bought a new one from a different vendor.
TP-Link is the worst... their enterprise WAP line doesn't support IPv6 at all. I've had IPv6 working out of the box on every piece of network hardware I've had since 2009. When I bought a new access point recently it didn't even occur to me that I needed to include it on my checklist of necessary features. Nope, no support.
My own router has it's problems too, like blocking ICMP traffic to IPv6 hosts by default and not properly supporting the privacy extensions (each address creates a new entry in the routers host list)
> I recently had to replace a new TP-link router because some wireless devices refused to get a IPv6 address
What's the advantage of having an ipv6 home lan? I think for a home network the 192.168.0.0 subnet should be more than enough. Or am I missing something?
Approximately half the internet exists because of the lack of IPv6.
A partial list:
* Streaming music - because you can't connect to your music collection at home
* drop box - because neither you or the person you shared with can direct connect
* power/solar monitoring - cloud service because you can't connect to your system
* IoT/Dropcams/Nest thermostats - require cloud services... because your phone/tablet/desktop can't connect to your clients automatically
* security services, garage door control, smart home - another cloud service because you can't monitor/control directly.
* netflix - can't connect to your home plex
* skype (after they ditched p2p), google hangouts etc - requires cloud because the clients can't connect to each other
* pretty much every chat client - central servers because you can't direct connect.
> IRC had servers decades before IPv4 address scarcity became a thing.
Because it's a group chat, where a server is much more natural than for two parties communicating. Plus, it has DCC, so you can actually efectively use IRC without an IRC server.
The worst thing about some software developers is their natural tendency to assign the success of the businesses to the purely technical decisions, and not political ones:
- streaming music - you pay Spotify for it's browsing and discovery services and the fact that you don't pay for every album you would like to listen to. Not to access "my music collection at home". Quite frankly it doesn't seem to me you can even do that on Spotify, but I may be wrong.
- power/solar monitoring - you would need a server which would specifically handle the metric collection and make decisions upon this. Obviously cloud is cheaper than a separate box stationed in your house.
- IoT/Dropcams/Nest thermostats - Philips Hue doesn't work through cloud since it doesn't have to. Dropcams are usually a separate device which does not provide server capabilities per se - so require a box.
- security services, garage door control, smart home - all of that is controllable directly, but I am not going to start on how much you will be overpaying for every of the devices for them to have a separate fully-functional IP stack that is easily connected to a (W)LAN (wi-fi, ethernet, bluetooth - all of that is either expensive, bulky or power-hungry). So a box/cloud is always a solution.
- netflix - same points as Spotify. You don't pay them to manage your collection, you pay them to have access to a constantly curated list of newly available items.
- skype, google hangouts, etc. - please do show everyone how to create a chat service that would allow me to chat with anyone I would like to without having to resort to a centralised storage of identities and at the same time solve the issue of spam.
Right, but imagine something like a Raspberry Pi with some cheap storage attached. It could collect data from your house (temps, duty cycle of furnace/AC, solar panel power, garage door state, collect your photos/docs, receive email/IM asynchronously, etc). Sure you'd want offsite backups, maybe at a friends house... if his server had a public IPv6 address. With IPv6 it would be much easier to remotely use all those resources/files.
You could give friends/family access to your photos, you could receive/send messages even if your phone/laptop was down, off, stolen, or gasp without a network connection. You could share files, and if someone wanted to confiscate it they would have to come knocking.
IRC never did async well (you have to be online at the same time) and never became popular with the general public. Skype did p2p well, back when most had an IP address, a physical network cable, and left their machine on (unlimited power). As NAT and mobile devices (that couldn't constantly be available for bouncing around a NAT and participating in a DHT). As a result Microsoft centralized it, so low power clients could connect as needed.
IPv4 basically turns a home computer into a consumer of internet services, even for silly things like using your cell phone to open your garage door requires a cloud service to be involved.
My main point is many traditional web services could be provided by the individual. You can share docs, communicate, and manage your increasingly complicated home environment easily with IPv6. Sure some would still use centralized services, but many more would do it yourself.
> - power/solar monitoring - you would need a server which would specifically handle the metric collection and make decisions upon this. Obviously cloud is cheaper than a separate box stationed in your house.
Except there is already a box stationed in your house, otherwise no data collection. Whether you might want to be able to use cloud-provided storage for reliability reasons would be a separate issue (which (a) could be completely application agnostic and (b) could just as well use your home server if you preferred that).
> Dropcams are usually a separate device which does not provide server capabilities per se - so require a box.
Or adding "server capabilities", whatever that is.
> but I am not going to start on how much you will be overpaying for every of the devices for them to have a separate fully-functional IP stack that is easily connected to a (W)LAN (wi-fi, ethernet, bluetooth - all of that is either expensive, bulky or power-hungry). So a box/cloud is always a solution.
How exactly do any of those connect to "the cloud" without a "fully-functional IP stack"?
>> Except there is already a box stationed in your house, otherwise no data collection. Whether you might want to be able to use cloud-provided storage for reliability reasons would be a separate issue (which (a) could be completely application agnostic and (b) could just as well use your home server if you preferred that).
Exactly the point I am making in my previous message. This tech is available independently from you using ipv4 or ipv6. You can still do all of this with ipv4 and the reason engineers would prefer to have the "cloud" method is because then they keep their clients on the platform and because most of their clients would not be setting their own server up anytime soon.
It is a business decision and not a technical one. You're making a point from a perspective of a geeky software engineer.
>> Or adding "server capabilities", whatever that is.
You can still do that with IPv4. My point stands.
>> How exactly do any of those connect to "the cloud" without a "fully-functional IP stack"?
For example, Philips Hue uses ZigBee to connect to "the box", which provides the HTTP interface; if they used wi-fi or bluetooth - the price for their lamps would go up by about ~$10 +-$2. So while you don't have to use "the cloud", you'd still need to have a separate piece of hardware that provides the ip connectivity. How does ipv6 solve the problem here?
Well, of course, it's also in part a business decision. But it's also in part a technical decision, because you cannot directly reach the home devices from outside the network, so you need a "cloud service" anyway if you want to allow the user to control their devices remotely (and you don't want to deal with the mess to set up that is port forwardings).
With IPv6, your device has a global address, so the user can just use a web browser to control the device from anywhere on the planet without any need for port forwarding, that is what IPv4 with NAT prevents.
Everything you upload to a cloud service still has to go through that uplink. As long as you are not transmitting it to more than one party, a cloud service does not change anything about the bandwidth you need.
Well, I don't use cloud services. But that does not mean that the only reason I use Spotify is because I don't have an external IP address at home. That's silly.
You could, for example, configure the firewall to give access to your IoT fridge, camera, baby monitor and toaster's web interfaces, all on port 80. With IPv4 NAT, you'd need to remember a port number for all but one of these services.
You can more easily accept an incoming connection, whether that's for gaming, video chat, P2P file sharing, etc. The computer knows its own address.
If the ISP is so short of IPv4 addresses that even the router only gets a private address (so, two layers of NAT), then without IPv6 there's no way to set up any type of server.
The IPv6 firewall user interface (my router calls it "pinholes") is simpler than the IPv4 port forwarding interface.
Most ISPs who support IPv6 don't give you a single address, but a whole range (e.g. BT in the UK give you a /56). If you give your internal devices an address in this range it means they are globally routable (obviously you will setup a firewall so the router doesn't allow arbitrary connections from the internet). If you have any devices you want to access externally, it means you can access them directly without worrying about NAT/port forwarding.
Of course for most users it's going to make no difference at the moment, but for those who need it, it is useful.
If you want to do inter-network connectivity, it's handy to have real IP connectivity instead of a manually configured port forwarding system. Sometimes it's nice to be able to access stuff running on your home Raspberry Pi from your 4G phone, or your friend's network, for example.
You might want to run apps that benefit from robust P2P connectivity, like VoIP or WebRTC apps.
You might use a VPN to connect to another network and get addressing conflicts.
You might need to VPN to somewhere that's also using 192.168.0.0. Or you might want to connect multiple computers to outside. E.g. my friends used to play an older game over the internet which worked great as long as each of us could forward the port (we just used each other's outside IP address as the address to connect to) but then as soon as two of us moved into the same house that stopped working, because obviously they couldn't both forward the same port.
Almost all popular apps started requesting IPv6 before IPv6 was broadly deployed, so they weren't actually using it. Then when IPv6 was deployed, it was less reliable because stuff was untested and suddenly there was intermittent breakage everywhere. So apps had to be updated to use happy eyeballs.
I once ticked "IPv6" when ordering a Debian VPS. It was super-slow and I didn't know IPv6 was the cause. Basically the system always tries IPv6 first, times out at 30s, then tries IPv4. I never completed an `apt-get update` and I assumed my provider had sold me crap. Years later, I discovered that disabling IPv6 did the trick.
So, my noob advice: If you ask for a guide about IPv6, it's not for you yet.
Actually, your provider did sell you crap. IPv6 will only be tried if your host has configured IPv6 connectivity and the destination host has IPv6 DNS entries. Debian mirrors generally support IPv6, so apt-get hanging probably means that the IPv6 connectivity of your provider was broken.
I just want to emphasize this a bit: IPv6 won't cause hangs even if the connection is IPv4 only if things are configured correctly.
(That said, I've seen incorrect configurations: Comcast, at one point, assigned me an IPv6 address (automatically) and led the system to believe that their was a valid IPv6 route, but proceeded to drop all IPv6 packets. This same scenario can happen on IPv4, too, and the resolution is the same: worm your way through the bowels of support until you reach someone competent.)
Mostly due to it being "mobile devices" - where every major platform has good support for IPv6, and the carriers need a massive amount of IP's - which are simply not available.
I just googled some IPv6 test tools and they all say "IPv6 not supported". Is there a way to find out why? If it's my settings, machine, my router, my provider...?
modern operating systems have ipv6 support out of the box. so it likely is your ISP or the router. Even if the ISP supports ipv6 they might only roll it out to new customers.
Beware though, some ISPs may switch to CGNAT via DS-Lite for IPv4 when they change you to a IPv6 setup.
Try running 'ip addr' in Linux or 'ipconfig' in Windows. Do you even have a IPv6 address assigned to any interface? If not, it is your router or ISP, most likely.
Your router's LAN switch might support IPv6, but it might not support it on its WAN/NAT side, or you might not have any public IPv6 addresses assigned by your ISP, or no tunneling configured, etc.
As much as I love and use IPv6 every day as my primary payload protocol (and have done so for 10+ years) - I find it dubious that, "The graph shows the percentage of users that access Google over IPv6." - Really, 20% of people are now connecting to Google over IPv6? If so, that's awesome and presumably a side effect of Comcast giving everyone IPv6 addresses.
What do you find dubious exactly? Why would Google lie about that? It doesn't sound that hard to believe, all it takes is a few big ISPs starting to enable IPv6 by default.
Google isn't even accessible in the biggest country with the most people on the internet. So the HN title is misleading, in that it isn't 20% worldwide.
You don't know that, even when you count in more Chinese people it could still not change the world average. The title is fine since it represents an extremely big sample on the most visited page on the Internet.
Fair enough, peaks isn't right,'reaches' maybe. Breaks just read wrong for me at first glance, I thought it was saying the usage of ipv6 was broken for 20% of users worldwide. That was obviously just a huge brain fail on my part.
A percentage can't double indefinitely. There is an upper bound. You'd need to look at the raw number of hosts supporting IPv6, rather than the percentage, to decide how fast it is doubling. I don't see the raw numbers on this site, so we can't say from this information.
Some countries seem to have not even started getting into IPv6: Spain, Italy, Russia. So I think it could accelerate again the day the ISP in those countries make the switch (if that ever happens).
The only major ISP that has tried to enable IPv6 is Orange. They did so by putting people in a DS-Lite connection. This is, CG-NAT for IPv4 and real IPv6 connectivity. Result: now everybody thinks "IPv6 sucks because it means I won't have an external IPv4 address". So they stopped the IPv6 programme.
The other two major ISPs also are ready. They just have to flip the switch.
That said... I bet most of the CPEs that are currently deployed have no IPv6 capability. The only ones that work with IPv6 are usually the fibre CPEs, which are more modern, by definition.
IPv6 is simply a failure, especially if you, as an ISP, can afford to buy all the IPv4 addresses you need. And that's what happens in Spain for the three major ISPs: they have all the IP addresses they need, so there is no need at all for them to switch to IPv6. In fact, they are using this as a weapon against the new ISPs: one of the three major ISPs mocked a smaller one for having their clients behind a CG-NAT, which is something they had to do that because they simply have no IPv4 addresses.
Our government forces the biggest ISP to share its last mile infrastructure with every ISP that wants to use it, so my question is, why doesn't the government force the big ISPs to share their IPv4 address pools?
IPv6 port forwarding likely just means allowing incoming connections in IPv6 firewall. Exposing internal machines with IPv4 uses NAT and is called "port forwarding". IPv6 doesn't need NAT but people still call it "port forwarding".
Yes ipv6 have nat and do port forwarding at least on linux, usefull scenario is when developing embedded devices and don't want make easily guess your isp how many devices have.
That's a phenomenally strange requirement. If you wanna run interference on your ISPs device count snoops, just create a bunch of fake interfaces, but why you would want to do that is beyond me.
All advertising companies (Google, FaceBook, Amazon) are pushing ipv6 hard for good reason: it allows them to [easily] see how many individual hosts a private network has and track them. I'm sure the NSA and other 3 letter agencies are delighted as well.
Absolutely false. All modern IPv6 implementations support privacy extensions and randomly generate new addresses periodically, so there is no practical advantage over NAT'ed IPv4.
There's a lot of cool things you can do when you don't have to worry about running out of IP addresses. A lot of complex stuff people are doing with cloud meshnets and overlay networks and bridged private networks with port forwarding and such becomes mostly moot if every VM and container can have as many dedicated real IPs as it needs to do its job.
It's also funny/weird to think about how much development effort has gone into stretching IPv4. NAT, port forwarding, SNI (and some hacky other SSL tricks before that to fit multiple SSL sites on one IP), masquerading, tunneling, VPNs, etc. The list is incredibly long and the hours spent on development unfathomable.