I've had IPv6 natively for 4+ years in San Francisco[0] on my residential cable connection. This appears to be one of the few things Comcast does right.
Without any extra effort the following sites (small sample from Alexa top 500) use IPv6:
* google.com
* youtube.com
* gmail.com
* facebook.com
* wikipedia.org
* netflix.com
Without IPv6 (no AAAA DNS records):
* reddit.com
* amazon.com
* twitter.com
* news.ycombinator.com
* imgur.com
* bing.com
* ebay.com
It's happening, slowly. ISPs who care are supporting it. A significant portion of my every day web traffic is over IPv6 and nobody has noticed. People on my local network are using it on Linux, Windows and Mac OS X and they don't even know what IPv6 is.
Google is clearly leading the IPv6 charge and has a statistics page[1] for those interested.
I don't think that's right at all. It might be true in the USA, but that's only like 3 providers, isn't it?
I'm in the UK and I don't have IPv6 on my mobile or at home. I travel to ROI often and my phone has never picked up on IPv6 address. I was in Italy a couple weeks ago and I never got an IPv6 address. I know I checked because a friend of mine keeps telling me bullshit like this about how real IPv6 is, and I've never had an IPv6 address.
I was in Spain at the beginning of the year and didn't get one; and Germany late last year: No IPv6.
Mobile networks use a lot of IPv6 internally, but that is invisible to the customer. Your IPv4 or v6 traffic in tunnelled inside IPv6 between nodes of the cellular network. That may be the cause of some confusion.
But are you roaming in those places? For reasons I don't understand fully but are presumably billing related your IP traffic gets tunnelled back to your home ISP when roaming, or at least, it used to.
In Germany, only Deutsche Telekom (and resellers such as Congstar) supports IPv6 on mobile (for both prepaid and postpaid). And it works great, even when tethering.
Since you're from the UK, I suppose you are a Vodafone customer and therefore roaming in the Vodafone network in Germany (which does not support IPv6 yet).
On some networks/devices you might have to enable IPv6 explicitly, by setting the APN to IPv4/IPv6.
In Singapore, Singtel seems to be the only provider that supports IPv6. Unfortunately only for postpaid plans.
Is that in the US? In my Eastern European country, IPv6 has not become directly available to mobile customers. One of our major ISPs began offering IPv6 addresses for fiber customers over half a decade ago; all the customer needs to do is set up PPPoE on the router and the connection automatically gets both IPv4 and a couple of IPv6 addresses. But if you add mobile internet to your contract with that ISP, that mobile connection still only provides an IPv4 address that I assume is NATed to hell. The same is true of internet connections through a large pan-European mobile provider here.
I don't think that Canadian ISPs are in on this. In particular, almost all Canadian mobile customers are on Bell, TELUS, and Rogers. I'm on TELUS right now and I fail test-IPv6.com. Telus and Bell actually share much of their mobile network so I'm not sure Bell would fare better. And I was on Rogers as recently as 6 months ago and they didn't have IPv6 either. And my home ISP, a small fibre ISP, doesn't have IPv6.
I'm on Fido/Rogers in Quebec/Ontario, and they have had IPv6 enabled for 1-2 years. Make sure that your APN settings enable IPv6 (in Android, there's an option for that).
Mobile is the main reason why Canada is >15% adoption on google-stats [1]. On DSL/cable, Rogers and Cogeco provide IPv6, as do smaller re-sellers such as Teksavvy on DSL, but otherwise big players such as Bell and Videotron have been dragging their feet and giving lame excuses.
I tried a few months ago and can enable IPv6 on my LG V20 (on Telus LTE) and it does indeed pick up an IPv6 address but test-ipv6.com complains of MTU problems.
Sites did load over v6 but it was slow compared to v4.
LTE or DSL? I'm on LTE in Vancouver and it fails (and has consistently in the last 6 months).
Are you in Calgary? Telus always rolls out experiments in Calgary first. For example, until recently their only deployed GPON networks have been in Calgary subdivisions.
You can see the remote address in Chrome's dev tool's network tab as well. Go to the network tab, pick the request for the page, and click on it, you'll see the remote address. If it's IPV6, you'll see the hex notation, like this: http://i.imgur.com/YK9vD53.jpg
We'll be having the same post 20 years from now. NAT, for all its problems, has more or less solved the IP address problem.
As a geek, one who has put the networking stack into the ETA-10 (yeah, I know, nobody knows that machine, CDC spinoff super computer) and SCO's unix (yeah, I know, it sucked), so as a geek who gets the stack pretty well, I've never warmed up to IPv6.
To me, it seems like it went too far. 64 bits not enough? Really? Unless I'm doing the math wrong 64 bits is enough for 2635249153 addresses for every human on the planet.
slovax ~/p bc
2^64
18446744073709551616
./(7*1000^3)
2635249153.38707880228571428571
So 128 bits is needed why? I get that people used to say that 16 bits would be enough and they were wrong and the 32 bit people were wrong. I just don't see how we run out of 64 bits in the next $BIG_PILE of years.
I don't get it. Seems over engineered. IPv4 works pretty well, seems like a slight improvement would have been enough.
> NAT, for all its problems, has more or less solved the IP address problem.
A bunch of very large-scale network operators (like Comcast, T-Mobile USA, Verizon, and Facebook) seem to strongly disagree with that, given how eagerly they've deployed IPv6 to get away from the hell that is IPv4 NAT and CGN.
Yes, IPv6 has lots of complexity/flaws/idiosyncrasies/weirdnesses (multicast, mobility, slaac, ndp, prettyprinting / the colons, extension headers, etc.) that mostly only look good through the rose-tinted glasses of the 90s and significantly slowed down deployment -- and in the end mostly ended up as "difference for difference's sake".
128 bits of addressing space and getting away from IPv4 NAT were unambiguously good. 128 bits is a lot, but memory/bandwidth is just going to get cheaper (for slow links you should use header-compression anyway), and it was better to go whole hog and skip 64 and go to 128 to avoid a future 64->128 transition. Given how the 32->128 transition is going, this seems like it was an excellent decision.
From an operator's perspective, 128 bits is more difficult to troubleshoot compared to the 32 bits of IPv4. RFC5962 makes things easier, though only marginally.
You can very easy end up with multilevel nat. The last mile (ie a apartment complex) can have one and then the customer router is the second.
But that assumes that the ISP has addresses to spare. If not, we have the three layers of nat. ISP->apartment complex->customer router->all customer devices.
And then we have intermediates, like ISP->municipal->apartment complex->customer router->customer devices. Now we have four layers of nat.
In the really worse case, ISP are split up into multiple ones, and you can get carrier grade NAT in the form of ISP->ISP->municipal->apartment complex->customer router->customer devices. Five layers of nat and up.
Multilevel NAT is a form of sadness that NAT never was designed to do.
NAT is also expensive to operate at the scale and reliability that large network operators need. If stateful NAT middleboxes go down, everything goes down -- it's a point of failure that's hard to route around!
Also there's the issue that you'll end up having multiple devices with the same RFC1918 addresses, which is an immense pain in the arse to deal with.
Of all the various reasons to define address lengths and wire formats (that'll get burned into billions of dollars of ASICs over decades), "C doesn't have a default type for it" is frankly the worst.
Which is a byte array. When you pass this to a function, it does not fit in a single register. The equality operator doesn't work, nor do other logical operators. Everything has to be defined. 64 bit would have been so easy. And it would still have been enough.
Edit: somebody replied and deleted their comment. Since I had written a response I am editing this comment.
> Then your real complaint... is that you don't have 128-bit machine registers
Agreed, although my real complaint is more towards IPv6, for not thinking about this real-life limitation.
> what the urgent need to pass IPv6 addresses in machine registers
It's much slower than IPv4 to deal with! 64 bit addresses wouldn't have had this problem and still would have enough space for everyone on earth.
> And how is it "irritating af"?
Apart from the speed concerns:
> The equality operator doesn't work, nor do other logical operators. Everything has to be defined.
So what? Didn't you notice that the 128 bits are split in half: {network|host}? Anything that needs to route things around is only concerned about the first 64 bits. Once you're hitting on the local scope the last 64 bits is what matters ~99.9% of the time. So you can have your efficient 64-bit comparison right there for most of the traffic.
> Everything has to be defined. 64 bit would have been so easy. And it would still have been enough
I agree. It sucks, 64 bits almost certainly would have worked and languages/libraries/OSes tend to not do their fair share at taking care of IPv6-related stuff. That, along with all the prettyprinting/parsing business with the colons is legitimately annoying.
However, IPv6 was designed not just to fix IPv4's sins, but to ensure that there'd never be an address exhaustion issue with IPv6, no matter how many decades it would be in use. That's why there's 128 bits of overkill; the IPv6 designers knew that the IPv4->IPv6 transition would be awful (they even underestimated just how awful it'd be), that IPv6 would keep running for a long time once it got deployed -- and wanted to do their best to avoid subjecting the world to a transition from IPv6.
> When you pass this to a function, it does not fit in a single register.
Depends on the architecture. On amd64 (the architecture I'm typing this comment on), a 128-bit struct, like defined above, will fit in registers — yes, in 64-bit registers. The amd64 ABI[1] will split them across two registers. For example, if we take the above struct and use it,
movabsq $578437695752307201, %rdi
xorl %esi, %esi
jmp bar
The nasty looking number is the initialization; it's easier to see in hex:
In [1]: hex(578437695752307201)
Out[1]: '0x807060504030201'
That ends up in %rdi, the first of the amd64 arg-passing registers. The next half is zeros, so it goes in %rsi (the compiler just zeros it). Then we "call" bar. (There is tail-call optimization here)
The non-optimized version is similar, but more drawn out:
# for some reason we zero it first
movq $0, -16(%rbp)
movq $0, -8(%rbp)
# then we init it again… okay gcc.
movb $1, -16(%rbp)
movb $2, -15(%rbp)
movb $3, -14(%rbp)
movb $4, -13(%rbp)
movb $5, -12(%rbp)
movb $6, -11(%rbp)
movb $7, -10(%rbp)
movb $8, -9(%rbp)
# move the struct into rdx/rax
movq -16(%rbp), %rdx
movq -8(%rbp), %rax
# just to move it into the arg-passing registers
movq %rdx, %rdi
movq %rax, %rsi
# call the function
call bar
> It's much slower than IPv4 to deal with! 64 bit addresses wouldn't have had this problem and still would have enough space for everyone on earth.
It's twice as wide, yes, but that doesn't necessarily mean you're needing to pass it in memory.
> still would have enough space for everyone on earth.
IP addresses aren't just numbers assigned to machines. They must also — effectively — encode the route to that machine; you can sort of imagine it as a tree, with each bit giving you successively more local directions on the Internet. Now, of course, that's not exactly how it works, but the point is that some parts of that tree are going to be sparsely populated. Having a wider address space means you can make bigger, but not necessarily full, allocations in the address space, allowing you to keep whole networks together in a common prefixes, which results in simpler routing tables. (At least, that's the idea as I understand it.)
And it's not just 1 per person: I have more than one device, and I move between networks during the course of a day. If all of the networks I frequented actually had IPv6, I'd bog down at least 6–8 IPv6 addresses during the course of a boring day, and that's not counting stuff like networking equipment.
It's not just a simple question of "are there enough bits to assign each person an address"
> The equality operator doesn't work, nor do other logical operators.
On amd64 at least, __int128_t exists, I believe, and I think it should come with operators. In higher-level languages, you can define < and == simply enough.
Now, I grant that the above is highly architecture specific, and there definitely exist architectures where this doesn't apply. And those, yes, 128-bit will be slower than a theoretical 64-bit. I just don't think it's worth worrying about.
> IP addresses aren't just numbers assigned to machines. They must also — effectively — encode the route to that machine; you can sort of imagine it as a tree, with each bit giving you successively more local directions on the Internet. Now, of course, that's not exactly how it works, but the point is that some parts of that tree are going to be sparsely populated. Having a wider address space means you can make bigger, but not necessarily full, allocations in the address space, allowing you to keep whole networks together in a common prefixes, which results in simpler routing tables. (At least, that's the idea as I understand it.)
Exactly, and the huge address space allows the standard to right out set some structure to it, with 48 bits for global routing, 16 bits for subnet addressing, plus 64 bits for link-local, interface identifier. Routing is only concerned about the first 64 bits (which has all the fast operations you could dream of) and global routing only the first 48 even. Obviously doing some work to match the topology to the address space in a smart way by leveraging CIDR to reduce the size of routing tables is always going to be useful.
* getting IPv6 provider-independent space is too hard
* extension headers are tricky, slow to parse, a source of tricky security issues, and thus are almost completely unused on the Internet in general
Basically almost all the moving parts in ipv6 (beyond the wire format and its 128-bit addresses) that aren't dangerously convoluted / mostly unused are pretty much just NIH'd reimplementations of the corresponding IPv4 protocols (like ARP, say).
Provider-independent space ought to be impossible - addresses should be addresses. If you want multiple routing paths to you, get an AS number and participate in actual global routing. Otherwise, accept that when you move your address will change.
NAT is pure evil. It adds huge complexity to anything wanting to do any kind of end-to-end or peer-to-peer connectivity, and it does not scale at carrier sizes very well. Even for regular client-server stuff it introduces performance and stability problems when you try to do it for millions of clients. Don't even get me started on the complexity it adds on the devops front. Layers and layers of cruft go away when everything can have an actual address.
It's a nasty hack to keep the net running until we can sunset IPv4. That's it.
64-bit IP would have been fine. If I were asked to extend IPv4 that's what I would do. I've ranted about the annoyance of 128-bit address lengths, but it's not a show stopper and it's something that could be fixed at the UI level and with better DNS management systems.
There are cool things about 128-bit addresses like SLAAC and cryptographically meaningful addressing.
We have IPv6. It works. It's getting deployed. There's absolutely nothing to be gained and a lot to be lost by bikeshedding about why 64-bit would have been veryveryslightly better. It's like arguing in 2017 about how PCs would be 0.5% faster if we were using the DEC Alpha instruction set instead of x86_64 or what the world would be like if Apple had stuck with PPC.
NAT has not solved the IP address problem, it has merely postponed it slightly. Multi-level NATs are a hell far beyond the single-level NATs that most consumers see (and single-level NATs already cause all sorts of problems for even moderately advanced network usage). So most people only have single-level NATs, which practically only extends the address space by a small multiple - 8 bits at most, in practice ~2-3 bits.
128 bits allows routing tables to be super small and fast. While RAM has gotten cheaper, it is still slow, and smaller routing tables are way more important than smaller addresses.
However, I agree with your central point - IPv4 was "good enough" that IPv6 is going to be a tougher battle than it ought to be. However, IPv6 is winning that battle already. 15% of google's users use IPv6, and it's increasing sigmoidally. [1]
It's only too big if you consider they would all be used. The large tracts of open unused space allow you to subdivide networks many times over - simplifying routing. If you just made the space bigger and expected to pack it very full, the routing would be very complex - worse than now.
Its amazing people still wanna bike-shed what is essentially a 20+ year old protocol at this point. Its time to give up on the nitpicking guys, ipv6 is the future regardless of if you like it or not.
You're right that ipv6 is the future. However that does not mean it is impossible to find flaws in it. For some people, having 128 bits instead of 64 is a flaw.
Its about as relevant at this point as arguing that traffic lights shouldn't be red and green, sure maybe, but its not a very useful discussion because its both a trivial aesthetic concern and never ever going to change.
But with WebAssembly, you'll not be locked into it, or into transpilers that produce it. Chances are, we'll see other reasonable languages being compiled to WebAssembly and getting mass adoption.
(WebAssembly is a stack machine with a bytecode interpreter, running in the browser, with code downloaded from the net. Java tried to be basically the same thing, only 25 years too early.)
Java also did it with 25x worse VM start times, 25x more security vulns, and a 25x more greedy and terrible company behind it (eventually). The legendary GC pause never helped. "Write once, run anywhere" then ironically becomes the specialty of Java...script.
Yeah I am really excited with Webassembly as the new JVM/CLR. But I was told this wasn't going to happen. As the downvote illustrates, there are many javascript militants who probably think we do not need any other language.
64 bits isn't enough for classful (pre-CIDR-style) routing. Remember that IP addresses aren't just arbitrary numbers, they're addresses. Note also that there's a fixed divide at 64 bits, so IPv6 is "really" only 64 bits of global routing, the last 64 bits are reserved for site-local routing.
> the last 64 bits are reserved for site-local routing.
No, the last 64 bits should never be involved in routing, /64 is the prefix length for a single ethernet segment. A site should by default have at least a /48.
Stop thinking about 64 bits as an address space that might get filled (like it did in IPv4). The 128 bit length of IPv6 allows them to be used differently - more like a UUID that can be randomly generated with low probability of collision (similar to Git hashes). This allows a number of features like self-assigning random IP addresses on private networks that would be infeasible with a smaller address space.
I was actually curious if it might not have been designed not for the number of addresses but for the average distance between any two addresses in use.
Won't this make scanning the address space nigh on untenable for the foreseeable future? The big thing is to retire IPv4 then.
Configuration systems for those typically do support symbolic prefixes for easy renumbering and deployment of sibling networks.
Also, most people dealing with rfc1918 networks would much rather get rid of addressing conflicts and other problems resulting from non-unique addresses, like security problems arising from ambiguous addressing. (Or don't know what they're missing...)
I remember 208.67.222.222 and 208.67.220.220 being someone who grew up in a country with DNS-level censorship way before Google announced their Public DNS.
Passing around an IP address in a single register. Today's CPUs are powerful enough to not need hardware forwarding chips to route up to 1Gbps of traffic easily, without much custom software optimisation. However that only holds true for IPv4 traffic. Throw in IPv6 traffic and suddenly each compare takes twice as much time in the CPU. Functions cannot pass addresses and masks in the registers, requiring stack juggling or worse, memory access.
> Throw in IPv6 traffic and suddenly each compare takes twice as much time in the CPU
So an operation responsible for less than 0.1% of the total time spent routing a packet now takes twice as much time... or it would if CPUs weren't superscalar for a long time now. That's paid back in tenfold just by the omission of the header checksum.
Depends on the ISA and optimization level - and the OS. Win32's x86-only __stdcall convention always passes arguments on the stack instead of in registers.
Ask yourself who benefits from this...slower networking on commodity hardware. Then look at who had the most influence over ipv6 in the IETF, etc. No big surprises.
Putting in 128 enables them to waste the address space the same way IPv4 was treated decades ago. "Oh, you want to hook up a classroom? Here's a /16 <-> /64". If address space is so plentiful the default home isp allocation is /64, there's something wrong here.
I can somewhat easily remember a bunch of IPv4 addresses. I'll probably never memorize an IPv6 one, unless it's one of the 0xface cafe babe 0000 ones. Which waste address space even more, see above.
If it is, then your ISP is incompetent. You should get a /48 by default, at the very least a /56.
> there's something wrong here.
Why?
> I'll probably never memorize an IPv6 one, unless it's one of the 0xface cafe babe 0000 ones. Which waste address space even more, see above.
Why would you want to? Except for a few special ones (routers and DNS servers, mostly), which you probably should configure to use easy to remember addresses, what's the point of remembering addresses when there is DNS?
> NAT, for all its problems, has more or less solved the IP address problem.
This is only kind of true if you can fit your network completely into the RFC1918 space (which many large companies, for example, can not). Again, given the aggressiveness many of the providers, like Verizon, have taken in their IPv6 roll-out, including internally, and given how much of a complete mess NAT is at scale (with CGN and statefulness), I am personally dubious that IPv4 has the capability to carry us much further forward.
It's interesting how his chart deflects somewhere around 80%, since at the 2017 Rocky Mountain IPv6 Summit that's about where T-Mobile US (who probably have the highest penetration of IPv6-capable endpoints of any ISP) noted their transition started slowing drastically.[0] The main reasons are that the remaining devices are old (e.g. 3G phones), have limited capabilities/needs (e.g. embedded IoT devices which just need to phone home once in a while), or are using odd configurations (e.g. for some reason T-Mobile doesn't currently support IPv6 for tethering).
Another good talk from that conference is about how Carrier Grade NATs are (amazingly) even worse in practice than they sound in theory[1]. During the Q&A portion one of the audience members points out that as technologies like CGN become required to provide IPv4 service it will cause the cost of supporting IPv4 to rise over time and naturally push ISPs to kill IPv4 as the use of v4 drops while the costs to support it do not.
I can also recommend a short talk by Cloudflare about their experience serving IPv6 traffic[2] and another on the history and future of IPv6[3].
I remember the first time I looked at my ip6 address and found my MAC in the host portion. Obvious and predictable as it might be to some folks, it surprised and annoyed me. With a unique MAC in every assigned ip6 address, it's pretty easy to imagine the tracking potential, e.g., a unique ID following a user where ever an ip6 address is assigned. Apparently Apple and even Network-Manager(Linux) automatically randomize/obscure the MAC for ip6 addresses - I don't know about Windows though. Using wicd in Linux, I must either randomize the MAC manually, or configure sysctl.conf accordingly. Otherwise, it's great, I suppose, that every atom in the known universe can have its own ip.
When my residential ISP started allocating IPv6 blocks, they published our postal codes in the whois database. In Canada, in a city, that postcode is basically a dozen buildings (one side of a street block), at least where I live. For a stalker, it's practically a full address.
We pressured the ISP to remove this information. They resisted, said it was policy, we read the RFCs and argued back. A few weeks later it was removed.
Similarly, most Linux distributions now enable IPv6 privacy extensions. Once people settle in their habits, it becomes more difficult to change this type of behaviour.
IPv6 is a big change. Adopt early, influence policy while you can :)
That was an issue for early IPv6 implementations. In most OS now, even link-local IPv6 addresses do not necessarily include MAC addresses.
However, public IPv6 addresses are obviously part of provisioned ranges. And without NAT, there's no ambiguity about assignment to devices. So in practice, with IPv6 you're sharing something as unique as a MAC with all peers.
One solution is using proxies with anonymously provisioned IPv6. Tor will eventually handle that. It's also possible for VPN services. FrootVPN, for example, does that already, whether you're connecting to their servers via IPv4 or IPv6.
Most OSes already support some form of using temporary random IPv6 addresses within your provisioned range, including so far as for each individual outgoing communication. Windows has supported it since Vista, IIRC, and defaulted to it since 7, I believe.
It's definitely still a problem if your ISP assigns you too small of an IPv6 range, and doesn't stop people from tracking you as your range, but it does as well, if not better, than NAT at stopping people tracking your individual devices.
To this I've added a DHCP script that randomly selects one of the /64's inside the /60 that my ISP allocates me, it runs on binding a lease after a given fraction of the DHCP lease time. Combined with privacy extensions, this keeps my address fairly unpredictable.
> Most OSes already support some form of using temporary random IPv6 addresses within your provisioned range, including so far as for each individual outgoing communication. ...
Yes. I'm planning to run a Tor exit relay that does something like that. It'll connect with directory servers and upstream relays on a stable IPv4 address, however. Changing the exit IPv6 will screw up bandwidth measurements. But it doesn't matter, because I don't want the relay used as anything but exit role.
After watching Windows, Python3, and IPv6 all go through decade long upgrade cycles, I'm hoping we've all learned some valuable lessons about the hidden costs of backward compatibility.
Alternatively, the computer industry forgot about backward compatibility and now has to relearn it.
Color TV was designed to be compatible with black&white. Stereo FM radio compatible with mono, stereo vinyl records with mono. Electricity changes very, very slowly.
When computers become such an essential part of every day life, you cannot make radical changes any more every couple of years.
If your design becomes successful, you may be stuck with it for a couple of decades.
The failure of IPv6 is also the success of IPv4 engineering. When IPv6 was designed in the mid 90s, there were many issues that might hold back IPv4 down the road.
It is only in the last couple of years, that issues (related to the IPv4 address shortage) pop up that basically cannot be solved anymore and make IPv6 an attractive alternative.
> The failure of IPv6 is also the success of IPv4 engineering. When IPv6 was designed in the mid 90s, there were many issues that might hold back IPv4 down the road.
Another big part of it is that all of the features of IPv6 except the address length change were back-ported to IPv4 (e.g. address auto-assignment and IPsec) removing the carrots and leaving only the "stick" of the IPv4 address shortage (which barely registered at all until a few years ago) to push people to v6.
I don't get it. Those long upgrade cycles happened specifically because the new version was not backwards compatible with the old. That's not a cost of backwards compatibility, it's a benefit.
We've not been using IPv6 long enough yet to tell. For all we know today, how many man-hours might get saved just from not having to deal with NAT? How many engineers won't need to learn that STUN and TURN were things? What new apps might get built if real and easy peer-to-peer is possible? We haven't had time to realize the gains.
On Python 3, I'm okay with having more discussions about some line thats failing at a byte/unicode boundary, instead of the "your entire design ignored the unicode/byte distinction, but mostly worked until now, and you've unwittingly built a mountain of technical debt." The language, going forward, encourages the correct behavior. Now if only my co-workers would stop working on that mountain long enough to switch to it…
DJ Bernstein of qmail and crypto fame etc. wrote about this in detail, ten years ago: ``The IPv6 mess''[0]
Designing around an incremental upgrade strategy is hard. It's a very important design constraint for an upgrade though!
The extra, wastefully spent bits in IPv6 make it super expensive to implement routing tables. Compare that approach to the 2^48 effective limit in the 2^64 bit address space in AMD64. Like IPv6, AMD64 is an upgrade from a 32-bit system - but AMD64 included support for the previous 32-bit version and won its war long ago, while IPv6 is still reluctantly limping along.
Upgrades of huge interconnected systems need to be incremental. As a human, invested in the process, it's hard to accept that: the point of the upgrade is to replace the old system :)
For IPv4, wouldn't that be forward compatibility? If they had designed the protocol to support different addressing schemes from the beginning, then we could have transitioned in place.
Additionally, Windows seems to be doing pretty well in backward compatibility. IMHO, its major source of issues.
Yeah, I got pretty happy with my dual wan setup with Tomato (240/20MB DOCSIS & 90/30MB VDSL) but had to disable IPV6 PD from the DOCSIS provider so the balancing and failover works properly.
>With IPv4 the router will just fix up NAT. With IPv6 you now have to deal with significantly more complexity.
How so?
In a multihomed environment, you'd still be PAT'ing to unique addresses on the WAN side (unless a FHRP is in use, which would be rare) - if one of those links go down, so too does all of the flows associated with address of the link. If no dynamic routing protocol or redirects are in use, the gateway with the down link will also eat half (assuming two gateways) of all egress traffic.
IPv6 should be easier as no NAT/PAT is in use, therefore you have no challenges with statefulness or routing symmetry.
It SHOULD be easier. It's not on current widely available prosumer hardware.
Yes, your connections will get temporary eaten. But for the typical developers workload that won't be a huge issue because most connections you do are short-lived. Configuring all your clients to properly switch vs. configuring your NAT router (with builtin functionality for exactly that) is orders of magnitude more complex.
* add another entry to the global routing table thus nullifying a benefit of IPv6
* cost a bloody fortune (approx £5,000 per year)
* is your mum able to ask for BGP peering
I am personally able to pay the price for PI but not everyone is and that is my fucking point. Why should your mum not be able to ask for a internet connection that is able to tolerate a failure?
There is NPT but it is simply NAT via another name.
I've been running IPv6 at home for quite a long time. I passed the WAF at least two years ago.
I haven't tried it myself, but I guess one option would be to use DHCPv6 with low lifetime timers? That way router could stop advertising the prefix from upstream that no longer works.
I have switched to IPv6 at home for a few years now. I love it. I wish my work supported IPv6. The ability to have multiple VMs be able to have incoming connections is great. No more having to do wired ports for NATing reasons although an IPv6 firewall is a must.
I'm not super familiar with the development in the low level network space, but I really wonder what the plan for IPv6 is.
IPv6 has been the future of IP networking for decades. Yet here we are and I still often surf the Internet without v6 connectivity.
It suffers from a fundamental problem: As long as IPv6 is not universally available nobody has a real advantage from supporting it. But as long as it provides no advantage many ISPs and web server operators won't bother supporting it.
I think this is a design flaw. IPv6 was built without a plausible transition plan. The plan "over time more and more people will switch to v6 and at some point everyone will have it" clearly doesn't work and will never work.
There was a time when running out of IPv4 addresses meant that ISPs and other providers _had_ to switch to IPv6, or they would run out of addresses (or spend too much acquiring them). With NAT and stuff, that risk has seemed to decrease significantly.
Google statistics show that nearly 20% of their traffic is over v6, which is honestly not bad. The USA itself is 35%, with no latency hit.
> This is totally bad. We need close to a 100% for v6 to make any sense.
Considering how it was 2% not many years ago, this is a huge improvement.
What's going to drive this further is that the cost of supporting IPv4 will increase more and more as IP-space is exhausted and ISPs will have to apply new hacks like CGN.
At that point getting people to IPv6 and IPv6-only will be a purely be about economics.
I guess we will get there. But possibly in 10y. My home broadband in the UK is BT and they just switched on IPv6. Right now it is very unstable. Sometimes I am IPv6 enabled, sometimes not. IPv6 connectivity usually lags behind IPv4 (ie assignment of an IPv6 address is delayed by a few minutes). So it's all hacky and unreliable but it is making some slow progress.
Have we figured out good ways to gracefully handle prefix changes via DHCP6-PD. I'm kind of worried of my provider changing my prefix "from under my feet" and breaking firewall rules, or worse.
Also my ISP blocks some ports incoming lst time I checked, even on IPv6, even on their business plans, without a static IP. And I assume they would do the same with v6 because they don't support static prefixes themselves.
To be fair their IPv4s are very static and only change when I change my WAN MAC address or am offline for longer than a DHCP lease (power outage)
boy world war 2 really put a dent in clothes washer adoption. That aside, it feels like the adoption sort of resembles 64 bit windows adoptions. took a while but it happened bit by bit
With Neftlix and Youtube using IPv6, the majority of traffic of an average household may as well be on IPv6 already, where available at the last-mile level.
We're measuring 'eyeballs' based on google advert placement. And, China is notoriously hard to measure because of the GFC but that said, my contacts inside China confirm that globally routable IPv6 deployment inside China is stalled at a very low level, except for in CERNet, the academic network. This may change soon, it depends.
The #1 mistake IETF did was not making IPv6 compatible with IPv4. It's hard to comprehend for most, bug essentially we're building a whole new separate Internet. The old Internet, or the Internet Classic (v4) and the New Internet - The v6 Internet. IPv6 is a totally new protocol - new L2 interaction with Neighbor Discovery (i.e. has no concept of default gateway), new routing tables, new route-maps, nes access lists, new BFD,... Therefore new topology, new routing behavior, new resiliency and redundancy mechanisms... Just because hardware allows running v4 and v6 stacks side by side, it doesn't make them compatible, just easier to implement by not having to buy new hardware for both.
This gets suggested and rehashed on every single IPv6 comment section. There is no way to make IPv6 compatible with IPv4: by the Pigeonhole principle, there is simply no way to reference 2 ^ 128 objects using only 32-bits. The next usual hack is to "add an option" or something; but all the routing hardware would need to understand that option, which entails upgrading the entire Internet, which is exactly what IPv6 is doing/has done, except that adding an option ends up with a worse design.
Any suggestion needs to fulfill a. any machine should be reachable and b. you can't upgrade everything, or you may as well just go with what we've got.
I don't think even many of the IPv6 designers would agree with you. Originally, IPv6 was supposed to bring a large set of improvements, like first-class encryption, larger minimum packet sizes, stateless addressing and auto-configured routing. It wasn't just more bits.
In the end either all those things were backported to IPv4 or turned out to be bad ideas. IPv6 ended up being just more bits, but with a fully incompatible implementation.
If they had known this at the beginning, we could have transitioned to IPv6 long ago, by designing for a smooth transition period and reusing as much of the IPv4 stack as possible.
An end-to-end extension header would have been simple - something that can fallback to NAT connection tracking when it's not recognised. And it would have saved man-centuries of effort.
You cannot make it fully and magically compatible. 128 bits do not fit in 32 bits. They did make it compatible in a whole bunch of ways, like making v4 addresses a subset of v6, and tunnelling v6 through v4, but that seems to have just caused trouble and confused things.
I have to disagree with you there, making it compatible would have meant carrying legacy work flows. With a greenfield development they could engineer purely with an eye to the future.
Coding for a mix of paths creates a 3 way test problem. You have to test purely legacy, the mix of legacy and new and then just the new. You suddenly have to start coding for runtime depended details.
I completely agree. I think the whole move from v4 to v6 should be a case study in exactly how industry-wide technology migrations should not be done.
The only thing that was the critical flaw in v4 was lack of address space. Yes, there are obviously a lot of other issues with v4, but instead of just fixing that one critical flaw, v6 suffered from classic scope creep, put in the kitchen sink, in a way incompatible with v4, and 2 decades later we're still 5 years away.
Have a poke around on the internal interfaces you can find. I don't think I ever got a loud announcement from Comcast that they were going to support IPv6; from my perspective as a customer and not someone who reads HN, it just sort of happened one day.
My ISP supports IPv6... if you configure a second, PPPoEv6 connection on your router. Which as far as I can tell none of the top routers on the market here support. Heck even OS X doesn't seem to support it.
There is no such thing, it's still PPPoE and PPP, just that there is IPV6CP and IPv6 on top of PPP. And that, in principle, can run through the same PPP session as IPCP and IPv4, though a weird ISP might not support that, obviously.
I don't think we will see IPv6 eliminating IPv4 within the next 10 years. As long as IPv6 is used in parallel there is really no advantage since IPv4 depletion is still an issue and you need to use both. Since switching and routing IPv6 is more expensive the current hardware in use won't even be able to handle all the load and until every switch and router (at home and in the datacenter) is replaced 10 years will go by in no-time.
Also, most people who ask for IPv6 for their VMs or whatever don't even have any use for it. IPv6 will be a huge mess, if I only think about sending emails via IPv6, how should that even work properly?
> Since switching and routing IPv6 is more expensive
This was true for the first generation of products which weren't designed with v6 in mind. I don't think it's necessarily true anymore. The fixed length fields and much easier routing tables should lead to less complex hardware. (Not that it matters since everyone is dual stacked for the forseeable future.)
Email works fine technically for sure. But what about handling things like spam? How are projects like spamhaus supposed to work with nearly infinite IPv6 addresses?
This is extremely hard with IPv4 already, it will be a huge mess with IPv6.
IPv6 blacklists seem to be based on /64 prefixes rather than individual addresses. That hit me when I was enabling an IPv6 MX on a VPS; I had to get my own /64 prefix rather than use the standard default single address, since the default lied within a spammer-contaminated /64 block.
I know it seems rather excessive to use an entire /64 and only populate a few addresses, but I'd rather have too many addresses available than too few.
Blocking a /64 is not even enough in many cases. I know a couple of server providers handing out a /48 per server. If routing is done the right way, you can pretty easily randomize your source address by making use of features like AnyIP and add a whole prefix to your network interface. I have written a small tool to demonstrate this: https://github.com/blechschmidt/freebind
Solutions to this problem that try to avoid penalizing other users sharing a prefix will certainly be interesting. Some approaches ban per /128 and extend this ban to a /64 if two or three addresses within the /64 got banned.
But how do you know you should use a /64 mask? One of my hosting providers assigns much smaller subnets. Some others assign /56. You are at risk of blocking many legitimate IPs and missing many others.
> But how do you know you should use a /64 mask? One of my hosting providers assigns much smaller subnets.
It's baked into the standard that IPv6 networks shouldn't be smaller than /64. If a provider is disregarding the standard so blatantly I would probably avoid them.
Really, why on earth would a cloud provider be so stingy with IPv6 that they'd give less than a /64 per customer? ARIN gives out /32s like candy and a single /32 can be split into ~4.3 billion /64s.
Sadly the ISP for internet to our office building only gave out a /65... that we are meant to share with ~20 companies.
Suffice to say I've got IPv6 to the internet gateway, but no further. => They fulfilled their contractual obligation to "provide ipv6 connectivity", while being entirely useless.
They'll probably use us as a stat to prove that no one wants ipv6 anyway...
But why /65 is such a big deal? You can divide it in 32 different /70 subnets, one per company. That still leave you with 2^58 IPs by company. You can still even use MAC addresses in your IPs.
SLAAC on ethernet requires a /64. A provider assigning you anything but at least a /48 is pure incompetence, if it's explicitly for 20 companies, they really should be giving out a /43.
Also, no, it's not really just a minor problem. Reconfiguring your one client device might be trivial, but that's really not the question.
The question is what you do with a setup with a few dozen devices/machines/routers/whatever.
First of all, even if you do a new setup, it's idiotic that you'd have to consider the idiosyncrasies of your ISP when designing your network, instead of choosing whatever setup fits your internal requirements best. That you possibly cannot buy a certain printer because it doesn't support DHCPv6, or whatever.
But it's a lot worse when you think about switching ISPs with an existing setup: Having to completely rebuild your network because of your ISP's idiocy is ... well, idiotic. Suppose you have a bunch of routers that do SLAAC for end devices and obtain prefixes via DHCP-PD from the uplink router. Really, all that should be technically required in such a setup to switch from one provider to another would be to unplug the old line, plug in the new line, everything should renumber automatically, while keeping the exact same network structure. Good luck reconfiguring all of that to work with a /65 ... and when you have done that, tell me again that it's a minor problem.
You don't need to set up your clients with IPv6 more than you need with IPv4. Your router will do DHCP in just the same way. To me this is only a minor inconvenience.
You might as well be saying that electrical installation is trivial, as it's just a plug you need to plug into the wall.
All the stuff that I've been talking about is what is required so that in the end, you can just plug in your laptop and have IPv6 connectivity without any manual intervention on your part. Yeah, that's how it is supposed to be. But that depends, among other things, on the ISP providing a reasonably sized prefix.
Also, there is more to networks than "the router" and "clients". You can have more than one router, you can have servers, you can have routers with multiple interfaces that are isolated from one another ... not everything is "my home DSL router with built-in WiFi access point, used by one smartphone, one tablet, and one laptop".
And I think you might be confusing SLAAC with DHCP? Those are two completely distinct mechanisms, and you don't need DHCP in IPv6 networks at all, in particular not for client systems.
Completely eliminated - of course not. There will be the odd medical device, a couple labs, or "grandma" with old hardware.
However practically eliminated is possible, even likely. ISPs are moving that way, we are out of IPv4 addresses and all. Eventually penetration will be large enough that some smaller servers will decide that having an ipv4 presence isn't worth it. Probably because the ipv4 static address costs money and ipv6 is cheaper.
Without any extra effort the following sites (small sample from Alexa top 500) use IPv6:
* google.com
* youtube.com
* gmail.com
* facebook.com
* wikipedia.org
* netflix.com
Without IPv6 (no AAAA DNS records):
* reddit.com
* amazon.com
* twitter.com
* news.ycombinator.com
* imgur.com
* bing.com
* ebay.com
It's happening, slowly. ISPs who care are supporting it. A significant portion of my every day web traffic is over IPv6 and nobody has noticed. People on my local network are using it on Linux, Windows and Mac OS X and they don't even know what IPv6 is.
Google is clearly leading the IPv6 charge and has a statistics page[1] for those interested.
[0] https://blog.kylemanna.com/ipv6/comcast-automatically-enabli...
[1] https://www.google.com/intl/en/ipv6/statistics.html