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.
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.]
> 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.
I disagree that it would've been just as hard anyway. The people who say "I just wanted v4 with more bits" have a point that most of these arguments completely ignore, but this one touches on it:
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.
The practical use would've been going all-in on those, making it as easy as possible for users to switch. But instead, the default way of using v6 was those new addresses, also SLAAC and no NAT, and 6to4 was bolted on in a way that never worked very well.
The thing is, their objective wasn't just to add more bits, it was to defrag the old v4 routes. If you did it the "just add more bits" way, once everyone is on v6 but with the old v4 /32s, the new address space for sale is underneath those. Maybe there'd be a way to defrag afterwards in a separate effort.
How would this have worked in practice, in a way that the NAT464/NAT64 schemes that most mobile operators use haven’t? Would IANA have dedicated some blocks of IPv4 to be used for IPv4-compatible IPv6 addresses on the public internet?
Copy-paste the v4 blocks into v6 space under a common prefix, let's say 4::. Routers and software add ipv6 support (as they already have), but you only use 4::. Now once a user wants to switch, it looks the same. I'm still on NAT and DHCP. If I'm hitting Google.com on ipv6, I still use DNS4 and get 142.251.214.110, it actually sends to 4::142.251.214.110 takes the exact same route.
Time has to pass for all users to switch to v6. DNS6 and DHCP6 are in-place upgrades to the existing ones, not alternatives, so now they support longer fields. Once that's done, Google.com can say hey actually we're 142.251.214.110.1 now, and probably my ISP also gives me x.x.x.x.1.1 and leases x.x.x.x.2.2 to someone else.
You can also do all the above without the 4:: prefix. The point of that was to keep the possibility of offering all-new routes under the other v6 /8s, but that has its own friction.
This already exists in two forms, and has for basically the entire history of production dual stack deployments. The first are IPv4 mapped addresses (of the form ::ffff:x.x.x.x) which instruct the local machine’s network stack to use a local IPv4 address to communicate to the server. This still requires each machine to have a routable IPv4 address (though not necessarily a public one - it can be used with a NAT44 router).
If you don’t want the local machine to have a routable IPV4 address at all (which is a common practice on mobile networks), you can do something similar with a different prefix (usually 64:ff9b::/96) called NAT46. In this case the local machine’s network stack exclusively emits IPv6 packets, and the upstream router/network detects the prefix and performs stateful NAT using its own IPv4 address(es), just like NAT44. Depending on the use-case, the local machine doesn’t even have to understand what you’re doing at all. Instead you just have the local network’s DNS server return fake AAAA records with the corresponding 64:ff9b::x.x.x.x addresses when some particular domain doesn’t have native IPv6 support.
I want something:x.x.x.x to get routed to me over v6 if I had x.x.x.x in v4, as the default and recommended way of contacting an ipv6 host, without needing additional config or middleboxes. Neither NAT64 or NAT46 do this really, and they're presented as alternatives rather than the native way.
The closest was 6to4. rfc6343 goes into why that got deprecated. You'd either have "router 6to4" which required additional setup for more parties, or "relay 6to4" which introduced nasty failure modes. Also don't think 6to4 was meant to support cases like 2002:1.2.3.4.5 down the road.
> I want something:x.x.x.x to get routed to me over v6 if I had x.x.x.x in v4, as the default and recommended way of contacting an ipv6 host, without needing additional config or middleboxes.
Anyone with an IPv4 automatically got a 'free' IPv6 allocation:
> For any 32-bit global IPv4 address that is assigned to a host, a 48-bit 6to4 IPv6 prefix can be constructed for use by that host (and if applicable the network behind it) by appending the IPv4 address to 2002::/16.
> For example, the global IPv4 address 192.0.2.4 has the corresponding 6to4 prefix 2002:c000:0204::/48. This gives a prefix length of 48 bits, which leaves room for a 16-bit subnet field and 64 bit host addresses within the subnets.
Owning 192.0.2.4 in v4 didn't really give you 2002:192.0.2.4 in v6, as in v6 packets can't reach you that way. If someone sent a v6 packet there, some router on their side would intercept it and relay as v4. Aside from this still relying on v4, it was very unreliable in practice because of uncertainty around what v6 route is taken to the relay. There's an RFC somewhere that looked at this in hindsight.
AIUI, you encapsulate anything to 2002:192.0.2.4/48 into an IPv4 packet with "41" in the protocol field (as opposed to 6 (TCP) or 17 (UDP)) and send it to 192.0.2.4. 192.0.2.4 would then work as the relay and extract the IPv6 traffic and handle it.
You can do this quite easily on all the major OSes by opening a single dual-stack socket. On most Linux distributions that is the default, and then mapped addresses will work fine if the machine has a v4 address or a 464XLAT configuration. This has been the case for about 20 years.
Opening a dual stack ipv4 and ipv6 does allow the service to accept both ipv4 and ipv6 connections. But I do not think that is what zadikian is getting at?
It does not address the network level identity and reachability. There is no default, globally routable mapping where owning a ipv4 automatically gives you an equivalent identity in ipv6 that others can reach without translation infrastructure. The transition mechanisms are not uniform or canonical, and that increases complexity.
6to4 was an attempt at that kind of embedding and I do not think it succeeded?
The original specification of ipv6 did not directly address a translation mechanism? It seemed to rely on, well, everyone will go dual stack and we will shut down the old ipv4 stack. I think it should have addressed that in the beginning and provided the one canonical way of doing it, perhaps with guides on timelines to get the ISP and backbone providers to get on board.
I’m not clear on who is supposed to do the translating that isn’t doing it today, or why the mapped IPv4 addresses don’t qualify. Virtually all ISPs either give you an IPv4 address or do the translation for you, and the software you write doesn’t have to care exactly how it’s set up for the most part (there’s some subtlety about stuff like MTUs, but if you’re just doing unencapsulated TCP it usually doesn’t matter). It can just use whatever comes back from DNS (including using the official mapped addresses if only an IPv4 record exists) and expect the network stack to figure it out.
None of this stuff works perfectly, but it’s powering almost every mobile internet connection in the world so I don’t understand what is missing.
ipv6 was standardized in 1995
6to4 was standardized in 2001
6to4 is not used in any meaningful way today.
What was missing was ipv6 should have had 6to4 (but better) in it, in 1995.
Now, I could go on about what is wrong with 6to4, but every new topic is just another surface area for ipv6 proponents to launch another question (I sometimes suspect in bad faith).
They're allowed to do that if they want to. Most find there's no practical reason to ensure the addresses are related. It wouldn't help them support v6 faster.
Do they own such an address, as in, a packet sent by someone on another ISP to that address will actually reach my ISP's router over v6? Not talking about translations that use v4. If they do, I've never seen them actually give it to me.
Yes, they can just put your 32-bit IPv4 address after their 32-bit prefix, and that gives you a /64 as is standard. If they want to. But what's the advantage?
How would this work if your upstream router doesn't support v6? All other networks send packets towards you, but your ISP ignores them because they are invalid packets. Then what?
If you want to start using v6 before you're sure that every host supports it. But this isn't strictly needed, could just rely on something in DNS telling you the host supports it (I'm not saying AAAA records cause idk if you'd use them in this scheme).
This exists already. But how does the ipv6 packet that says 4::1.2.3.4 get through all the ipv4 routers that have no idea how to read that, to the ipv4-only endpoint that doesn't know how to read it, and even if it did know, has no way to send a packet back to the sender's ipv6 source address?
We have it already with a translator box. It's called NAT64 and almost every cellular ISP in the whole wide world uses it.
> But instead, the default way of using v6 was those new addresses, also SLAAC and no NAT...
Well, the good news is that we've had DHCPv6 and IPv6 NAT for at least like 25 years. It's true that these weren't standardized in 1995, but I always wonder how long things need to be fully supported [0] before people stop acting like they don't exist.
It took something like a decade for IPv4 to get DHCP, and I don't know how long for it to get NAT, and yet I don't hear people saying that IPv4 has no default mechanism for address autoconfiguration or network address translation.
The defaults determine what like 95% of users end up actually using, even if they have their own preference. Like you said, even if I wanted to use DHCP6, Android won't use it. My router also doesn't support it.
I'm sorry your router sucks. If -for example- my router intermittently fucked up its IPv4 NAT and sent NATted packets into the Internet Bitbucket, it would be incorrect for me to claim that IPv4 NAT sucks or isn't supported by default. The correct claim would be that my router's NAT implementation sucks.
A router messing up IPv4 NAT would make it unusable for v4. My router still works with v6, just doesn't support an optional extension of it. (Idk if the v6 spec actually says DHCP is optional, but it de facto is because slaac isn't, likewise NAT isn't even part of v4 spec but a home router will need it.)
And it's not exactly a bad thing that most routers have only one right way to do v6 addressing. One thing that's explicitly optional in v6 is default-deny firewall, which is where those "v6 is insecure" "no you're just using it wrong" fights come from:
REC-49: Internet gateways with IPv6 simple security capabilities MUST
provide an easily selected configuration option that permits a
"transparent mode" of operation that forwards all unsolicited flows
regardless of forwarding direction, i.e., not to use the IPv6 simple
security capabilities of the gateway. The transparent mode of
operation MAY be the default configuration.
You could say well the user is dumb for not changing this setting, but there's a point where you should blame the design instead of the user if it's not generating the desired outcome across many users. This also goes if you actually want the router to leave your inbound alone and let the devices do firewalling, cause your device isn't going to be reachable when you're on someone's default-deny network.
they have no point. some random aesthetic aspect of a standard is not why it does or does not get adopted. it's an evolutionary standard that offers no direct incentives for adoption.
the real obstacle was enterprise sales, that is, someone had to pay Microsoft, Google, Amazon, etc. as a major customer of theirs to implement correct IPv6, which takes time. the people at Microsoft working on ipv6 for customers, they're only going to implement the parts that customers need, they're not going to proactively discover all the bugs and fix everything. this is true about everything, i'm not saying anything that unorthodox, except...
the reason we're talking about ipv6 now is, in a post LLM world, it is now possible to take a well written and thoughtful spec like ipv6 and Just Do It. you don't have to wait for a customer relationship to do it.
Despite the lack of incentive for some, it's gotten pretty far. Pretty much every network device and host supports it in a minimal way. It's just that people/corps don't want to switch because it introduces a lot of risk and changes in unexpected areas. Like you can fully understand the spec without knowing what the routes and reputation will look like.
The only thing I can think of is making it easier to run your local network v6-only. But if you're translating at the router like that, you don't need any particular mappings.
I think this is the kind of the topic that can be endlessly debated because you can not easily go back in time and test out alternate hypothesis. I will say that I do not like ipv6 because it tried to fix multiple accumulated problems. I know! How contrarian! How can you be against trying to fix things. But all of those issues made ipv6 a dual stack solution that replaced ipv4.
Address exhaustion, Routing table scalability, restore end to end routability, autoconfiguration, header simplification, mulitcast + anycast, security standardization.
Whereas, I think a lot of those things could have been solved in other ways, or more slowly. I would have preferred a ipv4.2 64 style because it would have prioritized
Address exhaustion, keeping backward operational compatibility, fewer changes to institutional knowledge, and still had incremental rollout (that I think would have occurred much more quickly than ipv6).
You are right that a 32 bit ipv4 stack can not understand a 64 bit packet format. The thing I am trying to get at is not native compatibility, it is operational compatibility via translation. I know, I know, you will probably say that is what ipv6 bridges do.
But in an ipv42 type setup, you would have determnistic embedding so that every ipv4 address is represented inside the larger address space. This would allow translation at network boundaries and let old systems continue to operate unchanged. Then the routers and systems would be upgraded incrementally. I think that is why it would have been upgraded more quickly.
I remember reading about that a long time ago. I wonder why it never really caught on?
I think part of the problem is not so much a technical one, as a coordination issue. Who are you more likely to get on board? ISP and backbone providers. What is the path forward? Here is the recommended path forward, kind of thing.
I don't see how it matters we forced people into ipv6 as well. Who cares. It's more about the difference in mental models that prevented adoption especially among those who run the services that are on the internet.
I went and re-read point 3B. I agree that some hypothetical ipv42 faces a translation problem.
But it does not follow that address design is irrelevant. The structure of the address space directly determines whether translation can be stateless and alogrithmic.
In a hypothetical ipv42 design that preserves a deterministic embedding relationship between old and new addresses, translation at the edges could be largely stateless and mechanically reversible, to reduce coordiation overhead between operators and it makes reachability more predictable.
In our world ipv6, the transition seems to require a mix of dual stack, nat64, dns64, tunneling aproaches. The mapping between ipv4 and ipv6 is not uniformly deterministic across all deployment contexts.
Also, there is just a human factor. The mental gymnastics that go on. The perception of what is the way forward? With ipv6, it feels like everyone has to go get their ipv6 stack in order. With a hypothetical ipv42, where the ISPs and backbone providers can throw in the translation layers, it feels like, to me, they would have gotten on board much more quickly. Yeah, I know, it is just a feeling.
I agree with you about the embedded addresses, and I don't understand why the space was moved to all zeros to a bunch of other mappings.
but the utility of this isn't that high. we already know how to handle 4-4 and 6-6 traffic just fine. but if a 4 host wants to talk to a 6 host, it just doesn't have the extra bits in order to describe it, so this just doesn't facilitate 4-6 endpoint communication at all. this is true even you substitute v6 with any other layer 3 with a larger address space.
where it does help is in a unified routing backbone, that would allow v4 prefixes to be announced in the v6 routing system. which is arguably useful.
The embedding I believe you are referring to is not a part of the global routing model. (maybe I am wrong?) What I am describing is making that kind of declaration central to the system in a deterministic, network wide mapping of ipv4 to the larger ipv6 space. The translation in ipv6 ended up being handled by a mix of mechanisms after the fact, rather than a single, uniform mapping model that tied directly to the address structure. I think part of the problem is they did not put that front and center, at the beginning, when doing the initial specification.
Indeed doing it this way would keep the fragmentation, or at least delay fixing it. That's what these articles always overlook, the goal of ipv6 wasn't to just add more bits, it was also to defrag the routes.
I think instead of 1.1.1.1::, you could do 4:1.1.1.1::, wait for v4 to be gone, then start building new topologies in the other /8s. Not sure how hard that is, but it seems easier than what they're trying to do now.
Would it help at all? You can't just send IPv6 packets down the equivalent IPv4 path because that bext-hop router probably xoesn't understand IPv6 packets. In fact there could be no IPv6 path at all between you and the destination, so knowing where they are still wouldn't help you forward packets. If it understood them, it would have given you an IPv6 route anyway. Updating BGP to support IPv6 routes wasn't an actual problem.
There are lots of services I can't send v6 to, not because some router in the middle only understands v4 but because the service operator decided not to deal with v6.
So the idea is to surreptitiously install software on the service operator's machines that they can't disable?
It's already a bit like that, but they can and do disable it. You can see the other comments in this thread: many people disable IPv6 upon any sign of a networking problem.
No, the idea is you can turn v6 on/off, but doing so only changes the packet format and nothing else at first. There's no separate place to configure v6-specific settings because there are none. You use the same address, routes, DHCP, NAT, DNS, etc as v4, but you're limited to 32-bit addrs at first. The point is to just get people off v4.
Once v6 has reached enough adoption, you can turn off v4. Those who want to keep the addrs from v4 can, except now they get way more addresses under those too. Others can start building a clean new topology under the other prefixes without worrying about compatibility.
I don't see why anyone would change all the bits you actually need to change for some nebulous future gains. Still have to deal with new sockets and new routing decisions at least. To not really gain much from new features.
To me it looks like something that would have gained nearly no actual adoption outside some toy examples. Later you will need to anyway get new DNS, DHCP(or alternative) and so on.
That's a legit concern. If that's not interesting enough to the kind of user that wants all-new v6, instead start from today where some users are on the new v6 network, and say they added the 4:: prefix as a way to pick up the kind of user that doesn't want to change much. They'd still be compatible eventually. Though the reason I was thinking 4:: from the start would've been attractive enough is, a lot of people did use 6to4 and other halfway measures despite having no immediate gain.
Today's DNS6 DHCP6 etc are totally incompatible with v4. 4:: buys backwards-compatibility. Each can be updated to support longer addrs without caring whether you use it with v4 or v6.
> At least at first, you wouldn't, you'd embed all of them. Cloudflare has 1.1.1.1, so they get 1.1.1.1:: too.
Everyone with an IPv4 address automatically got an IPv6 allocation:
> For any 32-bit global IPv4 address that is assigned to a host, a 48-bit 6to4 IPv6 prefix can be constructed for use by that host (and if applicable the network behind it) by appending the IPv4 address to 2002::/16.
> For example, the global IPv4 address 192.0.2.4 has the corresponding 6to4 prefix 2002:c000:0204::/48. This gives a prefix length of 48 bits, which leaves room for a 16-bit subnet field and 64 bit host addresses within the subnets.
What does it mean to have an /48? Well, a IPv6 subnet is /64, so that's 16 bits for subnets. In IPv4 land, if you take a subnet to be /24, an allocation with 16 bits worth of subnets would be a /8.
So basically, with 6to4, every person with an IPv4 address got the equilvalent of a Class A in IPv6.
This is a fake argument. Noone is arguing for backwards compatibility.
But there was also no necessity to demand reshaping networks and changing address assignment in a way that made migration extremely work intensive and hard to deploy in parallel.
I wouldn't try to reinvent DHCP, kept NAT and generally attempted to keep the overall shape of a v6 network the same as v4 networks to ease transition of large deployments.
Ipv6 now has most of that - after years of resistance - which results in a mixed mess of "several ways to do it" approaches spiced with clients and equipment supporting a random set of them.
Yes, but CGNAT is an inherently stateful system and as a result will always be more expensive to operate per packet than a stateless router. The reason we are seeing steady (if slow) growth in native IPv6 is because the workarounds for IPv4 exhaustion cost money, and eventually upgrading equipment and putting pressure on website operators to support IPv6 becomes cheaper than growing CGNAT capacity.
How you would have implemented backward compatibility? I am interested to hear the general technical details of how this could have been possible.
I am mostly interested in two basic scenarios. With expectation that only on one side is any changes made. Host from new addressing scheme connecting to old one and receiving data back. Host from old addressing scheme connecting to one in new one and receiving data back.
There was a proposal called SIP that mostly focused on increasing address length (it got published as a historic RFC eventually): https://www.rfc-editor.org/rfc/rfc8507
It still had the problem that it made it harder for middleboxen (compared to IPv4) to look at port numbers.
> 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.
This is the only topic that tempts me to create a throwaway account. (I have not given in) None of the IPv6 proponents are willing to acknowledge that IPv6 is a pain.
All of them seem to have gone to some secret seminar somewhere where they receive their talking points:
- Everyone who dislikes IPv6 doesn't know how NAT works and thinks it's the same as a firewall.
- There's absolutely no downside whatsoever to being publicly addressable. (also this is a good time to reiterate that NO ONE understands that NAT is not a firewall)
- 128 bit addresses are exactly as convenient and memorable as as 32-bit addresses.
- The entire internet would be hosting home servers if not for the evils of NAT.
On my network, if it's not DNS, it's IPv4. IPv6 just works. I wish websites would hurry up and get with the times so I could turn off this old pile of hacks already.
> Everyone who dislikes IPv6 doesn't know how NAT works and thinks it's the same as a firewall.
It would be easier if IPvOld proponents didn't keep saying that it is. Seriously, every time this topic comes up, at least one person expresses horror at the idea of running IPv6 without a firewall, unlike their safely NAT-firewalled IPv4 setup.
> There's absolutely no downside whatsoever to being publicly addressable.
I won't say there's no downside, because such a thing is possible. It's just that I've never actually heard one outside weirdly contrived scenarios like "but what if they're not using a firewall", which is something you'd have to go out of your way to do.
> 128 bit addresses are exactly as convenient and memorable as as 32-bit addresses.
It's more realistic to say that IPv4 addresses are less horrid than IPv6, while still horrid. Who are all these people who don't like using DNS?
> The entire internet would be hosting home servers if not for the evils of NAT.
Um, true. I was on the Internet before NAT became popular, and P2P connections were the norm, not some weird thing you had to hack up with a STUN broker or such. NAT, more than any other single technology, worked to turn the Internet from a collection of peers to a producer-consumer arrangement. There's no scheme in which having the possibility of P2P connections is worse than only allowing client-server.
How do I use DNS on my home network to set up my home router? It's the same problem as TLS certificates on web interfaces for infrastructure.
And the commercial solution is going to be "pay us a subscription fee so your home device can get an Internet management interface on top of all the egregious data collection".
I think if they just double the address length the people would still cry about how 111.211.234.231.189.243.253.100 too hard to write and remember... There is no helping with people.
On extra byte shoved in a reserved field would have created 256 internets. That's two more for big countries and another for each small country and other planets. Then write in hex so addresses are shorter, require dhcp/sec etc, solved. My proposal for IPv7. ;-)
> On extra byte shoved in a reserved field would have created 256 internets.
Ah yes, the old IPv4 with 'just' adding more address byte(s) idea (you "IPv7"):
So you have to update DNS to create new resource record types ("A" is hard-coded to 32-bits) to support the new longer addresses, and have all user-land code start asking for, using, and understanding the new record replies. Just like with IPv6. (A lot of legacy code did not have room in data structures for multiple reply types: sure you'd get the "A" but unless you updated the code to get the "A7" address (for "IPv7" addresses) you could never get to the longer with address… just like IPv6 needed code updates to recognize AAAA, otherwise you were A-only.)
You need to update socket APIs to hold new data structures for longer addresses so your app can tell the kernel to send packets to the new addresses. Just like with IPv6. In any 'address extension' plan the legacy code cannot use the new address space; you have to:
* update the IP stack (like with IPv6)
* tell applications about new DNS records (like IPv6)
* set up translation layers for legacy-only code to reach extended-only destination (like IPv6 with DNS64/NAT64, CLAT, etc)
You're updating the exact same code paths in both the "IPv7" and IPv6 scenarios: dual-stack, DNS, socket address structures, dealing with legacy-only code that is never touched to deal with the larger address space.
Deploying the new "IPv7" code will take time, there will partial deployment of IPv7 is no different than having partial deployment of IPv6: you have islands of it and have to fall back to the 'legacy' IPv4-plain protocol when the new protocol fails to connect:
(This idea of "just add more addresses" comes up in every discussion of IPv6, and people do not bother thinking about what needs to change to "just" do it.)
A node having 198.51.100.42 and 7.198.51.100.42 (or 198.51.100.42.7) is dual-stack: one address is for the IPv4 protocol and other is for the IPv7 the protocol.
You need different DNS records for IPv7 and new API calls. You need Happy Eyeballs so that if 7.198.51.100.42 fails your application falls back to 198.51.100.42. It's the exact same situation.
There’s not two there’s one, the longer. There will be old equipment that can’t handle the new but would have been mostly replaced over time, perhaps a deadline. Like phone numbers or hdtv.
yeah and the global migration to add bits is already so expensive, if you're adding bits you shouls add a lot of bits so it only has to be done once. Wish they'd made it 256 bits actually, it could fit cryptographic hashes for secure routing protocols of the future.
You forgot important thing: There will always be some security guy yelling that leaking your internal IP structure is bad.
There will also be another clown that does IP whitelisting as security measure and refuses to just whitelist single /64|/24 network "because it is too wide" (I literally had this conversation last week with one of the clients)
> - The entire internet would be hosting home servers if not for the evils of NAT.
But NAT is _not_ a firewall. It's entire purpose is to allow traffic through. There's a million dozen tricks attackers can play, e.g. tricking a PC into sending traffic to some address will usually allow all traffic from that address back into one's precious network.
This is a common misconception and very dangerous -- I see a lot of people, ISPs even, who seem to think NAT is enough and you only need the firewall for IPv6.
Their NAT-phobia was legendary, and it carried through to other WGs as well like IPsec. The fact that IPsec broke NAT was a feature because it would force everyone to move to IPv6 ,for example.
The downside of publicly-addressable hosts is actually acknowledged in things like RFC 6092, but REC-49 is that routers provide a clear firewalling option that MAY be default-allow.
Works but addresses are unreadable. Ensuring security on a small network is more difficult than it needs to be when addresses are gibberish. Still not sure mine is on IPv6.
SLAAC and link-local is very different from DHCP/NAT/etc. in IPv4 world. Link-local addresses are pretty arcane in IPv4 while they are a central idea in IPv6.
That’s fine. As pointed out elsewhere, DHCP was relatively new when IPv6 was introduced. But it is a learning curve well past just knowing the difference between NAT and stateful firewall.
I installed a new bare metal server from a european cloud provider this week.
Both my clean Debian and the rescue system couldn’t reach internet through IPv6 despite getting an address through DHCP.
I immediately permanently disabled IPV6. I usually do that pretty late in my installation scripts anyway.
I understand the perfect solution didn’t exist and still doesn’t exist, but it’s frustrating. I wish IPv6 could work reliably, not only on major CDNs, and that is appreciated. Then IPv4 would be a vanishing memory.
It's supposed to Just Work on clean and rescue systems. Otherwise, it's a regression with respect to v4. The fact that it doesn't work is evidence that someone has been doing something wrong. The user at the receiving end of this clusterfuck is not that someone.
No, I did not bother because I don’t use IPv6 and I don’t plan to use it anytime soon.
Reporting an issue usually involves some effort, and the support may decide to follow up even if I say that I don’t need a fix. It’s better if someone who cares about IPv6 reports it.
Personally, i feel it is complicated because ISPs are highly afraid of trying it. I understand that such novel technology would be risky to use. But after 20+ years there are still many countries, like Spain, which are barely using it. After that much time has passed, it is already well battle-tested. At this point, you don't want to make the move either because you are too afraid of anything or you have commercial reasons.
I believe Telefonica has reasons to not use IPv6... Although in the long run is turning to be a bad decision. Look at digi :p
I think they are not afraid, they just see 0 reasons to
without IPv6: everything works already, your customers can access any website
with IPv6: ...what are the benifits to them? they still have to provide IPv4 to customers or do some ipv6 to ipv4 translation to make sure ipv4 websites still work
(I've never worked at an ISP so my opinion might be useless)
There are some reasons, which is why you do see IPv6 use increasing. IPv4 exhaustion means that almost all mobile (and in some countries landline) internet connections have to access the IPv4 internet through Carrier Grade NAT. ISPs have to buy the equipment to operate these and pay for their maintenance, and they have to do so in proportion to how much traffic is stuck on the IPv4 internet. At a certain point making the necessary investments to send more traffic over IPv6 end-to-end becomes a better bet than continuing to maintain a growing CGNAT stack.
The tough part is that while ISPs can largely control whether their mobile and residential users have IPv6 available they can’t really do so for their business users, let alone arbitrary website operators they have no relationship with. So the reality is that everyone is going to have to maintain both 4to6 and 6to4 basically forever. But as it becomes less common it’ll no longer need to be especially fast or efficient and the costs to operate it will come down.
> I think they are not afraid, they just see 0 reasons to
This is a big part of it. Apart from extra addresses, it offers remarkably little benefit in terms of networking features from an operational management perspective. It sounds like it should be better when you look at the features, but, in actual operation the features don't really offer that much.
Further, there's the general problem that for some reason the network equipment manufacturers seem to think that because you don't frequently need NAT that now you don't need to have a stateful firewall just always on by default on a network edge device.
Plus the general confusion among tech neophytes that NAT itself is offering actual security features, so that a stateful firewall is a downgrade. This is such a fundamental misunderstanding that you can't even communicate with a person that believes it to be the case. I fear that this confusion will remain with us for decades. I'm sure me even mentioning it will spawn a whole thread of people vehemently disagreeing, because there is always at least one.
This is coupled with the fact that the addresses are just ugly. Like, I'm sorry, but unless you're exactly an electrical engineer, the IPv6 addressing scheme is difficult to remember. IPv4 has the same problem -- the magic numbers are only easy to remember if you have memorized the binary values, too -- but it's really only a handful of things to remember in comparison. Hex values are just not as easy to read or remember compared to decimal numbers. So even though IPv6 isn't harder to use, it feels like it's much harder to use.
IT and telecom tend to have an ultra conservative if it’s not broke don’t fix it attitude. It won’t get deployed until enough customers ask for it or it’s required for something important.
Most v4 support is through a gateway. You can't tell the user's IP address from the wrong side of the gateway, for example - only the gateway's address. The user isn't on v4, the gateway is.
Yeah, so you still reach the user, it's just probably less efficient than the all-v6 route.
Edit: Oh, you mean if they want unsolicited inbound traffic? Sure, but that's only a thing for services. I mean you can have a default-allow firewall to home devices but really shouldn't.
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 have a /56 at the datacenter and Google Fiber gives me something like a /64 or something so I have full IPv6 connectivity everywhere. For the most part this is fine, but I've noticed the Internet is 'less reliable' on IPv6 and so in my head I still feel like it's a little iffy. There are times where a AAAA record points to an IP that doesn't respond, but the A record responds and so on. I just think it's the same as my blog's Gemini protocol server. I don't use it and offer it for fun but it's a best-effort basis. If it went down for months I wouldn't notice.
> There are times where a AAAA record points to an IP that doesn't respond, but the A record responds and so on
> If it went down for months I wouldn't notice.
you are not alone.
I am building a service to monitor such events. usual up-time monitors mostly checks the v4 address.
Man a /56 is not as big as you think. I'm an IPv6 neophyte but I'm starting to think about /64's the way I think I think about IPv4 /24's but 802.11 /24's y'know?
So Google Fiber giving a you a /64 is the same as saying - would you run your home network on a single /24. I mean ... you could but it feel like saying could you have one pair of shoes. XFinitity gives me a /60 and honestly I feel unhappy about it.
At my modestly sized job site we're easily using a couple 100 /24's - and I'm not in network operations so that number is probably wrong.
Short answer: Too many cooks in the kitchen, and too many of 'em motivated to make it more complicated.
A computer standard that is still widely avoided almost 30 years after it became official is a computer standard that should have been tossed in the bin before the ink was dry.
Despite the article title, IPv6 is not the complication. The problem is that IPv4 is incumbent and IPv6 has to live along side of it. It doesn’t matter how it’s done, the dual stack nature of expanding the addressing system will always exist.
this is why people keep inventing nonsense like ipv8 which is worse than ipv6 in every possible way but they think because ipv6 has problems and ipv8 isn't ipv6, ipv8 doesn't have exactly the same problems.
Dual stack isn't a terrible experience it's just usually bad. I wonder if more effort should have been put into making dual stack good instead of making IPv6 good?
Would that have been possible? No clue but my instinct is that most design decisions are trade offs and if you can imagine a trade there's someone out there clever enough to make it happen.
IMHO, the worst thing about dual-stack is that you have to do it at all. There are translation mechanisms but that doesn’t help when you have local devices (maybe IoT?) that don’t support IPv6.
I think that's why this new IPv6-Mostly stuff is so exciting. You can dual stack a network segment if some of those v4-only devices exist there, but IPv6-Mostly will make sure that the other devices stay on v6 (translated or native).
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.
The problems of IPv6 deployment are ones of incentives, not design.
Increasingly, the vast majority of services are accessed via the service cone of various CDNs and IAAS providers directly at edge servers local to them, and at some point it may be that the industry decides that it's not worth providing ordinary internet users the ability to talk to each other directly at all. At which point, we might just as well have stuck with IPv4. I don't particularly like that outcome, but it's possible.
I think they worked that out long ago - that segmenting users has no downside for them and IPv6 has minor upside. It's only mobile devices that help us but I'm sure there will be kinks in the chain that don't get fixed.
Or it means a ton of people can't connect to you because of your netcode preferences, and that makes your boss very upset. It'll get fixed extremely fast, and fixed means turning IPv4 back on.
> They said the same in Y2K, and turned out that people were able to extend their date fields and the systems ran just fine.
Ah yes, the old IPv4 with 'just' adding more address byte(s) idea ("IPv4+"):
So you have to update DNS to create new resource record types ("A" is hard-coded to 32-bits) to support the new longer addresses, and have all user-land code start asking for, using, and understanding the new record replies. Just like with IPv6. (A lot of legacy code did not have room in data structures for multiple reply types: sure you'd get the "A" but unless you updated the code to get the "A+" address (for "IPv4+" addresses) you could never get to the longer with address… just like IPv6 needed code updates to recognize AAAA, otherwise you were A-only.)
You need to update socket APIs to hold new data structures for longer addresses so your app can tell the kernel to send packets to the new addresses. Just like with IPv6. In any 'address extension' plan the legacy code cannot use the new address space; you have to:
* update the IP stack (like with IPv6)
* tell applications about new DNS records (like IPv6)
* set up translation layers for legacy-only code to reach extended-only destination (like IPv6 with DNS64/NAT64, CLAT, etc)
You're updating the exact same code paths in both the "IPv4+" and IPv6 scenarios: dual-stack, DNS, socket address structures, dealing with legacy-only code that is never touched to deal with the larger address space.
Deploying the new "IPv4+" code will take time, there will partial deployment of IPv4+ is no different than having partial deployment of IPv6: you have islands of it and have to fall back to the 'legacy' IPv4-plain protocol when the new protocol fails to connect:
(This idea of "just add more addresses" comes up in every discussion of IPv6, and people do not bother thinking about what needs to change to "just" do it.)
Meanwhile, if you have a database it's fairly trivial to add a new field with a four-digit year, and since you're probably only using the data internally, so your co-ordination problem is generally with-in one organization. The co-ordination problem with a new Internet protocol is global.
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.
Why are we, in 2026, still talking about ipv6? It is time to give it up and start over. Yes, it is unlikely we can agree on an ipv4 successor. But at this point we should be able to agree ipv6 is not going to be it.
What do you think should be done instead? If ipv4 but with longer addresses (which is called ipv6) is not to your satisfaction, what would be? You want to completely overhaul the internet like in ipv8 and you think ipv8 doesn't have the exact same problems and thousands more just because it's never been deployed and nobody's encountered them yet?
IPv6 is over 30 years old. The world has not embraced it. It isn’t going to. It is time to call it and try to figure out something that will work.
You do understand that one need not have a better idea to make that observation? The observation is self-evident and can exist in the world regardless of what we think about IPv6 or the feasibility of figuring out something people will want to use.
Getting defensive and playing “then you come up with something better”-games is not getting us anywhere. It is just part of the problem. It is unproductive.
That would indeed be a disaster because there is a lot of IPv6 usage and a lot more support from operating systems and hardware that has to exist first and now we should start again with something else would introduce a 3rd unsuccessful attempt with ....what benefits?
So now please get to step 2 of the argument: why do you think a world that did not embrace IPv6 (a false premise by the way, as 50% of internet traffic is IPv6) would embrace IPvBBORUD?
Again, you are not getting the argument. IPv6 is dead. It is better go give up and see what else can be done. Stop and think about what I'm saying before you react.
Are you suggesting we spend another 30 years beating a dead horse?
Java bent a lot to accommodate. There are lambdas and records which violate the old OOP rules, and now virtual threads which were sorely missing for things like web backends.
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
> First of all, IPv6 really is a conservative design - it doesn't change the basic IP model of connectionless packet switching with topological addresses.
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).
>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.
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.
There's nothing stopping you from using memorable ULA prefixes on your LAN [0] and requiring the use of DHCPv6 for addressing so that each host gets a host part that is easy to remember. Hand-selecting your ULA prefix abandons the collision-resistance that you get from using The Technique to generate one, but if that's something you don't care about, then it's something you don't care about.
Plus, manual address assignment is just as viable in an IPv6 world as it is in IPv4.
[0] fd00::/64 is quite easy to remember, as are fd00::1 and similar.
If I hadn't put my long-running machines' -er- ULA-derived [0] SLAAC addresses into my local DNS ages ago, I'd either do exactly that, or slice off the "redundant" parts of the IPv4 address off, so that I could choose to assign sixteen additional bits of addresses to each host. That is:
- ipv6: prefix:192:168:0:42
would become
- ipv6: prefix::0:42:[0-ffff]
[0] I'm really not sure how to succinctly say "The autonomously-configured addresses on my LAN's ULA prefix".
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.
I think we've been shunted into an alternate universe by NAT - one which reinforces the power of large companies because we essentially cannot communicate computer to computer without going through some service.
As for security.........are we really that secure running code in our browsers that we downloaded from who knows where? Is nat really saving us?
And now here we are with IPv6 and the real age of the network could begin.
> 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.
Because they didn't realize how that was the fundamental problem.
There are some designers who knew their system would be incompatible but thought it was interesting enough to design anyway, like RINA. There are other designers who just didn't realize why this was a problem, like ipv8. The ipv8 designer is currently berating the NANOG (north america network operators group) mailing list for not already supporting ipv8 on all networks. If it's compatible then why do they need to do anything to add support, eh?
People get emotionally attached to the name "IPv6" being bad, and don't realize how putting the same stuff in a different protocol makes that one just as bad, but without the 30 year head start. If a new proposal is about the same as IPv6 but isn't already supported by most equipment, then wouldn't it be better to use IPv6 instead?
some of the alternatives were simpler and deliberate attempts to reduce the scope of the migration problem. You can’t say “all approaches would have suffered the same migration effort” as if it’s a given. That’s like saying UTF8 and UTF16 had the same migration effort because they both tried to migrate from 1-byte code points. UTF8 was way easier.
Yeah and UTF-8 shouldn't be taken for granted. I always wondered why there's still UTF-16 in so many places, even Swift strings (apparently changed in v5)... It's cause that was the natural replacement for UCS-2, which for certain reasons was beating UTF-8 early-on.
Is it a job security issue? Greyed Neckbeards keeping things overly complex because they’ve managed to cement themselves in with IPv4 systems and anti-IPv6 talk?
ARP and DHCP really look really dirty whenever I look at them. Like pretty bad designs overall. From more neutral viewpoint it feels that whole stack would be better with something else than these clear hacks.
arp simply breaks down in very large networks aswell.
Think about things like the following:
you are a datacenter and are providing connectivity to the internet for your customers. Each customer get a vlan with a specific ip prefix attached to it. You prove the gateway for each customers subnet.
ARP crosses the L2 vs L3 boundary to do succesful address resolution. The problem this creates in large (mainly datacenter) networks is that a router needs to do arp resolution for for a LOT of networks. (i am talking about 100's of networks in past, many thousands with something like an EVPN vxlan).
Why is this a problem? Layer 2 lookups are usually done in the forwarding plane, and ARP resolution is usually a routing engine task. Doing it this way is very expensive compared to the IPV6 way of doing things. (multicast based address resolution).
The router only needs to send out one multicast packet per vlan, instead of doing arp resolution for each specific host in the vlan.
In modern datacenters this is "fixed" by doing arp suppression, which is a whole other level of hackary added on top of it.
Is there broadcast address resolution in V6? I don't think there is. Each packet is still for a specific host. It's because it leverages the layer 2's multicast system though, it can filter the multicast to only hit 1 in 2^24 hosts.
the intent behind the ipv6 spec was to remove dhcp as a requirement for establishing layer 3 connectivity. there was a generalized notion at the time that other service discovery (dns) would be handled by a more graceful multicast protocol. that was a very reasonable position to take.
but operational inertia got in the way. I don't think people really wanted to think about what a dhcp-less world would look like, even if it removed the requirement to manage a central service and the associated configuration.
this was kind of ok. but then things got ugly. people wanted to be able to get assigned prefixes dynamically from their upstream provider that they could subnet themselves. because we don't think about these issues architecturally anymore, someone put that function on dhcp. and since we don't think about these issues architecturally anymore no one really realized that that would require _another_ protocol on the inside of that boundary to manage assignments in the providers space.
and now we don't even have the option of depreciating dhcp gracefully.
The changes to Ethernet lookup mandate that you have a link-local address in addition to your “real” address, and this starts the ball rolling on the idea that machines have multiple IP addresses in general. Which makes privacy addresses commonplace, ULA+GUA addresses on the same machine, etc.
I think this is the biggest change with IPv6: that a machine’s IP addresses is no longer its identity, and you can’t easily predict what address will be used when connecting somewhere. IP-based access control becomes impossible (not that it was ever a great idea in the first place), reverse DNS lookups become irrelevant, seeing IP’s in logs no longer tells you “what machine connected here”, it’s overall a big change in mental model.
But then you get over it, stop making assumptions that you can rely on IP addresses for knowing things about a host, and the rest of it is fine.
> I think this is the biggest change with IPv6: that a machine’s IP addresses is no longer its identity, and you can’t easily predict what address will be used when connecting somewhere.
Can't you unset the "Use autonomous addressing" bit and set the "Use DHCPv6 for addressing and other config" bit in your RAs, and then refuse to hand out anything other than DHCPv6 Normal Addresses? Or do OS's ignore the fact that Temporary Addresses are an entire other category of DHCPv6 addresses and just go off and make their own "privacy addresses" off of the advertised prefix in the RA... ignoring the router's command to not use SLAAC for addressing? [0]
[0] Yes, I'm very aware that Android doesn't support anything that DHCPv6 provides other than getting an entire damn prefix delegated. For the duration of this discussion, let's ignore Android.
IME nothing pays attention to when you set a flag to not do autonomous addressing. macOS and iOS don't respect it AFAICT, I don't recall what Linux does by default, but I don't remember having any success.
But it's rather not really my point... best practices for IPv6 are to not do any of this, and you probably don't want to do it, because privacy addresses are an actually-important thing for privacy (so that sites can't correlate you easily.) You can say "oh but websites use fingerprinting anyway" (which doesn't help you when it's not a web browser you're using, but any other software that's connecting places) or "but sites don't trust the trailing 64 bits" (which only helps because everyone else is using privacy addresses, which rather proves my point.) When doing IPv6, you sort of have to abandon the idea that you're going to have a fixed, known IP address that you will use for all outbound connections. Fighting this is an exercise in pain.
> IME nothing pays attention to when you set a flag to not do autonomous addressing.
When I unset the Autonomous flag, Linux does the right thing, at least on the systems I have at hand. Android does the right thing. My Playstation 5 does the right thing. I'd be shocked if Windows doesn't do the right thing. While I wouldn't be surprised to hear that Apple devices absolutely do the wrong thing -given Apple's long history with flagrantly doing the disruptively-wrong thing in regards to networking-, based on the results I'm seeing, I expect that Apple devices work just fine. I think you came to the wrong conclusions because you fucked up your test.
> ...privacy addresses are an actually-important thing for privacy (so that sites can't correlate you easily.)
As you allude to, The Web has eleventy billion ways to track you that give absolutely zero shits about your IP address. "Privacy" addresses buy the typical user of The Internet effectively zero privacy. January's deprecation of DHCPv6 "Temporary Addresses" suggests that folks who deploy this stuff believe that this feature is far less useful than proponents might think it to be. Plus, absolutely nothing prevents a DHCPv6 server from randomly generating the host part of the addresses it hands out, as well as handing out entirely new addresses for each address request. If I believed that "privacy" addresses actually provided any meaningful privacy, that's how I'd configure mine to behave for hosts that I wasn't intentionally providing fixed addresses.
Y’know I see you in every thread about IPv6 and you have this terrible habit of completely ignoring the actual point someone is trying to make and bogging straight down into the minutiae of some technical detail instead.
I will stipulate that it’s possible to configure a network so that clients don’t set up their own addresses and use only DHCP. I will stipulate that I fucked up the configuration the last time I tried it. You’re obviously a lot more smart than me. Congratulations.
Now, yould you maybe get past that and look at my actual point, which is that multiple addresses is the expected and default behavior of IPv6, and is a big change from how people are used to doing things in IPv4? You don’t need to use every opportunity you can to flex your nerd cred at the expense of actually getting the point of what is being discussed.
> ...you have this terrible habit of completely ignoring the actual point someone is trying to make and bogging straight down into the minutiae of some technical detail instead. ... [w]ould you maybe get past that and look at my actual point, which is that multiple addresses is the expected and default behavior of IPv6...
Here's your comment's [0] second paragraph:
I think this is the biggest change with IPv6: that a machine’s IP addresses is no longer its identity, and you can’t easily predict what address will be used when connecting somewhere. IP-based access control becomes impossible (not that it was ever a great idea in the first place), reverse DNS lookups become irrelevant, seeing IP’s in logs no longer tells you “what machine connected here”, it’s overall a big change in mental model.
An attentive reader notes that I did not object to your comment's first paragraph. [1] Such a reader also notes that in your reply to me you both double down on the claim that it's impossible to centrally control what IPv6 addresses a host has, and go on to claim that even if you could it would be undesirable to do so.
[1] "The changes to Ethernet lookup mandate that you have a link-local address in addition to your “real” address, and this starts the ball rolling on the idea that machines have multiple IP addresses in general. Which makes privacy addresses commonplace, ULA+GUA addresses on the same machine, etc."
See here you go again. I'm not doubling down on anything.
My claim goes like this. Tell me where you disagree.
1. In a typical IPv6 setup you have more than one address. You even had to exclude android from the discussion just to bring up a scenario where this isn't true.
> Yes, I'm very aware that Android doesn't support anything that DHCPv6 provides other than getting an entire damn prefix delegated. For the duration of this discussion, let's ignore Android.
Yeah so as long as we ignore the largest operating system in the world by number of devices, yeah you totally are making a great point here.
2. In such a setup, things like IP-based access control become impossible (no, I'm not going to just pretend android doesn't exist, sorry), reverse DNS lookups become irrelevant, etc.
3. Yes, it is possible to configure a network such that these things are not the case, but that is not a typical IPv6 setup. There are a lot of reasons this setup is not typical, there are a lot of SHOULD lines in various IEEE specs that talk about this. Hell, even if you get your network configured perfectly, it's not going to stop a random machine from deciding to use its link-local address when talking to somemachine.local (which happens all the damned time in my network.)
It's like if someone came in and critiqued that /64 is way too huge of a subnet size in IPv6, and you responded with "yeah but you can change it and run a /96 network!" Which while technically true is also not how literally fucking anybody does IPv6 at all.
Now I wait while you attack the above with dumb fucking nitpicks about technicalities while totally fucking ignoring the point I was trying to make. Go ahead, you've done it in these threads for years.
Hon, you really need to step away from the keyboard and seek yourself some headpats, or other such comforting entertainment. I expect that -like most people- once you're able to find a way to regularly and reliably enhance your calm, you'll be better able to take critique and acknowledge when parts of your argument are substandard.
Nothing in v6 stops you giving a machine a single stable address (plus link-local). Every server on the internet has one. You can also bind a socket to a specific source address if that's what you want, because the recipient is IP-filtering.
I'm not necessarily talking about fingerprinting or tracking here, it can be something a lot more mundane. Like if I have a homelab setup and I want to see what hosts connected to something, and I look at the logs and see privacy addresses, I know I'll never know what host it was. Or if I want to set up netgroups for access control to shares or something (just a hypothetical.)
In the classic sysadmin world, the idea that an IP you see could belong to any host and you have practically zero way of knowing, is rather different from what we expect in the IPv4 world. You just have to embrace it, basically.
It's the more bits that are the problem. Anything with more bits is incompatible with the whole internet and anything that's incompatible with the whole internet won't be deployed quickly if ever. NAT is way worse than IPv6 but it got deployed quickly because it was compatible.
SLAAC and DHCPv6 actually make a ton of sense, along with the other features of IPv6. I think you need a lot of experience in both networking and applications, at many scales, to understand the design decisions and appreciate how useful they are in which contexts. That said, you could publish a clear playbook for an ISP of residential Internet for ipv6 adoption, it wouldn't change much, because they are not deciding to adopt ipv6 based on either its aesthetics or its technical merits.
SLAAC is probably one of the better improvements of IPV6.
DHCP breaks down at scale. Managing many DHCP prefixes becomes a massibe pain, SLAAC is far more scalable, far more easy to make redundant if you have redundant gateway's and protocol wise is really simple.
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.
Article does not address the elephant: there is no ability to NAT with IPv6. Sure, absolutely, you shouldn't have to NAT, but in my datacenter, NAT is a feature, not a bug. The article specifically asks "did the ipv6 designers go mad" and then they list features I've never heard of or use to prove they didn't. Those features are not why I think they went mad. The inability to create a NAT is.
For this reason, at every shop I've ever worked at, the intranet is ipv4, often with ipv6 disabled, with dual stack on the load balancer for ingress traffic. Note, I do not set it up that way: it comes like that when I've arrived.
Its not just NAT, it's also DHCP. Somehow the nerds creating IPv6 decided to not only add bytes (which is what people wanted), but also "fix" DHCP and NAT, which nobody asked for.
I'm not sure what you mean by "fix" DHCP and NAT, but FYI: RFC 3315 was published in 2003.
As far as NAT goes, it looks like iptables added IPv6 support to the MASQUERADE, SNAT, and DNAT targets in kernel version 3.7, released in 2012. IDK when other OSs added such support.
I wasn't around for the discussions at the time, but I would have asked for it if I was. SLAAC is IPv4LL, except that you usually get a globally-routable IP address from it. It's great. It's also quite a bit simpler than DHCP... "If the advertised prefix permits autonomous addressing, generate a host part in the non-fixed part of the prefix, run DAD on the generated address to ensure it's not in use, and start using it if it's not.".
> SLAAC was part of IPv6 since the original RFC...
An attentive reader notices that RFC 1883 and RFC 1971 are separated by nearly a year.
"use MDNS for name resolution" works until your machine is reattached to your LAN and your MDNS server thinks your hostname is "in use" and sticks a "-N" at the end of it to "avoid hostname collisions". Though, it might just be Avahi that has this particular bit of brain damage... I haven't paid attention to the behavior of the Macs that I've been obligated to use over the years.
Few people are more sad about this behavior than I am.
When ipv6 was first created DHCP and NAT were new and not widely deployed. They weren't trying to "fix" them, they solved the same problems independently.
And if you need NAT or DHCP, there isn't any reason you can't use them with ipv6. DHCP6 had been around for a long time.
that's not at all true. DHCP was very much part of the operational canon of the internet at the time, which is why it persisted as a model. V6 really wanted to back that out so that networks 'just worked' without depending on an administrator to manage that local service.
NAT was already in use, and a substantial motivation for the IPv6 work was to provide an alternative before it got too entrenched, which sadly failed.
it was first published in 1993. I know it was in common use because I got into into argument with one of the authors, Greg Minshall, in 1995 about how basing it on bootp was really a useless idea. and I used it at my first job which I left in 1992. I sat in on the v6 working group, and remember the discussion about what to do about it. Steve pretty much just drove the consensus as usual and no one had any real objections.
NAT is a crutch to circumvent the problem of "there are not enough addresses for each device".
I _assume_ you are referring to a default deny inbound firewall (so that devices are not reachable from the outside), but these are very different, completely orthogonal concerns (and independent of the IP version in use).
Everyone I've talked to with this opinion are typically mobile devs thinking about cell phones. Ipv6 works great there, but NATs are often used in corporate networks for isolation and in particular obfuscation. You can't tell what's behind a NAT by inspecting traffic coming from inside it like you can with no NAT networks. Some of the networks I administrate are contractually obligated to be so isolated.
I am aware that NAT is often used in corporate networks, but it does not automatically make any more sense there - the isolation is achieved by the firewall, not by NAT.
NAT (address or port translation) and a firewall (allowing traffic from/to those addresses or ports) are orthogonal concepts.
You can do NAT on IPv6, if you so desire.
It _should_ make no difference whether any adversary knows "what's behind a NAT", because it is your firewalls job to block any unwanted traffic.
Relying on "nobody knows what is inside our network so it can't be attacked" is not a viable strategy.
> I administrate are contractually obligated to be so isolated
Yeah, I've seen those contracts. They just reference a SeCuRiTy doc that's 20+ years old, and has never been re-evaluated. Things are secure because they follow the doc, not because they have actually evaluated the reasonable attack space.
I've fighting customers for years on their ideas of proper TLS usage and it's always the same thing. They've got a security doc that never changes and has never evaluated any of the trade-offs. Almost to the point that the people who wrote them choose things that increase downtime and KTLO work without helping security.
Ah-yup. The equivalent in my world is contracts that insist we make our employees rotate their passwords every 2 months or whatever, which was a popular (but still dumb) idea 20 years ago and is strongly recommended against today.
On week one of my current job, I turned that off for the whole company. Here's the citation you can give your security department to show them why they're doing it wrong.
NIST Special Publication 800-63B, the July 2025 version, section 3.1.1.2, says:
"Verifiers and CSPs SHALL NOT require subscribers to change passwords periodically. However, verifiers SHALL force a change if there is evidence that the authenticator has been compromised."
The previous version from June 2017, section 5.1.1.2, says:
"Verifiers SHOULD NOT require memorized secrets to be changed arbitrarily (e.g., periodically). However, verifiers SHALL force a change if there is evidence of compromise of the authenticator."
So 9 years ago, NIST said to stop requiring that. Last year, they clarified that to say, no, really, freaking stop it. Any company still making people do that today is 9 years out of date, and 1 year out of compliance.
Obfuscation. By inspecting packets coming from my network now you can tell what MAC addresses are in my network and also internal network topology. It's part of the reason your cell phone feels the need to randomize its MAC.
> my network now you can tell what MAC addresses are in my network
only if you're using EUI-64, but I don't think many things use that anymore. I think the only thing is cisco shit. but even then I suspect that they have RFC7217 on by default at least.
2. NAT is totally orthogonal to IP and addressing.
3. NAT (as in transparent packet modification to rewrite addresses) is utterly idiotic. Ephemeral, anonymous address allocation with inbound filtering is smart, but transparently rewriting packets to do that is one of the dumbest possible ways prone to horrible compatibility and ossification issues as has been proven empirically.
I wouldn't advertise my title as "network engineer" but having a strong understanding networking and network design has been a big part of my jobs for the last 20 years or so.
I engineer and design network device drivers and network protocol stacks.
NAT is a terrible network protocol. The correct protocol would have been a DHCP extension giving you a 49-bit address where your IPv4 address constitutes a /32 with a 17-bit unique local address.
I am reading about ipv6 nat. I guess it's possible but discouraged?
This contention point confuses me. I consistently get downvoted for this opinion, and I've seen contrarian voices online, but I have yet to meet an actual datacenter network admin who disagrees with me.
Facebook uses IPv6 virtually everywhere. They have NAT for ipv4 in dual stack (usually only on certain desktop machines), but not for IPv6 as that defeats the usefulness of it.
virtually all the datacentre is exclusively IPv6. they kinda have NAT in the sense that all the web proxies at the edge terminate the IP connections with the outside world, but thats higher up the stack rather than on the IP level.
However I never dealt with the edge stuff, as that was far away from what I was doing.
I am one, also disagree with you. Ipv6 nat is possible. I dont find nat particularly useful inside a network and dont use it unless strictly required to solve a problem like shared internet access or overlapping IP addresses. Isolation is best handled with separate physical networks, vlan or firewalls.
It's totally possible and it's totally discouraged. We are not the internet police on HN, and neither is the IETF. If you want to do weird stuff on your own network, you can and you get to keep both pieces.
but why do you want NAT? to hide whats in the datacentre?
I mean thats what reverse proxies are for, if you're that worried.
NAT doesn't give you anything useful, apart from the veneer of security. Sure it feels like your safe because there isnt a direct routable link between host A and the outside world, but thats not actually true.
If you want that, then you need firewalls and reverse proxies, even in IPv4.
* 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 personal opinion of having worked with all layers of networking for my job without developing a comprehensive understanding, is this:
We as consumers see and use the highest level, which is often https or friends, and due to the layered nature of the OSI stack, as often happens in software, if a layer is lacking in something, it gets fixed 1 or 2 layers up. If then said thing is then implemented on the layer its supposed to, its often unwelcome and just causes issues.
TCP/IP has already acknowledged this (haha) by offering UDP, on top of which you can build the network protocol of your dreams.
And people have. It's called QUIC or HTTP3. It does everything one could ask of a network protocol, with QoS, NAT punchthrough, packet based low latency/overhead comms, etc. etc.
And QUIC doesn't assume any sort of advanced mechanisms beneath, it works happily with IPv4.
And once you have everything figured out for you on the level you like to work, there's not really a need for the lower layers to pick up the slack, as long as they work reliably.
You are being downvoted because nothing you said seems to have anything to do with IPv6. It seems you think as long as it's not your problem, it's solved?
I feel like it's an entirely reasonable stance. The two valid approaches to solving a technical problem is either you try to solve all of it so that no one is concerned by it any more, or you solve as little of it as possible, but solve that part well, so there's a clear line on what's your job and what is not.
IP as a concept of 'digital PO box' falls short even if we upgrade to IPv6 - imagine talking to someone via voicechat on your phone, and moving from home Wifi to mobile data. They are two separate HW interfaces with their own identities and networking stacks, so moving your connection has to bypass the IP layer even on IPv6.
On the other hand if your job description is to shuttle packets between 'A' and 'B', where neither is guaranteed to be the actual sender or receiver, IP address becomes an implementation detail, and doing you job on IPv4 is much simpler, with the rube-goldberg stuff of actually figuring out how to connect the actual sender and recipient falling to higher level protocols.
So while I don't have strong feelings on the topic, this movement feels like a management reorg, where some business units get shuffled around, priorities change, but ultimately there's very little consistent motive or goal to the whole thing.
Personal experience that I see noone talk about with IPv6 is how much more expensive hardware that handles it correctly is for datacenters. On IPv4 your usual unit of allocation is a /32 for customers - that means a simple hashmap `1.1.1.1=destination mac` works wonderfully and is cheap (single memory lookup), but for ipv6 your usual unit is a /64 so its longest prefix match instead, which requires parsing the address to group it back into the /64 and alot of switches and routers that are already expensive still have very low limits on LPM memory banks.
Expensive switch at work we have can only do 3000 route entries for example on ipv6. If we did /128s it's basically infinite though, because it goes from a LPM to exact match, which has much much more memory available.
Doesn't help as well that for example, to be able to do SLAAC or even DHCPv6 (which barely works reliably in my experience) you need to do a /64 at minimum, those mechanisms dont even work otherwise, so for ISPs who can easily have more than 3000 downstream customers doing routed ipv6 is such an increase in hardware cost vs just doing NAT which they were already doing anyway.
Never mind the actual performance issues that I keep seeing in production deployments.
We have large networks that are essentially rolling on autopilot totally unmanaged, like Lumen'e recently sold Quantum Fiber asset that is now owned by AT&T holding company Forged Fiber 37 LLC
No native IPv6 still on this forgotten about network, 6RD keeps having weird routability issues, but if you just disable IPv6 everything works fine.
NAT requires remembering every connection pair (IPv4:port for both internal and external sides of the NAT)
You don’t need more than the /64 to know where to send traffic, all of the bits required are still just in the prefix. One route per customer… the edge deals with addressing issues.
Why on earth would you ever want to route something smaller than a /64? At the ISP level, you'd only be concerned about your customers' /48 or maybe /56 networks.
OP seems to want to route /64 or larger to each customer, but can only have 3000 total entries larger than /128 in the expensive routers his firm owns.
Essentially the hardware doesn't support scaling a /64 or /56 to each customer, leaving OP in a terrible position when it comes to proper IPv6 deployment.
When you look at Ziply Fiber, they seem to be ripping out these types of Enterprise grade routers left and right in favor of a simple Linux box doing routing. I think a large portion of why they're doing this is due to limitations like what OP is experiencing
Both of which are LPM and cause the issue I just mentioned! It's not about "routing lower than a /64" its about LPM vs Exact Match memory bank usage (and for some reason, how much more expensive good hardware that handles LPM is).
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.