FR version is available. Content is displayed in original English for accuracy.
Advertisement
Advertisement
⚡ Community Insights
Discussion Sentiment
41% Positive
Analyzed from 2772 words in the discussion.
Trending Topics
#nat#address#addresses#more#don#internet#bits#point#those#dhcp
Discussion (91 Comments)Read Original on HackerNews
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.
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.
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.
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
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 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).
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.
[1] https://www.ietf.org/archive/id/draft-mrw-nat66-00.html
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.