A brand new UK ISP, YouFibre, is providing FttP in many UK cities. It's incredible being able to get a symmetric 1 Gbit connection for £30 pcm.
It's also incredible that, despite putting all their users behind CGNAT, they don't provide IPv6.
I mean technically they are no _worse_ than their major competition here (Virgin Media which has failed to move on IPv6 for 20 years, why start now). But it's baffling that a _new_ network would be built without IPv6 provision!
This behavior was rare in the US market, but it is very common now that our wireless providers are entering the home internet market. T-Mobile and Verizon both use CGNAT (but do issue individual ipv6 addresses to end user devices).
It's been a nightmare for my org. We have several people with T-Mobile and Verizon home internet and it's always a game of "What shenanigans will I have to use this week to get VPNs to work?" Sometimes it seems like their 6to4 implementation is just broken but I'm not a network engineer.
I don't know how it works in the UK, but here in France there are many commercial ISPs that cannot provide IPv6 because the underlying infrastructure does not support it.
Yes, ideally, an infrastructure provider should not dictate what kind of IP packets the commercial ISP can use, and there are dozens of technologies that would allow them to provide transports that don't care about the routing layer, but in practice, these providers (that we never really hear about as end-users) often make very bizarre choices, for example setting up a complex DHCP interception schemes that feed both the OLT to "open the port" and a BGP route server to announce connected clients at the collection point, of course not supporting IPv6.
In one of the ISPs I work for, we literally have /48s assigned to all of our clients, but the infrastructure provider's doesn't route them to us : IPv6 traffic is rejected at both ends of the transport. The ticket has been open for years (IPv6 was supposed to be part of the network they were commissioned to build), and insiders told me that they had difficulties adapting their transport system for IPv6.
We may end up having to tunnel IPv6 through IPv4 to our clients, but we try to fight against that so that the infrastructure provider doesn't declare the problem "fixed" and decide that the proper way for ISPs to provide IPv6 is to tunnel it through IPv4 so that they don't have to change anything.
Luckily here in Italy the company that was given govt money to connect rural areas with fiber provides simple L2 transport so ISPs are free to provide a fully working dual stack IPv6
IPv6 is pretty great. You don’t run out of numbers locally, you don’t run out of numbers globally. Most software and OSs just support it these days… many embedded things still don’t.
I think the biggest pain point with IPv6 adoption is probably the large number of customers with a little netgear router that doesn’t know how to pass IPv6 through it. I also think local administrators that still purchase stuff that doesn’t support IPv6 are just shooting themselves in the foot. After all, the writing has been on the wall for over two decades.
Anything as large and hodgepodge as the Internet isn’t going to change in a day. I’d say that the writing has been kept fresh [1] and the underlying need hasn’t gone away.
Biggest pain point in adoption are lazy ISPs who actively resist the transition. Once it's mandated, like in India or China, transition happens very quickly.
I don't think it's lazy ISPs, I think it's economics. I think it's that the cost/benefit ratio of making the change isn't clearly favorable to making the change.
The IPv6 spec was published in 1998. 25 years on it should be nearly flawless. Not “most software,” all software including firewalls should support it with safe and sensible defaults.
The current state of support and adoption is frankly abysmal. The attack surface is non-negligable. And there is no end in sight.
The idea of deploying a new version of the internet protocol (which lacks backwards compatibility for reasons) in parallel to the existing version should never have left the drafting table.
I agree it should be better but you’re talking roughly half of Google’s total traffic now, and it’s really common for people to be using it without even realizing that so I’m not sure I’d call it abysmal in the context of a large distributed system operated by millions of independent organizations around the world.
Phone carriers are responsible for a lot because they had nowhere near enough IPv4 capacity to handle all of the phones & other devices, but it’s not just them. A lot of people use IPv6 but never realize it because the experience is so smooth — all browsers use Happy Eyeballs and it tends to pick IPv6 because it’s often faster. I know that because I semi-regularly get support requests from developers wondering why they couldn’t access an IP-restricted service because they didn’t even realize that their browser had picked the IPv6 record because it responded faster.
I’m not sure there’s a better option: too many network operators are asleep at the switch and you’ll find networks where IPv6 works but v4 is subtly broken or vice versa. Asking nicely won’t get the stragglers to upgrade so what we probably need are economic incentives: as IPv6 becomes more common, providers charging for IPv4 is a good prod.
The most important thing is probably just pushing equipment vendors to set better defaults since that’s what a disturbing number of places will be using.
I'm not sure we ever really hit that bar (beyond adoption) with IPv4 either. A surprising amount of things don't really do it right and definitely not securely.
This sounds like and A/B problem. You’re asking how to do A but what you really want is B. But you’re asking about A because that’s how you think you’d get B in the ipv4 world.
Your ISP should give your router a /56 prefix via PD, which you can divvy up into 256 networks internally. Alternatively, if you don’t need globally-routable addresses, just pick a ULA prefix and have your router advertise it internally.
ISPs should do a lot of things, but when it comes to IPv6 many don't. Mine gives me a new prefix every time my router boots. Meanwhile I've had my DHCP allocated IPv4 for 3 years now...
Given that the IPv6 standard was written by enterprise network people with no thought how it would get deployed to the masses, lots of software is still a PITA to work with if you got an ISP like mine.
It's not that obscure. It's common to be given a /64 to a home, or even to small business premises. Some even get a /128.
So it's reasonable to wonder how people deal with that problem when needing multiple subnets. Many locations don't have a realistic choice of affordable providers, or none of them provide IPv6 with a shorter prefix anyway.
There's no technical reason why you can't if you use active DHCPv6 and other such tricks. They make life harder than standard IPv6, but there's no reason why you can't turn one of your /64s into /120s. With a /56 being the standardised assignment for ISP customers (=256 subnets), I think there's more than enough space for a home network. /48s used to be the recommended space assignment but I think these days you can only get those as a business customer or through an independent party (i.e. Tunnelbroker).
IPv6 subnets are supposed to be super cheap. As an individual, through a RIPE LIR, I was able to get a /44 (2^20 /64 subnets), no questions asked. I have these tunneled into my home lab and a couple other locations. I realize my setup is unusual: I have my own ASN and am running BGP.
If you work with a RIPE LIR, they may be more than willing to help you, even if you are outside of Europe. You just need a "presence" in Europe, which can be virtual (a VPS counts.)
I am in the ARIN region but I did not want to pay the ARIN registration fees for an ASN. It was $550 + $150/year, so I went with a RIPE LIR.
It answers the question posed by the parent comment. You asked how using a larger subnet hurts. I provided an example of how using a larger subnet might hurt. How is that irrelevant?
Based on the way IPv6 is currently allocated we only leverage about 56 bits of usable address space but IPv4 with NAT gives us a max of 96 bits of address space
Edit: don't know why I'm being downvoted, I guess the network gurus here don't research
I think the point is that 96 is quite enough to not run out. Which is plausibly fair, if you can actually get that many bits (or close enough to actually cover everyone) and can deal with the ugliness of NAT. It's especially fair, I think, to argue that the reason that IPv6 adoption has been so slow is because IPv4+NAT is good enough for most people. Just because IPv6 is better doesn't mean that people will want it if the old option can be hacked up to keep working.
Oh, sure; arguing that IPv6 doesn't, in any way shape or form, have enough addresses would be extremely misguided. I was reading it as "IPv4 already has enough address space (if we include NAT) so we don't need to deal with v6".
FYI: After skimming the article, I'm downvoting because you conflated what the article calls "This 96-bit NAT address space is a highly theoretic ceiling, […]" became a plain unqualified "96 bits of address space" in your comment. Which you're then comparing with the "56 bits of usable address space" in IPv6.
Also, that sentence continues in the article with: "[…] but the pragmatic question is how much of this space can be exploited in a cost-effective manner such that the marginal cost of exploitation is lower than the cost of an IPv6 deployment."
You probably need some amount of CGNAT or equivalent (e.g. DS-Lite). But if you offload the vast majority of your traffic onto v6 (which is easier than it sounds, because most traffic is to a few big sites and most of them are v6-enabled) then you can reduce the number of connections you have to track by orders of magnitude, which saves you real money.
Yeah I remember seeing that in a talk about an ISP adding IPv6 support: https://youtu.be/75h4gm7t1oI . They say that 30% of traffic is IPv6, which means 30% less CGNAT hardware needed.
Does it? If you pretend IPv6 doesn't exist, sure, but that's like pretending UDP doesn't exist because all of your applications use TCP, or only logging traffic going to port 80 because you don't have HTTPS yet.
Every firewall I've come across has a default deny rule for incoming IPv6 traffic, giving the firewall the same properties as any IPv4 network. Host firewalls are the same; anything ranging from Windows Firewall to UFW and firewalld have presets to block all traffic except for the applications you've whitelisted. Once you get to huge enterprise routers managing routable IPv4 addresses and IPv6 addresses the situation may become different, but it's still not that much overhead.
The biggest problem with securing IPv6 seems to be ignoring it assuming that makes it disappear. If you configure your firewall to drop all IPv4 traffic not on a whitelist but somehow manage to forget to add the same rule for IPv6, you should re-evaluate your networking knowledge and maybe get up to speed with how the internet has changed since 2015.
Its also all kinds of code that interacts with the internet in all kinds of ways. Extending all that code to two kinds of IPs, writing tests, setting up two types of IPs in development, staging and production, monitoring real life implications ... that would be a huge cost with no benefit at all.
If you're writing code, you'll be either manually specifying the IP address family (so there's no real IPv6 risk) or you're probably using middleware that does all the hard parts for you anyway. If anything, I'm annoyed how hard it is to get a socket listening on both IPv4 and IPv6 in many low level libraries. I just want a socket to receive data on, who cares what address family it's from.
In my experience, IPv6 Just Works (tm) with modern software. There are some mid 00's frameworks for blacklisting abusive hosts that can't parse IPv6 addresses, or don't understand the /64 subnet you need to treat as a single IP address, but that's all I've ever run into. If anything, that gave me an excuse to finally get rid of an old Perl network filter running on my server.
I'm not sure how many tests the average piece of software needs that deals with the type of address family connecting. I suppose it matters if you want to test your rate limiting middleware or your logging library? That should only matter for the vendored code of course because modern libraries all have those tests themselves already. It's not like you need to run and write every test twice, only one or two very specific subcomponents if any.
If you're writing firewalls or kernels or router firmware then yeah you'll have your hands full with this stuff, but that's far from the standard developer experience. In those cases, IPv6 is a reality as much as TCP and UDP are.
To add a trivial example: if an application is coded well, it’s ready to connect to hosts both on ipv4 and ipv6, in the sense that when resolving a dns name, it will ask for addresses of any kind (unless it supports being explicitly told to only use ipv4).
So now you’re getting a record with multiple ip addresses, some of which are ipv6, but ipv6 is blocked… there you go with random connection delays and possibly timeouts.
Ipv6 exists and it’s getting more and more adoption, no matter if some people keep their head under the sand…
Including the case where you have something else in the middle already - for example, if you're fronting a website through cloudflare, then you can only have IPv6 on your server and still support dual-stack for clients:)
> but that's like pretending UDP doesn't exist because all of your applications use TCP, or only logging traffic going to port 80 because you don't have HTTPS yet.
In fairness, neither of those things would be unreasonable stances, given those conditions.
It does take more work to run dual stack. I wanted to avoid duplicating efforts when I set out to learn ipv6, so I disabled ipv4 routing on my network and just ran ipv6 with DNS64/NAT64 to provide my clients access to legacy services. In this configuration, most of my traffic was end-to-end ipv6. I tested iOS, Android, Windows, and Ubuntu clients with no issues, even my aging printers support it!
The only issue I have is the same issue found in the article, but in reverse: now that I have a securely configured ipv6 network, how can I ensure that my hosts are fully prevented from communicating over a rogue ipv4 net?
I have an example from my ISP. While it theoretically started with IPv6 all the way back in around 2012, their IPv6 infrastructure still remains quite crippled -- they won't even assign you static prefixes, all you get is a DHCPv6 /56 (meaning you can't set a PTR).
And the example revolves exactly around filtering and firewalls -- on IPv4 they drop outgoing packets whose source address isn't a part of their subnet -- they prevent source spoofing of other addresses.
But on IPv6 they do not do that. I noticed this when their router somehow lost the prefix route to me -- I was informed that their DHCP server adds router dynamically to routers -- and I could still send packets. But I couldn't just send packets from my prefix, but also from any other address, including stuff like 2000::.
Delegating relay:
A delegating relay acts as an intermediate device, forwarding
DHCPv6 messages containing IA_PD and IAPREFIX options between the
client and server. The delegating relay does not implement a
DHCPv6 server function. The delegating relay is also responsible
for routing traffic for the delegated prefixes.
It's generally done by having the relay be a passive observer of the DHCPv6-PD packets it is relaying between client and server, installing and updating routes for prefixes as needed.
That RFC also goes into detail on problems with these setups. What you experienced was probably the loss of state described in section 3.2.
That's pretty silly. I wouldn't have much faith in my ISP if they'd mess up that badly.
Perhaps the good network engineer that got IPv4 working right left before they could implement IPv6? Or maybe they don't provide enough of a training budget for their engineers to stay up to date on networking technology?
Either way, if their core business is doing networking, I'd expect them to be better at this!
I think that's what my ISP (spectrum) does, which has thus prevented me from enabling IPV6 on my router. It works for a little bit, then just stops. Support won't help since I want to use my own hardware.
The IPv6 Buzz podcast had a recent episode[0] making the claim that IPv6 is happening on your network whether you intentionally enable/control it or not these days and I had a similar reaction to the one in the post. Definitely something to think about though if you’re in a position to worry about such things.
What are you going to do when your students need to access an IPv6-only service? How do the instructors of your networks courses feel about this approach? Do you think the lack of exposure to IPv6 puts your students at an advantage or disadvantage compared to those graduating from an institution running dual stacks?
> Something they will have to think about the day that there are IPv6-only services. Which is not today or anytime soon.
Let me guess, you live in and/or operate setups in the US?
Yeah, the US has disproportionately many IPv4 addresses.
Meanwhile if one of our services doesn't need IPv4, it doesn't get IPv4. And if it does need IPv4, it's increasingly common to be IPv6 behind an IPv4 reverse proxy.
And as a result, due to the extra reverse proxy, you'll increasingly just get worse performance on IPv4 than native IPv6.
It's called CGNAT when you do it near the end user / eyeballs and do it generically for all services on the internet.
When you do it near the service being provided, and only for your own services, it's called a Reverse Proxy.
You are right that these two things are similar, but they aren't identical; CGNAT attempting to handle you trying to talk to who knows what on the Internet (e.g. game servers, VoIP) is a much harder problem to solve than a Reverse Proxy handling a known set of protocols you want to expose.
And, yes, an unloaded CGNAT or Reverse Proxy is not noticable in terms of performance. However, both of them have load limits where you need to scale them up, and particularly CGNAT frequently degrades (due to larger tracking tables) before completely falling over.
There were (haven't checked for awhile) very cheap vps offerings that come only with ipv6 with no possibility to obtain ipv4 at all. While not useful for typical stuff, I've successfully used a swarm of these for personal project. I expect these things to become more common as companies like ovh start charging $10+ for a small fallback ipv4 address range.
Well, I've seen several. Nothing for the general public. But things like the CMS/admin interface of a big web site. The site itself is on v4, the admin interface not.
I am now supreme leader, IPv6 is mandatory for everyone with at least a /48 prefix available per customer location by 2025 or we'll break down your doors and take over; no IPv6 NAT allowed.
IPv4 started like that. I worked at several ISPs, one of which had a ton of address space, and we gave every dedicated customer site a /24 by default. We had public IPs on all the desktops, no NAT, and generally no firewalls. The good old days...
Since universities were some of the first movers to the internet, there's a lot of legacy stuff holding them back. When you add in the sheer size and the lack of centralized power (which the author has talked about[1]), I'm definitely not surprised.
This is changing rapidly and in significant ways, at least in the US
There's a lot of requirements that apply to institutions as a whole to clean up their acts and mature a lot of their security processes to even be eligible for grants. A lot of the wild west days are coming to an end, and I've seen a push in several institutions to wrangle unit-level IT groups into one massive IT organization for their entire campuses. Not only is there a lot of security vulnerability there, but it's also a huge cost center that can be squeezed to flatten the curve of tuition, but not have to reduce the salary of three dozen associate deans
I'm working on a project to increase the supply of IPv4 addresses, and people often complain that attempting to do so undermines confidence in (or, allegedly, the pressure to adopt) IPv6, thereby harming the IPv6 transition.
I don't think we could possibly be anywhere near the top of the things harming the transition when we regularly encounter people actively encouraging others not to use IPv6 for either security or convenience reasons!
> 1) When was the last time you fixed networking issues by turning on IPv6?
I've used IPv6 to help users behind CGNAT; enabling IPv6 for client -> server often means those clients no longer go through carrier stateful firewalls and their sometimes tragically low idle timeouts (I've seen timeouts as low as 10 seconds).
I've also used IPv6 to help in a proxy config when I couldn't get the upstream servers configured for more listening ports; it's super easy to get extra v6 source addresses for the proxy servers and harder to get v4 addresses. With high volumes and low session times, you run into port reuse issues at around 10k-20k sessions per {source ip, dest ip, dest port} tuple; theoretically you can get to 64k, but TIME_WAIT takes time to clear and you don't want to be too aggressive.
Probably less going forward, but v6 and v4 often have different routed paths, and sometimes you want to get off of one path and onto another. If you're using a tunneled v6 connection, you almost certainly have a different path for most destinations.
> 2) When was the last time you fixed networking issues by turning off IPv6?
My previous DSL modem would crash when receiving fragmented IPv6 packets. My current one doesn't crash, but adds a lot of internal latency. Temporarily fixed by disabling IPv6; permanently fixed by using the modem in bridge mode and doing PPPoE on my own personal equipment (at great cost to my own sanity, PPPoE is gross, and I built a multi-node redundancy setup, so PPPoE sessions can be transferred between my redundant routers, bleh)
> 1) When was the last time you fixed networking issues by turning on IPv6?
In 2017. The problem was that file copying via scp was very slow between the servers (one in Germany, one in China). I set up a he.net tunnel in China, got an IPv6 address, and it went much faster via IPv6.
I've been running IPv6 since roughly 2007, starting with SiXXS tunnels, then HE.net tunnels, then moving to native. In that time, all problems "due to IPv6" were fixable. Turning off IPv6 was never the actual answer.
1. Multiple times. Idiots love to do meaningless things, so they disable IPv6 without understanding the consequences. I turn it back on and things start to work again.
I've been using IPv6 in anger for about a decade now and I have a few observations too.
This blog implies that IPv6 might simply happen and that is bad. If it does "happen" for a particular site then it will "happen" in the same way as IPv4 does already. Routers generally fail safe and so do PCs. In general a router will by default block inbound and allow outbound, regardless of IP flavour.
Yes it is a bit of a pain to maintain two lots of firewall rules but when you think about it you already have to worry about protocols too so IPv6 simply adds one more dimension to the already considerable combinations. A firewall rule generally worries about inbound/outbound IP/port/protocol. All IPv6 adds is IP version.
You'll also be surprised how quickly you can become accustomed to the stupidly long addresses. You may have forgotten how long it took you to get to grips with dotted quads when you first encountered IP(v4).
IPv6 does just work - it does have issues with multi ISP and that is a major issue that was never considered at the initial design stage. There are workarounds but they are shit unless you do full on BGP which is hardly a home user solution. It is what it is.
My fiber provider inherited network equipment that is preventing them from deploying IPv6. On their subreddit they responded from multiple inquiries that they are ready to provide a /60 once they upgrade their equipment.
I imagine this may be a problem for other providers.
Thankfully no CGNAT, so I have a couple VLANS that use he.net in the meantime.
IPv6 is such a mess. If I could go back in time to 1995 I would kick some people at IETF meetings. All they had to do was increase the number of octets from 32 to 64. Instead they redesigned almost everything about how IP works and IMHO made things much more complicated than they needed to be.
We'd likely be in the same situation right now, just with fewer extra features which are actually good. The C API would have to change in almost the same way. The network hardware would have to have separate paths anyway. Rules would still have to cover both cases separately.
Sure, we'd save a little bit of time from the extra features, but I don't see how anyone's deployment approach would be different.
So any increase in address size meant updates on all hosts and routers. If you're going to do a huge, global infrastructure update, it better be worth it. The changes made with IPv6 actually simplified deployment compared to IPv4.
What's so radical about it? I can understand some hesitance, but I've been working with IPv6 off and on for over 15 years so I'm probably too familiar with it now.
There's *tons* of backwards compatibility in v6. It's got dual stack, Teredo, 6to4, 6rd, 6over4, ISATAP, 6in4/4in6, NAT64/DNS64, 464xlat, DS-lite, MAP-T/E, 4rd, LW4over6... it has pretty much every form of backwards compatibility that can possibly work with v4.
v6 isn't radical in the slightest. It works very similarly to v4.
You can't incrementally shift toward IPv6 -- that is, you have to learn an entirely new system whole hog rather than a piece at a time, you have to touch every machine on your network, and if you want to approximate an incremental change to IPv6, you have to run dual-stack or tunnel, which adds at least another layer of complexity to everything.
And that's not even beginning to talk about supporting services such as RA, etc.
> that is, you have to learn an entirely new system whole hog rather than a piece at a time
Every time IPv6 negativists come to the thread they make it look like you need to be a rocket scientist to configure two hosts for IPv6.
> You can't incrementally shift toward IPv6
Yes, you can, you don't need to throw out your lovely IPv4 networks and addresses. Yes, it's dual-stack.
> you have to run [..] tunnel, which adds at least another layer of complexity to everything
No more complexity than running a PPPoE/PPTP tunnel to get IPv4 connectivity.
> And that's not even beginning to talk about supporting services such as RA, etc.
Oh God! You need to read another 20 pages on top of the previous 20 pages you read to understand IPv6! So, so hard!
BTW you obviously forgot what there was a time when you didn't know nothing about IPv4, including what is the default router, what is ARP, what is CIDR, netmask, routing etc, etc. Yet somehow you know that now. Same applies to IPv6. You had 20 years to learn it, yet in 2023 you still complaining what to use a technology you need to learn.
Your odd hostility is misplaced here. You seem to think I'm opposed to changing to IPv6, but I'm really not.
I'm describing various reasons why there is such slow adoption of IPv6. Ridiculing and being mad at people for avoiding it isn't likely to make them feel any differently. Understanding the resistance might be helpful in terms of getting people over that hump.
There is some truth to what you say, but I believe incremental deployment is possible. You could roll it out to end users in phases, a VLAN at a time. Same with the server side: migrate only a specific app to V6, perhaps just starting with a front end load balancer, adding external support to make it dual stack.
IPv6 has been available much longer than IPv4 was when the Internet went mainstream in the mid 90's. Yes, it's work to deploy. You might need to even upgrade to a router built in the past 10 years. Organizations have had decades to learn about it and deploy it. People just don't like change... especially corporate IT departments.
> People just don't like change... especially corporate IT departments.
Well, all change causes pain. People don't like change when there isn't an obvious benefit to offset the pain it brings. When they do see the benefit, though, they tend to embrace change. I think the mistake that was made with IPv6 was a social one: it's a huge amount of change (pain) for a benefit that is invisible or irrelevant to a whole lot of people.
IT departments, like most departments, dislike expense more than they dislike change.
I have a really hard time imagine a system that does not have those problems and provides the larger address space IPv6 provides. What would be your solution thats orders of magnitude easier to implement?
One that is backwards compatible with IPv4 would have eliminated a very large part of the friction here. I really think that if that were a feature of IPv6, we'd be at nearly 100% adoption by now, and IPv4 would be largely a dim memory.
I think we're talking about different things with "backwards compatibility". What I mean is the ability for IPv4-only software and hardware to be able to basically function on an IPv6 network. Maybe more slowly, certainly without any of the IPv6 features, but able to basically work.
Thats what I meant with the other way around. That would be awesome but how? Are there any protocolls that could do that? Any research? A paper? Because for my simple mind it seems impossible.
I'm no network engineer, but I can think of a few naive approaches. For instance, IPv6 could include IPv4 addresses inside its address scope, and provide for handling both IPv4 and IPv6 packets. Distinguishing between the two wouldn't be hard.
In reading the discussions leading up to IPv6, it was clear that the actual experts involved saw a few ways to maintain such compatibility. It was decided not to do that, though, because tradeoffs are (as always) involved. There are features they wanted to include that wouldn't have been possible while maintaining compatibility, and it was thought that a breaking change was worthwhile now as long as the IPv6 protocol was good enough that no breaking change would be required in the future.
Depending on what you mean exactly with "IPv6 could include IPv4 addresses inside its address scope", IPv6 actually does that.
For applications a subset of the IPv6 address space is set aside for IPv4 connections. So applications only need to support IPv6 and can communicate with IPv4 destinations using ::ffff:<ipv4-address>, so for example ::ffff:8.8.8.8 is a valid ipv6 address.
But that still requires the host to have a IPv4 address for this to work (it's only so applications can support both while only requiring support for one address family).
For IPv6 hosts connecting to IPv4 hosts there are different methods that translate IPv6 to IPv4 (NAT64, SIIT, etc.), but most (if not all) just embed the whole IPv4 address space inside IPv6 (and again you can have something like 2001:db8::8.8.8.8) and then translate based on extracting the IPv4 address from the IPv6 address.
And in combination with DNS64 you can have ipv6-only hosts that can communicate just fine with IPv4-only hosts (all ipv4 traffic gets routed via NAT64).
The problem is however the inverse. IPv4 is not forward-compatible. A IPv4-only host can only ever form outgoing connections to other IPv4 hosts, since there is no way to put more than 32-bits of information into the 32-bit destination field of the IPv4-packet.
You can of course expose certain ipv6-only hosts to the ipv4-internet using for example SIIT, but that requires a 1:1 mapping between the IPv4 and IPv6 host.
If you don't have that explicit mapping, how would a gateway know which IPv6 address you meant?
> If I could go back in time to 1995 I would kick some people at IETF meetings.
Sure.
But how is any of that relevant enough to bring up today? Now, IPv6 is what we have, and the standards are what they are, flaws and all.
The only reason I can think of is psychological: People don’t want to learn new things, so they find reasons to dislike the new thing to be able to pretend they don’t need to learn it.
I am not opposed to IPv6 in any way, but I'm also delaying changing my home network to IPv6 for as long as possible.
It's not from fear of change or not wanting to learn new things at all (I know IPv6 as well as I know IPv4). It's just that making that change is a whole lot of work, and IPv6 doesn't bring any benefit to me that I care about. I'll put in that effort when the situation changes and I get some benefit from it.
But that's the thing. I don't want to be a network engineer. I just want my devices connected.
Yet IPv6 is very complex with tons of moving parts compared to IPv4, and a lot of it works very differently so I can't rely on my existing IPv4 knowledge. In fact it frequently a hinderance.
Which IPv6 does pretty well even if you aren't a network engineer. More than 40% of all requests to google are from IPv6 and the vast majority of those connections are from people that never heard of IPv6.
> Which IPv6 does pretty well even if you aren't a network engineer.
Outside of smartphones (in the US, apparently), moving from IPv4 to IPv6 is genuinely painful and often requires deeper knowledge of networking to accomplish.
Yes, if you're using a smartphone or your needs are otherwise trivial (for instance, you don't have a real network at home but just have one or two devices connected to your modem), then none of this is a big deal. But outside of that, things can be very different.
We have millions of customers of which most don't know what an IP is. They mostly have a standard network, wired PCs, wifi devices, consoles etc. like 99% of all people. They browse facebook and instagram, search on google and watch youtube videos all over IPv6 without even knowing. Yes there where network engineers involved to make this work but without some engineers you wouldn't have IPv4 either.
The IPv4 knowledge already exists. For people who aren't network engineers, the fact that they have to learn an entirely new, complex, networking protocol and associated services is a huge pain point. I think a lot of actual experts really underestimate how much friction that presents. And that level of pain means that those people are very resistant to moving to IPv6.
Valid point but all those "not network engineers" that build networks can either fight it or implement it. Either way they have to learn it because they get exposed to it at least passively as the article calls it.
Well, they clearly have a third option because that's the one they've been taking: neither fighting nor implementing it. Thus the slow pace of adoption.
That's not an endorsement on my part at all, just a recognition of what has happened.
I confess that I'm doing the same thing in my home network -- I won't move to IPv6 until I have no other choice, because that move will take a ton of time, sweat, and tears.
Just to stave off misguided attacks on me: I am not saying IPv6 sucks and we shouldn't move to it. Not at all. But moving to it is a very expensive proposition.
Oh, now you've asked for it! I like talking about my home network. But I'll just give the 10,000ft view here.
I'll start by acknowledging that it's larger and more complex than a whole lot of networks. I have three subnets (not counting a second WiFi AP for guest use that just routes directly to the internet and bypasses my network entirely).
I have a subnet for my 4 internet-facing servers, a subnet for devices that for one reason or another aren't capable of working through my VPN, and a subnet for my general use. This is entirely encrypted using a VPN server I also run.
I have a total of around 70 different computers and devices on the network.
When I played with moving to IPv6, two things became immediately obvious to me. The first is that it will break most of what I have going on, so I'll have to go through and debug most of the systems to make them work right again. The second is that I'll need to rethink the entire network topology (except for my "lame devices" subnet -- those devices also can't use IPv6, so I'll have to maintain an IPv4 network just for them).
Rethinking the topology is probably the part that I'm least excited about, because it seems that I'll have to essentially become an IPv6 expert to design and implement that sort of change.
In any case, I anticipate at least a week of having a broken network ("broken" meaning just basic internet connectivity) while I figure all that stuff out.
In my experience, that depends highly on what you want to accomplish. For example, tell me how much less complex it is to inform a device on the network of what the address of the NTP server is in IPv6 compared to the IPv4 address. Assume you rely entirely on SLAAC, because that's the preferred way, or so they said.
> So you are a network engineer, but you just don’t want to move with the times?
I don't call myself a baker just because I can make a loaf of bread, but I then I've never been one to over-inflate my CV...
It's not like I don't want to move with the times, but I find IPv6 quite complex and rough around the edges in practice, especially for a homelab network.
It's the switches job to drop traffic from rogue routers/DHCP servers. Look up RA Guard and DHCPv6 guard. You also need to worry about rogue DHCP(v4) servers too. DHCP Snooping takes care of that.
If you're that paranoid then you also need to worry about IPv4 ARP and IPv6 ND attacks. Again, managed switches are required to drop unauthorized ARP and ND replies.
I never claimed that my nervousness is rational. But it's very real. This is complex stuff, and since I haven't been working with IPv6 for decades, I can't shake the fear that I've made a configuration error and am not aware that I've made a configuration error.
I think many people learned IPv4 at a relatively young age, and have internalized IPv4 as a natural part of the way the world works. But they were introduced to IPv6 late in their lives, and IPv6 therefore seems to be against the natural order of things.
So… you have learned from this and are now actively monitoring and participating at the IETF, so your expertise can be taken into account to prevent similar messes in the future?
(An octet is a byte btw, so it'd be an increase from 4 to 8.)
Hindsight is 20/20. It is easy to see now all the reasons IPv6 is not widely adopted, but back then they probably figured that adding more features would make it more attractive or something.
If I had a time machine and had to take a relatively naive crack at the problem, I'd make IPv6 really really simple: it'd just be IP-in-IP.
On the internet you're routed with an outer address, and the local router forwards it using the inner address. Speaking v6 over v4 is free because v4 routers ignore the inner packet. Speaking v4 over v6 just doesn't include the inner packet. Other local hosts are just contacted through v4.
Network engineers gotta engineer. Embrace IPv6 through a dual stack approach. Stay ahead of the curve by ensuring and ensure your security strategy accounts for IPv6.
It's all very well if you _have_ an IPv4 address range. But if you don't you're screwed. IPv6 fixes this, it should be adopted everywhere. Those against it seem to be the same ones who make money from the artificial scarcity of IPv4, funny that...
ipv6 has been “around the corner” since 2010 and it sucks we’re trying to force a protocol everyone hates.
i get all the reasons it’s great but when everyone on earth hates a single thing all together maybe it’s a sign???
It's also incredible that, despite putting all their users behind CGNAT, they don't provide IPv6.
I mean technically they are no _worse_ than their major competition here (Virgin Media which has failed to move on IPv6 for 20 years, why start now). But it's baffling that a _new_ network would be built without IPv6 provision!