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.
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 true that almost everything comes with a firewall rule that blocks new connections from the WAN to the LAN, so in practice these connections will be blocked on most things by default. But they come with this rule precisely because NAT doesn't do the job.
It is the default and default is secure. Users don't have to reason about it, they can assume it works, how doesn't matter and they may lack training/willingness to figure out.
You can't say the same for IPv6 where default is allow (have things changed?, havent checked in a long time)
Of course you can say the same for v6. Blocking connections that go from WAN to LAN by default has the same effect on both protocol families. If you assume that having the appropriate firewall rule to do that is the default then inbound connections will also be blocked on v6 by default.
NAT contributes nothing to your security in this scenario, and instead makes it harder (not easier) to understand and reason about what your router is doing.
Ah, okay. In that case v4 doesn't have a firewall by default either.
That's precisely why routers come configured with a firewall that blocks inbound connections from the WAN -- because the protocol itself doesn't have a firewall by default, and neither does NAT.
20 some years ago when cable broadband was new, you connected a computer and got public IP. For this example let's just assume it was a public/24. Back then there was no firewall built into Windows, it didn't ask you if you were connecting to a public or private network.
For some ISPs you could connect a switch or hub (they still existed with cable came out, 1gbps switches were expensive) and connect multiple computers and they would all get different public IPs.
Back then a lot of network applications like windows filesharing heavily used the local subnet broadcast IP to announce themselves to other local computers on the network. Yes this meant when you opened up windows file sharing you might see the share from Dave's computer across town. I don't recall if the hidden always on shares like $c where widely know about at this time.
ISPs fixed this by blocking most of the traffic to and from the subnet broadcast address at the modem/headend level but for some time after I could still run a packet capture and see all the ARP packets and some other broadcasts from other models on my node, but it wasn't enough to be able to interfere with them anymore.
I understand this aspect, and this conversation is tricky because most consumer routers have this barebones firewall built in to reject the routing mentioned by the OP. So what we think of as a "router doing nat" often is subtly doing more. I'd hate to call what a barebones consumer router is doing a firewall because there are important firewall features that it does not have that are necessary for security.
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.
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.)
> The nice thing about NAT is it makes the security model easier to reason about.
I first heard that relying on the 'moated castle' design of security (firewalls) was bad idea and no longer best practice a decade or two ago, and while inside/outside may be a convenient mental shortcut for security, it shouldn't be relied about.
Sure, sensible people know that NAT ≠ security, but by having private/public IPs I think it makes people's thinking lazy. Every system having publicly routable addresses (but not publicly accessible, due to SPI) would force more folks to actually examine their security controls.
It's too easy to think "ah, this has a 10.x.y.z address, therefore it's inside and safe". No, because most attacks nowadays involve compromised/ing clients, and then running around 10.x networks where people got lazy because these things are on the "inside".
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.
> IPv6 has some quirks that make it harder to digest.
Almost every point in your list is wrong.
> - link local gateway address, makes it hard to understand why the subnet does not have a gateway from the ssme address space
IPv4 has link-local addresses, too. Those are the 169.254.X.X addresses that you see on Windows machines. IPv6 adds nothing new.
> - privacy extensions: it is very hard to explain to people why they have 3-4 IPv6 addresses assigned to their computer
Well then, don’t use them. Configure the machines with one address each, just like before. If you want the (arguable) advantages of the privacy extensions, they are available, but not mandatory.
> - multicast instead of broadcast
IPv4 always had multicast, too. IPv6 is simplified by considering the broadcast concept to be a kind of multicast.
> - way too many ways for autoconfiguration (SLAAC, DHCPv6)
SLAAC is just link-local addresses, which you already mentioned above. Did you mean NDP with router advertisements?
If you did, you do have a small point, but DHCP6 is still there like always. IPv6 just offers an additional feature for the simple cases where a host just needs an IP address, netmask and a router address.
> - 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”
That’s the complete opposite of my experience. Almost everything in IPv6 works exactly the same as with IPv4.
>> IPv6 has some quirks that make it harder to digest.
> Almost every point in your list is wrong.
You missed the point and almost every counterpoint in your list is wrong.
>> - link local gateway address, makes it hard to understand why the subnet does not have a gateway from the ssme address space
>IPv4 has link-local addresses, too. Those are the 169.254.X.X addresses that you see on Windows machines. IPv6 adds nothing new.
That's not what the OP said. Note it says gateways. IPv4 when DHCP'd will show 192.168.1.1 for example when it has a 192.168.1.55 address. IPv6 will show fe23::166:8f2c:9a21:96de when it has a 2001:921:61c:aef:78f:7190:1ca2 address, despite the gateway actually being 2001:921:61c:aef::1. So its highly confusing for no good reason.
>> - privacy extensions: it is very hard to explain to people why they have 3-4 IPv6 addresses assigned to their computer
> Well then, don’t use them. Configure the machines with one address each, just like before. If you want the (arguable) advantages of the privacy extensions, they are available, but not mandatory.
While you can configure not use them, by default DHCP'd devices WILL have a bunch. Again confusing for no good reason.
>> - 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”
> That’s the complete opposite of my experience. Almost everything in IPv6 works exactly the same as with IPv4.
It's the complete opposite experience for most people, including network engineers.
You're being obtuse. Every point in the original comment is correct, you just disagree they're issues. The original comment also doesn't state they are issues just that they are differences.
• link local addresses
.Auto configuration addresses are in V4 but they are used entirely differently. Interfaces do not have link local addresses if they have a DHCP or statically configured address, in V6 it is extremely common to use a link local address as the gateway, in V4 this basically never happens.
> The original comment also doesn't state they are issues just that they are differences.
My point is that, in most cases, these aren’t differences, since IPv4 does the same thing as IPv6. Therefore, the claim that IPv6 “has some quirks that make it harder to digest [than IPv4]” is incorrect.
> Interfaces do not have link local addresses if they have a DHCP or statically configured address
I could be wrong, but I seem to recall that Windows machines always have a IPv4LL address?
> in V6 it is extremely common to use a link local address as the gateway
>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.]
> 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.
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 IPS changes my prefix once in while. I consider this a privacy feature, not a bug.
Now I find myself in a situation that my devices are not reachable anymore as when the IPv6 address changes and both DNS entries and firewall need to be updated each time when the prefix changed (In between connections break, but this might be a lesser problem)
As far as I understand the only solution which does not include some complex scripting of ip change detection and automatically updating the firewall rules is to use NAT66 and ULA. But even then I have a protocol whose most advertised feature is not to rely on NAT and puts mit fast in a situation in need to use NAT. And the privacy extension of every device or the devices using SLAC and not DHCPv6 are problematic.
IPv6 is just not able to steup efficiently for where IP addresses are changing. Not with moving mobile devices, not in wifi environments with multiple access points, not with changing prefixes, not in failover scenarios.
Bottom Line: I disabled IPv6 again here without any intentions to look for complex workarounds. All outbound traffic is now IPv4 again. IPv6 is providing no benefit but causes additional problems over IPv4 due to issues with the design. I am waiting for IPv7 (or whatever will be the next successor of IPv4) will arrive.
Are you talking about reaching the devices from inside the network, or outside?
If inside then you don't need NAT66 and ULA, you just need ULA. Use both ULA and the ISP GUAs on the network, and do your internal connections over ULA. If outside, then NAT66+ULA doesn't help because connections from outside will still fail until you update DNS for the new prefix.
NAT66 doesn't help in either situation, so why do you think you need to use it here?
> automatically updating the firewall rules
You can probably structure your firewall rules to not rely on the prefix, e.g. by doing "connections from WAN to LAN where the address matches ::42/-64" -- you might to write it with a mask instead (::42/::ffff:ffff:ffff:ffff), which looks awful but works fine. There's no point in putting a specific prefix into the rule if you're just going to change it to match the network anyway.
It'll prefer ULAs when connecting to hosts without A records. Programs will use ULAs if you connect to an IP literal, or if connecting to the A records fails. Also, Linux/glibc will prefer ULAs if you have a ULA assigned to the machine, and so will anything using the update to RFC 6724. So "ULA won't be used at all" is definitely not correct.
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?
This is a great idea. To slightly sidetrack things: I think updating computer UI text selection behavior to not break click/snap-to-next selectable words on colons without padding spaces in general would be a good thing.
"A: B" would still click-select either "A:" or "B", but "1:2" (a ratio) would select the whole thing, as would "small:med:large" or an ipv6 address. In other words, I think that, in practice, English writing has assigned semantic significance to space-less colons in enough cases that text selection systems should reflect that.
Though I'm not sure RFCs are going to drive general GUI behavior--they won't "MUST" it, because that's overstepping, and I'm not sure GUI/OS-text-selection-functionality maintainers will be persuaded otherwise.
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.
> 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.
One of the major issues with IPv6’s design and development is that the people who designed it do not operate networks, nor do they build networking products. They literally fly around the world to committee meetings for a living.
Critical use cases like this are missed and/or ignored because they do not fall within the committee members’ ivory tower world view.
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!
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.
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.
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.
That might well have been a more immediately pressing issue, but they did know that v4 was going to be too small and that they still needed to work on v6.
I might be saying something obvious here, but address space exhaustion and size of the core routing table are really two sides of the same problem anyway. The way to keep the routing table size down is to give everybody a small number of big allocations instead of a big number of small allocations, but that consumes more address space since the allocations have to be rounded up to at minimum the next integer power of 2 (and really more, to accommodate growth).
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.
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.
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.)
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.
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.
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.
My experience is that this is largely true only of the biggest ISPs in the US and Europe that were around in the 90s and have IPv4 in plenty. In other countries or even with other ISPs I see fairly frequent turnover.
Agree it’s not the biggest deal but it is a pity and something the protocol stack around IPv6 should support (daily/weekly randomizing of prefix unless someone needs the stability). The vast majority of modern devices and usecases get no additional value from being stably addressable from the internet.
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
>Getting IPv6 to about 50% deployment has taken more than 25 years. Any alternative or new proposal would be the same.
That is oversimplified a few things. The 50% deployment is largely Mobile Phone + Cloudflare and India. ( Not sure about China ). Outside of that things aren't that different from a high level overview.
You could have 50% deployment in less than 10 years if 6G Mobile Phone mandate the use of let say IPv8.
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).
I would be easier to accept if it was just an extension of IPv4. Make the addresses longer but keep the types A,B,C,D. Keep the network address x.x.x.x/y. That way everybody will be familiar with it and change will be done smoothly.
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!
Ah, right, that one with all the ALGs. Kinda NAT64's ancestor, though I have no idea of the evolution/development process.
I don't believe this ever worked at scale, even if it is pretty much NAT64. Particularly the part where IPv4 hosts can reach IPv6 systems with the NAT-PT tracking through DNS what is given out in A records is "a bit much".
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.
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.
> 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.
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.
NAT doesn't apply to inbound connections if you don't have a matching port forward rule, so it kind of doesn't matter how NAT works here. This is pure routing, not NAT.
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."
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?
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.
I think most of the web wasn't encrypted by default until letsencrypt came on the scene just over a decade ago. (I remember a few "free cert" offerings that were entirely manual, and cost you $200 if you wanted to revoke a cert)
It's firmly the default now, and very odd if a site doesn't default to https.
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.
> 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"?
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.
None of that has anything to do with what you said in the post I replied to. "Add an extra octet to v4 addresses" has hard technical barriers to deal with if you want it to work, regardless of what the world looks like or what you're designing for.
> 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
None of this is really relevant either. IP's job is to handle the addressing used when sending data over the Internet, and it should do this job well regardless of what people end up doing with it.
> We also know that tying an IP address to a person (compared to an ISP using NAT) reduces privacy
We don't tie IP addresses to people. PI allocations might sort of count, but regular users don't get those.
None of that has anything to do with what you said in the post I replied to.
Of course not, why would it? I quoted what I was replying to, and all of my comments made perfect sense in that context. In that context, I was discussing the winning ipv6's original design considerations, and yes "IPs for everything" was one of them, hence me talking about it.
I intended the quoted part to mean something like "they did consider adding extra octets to v4 addresses and setting those octets to zero to mean v4".
It's not like they weren't able to come up with that idea. It's just that if you follow that train of thought through to its conclusion, you'll either decide it can't work or you'll make enough changes to end up with something that works basically the same way v6 does.
But yes, having enough IPs for everything was obviously a design goal. It would be excessively silly to go through all the work to increase the address size and not increase it by enough to handle whatever people ended up wanting to do with it.
> 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.
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.
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.
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 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).
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.
Same! I even had my home network on a public /24.
The good ol’ days. Same. Had a public IP on my computer, could SSH into it to read my mail.
That I still do, but now it goes through a firewall, a bastion host and a second different firewall.
i still do this today!
You run a mail server on a residential IP? I thought that pretty much guarantees non delivery nowadays?
> Good times.
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.
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.
[0]: https://news.ycombinator.com/item?id=47814070
[1]: https://news.ycombinator.com/item?id=44773999
[2]: https://datatracker.ietf.org/doc/html/rfc6563
Just because it technically supported something in some RFC it doesn't mean you could get affordable and capable equipment supporting it.
> IPv6 supports NAT
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.
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.)
[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...
IPv6 DOES support 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.
…You get the idea.
That is the same argument with USB, USB support x, but 90% of USB dont implement it. In reality that is no different to not supported.
NAT is evil!
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.
> and that's fairly easy to reason about for me
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.
That would be my take as well, but feel free to read some of the sibling comments here, eager to bikeshed over the IPs of their equipment.
HN users aren’t typical home users.
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.
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.
Have you tried that?
I have yet to see a router that allows that forwarding unless explicitly configured. Still, i'm using mostly openwrt/opnsense/mikrotik
Default is to disallow/block forwarding packets from public wan to private range lan.
ISP can still inject packets on ports that NAT opens if it spoofs the source address/port, so you still have some validity to argument.
Yup, repeatedly.
It's true that almost everything comes with a firewall rule that blocks new connections from the WAN to the LAN, so in practice these connections will be blocked on most things by default. But they come with this rule precisely because NAT doesn't do the job.
> Yup, repeatedly
Cool, me too :)
Anyway, the other side of the argument:
It is the default and default is secure. Users don't have to reason about it, they can assume it works, how doesn't matter and they may lack training/willingness to figure out.
You can't say the same for IPv6 where default is allow (have things changed?, havent checked in a long time)
Of course you can say the same for v6. Blocking connections that go from WAN to LAN by default has the same effect on both protocol families. If you assume that having the appropriate firewall rule to do that is the default then inbound connections will also be blocked on v6 by default.
NAT contributes nothing to your security in this scenario, and instead makes it harder (not easier) to understand and reason about what your router is doing.
> If you assume that having the appropriate firewall rule to do that is the default
That's the thing, it's not the default, default is public ipv6 for everyone and its the users duty to configure firewall...
I could definitely set this up easily, someone like my parents or friends would ask me 'what's IPv6?'
Ah, okay. In that case v4 doesn't have a firewall by default either.
That's precisely why routers come configured with a firewall that blocks inbound connections from the WAN -- because the protocol itself doesn't have a firewall by default, and neither does NAT.
20 some years ago when cable broadband was new, you connected a computer and got public IP. For this example let's just assume it was a public/24. Back then there was no firewall built into Windows, it didn't ask you if you were connecting to a public or private network.
For some ISPs you could connect a switch or hub (they still existed with cable came out, 1gbps switches were expensive) and connect multiple computers and they would all get different public IPs.
Back then a lot of network applications like windows filesharing heavily used the local subnet broadcast IP to announce themselves to other local computers on the network. Yes this meant when you opened up windows file sharing you might see the share from Dave's computer across town. I don't recall if the hidden always on shares like $c where widely know about at this time.
ISPs fixed this by blocking most of the traffic to and from the subnet broadcast address at the modem/headend level but for some time after I could still run a packet capture and see all the ARP packets and some other broadcasts from other models on my node, but it wasn't enough to be able to interfere with them anymore.
I understand this aspect, and this conversation is tricky because most consumer routers have this barebones firewall built in to reject the routing mentioned by the OP. So what we think of as a "router doing nat" often is subtly doing more. I'd hate to call what a barebones consumer router is doing a firewall because there are important firewall features that it does not have that are necessary for security.
NAT is a statefull firewall with a trick.
One is exactly as complicated to reason about as the other.
Except on one you don't need the trick.
NAT is state tracking with a trick, but not firewalling. It doesn't block connections, so it's not a firewall.
Not in the context I was describing.
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.
Is it really identical when the receiving party can now identify every workstation at your internal network and track them separately?
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?
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.
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.)
¹ Unique Local Address, fc..: and fd..:
² Global Unicast Address
Pretty much the only way I've seen a /48 split in practice is to get 256 /56 (one per site) then 256 /64 (one per VLAN).
/52 and /60 are quite common as well, predictably what with falling on a "letter boundary" and all
Interesting. I've only seen /60 when they're trying to split up a /56, and IMO it's a little unclean.
> The nice thing about NAT is it makes the security model easier to reason about.
I first heard that relying on the 'moated castle' design of security (firewalls) was bad idea and no longer best practice a decade or two ago, and while inside/outside may be a convenient mental shortcut for security, it shouldn't be relied about.
Sure, sensible people know that NAT ≠ security, but by having private/public IPs I think it makes people's thinking lazy. Every system having publicly routable addresses (but not publicly accessible, due to SPI) would force more folks to actually examine their security controls.
It's too easy to think "ah, this has a 10.x.y.z address, therefore it's inside and safe". No, because most attacks nowadays involve compromised/ing clients, and then running around 10.x networks where people got lazy because these things are on the "inside".
It is absolutely a thing in IPv6 as well, but why would you do that.
https://en.wikipedia.org/wiki/IPv6-to-IPv6_Network_Prefix_Tr...
For exactly the reasons I stated
> But it is a lot easier to see and to explain what has access to what.
"What has access to what" is exactly what computer security is.
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!
https://en.wikipedia.org/wiki/Reverse_Address_Resolution_Pro...
https://en.wikipedia.org/wiki/Bootstrap_Protocol
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.
> IPv6 has some quirks that make it harder to digest.
Almost every point in your list is wrong.
> - link local gateway address, makes it hard to understand why the subnet does not have a gateway from the ssme address space
IPv4 has link-local addresses, too. Those are the 169.254.X.X addresses that you see on Windows machines. IPv6 adds nothing new.
> - privacy extensions: it is very hard to explain to people why they have 3-4 IPv6 addresses assigned to their computer
Well then, don’t use them. Configure the machines with one address each, just like before. If you want the (arguable) advantages of the privacy extensions, they are available, but not mandatory.
> - multicast instead of broadcast
IPv4 always had multicast, too. IPv6 is simplified by considering the broadcast concept to be a kind of multicast.
> - way too many ways for autoconfiguration (SLAAC, DHCPv6)
SLAAC is just link-local addresses, which you already mentioned above. Did you mean NDP with router advertisements?
If you did, you do have a small point, but DHCP6 is still there like always. IPv6 just offers an additional feature for the simple cases where a host just needs an IP address, netmask and a router address.
> - 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”
That’s the complete opposite of my experience. Almost everything in IPv6 works exactly the same as with IPv4.
>> IPv6 has some quirks that make it harder to digest. > Almost every point in your list is wrong.
You missed the point and almost every counterpoint in your list is wrong.
>> - link local gateway address, makes it hard to understand why the subnet does not have a gateway from the ssme address space >IPv4 has link-local addresses, too. Those are the 169.254.X.X addresses that you see on Windows machines. IPv6 adds nothing new.
That's not what the OP said. Note it says gateways. IPv4 when DHCP'd will show 192.168.1.1 for example when it has a 192.168.1.55 address. IPv6 will show fe23::166:8f2c:9a21:96de when it has a 2001:921:61c:aef:78f:7190:1ca2 address, despite the gateway actually being 2001:921:61c:aef::1. So its highly confusing for no good reason.
>> - privacy extensions: it is very hard to explain to people why they have 3-4 IPv6 addresses assigned to their computer > Well then, don’t use them. Configure the machines with one address each, just like before. If you want the (arguable) advantages of the privacy extensions, they are available, but not mandatory.
While you can configure not use them, by default DHCP'd devices WILL have a bunch. Again confusing for no good reason.
>> - 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” > That’s the complete opposite of my experience. Almost everything in IPv6 works exactly the same as with IPv4.
It's the complete opposite experience for most people, including network engineers.
You're being obtuse. Every point in the original comment is correct, you just disagree they're issues. The original comment also doesn't state they are issues just that they are differences.
• link local addresses
.Auto configuration addresses are in V4 but they are used entirely differently. Interfaces do not have link local addresses if they have a DHCP or statically configured address, in V6 it is extremely common to use a link local address as the gateway, in V4 this basically never happens.
> The original comment also doesn't state they are issues just that they are differences.
My point is that, in most cases, these aren’t differences, since IPv4 does the same thing as IPv6. Therefore, the claim that IPv6 “has some quirks that make it harder to digest [than IPv4]” is incorrect.
> Interfaces do not have link local addresses if they have a DHCP or statically configured address
I could be wrong, but I seem to recall that Windows machines always have a IPv4LL address?
> in V6 it is extremely common to use a link local address as the gateway
What? I have never seen this.
> What? I have never seen this.
What? Never? Is extremely common. I just checked both my Mac and Windows desktops and they both show a link local gateway.
It makes me question whether you've used IPv6 all that much.
>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.
> 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”…
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.
Okay, so you configure a firewall. NAT is not required.
To be fair it's a pretty decent defense, in the early days of blaster and today with iot crap.
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.
[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
ULA give more trouble than what it solves.
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
> ULA give more trouble than what it solves.
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
> LLAs (...) and don't have an IPv4 analog
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.]
> 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.
And that's what you should do, since you're forcing the protocol update you should take the opportunity that might not come later
In hindsight though, and really also in foresight, it didn't work out that way.
Didn't happen. The swamp aside, Traffic engineering drives most disaggregation. Better in some senses, but not orders of magnitude better I think.
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 IPS changes my prefix once in while. I consider this a privacy feature, not a bug.
Now I find myself in a situation that my devices are not reachable anymore as when the IPv6 address changes and both DNS entries and firewall need to be updated each time when the prefix changed (In between connections break, but this might be a lesser problem)
As far as I understand the only solution which does not include some complex scripting of ip change detection and automatically updating the firewall rules is to use NAT66 and ULA. But even then I have a protocol whose most advertised feature is not to rely on NAT and puts mit fast in a situation in need to use NAT. And the privacy extension of every device or the devices using SLAC and not DHCPv6 are problematic.
IPv6 is just not able to steup efficiently for where IP addresses are changing. Not with moving mobile devices, not in wifi environments with multiple access points, not with changing prefixes, not in failover scenarios.
Bottom Line: I disabled IPv6 again here without any intentions to look for complex workarounds. All outbound traffic is now IPv4 again. IPv6 is providing no benefit but causes additional problems over IPv4 due to issues with the design. I am waiting for IPv7 (or whatever will be the next successor of IPv4) will arrive.
Are you talking about reaching the devices from inside the network, or outside?
If inside then you don't need NAT66 and ULA, you just need ULA. Use both ULA and the ISP GUAs on the network, and do your internal connections over ULA. If outside, then NAT66+ULA doesn't help because connections from outside will still fail until you update DNS for the new prefix.
NAT66 doesn't help in either situation, so why do you think you need to use it here?
> automatically updating the firewall rules
You can probably structure your firewall rules to not rely on the prefix, e.g. by doing "connections from WAN to LAN where the address matches ::42/-64" -- you might to write it with a mask instead (::42/::ffff:ffff:ffff:ffff), which looks awful but works fine. There's no point in putting a specific prefix into the rule if you're just going to change it to match the network anyway.
If you’re dual stack, your OS will prefer IPv4 to ULA and ULA won’t be used at all, and so the extra config overhead of deploying ULA is pointless.
It'll prefer ULAs when connecting to hosts without A records. Programs will use ULAs if you connect to an IP literal, or if connecting to the A records fails. Also, Linux/glibc will prefer ULAs if you have a ULA assigned to the machine, and so will anything using the update to RFC 6724. So "ULA won't be used at all" is definitely not correct.
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?
This is a great idea. To slightly sidetrack things: I think updating computer UI text selection behavior to not break click/snap-to-next selectable words on colons without padding spaces in general would be a good thing.
"A: B" would still click-select either "A:" or "B", but "1:2" (a ratio) would select the whole thing, as would "small:med:large" or an ipv6 address. In other words, I think that, in practice, English writing has assigned semantic significance to space-less colons in enough cases that text selection systems should reflect that.
Though I'm not sure RFCs are going to drive general GUI behavior--they won't "MUST" it, because that's overstepping, and I'm not sure GUI/OS-text-selection-functionality maintainers will be persuaded otherwise.
This is the most pro-IPv6 comment I could ever imagine. I am more persuaded now than by the IPv6-is-easy guys all these years.
Fwiw opera mobile on Android selects the whole address there when i long-press
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.
> 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.
One of the major issues with IPv6’s design and development is that the people who designed it do not operate networks, nor do they build networking products. They literally fly around the world to committee meetings for a living.
Critical use cases like this are missed and/or ignored because they do not fall within the committee members’ ivory tower world view.
The actual solution is network prefix translation. You effectively NAT the primary network when failed over to the secondary. See https://docs.netgate.com/pfsense/en/latest/recipes/multiwan-... for an example.
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!
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.
"Directly addressable endpoints" is how the Internet is supposed to work. It's how it did work for anyone who grew up with the 90's Internet.
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.
Can you just NAT66?
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.
> NAT66 implies using fd00::/8
No it doesn't. Use the GUA from your primary ISP.
You can change the priority.
Pretty sure BGP exists. NAT, also.
BGP is not for everyone: get an ASN, your own prefixes, and run BGP. Compare that to the simplicity of ipv4 NAT.
Ipv6 NAT66 is fundamentally broken, see sibling comment.
If you ever find a cellular carrier who will do BGP over LTE for a retail customer, let me know.
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.
That might well have been a more immediately pressing issue, but they did know that v4 was going to be too small and that they still needed to work on v6.
I might be saying something obvious here, but address space exhaustion and size of the core routing table are really two sides of the same problem anyway. The way to keep the routing table size down is to give everybody a small number of big allocations instead of a big number of small allocations, but that consumes more address space since the allocations have to be rounded up to at minimum the next integer power of 2 (and really more, to accommodate growth).
India on around 80% in the apnic labs active measurement of end users.
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,
if you want population measurements, there is a APNIC page for that too.
https://stats.labs.apnic.net/v6pop
Fair warning, this page is not optimized and takes a lot of resources to render.
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]
[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...
Now compare average income to see how much this matters.
Depends what you are selling and to whom. Meanwhile, India wanted to get a lot of people online and this appears to suit their needs.
This has nothing to do with income.
The problem here is that India alone would be consuming 20% of the IPv4 address space.
I'm confused. What's your point?
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.
very transparent.
what has _that_ got to do with ipv6 adoption/usage ?
afaics, it probably has more to do with large indian-isp’s f.e. jio adopting ipv6.
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.
Why/how did it turn out?
> Why/how did it turn out?
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.)
Try it and see!
(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.
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.
An interface can have many ipv4 addresses as well. It's just not that common, so many people believe they'd need vlans to achieve that.
Yes. But it's quite an uncommon setup. For IPv6 multiple addresses is the default.
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.
My experience is that this is largely true only of the biggest ISPs in the US and Europe that were around in the 90s and have IPv4 in plenty. In other countries or even with other ISPs I see fairly frequent turnover.
Agree it’s not the biggest deal but it is a pity and something the protocol stack around IPv6 should support (daily/weekly randomizing of prefix unless someone needs the stability). The vast majority of modern devices and usecases get no additional value from being stably addressable from the internet.
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
>Getting IPv6 to about 50% deployment has taken more than 25 years. Any alternative or new proposal would be the same.
That is oversimplified a few things. The 50% deployment is largely Mobile Phone + Cloudflare and India. ( Not sure about China ). Outside of that things aren't that different from a high level overview.
You could have 50% deployment in less than 10 years if 6G Mobile Phone mandate the use of let say IPv8.
"The IPv6 mess" by DJB
https://cr.yp.to/djbdns/ipv6mess.html
How I wish that djb time stamped his articles, as I feel like this article is over a decade old but I can’t tell with certainty.
https://web.archive.org/web/20021203075817/https://cr.yp.to/...
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).
That's because the problems he's describing come from v4 rather than v6, and v4 hasn't changed in a long time.
It's not like anything has changed, except the running out of IPv4 part.
Edit: or maybe they added 12 more extra configuration protocols to manage, in the name of "ease of use".
I would be easier to accept if it was just an extension of IPv4. Make the addresses longer but keep the types A,B,C,D. Keep the network address x.x.x.x/y. That way everybody will be familiar with it and change will be done smoothly.
It basically did, just in hex...
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!
NAT64 is a subset of a different thing that existed since 2000 though, when v6 was ~5 years old and before most OSs even had support for it.
What would that "thing" be?
See RFC 2766.
Ah, right, that one with all the ALGs. Kinda NAT64's ancestor, though I have no idea of the evolution/development process.
I don't believe this ever worked at scale, even if it is pretty much NAT64. Particularly the part where IPv4 hosts can reach IPv6 systems with the NAT-PT tracking through DNS what is given out in A records is "a bit much".
Because the internet was still a "network of networks".
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.
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.
And packet forwarding was done in hardware pipelines, can't software update them to handle new protocols.
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.
> at some point sooner or later you'll get pressure to support IPv6
I've been told that for 20+ years. Nothing has changed.
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!
You are so very incredibly wrong about absolutely everything here.
> If two nodes are on different networks, they should not be allowed to talk to each other anyway.
We are so lucky people like you aren't in charge, or we wouldn't have the internet in the first place.
Yeah, I’ll sign a contract so you can “support” a configurable bind address. That’s post-doc level of comp-sci stuff right there.
I’ll also sign the “numbers bigger than 2^32” contract and a “weird looking characters in text” contract.
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.
inet_pton/inet_ntop handle AF_INET6.
> 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.
It's not. I learned how IPv6 worked SO LONG AGO that I really can't understand remaining confusion.
It's not complicated because you understand it? Okay then
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.
Yes, processes changed. Because you don't need NAT, mainly. Overall it's simpler, with more bits in the addresses.
if it was easier to use and less of a PITA, it wouldn't be taking decades.
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.
> especially with SLAAC
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?
> you can just `ping appletv` and it works fine.
How many service does it take to make this work?
mDNS is quite fragile.
I haven’t seen a bog-standard router yet that didn’t just do it out of the box.
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.
> I mean generally I want fixed IPs on my local network for robustness.
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.
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?
> Aside from being a fairly exotic setup for personal use anyway.
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? :)
> So I should cancel one of my pipes because the "commitee" overcomplicated things in the name of autoconfiguration?
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.
> 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.
> since we can just use the MAC address as an IP address
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.
That’s kind of my point, though. There is no reason at all to remember IP addresses.
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.
At the home level, you have a home router that can do mDNS out of the box. All devices are reachable by their hostname.
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).
> I mean generally I want fixed IPs on my local network for robustness.
With IPv6 you can assign fixed unique local addresses in addition to dynamic public addresses from your ISP.
What firewalling? You don’t have an ipv4 firewall?
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.
the internet, in very large volume, disagrees. Am I not allowed to document the widely held common sentiment?
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.
So, like ipv4, but you lose the protection and privacy afforded by the NAT?
What protection? What privacy? Smoke and mirrors, mostly.
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.
It's the illusion of a firewall too.
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.
Misconfigured firewall is a gaping hole. Misconfigured NAT is not letting data from outside into your local network.
So firewall is actually worse than NAT.
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.
> Even a correctly-configured NAT will let connections in from outside, and a lot of people don't understand this.
Yes, that's called port forwarding and it is normal thing. You actually want that.
It will let them in without a port forward in place. The port forward just rewrites the IP on an incoming connection, nothing more.
If you can reuse opened connection, but that will work with firewall too.
You don't need any tricks like that. Regular new connections will work.
No it won't because that's not how NAT is working.
It will, and if you test it then it does.
NAT doesn't apply to inbound connections if you don't have a matching port forward rule, so it kind of doesn't matter how NAT works here. This is pure routing, not NAT.
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.
>IPv4 requires a DHCP server.
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."
The dhcp server is in the router, just like you need a router for slaac.
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.
> Instead they expected humans to parse hex, which no one does
Of all aspects of IPv6 you took the only one that doesn't complicate implementations and can easily be swapped if you wanted.
Wait til you’ve got to copy & paste em, or see em comingled with hw addresses
Wait till you find an application that accepts 1.65793 as an IPv4 address. Or 134744072.
(by the way, this was way less of a dumb peculiarity back when IPv6 was designed)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'm not disagreeing that's a bad aspect of IPv6, I'm just saying that it's not that big of a issue for its adoption.
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?
* privacy addresses are great
* 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.
Privacy addresses... Isn't it silly to talk of privacy if the prefix doesn't change?
Absolutely schizo.
"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.
When it fail, you find there is no option to tune its behaviour.
Plug in a rough router and see quickly you can find it.
What kind of failure are you referring to? What would you want to tune? You can still easily locate all devices on your network.
I like the ability to
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.It’s a no-brainer with SLAAC and mDNS, which is what pretty much all home routers do out of the box.
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?
> It didn’t take 25 years for SSL.
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.
I think most of the web wasn't encrypted by default until letsencrypt came on the scene just over a decade ago. (I remember a few "free cert" offerings that were entirely manual, and cost you $200 if you wanted to revoke a cert)
It's firmly the default now, and very odd if a site doesn't default to https.
> What does your ISP support?
My ISP is Spectrum. They get a 0/10 on IPv6 support on this test page [1].
[1] https://test-ipv6.com
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.
Good idea–on my list of to-check items.
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.
> 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"?
how do you encode 128 bits without making a long number? and not using hex?
Far easier to use ipv8, which just has 5 octets instead of 4.
That still means replacing every part of the chain.
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.
Pray tell me exactly where in the IP packet you put those extra octets. In a way that it affects zero other devices?
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.
None of that has anything to do with what you said in the post I replied to. "Add an extra octet to v4 addresses" has hard technical barriers to deal with if you want it to work, regardless of what the world looks like or what you're designing for.
> 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
None of this is really relevant either. IP's job is to handle the addressing used when sending data over the Internet, and it should do this job well regardless of what people end up doing with it.
> We also know that tying an IP address to a person (compared to an ISP using NAT) reduces privacy
We don't tie IP addresses to people. PI allocations might sort of count, but regular users don't get those.
None of that has anything to do with what you said in the post I replied to.
Of course not, why would it? I quoted what I was replying to, and all of my comments made perfect sense in that context. In that context, I was discussing the winning ipv6's original design considerations, and yes "IPs for everything" was one of them, hence me talking about it.
I intended the quoted part to mean something like "they did consider adding extra octets to v4 addresses and setting those octets to zero to mean v4".
It's not like they weren't able to come up with that idea. It's just that if you follow that train of thought through to its conclusion, you'll either decide it can't work or you'll make enough changes to end up with something that works basically the same way v6 does.
But yes, having enough IPs for everything was obviously a design goal. It would be excessively silly to go through all the work to increase the address size and not increase it by enough to handle whatever people ended up wanting to do with it.
> 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.
You misunderstand.
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.
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.
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.
Easier if you’re a native English speaker. Harder if you’re not.
My only gripe with IPv6 addresses is they look too similar to MAC addresses. But as a representation, I think they’re absolutely fine.
fair point about native english speakers, but there's also no reason this scheme can't be localised
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.
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.
Well, other than the transition plans that it has and still has. The exact same plans that the other options like TUBA had.
If you ignore those then sure, it didn't have a plan.
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 is like it is because:
* 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).