About two years ago, when we deployed our datacenter, I insisted for IPv6 first.
All out management network is IPv6 only, all kvm, switches, routers...
It was a pain and gives nearly no practical advantage (at the time), but the motivation was to make everyone "intimate" with IPv6. We learned a lot and we even discovered some implementation bugs (for example, Cisco default link local address is not /64 and this is not compliant with more recent RFC and will make them unable to communicate with BSD systems).
Now we have IPv6 everywhere and everybody from dev to sysadmin is aware of IPv6 and we start to see some real advantages. VPN are easier to manage, routing is easier, firewall is easier, clustering, failover... everything is "cleaner".
We still have IPv4 (dual stack) on some servers, but about 80% of them are IPv6 only with DNS64/NAT64.
It's obvious that a major reason more people don't do this is a lack of instant payoff.
Indeed, but also not everyone gets the payoff that GP did. We did IPv6 only and abandoned it after a while because there were some show-stoppers in our cloud provider that didn't work (at the time, this was a few years ago). It ended up being a good investment in the two people spearheading the work, but otherwise was a waste of time/money.
Same applies for directory services, configuration management, etc. Eating vegetables
All those give me a clear advantage in the long run. What’s the advantage for me with ipv6?
One past employer of a friend has an internal network using IPv4 only. Every night a database query runs on one database and updates a second database based on the results (a DSS updated from a data warehouse, I think). One of the TCP connections involved goes through five levels of NAT, internally to the company.
No one on the team liked adding the fifth NAT, but no one felt confident enough to undo any of the old NATs either.
If you use IPv6 internally you don't dig yourself into holes like that one. You have enough addresses that you can choose clarity and maintainability in little day-to-day choices and a few years later that clarity has added up.
I don't know you as well as I should :) I should say I'm not that interested in selling something that is both free and 'politically' loaded.
People have made up their minds, they'll pick it up or they won't. No "skin off my teeth" at all. Implementation details matter to those who care. They have their reasons, I'm not one to question them.
One of the things I like about v6 is it allows us to give up the charade or vanity of addressing. At least minify it. One can define classes of networks and simply identify hosts by MAC (or FQDN assuming an AAAA record).
I already have to tote that information around to configure them. Having a v4 address can be seen as duplicating the role of identity, while risking conflict. Outright removal of v4 may offer benefits in some scenarios.
Now... 'conflict' is how BGP anycast literally works. Two or more hosts announce the same location. There are perfectly valid reasons to still use v4, neither precludes the other.
Why is it now easier to manage?
No translation, no subnet allocation issue (because no scarcity), global reachability from everybody to everybody (as internet was meant to be), no overlap (because no RFC1918)
The world is much easier when everybody has its own identity.
I'm not the OP, but I expect VPNs are easier to manage because you don't have to worry about slicing up the very, very limited IPv4 non-public space and puzzling out how to resolve addressing collisions between all of the various networks you have to manage. With IPv6 you can just calculate a /48 ULA prefix and allocate /64s for your VPNs (and every other internal network) out of that. If ever you run out of room, just calculate another /48 and carry on... easy!
You are a shining example!
What do you use for a NAT64 gateway?
Not GP but in similar setups I've had good success with using the FWs (typically Fortinet or Palo Alto) as the NAT64 gateway. Hosted services that require 1:1 NATs also end up there anyways so it's a good fit for DC.
Outstanding. As Google’s IPv6 traffic portion approaches 50% (https://www.google.com/intl/en/ipv6/statistics.html) it’s clear IPv6 is here, now, today. I wouldn’t dream of launching a new public-facing greenfield project without it.
Nothing's realistically dropping support for v4 any time soon, so v6 support is optional. On the other hand, we're far, far away from all users supporting v6, so v4 support is not optional.
Running a single IP stack is infinitely simpler and easier than running two concurrently, and until that "single IP stack" can be v6, I see very little reason to support it.
I didn't recommend dropping IPv4. It's a terrible it to start a new project in 2024 without IPv6 support though. It's easy enough to build in from the beginning that there's not any real reason not to go for it.
And running a dual stack is trivially easy for almost everyone using it. That chart has almost half of Google's users coming in via IPv6. I promise you less than 1% of that 50% have ever even heard of IPv6, let alone done a single thing to configure it. With my ISP I'd have to go out of my way to turn it off, which I haven't done because this isn't 2008 where it broke things more often than never.
> It's a terrible it to start a new project in 2024 without IPv6 support though.
Why? Radical complexity reduction at essentially no cost to yourself or your customers seems like a tempting proposition.
Exactly! IPv4 management is hideous compared to IPv6 once you grok it. The sooner you upgrade to it, the sooner you can deprecate horrid mitigations like NAT.
Out of curiosity, what parts of NAT management tend to be so horrible in practice?
The fact that it exists. I was a network engineer before NAT became a common thing and remember how it use to be when nodes on the network were legitimately peers. NAT is a bletcherous band-aid for the fact there are more people than 32 bit numbers. Now we're seeing true abominations like CGNAT. That stuff needs to be lost to the realm of scary legends told late at night.
I was asking about practical issues, not just complaints of subjective ugliness. While I'll grant that CGNAT can be pretty bad (though not entirely indefensible for mobile networks), I don't think we can ever return to "every node being a peer" in any case, not when any typical network will have a firewall that denies incoming connections.
>I don't think we can ever return to "every node being a peer" in any case, not when any typical network will have a firewall that denies incoming connections.
Forgive me if I'm missing something here, but how is that any different WRT IPv4 vs. IPv6?
In both cases, except for those services one wishes to expose to the Internet (assuming one has a use-case for that), all incoming connections should be blocked, IPv4 or IPv6.
Or are you arguing that NAT masquerade confers some sort of security benefit on one's network that precludes the necessity of blocking incoming connections?
I'd argue that NAT (N:1 or 1:1) doesn't provide any security benefit. Nor does IPv4+NAT reduce the complexity of firewall rules as compared with IPv6.
In fact, I'd posit that NAT makes things more complicated and not less. That said, you can use NAT/NPT[0] with IPv6 (along with ULA/SLAAC) if you really want.
As such, I'd say that IPv6 provides the best and worst of IPv4, plus additional benefits.
IF we ever get completely off IPv4, that will be a good day.
I don't think I'm disagreeing with you regarding firewalls: what I was trying to say is that "every node being a peer" isn't a good argument against NAT, since these days it holds neither in IPv4 nor in IPv6, now that everything has a firewall in front of it.
> In fact, I'd posit that NAT makes things more complicated and not less.
Sure, it clearly adds some iota of additional work, but I've never seen it as being the worst thing in the world. I'm young enough to have never witnessed the legendary paradise of globally-reachable static IPs for everything, so it seems more like "just the way things are". And yet there is widespread hatred against the existence of NAT, and I can't tell if it's primarily ideological, or if NAT is causing real practical difficulties for many setups. (Though at least the issues with CGNAT are easy to see. And also with broken NAT implementations.)
Meanwhile, one might argue that things like SLAAC in IPv6 can similarly add conceptual difficulties compared to IPv4. E.g., "How do I identify some particular device in my network, if its link-local IP is changing on a regular basis?" (To which the answer is something DNS-like, I guess?) So switching a network's internal operations from NATted IPv4 to NATless IPv6, with all of its different mechanisms, would seem like more of a tradeoff than an unequivocal win.
I mean adding IPv6 support doesn't make nodes "legitimate peers". NAT still exists in a v4+v6 world; there will always be a distinction between "nodes with a public v4 address" and "nodes without a public v4 address".
You're missing the point, I believe intentionally. You can't get away from IPv4 as long as you have users who can't access IPv6-only servers. All your users and potential users can access IPv4-only servers.
> All your users and potential users can access IPv4-only servers.
Not all servers are user-accessible. For instance, a database server or a NAS server might only be accessed by other servers within the same organization. Using IPv6 between these internal-only servers, instead of RFC 1918 addresses, can simplify things.
And can make things far more complex too. You now need people to understand both ipv4 (for your public facing) and ipv6 (for your internal ones).
Instead you could just choose ipv4 only and reduce a lot of complexity. Sure there are also downsides -- if you're in a large org and are running out of RFC1918 space, or you're rationing it to smaller than /24 networks, that can be a pain (I don't see a benefit of more than 256 host addresses on a subnet as that's already far to large a broadcast domain)
Obviously. I thought it was clear enough that I was takling about public-facing servers, since I talked about the capabilities of users' devices.
> You can't get away from IPv4 as long as you have users who can't access IPv6-only servers.
That depends on your definition of "can't get away from". Your users can live on a IPv6 only lan and have the IPv4 world available to them. IPv6 supports 4 in 6 - ie you can embed IPv4 addresses in IPv6, so all you need is a gateway that translates IPv4 to IPv6 for them.
I've done it. At a conference, to unsuspecting users. All phones support IPv6 well, so they didn't notice. Not one complaint - I was blown away by how well it all worked.
It was done because some noisy attendees insisted on being assigned routable IP addresses. That can be difficult to provide with IPv4 for obvious reasons, whereas ISP's will happily hand you thousands of billions of IP{v6 routable addresses, for free.
I set up the gateway myself, rolling my own using a linux box I had lying around. Adding the 4 in 6 capabilities is maybe an hours work on top of all the other setup you have to do on the box, and that includes googling to find what tools you need and how to configure them. It's not hard.
On the other hand only your edge load balancers need dual-stack, everything behind them can be v6-only.
I think you're misunderstood what you quoted:
> It's a terrible it to start a new project in 2024 without IPv6 support though.
That does not preclude ALSO supporting IPv4.
Remember that for many technical folks out there, the default is "Only do IPv4 support" which is (IMO) just batshit stupid.
(Do also note that the sentence immediately prior to the one you quoted is "I didn't recommend dropping IPv4.".)
As you know, we have two options:
1. Support IPv4 and IPv6.
2. Support only IPv4.
#2 has essentially no downsides and is radically simpler.
That's my point. It's not terrible to start a new project without IPv6 support, because adding IPv6 support adds a ton of complexity for almost no benefit.
I never claimed or insinuated that you recommend dropping IPv4. If I thought your recommendation was to drop v4, my argument about the complexity of dual-stack would've made no sense.
> I never claimed or insinuated that you recommend...
Check my handle. I'm not who you seem to think I am.
> ...adding IPv6 support adds a ton of complexity for almost no benefit.
That doesn't at all match my experience with IPv6 support in greenfield projects for the past decade+. You actually have to do extra work to make them IPv4-only. Remember that the statement you initially responded to said "It's a terrible it to start a new project in 2024..."
> > I never claimed or insinuated that you recommend...
> Check my handle. I'm not who you seem to think I am.
Sorry, I didn't notice. Pretend I said "they" rather than "you".
> > ...adding IPv6 support adds a ton of complexity for almost no benefit.
> That doesn't at all match my experience with IPv6 support in greenfield projects for the past decade+. You actually have to do extra work to make them IPv4-only. Remember that the statement you initially responded to said "It's a terrible it to start a new project in 2024..."
Huh, I never found it difficult to ... not add an AAAA DNS record to point to a server. It surprises me that you find that to be extra work.
> Huh, I never found it difficult to ... not add an AAAA DNS record to point to a server.
Have you attempted to make greenfield software written in 2024 support only IPv4 addresses and be deliberately incompatible with IPv6 addresses? It's a lot more work than just using what the standard libraries give you and just getting support for v4 and v6.
I have actually made a green field project in 2024 and created a VPS for it and not added an AAAA record to point to that VPS, it was pretty easy to not add that AAAA record, I could do it in my sleep (in fact I do spend most of my nights not adding AAAA records to anything)
Now the software itself would probably work v6 if you set up the infrastructure for it, but that's not what I'm talking about. (I don't know for sure that it works with v6 though, never tested)
I know for sure that I've written some software before which doesn't work with IPv6 because the buffer I pass to gethostbyname is 4 bytes, but to be fair I haven't written such software in 2024. I have also written software to configure a device's interfaces and routing tables which only does DHCP4 and only configures v4 addresses, but that was in 2023 not 2024, maybe dhcp4 would've magically worked with IPv6 if I had done it this year
> Running a single IP stack is infinitely simpler and easier than running two concurrently
I’d say it’s marginally simpler. Unequivocally it’s quantifiably simpler. But infinitely simpler? That’s a pretty tall claim to make.
[deleted]
Depends on your users; there are, for instance, plenty of phones that only natively have v6 and have to use NAT64 to reach v4 websites. So if you have such users, there might be a benefit to supporting v6 directly.
As you said though, those users can reach v4 websites.
There are already cases of Internet connectivity issues due to overloaded CGNAT. I know for a while I could only visit IPv6 websites, IPv4 technically works but the amount of packet drops meant that my IPv4 internet speed was only about 15KB/s!
It's the whole reason why I discovered a DNS server that synthesizes AAAA records, for websites that actually support IPv6 through their CDN. [0]
> As you said though, those users can reach v4 websites.
Therefore, the question is: Can those users really reach IPv4 websites?
Mind you, I don't expect the CGNAT-overloading issue to relieve over time -- unless we deploy IPv6 everywhere ;)
yes, with the increased latency of having to travel to the NAT64 server first. This can also cause you to not use the nearest CDN, etc.
Its easier to get good latency and bandwidth over v6 than natted v4
What is the latency or bandwidth bottleneck in nat v4?
Taking the detour to the NAT.
NAT registers in the microseconds for packet processing time, that isn’t even comparable to Internet path jitter.
You mean that the packets go through a router? They would do that regardless though?
Your typical router shouldn't fill up its port mapping table. In fact, the 4th layer isn't involved at all so "ports" don't even exist as a concept.
> Nothing's realistically dropping support for v4 any time soon […]
Or potentially ever, as predicted when IPng was being originally thought about:
We believe that it is not possible to have a "flag-day" form of
transition in which all hosts and routers must change over at
once. The size, complexity, and distributed administration of the
Internet make such a cutover impossible.
Rather, IPng will need to co-exist with IPv4 for some period of
time. There are a number of ways to achieve this co-existence
such as requiring hosts to support two stacks, converting between
protocols, or using backward compatible extensions to IPv4. Each
scheme has its strengths and weaknesses, which have to be weighed.
Furthermore, we note that, in all probability, there will be IPv4
hosts on the Internet effectively forever. IPng must provide
mechanisms to allow these hosts to communicate, even after IPng
has become the dominant network layer protocol in the Internet.
Why build today with deprecated technology ? Build your infra v6-only, add a layer at the edge to support old clients via IPv4. Job's done.
You should design your infrastructure to avoid paying too much for other people's legacy.
I personally push for IPv6-only internal networks whenever possible, and have deployed several such designs in datacenters.
Unfortunately, a lot of applications are building on platforms where IPv6 is an afterthought if even present at all. Take for example Azure, where IPv6 support is a fucking joke. From core services like Route Server not supporting it, to it being impossible to build v6-only networks due to forced v4 subnet and vNIC requirements, to many services that Microsoft provides only running on v4.
As much as I want to push IPv6 everywhere, that physically cannot happen until companies support it for all use cases. In the mean time dual stacking can be better than nothing but the complexity is non-trivial when the alternative is just running straight v4...
IMO the separate-stack nature of ipv6 was a mistake. I can see why they did it, but the changes could've been a lot more incremental otherwise, and we might've been done already. Everyone talks about the biggest change being the 128-bit address space, but the real leap is that pre-existing ipv4 blocks weren't preserved in ipv6.
The changes couldn’t have been more incremental. Routing hardware only understood the IPv4 header (and at that time I believe a lot of this was baked in silicon). There was no way to create an IPv4+ without needing to replace all the internet’s routers before it could reliably work.
How would have it made it easier to migrate when all of the new blocks wouldn’t be accessible (in either direction) if the traffic passed through any router that hadn’t yet been upgraded? Nobody could really use any of the extended space at all until every single router had been upgraded to this IPv4+.
It is a common misunderstanding (I hear “we could have just made IPv4 bigger” a lot) but apart from the routing issues above (needing to replace every router before it could work at all), the endpoints are also a problem. Nothing in the expanded space could actually call out to a legacy IPv4 endpoint - it could sent packets to it, but that legacy host wouldn’t be able to return packets back since it wouldn’t understand the larger address. And of course the legacy endpoint couldn’t initiate a connection to anything in the extended space either from its side.
So you not only have all the same problems of IPv6 (like needing to upgrade everything), you actually add a bunch of problems of breaking the ability of big parts of the internet from being able to communicate with the rest.
Dual-stack was necessary because everything couldn’t be switched over on the same day. If everything was upgraded at once, your extended-IPv4 idea would work, but otherwise it would break the internet!
They are, though?
It's how dual stack sockets work, they just map IPv4 into the part of IPv6 where they belong.
But then you're still using ipv4.
I'm on a laptop on an ipv6 only subnet at the moment which mostly does the job with dn64/nat64.
The only benefit of this is to increase familiarity with ipv6. I'm trying to push some colleagues to do an ipv6 only section of our network which has limited interconnect, but there's a lot of concern about devices that still don't support ipv6, and ultimately what's the business reason to do it compared with subnetting 10.0/8 and natting at your firewalls
I'm very happy to not have to know what dns64 and nat64 is.
And many people are happy to not know what an IP address is either. That's fine.
I find it amazing how that lack of curiosity about how computers work extends into modern software developers, I guess that the majority of the industry nowadays are people that do things like "bootcamps" and go into it for the money.
I have no need for ipv6, however I wanted to know about it so spent a couple of hours setting myself up with it. I don't bother with the latest fads that last 3 or 4 years and then are replaced by a new fad, but ipv6 has been around long enough that it's clearly not a fad.
I have plenty of curiosity around how computers work. I've implemented compilers and interpreters, designed CPUs (I made a RISC-V CPU in Logisim which could run programs compiled with clang!), designed ISAs, back in university I had a lot of fun both writing a networking stack from almost-scratch (starting with only C and the raw ethernet packet API in Linux, building toy versions of ARP, IP, routing daemons and TCP) and writing a toy kernel, I have an ongoing game project where I'm writing the engine from scratch in C++ and using plain OpenGL to render, and this past year I've taken up PCB design and CAD. All this just because I want to learn stuff and make stuff. Don't assume that just because someone doesn't share your particular interests, they lack curiosity.
IPv6 has been around long enough that it's clearly a failed project. It's been 30 years and it hasn't even breached 50% adoption. It's not even at the hard part yet, which will be the long tail.
>IPv6 has been around long enough that it's clearly a failed project
You have a very radical definition of "failed". Take your emotions out, and perhaps you would get a more objective evaluation of the technology.
For one, it's very clear that IPv6 has only, truly received global attention after the depletion of IPv4 address space -- someone has already linked the Google IPv6 adoption page, go have a look at it, look at the flat line before 2012. That means we have spent about of 10~15 years of time deploying IPv6, not 30 years, and getting to 50% adoption in such a time period is not what I'd describe as a failure.
Secondly, if you are defining failure as "less than 50% prevalence in 30 years" then HTTPS before 2014 will probably fall under the same category too. (Don't underestimate the age of SSL/TLS.)
Do you consider HTTPS a failure?
The only way this stuff trickles down to the masses is people that know what they are doing forcing it on them through their products. Very, very few 'engineers' actually go out and learn the state of the art these days in my experience, with most just culting around whatever the current marketing fad is.
Hell just look at SDWAN land and everyone acting like it is the second coming of jesus when it is just a fancy marketed version of technologies that have been available for decades.
IPv4 stuff is accessible over IPv6. It's just the other way around that is not the case.
Not by default it’s not. An ipv6-only deployment cannot natively access an ipv4 network, there is no backwards comparability in the protocol.
I get that you're trying to make a point, but NAT64 makes this not a real problem. Every practical use of IPv6 can access IPv4 hosts.
I'm pretty sure we're discussing about connecting to the Internet.
What I understood is being implied is that ipv6 has little utility if it cannot access ipv4, but is not the case the other way around.
How would v6 connect to v4? Specifically, how would the return packets back from v4 to v6 be routed?
Through a NAT64 NAT. Which is extra work, but not that bad.
Well, we have that. What GP refers to is a missed opportunity, so NAT64 can't be what GP has in mind.
[deleted]
Not really my point, was just pointing out there's scant incentive to transition from the incumbent.
One of the many missed opportunities of IPv6.
I keep seeing people say this, but nobody ever takes the next step of proposing how this "missed opportunity" might have been fixed.
The reality is that there is no possible way IPv6 could have been designed that would both solve the IPv4 address exhaustion problem and natively interoperate with IPv4. When you send a packet to an IPv4 host, it needs to know where to send the response, and there simply aren't enough bits in the IPv4 header to fit more than 2^32 possible addresses.
You need something in the middle to translate between IPv6 and IPv4 addresses, and we already have that: it's called NAT64. It works the same way you would expect NAT to, and just like NAT on IPv4, there's no need to codify it as an explicit part of the IP protocol itself.
I think it was bad timing. We might have been able to migrate to IPv6 wholesale when the Internet was much smaller in the early 90s. One thing that comes to mind is the kumbaya moment when everyone got together to switch from BGP v3 to BGP v4 to support CIDR.
> We might have been able to migrate to IPv6 wholesale when the Internet was much smaller in the early 90s.
In the early 1990s IPng/IPv6 was not yet invented, and when it was being considered they realized a flag-day (like (mostly) happened with NCP->IP) was unlikely:
We believe that it is not possible to have a "flag-day" form of
transition in which all hosts and routers must change over at
once. The size, complexity, and distributed administration of the
Internet make such a cutover impossible.
Rather, IPng will need to co-exist with IPv4 for some period of
time. There are a number of ways to achieve this co-existence
such as requiring hosts to support two stacks, converting between
protocols, or using backward compatible extensions to IPv4. Each
scheme has its strengths and weaknesses, which have to be weighed.
Furthermore, we note that, in all probability, there will be IPv4
hosts on the Internet effectively forever. IPng must provide
mechanisms to allow these hosts to communicate, even after IPng
has become the dominant network layer protocol in the Internet.
That was the plan. V6 was killed by NAT and the commercial forces that promoted its use.
"Killed" is a bit harsh, given that it's half of all Google's traffic. A huge chunk of that is probably from cell phones where IPv6 support is the norm.
Not really.. IPv6 was theoretically ready in 1997. But, it was theoretical. It was still buggy. In 2000s Internet expansion skyrocketed and noone really cared about IPv6. Buggy, too different from IPv4, basically overengineered. They made prediction that was absolutly off.. And thats why adoption is crappy.
IPv6 is not overengineered. It is, in fact, simpler in design than IPv4.
What are some others?
It does seamlessly work w/ services like Apple's Private Relay. I was surprised to see an IPv6 address when checking my IP address on external websites. Maybe eventually proxies like this might be the solve for this.
how can I access IPV4 stuff over IPv6?
NAT64 from pretty much every provider.
Probably thinking of DNS64/NAT64
In my country, nearly all ISPs provide native IPv6, and I include mobile internet (we are closer to 100% than 50%).
The fact that a company like monopolistic, abusive, privacy invading company like Google that desperately desperately wants me to run ipv6, ensures that I will disable it on every device I own and corporate network I run.
This is like boycotting 5G cell phones because you don't like Verizon.
They want you to run IPv4 too.
>They want you to run IPv4 too.
Exactly.
I'd expect that they don't much care which version of IP you use, as long as they can show you ads -- which is their business model after all.
I… think that at the end of the day, Google wants you to run v6.
Google competes with Facebook. Facebook wants sites to host Facebook Pages and such, which needs no IP addresses. Google wants lots of websites and other services on an open web, to which it can sell lots of ads, and for which it can run a good search engine that again brings in lots of opportunities. A lack of IP addresses isn't a problem for Facebook, but it is one for people who want to host new web sites and other services. And therefore Google wants to alleviate that problem, with which IPv6 can help.
They don't desperately want you to run IPv6. They're not doing anything to incentivise it in any way.
They just deployed it because that's the direction the tech world is moving, and there was increasing IPv6 presence in end user environments.
You've perhaps seen the Onion article whose headline goes something like "Heartbreaking: The Worst Man You Know Just Made An Excellent Point"?
You're simply kneecapping yourself if you refuse to learn how to acknowledge and incorporate good ideas that happened to be uttered by execrable entities.
Just like following the sleeping schedule and daily routine of a billionaire will also make you a billionaire.
Excellent logic! Hitler drank water and, if you had the chance to ask him, he would have likely suggested you also drink water. Does that mean you won't drink water now?
If Hitler was pushing a new kind of water which he argued was superior to the old water you've been drinking all your life, maybe some skepticism would be warranted?
I'm not saying that "I will disable v6 because Google wants me to enable v6" is a good argument, but your rebuttal is pretty bad as well.
Calm down. Please try to make your point less flamboyantly.
I am running as many IPv6 only services as I can.
All MY core services that I use daily are v6 only.
At the end of 2024 i am still shocked to see how much new software does not work without ipv4.
My most recent struggle was with Seq - the opentelemetry server for example.
It is full of new software created in the recent few years that just refuses to work without ipv4. And not because it need to reach some server on the internet. It just does not work if you do not have ipv4 (even private).
Why make so much trouble for yourself?
for me, its not really trouble. MY ISP has IPv6 and I have trouble using it.
Also I have lot of small VPS and the cost of the IPv4 address is the highest cost of the price of VPS. removing it reduces the cost by a lot.
How cheap VPSes are you getting? I've always just used v4 on my $5/month VPSes, never felt the need to think about v6 on them because v4 just works
>Why make so much trouble for yourself?
I'm not sure what you mean by that. I'm not GP, but I actually have to do more work to disable IPv6 on my systems than to use a dual stack.
As such, please explain what you mean by making "so much trouble for yourself."
I'm referring to running in a weird v6-only configuration and fighting with software which expects a normal configuration with v4.
>I'm referring to running in a weird v6-only configuration and fighting with software which expects a normal configuration with v4.
To which software are you referring? I'm not familiar with such code.
The software which Habgdnv was referring to? Seq being their most recent problematic encounter, but there's apparently more. I don't know the details, you'd have to ask them.
Using software that doesn't support the appropriate standards will likely fall down elsewhere too.
I'd avoid such trash.
Better make that suggestion to Habgdnv and not me, I've never heard about Seq lol
This seems as good a place to ask as any: how does one obtain a (larger) block of IPv6 not via their ISP/datacenter and then route it (to a network they control) through their ISP/datacenter-provided IPv6 uplink? Is that even possible?
You get yourself an AS and a registration and then talk to your ISPs about how to BGP peer with them.
You only need an ASN (and at least for RIPE it's a requirement) if you have multiple upstreams.
Thanks. Same process as IPv4, but my question was more focused on the ??? magical last step of getting the ISP to advertise that route.
It’s not magical, it’s exactly the same as IPv4, you either peer with them via BGP and advertise it yourself, or you give them an LOA to advertise it on your behalf.
You need to ask your ISP either to announce it with their own ASN or peer with you if you have your own.
Its no more magical than v4. In fact the BGP turn up call I usually have to do does both v4 and v6 at the same time.
Literally you just talk to your ISP. A support ticket or a technical phone contact. They'll either just do it for you or get you set up to announce your routes to them.
You'll need an ISP that does actual business networking things, probably. I doubt Xfinity home service would do it for you.
> You'll need an ISP that does actual business networking things, probably. I doubt Xfinity home service would do it for you.
It would be nice if someone made a wiki somewhere of which ISP's worldwide will do this on which plans.
I'd really like to have two ISP's and BGP peer with both, so that if one goes down all my systems keep the same IP address and maintain connectivity.
The whole idea of everyone having just one connection in a fragile tree-like structure seems against the original design goals of the internet.
>It would be nice if someone made a wiki somewhere of which ISP's worldwide will do this on which plans.
More or less all of them with a business tier of service will do this.
>I'd really like to have two ISP's and BGP peer with both, so that if one goes down all my systems keep the same IP address and maintain connectivity.
The smallest subnet that is going to get advertised outside of your ISP (outside of the ASN you're in) is a /24, you can't have multiple ISPs and get that kind of address space for your personal stuff.
The design goals of the Internet you're referring to are about networks not going offline, a global routing table with individual entries for every user is not sustainable.
> The smallest subnet that is going to get advertised outside of your ISP (outside of the ASN you're in) is a /24,
In an IPv4 world. In an IPv6 the equivalent is a /48
It's far easier to get a ipv6/48 than a ipv4/24 (naturally).
> The design goals of the Internet you're referring to are about networks not going offline, a global routing table with individual entries for every user is not sustainable.
With a bit of a redesign it would be. Most mesh networks tackle this problem. In the worst case, a routing table entry for every human in the world is only 8 billion entries, which would fit in RAM on a typical server today. And every optimization you do dramatically reduces that number (eg. make users who have similar network configs and peers have neighbouring addresses, allowing you to coalesce potentially millions of users into a single route)
It would fit in RAM but then you actually have to search through RAM. I have a router that is doing a very modest 3gbps of traffic, or about 2000pps that all need lookups, and about 40 updates per second that goes into that table.
I should also mention that's 40 updates per second for a default free zone of about 950,000 routes. 8 billion routes would be an minimum update frequency of ~370,000 routes per second assuming the same stability.
What about updates? Propagating routing table changes for even 8 billion devices (assuming each human has on average one device, which is quite the assumption to make) would be incredibly resource-intensive.
Your challenge is getting every ISP to accept this. The routing table might fit in the RAM of a typical server, but perhaps not so easily in the RAM of many routers still deployed in the field.
It's a nice idea, but sadly it'll lose out to commercial realities in many cases.
I'm just saying that rearchitecting the Internet / routers to support billions of routes would be a challenge, and it might just be too slow to have a routing table that big.
If you are in RIPE land you can get a PI (provider independent) /48 from a LIR (a RIPE member) and ask your datacenter to announce it.
https://tunnelbroker.net/ will give you a free IPv6 subnet and you can route it over your existing IPv4 link. I think you can get either a /64 or /48.
I had a tunnel with them I was using for a while, but ended up turning it off a couple of months ago.
Any request to a CDN will be slower since you’re not hitting the cache closest to your actual ISP, and since it’s “a VPN” a lot of things start to break, need more captchas, or get blocked for you since there’s a higher level of abuse from HE’s tunnel broker IP blocks.
Oh wow, I didn’t know they were still around! I used that to get an IPv6 address more than a decade ago; I think they used the bastardized IPv4-mapped-to-v6 address format at the time. But iirc it involved extra network hops because it was tunneled rather than routed, but maybe I’m misremembering.
I’m guessing they have larger blocks for sale?
Sorry to mislead--you're correct, it is a tunnel.
I was very happy to get symmetric Gig internet at my new place but very bummed that my ISP doesn’t offer IPv6.
I had enjoyed learning about and deploying it on my LAN whenever Comcast added support (SLAAC is magical) but I guess I’ll be waiting for quite a while to play with it again :(
There's also a cool trick you can do with IPv6 addresses for servers where you use RA to broadcast your IPv6 prefix on the LAN and the OS assigns itself a valid public IPv6 using the MAC address for uniqueness.
Very clean and easy.
Hoping AWS and my ISP implement IPv6 before I retire...
(AWS has partially implemented IPv6, but it's still not usable in my mind)
> route when you can, switch only when you need to mantra
Naive question: isn't switching faster than routing?
Only at small scale: the flat MAC lookup quickly becomes more expensive than matching against a handful of (post-consolidation) routing prefixes.
E.g. in their setup only the switch the hosts are directly plugged in needs to be aware of the individual hosts; all other switches/routers only look at it with a granularity no finer than this access switch. And at some point even coarser.
All 'boring' packets are hardware switched/routed with no CPU involvement in everything bigger than your home cable router.
For both switched and routed networks it's possible to build hardware that can route at the same speed as the ports, so in 2024 performance isn't really a reason to choose switched or routed.
Cost might be though - I believe that for the same number of gigabits, hardware sold as a switch is substantially cheaper.
500 routes are still cheaper than 50k MACs, though, but I might be off a little with the number threshold there.
Market segmentation is a thing, sadly :(
It is; it also provides less control. Some networks do it one way and some do it the other way.
IPv6 is great, but it does open up new challenges with traffic management, reputation, and bot analysis. We need advances there.
[flagged]
We need something better than IPv6 that better addresses the needs of users. IPv6 does too much and is too complicated.
If you think IPv6 is too complicated, you are either overestimating IPv6’s complexity or underestimating IPv4’s complexity. IPv6 is undeniably simpler. It has a cleaner header format that is simpler to parse, it has no need for on-path routers to perform fragmentation, it combines host/router discovery and various diagnostic control packets down into a single protocol called ICMPv6, it has stateless address autoconfiguration and correct link-local address behaviours amongst others. It fixes decades of mistakes that have accumulated in IPv4.
> IPv6 is undeniably simpler.
Perhaps to someone who's never been exposed to IPv4.
But for those who know IPv4 from before, it means almost a complete rewrite of all the knowledge. Just about every detail of setting up an IPv6 network is different from an IPv4 network, with just the superficial bits staying similar.
It also has bits that are undeniably more complex than IPv4, like dynamic address allocation. You got SLAAC, RA, stateful and stateless DHCPv6, with the latter being required in certain cases. And with that you now got two different ways to provide DNS servers to clients, and which one takes precedence is undeniably non-trivial[1] and even implementation dependent!
Any solution that requires updating clients, servers, and networking equipment to support the protocol and/or adjust the network address scheme of the environment will require the exact same steps doing an IPV4 to IPV6 migration would require.
Not so. IPv4->6 removes all existing v4 address blocks and redoes the addressing scheme. Those changes weren't necessary for expanding the address space. This implies that day 1 of using ipv6, all your addresses are different (and way longer), all your routes change, DNS DHCP etc all need to be swapped out, and bans/reputation are all reset with no clear replacement. And there were a bunch of smaller changes / new features.
Whatever you do to get more addresses, it will look similar in the end, but the steps could've been very different.
How would a computer with an expanded address scheme communicate with another device with an unexpanded IPV4 address? How would that client get its response back?
How would a router know what to do with it without updating its software?
At the end of the day, you are talking about using a different than IPV4 address scheme and using a different protocol than IPV4. Everything in the stack will need to be updated. Every hop on the route, every single piece of software that will interact with the network address. Backwards compatibility still requires everything but the older device to be updated.
Yes, everything has to be updated eventually, but going forward doesn't have to be this hard. A network and its hosts could start supporting ipv6 without changing anything else. Same addr and routes as before, same NAT, and no DNS6/DHCP6/etc, so very low effort and risk to turn it on. If a peer only supports v4, talk v4 to it for now.
Then once there's sufficient v6 adoption, you can disable v4 entirely and start using /40, /48, etc..
> Same addr and routes as before
But same addr is the problem we are trying to solve in the first place. Using your IP-new proposal (let's call it IPv5): If every IPv5 addr is just a padded version of the same IPv4 addr, then once IPv4 addresses are exhausted the IPv4-mapped-into-IPv5 addresses are also exhausted.
At that point you need to start handing out IPv5 addresses to hosts without an IPv4 address. And then, how does a IPv5-only host talk to a IPv4-only legacy host? That's the fundamental issue!
The same addr thing only buys you time until the address exhaustion becomes real.
But you can do that with IPV6? I have both an IPV4 and IPV6 address on this very device.
My confusion in the claims that we could do it differently is how the protocol could be updated without actually doing the work of updating everything on the network and adding the new address scheme.
What do you suggest as "something better than IPv6"?
v4 but with a larger address space?
How is that better than IPv6? Remember that there is no way to squeeze more address bits into IPv4 header, that need to come up with a new protocol. In fact, need to come up with a whole suite of new protocols. You could just make the addresses bigger but still need to deploy.
IPv6 changed some things, most of them for the better, and it already works. The only problem is migrating and the problem is people who don't want to switch.
One example of how IPv6 is better than IPv4 with more address bits, is that 128-bit address is big enough to put the whole IPv4 address in. NAT64 put the IPv4 address in the 64-bit host section. MAP-T puts the whole NAT state in address, getting rid of expensive CGNAT.
I don't understand why all my devices randomly assign themselves non-functional IPv6 addresses with no involvement from any router. Often it's even multiple non-functional IPv6 addresses.
IPv6 assigns link-local addresses automatically. They are for talking to other computers on same the network. It works when you don't have router. It won't interfere with anything else.
IPv6 supports multiple addresses on each machine for different scopes: global, internal, local. IPv6 uses address hierarchy to figure out which one to use to reach destination.
Why?
> It works when you don't have router.
Who doesn't have a router?
Computers connected by a switch? Another scenario is when you connect two computers directly by Ethernet.
Or... Peer to peer links between your router and the ISP?
Hard to take seriously any suggestion which look at ARP (and the other warts in v4) and goes "yep, let's hang onto those".
"Let's make a new, backwards incompatible protocol and not learn anything from the old one" doesn't feel like a good idea to me.
I see nothing wrong with ARP.
Every proposed alternative to IPv6 that I've ever seen has just been IPv6 with extra steps. What's yours?
That's my proposal, ipv6 with extra steps. As in, incremental steps instead of one impossibly big change. tl;dr keep the pre-existing v4 /32 blocks day 1, and the rest follows.
Edit: I said "my" proposal, but pretty sure the same idea has been brought up many times.
Getting rid of IPv4 address allocation is one of the huge advantages of IPv6. IPv4 is chopped up into little pieces and the routing table is mess from it. Starting from scratch, IPv6 can make that better.
IPv6 also realized that most people don't need their own address space. It is valuable in IPv4 to own an allocation, but IPv6 is so huge it doesn't matter.
For setup, IPv6 does it automatically for customers. Peering requires entering IPv6 addresses, but that is a one time thing.
> Getting rid of IPv4 address allocation is one of the huge advantages of IPv6. IPv4 is chopped up into little pieces and the routing table is mess from it.
Basically IPv6 only solves problems if you're paid full time to do network administration.
If you just run a small network among other things, it creates problems. Because you can't hold the new structure in your head if it's not your main job.
> Starting from scratch, IPv6 can make that better.
Yeah right. Want that "things you should never do" Joel link?
He was talking about Netscape, but I think IPv6 is a much better example.
Yeah, the route fragmentation a disadvantage of what I've had in mind. My focus is just on getting things to speak v6 to fix the scarcity problem first. Maybe at some point the owners could've swapped addresses back to defrag things.
[deleted]
IPv6 is better than IPv4 and NAT. Your connection has been reset by peer.
About two years ago, when we deployed our datacenter, I insisted for IPv6 first.
All out management network is IPv6 only, all kvm, switches, routers...
It was a pain and gives nearly no practical advantage (at the time), but the motivation was to make everyone "intimate" with IPv6. We learned a lot and we even discovered some implementation bugs (for example, Cisco default link local address is not /64 and this is not compliant with more recent RFC and will make them unable to communicate with BSD systems).
Now we have IPv6 everywhere and everybody from dev to sysadmin is aware of IPv6 and we start to see some real advantages. VPN are easier to manage, routing is easier, firewall is easier, clustering, failover... everything is "cleaner".
We still have IPv4 (dual stack) on some servers, but about 80% of them are IPv6 only with DNS64/NAT64.
It's obvious that a major reason more people don't do this is a lack of instant payoff.
Indeed, but also not everyone gets the payoff that GP did. We did IPv6 only and abandoned it after a while because there were some show-stoppers in our cloud provider that didn't work (at the time, this was a few years ago). It ended up being a good investment in the two people spearheading the work, but otherwise was a waste of time/money.
Same applies for directory services, configuration management, etc. Eating vegetables
All those give me a clear advantage in the long run. What’s the advantage for me with ipv6?
One past employer of a friend has an internal network using IPv4 only. Every night a database query runs on one database and updates a second database based on the results (a DSS updated from a data warehouse, I think). One of the TCP connections involved goes through five levels of NAT, internally to the company.
No one on the team liked adding the fifth NAT, but no one felt confident enough to undo any of the old NATs either.
If you use IPv6 internally you don't dig yourself into holes like that one. You have enough addresses that you can choose clarity and maintainability in little day-to-day choices and a few years later that clarity has added up.
I don't know you as well as I should :) I should say I'm not that interested in selling something that is both free and 'politically' loaded.
People have made up their minds, they'll pick it up or they won't. No "skin off my teeth" at all. Implementation details matter to those who care. They have their reasons, I'm not one to question them.
One of the things I like about v6 is it allows us to give up the charade or vanity of addressing. At least minify it. One can define classes of networks and simply identify hosts by MAC (or FQDN assuming an AAAA record).
I already have to tote that information around to configure them. Having a v4 address can be seen as duplicating the role of identity, while risking conflict. Outright removal of v4 may offer benefits in some scenarios.
Now... 'conflict' is how BGP anycast literally works. Two or more hosts announce the same location. There are perfectly valid reasons to still use v4, neither precludes the other.
Why is it now easier to manage?
No translation, no subnet allocation issue (because no scarcity), global reachability from everybody to everybody (as internet was meant to be), no overlap (because no RFC1918)
The world is much easier when everybody has its own identity.
I'm not the OP, but I expect VPNs are easier to manage because you don't have to worry about slicing up the very, very limited IPv4 non-public space and puzzling out how to resolve addressing collisions between all of the various networks you have to manage. With IPv6 you can just calculate a /48 ULA prefix and allocate /64s for your VPNs (and every other internal network) out of that. If ever you run out of room, just calculate another /48 and carry on... easy!
You are a shining example!
What do you use for a NAT64 gateway?
Not GP but in similar setups I've had good success with using the FWs (typically Fortinet or Palo Alto) as the NAT64 gateway. Hosted services that require 1:1 NATs also end up there anyways so it's a good fit for DC.
Outstanding. As Google’s IPv6 traffic portion approaches 50% (https://www.google.com/intl/en/ipv6/statistics.html) it’s clear IPv6 is here, now, today. I wouldn’t dream of launching a new public-facing greenfield project without it.
Nothing's realistically dropping support for v4 any time soon, so v6 support is optional. On the other hand, we're far, far away from all users supporting v6, so v4 support is not optional.
Running a single IP stack is infinitely simpler and easier than running two concurrently, and until that "single IP stack" can be v6, I see very little reason to support it.
Fun fact: US government agencies are required to progressively migrate to IPv6-only environment, beginning with completing at least one pilot of IPv6-only system by FY 2021: https://www.whitehouse.gov/wp-content/uploads/2020/11/M-21-0.... Apparently, National Archives decided to pick archived Clinton White House website for this: https://clintonwhitehouse1.archives.gov/
I didn't recommend dropping IPv4. It's a terrible it to start a new project in 2024 without IPv6 support though. It's easy enough to build in from the beginning that there's not any real reason not to go for it.
And running a dual stack is trivially easy for almost everyone using it. That chart has almost half of Google's users coming in via IPv6. I promise you less than 1% of that 50% have ever even heard of IPv6, let alone done a single thing to configure it. With my ISP I'd have to go out of my way to turn it off, which I haven't done because this isn't 2008 where it broke things more often than never.
> It's a terrible it to start a new project in 2024 without IPv6 support though.
Why? Radical complexity reduction at essentially no cost to yourself or your customers seems like a tempting proposition.
Exactly! IPv4 management is hideous compared to IPv6 once you grok it. The sooner you upgrade to it, the sooner you can deprecate horrid mitigations like NAT.
Out of curiosity, what parts of NAT management tend to be so horrible in practice?
The fact that it exists. I was a network engineer before NAT became a common thing and remember how it use to be when nodes on the network were legitimately peers. NAT is a bletcherous band-aid for the fact there are more people than 32 bit numbers. Now we're seeing true abominations like CGNAT. That stuff needs to be lost to the realm of scary legends told late at night.
I was asking about practical issues, not just complaints of subjective ugliness. While I'll grant that CGNAT can be pretty bad (though not entirely indefensible for mobile networks), I don't think we can ever return to "every node being a peer" in any case, not when any typical network will have a firewall that denies incoming connections.
>I don't think we can ever return to "every node being a peer" in any case, not when any typical network will have a firewall that denies incoming connections.
Forgive me if I'm missing something here, but how is that any different WRT IPv4 vs. IPv6?
In both cases, except for those services one wishes to expose to the Internet (assuming one has a use-case for that), all incoming connections should be blocked, IPv4 or IPv6.
Or are you arguing that NAT masquerade confers some sort of security benefit on one's network that precludes the necessity of blocking incoming connections?
I'd argue that NAT (N:1 or 1:1) doesn't provide any security benefit. Nor does IPv4+NAT reduce the complexity of firewall rules as compared with IPv6.
In fact, I'd posit that NAT makes things more complicated and not less. That said, you can use NAT/NPT[0] with IPv6 (along with ULA/SLAAC) if you really want.
As such, I'd say that IPv6 provides the best and worst of IPv4, plus additional benefits.
IF we ever get completely off IPv4, that will be a good day.
[0] https://en.wikipedia.org/wiki/Network_address_translation#NA...
I don't think I'm disagreeing with you regarding firewalls: what I was trying to say is that "every node being a peer" isn't a good argument against NAT, since these days it holds neither in IPv4 nor in IPv6, now that everything has a firewall in front of it.
> In fact, I'd posit that NAT makes things more complicated and not less.
Sure, it clearly adds some iota of additional work, but I've never seen it as being the worst thing in the world. I'm young enough to have never witnessed the legendary paradise of globally-reachable static IPs for everything, so it seems more like "just the way things are". And yet there is widespread hatred against the existence of NAT, and I can't tell if it's primarily ideological, or if NAT is causing real practical difficulties for many setups. (Though at least the issues with CGNAT are easy to see. And also with broken NAT implementations.)
Meanwhile, one might argue that things like SLAAC in IPv6 can similarly add conceptual difficulties compared to IPv4. E.g., "How do I identify some particular device in my network, if its link-local IP is changing on a regular basis?" (To which the answer is something DNS-like, I guess?) So switching a network's internal operations from NATted IPv4 to NATless IPv6, with all of its different mechanisms, would seem like more of a tradeoff than an unequivocal win.
I mean adding IPv6 support doesn't make nodes "legitimate peers". NAT still exists in a v4+v6 world; there will always be a distinction between "nodes with a public v4 address" and "nodes without a public v4 address".
You're missing the point, I believe intentionally. You can't get away from IPv4 as long as you have users who can't access IPv6-only servers. All your users and potential users can access IPv4-only servers.
> All your users and potential users can access IPv4-only servers.
Not all servers are user-accessible. For instance, a database server or a NAS server might only be accessed by other servers within the same organization. Using IPv6 between these internal-only servers, instead of RFC 1918 addresses, can simplify things.
And can make things far more complex too. You now need people to understand both ipv4 (for your public facing) and ipv6 (for your internal ones).
Instead you could just choose ipv4 only and reduce a lot of complexity. Sure there are also downsides -- if you're in a large org and are running out of RFC1918 space, or you're rationing it to smaller than /24 networks, that can be a pain (I don't see a benefit of more than 256 host addresses on a subnet as that's already far to large a broadcast domain)
Obviously. I thought it was clear enough that I was takling about public-facing servers, since I talked about the capabilities of users' devices.
> You can't get away from IPv4 as long as you have users who can't access IPv6-only servers.
That depends on your definition of "can't get away from". Your users can live on a IPv6 only lan and have the IPv4 world available to them. IPv6 supports 4 in 6 - ie you can embed IPv4 addresses in IPv6, so all you need is a gateway that translates IPv4 to IPv6 for them.
I've done it. At a conference, to unsuspecting users. All phones support IPv6 well, so they didn't notice. Not one complaint - I was blown away by how well it all worked.
It was done because some noisy attendees insisted on being assigned routable IP addresses. That can be difficult to provide with IPv4 for obvious reasons, whereas ISP's will happily hand you thousands of billions of IP{v6 routable addresses, for free.
I set up the gateway myself, rolling my own using a linux box I had lying around. Adding the 4 in 6 capabilities is maybe an hours work on top of all the other setup you have to do on the box, and that includes googling to find what tools you need and how to configure them. It's not hard.
On the other hand only your edge load balancers need dual-stack, everything behind them can be v6-only.
I think you're misunderstood what you quoted:
> It's a terrible it to start a new project in 2024 without IPv6 support though.
That does not preclude ALSO supporting IPv4.
Remember that for many technical folks out there, the default is "Only do IPv4 support" which is (IMO) just batshit stupid.
(Do also note that the sentence immediately prior to the one you quoted is "I didn't recommend dropping IPv4.".)
As you know, we have two options:
1. Support IPv4 and IPv6.
2. Support only IPv4.
#2 has essentially no downsides and is radically simpler.
That's my point. It's not terrible to start a new project without IPv6 support, because adding IPv6 support adds a ton of complexity for almost no benefit.
I never claimed or insinuated that you recommend dropping IPv4. If I thought your recommendation was to drop v4, my argument about the complexity of dual-stack would've made no sense.
> I never claimed or insinuated that you recommend...
Check my handle. I'm not who you seem to think I am.
> ...adding IPv6 support adds a ton of complexity for almost no benefit.
That doesn't at all match my experience with IPv6 support in greenfield projects for the past decade+. You actually have to do extra work to make them IPv4-only. Remember that the statement you initially responded to said "It's a terrible it to start a new project in 2024..."
> > I never claimed or insinuated that you recommend...
> Check my handle. I'm not who you seem to think I am.
Sorry, I didn't notice. Pretend I said "they" rather than "you".
> > ...adding IPv6 support adds a ton of complexity for almost no benefit.
> That doesn't at all match my experience with IPv6 support in greenfield projects for the past decade+. You actually have to do extra work to make them IPv4-only. Remember that the statement you initially responded to said "It's a terrible it to start a new project in 2024..."
Huh, I never found it difficult to ... not add an AAAA DNS record to point to a server. It surprises me that you find that to be extra work.
> Huh, I never found it difficult to ... not add an AAAA DNS record to point to a server.
Have you attempted to make greenfield software written in 2024 support only IPv4 addresses and be deliberately incompatible with IPv6 addresses? It's a lot more work than just using what the standard libraries give you and just getting support for v4 and v6.
I have actually made a green field project in 2024 and created a VPS for it and not added an AAAA record to point to that VPS, it was pretty easy to not add that AAAA record, I could do it in my sleep (in fact I do spend most of my nights not adding AAAA records to anything)
Now the software itself would probably work v6 if you set up the infrastructure for it, but that's not what I'm talking about. (I don't know for sure that it works with v6 though, never tested)
I know for sure that I've written some software before which doesn't work with IPv6 because the buffer I pass to gethostbyname is 4 bytes, but to be fair I haven't written such software in 2024. I have also written software to configure a device's interfaces and routing tables which only does DHCP4 and only configures v4 addresses, but that was in 2023 not 2024, maybe dhcp4 would've magically worked with IPv6 if I had done it this year
> Running a single IP stack is infinitely simpler and easier than running two concurrently
I’d say it’s marginally simpler. Unequivocally it’s quantifiably simpler. But infinitely simpler? That’s a pretty tall claim to make.
Depends on your users; there are, for instance, plenty of phones that only natively have v6 and have to use NAT64 to reach v4 websites. So if you have such users, there might be a benefit to supporting v6 directly.
As you said though, those users can reach v4 websites.
There are already cases of Internet connectivity issues due to overloaded CGNAT. I know for a while I could only visit IPv6 websites, IPv4 technically works but the amount of packet drops meant that my IPv4 internet speed was only about 15KB/s!
It's the whole reason why I discovered a DNS server that synthesizes AAAA records, for websites that actually support IPv6 through their CDN. [0]
> As you said though, those users can reach v4 websites.
Therefore, the question is: Can those users really reach IPv4 websites?
Mind you, I don't expect the CGNAT-overloading issue to relieve over time -- unless we deploy IPv6 everywhere ;)
[0]: https://gitlab.com/miyurusankalpa/IPv6-dns-server
yes, with the increased latency of having to travel to the NAT64 server first. This can also cause you to not use the nearest CDN, etc.
Its easier to get good latency and bandwidth over v6 than natted v4
What is the latency or bandwidth bottleneck in nat v4?
Taking the detour to the NAT.
NAT registers in the microseconds for packet processing time, that isn’t even comparable to Internet path jitter.
You mean that the packets go through a router? They would do that regardless though?
Your typical router shouldn't fill up its port mapping table. In fact, the 4th layer isn't involved at all so "ports" don't even exist as a concept.
> Nothing's realistically dropping support for v4 any time soon […]
Or potentially ever, as predicted when IPng was being originally thought about:
* https://datatracker.ietf.org/doc/html/rfc1726#section-5.5IPv4 at the edge and call it a day.
Why build today with deprecated technology ? Build your infra v6-only, add a layer at the edge to support old clients via IPv4. Job's done.
You should design your infrastructure to avoid paying too much for other people's legacy.
I personally push for IPv6-only internal networks whenever possible, and have deployed several such designs in datacenters.
Unfortunately, a lot of applications are building on platforms where IPv6 is an afterthought if even present at all. Take for example Azure, where IPv6 support is a fucking joke. From core services like Route Server not supporting it, to it being impossible to build v6-only networks due to forced v4 subnet and vNIC requirements, to many services that Microsoft provides only running on v4.
As much as I want to push IPv6 everywhere, that physically cannot happen until companies support it for all use cases. In the mean time dual stacking can be better than nothing but the complexity is non-trivial when the alternative is just running straight v4...
IMO the separate-stack nature of ipv6 was a mistake. I can see why they did it, but the changes could've been a lot more incremental otherwise, and we might've been done already. Everyone talks about the biggest change being the 128-bit address space, but the real leap is that pre-existing ipv4 blocks weren't preserved in ipv6.
The changes couldn’t have been more incremental. Routing hardware only understood the IPv4 header (and at that time I believe a lot of this was baked in silicon). There was no way to create an IPv4+ without needing to replace all the internet’s routers before it could reliably work.
How would have it made it easier to migrate when all of the new blocks wouldn’t be accessible (in either direction) if the traffic passed through any router that hadn’t yet been upgraded? Nobody could really use any of the extended space at all until every single router had been upgraded to this IPv4+.
It is a common misunderstanding (I hear “we could have just made IPv4 bigger” a lot) but apart from the routing issues above (needing to replace every router before it could work at all), the endpoints are also a problem. Nothing in the expanded space could actually call out to a legacy IPv4 endpoint - it could sent packets to it, but that legacy host wouldn’t be able to return packets back since it wouldn’t understand the larger address. And of course the legacy endpoint couldn’t initiate a connection to anything in the extended space either from its side.
So you not only have all the same problems of IPv6 (like needing to upgrade everything), you actually add a bunch of problems of breaking the ability of big parts of the internet from being able to communicate with the rest.
Dual-stack was necessary because everything couldn’t be switched over on the same day. If everything was upgraded at once, your extended-IPv4 idea would work, but otherwise it would break the internet!
They are, though? It's how dual stack sockets work, they just map IPv4 into the part of IPv6 where they belong.
But then you're still using ipv4.
I'm on a laptop on an ipv6 only subnet at the moment which mostly does the job with dn64/nat64.
The only benefit of this is to increase familiarity with ipv6. I'm trying to push some colleagues to do an ipv6 only section of our network which has limited interconnect, but there's a lot of concern about devices that still don't support ipv6, and ultimately what's the business reason to do it compared with subnetting 10.0/8 and natting at your firewalls
I'm very happy to not have to know what dns64 and nat64 is.
And many people are happy to not know what an IP address is either. That's fine.
I find it amazing how that lack of curiosity about how computers work extends into modern software developers, I guess that the majority of the industry nowadays are people that do things like "bootcamps" and go into it for the money.
I have no need for ipv6, however I wanted to know about it so spent a couple of hours setting myself up with it. I don't bother with the latest fads that last 3 or 4 years and then are replaced by a new fad, but ipv6 has been around long enough that it's clearly not a fad.
I have plenty of curiosity around how computers work. I've implemented compilers and interpreters, designed CPUs (I made a RISC-V CPU in Logisim which could run programs compiled with clang!), designed ISAs, back in university I had a lot of fun both writing a networking stack from almost-scratch (starting with only C and the raw ethernet packet API in Linux, building toy versions of ARP, IP, routing daemons and TCP) and writing a toy kernel, I have an ongoing game project where I'm writing the engine from scratch in C++ and using plain OpenGL to render, and this past year I've taken up PCB design and CAD. All this just because I want to learn stuff and make stuff. Don't assume that just because someone doesn't share your particular interests, they lack curiosity.
IPv6 has been around long enough that it's clearly a failed project. It's been 30 years and it hasn't even breached 50% adoption. It's not even at the hard part yet, which will be the long tail.
>IPv6 has been around long enough that it's clearly a failed project
You have a very radical definition of "failed". Take your emotions out, and perhaps you would get a more objective evaluation of the technology.
For one, it's very clear that IPv6 has only, truly received global attention after the depletion of IPv4 address space -- someone has already linked the Google IPv6 adoption page, go have a look at it, look at the flat line before 2012. That means we have spent about of 10~15 years of time deploying IPv6, not 30 years, and getting to 50% adoption in such a time period is not what I'd describe as a failure.
Secondly, if you are defining failure as "less than 50% prevalence in 30 years" then HTTPS before 2014 will probably fall under the same category too. (Don't underestimate the age of SSL/TLS.)
Do you consider HTTPS a failure?
The only way this stuff trickles down to the masses is people that know what they are doing forcing it on them through their products. Very, very few 'engineers' actually go out and learn the state of the art these days in my experience, with most just culting around whatever the current marketing fad is.
Hell just look at SDWAN land and everyone acting like it is the second coming of jesus when it is just a fancy marketed version of technologies that have been available for decades.
IPv4 stuff is accessible over IPv6. It's just the other way around that is not the case.
Not by default it’s not. An ipv6-only deployment cannot natively access an ipv4 network, there is no backwards comparability in the protocol.
I get that you're trying to make a point, but NAT64 makes this not a real problem. Every practical use of IPv6 can access IPv4 hosts.
I'm pretty sure we're discussing about connecting to the Internet.
What I understood is being implied is that ipv6 has little utility if it cannot access ipv4, but is not the case the other way around.
How would v6 connect to v4? Specifically, how would the return packets back from v4 to v6 be routed?
Through a NAT64 NAT. Which is extra work, but not that bad.
Well, we have that. What GP refers to is a missed opportunity, so NAT64 can't be what GP has in mind.
Not really my point, was just pointing out there's scant incentive to transition from the incumbent.
One of the many missed opportunities of IPv6.
I keep seeing people say this, but nobody ever takes the next step of proposing how this "missed opportunity" might have been fixed.
The reality is that there is no possible way IPv6 could have been designed that would both solve the IPv4 address exhaustion problem and natively interoperate with IPv4. When you send a packet to an IPv4 host, it needs to know where to send the response, and there simply aren't enough bits in the IPv4 header to fit more than 2^32 possible addresses.
You need something in the middle to translate between IPv6 and IPv4 addresses, and we already have that: it's called NAT64. It works the same way you would expect NAT to, and just like NAT on IPv4, there's no need to codify it as an explicit part of the IP protocol itself.
I think it was bad timing. We might have been able to migrate to IPv6 wholesale when the Internet was much smaller in the early 90s. One thing that comes to mind is the kumbaya moment when everyone got together to switch from BGP v3 to BGP v4 to support CIDR.
> We might have been able to migrate to IPv6 wholesale when the Internet was much smaller in the early 90s.
In the early 1990s IPng/IPv6 was not yet invented, and when it was being considered they realized a flag-day (like (mostly) happened with NCP->IP) was unlikely:
* https://datatracker.ietf.org/doc/html/rfc1726#section-5.5That was the plan. V6 was killed by NAT and the commercial forces that promoted its use.
"Killed" is a bit harsh, given that it's half of all Google's traffic. A huge chunk of that is probably from cell phones where IPv6 support is the norm.
Not really.. IPv6 was theoretically ready in 1997. But, it was theoretical. It was still buggy. In 2000s Internet expansion skyrocketed and noone really cared about IPv6. Buggy, too different from IPv4, basically overengineered. They made prediction that was absolutly off.. And thats why adoption is crappy.
IPv6 is not overengineered. It is, in fact, simpler in design than IPv4.
What are some others?
It does seamlessly work w/ services like Apple's Private Relay. I was surprised to see an IPv6 address when checking my IP address on external websites. Maybe eventually proxies like this might be the solve for this.
how can I access IPV4 stuff over IPv6?
NAT64 from pretty much every provider.
Probably thinking of DNS64/NAT64
In my country, nearly all ISPs provide native IPv6, and I include mobile internet (we are closer to 100% than 50%).
The fact that a company like monopolistic, abusive, privacy invading company like Google that desperately desperately wants me to run ipv6, ensures that I will disable it on every device I own and corporate network I run.
This is like boycotting 5G cell phones because you don't like Verizon.
They want you to run IPv4 too.
>They want you to run IPv4 too.
Exactly.
I'd expect that they don't much care which version of IP you use, as long as they can show you ads -- which is their business model after all.
I… think that at the end of the day, Google wants you to run v6.
Google competes with Facebook. Facebook wants sites to host Facebook Pages and such, which needs no IP addresses. Google wants lots of websites and other services on an open web, to which it can sell lots of ads, and for which it can run a good search engine that again brings in lots of opportunities. A lack of IP addresses isn't a problem for Facebook, but it is one for people who want to host new web sites and other services. And therefore Google wants to alleviate that problem, with which IPv6 can help.
They don't desperately want you to run IPv6. They're not doing anything to incentivise it in any way.
They just deployed it because that's the direction the tech world is moving, and there was increasing IPv6 presence in end user environments.
You've perhaps seen the Onion article whose headline goes something like "Heartbreaking: The Worst Man You Know Just Made An Excellent Point"?
You're simply kneecapping yourself if you refuse to learn how to acknowledge and incorporate good ideas that happened to be uttered by execrable entities.
Just like following the sleeping schedule and daily routine of a billionaire will also make you a billionaire.
Excellent logic! Hitler drank water and, if you had the chance to ask him, he would have likely suggested you also drink water. Does that mean you won't drink water now?
If Hitler was pushing a new kind of water which he argued was superior to the old water you've been drinking all your life, maybe some skepticism would be warranted?
I'm not saying that "I will disable v6 because Google wants me to enable v6" is a good argument, but your rebuttal is pretty bad as well.
Calm down. Please try to make your point less flamboyantly.
I am running as many IPv6 only services as I can. All MY core services that I use daily are v6 only. At the end of 2024 i am still shocked to see how much new software does not work without ipv4. My most recent struggle was with Seq - the opentelemetry server for example. It is full of new software created in the recent few years that just refuses to work without ipv4. And not because it need to reach some server on the internet. It just does not work if you do not have ipv4 (even private).
Why make so much trouble for yourself?
for me, its not really trouble. MY ISP has IPv6 and I have trouble using it.
Also I have lot of small VPS and the cost of the IPv4 address is the highest cost of the price of VPS. removing it reduces the cost by a lot.
How cheap VPSes are you getting? I've always just used v4 on my $5/month VPSes, never felt the need to think about v6 on them because v4 just works
>Why make so much trouble for yourself?
I'm not sure what you mean by that. I'm not GP, but I actually have to do more work to disable IPv6 on my systems than to use a dual stack.
As such, please explain what you mean by making "so much trouble for yourself."
I'm referring to running in a weird v6-only configuration and fighting with software which expects a normal configuration with v4.
>I'm referring to running in a weird v6-only configuration and fighting with software which expects a normal configuration with v4.
To which software are you referring? I'm not familiar with such code.
The software which Habgdnv was referring to? Seq being their most recent problematic encounter, but there's apparently more. I don't know the details, you'd have to ask them.
Using software that doesn't support the appropriate standards will likely fall down elsewhere too.
I'd avoid such trash.
Better make that suggestion to Habgdnv and not me, I've never heard about Seq lol
This seems as good a place to ask as any: how does one obtain a (larger) block of IPv6 not via their ISP/datacenter and then route it (to a network they control) through their ISP/datacenter-provided IPv6 uplink? Is that even possible?
You get yourself an AS and a registration and then talk to your ISPs about how to BGP peer with them.
Read this to start wtih
https://www.arin.net/resources/guide/ipv6/first_request/#end...
You only need an ASN (and at least for RIPE it's a requirement) if you have multiple upstreams.
Thanks. Same process as IPv4, but my question was more focused on the ??? magical last step of getting the ISP to advertise that route.
It’s not magical, it’s exactly the same as IPv4, you either peer with them via BGP and advertise it yourself, or you give them an LOA to advertise it on your behalf.
You need to ask your ISP either to announce it with their own ASN or peer with you if you have your own.
Its no more magical than v4. In fact the BGP turn up call I usually have to do does both v4 and v6 at the same time.
Literally you just talk to your ISP. A support ticket or a technical phone contact. They'll either just do it for you or get you set up to announce your routes to them.
You'll need an ISP that does actual business networking things, probably. I doubt Xfinity home service would do it for you.
> You'll need an ISP that does actual business networking things, probably. I doubt Xfinity home service would do it for you.
It would be nice if someone made a wiki somewhere of which ISP's worldwide will do this on which plans.
I'd really like to have two ISP's and BGP peer with both, so that if one goes down all my systems keep the same IP address and maintain connectivity.
The whole idea of everyone having just one connection in a fragile tree-like structure seems against the original design goals of the internet.
>It would be nice if someone made a wiki somewhere of which ISP's worldwide will do this on which plans.
More or less all of them with a business tier of service will do this.
>I'd really like to have two ISP's and BGP peer with both, so that if one goes down all my systems keep the same IP address and maintain connectivity.
The smallest subnet that is going to get advertised outside of your ISP (outside of the ASN you're in) is a /24, you can't have multiple ISPs and get that kind of address space for your personal stuff.
The design goals of the Internet you're referring to are about networks not going offline, a global routing table with individual entries for every user is not sustainable.
> The smallest subnet that is going to get advertised outside of your ISP (outside of the ASN you're in) is a /24,
In an IPv4 world. In an IPv6 the equivalent is a /48
It's far easier to get a ipv6/48 than a ipv4/24 (naturally).
> The design goals of the Internet you're referring to are about networks not going offline, a global routing table with individual entries for every user is not sustainable.
With a bit of a redesign it would be. Most mesh networks tackle this problem. In the worst case, a routing table entry for every human in the world is only 8 billion entries, which would fit in RAM on a typical server today. And every optimization you do dramatically reduces that number (eg. make users who have similar network configs and peers have neighbouring addresses, allowing you to coalesce potentially millions of users into a single route)
It would fit in RAM but then you actually have to search through RAM. I have a router that is doing a very modest 3gbps of traffic, or about 2000pps that all need lookups, and about 40 updates per second that goes into that table.
I should also mention that's 40 updates per second for a default free zone of about 950,000 routes. 8 billion routes would be an minimum update frequency of ~370,000 routes per second assuming the same stability.
What about updates? Propagating routing table changes for even 8 billion devices (assuming each human has on average one device, which is quite the assumption to make) would be incredibly resource-intensive.
Your challenge is getting every ISP to accept this. The routing table might fit in the RAM of a typical server, but perhaps not so easily in the RAM of many routers still deployed in the field.
It's a nice idea, but sadly it'll lose out to commercial realities in many cases.
I'm just saying that rearchitecting the Internet / routers to support billions of routes would be a challenge, and it might just be too slow to have a routing table that big.
If you are in RIPE land you can get a PI (provider independent) /48 from a LIR (a RIPE member) and ask your datacenter to announce it.
https://www.ripe.net/manage-ips-and-asns/ipv6/request-ipv6/h...
https://tunnelbroker.net/ will give you a free IPv6 subnet and you can route it over your existing IPv4 link. I think you can get either a /64 or /48.
I had a tunnel with them I was using for a while, but ended up turning it off a couple of months ago.
Any request to a CDN will be slower since you’re not hitting the cache closest to your actual ISP, and since it’s “a VPN” a lot of things start to break, need more captchas, or get blocked for you since there’s a higher level of abuse from HE’s tunnel broker IP blocks.
Oh wow, I didn’t know they were still around! I used that to get an IPv6 address more than a decade ago; I think they used the bastardized IPv4-mapped-to-v6 address format at the time. But iirc it involved extra network hops because it was tunneled rather than routed, but maybe I’m misremembering.
I’m guessing they have larger blocks for sale?
Sorry to mislead--you're correct, it is a tunnel.
I was very happy to get symmetric Gig internet at my new place but very bummed that my ISP doesn’t offer IPv6.
I had enjoyed learning about and deploying it on my LAN whenever Comcast added support (SLAAC is magical) but I guess I’ll be waiting for quite a while to play with it again :(
There's also a cool trick you can do with IPv6 addresses for servers where you use RA to broadcast your IPv6 prefix on the LAN and the OS assigns itself a valid public IPv6 using the MAC address for uniqueness. Very clean and easy.
Hoping AWS and my ISP implement IPv6 before I retire...
(AWS has partially implemented IPv6, but it's still not usable in my mind)
> route when you can, switch only when you need to mantra
Naive question: isn't switching faster than routing?
Only at small scale: the flat MAC lookup quickly becomes more expensive than matching against a handful of (post-consolidation) routing prefixes.
E.g. in their setup only the switch the hosts are directly plugged in needs to be aware of the individual hosts; all other switches/routers only look at it with a granularity no finer than this access switch. And at some point even coarser.
All 'boring' packets are hardware switched/routed with no CPU involvement in everything bigger than your home cable router.
For both switched and routed networks it's possible to build hardware that can route at the same speed as the ports, so in 2024 performance isn't really a reason to choose switched or routed.
Cost might be though - I believe that for the same number of gigabits, hardware sold as a switch is substantially cheaper.
500 routes are still cheaper than 50k MACs, though, but I might be off a little with the number threshold there.
Market segmentation is a thing, sadly :(
It is; it also provides less control. Some networks do it one way and some do it the other way.
IPv6 is great, but it does open up new challenges with traffic management, reputation, and bot analysis. We need advances there.
[flagged]
We need something better than IPv6 that better addresses the needs of users. IPv6 does too much and is too complicated.
If you think IPv6 is too complicated, you are either overestimating IPv6’s complexity or underestimating IPv4’s complexity. IPv6 is undeniably simpler. It has a cleaner header format that is simpler to parse, it has no need for on-path routers to perform fragmentation, it combines host/router discovery and various diagnostic control packets down into a single protocol called ICMPv6, it has stateless address autoconfiguration and correct link-local address behaviours amongst others. It fixes decades of mistakes that have accumulated in IPv4.
> IPv6 is undeniably simpler.
Perhaps to someone who's never been exposed to IPv4.
But for those who know IPv4 from before, it means almost a complete rewrite of all the knowledge. Just about every detail of setting up an IPv6 network is different from an IPv4 network, with just the superficial bits staying similar.
It also has bits that are undeniably more complex than IPv4, like dynamic address allocation. You got SLAAC, RA, stateful and stateless DHCPv6, with the latter being required in certain cases. And with that you now got two different ways to provide DNS servers to clients, and which one takes precedence is undeniably non-trivial[1] and even implementation dependent!
[1]: https://datatracker.ietf.org/doc/html/rfc8106#section-5.3.1
Any solution that requires updating clients, servers, and networking equipment to support the protocol and/or adjust the network address scheme of the environment will require the exact same steps doing an IPV4 to IPV6 migration would require.
Not so. IPv4->6 removes all existing v4 address blocks and redoes the addressing scheme. Those changes weren't necessary for expanding the address space. This implies that day 1 of using ipv6, all your addresses are different (and way longer), all your routes change, DNS DHCP etc all need to be swapped out, and bans/reputation are all reset with no clear replacement. And there were a bunch of smaller changes / new features.
Whatever you do to get more addresses, it will look similar in the end, but the steps could've been very different.
How would a computer with an expanded address scheme communicate with another device with an unexpanded IPV4 address? How would that client get its response back?
How would a router know what to do with it without updating its software?
At the end of the day, you are talking about using a different than IPV4 address scheme and using a different protocol than IPV4. Everything in the stack will need to be updated. Every hop on the route, every single piece of software that will interact with the network address. Backwards compatibility still requires everything but the older device to be updated.
Yes, everything has to be updated eventually, but going forward doesn't have to be this hard. A network and its hosts could start supporting ipv6 without changing anything else. Same addr and routes as before, same NAT, and no DNS6/DHCP6/etc, so very low effort and risk to turn it on. If a peer only supports v4, talk v4 to it for now.
Then once there's sufficient v6 adoption, you can disable v4 entirely and start using /40, /48, etc..
> Same addr and routes as before
But same addr is the problem we are trying to solve in the first place. Using your IP-new proposal (let's call it IPv5): If every IPv5 addr is just a padded version of the same IPv4 addr, then once IPv4 addresses are exhausted the IPv4-mapped-into-IPv5 addresses are also exhausted.
At that point you need to start handing out IPv5 addresses to hosts without an IPv4 address. And then, how does a IPv5-only host talk to a IPv4-only legacy host? That's the fundamental issue!
The same addr thing only buys you time until the address exhaustion becomes real.
But you can do that with IPV6? I have both an IPV4 and IPV6 address on this very device.
My confusion in the claims that we could do it differently is how the protocol could be updated without actually doing the work of updating everything on the network and adding the new address scheme.
What do you suggest as "something better than IPv6"?
v4 but with a larger address space?
How is that better than IPv6? Remember that there is no way to squeeze more address bits into IPv4 header, that need to come up with a new protocol. In fact, need to come up with a whole suite of new protocols. You could just make the addresses bigger but still need to deploy.
IPv6 changed some things, most of them for the better, and it already works. The only problem is migrating and the problem is people who don't want to switch.
One example of how IPv6 is better than IPv4 with more address bits, is that 128-bit address is big enough to put the whole IPv4 address in. NAT64 put the IPv4 address in the 64-bit host section. MAP-T puts the whole NAT state in address, getting rid of expensive CGNAT.
I don't understand why all my devices randomly assign themselves non-functional IPv6 addresses with no involvement from any router. Often it's even multiple non-functional IPv6 addresses.
IPv6 assigns link-local addresses automatically. They are for talking to other computers on same the network. It works when you don't have router. It won't interfere with anything else.
IPv6 supports multiple addresses on each machine for different scopes: global, internal, local. IPv6 uses address hierarchy to figure out which one to use to reach destination.
Why?
> It works when you don't have router.
Who doesn't have a router?
Computers connected by a switch? Another scenario is when you connect two computers directly by Ethernet.
Or... Peer to peer links between your router and the ISP?
Hard to take seriously any suggestion which look at ARP (and the other warts in v4) and goes "yep, let's hang onto those".
"Let's make a new, backwards incompatible protocol and not learn anything from the old one" doesn't feel like a good idea to me.
I see nothing wrong with ARP.
Every proposed alternative to IPv6 that I've ever seen has just been IPv6 with extra steps. What's yours?
That's my proposal, ipv6 with extra steps. As in, incremental steps instead of one impossibly big change. tl;dr keep the pre-existing v4 /32 blocks day 1, and the rest follows.
Edit: I said "my" proposal, but pretty sure the same idea has been brought up many times.
Getting rid of IPv4 address allocation is one of the huge advantages of IPv6. IPv4 is chopped up into little pieces and the routing table is mess from it. Starting from scratch, IPv6 can make that better.
IPv6 also realized that most people don't need their own address space. It is valuable in IPv4 to own an allocation, but IPv6 is so huge it doesn't matter.
For setup, IPv6 does it automatically for customers. Peering requires entering IPv6 addresses, but that is a one time thing.
> Getting rid of IPv4 address allocation is one of the huge advantages of IPv6. IPv4 is chopped up into little pieces and the routing table is mess from it.
Basically IPv6 only solves problems if you're paid full time to do network administration.
If you just run a small network among other things, it creates problems. Because you can't hold the new structure in your head if it's not your main job.
> Starting from scratch, IPv6 can make that better.
Yeah right. Want that "things you should never do" Joel link?
He was talking about Netscape, but I think IPv6 is a much better example.
Yeah, the route fragmentation a disadvantage of what I've had in mind. My focus is just on getting things to speak v6 to fix the scarcity problem first. Maybe at some point the owners could've swapped addresses back to defrag things.
IPv6 is better than IPv4 and NAT. Your connection has been reset by peer.
[flagged]