IPv6 Adoption
google.com
google.com
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.
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.)
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.
What does that have to do with any of the technologies you cited as being used for security purposes?
It's called a firewall, and you already have one when you use IPv4. The IPv6 one is much simpler, as there's no address translation (NAT).
Unless you don't. In any case that doesn't have anything to do with the technologies they cited, as a firewall was not listed among them.
a) Mask end-user addresses somehow. You wouldn't want everyone on your corporate network to get a globally unique, trackable ID.
b) Allow outgoing connections in arbitrary ways but forbid random incoming connections.
c) Some sort of central, highly secured network node where your admins can configure this stuff.
At this point you're close to reinventing NAT, except crappier.
Everyone on your corporate network has tons of globally unique, trackable IDs. They're called cookies.
Also, there are IPv6 privacy extensions.
> b) Allow outgoing connections in arbitrary ways but forbid random incoming connections.
Just as with IPv4?
> c) Some sort of central, highly secured network node where your admins can configure this stuff.
That's called a firewall. You need one with IPv4 as well.
> At this point you're close to reinventing NAT, except crappier.
None of that has anything to do with NAT.
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.
- 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.
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.
It's as trivial as not setting up a route for the address range at your inbound router.
Bonus: If you ever discover that you need to have some service globally routable, it's as easy as adding a route. Try that with your IPv4 NAT setup.
> 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.
[1]: https://f5.com/resources/white-papers/the-myth-of-network-ad...
[2]: https://blog.webernetz.net/2013/05/21/why-nat-has-nothing-to...
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.
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.
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...
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.
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.
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.
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!
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 does not provide security, really.
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.
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).
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.
Yeah, that's the only one where I can see a use for security purposes, but even then, that's not the only reason why it's used.
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.
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.
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
You mean how you can map from IPv4 addresses to IPv6 addresses? See RFC4291 section 2.5.5.
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?
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.
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.
Which would work how exactly in the case of IP? So far sounds mostly like "make it backwards compatible by making it backwards compatible".
> how exactly in the case of IP?
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)
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.
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.
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?
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.
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.
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 ...
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.
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.
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?
See the difference?
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.
I don't know why the former was deprecated, but I think almost no OS supported it so might've been just that.
Now some software use those addresses to store IPV4 addresses in the same memory as an IPV6 address.
Last-Modified: Sat, 02 Aug 2003 14:27:40 GMT
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?
NAT64 - October 2010
DNS64 - April 2011
464XLAT - April 2013
If your upstream provider doesn't support IPV6, you can't do anything to help that besides complain about it and hope they provide it one day.
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.
And according to Google's graph I'd say we're about 5 years away from reaching 40%.
So I don't think we're gonna see adoption in Western countries that soon.
Here's an IPv4 map for comparison: https://www.jessevaughn.com/images/ipv4_map_of_the_internet....
India, Japan, Brazil, and Australia also rank relatively high.
Keep in mind some of the largest US ISPs (like Comcast) are offering native dual stack now by default. You'd have to go out of your way to disable it.
Edit: Cell phone carriers are a big driver of this as well, both Tmobile and Verizon are majority IPv6 according to [0].
[0] https://en.wikipedia.org/wiki/IPv6_deployment#United_States
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?
Do you mean v6 tunnel brokers? That's a response to not supporting native v6, not running out of v4 space.
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.
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.
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.
rsync.net has been ipv6 accessible (the storage, not the website) for 7-8 years ...
It would be nice if providers that support IPv6-only networking would provide NAT64 gateways and DNS64 DNS servers.
https://aws.amazon.com/blogs/aws/now-available-ipv6-support-...
Or have outright broken IPv6, e.g. Digital Ocean's /124
$ host -t aaaa news.ycombinator.com.cdn.cloudflare.net.
news.ycombinator.com.cdn.cloudflare.net has no 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.
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.
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.
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.
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].
[1] n:1 NAT using RFC 1918 private addresses
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.
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.
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
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.
Just ban people without letting them know.
https://support.cloudflare.com/hc/en-us/articles/202494830-P...
At work, only parts of our network do IPv6, 5 years later. Enterprise stuff is slow to change. :(
[0] https://tools.ietf.org/html/rfc6333
Edit: On the other hand, if connections via IPv4 were spotty I would not hesitate to suggest problems with NAT or path MTU.
For most ISP's today, enabling IPv6 is just a matter of a lot of reconfiguration and then a bunch of testing.
Not really, UnityMedia Germany is also owned by Liberty Global and we have had IPv6 for years (since I moved here in 2013).
Also, that easily generates petabytes of logs, so it's not really cheap either.
This kinda stuff is clearly madness.
So only 65,535 customers can establish a connection to facebook.com from the same ip.
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.
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.
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.
https://en.m.wikipedia.org/wiki/List_of_countries_by_IPv4_ad...
This is a disaster. Half the world is not yet online. If we're going to change that, then we need to move to ipv6, and soon.
Why? ipv6 is so much better than ipv4 it's insane that we're even discussing this.
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.
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.
Yes, almost all of which has to be aware of which address family it's using in order to work.
Don't most higher level languages also just do this by default under the hood?
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.
- 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.
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.
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.
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.
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.
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.
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 ...
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.
What do you mean by that?
> 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?
They did. Every IPv4 address is in a reserved area of the IPv6 address space.
a.b.c.d # v4
::FFFF:a.b.c.d # v6
> 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 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.
> 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)
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.
* If you store IP addresses ensure that you can store IPv6 address if necessary.
* Rent servers only from IPv6 capable providers.
* When configuring DNS don't forget AAAA records.
* If you ban users by IP you might need to ban entire IPv6 subnets.
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.
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.
https://www.tablix.org/~avian/blog/archives/2017/04/ipv6_pro...
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?
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.
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.
Skype was popular before they had to ditch P2P, and most users aren't aware of the issue.
DropBox is first and foremost a backup service, and you always want backup to be off-premise.
[..]
Cloud services are awesome and we would all use them even if we could accept incoming connections.
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.
- 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.
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"?
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?
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.
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.
Of course for most users it's going to make no difference at the moment, but for those who need it, it is useful.
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.
The issues were generally around the OS prioritizing IPv6 over IPv4 which a lot of applications aren't ready for.
I know IPv6 is more secure, better, conditions your hair for you, but I am not excited to move IPv6 forward with our network.
If the application doesn't explicitly request IPv6, it doesn't get IPv6.
So, my noob advice: If you ask for a guide about IPv6, it's not for you yet.
(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.)
Beware though, some ISPs may switch to CGNAT via DS-Lite for IPv4 when they change you to a IPv6 setup.
Mods, please fix the title?
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.
As well as Verizon Wireless and T-Mobile wireless. Mobile usage is huge.
http://www.techrepublic.com/blog/10-things/10-things-you-sho...
Since it is such a low level issue and implies a lot of software and hardware, I would not be surprised to not see it progress fast enough.
https://cloud.google.com/compute/docs/load-balancing/ipv6 https://cloudplatform.googleblog.com/2010/07/app-engine-and-... https://cloudplatform.googleblog.com/2014/11/cloudsql-instan... https://googlecloudplatform.uservoice.com/forums/302595-comp...
Source (click on per country tab)
https://www.google.com/intl/en/ipv6/statistics.html#tab=per-country-ipv6-adoptionI thought 20% of IPv6 went down or something.
It used to double every ten to twelve months, the last two doublings took fifteen (IIRC) and nineteen months. 40% around October 2019, then?
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?
Years ago they used to put a modem instead of a router in every home, the modem had three ports with each of them being assigned a public ip address.