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.
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.
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)
> 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.
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.
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.
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.
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.
> 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.
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.
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 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.
> First of all, IPv6 really is a conservative design - it doesn't change the basic IP model of connectionless packet switching with topological addresses.
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.
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.
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".
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.
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?
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.
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.
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.
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.
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 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.
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.
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.
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.
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 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).
> keeping backward operational compatibility
It is not possible to be backwards compatibility with a larger address space
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.
Your proposal (translation) is addressed as point 3B in the article.
And yet 50% of the internet is using CGNAT just fine. The extra bits are just in a different place.
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.
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)
> 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.
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.
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.
it’s the cost of dual stack. The transition from ipv4 to dual stack to ipv6-only goes from low cost, high cost, moderate cost.
There is little value to run dual stack.
Find me a business that would like to spend a lot of money on something of little value.
[dead]
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:
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.
Going all-in in what way?
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.
> 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.
[0] ...by everyone except Android, of course...
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.
> 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.
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.
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 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.
You could have spent a bit of time on debugging the issue. This would have been a great learning opportunity.
The headline is not confirmed in the text:
> First of all, IPv6 really is a conservative design - it doesn't change the basic IP model of connectionless packet switching with topological addresses.
related - https://news.ycombinator.com/item?id=47813631
> Just adding bits to the address isn't as simple as it seems.
They said the same in Y2K, and turned out that people were able to extend their date fields and the systems ran just fine.
You can add bits to your own systems fine.
When you want your packets to work on other people's routers, it stops being fine.
If that means those other people cannot reach the internet, then I'm sure those people will fix that faster than anything ever fixed before.
No, it means you can't reach the Internet.
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.
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.
personally I just hate this -> http://[0123::4567]:5000/whatever
This. It’s ugly.
All of talk about the technical merits or demerits misses the point. I can spout of a dozen or more memorized IPv4 addresses. IPv6? Good luck.
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.
Another option for simplicity in dual stack is to assign visually similar addresses:
I only do this for static/server machines, configuring Linux with a fixed ipv4, and append the fixed ipv6 host to the Router Advertisement prefix.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:
would become [0] I'm really not sure how to succinctly say "The autonomously-configured addresses on my LAN's ULA prefix".It’s not. It’s IPv4 with more bits and some changes to Ethernet level lookup.
The SLAAC vs DHCPv6 mess is not really a problem with the core V6 spec.
IPv4 + all the other stuff you need to actually make it work in the real world actually seems more complicated than IPv6 to me.
Maybe they’re comparing the minimal implementation on a home network. But even then I’m not sure the claim holds up.
People learned IPv4 when they were younger in a more incremental manner and take it for granted now.
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.
V4 plus one or more layers of NAT and all that junk objectively is more complicated, but it’s the devil people know.
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?
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,
a little over half the bytes of a typical IPv6 visitor's address is comparable in identification to what all four bytes of an IPv4 address tells you
> 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.
When I turned IPv6 on on my spectrum connection i ended up with like 4 different interfaces I didn’t need and broken local DNS.
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.
If it actually was v4 with more bits and different ARP it wouldn't take 30+ years to be deployed.
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.
> Any address length greater than 32 would create all the coexistence and transition problems we have experienced since 1994
This is the author’s assumption and not a conclusion. Why did the other designers even bother if this was the case?
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.
You can do NAT on IPv6. I've personally done so with both ip6tables and pf.
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 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.
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.
> Its not just NAT, it's also DHCP.
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'm not sure what you mean by "fix" DHCP
SLAAC was part of IPv6 since the original RFC, its a horribly over engineered stateless replacement of DHCP. Nobody asked for that.
What purpose do you have for NAT other than putting it where you should actually be putting a firewall?
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.
This concern is addressed in RFC 4941 (IPv6 privacy extensions).
What stops you from using NAT66 (full NAT) or NPTv6 (prefix translation)?
https://www.juniper.net/documentation/us/en/software/junos/n...
You can do it, it's just not default, which does matter too
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.
1. IPv6 does have NAT [1], NAT66.
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.
[1] https://www.ietf.org/archive/id/draft-mrw-nat66-00.html
Are you a network engineer?