Most of the bitching about IPv6 is from those who really, really want IP addresses to identify machines or users. IP addresses (including IPv4) were never intended to do that and it was never a good idea to put them in that position.
There was a time when most devices had 1 network interface and didn't move. But that was never a guarantee. People thought it was a guarantee when your $400-in-1988-dollars Madge ISA full-height full-width token-ring NICs with dangling AUI dongles next to your tank of an ST225 hard drive were a thing, but we're past that. Today most things that aren't servers have at least 2 - wired/Wi-Fi for laptops, Wi-Fi/cellular for phones. You can talk about NAT and security and mapping all you want, but if I can bypass your corporate internal network security simply by turning off my phone's Wi-Fi, yet still get to your resources - then NAT is a legacy chore that IPv6 makes unnecessary.
My first IPv6 implementation was in 2010-2011 (memory a but fuzzy). Carriers supporting BGP over IPv6 were few, websites over IPv6 were also scarce.
Fast forward 15 years snd the situation has improved quite dramatically.
IPv6 has some quirks that make it harder to digest.
- link local gateway address, makes it hard to understand why the subnet does not have a gateway from the ssme address space
- privacy extensions: it is very hard to explain to people why they have 3-4 IPv6 addresses assigned to their computer
- multicast instead of broadcast
- way too many ways for autoconfiguration (SLAAC, DHCPv6)
- no real tentative mapping to what people were used to. Every IPv6 presentation I did had to start with “forget everything you know about IPv4”
In the enterprise space, if you mention globally reachable address space, the discussion tends to end pretty fast because “its not secure”. Those people love their NAT.
> In the enterprise space, if you mention globally reachable address space, the discussion tends to end pretty fast because “its not secure”.
Topic drift, but for younger people who didn't live it, that's how it used to be!
For most of the 90s my workstation in the office (at several employers) was directly on the Internet. There were no firewalls, no filtering of any kind. I ran my email server on my desktop workstation to receive all emails, both from "internal" (but there was no "internal" really, since every host was on the Internet) people and anyone in the world. I ran my web server on that same workstation, accessible to the whole Internet.
That was the norm, the Internet was completely peer to peer. Good times.
Pretty much all tech companies and universities had a drop-in ftp server where anyone could, anonymously, put and retrieve files. It was a collective 'pastebin' useful to exchange information with clients and partners.
On the ftp server of the company I worked for, someone had put a cracked copy of our software for their colleagues to use.
The nice thing about NAT is it makes the security model easier to reason about.
By this, I don’t mean it’s more secure, because I know it isn’t. But it is a lot easier to see and to explain what has access to what. And the problem with enterprise is that 80% of the work is explaining to other people, usually non-technical or pseudo-technical decision makers, why your design is safe.
I really do think IPv6 missed a trick by not offering that.
> The nice thing about NAT [...] I really do think IPv6 missed a trick by not offering that
IPv6 supports NAT [0], and nearly all routers make it easy to enable. The primary differences compared to IPv4 is that no-NAT is the default, and that it's more heavily discouraged, but it still works just as well as it does with IPv4.
[0]: In the same way that IPv4 "supports" NAT, meaning that the protocol doesn't officially support it, but it's still possible to implement.
But would we have said the same in 1996 or 2000? Part of the adoption curve seems to be that it took years to abandon some of the bad ideas around IPv6 and readopt some of the better ones from IPv4. And a good chunk of the complexity of IPv6 is that some of the early ideas are very persistent, both in some deployed systems and in people's minds
> But would we have said the same in we 1996 or 2000?
IPv6 the protocol supported NAT just as well back then as it does now, but the software probably didn't. Which goes back to my point [0] [1] that IPv6 is a great protocol with bad tooling and documentation.
> Part of the adoption curve seems to be that it took years to abandon some of the bad ideas around IPv6 and readopt some of the better ones from IPv4.
The only abandoned IPv6 concept that I'm personally aware of is A6 records [2], but I'm pretty young, so I'm sure that there are others that I'm just not aware of. My impression from reading the RFCs and Wikipedia is that IPv6 hasn't changed very much, but that doesn't really mean anything, since I wouldn't expect for current sources to talk about concepts abandoned 20+ years ago.
My consumer router, and every router I have configured, implicitly supports IPv4 NAT out of the box. But it will never NAT an IPv6 network. If I enable IPv6 then it operates by IPv6 rules, which means each device gets a Network ID and each Network ID gets routed directly and transparently. The router has no NAT table and no NAT settings for this protocol.
So if NAT is “supported” whatever that means, it simply isn’t possible for most end-users.
Consumer routers don't support lots of useful stuff though, so them not supporting NAT66 isn't very surprising. Enthusiasts are likely to use OpenWRT or nftables, both of which support NAT66 [0], and quickly Googling some random enterprise routers shows that they all support NAT66 too [1] [2] [3].
This isn't enabled by default because it's usually a bad idea, but it's certainly possible if you really want. (It's discouraged because NAT in general is a bad idea, but it's no worse with IPv6 than with IPv4; the only difference being that IPv4 effectively requires NAT.)
If you've got a car that can't go 100, that doesn't mean nobody can, or that it doesn't exist. I don't care if you can't do it, it IS supported in the spec.
That’s an interesting analogy because there’s several ways you could easily dismiss it.
For example: if roads aren’t built to support cars travelling at 100 miles per hour then it doesn’t matter how much you argue that cars are can do 100MPH, because you’re still not going to be travelling at 100MPH.
Or
But if the only cars that can travel at 100 MPH are Bugatti Veyrons then it’s safe to say that 100MPH cars isn’t something available to even the average consumer of high end sports cars.
Or
Sure, some cars can travel at 100 MPH, but they’re so unstable at those speeds that it’s not even safe to attempted it.
The price you pay is that it's more difficult to reason about what is accessible from elsewhere, because all devices are represented by your router from the outside, and there are no great ways to opt out of that.
With NAT removed, you've still got the firewall rules, and that's fairly easy to reason about for me: Block anything from outside to inside, except X. Allow A talking to B. Allow B to receive Y from outside.
But we aren’t talking about someone technical glancing at their home routers firewall. We are talking about explaining a network topology to enterprise teams like change management, CISO, etc in large infrastructure environments.
That’s a whole different problem and half the time the people signing off that change either aren’t familiar with the infrastructure (which means explaining the entire context from the ground up) and often aren’t even engineers so need those changes explained in a simplified yet still retaining the technical detail.
These types of organisations mandate CIS / NIST / etc compliance even where it makes zero sense and getting action items in such reports marked as “not required” often takes a meeting in itself with deep architectural discussing with semi-technical people.
Are these types of organisations overly bureaucratic? Absolutely. But that’s typical for any enterprise organisation where processes have been placed to protect individuals and the business from undue risk.
In short, what works for home set ups or even a start up isn’t necessarily what’s going to work for enterprise.
> But we aren’t talking about someone technical glancing at their home routers firewall.
Are we not? Because I suppose most people here are only disgruntled by a new protocol that changes how their home router works, and having to spend some learning effort.
For network admins in commercial settings, this is even less of an excuse. IPv6, the protocol, is fairly well documented and understandable if you put in the work to do so. And I am confident in saying it is absolutely able to deliver on any kind of corporate network scenario, even moreso than IPv4.
> Are we not? Because I suppose most people here are only disgruntled by a new protocol that changes how their home router works, and having to spend some learning effort.
People at home don’t care about protocols. If the WiFi works and the TV plays Netflix or Hulu or whatever, the protocol can be anything.
Last time I “cared” was when I changed the DHCP network to not overlap with the VPN. And that was a long time ago.
Also I’m really not seeing many people here “bikeshedding” over their home gear. Are you sure you’re reading these comments and not some other IPv6 discussion? Because those conversations definitely do happen but this particular thread hasn’t gone like that.
> Are we not? Because I suppose most people here are only disgruntled by a new protocol that changes how their home router works, and having to spend some learning effort.
I did make the context pretty clear when I said:
> the problem with enterprise is…
Also, you completely missed my point when you said:
> if you put in the work to do so. And I am confident in saying it is absolutely able to deliver on any kind of corporate network scenario, even moreso than IPv4.
My point wasn’t that IPv6 cannot deliver enterprise solutions. It’s that some of the design around it makes the process of deploying enterprise solutions more painful than it needed to be.
One good thing about IPv6 is that any reasonable allocation will be large enough to use sizable chunks as functional divisions.
A small company might have a /48. You don't have to be concerned about address space when you just go, ok, first bit is for security zones. Or first 2 bits. Or first 3 bits. Do you need more than 8 security zones?
(Also, ULAs¹ exist, and most people should use them, independent of a possible consideration to not roll out GUAs² in parallel as one would normally do.)
Nope, it doesn't. The security model is based on your firewalls and routing, not on NAT. NAT just gets in the way and makes it harder to understand what's going on.
For example, on a normal home network, if you don't have a firewall on your router then your ISP can connect to anything on your network. Even when they don't control the router and even if you're NATing.
If you didn't realize this then apparently NAT didn't make it easier to reason about after all.
Can you say more about the ISP connecting to any computer on your network? I can’t find any references to this aspect in googling the right terms and the concept is foreign to me.
There are a bunch of ways to break it, or misconfigure it. But I have idea what this isp method is.
It's just normal routing. If you send packets to a router, it'll route them.
More concretely, they can run the equivalent of `ip route add 192.168.1.0/24 via <your WAN IP>` on a machine that's connected to your WAN network, and then their machine will send packets with a dest of 192.168.1.x to your router. Your router will route them onto your LAN because that's what its own routing table says to do with them.
Anyone on your immediate upstream network can do this, not just your ISP. Also, if you use ISP-assigned GUAs then this inbound route will already exist and anyone on the Internet can connect. Applying NAT to your outbound connections will change their apparent source address, but it won't make that inbound route disappear.
It's just one firewall rule at the border to block all inbound traffic to a subnet or a range unless related to an outbound connection. Now you have identical security to a NAT. The huge win is you can forget about port forwarding and later just open the ports you need to the hosts you need or even the whole host if required.
At this point, the people who would be worried about this ought to know that temporary addresses are a thing, and that they prevent workstation N from having a single fixed IP for its outbound connections that it could be identified with.
> any website can now not only log that the traffic originated from org A, but specifically from org A, workstation N.
GeoIP databases and Cookies exist. So I'm not sure how your threat profile has increased here.
> I wonder, is privacy implication is not important enough for people to worry about this?
The most you can do over what is already possible is attempt an inventory or unit count of my office; however, you'd have to get every computer in my office to go to the same website that you control. Then you'd have to control for upgrades and other machine movements. I don't think this enables anything in particular.
The SLAAC/DHCPv6 combo seems really strange to me.
Either IP/DNS/gateway discovery with one or the other could be tolerable. But allowing combinations such as SLAAC for addressing and DHCP for DNS discovery is lunacy.
It’s as if one said, let’s take the most basic and critical step and make it as complicated as possible and explore the combinatorial explosion…
The article mentions that DHCPv6 was an afterthought because DHCP itself barely existed when IPv6 was being designed - they were still using things like RARP or BOOTP!
The article does seem to simultaneously claim that IPv6’s design is the result of wierd no longer current pressures but also that it’s perfectly fine and correctly designed.
>In the enterprise space, if you mention globally reachable address space, the discussion tends to end pretty fast because “its not secure”. Those people love their NAT.
Was also designed in the early 90s before security was taken seriously.
I would need to ask the follow up question. Okay so what happens when someone gets in? Say some idiot install something they should not. Or there is some vulnerability in something you allow in?
Extra layers is good. But it does not mean you can forgo anything else.
The real problem is many "enterprises" have people who don't understand networking. NAT was a solution to IP address depletion. This is not a problem we have with IPv6.
If security is taken seriously, I'm sure they can spend a few minutes and learn how to configure a IPv6 firewall that allows no inbound connections. It's basically the simplest configuration possible.
> There was also unnecessary confusion caused by a rather political decision to make IPv6 require support for IP Security (IPsec), which was an immature technology at the time. This was a definite brake on IPv6 deployment until it was dropped after some years.
I don't know anything about the IPv6 situation, but the way this paragraph just slots in so innocently foreshadows some long wordy Wayland retrospective document on why adoption was so slow where someone from deep in the community slips in 1 short "sure we tried to block screenshots and that might have caused some issues with adoption for some users" paragraph in the middle-end. The innocence of the admission is so mild and context-free that it somehow manages to make itself look guilty.
In my experience, the IPv6 protocol is much simpler than the IPv4 protocol. However, the IPv6 tooling and documentation is still worse than it is with IPv4, and dual-stack is inherently going to be more complicated than implementing any single protocol, so I do have some sympathy towards "IPv6 is hard".
For example, the IPv6 packet structure [0] is much simpler than the IPv4 packet structure [1]; SLAAC [2] is much simpler than DHCPv4 [3]; IPv6 multicast [4] is much simpler than IGMP [5]; IPv6's lack of NAT simplifies peer-to-peer networking compared to IPv4; ULAs [6] prevent the annoying address conflicts you get with IPv4 [7]; etc.
Almost all computer have multiple interface (virtual or not). Application now need to know which interface the destination is on, and there is no easy data structure to store the interface
How? They're essentially the same as IPv4 addresses; the only difference is that there are way more of them, so address conflicts are much less likely.
> Almost all computer have multiple interface (virtual or not)
Sure, but that's the case with IPv4 too: my cell phone has one IPv4 address over WiFi and another over cellular, and my laptop has one IPv4 address over WiFi and another over Ethernet.
Edit: Ah, I think that eqvinox's comment [0] is what you were getting at here. And yeah, I agree that LLAs are kinda confusing and annoying. The difference is that LLAs aren't routable [1] and don't have an IPv4 analog, while ULAs are routable and are mostly equivalent to IPv4 addresses [2].
They do. You don't really see them on Linux unless configured manually, but Windows defaults (or at least defaulted in the past, my Windows-foo is very outdated by now) to a IPv4 LLA when DHCP fails.
The difference is that IPv6 requires it on every interface regardless of whether it has a different address already.
You're confusing ULAs (Unique Local Addresses) with LLAs (Link-Local Addresses).
(ULAs don't need the interface specified.)
ULA: fc..:… and fd..:…
LLA: fe80:…
[ed.: By the way, sin6_scope_id is where the interface identifier is stored in struct sockaddr_in6. So, basically every single IPv6 address object you're handling has the field for it.]
My problem with IPv6 is that I can't double click 2001:db8::1428:57ab to select the entire address. It's a silly complaint but representative of real ergonomic issues.
It would be pretty straightforward to change the text selection rule, so that double-clicking anything matching the syntax of an IPv6 address selects the whole address.
The hard part is to find all the places to repeat that change, and convince the code owners to accept it. Probably start with a standard analogous to RFC 5952?
A lot of it seems to boil down to "IPv6 was too early". Had IPv6 been developed a couple years later DHCP would have been mature, and SLAAC would have never been invented (since DHCPv6 is fairly obvious when you have good experiences with DHCP). Also it would have given all the alternative protocols (especially OSI) time to try (and likely fail) to gain traction, freeing IPv6 from the obligation to cram in all of their features. IPv6 could have picked a much smaller set of features that were proven useful by other protocols, then swoop in as the much simpler upgrade from IPv4 than any of the competitors
A couple of years later ipv6 became unnecessary. A big driver for ipv6 at the time was routers not being able to manage the increasing size of the core routingtable. Then 2 years later betterhardware and routing table compression became available and ipv6 became unnecessary.
Uh, no it didn't? Routing table size is still something of a problem, especially as v4 continues to fragment more and more, but also the main driver was insufficient IP addresses in v4 and that problem hasn't even slightly gone away.
I was there, reading the ipv6 mailing list eagerly. Address space exhaustion was a smaller problem because NAT was pretty primitive, so called carrier grade NAT was not even a thing yet. But cisco had the largest routers and their biggest was not big enough for the core router fabrics projected growth. And there was not enough demand (yet) for very large routers fir cisco to want
to design and build the nevessary chips. The IPv6 people thought they held all the cards and could mandate whatever they wanted.
But of course, it was s very long time ago and my memory may be inexact.
At a high level one of the sad things about IPv6 is that it surrenders a wierd, valuable and emergent property of IPv4 for the average home user in $random_country:
IPv4 addresses in logs are not super helpful in tracking a specific person and household’s behavior long term (NAT, reuse etc.)
Almost every end user oriented IPv6 deployment makes it significantly easier to use IPv6 addresses to persistently track individual machines (ie individual people) and map them to a household (yes I’m aware of RFCs 7217 and 8981, I’m mostly talking about long term stable prefixes).
How much of a real concern this is is debatable but it’s perhaps a little bit unfortunate.
At home, my external IPv4 address was the same for extended periods of time even though I never paid for a static IP. You could have figured the traffic was coming from the same location.
The one external IP to many internal devices relationship does help with privacy.
But once you enable those IPv6 privacy extensions, I have so many devices bouncing between IPs I’m not sure how you’d even know how many devices I have, let alone which device is which.
This is not very substantive, but rather procedural, like this example of an answer doesn't tell you much, but tells you the official paper IDs:
> Actually, we tried that: the "IPv4-Compatible IPv6 address" format was defined in {{RFC3513}} but deprecated by {{RFC4291}} because it turned out to be of no practical use for coexistence or transition.
192.168.1.1$ ip link set sit0 up
192.168.1.2$ ip link set sit0 up
192.168.1.2$ ping ::192.168.1.1
64 bytes from ::192.168.1.1: icmp_seq=1 ttl=64 time=0.812 ms
(It works over the Internet too, though make sure your firewall doesn't block protocol 41 and that the packet doesn't get NATed.)
Notice how this doesn't really help you at all. You still need a functional v4 network, you still need v6 support in the kernel on both sides and your programs still need to support AF_INET6 sockets -- at which point, why not just use ::ffff:192.168.1.1 which sends packets without the tunnelling and doesn't need OS support on the far side, or 192.168.1.1 which works with AF_INET sockets and doesn't need tunnelling or any OS support on either side? This is strictly worse than the former option and less compatible than the second.
It is extremely hard (for Brian, but even more so for anyone else, I certainly can't) to give a good answer to that, since you're talking about the absence of utility. People had applications in mind but dismissed them because they either found better ways or it wasn't practical. But that very frequently doesn't result in a "paper trail".
(It's a bit like LLMs having problems with negatives/absences.)
It happened in india mainly due to regulatory pressure[1]. It also helped that around the same time, Reliance (an oil company) launched at a hitherto-unseen pace an entirely new telco (Jio) with only 4G support (now 5G too, but at the time) and zero legacy infrastructure. Airtel (an older telco) was still using ipv4 in lots of cases. However due to pricing pressure[2] and TRAI pressure, they also switched when their 5G rollout happened in 2022. They changed vendors and with that changed the infrastructure as well. So today they are also in good shape ipv6-wise. See also [3]
[2] The pricing pressure was _real_. 4G was the first time networks moved away from circuit switched to IP-based. So the marginal cost equation became better. And no legacy infra to support. By 2020, they also had funding from google and meta.
Obviously economies that rely largely on second hand technology are going to have old technology. Much of Africa is in this bucket. But looking past the extremes, India is at nearly 80% right alongside Germany. They fall in very different average income brackets. So the correlation isn't tight.
I can't see any value in pointing out vague correlation between income and proliferation of a new technology. It's the most obvious of observations.
There is no working solution to ipv6 dual WAN failover, 30 years later... A critical design flaw that was simply ignored by the designers despite being used in almost any SME network.
inb4 no you can't have all lan devices have multiple ipv6 addresses and choose for themselves, typically 1 WAN is cheap and the second WAN is expensive/slow and should be used only for WAN1 failover
Inb4 no you can't just advertise new RA, devices on lan can takes minutes to update.
On ipv4, NAT+changing route on router just works, 1-2 seconds failover.
That's one ugly hack, which assumes (1) WAN1 has static ipv6 (the typical SME has dynamic DHCPv6 address...) (2) all the devices will behave correctly when running on NPT on failover WAN2. Many devices do not know about NPT which is basically NAT for ipv6, and break on p2p protocols like voice, video, streaming. They'll send the wrong NPT address to the other side, which try to connect back to the WAN1 address, which is down because of failover.
It is a hack, no argument. It seems fine for web traffic... You'd have to do some scripting to handle the dynamic prefixes. My own dynamic v6 prefix hasn't changed in years.
If you want "real" failover, get an ASN, your own prefixes, and run BGP. I know that's not for everyone!
Have you tried it? NAT66 implies using fd00::/8, which then gets deprioritized in all devices below ipv4, in accordance with RFC 3484. The end result: all devices revert to using ipv4 on dual stack lan.
Ipv6 is fundamentally broken for failover scenarios.
IPv4 has exact same problem, the NAT is working here because devices does not actually have proper Internet connection, all connections are terminated on NAT and reassembled after.
Actual solution could be extending TCP and UDP or make a new transport layer procotol that handles changing addresses, similar to what QUIC do. But we cannot do it exactly because things like NATs existing, thus QUIC build was build on ossificated UDP.
Imagine if instead of IP+port a connection use unique per-connection hash to persist IP addreses changing. No more trying fighting to keep the IP the same.
Ipv4 does NOT have this problem. The typical setup is always NAT for ipv4 lan, so external address can be changed with minimal disruption.
All ipv4 apps that require hole punching assume they will need to "discover" the external address anyways, for every new p2p connection.
In contrast to the vast majority of ipv6 apps which assume their ipv6 address is identical to external ipv6 address, as this is(was) the main marketing point of ipv6 - directly addressable end points.
I've always found the most complicated part of IPv6 to be address scopes and source address selection. The fact that one interface can have any number of addresses in different scopes and prefixes complicates things a lot.
Another thing that will always trip up new IPv6 network engineers is solicited-node multicast. You know the theory, computers talk to ff02::1 for neighbor discovery and then you hop onto a real network and see none of that actually happening.
And probably the most complicated thing for network engineers - how to set up firewall rules if machines are constantly changing their addresses.
For developers and security people - just parsing and validating v6 addresses is a whole bunch more work, but at least for this, the tools are available to help you now.
Honestly... Its more machine vocab than human level vocab.
Ipv4 is jsut about able still to hold in your head, have a convo or more importantly you can:
"Shout an ipv4 across the open office floor from your desk to your tech colleague"
If you shout an ipv6 address in public, you jsut seem broken
> The main reason for IPv6, and its only real reason for existence, was bigger addresses.
Which also allowed for better route aggregation in the core BGP tables.
Better node mobility support. Better multicast support. Genuine link local addresses.
IPv4 had a lot of unfortunate edge cases. I think IPv6's greatest strength and also responsible for it's slow rollout was it's insistence on solving several of these problems at once, along with IPSec as the article notes, and hammering them into the hard requirements for the core stack.
I recently had to set up basic IP-based country detection in Nginx for a project. Parsing and handling IPv4 is trivial. The second I had to account for IPv6 string formats and update the Geo databases to match, the complexity just spiked for no good reason. It feels like we traded address exhaustion for parsing nightmares.
On one of my linux machines the "localhost:8080" did not work after new installation. It resolves to local ipv6 address, while server only listened on ipv4.
After this I go out of my way to disable, remove and nuke ipv6, out of every setup and deployment I do. Ipv6 is already quite complicated, but supporting TWO competing network stacks, with complicated pseudo compatibility, just multiplies unnecessary complexity!
Or, you could've fixed your server's configuration. Probably would've been faster than to "disable, remove and nuke ipv6". In general, the mistake is that it says "0.0.0.0" or "0.0.0.0:8080" somewhere where it should really say "::" or "[::]:8080".
(IPv6 sockets by default accept IPv4 connections, unless you disable that either system-wide or on the specific socket.)
By the way, I do agree the colon was a really poor choice for separating the blocks, when it is also used to separate the port number.
I fixed the problem once for all. Now my program even refuses to start, if IPv6 is enabled. I am not going to spend time debugging problem, that can be easily prevented. Pretty valid solution on private networks and local only kubernetes deployments.
If customer wants proper ipv6 support, we can sign a contract and talk about it. But do not expect me to support some technology for free, just because it is enabled by default.
Nah, you didn't fix anything, you just moved the problem around.
(Worst case, you moved the problem to your finance department, for buying IPv4 address space. But even if you didn't do that, at some point sooner or later you'll get pressure to support IPv6. And then you'll have to "un-fix" everything you did, and fix the actual problem. Maybe it'll be after you're retire, but I wouldn't take bets on that.)
[ed.: best case, you moved the problem to someone else outside your company or scope. Good for you, I guess. Like the sibling post says, address space shortage is an issue for everyone, and personally speaking I would consider it rude to make it other people's problem.]
As I wrote, we use internal networks and k8s. Most of our nodes can not even access internet. I would welcome pressure to support ipv6, it means juicy fresh contract and money.
> you didn't fix anything, you just moved the problem around.
I do not get this attitude "ipv6 is inevitable". So far no customer even asked about it. We have way more urgent problems like cloudflare blocking, ddos from clankers, state regulations...
If the problem actually becomes real in like 20 years. The clankers will probably solve it in like 10 seconds. There is zero benefit right now to deal with headaches of dual routing and addressing.
Did you just miss the headline a few days ago, that IPv6 adoption has reached 50%?
You might be right if IPv6 adoption stayed at 10% or so. But the current trend suggests that sooner or later someone is going to demand IPv6 support on your side.
This attitude is widespread enough to hold the world back by forcing everyone who interacts with the public Internet to support ipv4 (some technology), "for free". So, either way, we're forcing one of them. So, we might as well lean towards supporting the one that isn't hard capped at 4 billion addresses in a world with at least 2x as many devices. Have you ever tried to deal with NAT punchthrough? That's way more difficult to fix than having to properly configure your server.
> Have you ever tried to deal with NAT punchthrough? That's way more difficult to fix than having to properly configure your server.
Yes I did, and I no longer support that either. For my setups it is local private ipv4 networks all the way now! How tailscale or other VPN deals with that is not my problem!
If two nodes are on different networks, they should not be allowed to talk to each other anyway. Seems like security risk! Clean design, simple rules!
What you seem to be misunderstanding is that your whole process of nuking IPv6 is more work than studying the issue for a few minutes and then listening on both protocols. Setting a service to listen on a port will use both IPv4 and IPv6 by default, and if yours isn’t means you’re probably already doing something wrong or also have other bugs.
Yeah, 24 years old. It’s crazy how little has changed in 24 years, other than most of the major sites now supporting IPv6 (with some notable exceptions, such as AWS and GitHub).
> Incidentally, "IPv8" proponents often ask why IPv6 didn't simply stick some extra bits on the front of IPv4 addresses, instead of inventing a whole new format. Actually, we tried that: the "IPv4-Compatible IPv6 address" format was defined in {{RFC3513}} but deprecated by {{RFC4291}} because it turned out to be of no practical use for coexistence or transition.
Any tl;dr on why/how the simplest solution imaginable would have been "of no practical use for coexistence or transition"? Granted, I understand the other points make a strong enough case by themselves.
TL;DR: because it doesn't actually solve anything.
Being able to jam an IPv4 address into an IPv6 packet header doesn't mean you can send that packet to an IPv4-only host and have it be understood. You still need an IPv6 stack on both endpoints, and on all the routers in the middle - and at that point, why not just use IPv6 addresses?
Also, it already exists. The IPv4 range is included in the IPv6 range. 0000:0000:0000:0000:0000:ffff:0a00:0001 is the official IPv6 representation of 10.0.0.1.
As you can see, it doesn't actually solve anything.
It makes some APIs more convenient! You can pass this address to Linux for an IPv6 socket and it will secretly open an IPv4 connection to 10.0.0.1, so your code only has to support IPv6 sockets to support IPv6 and IPv4 connections.
It seems I've been rate limited to post every 12 hours, instead of five times per three hours. It must be either because I said interpreters don't emit native instructions, or because I said America had to buy TikTok to maintain American propaganda, or because I said you can make money gambling if your bets are the same as insiders. Or maybe I'm being punished for voting. I don't think dang will ever confirm what the reason was. Hacker News is so intransparent.
That applies to pretty much any reasonably complex idea. A new system requires effort to understand it. When you've expended that effort, it's not complicated anymore.
I don't understand this sentiment—as if learning IPv4 was enough work on your part, and now you're entitled to networking protocols never changing anymore.
Just as much as people are not entitled to lack of change, they are not obligated to enjoy, welcome or facilitate change.
What I learned about IPv4 at the turn of the century allows me to comfortably plan and manage networks up to a few thousand nodes, maybe a few tens of thousands.
I don't work in networking anymore. I really don't care about what those who are in that business. What you need to manage contemporary billion-node size networks and interchange between them is not my problem. You try to make it my problem, but I don't care.
I'll continue organizing the very few and very small networks that are still my responsibility using pre-CIDR ideas.
Maybe it becomes impossible some day. I'll deal with it then.
Not much more complicated than IPv4. There are more bits. The addresses are longer. It's not hard to grasp if you understand the prerequisites to understanding networking in general.
The idea that it’s just “more bits” it’s wrong, so I’m not sure your assessment is valid. Maybe at the packet level it’s just “more bits”, but at the network level a lot of processes changed. IP assignment, router discovery, etc. are different.
What I don’t understand is why coexistence was so important. TFA notes a lot of protocols were in use back then.
Also what’s with all the problems? I’ve had RA packets leak across VLANs via firewall misconfigurations, some my fault and some not. I get that people designing internet protocols had a lot to think about, but why am I fighting stuff like this?
> What I don’t understand is why coexistence was so important.
Military, corporate, tech... it isn't. (If your people like flag day migrations. It's… "a choice".) But if you have to explain to an end user why some things work and some don't, you're just f'd.
And note "coexistence" here means that an end host can implement IPv4 and IPv6 at the same time, without them interacting at all. Imagine if you had to choose between IPv4 and IPv6 on your devices, maybe something like "you need a 2nd network card". Can you imagine anyone switching to the less popular protocol?
The article describes coexistence as both dual-stack and connectivity between single-stack IPv6 and single-stack IPv4 host. And that in the autor's opinion all the complexity is in the latter, not in the dual-stack
You raise a good point that we also should't take dual- stack for granted. But I think the more precise question 'why not dual-stack as the only coexistence option' also seems like a good one, and one the article does not explore or even acknowledge
Dual-stack was the only coexistence option for a long time, until NAT64 came around. There were a whole bunch of attempts at compatibility, e.g. with "::1.1.1.1" and "::ffff:1.1.1.1" as IPv6 addresses, they just didn't go anywhere. (Well, not quite, the latter is in POSIX and in socket libraries around the planet. Doesn't leave the host though. At least it's not supposed to. I have some horror stories…)
NAT64 started happening because it solves real problems — large eyeball networks, particularly mobile phone networks, didn't want to pay for twice as large table sizes on their routers and twice the maintenance effort. So they made IPv6 end hosts capable of connecting to IPv4 systems. But this is 2010 era, IPv6 was ≈15 years old at that point!
The whole world can't migrate all of their hardware on a whim. There was a period of time when it was a very common quip to say that Amazon would have to buy every new IPv6 compatible router in the world for a year if they wanted to upgrade their infra. I don't know if the urban legend is true or not, but the fact that it sounded plausible is a good enough of an example.
The main complexity of IPv6 is still ha I g to maintain an IPv4 installation. The vast majority of non phone devices do not work in an IPv6 world only because CLAT hasn’t been baked into the OS since the very beginning. It still isn’t a first division tenant on Linux servers, desktops, IoT, or windows. I believe OSX integrates it now
Could with approximately zero services requiring IPv6, the collapsing cost of IPv4 addressing, and it makes IPv6 very much a hidden protocol for phones. When I tether off my phone I get an IPv4 address, the phone may well do a 4:6 translate and then something else does a 6:4 translate. That doesn’t matter, I can still open a socket to 1.1.1.1 from my application.
Had IPv4 been transparently supported IPv6 wouldn’t have taken 30 years and a whole new ecosystem (phones) to get partway there.
If anything, IPv6 is extremely easy to use, especially with SLAAC: On any kind of standard network, you turn on IPv6 on your machine, and, given physical connectivity, bam! You're on the internet.
It only gets complex if you try to micro-manage it.
Oh no, last time I asked on HN I got 24 to 48 easy steps involving a lot more acronyms than this (please don't repeat them).
IPv6 is easy to use only if you let your one router manage everything and you give up control of your home network.
Edit: again, please don't help. There have been HNers trying to help before, but my home network is non trivial and all the "easy" autoconfiguration actually gets in the way.
There are no more acronyms. SLAAC means automatic client configuration. That's the only one you need.
> give up control of your home network.
What does that even mean? What do you gain by deciding your Apple TV should be at 192.168.0.3? With IPv6, you can just `ping appletv` and it works fine. What more "control" do you need?
I mean generally I want fixed IPs on my local network for robustness.
With IPv6 I actually want it more and it becomes possible since we can just use the MAC address as an IP address.
I have IPv6 service at my ISP right now but I'm hesitant to turn it on on my local network because it does make my firewalling concerns much more critical.
You're assuming there is only one internet connection in my home network, for example. The "easy" trick where your ISP gives you routable addresses does not work when there's more than one exit.
Still want to help? :)
And really... everyone is pushing for SSL everywhere - among other things so that the ISP doesn't MITM your traffic.
Why would you allow the ISP to know what machines are inside your home network then?
This doesn’t change anything about the NAT or firewall story, and having two different connections is complex with IPv4 just as well. Aside from being a fairly exotic setup for personal use anyway.
What would your ISP do with the information that there are 73 unique addresses in your network at this point in time? Especially given that devices may mint any number of them for different reasons, so you can’t even really assume that corresponds to the number of physical devices in your network?
> I mean generally I want fixed IPs on my local network for robustness.
Same here, which is why I use DHCPv6. It's pretty easy to set up, nearly everything supports it, and it's super reliable.
The only catch is that Android refuses to support DHCPv6 for some reason, which is kinda annoying since it means that you need to keep SLAAC enabled if you have any Android devices on your network. Which means that your DHCPv6-supporting devices will end up with two addresses, but there aren't any real downsides to that.
I don't care to remember them, but I do want them to be consistent so there's no dependency in DNS.
My home network isn't the Internet and isn't large: DNS is a much more complicated system to keep running then just fixed IP addresses in that circumstance.
Above a certain scale, that flips but not at the home level.
A router which can be switched off sometimes, or break and delay replacement.
I don't want all my IoT devices going down because they can't resolve hostnames - that's why I set fixed IP addresses for them. It means how they communicate with each other and my network is well-defined, and works provided they have Layer 2 (easy to keep up - it works provided any 1 AP is online, whereas my internet or the router providing it can vanish).
Honestly, it sounds more like your network is fragile rather than robust. A robust network would be able to handle the IPs changing, rather than needing them permanently set to some specific value.
You are allowed to state your opinion, as am I. My issue with your opinion is that is grounded in false belief and a lack of knowledge, and rehashing it here reproduces those opinions in others.
NAT changes the apparent destination address of a connection, it doesn't filter them. If a connection arrives with the destination address already set to one of your machines, NAT won't prevent it.
NAT is not a security device. A firewall, which will be part of any sane router's NAT implementation, is a security device. NAT is not a firewall, but is often part of one.
Any sane router also uses a firewall for IPv6. A correctly configured router will deny inbound traffic for both v4 and v6. You are not less secure on IPv6.
Even a correctly-configured NAT will let connections in from outside, and a lot of people don't understand this.
Personally I'd count "your security thing doesn't actually do the thing it's supposed to do" as being pretty bad on the security scale. At least people understand firewalls.
IPv4 requires a DHCP server. It requires assigning a range of addresses that's usually fairly small, and requires manual configuration as soon as you need more than 254 devices on a network. The range must never conflict with any VPN you use. And there's more. Compare to IPv6: Nothing. All of these just go away.
And concerning the NAT: That's just another word for firewall, which you still have in your router, which still needs to forward packages, and still can decide to block some of them.
Windows[0]: Static IP configuration is as simple as typing an IP address into the pretty dialog box. No DHCP required.
Linux[1]: # ip addr <ip4 address> <subnet mask> <device> will set a static IP address
>It requires assigning a range of addresses that's usually fairly small, and requires manual configuration as soon as you need more than 254 devices on a network.
Is 65,536 (172.16.0.0/16) or 16 million addresses (10.0.0.0/8) "fairly small"? Are DHCP servers unable to parse networks that "big"?
>Compare to IPv6: Nothing. All of these just go away.
They most certainly do. But they're not "problems" with RFC1918 addressing and aren't "problems" at all with IPv4.
There are many issues with IPv4 and the sooner it dies, the better. But the ones you mention aren't issues at all.
If you're going to dunk on IPv4, then dunk on it for the actual reasons it needs to go, not made up "problems."
* It was designed by people who didn't have the full picture and were missing representatives from hardware vendors, small businesses, home network admins and a bunch of other people that will be affected by design.
* It was designed by people who didn't consider the cost of migration and the amount of work that would require (see previous point).
* It was designed by people who lived in an ivory tower of "noone will run dual stack for a long time", "everyone will love to run two completely separate network designs".
* It was designed on a premise that end-to-end, fully accessbile devices are something we actually want and won't cause privacy issues.
I think it should be a study material on how standards and designs by commitee can go wrong if they're not headed by people with extensive experience across the industry with enough authority to push for good solutions.
IPv6 tried to do too much (just like many software "let's refactor this legact code") and was done by people who didn't consider all perspectives and costs (again, like many less experienced architects trying to rewrite legacy software).
This annoys me, especially the last “It takes at least 25 years” rhetoric.
It didn’t take 25 years for SSL. SSH. Gzip encoding on HTTP pages. QUIC. Web to replace NNTP.
GPRS/HSDPA/3G/4G/5G
They all rolled out just fine and were pretty backwards and forwards compatible with each other.
The whole SLAAC/DHCPv6/RA thing is a total clusterfuck. I’m sure there’s many reasons that’s the case but my god. What does your ISP support? Good luck.
We need IPv6 we really do. But it seems to this day the designers of it took everything good/easy/simple and workable about v4 and threw it out. And then are wondering why v6 uptake is so slow.
If they’d designed something that was easy to understand, not too hard to implement quickly and easily, and solved a tangible problem it’d have taken off like a rocket ship. Instead they expected humans to parse hex, which no one does, and massive long numbers that aren’t easily memorable. Sure they threw that one clever :: hack in there but it hardly opened it up to easy accessibility.
Of course hindsight is easy to moan but the “It’s great what’s the problem?” tone of this article annoys me.
I was at some of those IETF meetings in the mid-1990s and attended some early IPv6 working group sessions. We knew the conversion would take time, but I don’t think any of us thought it would be this slow. I was involved with multiple L3 switches and routers from 1997 through 2010. The issue was always that IPv6 basically required lots of boxes in the middle to understand it in order to roll it out, so when would it be commercially necessary? Yes, you can do tunneling and NAT at various points, but it always requires more than just the endpoints. It shows up in DNS and socket APIs. There’s no easy way to determine if a path supports it, and the path can change in an instant due to a route change. All that is very different than SSL or QUIC where only the endpoints have to be involved. That’s why QUIC uses UDP, for instance, so old intermediate devices just see it as a protocol they already know. SSL just assigned port 443 and the “https” protocol in the web URL. If a web client contacts a server on port 443 that doesn’t use SSL, it just fails. To put it another way, the level of the stack that you’re changing matters. SSL and QUIC are really L5+. IPv6 is squarely L3. There are no protocol negotiation mechanism available at L3. So, from a business standpoint, when do you take the hit and integrate it all into the processing pipeline? How do you do that in a way that doesn’t impact your IPv4 forwarding performance, because that’s what the near-term market will judge you on? How do you afford the development and test cost associated with a whole other development (almost double)? If you’re doing software forwarding, the answers are a lot easier. As soon as you’re designing silicon, it’s a lot harder. When you’re under a lot of commercial pressure, it’s difficult to be the one who goes first. And remember that this hardware evolves on roughly 10 year cycles (2 years for design, 3-5 year market sales, 3-5 year depreciation at the customer before they buy new ones). Oh, and customer rollout of IPv6 is a major project with lots of program management and testing, not just buying a box or two. So, yea hindsight is easy. Eventually you get there, but it’s a long road.
> It didn’t take 25 years for SSL. SSH. Gzip encoding on HTTP pages. QUIC. Web to replace NNTP.
All that's required to implement each of those is two computers: 1 client and 1 server. Whereas supporting IPv6 requires every router between the two computers to also support IPv6. Similarly, if your current software doesn't support SSL/SSH/Gzip/etc., it's pretty easy to switch to different software, whereas it's hard or impossible for most people to switch ISPs.
> GPRS/HSDPA/3G/4G/5G
Radio spectrum costs providers millions of dollars, and each new cellular protocol increased spectrum efficiency, so upgrading means that providers can support more users with less spectrum. The problem is that most of the "Western" countries still have lots of IPv4 addresses, so there isn't much cost benefit to switching to IPv6. However, China and India both have lots of users and fewer IPv4 addresses, so there is a cost benefit to switching to IPv6 there, and unsurprisingly both of these countries have really high IPv6 adoption rates.
I damn near have a stroke every time I try to reason about IPv4 addresses as an integer. But hey, I guess four bytes is four bytes no matter how you read them.
I think it’s one of many that indicates the underlying issues for its adoption. It’s a 90s technology, not as much thought was given about how it would be used.
> The whole SLAAC/DHCPv6/RA thing is a total clusterfuck.
SLAAC is easily the thing I love most about IPv6. It just works. Routers publish advertisements, clients configure themselves. No DHCP server, no address collisions, no worry. What's bugging you about it?
What problem is this actually solving? I've deployed DHCP countless times in all sorts of environments and its "statefulness" was never an issue. Heck, even with SLAAC there's now DAD making it mildly stateful.
Don't get me wrong, SLAAC also works fine, but is it solving anything important enough to justify sacrificing 64 entire address bits for?
"I wish to participate in a global telecommunications network and I wish to connect immediately to all my friends and be available to them 24/7 and I wish to play games with strangers across the country and I wish to receive all my email within 300ms with no spam and I wish to watch the latest news from Iran in 4K streaming Dolby"... but priiiiivacy!
SEND secures NDP by putting a public key into those 64 bits, and also having big sparse networks renders network scanning rather useless at finding vulnerable hosts, so there are reasons to make subnets /64 other than SLAAC.
Also we can always reduce the standard subnet size in 4000::/3 if we ever somehow run out of space in 2000::/3 (and if we don't then we didn't sacrifice anything to use /64s).
DHCP requires explicit configuration; it needs a range that hopefully doesn't conflict with any VPN you use; it needs changes if your range ever gets too small; and it's just another moving part really.
With SLAAC, it's just another implementation detail of the protocol that you usually don't have to even think about, because it just works. That is a clear benefit to me.
on the local network and have it work (where ping can be any command or browser). That's easy with DHCP+DNS, and either impossible or amazingly ugly with DLAAC.
That's an extra service or two running on every device with extra configuration, and... Maybe it's more reliable now? I vaguely recall having a bad time.
What does the router do out of the box, or at all, for mdns? Isn't it a p2p service?
Is it possible that you own your own router and have at some point configured the router to turn up 6 off? I know it is turned off on my router because I had some issues with Verizon ipv6 and tp link in the past.
FWIW, I'm also on Spectrum (by virtue of the Time Warner acquisition back in the day) and I get 10/10 on that page. That is, after turning off Firefox "Enhanced Privacy Protection" which actually blocked the page from loading at all for some reason. Got 9/10 using Chrome. Both on Linux.
have that be the invisible bottom layer. come up with a list of 256 common words, one per byte, and have that be the human visible IP address. mentally reading a string of words, however nonsensical, is way easier than a soup of undifferentiated hex digits.
That would cause worse confusion when working with teams from different localisations. Not to mention the complexity of now adding localisations to the address parser.
We have that variant of IPv8, it's what CGNAT gives you, especially if you run MAP-E or MAP-T (which are technically not quite NAT, but kinda are, it's… complicated). You take some bits from the port number and essentially repurpose them into part of the address.
It's a nice band-aid technology, no less and no more.
There are lots of legacy things in tcp/ip headers. One of them can be for the extra octlet.
When ipv4 legacy flies around, that oclet will be null or 0. The entire internet could route just fine, especially if you put the extra octlet at the end. 1.1.1.1 gets an extra 1.1.1.1.newoctlet.
So every existing IP gets a bonus 255 new IPs, and for now, routing of those is hardlocked to that IP, and it works with all legacy gear.
In 30 years or something, we can care about the mobility of those new IPs.
You're at the very beginning, baby steps stage of inventing IPv6 there.
You aren't the first person to come up with the idea of adding extra bits to IP addresses to make them longer. The problem isn't finding somewhere to stash the extra bits in the packet format (which is trivial; you can simply set the next-protocol field to a special value and then put the bits at the start of the payload), it's getting all software to use those extra bits -- and getting that to work requires doing all of the new AF family, new sockaddr struct, new DNS records, dual stack/translation/tunnels etc etc that v6 does.
Please consider that maybe the people working on v6 weren't actually complete imbeciles and did in fact think things through.
Please consider that maybe the people working on v6 weren't actually complete imbeciles and did in fact think things through.
It is possible for the world to change, and for designs and plans and viewpoints 30+ years ago to be less correct today.
This world is not that world. That world had massive concerns about the processing cost of NAT. That was one reason for ipv6. It also had different ideas about where the net would go. We now know that the "internet of things" and "having your fridge online", as well as "5G in everything so people can't firewall it off" is just insane and malign.
We also know that tying an IP address to a person (compared to an ISP using NAT) reduces privacy. That devious and devilish actors abound.
Even though they thought these things might be neat, many of them aren't.
> That world had massive concerns about the processing cost of NAT
The processing cost of NAT is still a problem. There's that classic post by a Native American tribal ISP where it was cheaper for them to pay to replace their clients IPv4-only Roku devices with IPv6 capable Apple TVs than to upgrade their CGNAT appliance to handle the video traffic.
The concerns about the "processing cost of NAT" were edge concerns. Companies, homes, edge-devices with 100 or 1000 RFC1918 addressed devices behind them. When ipv6 was created, NAT wasn't a thing, as processing power just wasn't there.
And it was thought the processing power would never be there.
Yet now everyone has NAT in little devices at home. So the need to route 100 IPs into every person's home isn't a thing. Which is inline with my comment about how the world looked different 30 years ago, and how the concept of "IPs for everything" is the reverse of what people even want now.
> It didn’t take 25 years for SSL. SSH. Gzip encoding on HTTP pages. QUIC. Web to replace NNTP. GPRS/HSDPA/3G/4G/5G They all rolled out just fine and were pretty backwards and forwards compatible with each other.
You're comparing incremental rollout with migratory rollout for most of these; (not the mobile phone standards.) That's apples and oranges.
You can argue for other proposals. But at the end of the day the best you could've done is steal bits from TCP and UDP port numbers, which is... NAT. Other than that if you want to make a serious claim you need to do the work (or find and understand other people's work. It's not that people haven't tried before. They just failed.)
And, ultimately, this is quite close to typical political problems. Unpopular choices have to be made, for the benefit of all, but people don't like them especially in the short term so they don't get voted for.
> If they’d designed something that was easy to understand, […]
I can't argue on this since it's been far too long since I had to begin understanding IPv4 or IPv6… bane of experience, I guess.
> […] not too hard to implement quickly and easily, […]
As someone actually writing code for routers, IPv6 is easier in quite a few regards, especially link-local addresses make life so much easier. (Yet they're also a frequent point of hate. I absolutely cannot agree with that based on personal experience, like, it's not even within my window of possible opinions.)
> […] expected humans to parse hex […]
You're assuming hex is worse than decimal with binary ranges. Why? Of course it's clear to you that the numbers go to 256 because you're a tech person. But if you know that, you very likely also know hex. (And I'll claim the disjunct sets between these are the same size magnitude.)
Anyway I think I've bulletpointed enough, there's arguments to be made, and they have been made 25 years ago, and 20 years ago, and 15 years ago, and 10 years ago and 5 years ago.
Please, just stop. The herd is moving. If anything had enough sway, it would've had enough sway 15 years ago. Learn some IPv6. There's cool things in there. For example, did you know you can "ping ff02::1%eth0"?
Yeah the at least 25 years thing is a cop out. The IPng committee specifically chose the protocol that didn't have a transition plan, and today still doesn't have a transition plan.
I expect we're going to plateau with adoption for a long while now. 50% adoption is meaningless if it doesn't tangibly make a dent in the IPv4 exhaustion problem.
Stomping your foot angrily at ISPs and Internet facing entities to adopt a protocol noone cares and/or getting governments to intervene because you've exhausted all your options and progress is stagnant is not a transition plan, that's a hail mary.
If you can't enforce a flag day then that's all you're left with, isn't it? Other than maybe hacking into people's networks, upgrading them and then somehow preventing them from undoing your work.
It wasn't even on the map until 1994. Prior to that it was an ad-hoc mess of "encryption" standards. It wasn't even important enough to become ubiquitous until Firesheep existed.
Even then SSL just incorporated a bunch of things that already existed into an extensible agreement protocol, which, in the long run, due to middleware machines, became inextensible and the protocol somewhat inelegant for it's task. 30 years later and it's due for a replacement but we're stuck with it. Perhaps slow adoption isn't a metric that portends doom.
There was a time when most devices had 1 network interface and didn't move. But that was never a guarantee. People thought it was a guarantee when your $400-in-1988-dollars Madge ISA full-height full-width token-ring NICs with dangling AUI dongles next to your tank of an ST225 hard drive were a thing, but we're past that. Today most things that aren't servers have at least 2 - wired/Wi-Fi for laptops, Wi-Fi/cellular for phones. You can talk about NAT and security and mapping all you want, but if I can bypass your corporate internal network security simply by turning off my phone's Wi-Fi, yet still get to your resources - then NAT is a legacy chore that IPv6 makes unnecessary.
Fast forward 15 years snd the situation has improved quite dramatically.
IPv6 has some quirks that make it harder to digest.
- link local gateway address, makes it hard to understand why the subnet does not have a gateway from the ssme address space
- privacy extensions: it is very hard to explain to people why they have 3-4 IPv6 addresses assigned to their computer
- multicast instead of broadcast
- way too many ways for autoconfiguration (SLAAC, DHCPv6)
- no real tentative mapping to what people were used to. Every IPv6 presentation I did had to start with “forget everything you know about IPv4”
In the enterprise space, if you mention globally reachable address space, the discussion tends to end pretty fast because “its not secure”. Those people love their NAT.
Topic drift, but for younger people who didn't live it, that's how it used to be!
For most of the 90s my workstation in the office (at several employers) was directly on the Internet. There were no firewalls, no filtering of any kind. I ran my email server on my desktop workstation to receive all emails, both from "internal" (but there was no "internal" really, since every host was on the Internet) people and anyone in the world. I ran my web server on that same workstation, accessible to the whole Internet.
That was the norm, the Internet was completely peer to peer. Good times.
On the ftp server of the company I worked for, someone had put a cracked copy of our software for their colleagues to use.
Hope you're sarcastic, because they really weren't. It was a shitshow for decades until we figured out just a bit of a clue about security practices.
By this, I don’t mean it’s more secure, because I know it isn’t. But it is a lot easier to see and to explain what has access to what. And the problem with enterprise is that 80% of the work is explaining to other people, usually non-technical or pseudo-technical decision makers, why your design is safe.
I really do think IPv6 missed a trick by not offering that.
IPv6 supports NAT [0], and nearly all routers make it easy to enable. The primary differences compared to IPv4 is that no-NAT is the default, and that it's more heavily discouraged, but it still works just as well as it does with IPv4.
[0]: In the same way that IPv4 "supports" NAT, meaning that the protocol doesn't officially support it, but it's still possible to implement.
IPv6 the protocol supported NAT just as well back then as it does now, but the software probably didn't. Which goes back to my point [0] [1] that IPv6 is a great protocol with bad tooling and documentation.
> Part of the adoption curve seems to be that it took years to abandon some of the bad ideas around IPv6 and readopt some of the better ones from IPv4.
The only abandoned IPv6 concept that I'm personally aware of is A6 records [2], but I'm pretty young, so I'm sure that there are others that I'm just not aware of. My impression from reading the RFCs and Wikipedia is that IPv6 hasn't changed very much, but that doesn't really mean anything, since I wouldn't expect for current sources to talk about concepts abandoned 20+ years ago.
[0]: https://news.ycombinator.com/item?id=47814070
[1]: https://news.ycombinator.com/item?id=44773999
[2]: https://datatracker.ietf.org/doc/html/rfc6563
You say that, but in practice it does not.
My consumer router, and every router I have configured, implicitly supports IPv4 NAT out of the box. But it will never NAT an IPv6 network. If I enable IPv6 then it operates by IPv6 rules, which means each device gets a Network ID and each Network ID gets routed directly and transparently. The router has no NAT table and no NAT settings for this protocol.
So if NAT is “supported” whatever that means, it simply isn’t possible for most end-users.
This isn't enabled by default because it's usually a bad idea, but it's certainly possible if you really want. (It's discouraged because NAT in general is a bad idea, but it's no worse with IPv6 than with IPv4; the only difference being that IPv4 effectively requires NAT.)
[0]: https://openwrt.org/docs/guide-user/network/ipv6/ipv6.nat6
[1]: https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipaddr_nat...
[2]: https://www.animmouse.com/p/how-to-nat-ipv6-in-mikrotik/
[3]: https://www.juniper.net/documentation/us/en/software/junos/i...
If you've got a car that can't go 100, that doesn't mean nobody can, or that it doesn't exist. I don't care if you can't do it, it IS supported in the spec.
For example: if roads aren’t built to support cars travelling at 100 miles per hour then it doesn’t matter how much you argue that cars are can do 100MPH, because you’re still not going to be travelling at 100MPH.
Or
But if the only cars that can travel at 100 MPH are Bugatti Veyrons then it’s safe to say that 100MPH cars isn’t something available to even the average consumer of high end sports cars.
Or
Sure, some cars can travel at 100 MPH, but they’re so unstable at those speeds that it’s not even safe to attempted it.
…You get the idea.
With NAT removed, you've still got the firewall rules, and that's fairly easy to reason about for me: Block anything from outside to inside, except X. Allow A talking to B. Allow B to receive Y from outside.
But we aren’t talking about someone technical glancing at their home routers firewall. We are talking about explaining a network topology to enterprise teams like change management, CISO, etc in large infrastructure environments.
That’s a whole different problem and half the time the people signing off that change either aren’t familiar with the infrastructure (which means explaining the entire context from the ground up) and often aren’t even engineers so need those changes explained in a simplified yet still retaining the technical detail.
These types of organisations mandate CIS / NIST / etc compliance even where it makes zero sense and getting action items in such reports marked as “not required” often takes a meeting in itself with deep architectural discussing with semi-technical people.
Are these types of organisations overly bureaucratic? Absolutely. But that’s typical for any enterprise organisation where processes have been placed to protect individuals and the business from undue risk.
In short, what works for home set ups or even a start up isn’t necessarily what’s going to work for enterprise.
Are we not? Because I suppose most people here are only disgruntled by a new protocol that changes how their home router works, and having to spend some learning effort.
For network admins in commercial settings, this is even less of an excuse. IPv6, the protocol, is fairly well documented and understandable if you put in the work to do so. And I am confident in saying it is absolutely able to deliver on any kind of corporate network scenario, even moreso than IPv4.
People at home don’t care about protocols. If the WiFi works and the TV plays Netflix or Hulu or whatever, the protocol can be anything.
Last time I “cared” was when I changed the DHCP network to not overlap with the VPN. And that was a long time ago.
Also I’m really not seeing many people here “bikeshedding” over their home gear. Are you sure you’re reading these comments and not some other IPv6 discussion? Because those conversations definitely do happen but this particular thread hasn’t gone like that.
I did make the context pretty clear when I said:
> the problem with enterprise is…
Also, you completely missed my point when you said:
> if you put in the work to do so. And I am confident in saying it is absolutely able to deliver on any kind of corporate network scenario, even moreso than IPv4.
My point wasn’t that IPv6 cannot deliver enterprise solutions. It’s that some of the design around it makes the process of deploying enterprise solutions more painful than it needed to be.
One is exactly as complicated to reason about as the other.
Except on one you don't need the trick.
A small company might have a /48. You don't have to be concerned about address space when you just go, ok, first bit is for security zones. Or first 2 bits. Or first 3 bits. Do you need more than 8 security zones?
(Also, ULAs¹ exist, and most people should use them, independent of a possible consideration to not roll out GUAs² in parallel as one would normally do.)
¹ Unique Local Address, fc..: and fd..:
² Global Unicast Address
https://en.wikipedia.org/wiki/IPv6-to-IPv6_Network_Prefix_Tr...
For example, on a normal home network, if you don't have a firewall on your router then your ISP can connect to anything on your network. Even when they don't control the router and even if you're NATing.
If you didn't realize this then apparently NAT didn't make it easier to reason about after all.
There are a bunch of ways to break it, or misconfigure it. But I have idea what this isp method is.
More concretely, they can run the equivalent of `ip route add 192.168.1.0/24 via <your WAN IP>` on a machine that's connected to your WAN network, and then their machine will send packets with a dest of 192.168.1.x to your router. Your router will route them onto your LAN because that's what its own routing table says to do with them.
Anyone on your immediate upstream network can do this, not just your ISP. Also, if you use ISP-assigned GUAs then this inbound route will already exist and anyone on the Internet can connect. Applying NAT to your outbound connections will change their apparent source address, but it won't make that inbound route disappear.
"What has access to what" is exactly what computer security is.
For example, any website can now not only log that the traffic originated from org A, but specifically from org A, workstation N.
I wonder, is privacy implication is not important enough for people to worry about this?
GeoIP databases and Cookies exist. So I'm not sure how your threat profile has increased here.
> I wonder, is privacy implication is not important enough for people to worry about this?
The most you can do over what is already possible is attempt an inventory or unit count of my office; however, you'd have to get every computer in my office to go to the same website that you control. Then you'd have to control for upgrades and other machine movements. I don't think this enables anything in particular.
Either IP/DNS/gateway discovery with one or the other could be tolerable. But allowing combinations such as SLAAC for addressing and DHCP for DNS discovery is lunacy.
It’s as if one said, let’s take the most basic and critical step and make it as complicated as possible and explore the combinatorial explosion…
https://en.wikipedia.org/wiki/Reverse_Address_Resolution_Pro...
https://en.wikipedia.org/wiki/Bootstrap_Protocol
Was also designed in the early 90s before security was taken seriously.
True, but since then it has transformed into “no one gets in because we have _private_ IP addresses”…
Extra layers is good. But it does not mean you can forgo anything else.
If security is taken seriously, I'm sure they can spend a few minutes and learn how to configure a IPv6 firewall that allows no inbound connections. It's basically the simplest configuration possible.
I don't know anything about the IPv6 situation, but the way this paragraph just slots in so innocently foreshadows some long wordy Wayland retrospective document on why adoption was so slow where someone from deep in the community slips in 1 short "sure we tried to block screenshots and that might have caused some issues with adoption for some users" paragraph in the middle-end. The innocence of the admission is so mild and context-free that it somehow manages to make itself look guilty.
For example, the IPv6 packet structure [0] is much simpler than the IPv4 packet structure [1]; SLAAC [2] is much simpler than DHCPv4 [3]; IPv6 multicast [4] is much simpler than IGMP [5]; IPv6's lack of NAT simplifies peer-to-peer networking compared to IPv4; ULAs [6] prevent the annoying address conflicts you get with IPv4 [7]; etc.
[0]: https://en.wikipedia.org/wiki/IPv6_packet#Fixed_header
[1]: https://en.wikipedia.org/wiki/IPv4#Packet_structure
[2]: https://en.wikipedia.org/wiki/IPv6_address#Stateless_address...
[3]: https://en.wikipedia.org/wiki/Dynamic_Host_Configuration_Pro...
[4]: https://en.wikipedia.org/wiki/IPv6#Multicasting
[5]: https://en.wikipedia.org/wiki/Internet_Group_Management_Prot...
[6]: https://en.wikipedia.org/wiki/Unique_local_address
[7]: https://stackoverflow.com/a/52374482/30512871
Almost all computer have multiple interface (virtual or not). Application now need to know which interface the destination is on, and there is no easy data structure to store the interface
How? They're essentially the same as IPv4 addresses; the only difference is that there are way more of them, so address conflicts are much less likely.
> Almost all computer have multiple interface (virtual or not)
Sure, but that's the case with IPv4 too: my cell phone has one IPv4 address over WiFi and another over cellular, and my laptop has one IPv4 address over WiFi and another over Ethernet.
Edit: Ah, I think that eqvinox's comment [0] is what you were getting at here. And yeah, I agree that LLAs are kinda confusing and annoying. The difference is that LLAs aren't routable [1] and don't have an IPv4 analog, while ULAs are routable and are mostly equivalent to IPv4 addresses [2].
[0]: https://news.ycombinator.com/item?id=47814154
[1]: https://en.wikipedia.org/wiki/Link-local_address
[2]: https://en.wikipedia.org/wiki/Unique_local_address
They do. You don't really see them on Linux unless configured manually, but Windows defaults (or at least defaulted in the past, my Windows-foo is very outdated by now) to a IPv4 LLA when DHCP fails.
The difference is that IPv6 requires it on every interface regardless of whether it has a different address already.
(ULAs don't need the interface specified.)
ULA: fc..:… and fd..:…
LLA: fe80:…
[ed.: By the way, sin6_scope_id is where the interface identifier is stored in struct sockaddr_in6. So, basically every single IPv6 address object you're handling has the field for it.]
The hard part is to find all the places to repeat that change, and convince the code owners to accept it. Probably start with a standard analogous to RFC 5952?
But of course, it was s very long time ago and my memory may be inexact.
IPv4 addresses in logs are not super helpful in tracking a specific person and household’s behavior long term (NAT, reuse etc.)
Almost every end user oriented IPv6 deployment makes it significantly easier to use IPv6 addresses to persistently track individual machines (ie individual people) and map them to a household (yes I’m aware of RFCs 7217 and 8981, I’m mostly talking about long term stable prefixes).
How much of a real concern this is is debatable but it’s perhaps a little bit unfortunate.
The one external IP to many internal devices relationship does help with privacy.
But once you enable those IPv6 privacy extensions, I have so many devices bouncing between IPs I’m not sure how you’d even know how many devices I have, let alone which device is which.
> Actually, we tried that: the "IPv4-Compatible IPv6 address" format was defined in {{RFC3513}} but deprecated by {{RFC4291}} because it turned out to be of no practical use for coexistence or transition.
Why/how did it turn out?
Notice how this doesn't really help you at all. You still need a functional v4 network, you still need v6 support in the kernel on both sides and your programs still need to support AF_INET6 sockets -- at which point, why not just use ::ffff:192.168.1.1 which sends packets without the tunnelling and doesn't need OS support on the far side, or 192.168.1.1 which works with AF_INET sockets and doesn't need tunnelling or any OS support on either side? This is strictly worse than the former option and less compatible than the second.
It is extremely hard (for Brian, but even more so for anyone else, I certainly can't) to give a good answer to that, since you're talking about the absence of utility. People had applications in mind but dismissed them because they either found better ways or it wasn't practical. But that very frequently doesn't result in a "paper trail".
(It's a bit like LLMs having problems with negatives/absences.)
https://stats.labs.apnic.net/ipv6/in
They report nearly a billion users, predominantly in mobile.
So, "only" 750 to 800 million users. Think about that: 3x the population of the USA using it most of the time, in one economy.
Here's the rankings:
https://stats.labs.apnic.net/ipv6/XA?o=cINw30x1r1
This is a different measure to Google's. They measure different things,
https://stats.labs.apnic.net/v6pop
Fair warning, this page is not optimized and takes a lot of resources to render.
[1] https://www.dot.gov.in/ipv6-transition-across-stakeholders Edit: hey look the govt drupal page is broken again, shocker. here is another source: https://icrier.org/pdf/IPv6_Transition.pdf
[2] The pricing pressure was _real_. 4G was the first time networks moved away from circuit switched to IP-based. So the marginal cost equation became better. And no legacy infra to support. By 2020, they also had funding from google and meta.
[3] https://broadbandindiaforum.in/wp-content/uploads/2022/08/Re...
Obviously economies that rely largely on second hand technology are going to have old technology. Much of Africa is in this bucket. But looking past the extremes, India is at nearly 80% right alongside Germany. They fall in very different average income brackets. So the correlation isn't tight.
I can't see any value in pointing out vague correlation between income and proliferation of a new technology. It's the most obvious of observations.
The problem here is that India alone would be consuming 20% of the IPv4 address space.
afaics, it probably has more to do with large indian-isp’s f.e. jio adopting ipv6.
inb4 no you can't have all lan devices have multiple ipv6 addresses and choose for themselves, typically 1 WAN is cheap and the second WAN is expensive/slow and should be used only for WAN1 failover
Inb4 no you can't just advertise new RA, devices on lan can takes minutes to update.
On ipv4, NAT+changing route on router just works, 1-2 seconds failover.
If you want "real" failover, get an ASN, your own prefixes, and run BGP. I know that's not for everyone!
Ipv6 is fundamentally broken for failover scenarios.
No it doesn't. Use the GUA from your primary ISP.
Ipv6 NAT66 is fundamentally broken, see sibling comment.
Actual solution could be extending TCP and UDP or make a new transport layer procotol that handles changing addresses, similar to what QUIC do. But we cannot do it exactly because things like NATs existing, thus QUIC build was build on ossificated UDP. Imagine if instead of IP+port a connection use unique per-connection hash to persist IP addreses changing. No more trying fighting to keep the IP the same.
All ipv4 apps that require hole punching assume they will need to "discover" the external address anyways, for every new p2p connection.
In contrast to the vast majority of ipv6 apps which assume their ipv6 address is identical to external ipv6 address, as this is(was) the main marketing point of ipv6 - directly addressable end points.
NAT is a hack that let us get 30+ more years out of IPv4, nothing more. Sadly, we now have a generation of engineers who thinks NAT is normal.
Another thing that will always trip up new IPv6 network engineers is solicited-node multicast. You know the theory, computers talk to ff02::1 for neighbor discovery and then you hop onto a real network and see none of that actually happening.
And probably the most complicated thing for network engineers - how to set up firewall rules if machines are constantly changing their addresses.
For developers and security people - just parsing and validating v6 addresses is a whole bunch more work, but at least for this, the tools are available to help you now.
Ipv4 is jsut about able still to hold in your head, have a convo or more importantly you can: "Shout an ipv4 across the open office floor from your desk to your tech colleague"
If you shout an ipv6 address in public, you jsut seem broken
Which also allowed for better route aggregation in the core BGP tables.
Better node mobility support. Better multicast support. Genuine link local addresses.
IPv4 had a lot of unfortunate edge cases. I think IPv6's greatest strength and also responsible for it's slow rollout was it's insistence on solving several of these problems at once, along with IPSec as the article notes, and hammering them into the hard requirements for the core stack.
After this I go out of my way to disable, remove and nuke ipv6, out of every setup and deployment I do. Ipv6 is already quite complicated, but supporting TWO competing network stacks, with complicated pseudo compatibility, just multiplies unnecessary complexity!
(IPv6 sockets by default accept IPv4 connections, unless you disable that either system-wide or on the specific socket.)
By the way, I do agree the colon was a really poor choice for separating the blocks, when it is also used to separate the port number.
If customer wants proper ipv6 support, we can sign a contract and talk about it. But do not expect me to support some technology for free, just because it is enabled by default.
(Worst case, you moved the problem to your finance department, for buying IPv4 address space. But even if you didn't do that, at some point sooner or later you'll get pressure to support IPv6. And then you'll have to "un-fix" everything you did, and fix the actual problem. Maybe it'll be after you're retire, but I wouldn't take bets on that.)
[ed.: best case, you moved the problem to someone else outside your company or scope. Good for you, I guess. Like the sibling post says, address space shortage is an issue for everyone, and personally speaking I would consider it rude to make it other people's problem.]
> you didn't fix anything, you just moved the problem around.
I do not get this attitude "ipv6 is inevitable". So far no customer even asked about it. We have way more urgent problems like cloudflare blocking, ddos from clankers, state regulations...
If the problem actually becomes real in like 20 years. The clankers will probably solve it in like 10 seconds. There is zero benefit right now to deal with headaches of dual routing and addressing.
I've been told that for 20+ years. Nothing has changed.
You might be right if IPv6 adoption stayed at 10% or so. But the current trend suggests that sooner or later someone is going to demand IPv6 support on your side.
Yes I did, and I no longer support that either. For my setups it is local private ipv4 networks all the way now! How tailscale or other VPN deals with that is not my problem!
If two nodes are on different networks, they should not be allowed to talk to each other anyway. Seems like security risk! Clean design, simple rules!
We are so lucky people like you aren't in charge, or we wouldn't have the internet in the first place.
I’ll also sign the “numbers bigger than 2^32” contract and a “weird looking characters in text” contract.
https://cr.yp.to/djbdns/ipv6mess.html
Edit: or maybe they added 12 more extra configuration protocols to manage, in the name of "ease of use".
Any tl;dr on why/how the simplest solution imaginable would have been "of no practical use for coexistence or transition"? Granted, I understand the other points make a strong enough case by themselves.
Being able to jam an IPv4 address into an IPv6 packet header doesn't mean you can send that packet to an IPv4-only host and have it be understood. You still need an IPv6 stack on both endpoints, and on all the routers in the middle - and at that point, why not just use IPv6 addresses?
As you can see, it doesn't actually solve anything.
It makes some APIs more convenient! You can pass this address to Linux for an IPv6 socket and it will secretly open an IPv4 connection to 10.0.0.1, so your code only has to support IPv6 sockets to support IPv6 and IPv4 connections.
It seems I've been rate limited to post every 12 hours, instead of five times per three hours. It must be either because I said interpreters don't emit native instructions, or because I said America had to buy TikTok to maintain American propaganda, or because I said you can make money gambling if your bets are the same as insiders. Or maybe I'm being punished for voting. I don't think dang will ever confirm what the reason was. Hacker News is so intransparent.
I don't understand this sentiment—as if learning IPv4 was enough work on your part, and now you're entitled to networking protocols never changing anymore.
What I learned about IPv4 at the turn of the century allows me to comfortably plan and manage networks up to a few thousand nodes, maybe a few tens of thousands.
I don't work in networking anymore. I really don't care about what those who are in that business. What you need to manage contemporary billion-node size networks and interchange between them is not my problem. You try to make it my problem, but I don't care.
I'll continue organizing the very few and very small networks that are still my responsibility using pre-CIDR ideas.
Maybe it becomes impossible some day. I'll deal with it then.
Also what’s with all the problems? I’ve had RA packets leak across VLANs via firewall misconfigurations, some my fault and some not. I get that people designing internet protocols had a lot to think about, but why am I fighting stuff like this?
There were interconnections between DECNET and Novell et al networks and IP networks etc, let alone the push from telcos etc of the OSI models.
IP hadn't "won" the networking space.
Military, corporate, tech... it isn't. (If your people like flag day migrations. It's… "a choice".) But if you have to explain to an end user why some things work and some don't, you're just f'd.
And note "coexistence" here means that an end host can implement IPv4 and IPv6 at the same time, without them interacting at all. Imagine if you had to choose between IPv4 and IPv6 on your devices, maybe something like "you need a 2nd network card". Can you imagine anyone switching to the less popular protocol?
You raise a good point that we also should't take dual- stack for granted. But I think the more precise question 'why not dual-stack as the only coexistence option' also seems like a good one, and one the article does not explore or even acknowledge
NAT64 started happening because it solves real problems — large eyeball networks, particularly mobile phone networks, didn't want to pay for twice as large table sizes on their routers and twice the maintenance effort. So they made IPv6 end hosts capable of connecting to IPv4 systems. But this is 2010 era, IPv6 was ≈15 years old at that point!
Could with approximately zero services requiring IPv6, the collapsing cost of IPv4 addressing, and it makes IPv6 very much a hidden protocol for phones. When I tether off my phone I get an IPv4 address, the phone may well do a 4:6 translate and then something else does a 6:4 translate. That doesn’t matter, I can still open a socket to 1.1.1.1 from my application.
Had IPv4 been transparently supported IPv6 wouldn’t have taken 30 years and a whole new ecosystem (phones) to get partway there.
It only gets complex if you try to micro-manage it.
Oh no, last time I asked on HN I got 24 to 48 easy steps involving a lot more acronyms than this (please don't repeat them).
IPv6 is easy to use only if you let your one router manage everything and you give up control of your home network.
Edit: again, please don't help. There have been HNers trying to help before, but my home network is non trivial and all the "easy" autoconfiguration actually gets in the way.
> give up control of your home network.
What does that even mean? What do you gain by deciding your Apple TV should be at 192.168.0.3? With IPv6, you can just `ping appletv` and it works fine. What more "control" do you need?
How many service does it take to make this work?
mDNS is quite fragile.
With IPv6 I actually want it more and it becomes possible since we can just use the MAC address as an IP address.
I have IPv6 service at my ISP right now but I'm hesitant to turn it on on my local network because it does make my firewalling concerns much more critical.
What do you mean by robustness? Isn't it really stable hostnames that you want? I don't understand how fixed IPs increase resilience (to what?).
> I'm hesitant to turn it on on my local network because it does make my firewalling concerns much more critical.
Block everything coming in from outside the network. Allow established connections. That's all there is to it.
Still want to help? :)
And really... everyone is pushing for SSL everywhere - among other things so that the ISP doesn't MITM your traffic.
Why would you allow the ISP to know what machines are inside your home network then?
What would your ISP do with the information that there are 73 unique addresses in your network at this point in time? Especially given that devices may mint any number of them for different reasons, so you can’t even really assume that corresponds to the number of physical devices in your network?
So I should cancel one of my pipes because the "commitee" overcomplicated things in the name of autoconfiguration?
> What would your ISP do with the information that there are 73 unique addresses in your network at this point in time?
Sell it of course. Good info for targeting marketing/political propaganda per household.
> I haven’t seen a bog-standard router yet that didn’t just do it out of the box.
Which one, the one from ISP A or the one from ISP B? :)
That is absolutely not what I said. It’s a more complex setup than a single connection with either protocol, and can be solved with both.
> Which one, the one from ISP A or the one from ISP B? :)
Realistically it is going to return an A record with both addresses, maybe also the link-local one, any works locally. That is a non-issue.
Same here, which is why I use DHCPv6. It's pretty easy to set up, nearly everything supports it, and it's super reliable.
The only catch is that Android refuses to support DHCPv6 for some reason, which is kinda annoying since it means that you need to keep SLAAC enabled if you have any Android devices on your network. Which means that your DHCPv6-supporting devices will end up with two addresses, but there aren't any real downsides to that.
With IPv4 you need to remember ... one number per machine. The one at the end, since it's usually a /24 and everything has the same prefix.
I'm sure it's trivial to remember mac addresses from different vendors with no connection to each other too :)
> Isn't it really stable hostnames that you want?
Hostnames are another layer. Your apple tv example may advertise itself on its own. My toys don't all do that.
My home network isn't the Internet and isn't large: DNS is a much more complicated system to keep running then just fixed IP addresses in that circumstance.
Above a certain scale, that flips but not at the home level.
I don't want all my IoT devices going down because they can't resolve hostnames - that's why I set fixed IP addresses for them. It means how they communicate with each other and my network is well-defined, and works provided they have Layer 2 (easy to keep up - it works provided any 1 AP is online, whereas my internet or the router providing it can vanish).
With IPv6 you can assign fixed unique local addresses in addition to dynamic public addresses from your ISP.
NAT is a firewall with extra steps. IPv6 reduces complexity. Privacy (illusion of it, anyway, just like in ipv4 NAT) is handled by private addresses.
…and if you really want to, NAT for ipv6 just works.
NAT changes the apparent destination address of a connection, it doesn't filter them. If a connection arrives with the destination address already set to one of your machines, NAT won't prevent it.
Any sane router also uses a firewall for IPv6. A correctly configured router will deny inbound traffic for both v4 and v6. You are not less secure on IPv6.
So firewall is actually worse than NAT.
Personally I'd count "your security thing doesn't actually do the thing it's supposed to do" as being pretty bad on the security scale. At least people understand firewalls.
Yes, that's called port forwarding and it is normal thing. You actually want that.
And concerning the NAT: That's just another word for firewall, which you still have in your router, which still needs to forward packages, and still can decide to block some of them.
Windows[0]: Static IP configuration is as simple as typing an IP address into the pretty dialog box. No DHCP required.
Linux[1]: # ip addr <ip4 address> <subnet mask> <device> will set a static IP address
>It requires assigning a range of addresses that's usually fairly small, and requires manual configuration as soon as you need more than 254 devices on a network.
Is 65,536 (172.16.0.0/16) or 16 million addresses (10.0.0.0/8) "fairly small"? Are DHCP servers unable to parse networks that "big"?
>Compare to IPv6: Nothing. All of these just go away.
They most certainly do. But they're not "problems" with RFC1918 addressing and aren't "problems" at all with IPv4.
There are many issues with IPv4 and the sooner it dies, the better. But the ones you mention aren't issues at all.
If you're going to dunk on IPv4, then dunk on it for the actual reasons it needs to go, not made up "problems."
* It was designed by people who didn't have the full picture and were missing representatives from hardware vendors, small businesses, home network admins and a bunch of other people that will be affected by design.
* It was designed by people who didn't consider the cost of migration and the amount of work that would require (see previous point).
* It was designed by people who lived in an ivory tower of "noone will run dual stack for a long time", "everyone will love to run two completely separate network designs".
* It was designed on a premise that end-to-end, fully accessbile devices are something we actually want and won't cause privacy issues.
I think it should be a study material on how standards and designs by commitee can go wrong if they're not headed by people with extensive experience across the industry with enough authority to push for good solutions.
IPv6 tried to do too much (just like many software "let's refactor this legact code") and was done by people who didn't consider all perspectives and costs (again, like many less experienced architects trying to rewrite legacy software).
It didn’t take 25 years for SSL. SSH. Gzip encoding on HTTP pages. QUIC. Web to replace NNTP. GPRS/HSDPA/3G/4G/5G They all rolled out just fine and were pretty backwards and forwards compatible with each other.
The whole SLAAC/DHCPv6/RA thing is a total clusterfuck. I’m sure there’s many reasons that’s the case but my god. What does your ISP support? Good luck.
We need IPv6 we really do. But it seems to this day the designers of it took everything good/easy/simple and workable about v4 and threw it out. And then are wondering why v6 uptake is so slow.
If they’d designed something that was easy to understand, not too hard to implement quickly and easily, and solved a tangible problem it’d have taken off like a rocket ship. Instead they expected humans to parse hex, which no one does, and massive long numbers that aren’t easily memorable. Sure they threw that one clever :: hack in there but it hardly opened it up to easy accessibility.
Of course hindsight is easy to moan but the “It’s great what’s the problem?” tone of this article annoys me.
All that's required to implement each of those is two computers: 1 client and 1 server. Whereas supporting IPv6 requires every router between the two computers to also support IPv6. Similarly, if your current software doesn't support SSL/SSH/Gzip/etc., it's pretty easy to switch to different software, whereas it's hard or impossible for most people to switch ISPs.
> GPRS/HSDPA/3G/4G/5G
Radio spectrum costs providers millions of dollars, and each new cellular protocol increased spectrum efficiency, so upgrading means that providers can support more users with less spectrum. The problem is that most of the "Western" countries still have lots of IPv4 addresses, so there isn't much cost benefit to switching to IPv6. However, China and India both have lots of users and fewer IPv4 addresses, so there is a cost benefit to switching to IPv6 there, and unsurprisingly both of these countries have really high IPv6 adoption rates.
Of all aspects of IPv6 you took the only one that doesn't complicate implementations and can easily be swapped if you wanted.
SLAAC is easily the thing I love most about IPv6. It just works. Routers publish advertisements, clients configure themselves. No DHCP server, no address collisions, no worry. What's bugging you about it?
Don't get me wrong, SLAAC also works fine, but is it solving anything important enough to justify sacrificing 64 entire address bits for?
* deriving additional addresses for specific functions is great (e.g. XLAT464/CLAT)
* you don't get collisions when you lose your DHCP lease database
* as Brian says, DHCP wasn't quite there yet when IPv6 was designed
* ability to proactively change things by sending different RAs (e.g. router or prefix failover, though these don't work as well as one would hope)
* ability to encode mnemonic information into those 64 bits (when configuring addresses statically)
* optimization for the routing layers in assuming prefixes mostly won't be longer than /64
… and probably 20 others that don't come to mind immediately. I didn't even spend seconds thinking about the ones I listed here.
"I wish to participate in a global telecommunications network and I wish to connect immediately to all my friends and be available to them 24/7 and I wish to play games with strangers across the country and I wish to receive all my email within 300ms with no spam and I wish to watch the latest news from Iran in 4K streaming Dolby"... but priiiiivacy!
Also we can always reduce the standard subnet size in 4000::/3 if we ever somehow run out of space in 2000::/3 (and if we don't then we didn't sacrifice anything to use /64s).
With SLAAC, it's just another implementation detail of the protocol that you usually don't have to even think about, because it just works. That is a clear benefit to me.
Plug in a rough router and see quickly you can find it.
What does the router do out of the box, or at all, for mdns? Isn't it a p2p service?
My ISP is Spectrum. They get a 0/10 on IPv6 support on this test page [1].
[1] https://test-ipv6.com
My only gripe with IPv6 addresses is they look too similar to MAC addresses. But as a representation, I think they’re absolutely fine.
It's a nice band-aid technology, no less and no more.
When ipv4 legacy flies around, that oclet will be null or 0. The entire internet could route just fine, especially if you put the extra octlet at the end. 1.1.1.1 gets an extra 1.1.1.1.newoctlet.
So every existing IP gets a bonus 255 new IPs, and for now, routing of those is hardlocked to that IP, and it works with all legacy gear.
In 30 years or something, we can care about the mobility of those new IPs.
You aren't the first person to come up with the idea of adding extra bits to IP addresses to make them longer. The problem isn't finding somewhere to stash the extra bits in the packet format (which is trivial; you can simply set the next-protocol field to a special value and then put the bits at the start of the payload), it's getting all software to use those extra bits -- and getting that to work requires doing all of the new AF family, new sockaddr struct, new DNS records, dual stack/translation/tunnels etc etc that v6 does.
Please consider that maybe the people working on v6 weren't actually complete imbeciles and did in fact think things through.
It is possible for the world to change, and for designs and plans and viewpoints 30+ years ago to be less correct today.
This world is not that world. That world had massive concerns about the processing cost of NAT. That was one reason for ipv6. It also had different ideas about where the net would go. We now know that the "internet of things" and "having your fridge online", as well as "5G in everything so people can't firewall it off" is just insane and malign.
We also know that tying an IP address to a person (compared to an ISP using NAT) reduces privacy. That devious and devilish actors abound.
Even though they thought these things might be neat, many of them aren't.
The processing cost of NAT is still a problem. There's that classic post by a Native American tribal ISP where it was cheaper for them to pay to replace their clients IPv4-only Roku devices with IPv6 capable Apple TVs than to upgrade their CGNAT appliance to handle the video traffic.
The concerns about the "processing cost of NAT" were edge concerns. Companies, homes, edge-devices with 100 or 1000 RFC1918 addressed devices behind them. When ipv6 was created, NAT wasn't a thing, as processing power just wasn't there.
And it was thought the processing power would never be there.
Yet now everyone has NAT in little devices at home. So the need to route 100 IPs into every person's home isn't a thing. Which is inline with my comment about how the world looked different 30 years ago, and how the concept of "IPs for everything" is the reverse of what people even want now.
You're comparing incremental rollout with migratory rollout for most of these; (not the mobile phone standards.) That's apples and oranges.
You can argue for other proposals. But at the end of the day the best you could've done is steal bits from TCP and UDP port numbers, which is... NAT. Other than that if you want to make a serious claim you need to do the work (or find and understand other people's work. It's not that people haven't tried before. They just failed.)
And, ultimately, this is quite close to typical political problems. Unpopular choices have to be made, for the benefit of all, but people don't like them especially in the short term so they don't get voted for.
> If they’d designed something that was easy to understand, […]
I can't argue on this since it's been far too long since I had to begin understanding IPv4 or IPv6… bane of experience, I guess.
> […] not too hard to implement quickly and easily, […]
As someone actually writing code for routers, IPv6 is easier in quite a few regards, especially link-local addresses make life so much easier. (Yet they're also a frequent point of hate. I absolutely cannot agree with that based on personal experience, like, it's not even within my window of possible opinions.)
> […] expected humans to parse hex […]
You're assuming hex is worse than decimal with binary ranges. Why? Of course it's clear to you that the numbers go to 256 because you're a tech person. But if you know that, you very likely also know hex. (And I'll claim the disjunct sets between these are the same size magnitude.)
Anyway I think I've bulletpointed enough, there's arguments to be made, and they have been made 25 years ago, and 20 years ago, and 15 years ago, and 10 years ago and 5 years ago.
Please, just stop. The herd is moving. If anything had enough sway, it would've had enough sway 15 years ago. Learn some IPv6. There's cool things in there. For example, did you know you can "ping ff02::1%eth0"?
I expect we're going to plateau with adoption for a long while now. 50% adoption is meaningless if it doesn't tangibly make a dent in the IPv4 exhaustion problem.
If you ignore those then sure, it didn't have a plan.
It wasn't even on the map until 1994. Prior to that it was an ad-hoc mess of "encryption" standards. It wasn't even important enough to become ubiquitous until Firesheep existed.
Even then SSL just incorporated a bunch of things that already existed into an extensible agreement protocol, which, in the long run, due to middleware machines, became inextensible and the protocol somewhat inelegant for it's task. 30 years later and it's due for a replacement but we're stuck with it. Perhaps slow adoption isn't a metric that portends doom.