HI version is available. Content is displayed in original English for accuracy.
Advertisement
Advertisement
⚡ Community Insights
Discussion Sentiment
41% Positive
Analyzed from 3905 words in the discussion.
Trending Topics
#nat#address#addresses#don#more#network#dhcp#those#point#internet
Discussion (94 Comments)Read Original on HackerNews
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.
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.
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.
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.
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.
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...
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.
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.
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).
It is not possible to be backwards compatibility with a larger address space
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.
IPv6 supports that, but it ended up not getting used very much.
See https://en.wikipedia.org/wiki/List_of_IPv6_transition_mechan...
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 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.
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
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)
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.
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 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.
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.
They said the same in Y2K, and turned out that people were able to extend their date fields and the systems ran just fine.
When you want your packets to work on other people's routers, it stops being fine.
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.
> First of all, IPv6 really is a conservative design - it doesn't change the basic IP model of connectionless packet switching with topological addresses.
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.
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.
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.
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.
This is the author’s assumption and not a conclusion. Why did the other designers even bother if this was the case?
The SLAAC vs DHCPv6 mess is not really a problem with the core V6 spec.
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.
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.
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
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.
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.
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.
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.
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.
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).
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.
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.
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.
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.
SLAAC was part of IPv6 since the original RFC, its a horribly over engineered stateless replacement of DHCP. Nobody asked for that.
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
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.
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.
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.