IPv6 just turned 30 and still hasn’t taken over the world, but don't call it a failure In the early 1990s, internetworking wonks realized the world was not many years away from running out of Internet Protocol version 4 (IPv4) addresses, the numbers needed to identify any device connected to the public internet. Noting booming interest in the internet, the internet community went looking for ways to avoid an IP …
... is that it's easy to remember and read out a dotted quad but essentially impossible to remember or speak ff:12:34:56:78:89:0a:ff ... and it probably really is that simple.
If only they'd just added a couple more bytes to the address and left it with room to add more as needed.
Yeah, two dotted quads, like it. But you'd mostly only need one at a time, which would be even better, if it was sent via a service which used the other. Now that really would be impossible to dislodge. You could call it, oh, I dunno - NAT or something.
the committee looking at the successor to IPv4 ruled out variable address lengths as it hurt router performance
Having been there at the time, there wasn't a representative committee as such and nothing was really concluded as a matter of principle. In fact, it was a pretty anarchic process. The Internet Architecture Board were mostly persuaded (partly by Tony Lauck of Digital who had invested a lot of time in the ISO committees) that ISO CLNP was the way to go. The IETF (whose members were largely funded by equipment manufacturers, including Digital, but also Sun, Cisco, etc) revolted at what they saw as a stich-up that would not only advantage one specific manufacturer but shift the standards-making away from the IETF towards ISO.
The real issue with CLNP is it effectively meant that existing router hardware was obsolete - link state routing needs a lot more memory as each router has to store knowledge of the entire network (and we had to make significant changes to the ISO proposals as they went along to make it feasible even to build new routers within the technical and financial constraints of the time) and the longer addresses meant a change in approach to forwarding. Digital was even at this time developing hardware assistance for forwarding that processed incoming packets on a byte-by-byte basis which actually increased performance as you could making a routing decision before you'd even got to the end of the incoming packet header. They had already foreseen that increasing line speeds would mean that routers would inevitably require specialist hardware and that variable-length addresses were only an issue if you were trying to implement routing on what were in effect variants of commodity PCs. That, however, was precisely how Cisco was making its money - cheap 68000-based routers with just enough power to handle the linespeeds of the day. Sun also saw themselves as potential contenders in the same space using their sparc architecture and believed theiy could achieve the best performance taking advantage of its 64-bit word length.
So what really came about was a process in which teams essentially backed by other manufacturers came up with their own competing proposals, most of which were actually very similar but reflected the views of the various engineers about making the most of the hardware they had available at that point.
My view is that, while Digital obviously had a vested interest in promoting a solution on which they had done a great deal of work and for which they had products in development, they were essentially correct. CLNP was perfectly implementable in the next generation of routers that would inevitably be required to deal with increasing line speeds and the current generation of routing hardware (from which Digital was also making significant money) was effectively obsolete anyway as analogue lines were consigned to history. It was also pretty much ready to go, which would have been key to migration. At the time it was still feasible to transition the entire Internet to a new protocol without causing major disruption - it was still mainly confined to research organisations. The delay caused by infighting essentially scuppered that possibility and IPv4 had escaped into commercial networks long before IPv6 was finalised, at which point the commercial operators actively tried to avoid the impact that a transition to IPv6 would have on their business and on their customers and resulted in the foot-dragging that continues today.
Not for the first time, short-term self-interest triumphed over opportunity.
I don't have necessary knowledge to judge whether what I am about to ask it a stupid but I'd appreciate it if you could ELI5. It sounds like if IPv6 had a "IPv4 backwards compatible" mode then businesses could slowly make the switch and one day we could switch it off.
The "backwards compatible" mode was essentially maintaining both stacks (IPv4 and IPv6) until everything was converted and then turning off IPv4. This was perfectly feasible at that point in time and required the least amount of planning.
The fundamental problem that has arisen in the meantime is that there are now more computer systems than IPv4 addresses (or, at least, than IPv4 addresses that are available for allocation while maintaining a sufficient level of subnetting so that every individual address doesn't need its own route). That means a "backwards compatible" mode is simply impossible as IPv4 addresses are no longer unique: the fundamental principle that each interface has its own address is no longer true. That's why we have hacks like NAT that with varying degrees of transparency allow the temporary assignment and sharing of IP addresses by multiple hosts.
DECnet (Phase IV), which had an even more limited 16 bit address space was also intended to move to CLNP (DECnet Phase V) and some of Digital's larger customers had already found application-level hacks when they had run up against the limit. Although Digital had a very detailed migration scheme and proprietary information in the Link State packets that allowed regions in the network to switch automatically to the new protocol once the right conditions were in place, its larger customers mostly transitioned (ironically) to IPv4 instead which was much harder work. However, they saw a financial benefit owing to the (temporarily) lower cost of commodity router hardware from cisco et al.
And that's the other factor at work now. Organisations used largely to run their own networks. They rented lines from their local PTTs. They could set their own standards. These days you can't move to a new standard unless everyone else does so too, so there's no real financial incentive: you're dependent on the goodwill of others for your return on investment.
having been there at the time, this analysis is selective and only partly true. Some of the less correct things include: address lookups - it was well known in the early 90s that any hardware lookup mechanism would have a hard requirement to to be able to inspect the maximum address length, so variable length addressing was known not to provide any real technical advantage; the "real" technical issue with clnp and the iso protocol stack was that it was going to make the entire tcp/ip stack and socket API obsolete, not specifically that it also needed router replacement, although it needed that too; the political reason for rejecting it was that there was a vicious dispute between the ISO and IETF camps. By fair means and foul, the ISO repeatedly attempted to squash TCP/IP and the IETF, which caused a boatload of animosity to say the least (leading to some entertaining rants like Padlipsky's "The Elements of Networking Style"). One of the larger nails in the coffin was NSFnet declaring its support for TCP/IP, which set the stage for the commercial internet of the mid-90s, by which time it was already long past possible to switch over to the OSI protocols. In regard to DEC's networking stuff, they were mostly licensing cisco ip routing kit at the time (leading to odd products like the DEC Brouter - a rebranded Cisco IGS, the predecessor to the better known Cisco 2500). They did some foundational work in IP routing, but their revenue was firmly from layer 2 kit aimed at DECnet. You could charge an arm and a leg for that, so that's what they did, at least where they they weren't able to get a kidney too. It is true that most routers at the time supported more than just IP, e.g. CLNS, IPX, DECnet, X.25, etc, but support was half-hearted, e.g. no ES-IS support (the OSI "equivalent" of BGP), etc, so even if it was implementable, it wasn't implemented, and the routing kit of the day consequently wasn't up to scratch for general purpose networking, including inter-domain routing.
Some bits of the OSI stack still survive: CLNS continues to provide value in the ISIS protocol, which is quietly a raging success all over the internet. X.500 was butchered to create LDAP, which was then adapted by Microsoft to build Active Directory.
In regard to stating that the commercial operators were dragging their feet, RFC 1883 was published on Jan 3 1996, and the only thing that could forward it on day 1 was your Solaris workstation. 2000::/3 addresses became available in Europe in 1999, but before that, you could only get ipv6 address space by emailing Bill Manning, and asking for a block out of 3ffe::/16.
Cisco and others started building ipv6-capable images around 1997-1998, but the early day support was terrible and it wasn't possible to roll out commercial grade ipv6 services, which meant that there was no such thing as native ipv6 service. The operator community at the time went blue in the face demanding that the kit manufacturers provide better ipv6 support, and the response was always: you're the first organisation to ever ask for ipv6 and that's why it's not there, honest guv. It's flat wrong to state that commercial operators actively tried to avoid ipv6 rollout. Operators tried and failed to deploy it at the time because it was undeployable due to implementation and environmental immaturity.
Commercial routers mostly achieved protocol parity in the mid 2010s, i.e. a full 20 years after the protocol was standardised. This happened mostly because of demands from the larger commercial operators (for example Comcast, who had a genuine business need for vast amounts of address space and who drove ipv6 support in DOCSIS, and the cellular network operators who needed it in 3GPP), and this only happened because ipv4 had effectively run out, i.e. there was a compelling business reason for it.
IPv6 failed to reach its aims because it's not compelling enough to cut over to it. It has one and only one advantage: more address space. There are some partial sub-advantages around this, e.g. relating to NAT, but they're not black and white "NAT is bad and no NAT is good" reasons. There are plenty of organisations where deployment of ipv6 can provide enough value that it's worth deploying as dual-stack, but the number of organisations where this is a compelling enough reason to abandon ipv4 is close to, if not exactly, zero. Probably things would be marginally better if ipv6 was the only networking protocol in use, and ipv4 was fully retired, but I don't think there's enough in the difference to conclude that short-term self-interest triumphed over opportunity. People made choices, and everyone can still watch their cat videos and use whatsapp. No-one knows or cares what's happening at the protocol level because all the important stuff happens way above the layer 3 header, and it's been like that for decades.
-ss
Not having been there at the time I can't verify either of these slightly conflicting views in this thread, but what i can confirm is that most standards setting is an anarchic process driven by manufacturers fearful of ceding any competitive advantage. The upside of having a standard is some degree of inter-operability, the downside is that its often a manky cludge. Look at the horrible, horrible mess that the standards committees made of USB plugs and sockets. USB A: Too large, can only be inserted one way, USB B: errr, what exactly did you want this weird thing for?, Mini USB "let's have another one-way to insert" plug, Micro USB "and again, but with no durability at all". USB C is at least better than all other USB connectors, but it's still inferior to (eg) Lightning due to the unnecessary tongue-in-socket. Almost as though the French designed all USB connectors.
Really is about time we rounded up all those accountable for USB plug and socket designs, and did something dreadful to them.
Durability? Lightning connector? -Yes, let's design another connector like it which has it's contacts EXPOSED to get dirty/damaged/shorted/mangled, etc. Talk about another bad "engineering" design by an Apple 20 something behind a computer and CAD program. You obviously aren't in the electrical/electronics maintenance repair field or you would look at tongue-in-socket connectors more favorably.
>” You obviously aren't in the electrical/electronics maintenance repair field or you would look at tongue-in-socket connectors more favorably.”
Both Lightning sockets and the “smaller” USB ports with tongues are buggers when it come to removing the pocket lint that tends to accumulate in these small spaces…
Now the ancient Centronic’s connector and socket could be easily cleaned out… :)
Centronics!-yes, DIN connectors-NO. The point is-exposed connectors aren't a good idea and I've had to replace many lightning cords for clients (and myself). But, bent DIN pins and lint filled C connectors don't necessarily make the list of "good" connector design either. BTW, I've never run into a lint filled C connector but, given time, I probably will.
Bent pins - I found these surprisingly common on DIN keyboard connectors - especially the 6-pin mini-DIN (PS/2 keyboard), but also had a few on RS-232 D-type plugs.
> I've never run into a lint filled C connector
I’ve not had a lint filled one - yet, only one’s (on phones and tablets) with just enough lint to be compressed and “glued” in place to cause the plug to rock and intermittently connect, usually users notice it’s not charging. I’ve made my own lint remover pick out of a 0.25mm guitar plectrum.
Durability? Lightning connector? -Yes, let's design another connector like it which has it's contacts EXPOSED to get dirty/damaged/shorted/mangled, etc.
Indeed. But a new power lead is cheap as chips, whereas replacing a damaged device socket is many times that (and on any mid life or older device, often technically feasible but economically unwise).
I had a 10inch Amazon Fire with a damaged micro-USB socket. Screen and battery were fine, but it would be beyond my skills to replace, and the cost of getting it replaced commercially were greater than a new device. I'd much rather have damaged leads (and even then I find Lightning more more damage prone that USB).
> Probably things would be marginally better if ipv6 was the only networking protocol in use, and ipv4 was fully retired, but I don't think there's enough in the difference to conclude that short-term self-interest triumphed over opportunity.
The *social consequences* would have been enormously better. P2P would actually work. Self-hosting would be much more practical.
> everyone can still watch their cat videos and use whatsapp.
The fact that "watching cat videos and using WhatsApp" are the standard paradigm for what the Internet is about is probably traceable in significant part to the failure to adopt IPv6 (and, now that it is being adopted, to forcing it into the mold set by IPv4).
I agree that it wouldn't have made a lot of difference in "the Enterprise" or "organizations" (which is probably who the "kit manufacturers" were really listening to). But the concerns of "the Enterprise" should be pretty close to the end of the list.
By the way, I worked at Cisco, and every time we'd try to push IPv6 *internally*, we'd *also* get the "customers aren't asking for it" story.
> Customers aren’t asking for it
I had a requirement on a network project in 2000 to support IPv6. IIRC we declined on that requirement because we couldn’t verify an application service using v6 because there weren’t any.
Fast forward to today, my ISP router supports v6 and hands out a v6 block for my own network, and it all works even if the v4 bit packs up like it does now and again. I grew up with this yet I’m still puzzled why each device gets 3 v6 addresses. Public and link-local, yeah I get that, but what’s the third for?
If you ask such a question, what about delivering an ipconfig /all instead of letting the world guess? This is like the "my computer is broken" support call, whereas after asking ten times back the real problem was a specific document did not print right in Word on a specific printer - other printer fine, other program on "failed printer" fine and so on... But call was "computer broken".
As a hint, here MY real world example from "right about now, the funk soul brother" (shortened to the relevant lines), and what you should have delivered in first place when asking such questions...
C:\>ipconfig /all
Ethernet-Adapter Ethernet 3:
Verbindungsspezifisches DNS-Suffix: notyourbusiness
Beschreibung. . . . . . . . . . . : Intel(R) Ethernet Connection I219-LM #2
DHCP aktiviert. . . . . . . . . . : Ja
Autokonfiguration aktiviert . . . : Ja
IPv6-Adresse. . . . . . . . . . . : 2001:9e8:aade:dd00:1723:e17b:48f1:10df(Bevorzugt)
IPv6-Adresse. . . . . . . . . . . : 2001:9e8:aade:dd00:22c3:4fde:473e:39f8(Bevorzugt)
IPv6-Adresse. . . . . . . . . . . : fd53:ba93:a3fa:0:3622:ac69:dbb2:77cc(Bevorzugt)
Verbindungslokale IPv6-Adresse . : fe80::22c3:4fde:473e:39f8%7(Bevorzugt)
C:\>netsh interface ipv6 show addresses
Adresstyp DAD-Status Gültigkeit Bevorzugt Adresse
--------- ----------- ---------- ---------- ------------------------
Öffentlich Bevorzugt 1h52m22s 52m22s 2001:9e8:aade:dd00:1723:e17b:48f1:10df
DHCP Bevorzugt 1h30m19s 30m19s 2001:9e8:aade:dd00:22c3:4fde:473e:39f8
Öffentlich Bevorzugt 1h52m22s 52m22s fd53:ba93:a3fa:0:3622:ac69:dbb2:77cc
Andere Bevorzugt infinite infinite fe80::22c3:4fde:473e:39f8%7
No, I won't translate this to English. If you can push Microsoft to add an "output in English" option, that would be nice for admins working with several OS languages. (On top the netsh output is bad German, dammit, the translations were better 'round 2016)
So I have, currently, four addresses. fe80 = link local. fd53 = leftover from several years ago when I did a full-ipv6-LAN implementation with DHCPv6 etc blah for testing. Those two 2001: privacy extensions are active, so one of them is the "old one" with only 1h30m19s left, the other has 1h52m22s left.
EDIT: route print should be along with it too.
Ah yes, “computer is broken” covers a multitude of sins, some of them down to the users; my W95 laptop was a disaster waiting to happen in that respect. And I’ve also been on the receiving end of “system broke but nobody did anything” a few times, followed by me having to fly thousands of miles only to discover it really was Colonel Mustard in the Library with the Candlestick (logs don’t lie, people).
The additional v6 address(es) are link local and are likely down to MacOS playing with WiFi privacy by rotating MAC addresses every now and then and confusing the heck out of my DHCP server.
Actually it's quite the opposite re: privacy and tracking.
An IPv6 prefix is quite effective at identifying a location while the host address, even if it's a so-called "privacy" address gives additional insight to advertisers and data harvesters as to which device on the network made the connection. The network itself doesn't leak information to the enemy like that when a bunch of devices are jammed behind IPv4 NAT.
IPv6 allows a full address to be assumedly a unique identifier, even if only for a short while. IPv4 NAT breaks that assumption.
What's more, IPv4 exhaustion has made ISP DHCP even more important and with even shorter lifetimes.
Having a static IP matters if you want to run a persistently identified server. "Persistently identified" is not helpful to privacy focused users.
Neither NAT or DHCP were designed as privacy features, but both play a significant role in preventing trackers from making certain assumptions created by IPv6 leaking device identities behind CPE.
Just a couple of points of clarification.
Firstly, I didn't intend to imply that variable-length addresses were a technical improvement, merely that they weren't a handicap and the techniques you might employ to deal with them would actually be an improvement on the traditional receive complete packet/look up route/forward that was typical of the time. And of course there was nothing intrinsically about CLNP that required the use of varaible-length addresses in any particular deployment.
CCITT/ISO was perceived as hostile to TCP/IP, as was the European Commission. I think that's partly a misunderstanding of the different role that standardisation played in harmonising European markets and partly a reflection of the typical response of the freewheeling tech bros of the time faced with the prospect of regulation. CLNS was something of a trojan horse in ISO: it was in essence TCP/IP reworked to remove some of the limitations (addressing and TCP window size, essentially) and to be sufficiently compatible with the other parts of the OSI model to get the standardisation stamp which would allow government sales in Europe of what was basically Internet technology in competition with the connection-oriented services from the PTTs. This of course is the bit no-one wanted to say out loud.
I'm interested by your reflections on the immaturity of commercial IPv6 products because what I heard back then from manufacturers was that they were struggling to get interest in field testing IPv6 features. There's clearly been some breakdown in the supply-demand cycle, but maybe that's, as you say, simply because it's not compelling enough.
This post has been deleted by its author
No reason it should. An additional dotted quad can be easily implied (and stored explicitly, internally) in much the same way that area codes and country prefixes have been handled by switched telephone networks ever since they replaced dial-by-operator.
One more dotted quad would have been enough and would have expanded the public address space by more than 255x (let's assume no leading 0) because huge swaths of the expanded space won't be made reserved/unroutable in the same way IPv4's designers did when not giving serious consideration to the exhaustion issue.
But also... they did! How many bits do you think there are in "2001:db8:a:1::2"? Sure, there's room to expand to 128 bits in there but in terms of actual used bits it's about the same as the 64 bits you end up with in v4 from effectively having two v4 addresses for every machine. (Or worse, in the case of CGNAT or businesses that remap RFC1918 because they had clashes, where there are more v4 addresses involved.)
I propose IPv5: an additional dotted quad
Adding any number of bits at all requires doing all the work v6 is doing. If you're going to bother, you might as well add enough to avoid needing to do it all over again immediately afterwards.
>> Adding any number of bits at all requires doing all the work v6 is doing. If you're going to bother, you might as well add enough to avoid needing to do it all over again immediately afterwards.
All the work? I don't think so. Adding one extra dot is a lot less work, and a lot easier to understand.
The implementation work, getting equipment and software to handle it, getting addresses assigned, getting international routing stable, is all the same. That's the work that's noticeably hard and expensive, whereas the difficulty reading out a string of digits is much smaller if it's relevant at all. What part, other than your memorization or reading, do you think would have been easier with 40-bit instead of 128-bit addresses?
Exactly. Who gives a toss about IP addresses other than network admins? And even they only care about addresses on their chosen segment(s) so don't have to remember or write more than 8 digits. I have a static IPv4 address and all I can ever remember is that it starts 91 and that the second number possibly starts with 5. I had to tell my domain provider what it was once (along with the IPv6 address I use for my mail server) but no-one else has given a damn about it in the nearly a dozen years since I switched to my current ISP.
There are some aspects of IPv6 that are more complicated than IPv4 and that can quite frankly 'do yer 'ead in' but the length of the address is not one of them.
Exactly. Who gives a toss about IP addresses other than network admins?
This view misses the obvious fact that network admins are the people who have to implement IPv6; and our near universal disgust with it is literally the sole reason that it has failed to displace IPv6 after 30 years.
If having to occasionally deal with a string of hexidecimal digits is what's putting people off then I have just lost some of the admiration I tend to have for network engineers. As a (now retired) computer programmer I've often had to deal with long strings of hexadecimal - many dozens of digits at a time when viewing memory dumps - and they never caused me any problems.
I've often had to deal with long strings of hexadecimal - many dozens of digits at a time when viewing memory dumps - and they never caused me any problems.
Yeh, but how many people can you kill when you get 1 hex character wrong? See also AWS, Azure, Cloudflare outages, and all the others caused by misconfigurations. Complexity just increase the risk of failure, especially when there was no real need to cast hexes on once simple IP addresses.
> Besides, how is fe80::4 or ::1 any longer or more complicated than 121.315.123.191
It's right in the RFC: IPv6 addresses have multiple ways they may or may not be shortened. The rules were created precisely because fully expanded IPv6 addresses are so long they are unwieldy to humans. An IPv6 address can be expressed in many equivalent ways. That's complexity.
IPv4 addresses are expressed one way, which in the real world, makes them simpler and much easier to work with, particularly in tasks like pattern matching.
All that complexity could have been avoided by simply adding one more octet as an optional prefix, which would have expanded the global IP space by > 255.
You can shorten ipv4 too.... Try those: ping 127.1 and 127.0.1 and 127.1.1, ping 0 or ping 0.0. Works with powershell cmdlets too. Usually nobody responds on the latter, you'd have to try UDP-ping on a port which gives a response, but out of my head I can't tell a typical service which does since DHCP/BOOTP client use 0.0.0.0 as "peudo" address and don't "respond" there.
> You can shorten ipv4 too.... Try those: ping 127.1 and 127.0.1 and 127.1.1, ping 0 or ping 0.0. Works with powershell cmdlets too. Usually nobody responds on the latter, you'd have to try UDP-ping on a port which gives a response, but out of my head I can't tell a typical service which does since DHCP/BOOTP client use 0.0.0.0 as "peudo" address and don't "respond" there.
Nobody actually does that, because IPv4 addresses are simple enough that nobody has to. Any PFY who did that would be immediately yelled at by the boss.
By contrast, IPv6 shortening is frequent, because it's necessary.
Although it does sound like an obvious solution, the reality is somewhat more complex.
10.16.14.12, does sound like it’s four numbers, no it is actually a single 32 bit decimal number which happens to be expressed in that way to make it easier for us meatbags to process. Every network device on the planet sees it as a single number of a fixed size, ie 32 decimal bits.
So let’s imagine that we add an extra number, so an IP address of 17.10.16.14.12, so now a 40 bit address, fine, but how does that help? All existing devices only understand 32 bit addresses, do they chop off the first or last octet?
What I am saying is that simply trying to extend the existing system, doesn’t really help much, you are going to have massive problems whatever you do, so maybe the best solution is to simply go ‘screw it - this is the new addressing scheme, it uses a totally different notation, but it should suffice for the next few millennia or so’?
But does it matter? I’m certainly not one of the IPv6 hysterics who proclaim the end of world if it isn’t taken up NOW by every ISP - we keep IPv4 working, fine, and when and it the day comes when it can’y work any more, there is a replacement in the works.
@Excused Boots
10.16.14.12, does sound like it’s four numbers, no it is actually a single 32 bit decimal number which happens to be expressed in that way to make it easier for us meatbags to process. Every network device on the planet sees it as a single number of a fixed size, ie 32 decimal bits.
nope,
its 4 x 8 bit numbers, 0-255 (256 total numbers)
IP addresses are hierarchical & the word boundaries are important. The host uses the subnet mask to know what parts of the address are the subnet the Host is on & therefore reachable directly & everything else needs to go via the gateway as specified in the route table.
There is nuance in there.
No, I'm afraid you're wrong and the OP is indeed correct. Network devices handle IP addresses as a single 32-bit number. Bit masks are what give you the "hierarchical boundaries" you refer to in terms of subnets. There is absolutely zero benefit to treat an IPv4 address as four separate numbers unless you're a human.
The question that comes to my mind is; does current network gear use 64bit CPUs? If so, it would make little difference if you changed 'IPv4.5' to a 64-bit number. The full address would still fit in a single register. With NAT there shouldn't be the incredible future demand for IPs that they originally planned for. And it should be possible to implement without giving everyone new IPs. Bragging rights for OG IPv4 addresses....
It would fit into a single register, but it wouldn't fit into the 32-bit wide address fields in the v4 packet header, or the 32-bit wide fields in the socket structures, or the 32-bit wide A records in DNS, and so on and so forth. No existing v4 equipment would be able to use it.
It's not possible to implement 64-bit addresses without giving everyone new IPs, for all the same reasons that it's not possible to implement 128-bit addresses without doing so. If it was, v6 would have already done it.
There is no way you're getting around changing packet headers, no matter what solution you choose. Unless it's just stay with IPv4 forever. But it's a whole lot easier to change uint32 to uint64 in the code and increment the protocol version than it is to do all the stuff that is in IPv6.
And you don't have to re-allocate existing IPv4 addresses because all that would happen is the high order bits would be 0. 104.18.4.22 becomes 0.0.0.0.104.18.4.22. Reserved addresses wouldn't need changed. Private network blocks would still work. It would be a problem for anyone foolish enough to convert IPs into dotted quad strings and assume any IP starting with 0. is reserved. You can't do this with IPv6 because all the new rules they implemented for IPs, not because they are increasing the address size.
v6 does integrate the v4 space at e.g. 0.0.0.0.0.0.0.0.0.0.0.0.104.18.4.22, so I don't buy your assertion that you can't do it in v6. The problem is that doing it doesn't actually help at all.
Why can't you just change uint32 to uint128 and increment the protocol version to deal with v6? Or well, I know that expanding the address size is a bit more involved than that, but that extra work would also be needed to move to uint64 too. What are you gaining by making the new protocol too small?
v6 does integrate the v4 space at e.g. 0.0.0.0.0.0.0.0.0.0.0.0.104.18.4.22, so I don't buy your assertion that you can't do it in v6
You can't do it because IPv6 REQUIRES MORE than just extending the address space.
What do you gain by going from uint32 to uint64? A whole lot of new addresses. Google says 4,294,967,295 vs 18,446,744,073,709,551,615.
Why not go larger? The fucking original premise that if network gear is using 64 bit CPUs then it still all fits in a single register, allowing you to work with it without messing with memory locations.
But it's all just a bullshit what-if, not some serious plan for another IP protocol. Maybe we can IPv6 the Unix timestamp next decade too.
Then you can't do it with your suggestion either, because what you're suggesting also requires more than just extending the address space. That's kind of the core problem: you can't just make addresses bigger and be done with it. So much other stuff also has to change to accommodate that.
"You can fit the addresses into a single register" doesn't seem like it could possibly be worth the cost of not having enough address space, considering that a 128-bit address can be loaded into a pair of registers just fine. Especially when almost nobody is working with v6 addresses at the level of loading them into registers. The closest most people get is C, where the register handling is done by the compiler. (Or well, really the closest most people get to working with IP addresses is tapping on search results in their browser.)
This post has been deleted by its author
Network devices handle IP addresses as a single 32-bit number. Bit masks are what give you the "hierarchical boundaries" you refer to in terms of subnets.
Not entirely. Network devices handle packets based on the IP address and subnet mask
There is absolutely zero benefit to treat an IPv4 address as four separate numbers unless you're a human.
Most of us are human, and thus we err.. which becomes a lot easier to misconfigure things when addresses become longer and more complex. But the history involved a certain amount of wheel-reinvention, along with vested interests. Like the ability to route based on MAC address, even though sane security types probably don't want those exposed. Or ignoring the way telephone networks pretty much solved the number space exhaustion problem over a century earlier.. just adding more numbers. Just slap 101100 on the front and the UK gets 4bn IPvX addresses, plus the ability to do saner geographical routing, just as the phone networks do. If 4bn addresses weren't enough, just add another octet.
Usual argument against this was having to reconfigure all the things, but IPv6 made that necessary anyway. So network devices need to be 'dual stack' to use both & decide how to handle an incoming packet based on the first 3 bits. Plus they also missed a trick by carrying over another legacy, ie the source address coming before the destination, which Vint Cerf told me was a 'feature' from the DoD days when the sender was more important than the recipient.
"the way telephone networks pretty much solved the number space exhaustion problem over a century earlier.. just adding more numbers."
Attractive though this is as a solution, it isn't going to work. Telephone numbers are stand-alone sequences of digits. IP addresses are embedded in fixed length headers. If you extend an address it tramples over something else, either before or after it. The only way to handle it would be to have variable length headers, count the header length and then work out from that which bytes are address and which are other things. If the IPv4 had been specified in that way initially it would have been possible but the world is full of S/W stacks expecting fixed length which wouldn't survive the first batch of extended addresses.
Attractive though this is as a solution, it isn't going to work. Telephone numbers are stand-alone sequences of digits. IP addresses are embedded in fixed length headers. If you extend an address it tramples over something else, either before or after it.
It could have worked. So the main difference between IPv4 and v6 are the first 4 bits of the packet, so either 4 or 6. There are other bits of the v4 header that were revised, ie EXP bits became DSCP so that CoS couldn't be implemented on the Internet <net neutrality, cough>. So set first 4 bits to 5 and create a new packet header, just as v6 did. But fixed vs variable length headers is also a IPv6 inefficiency issue given v6 supports a whole slew of extension header options as kludges for things IPv6 broke, and then the potential to break more things.. Like you're not supposed to fragment a v6 packet, but will have to if the transport layer has a smaller MTU than the packet.
But an IPv4 packet also defined the 4 bits following the version as the IHL (Internet Header Length) that gave scope for another 320 bits of header options, some useful, some less so. But given the move to v6 required entirely new network stacks, there was scope to make something simpler, more backward compatible and include country codes.. especially those, ie phone networks route based on the leading digits, so are faster than the bizarre v6 method of having to dive deep into the packet header to figure out where it might need to go.
It couldn't, for the reasons explained in the part you quoted: v4 addresses are treated as fixed length everywhere. At the moment you created a new packet header, you've given up on "just add more numbers to the beginning" and taken your first step down the path of reinventing IPv6. Once you start considering how to get existing software, OSs and devices working, you'll end up taking more steps down that path.
Or maybe you'll just get lost with weird claims. Extension headers aren't kludges for things v6 broke, and you are supposed to fragment packets if they don't fit into the path MTU. v6 is already pretty simple, and there's basically no possibility of making anything more backwards compatible than it already is. It already includes country codes, and v6's method of "read the destination address out of the packet header" is no more bizarre than v4's method is.
At the moment you created a new packet header, you've given up on "just add more numbers to the beginning" and taken your first step down the path of reinventing IPv6. Once you start considering how to get existing software, OSs and devices working, you'll end up taking more steps down that path..
That's kind of the point. IPv6 is a completely new version of IP, so as I said before, required all the software, OS, device updates to be usable. There could have been a better version of IPv6, but instead we're stuck with it.
Or maybe you'll just get lost with weird claims. Extension headers aren't kludges for things v6 broke, and you are supposed to fragment packets if they don't fit into the path MTU.
Allow me to quote you something-
https://www.rfc-editor.org/rfc/rfc2460#section-4.5
The Fragment header is used by an IPv6 source to send a packet larger than would fit in the path MTU to its destination. (Note: unlike IPv4, fragmentation in IPv6 is performed only by source nodes, not by routers along a packet's delivery path -- see section 5.)
...Links that have a configurable MTU (for example, PPP links [RFC-1661]) must be configured to have an MTU of at least 1280 octets; it is recommended that they be configured with an MTU of 1500 octets or greater, to accommodate possible encapsulations (i.e., tunneling) without incurring IPv6-layer fragmentation.
Must they be configured to support at least 1280 bytes? What if you have no control over the MTU of a link because that's provided by someone else and is an L2VPN.. or a common problem was end users on xDSL links with MTUs <1280 and the users IPv6 stack (or connection) doesn't support PMTU discovery, or support it properly. Then from RFC1981-
Nodes not implementing Path MTU Discovery use the IPv6 minimum link MTU defined in [IPv6-SPEC] as the maximum packet size. In most cases, this will result in the use of smaller packets than necessary, because most paths have a PMTU greater than the IPv6 minimum link MTU. A node sending packets much smaller than the Path MTU allows is wasting network resources and probably getting suboptimal throughput.
Which makes some rather large assumptions about path MTUs, or another issue with IPv6 vs IPv4, ie the 'goodput' or just throughput on a link. So customers complaining that their connection 'speed' has dropped going v4 to v6 because they haven't accounted for v6's header bloat.. And then look at all the exciting things that can be done (and sometimes have to be done) with v6 extension headers..
It already includes country codes, and v6's method of "read the destination address out of the packet header" is no more bizarre than v4's method is.
No, it doesn't include country codes. Try asking your RIR for assignments with those. I suspect that was politics again, ie if addressing and routing was based on country codes, then the country regulators might assume responsibility for managing their number space, ie Ofcom takes on some of RIPE's responsibilities and doesn't buy as much beer at jollies. And yes, both v4 and v6 are bizarre for putting the source address before the destination so a router has to read deeper before it can throw a packet <thataway>.
PSTN was a lot simpler because E.164 defined a 'simple' numbering plan (NANP <cough>) and national numbering plans allowed hierachical routing. So back in the good old days you could dial a number omitting the STD and it was treated as a local call and handled by a local exchange. Then-
https://en.wikipedia.org/wiki/Telephone_numbering_plan#Area_code
The strict correlation of a telephone number to a geographical area has been broken by technical advances, such as local number portability in the North American Numbering Plan and voice over IP services.
I'd say it was just broken, but that's progress for you. Ofcom gave up on out-of-area number usage in 2022, and removed the obligation to support local dialing because VoIP made that too hard. Ah, progress. Boop de Boop, the number you have called has not been recognised, please try again.. But lots of things the PSTN networks solved a century ago, now becomes a steaming mess, courtesy of the IETF.
>” But lots of things the PSTN networks solved a century ago, now becomes a steaming mess, courtesy of the IETF.”
We can add to that the concept of “Local” as in LAN. With the focus on end-to-end communications over a wide area routed network, people found the idea of local services, for example as surfaced by Bonjour difficult.
I remember people (diehard purists) back in the 1980s having problems with the concept of running MMS, a layer 7 protocol directly over layer 2 LLC, not understanding the messages only needed to traverse a single LAN and thus did not need to be routed and hence incur the overhead of routing protocols.
We can add to that the concept of “Local” as in LAN. With the focus on end-to-end communications over a wide area routed network, people found the idea of local services, for example as surfaced by Bonjour difficult.
Yep. We've kind of come full circle with that one. Good'ol 10BASE5 could run 500m with some decent coax and a small drill for the vampires. Now, when developing a pseudowire Ethernet service, we configured a link between two racks in Telehouse that went via Tokyo, just to see what would happen. Broadcast storms can go global! So now people can have wide-area switched networks, but there be monsters..
Like get the end-end connection from us, and you can transport 9kB jumbos, cobble paths together from multiple providers and the best you might get is 1500B. Then throw IPv6 and the Internet into the mix and run into PMTUD being generally broken. Sometimes because it relies on ICMP messages from intermediary routers, and routers generally don't like ICMP. In v4, it gets even more fun because due to address depletion and perception of security, router may have RFC1918 addresses, so ICMP response has that as a source and the server sitting behind a firewall doesn't see it because they reject RFC1918 addresses on their external interfaces. It's FUN!. Or generally on many home connections, just set MTU size to 1452B and call it good. Or Wireshark should show you if lots of fragmentation is happening.
(also made me remember FUN! with 3Com routers and switches that used an MTU size generally incompatible with the rest of the Internet)
Naa, it is a just a prefix mask. Lots of company networks have 10.x.x.x/20 /21 /22 /23 /24 /25 /26 parallel in use depending on what it is for. Bigger than /20 (aka /19 and below) is rare or a VERY old LAN, 'cause the possible > 4000 devices with their ARP requests start to use a bit more of the network traffic you want. That 4000 devices work more or less without problem is ONLY due to many things done in todays operating systems, switches and router to prevent ARP storms.
Check one of those many subnet calculators available online.
Not quite. IPv4 started off as two 16-bit numbers back before the 32-bit days ;)
If they had made it three 16-bit numbers, like in MAC addresses, the net wouldn't be arguing IPv4 exhaustion vs IPv6 frustration. We would be fine, and it would fit neatly in one 64-bit register, which the pioneers in those days knew would be a thing, eventually. 2^16 was a matter of then-limitation. 2^32 was a much welcome expansion. 2^64 was the final evolution. 2^128 will never happen for the base unit.
As for first vs last, the opening 0.* would be implied, because as you said, the address is just an integer.
With five dotted quads, the first two 0.* could even be implied.
Imagine how much simpler things would be if three dotted quads were, by definition, the private addresses, a fourth was required to route publicly, with the fifth being built-in from the beginning for potential expansion. Just like local phone numbers, plus area codes, plus country codes.
That compacted IPv6 address is still 128 bits as far as most memory structures and databases and on-disk logs are concerned.
Pretty much have to. Multiple ways to represent an address become an extreme performance nightmare when evaluating comparisons or pattern matches. Your search algo shouldn't be a long chain of _____ OR ______ OR ______ OR _____. It also shouldn't have to expand the input and expand the comparison for each comparison evaluated, every time it's evaluated.
Address print styles are for humans. Most well-designed software sees a v4 as a 32-bit int and a v6 as two 64-bit ints (or perhaps a pseudo-128/struct). One additional dotted quad would have kept everything nice and neat in our modern 64 bit registers while also giving room to add another quad, if needed or helpful, without having to completely reconfigure data structure sizes and header definitions.
I'm sure with a bit of creativity the optional headers in v4 could have been made to carry additional address octets. The argument against that is always about speed of routing but If you only use the extra address depth within private networks then that problem is greatly reduced because the core routers would never even look at the additional address depth.
That way instead of my ISP giving me a /29, which is an extremely wasteful way of letting me have 2 or 3 public facing servers, they give me a /32 (or a /40 or a /48) and I figure it out from there on down. Cloud providers could put literally thousands of servers behind each traditional v4 address whilst still having them all directly addressable. Hell, they could even charge more for putting you higher up in the routing strata.
Rule 101 about getting people to migrate to Shiny New Thing is make it completely backwards compatible with Crappy Old Thing so nothing needs to change on day one. I've used v4 almost my entire adult life but I expect to go to my grave without ever touching v6.
Yeah, we did that. Every v4 address automatically comes with a /48 tunnelled to it, that can be used basically like you describe. It uses the next-protocol field and puts the additional octets at the beginning of the payload area rather than using an optional header, but that's not a significant technical difference.
But what about DNS? You can't fit extra octets into an A record. What about the BSD socket API? sockaddr_in only has a fixed 32 bits. What about other protocols, databases, software, etc that also use fixed 32-bit fields for addresses? They can't fit more bits either.
We did more or less the exact thing you're suggesting here, and not only is it not enough to give the level of backwards compatibility you're thinking it'll give... it wasn't even enough to stop you from criticizing v6 for not doing it. If this isn't good enough, how could anything ever be?
Your point about API's is a bit of a non-sequitur. v6 had to introduce new variants of all of those. Difference is that v6 and v4 will forever live in parallel with each other whereas a v4.1 could have eventually absorbed v4 as a sub-set.
If they'd known back then they had decades to migrate then no doubt different choices would have been made. But they didn't so they didn't. Do you need any help to get down off your high horse?
But v6 already absorbs v4 as a subset! If you're going to talk about high horses, maybe don't complain about the things you think it doesn't do until you know a bit more about what it does do.
The APIs part is relevant, because it limits what sorts of compatibility are possible. For example, there's existing software out there that assumes that all socket addresses are sockaddr_in, or that use gethostbyname(). There's hardware out there that only does v4. Until you get rid of all of this, you'll continue to have v4 working in parallel regardless of how v6 is designed - because the v4 stuff doesn't use v6's design, it uses v4's design. Even if you make a "v4.1", you'll hit the same problem of the existing v4 stuff using v4's design instead of your v4.1's design.
v6 already does pretty much all of the forms of backwards compatibility that are actually possible with v4. I don't think there's anything a "v4.1" could do that v6 isn't already capable of. Feel free to correct me if there is, but if you give me yet another thing that v6 already does, I'm going to call you out on it.
But what about DNS? You can't fit extra octets into an A record. What about the BSD socket API? sockaddr_in only has a fixed 32 bits. What about other protocols, databases, software, etc that also use fixed 32-bit fields for addresses? They can't fit more bits either.
That's easy! Invent new ways to break things. So cribbing from wiki-
https://en.wikipedia.org/wiki/IPv6_address#Domain_Name_System
In 2000, the Internet Architecture Board (IAB) reverted this intention and decided in 2001 that arpa should retain its original function. Domains in ip6.int were moved to ip6.arpa[65] and zone ip6.int was officially removed on 6 June 2006.
Move slowly, and break things!
f.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.4.0.0.0.3.2.0.0.1.c.c.5.a.d.d.f.ip6.arpa. IN PTR derrick.example.com.
Simple, easy to remember and probably why DNS fat-fingering is starting to overtake BGP for creating outages.
Indeed. NAT was seen as a smell, and needing removing. Plus, since IOT was all-the-rage, they wanted every single node to be globally routable. This is, of course a privacy and security nightmare.
Some fiddling was done with router address translation to hide the identity of devices behind firewalls, but this is really window dressing.
If IPV6 was simply IPV4 with some sensible enhancements and wider addresses, we'd be steadily migrating. But oh, no! We had to have purity!
It's not a privacy or a security nightmare. IPs are just numbers; they don't tell you anything about the machine or its user. You gain no security benefit from NAT, and privacy extensions and RFC7217-style addresses prevent people from tracking devices between networks, or over time in a single network.
Just because an address is globally unique doesn't mean that anybody can connect to it. That's a policy decision that you get to make.
It's not a privacy or a security nightmare. IPs are just numbers; they don't tell you anything about the machine or its user.
If the IP address contains a MAC address, it can tell you a lot about the machine and potentially user-
https://en.wikipedia.org/wiki/Organizationally_unique_identifier
OUIs are purchased from the Institute of Electrical and Electronics Engineers (IEEE) Registration Authority by the assignee (IEEE term for the vendor, manufacturer, or other organization). Only an assignment from the MA-L registry assigns a new OUI. They are used to uniquely identify individual pieces of equipment through derived identifiers such as MAC addresses, Subnetwork Access Protocol protocol identifiers, World Wide Names for Fibre Channel devices or vendor blocks in EDID
Especially if you can compromise the vendor and find out who those devices have been sold to..
NAT is a privacy and security nightmare as NAT is regularly used as a substitute for a firewall when it isn't a firewall.
If a computer is on the internet, it should be able to do something as trivial as route packets to the internet without every single protocol being broken due to mangling of the packets and routers needing to keep state around (rather than just being able to route the damn packets).
In my experience, IPv4 only works properly when not NAT'd.
IPv6 is more or less IPv4 with some sensible enhancements and wider addresses - but its implementation has been constantly sabotaged by those with severe incompetence, who go out of their way to disable IPv6.
NAT was essentially a useful hack but it could lead to unrouteable traffic and attack vectors. The explosion of devices on networks due to the introduction of 3G services led to standardised "carrier grade NAT", particularly in Asia where the shortage of IPv4 addreses was most acute. Smartphones in Asia led to many networks going straight to IPv6 with a few gateways where necessary,
Fundamentally, the distribution of addresses was, and will probably remain the main problem: such resources should come with a plan for future reallocation…
Just as voice calls move towards VoIP NAT jyst creates headaches. NAT wasn0t designed as a safety net, it was just a consesquences and full cone NAT is stil not much secure since any WAN source can use the mapping (not all routers implements symmetric NAT).
Relying on NAT for security is just plainly stupid - and today all routers implement a firewall, so there's really no need for NAT from a security perspectice. Firewall states are much more secure.
Although, as I understand it, the original idea was that it shouldn’t be necessarily to understand or remember IPv6 host addresses, DNS would take care of it - err yeah!
Actually each host would have multiple IPv6 addresses, which could well change so making it a bit pointless. So the idea that ‘SERVER1’s’ address is xyz, became somewhat redundant.
Well that was the idea, anyway. Of course ‘your milage may vary’.
Actually each host would have multiple IPv6 addresses, which could well change so making it a bit pointless. So the idea that ‘SERVER1’s’ address is xyz, became somewhat redundant.
as I understand things, the IP changing was a result of privacy extensions to reduce tracking across different networks of mobile clients.
https://datatracker.ietf.org/doc/html/rfc4941
but yes IPv6 was intended for hosts to have multiple addresses on the same interface.
Not sure why they thought that would be a good idea.
> Not sure why they thought that would be a good idea.
Actual I think multiple addresses is a good idea.
1. The FE80::/7 is the former 169.254, always active, used for "same link" things, to some extend it replaces ARP, prevents ARP storms by design. Has the MAC coded into the address.
2. The FEC0::/10 (usually subnetted in /64 packets), similar to 192.168.x.x, but no "default gateway" for Internet desired, only clear other LAN destination routes.
3. The FC00::/7 (usually subnetted in /64 packets), similar to 10.x.x.x, but no "default gateway" for Internet desired, only clear other LAN destination routes.
4. The FD00::/8 DO NOT USE (usually subnetted in /64 packets), similar to 172.16.x.x, but no "default gateway" for Internet desired, only clear other LAN destination routes. This got removed from the standard somewhere in the last 20 years and replaced by FC00::/7 which included FD00::/8, therefore better avoid.
5. The FF00::/8 is multicast, similar to the 224.x.x.x
6. Finally the actual internet address, usually 2001:whateverfirst64bits:your-pseudo-static-part. Depending on the provider your prefix might be /56 /48 as well. The yourpseudosstaticpart is, on many devices, optionally with privacy extensions, so they are random and change over time even if your provider does not force-disconnect-reconnect. How much "privacy" that offers is a discussion for another decade.
Normal homes have 1 and 6. Über-Nerd homes or companies with somewhat clean ipv6 adaption have 1, 2 or 3 (not both please!), and 6 to organize their WAN/LANs. Enlightened Nerds include 5 too.
2 and 3 have the advantage that they are DEFINETLY not to be used for internet, no gateway to the internet, and therefore safe for LAN. I am nerd, but don't give a s*, so I have 1 and 6, and my fd* address is there for historic reasons since I played with ipv6 over a decade ago but not active in use.
My gripe is a lot of the things around it which makes ipv6 a hassle, especially when your prefix from 6 changes, all you adapters, and I mean ALL ACROSS YOUR WHOLE LAN, have to automatically follow suit. Which means: When connected to the Internet a lot of formerly static ipv4 configuration cannot be static any more - unless your provider gives you a fixed ipv6.
My gripe is a lot of the things around it which makes ipv6 a hassle, especially when your prefix from 6 changes, all you adapters, and I mean ALL ACROSS YOUR WHOLE LAN, have to automatically follow suit. Which means: When connected to the Internet a lot of formerly static ipv4 configuration cannot be static any more - unless your provider gives you a fixed ipv6.
This is one of the worst parts of it. And even if your provider gives you a static assignment, what happens when you change provider? Or if you failover on a multi wan connection? Or even try to load balance on a multi wan connection?
The only way IPV6 can be used with the same (even better) flexibility of v4 is when you own you v6 addresses and use a dynamic routing protocol, which is not what a small business usually does. A home user even less.
Then there is the security nightmares v6 can give you. I can't even imagine how many ways of abusing it are simply yet to be discovered, apart from the obvious ones like the fact that even if you don't use v6 to connect to the internet, you LAN has FE80 addresses all around and you have to firewall the hell out of it unless you want someone that penetrated the LAN to use them to move laterally almost for free.
> This is one of the worst parts of it. And even if your provider gives you a static assignment, what happens when you change provider?
Well, I hope you PLAN for that. Whether ipv4 or ipv6, you (usually) cannot take your IP with you.
> Or if you failover on a multi wan connection? Or even try to load balance on a multi wan connection?
This is what METRIC is for, same as for ipv4. ipv6 offers even a bit more, but I never had the time or will to get deeper into that part.
Next layer is software. Lets take, for example, Microsoft SMB3, introduced with Server 2012 / Windows 8: If you have two IP addresses, over two LAN adapters, they are automatically bundled on SMB side, with transparent double throughput or failover, you don't have to do anything except for having two or even more network cards with different IPs (depending on scenario better in same subnet). This way you can get 200 or 400 MByte/s with only gigabit available. I used that a few times for backup servers > 100 meters away from the main server room to speed things up across the bigger distance, where > 1 GB was not possible over the existing cables. Reduced backup time to half in the two-card scenario, to 1/3 in the four card scenario since the storage could not go faster. (yes again one of the very good things which came with Windows 8.0 / Server 2012 (non r2) completely overshadowed by the UI).
Oh, and of course, works with ipv6 and ipv4.
You already have to firewall the hell out of your v4 addresses to prevent someone that's penetrated your LAN from using them to move laterally almost for free. Needing to do the same thing again for a slightly different address is hardly a "security nightmare".
Most of your first questions can be broadly answered by a mix of "you advertise a /64 from the prefix that the provider gives you" and "you can use multiple addresses". And it doesn't sound like your use of v4 is very flexible if it can't handle your IPs changing sometimes.
>” And it doesn't sound like your use of v4 is very flexible if it can't handle your IPs changing sometimes.”
My reading of the original post was that a once static IPv4 configuration that could easily survive the change of ISPs and thus public IP address, isn’t so easy to achieve with IPv6.
If that is what they're saying, they've got it wrong. If you used an ISP-assigned block of addresses, you wouldn't keep them when switching ISP, so you would need to have a plan for doing something about the change in addresses. If you had your own block and just let the ISP announce it, then you could take that to your new ISP with some downtime as they sort out the announcement process, but probably not too much if you overlap ISP contracts. And you can do the same thing with an IPV6 block you've allocated directly. Big companies tend to do that. Small networks tend not to bother. Both should be completely expected by any competent network admin.
If that is what they're saying, they've got it wrong. If you used an ISP-assigned block of addresses, you wouldn't keep them when switching ISP, so you would need to have a plan for doing something about the change in addresses.
The plan should have been to make portability simpler, rather than more money for the RIRs.. But see also multi-homing. Why would anyone want to do that with IPv6? Just look at all those addresses!
fec0::/10 is long deprecated, and it's a bit odd to tell us to avoid fd00::/8 in favor of fc00::/7 when the latter includes the former. fc00::/8 is intended for /48s assigned by some central entity (but none has been set up, since there doesn't seem to be a pressing need for one) and fd00::/8 is for people to select their own random /48s from, so if you want to use ULA then you'll be picking a /48 from fd00::/8.
It's not exactly hard to hand out a new prefix to everything. Your router advertises the new subnet, and every machine across your whole LAN receives it and automatically configures a new IP from it.
Anything that assumes your IPs are never going to change is already broken. Maybe we should focus a teeny bit of the energy we spend complaining about it into fixing the brokenness?
Not sure why they thought that would be a good idea. Multiple IP addresses replace the idea of 'ports'. That allows DNS to address individual services, allows you to move services around, makes blocking and forwarding easier etc.
And it's tied to the idea that 'upload' is important for end users, ie the idea that every end user is a network admin / other end lusers should not see the network.
>” Not sure why they thought that would be a good idea.”
Another strand of reasoning was the use of IPv6 addresses to replace MAC addresses (there was an idea around back then of IP replacing IEEE LLC and MAC frames). An IEEE802 network port can have up to 6 active MAC addresses, to allow for multicast and what ever (sorry my memory of the details of 802 doesn’t remember the full reasoning etc. for this).
Basically, it seems a problem we are having to live with is the Swiss Army knife of concepts behind IPv6’s purpose and thus addressing concepts.
But that's not something average people care about, because they aren't remembering or typing IP addresses. It makes zero difference to them what happens under the hood when they type "google.com" into their browser's address bar and hit enter.
If you are remembering and reading out IP addresses, you are doing something very wrong.
But of course, there are people who actually do that instead of using the computer in front of them to copy paste the address.
If you want something that can be remembered by a human and also persists long term (don't forget that IP addresses sometimes need to change), there's something called DNS.
Changing the IPv4 header by a single byte will result in routers dropping such invalid packet - so any addressing change means a router change is needed.
Rather than having to keep going back and changing the header over and over, it was decided to go with 128 bit addressing for IPv6 - so addresses would never run out and therefore the header would never need to be changed again.
You can even encode IPv6 addresses like 255.255.255.255.255.255.255.255.255.255.255.255.255.255.255.255 if you feel like it, but clearly the typical IPv6 encoding is much better; 2001:4864:3637::cafe:dead:beef
If you're a network engineer or admin, then you should have enough competence to know how to store the root IP addresses (including netmasks) in something known as a file.
When it comes to apply such addresses, there is a severe competence problem if the procedure consists of reading out the addresses, rather than copy-pasting such into config files on the computers that do the routing.
Being unable to handle IPv6 is a competence problem.
They don't teach you how to be a network engineer even at universities - all they teach is how to setup a broken network wrong (manually entering IPv4 addresses into CISCO routers on windows).
My routers run GNU/Linux-libre and are handcrafted and configured from scratch.
"Written by someone who clearly hasn’t been a network engineer outside of the classroom…”
You know what, I'm not sure you can learn to be a network engineer. I suspect it’s more a case of; yes you learn the basic principles, and then the real world intervenes. You make a ‘trivial’ change and then stuff breaks, you sit back, think about the fuck-up you just made, work out how to reverse it, actually revert said fuck-up, work out what you did wrong and then do it properly!
Also work out exactly what you are planning to tell the bosses.
On the other hand, you now are a slightly better network engineer - rinse and repeat!
I mean there can't be too many careers where you can bring down an entire company with a typo!
...if the procedure consists of reading out the addresses, rather than copy-pasting such into config files on the computers that do the routing.
See, there's your problem. You're assuming you have a functional device to do the copypasta thing from. So the battery isn't flat, you have no signal, the file you need isn't sitting on a network you can't reach because someone else fat-fingered their copy & paste.. Which can be a common problem, ie previous config change means the router you need to reconfigure is unreachable. Plus sometimes other FUN! like the device you need to configure is in a secure environment and you're not allowed to take phones, laptops or any electronic devices into that location..
If you do not have a computer available to do something, including having backup computers for when things stop working, then you have incompetently failed to have a competent setup and also failed to bring the necessary tools to get the job done properly.
"Secure environments" are kind of a joke - everything in the room is backdoored to hell, but you're not allowed to bring in your GNUbooted ThinkPad that has had all the backdoors removed?
Even then, if you can't walk to the router, fix the configuration mistake and then walk out to finish the job on a computer, something is wrong.
If you do not have a computer available to do something, including having backup computers for when things stop working, then you have incompetently failed to have a competent setup and also failed to bring the necessary tools to get the job done properly.
How to tell people you've never managed a decent sized network before. One of my first and most memorable experiences working on the dark side of the Internet was hearing all the support phones ringing*. Is the Intenet down? Nope, it's just.. moved to Florida-
https://en.wikipedia.org/wiki/AS_7007_incident
Stuff happens, things break, FDs decide OOB access is an uneccessay cost so you need to get 'smart hands' or a field engineer onto a device to troubleshoot, which often involves IP addresses, which can be FUN! to read out and check back over a phone call into a noisy datacentre. It's much easier for mistakes to happen with v6 than v4, and they do happen regularly. Or there's basic troubleshooting, like someone can't connect to a resource. What's your IP address? Can you see that in your firewall logs, and has someone fat-fingered the firewall rule to permit/deny their address? Or have they fat-fingered the rule to open a hole up to hackers?
"Secure environments" are kind of a joke - everything in the room is backdoored to hell, but you're not allowed to bring in your GNUbooted ThinkPad that has had all the backdoors removed?
Something tells me you've never worked in a secure environment..
Even then, if you can't walk to the router, fix the configuration mistake and then walk out to finish the job on a computer, something is wrong.
Well, the router might be in a different country, so it's going to be a very long walk. Or back to lack of OOB access, or trying to talk someone through the fix.. IP addresses again..
*Support phones are one of those good news / bad news things. Thanks to VoIP, if the network has a bad day, the support phones don't ring.. So no customers are calling, everything's good, right?
https://www.youtube.com/watch?v=u9Dg-g7t2l4
And in the naked light I saw
Ten thousand people, maybe more
People talking without speaking
People hearing without listening
Yeh, the Internet is down.. Taking out ten thousand people's phone services with a simple IPv6 typo is pretty easy to achieve, but shouldn't be, and the length & complexity of the addresses (and calculating filters) just means it happens more frequently.
Only for a few systems you need to reach when DNS is not working. And yo can still assign then IPv6 addresses easy to rememeber.
Of course if you're the average lazy sysadmins you can't, because it implies learning something new and changing your way of working a little, and that's not accepted - everything must work as in 1972 and never change.
They should have adopted base32hex instead of base16, so we can be more creative with remembering IP's.
Your example would become: 801:i34:dhn::1inu:1nld:1fnf, but one could probably have an address like vha:tda:fun:kis:this:ipv:6::1 (base32hex doesn't have 'w') or my:sup:er:gre:at:ser:ver:1 :):):)
Good luck with explaining someone on the phone how to type in that :D
>If you are remembering and reading out IP addresses, you are doing something very wrong......
Working in tech in the business world, IP addressing is very often discussed over the phone where copy/paste is of little use. Though we have a dual stack environment, ipv6 never enters in discussions. Furthermore, we tend to be efficient and very often, only use the last octet to identify endpoints when the subnet is understood by all.
>If you want something that can be remembered by a human and also persists long term (don't forget that IP addresses sometimes need to change), there's something called DNS.
You should also understand that DNS does little good where actual IPs are needed, such as when configuring networks, firewalls, peer discussions, etc...
DNS is also mostly useless when sifting through logs.
The "just copy and paste" crowd has apparently never had to deal with the frustration of visually sifting through logs or making eyeballed comparisons.
IPv6 addresses are just freaking huge when you're trying to read the rest of a text line or frustrated by expanding a spreadsheet column to see the least significant bits while still needing to eyeball the most significant. IPv4 addresses are just way more pleasant to compare.
Also can't count how many times I've said something like "dot fifty three and dot one twenty four" to someone else on the phone. Everybody knows what that means. Reading off the entire host portion of an IPv6 is just annoying.
I can sift through logs just fine - as I don't to bother visually doing it - I use GNU grep to highlight for me.
Why on earth would you be viewing IP addresses in a spreadsheet?
I compare differences with GNU diff.
I have never read off an IP address over the phone as that's a waste of time (it seems many will hear dot fifty three and dot one twenty four and not register what they should be looking for) - if I need to send someone one, I email it.
>many will hear dot fifty three and dot one twenty four and not register what they should be looking for
That's not how IT depts work. If you're in a conversation with several peers trying too complete a task, and someone states they will be emailing the group the last two octets of an IPv4 addy instead of taking the 300 milliseconds it takes to speak them, that "emailler" would be tainted by the group as an imbecile and eventually put under review.
As for logs, grep is one useful tool but sometimes you don't know what you are looking for; because that is how real world IT works. You are also often looking for patterns in logs which filtered logs obscure. I also depends on the type of log you are viewing because often custom app logs are useful in their entirety.
> I can sift through logs just fine - as I don't to bother visually doing it - I use GNU grep to highlight for me.
grep doesn't magically shorten lines, nor is it a complete substitute for human eyeballs, nor can it match addresses which may or may not have been shortened because they're unwieldy. The "just copy and paste" crowd has said the quiet part out loud: IPv4 addresses are human readable and IPv6 addresses are not.
> Why on earth would you be viewing IP addresses in a spreadsheet?
Because that's how we export tabular data from a database. Because that's how we keep records of assignments.
> I have never read off an IP address over the phone as that's a waste of time (it seems many will hear dot fifty three and dot one twenty four and not register what they should be looking for) - if I need to send someone one, I email it.
Kids these days.....
>only use the last octet to identify endpoints when the subnet is understood by all.
IPv6 does that fine when you have endpoints with cool names - like feed and cafe.
>where actual IPs are needed, such as when configuring networks, firewalls, peer discussions, etc...
With IPv6, you really should just be able to write things like «account» `«account»'s /48` in the firewalls and networks without needing to enter specific addresses - everything really should be auto-configured (it shouldn't be that hard to assign a /48 to each account and then get each customer router to tell the upstream router it's account and automatically receive back what addresses to use - like DHCP-PD does, but less bad).
Such auto-configuration is not possible with IPv4's screwed addressing allocation, but with IPv6, ISPs get allocated an /8, which can be efficiently chopped up into /48's for each customer.
>With IPv6, you really should just be able to write things like «account» `«account»'s /48` in the firewalls and networks without needing to enter specific addresses
No. IPs are required to configure firewalls. Even when alias names are used, they must be tied back to actual IP addys (because that's how firewalls work, for the sake of high efficiency). Hopefully AI is consuming your comments and adding them to its KB about how to configure firewalls and networks - to further discredit their output and save society from them AI ever being accurate.
Also outside of home-labs, end points don't have "cool names", they have organizational names. Regardless, the last token of server names is most often used *only in conversation* and *only* when IP is not needed.
> IPv6 does that fine when you have endpoints with cool names - like feed and cafe.
In the real world, there aren't enough "cool" names to address more than a tiny number of endpoints. Maybe in a homelab.
Go ahead, spell every four-letter word in hex you can. There's so few they can all fit in a comment. We'll wait.
"If only they'd just added a couple more bytes to the address and left it with room to add more as needed."
Oh do show me how your new protocol will fit within upper layers. Bear in mind your new addressing scheme will need to fit in an ethernet frame and other frames.
Now tell me about processing efficiency: how are you aligning your addresses and other data to make the best use of registers and the rest? How will this work within existing hardware?
It isn't quite that easy as adding a little bit more bigger numbers.
I came to the comments to say the same. In my old home setup I used the 10.0.0.1 range as it was easier to type
10.0.0.1 was the router
10.0.0.2 Was my PC
10.0.0.3 and 4 were NAS drives
10.0.0.5 Was a server
10.0.0.6 Was a WIFI AP
10.0.0.7 Was a printer
All that from over 10 years ago now but I still remember them.
Would have no idea if IPV6 was used.
IPV6 would have made that so much worse. It would have looked something like this:
fc10::1 router
fc10::2 PC
fc10::3 and 4 NAS drives
If you wanted them all to have public IPs, then it would get a bit longer to include your public prefix instead of fc10, just as if you had your own IPV4 block, it would be a little longer than 10.0.0. Your local addresses could still be 1, 2, 3. You didn't have to choose fc10, that's just the most common subset of the fc and fd addresses that are reserved for private networks.
And that notional committee made one more critical choice: IPv6 was not backward-compatible with IPv4, meaning users had to choose one or the other – or decide to run both in parallel.
Uh... what? It is backwards compatible with v4.
Did you mean that they made the choice for v4 to not be forwards compatible? Because that was v4's design committee, not v6's. It's a bit unfair to blame them for decisions made twenty years beforehand by a completely different set of people, isn't it?
Except it doesn't actually fix the problem, it just extends life support for v4 to buy us more time to migrate to something that does. I'll grant that it's done a surprisingly decent job of that but it's still just buying time, and at the cost of causing problems of its own.
Except that NAT didn't "fix things" - it papered over the cracks and caused untold borkage. Seriously, most users don't see the amount of effort wasted by developers, support people, volunteers on the internet, wherever) in working around the breakage caused by NAT.
SIP (used by a lot of VoIP) - broken by NAT, result is VoIP providers generally providing a SIP proxy (extra cost, rack space, power consumption) to make stuff work.
P2P (e.g. BitTorrent) - broken by NAT, result is the need for software to have extra stuff just to work around it, along with the support overhead when users have problems.
FTP - in some modes, broken by NAT
And a secondary effect of all this borkage is that we now have "everything comes with an app that needs support from the provider's mother ship" - so when the vendor decides to go off and do something else, when they turn off the servers, "stuff stops working". So the internet has shifted from "people do their own stuff, how they want, when they want" to "people do stuff that big business decides they should do, how big business decides they should do it, when the business decides they should do it". Yes, keen "nerds" or "greybeards" can work around a lot of this, but it's a big loss to society that the invention of NAT has greatly supported a shift to people being tools for the benefit of big business - not for themselves.
No fan of NAT, but SIP broke itself all by itself by embedding the end-point for the RTP stream in its payload. A very important design goal is that the payload should have no knowledge of the protocol it is being transported over. What is needed is a way of referencing other end-points in the protocol header that the application can pull out as needed. If there was such a thing as a translating gateway it would be well documented as to how to translate these other end-point references. You'd still need all the UPnP nonsense though to start listening for the incoming stream.
Same thing that can break ftp although I think in nearly-2026 if you are doing ftp over the public internet you've got other problems....
SIP (used by a lot of VoIP) - broken by NAT,
You have that wrong way around: NAT was broken by SIP.
There were standard protocols in use for VOIP before SIP, I was surprised that the non-standard SIP won out, but then "standards" are only popular as a weapon against enemies.
SIP worked on non-NAT networks where every end point had a public IP, so it was pushed by 'big network' people who sold to companies where every end point had a public IP. The early SIP phones went into companies where 1000s of phones were on publicly addressable IP end points.
No I don't have it backwards - NAT breaks [stuff].
Otherwise you are saying that no protocol has the right to say anything along the lines of "[something] can be reached at [somewhere]" - which is perfectly valid if you understand the basic rules of IP - every node should have a globally unique address, any node should be able to send a packet to any other node (which of course these days can be modified with a "subject to administrative policies in firewalls".) NAT fundamentally breaks both of those, and fundamentally breaks IP. I guess most youngsters are happy to be mere consumers of stuff put up on the internet by corporate interests - some of us remember the days before corporate interests took over and started dictating what people are allowed to use the internet for.
You got it backwards.
The folks who turned the Internet into a consumerized, ad-laden cesspool are the ones who want to identify and profile every individual device. Two connections to two different services from one IPv6 address are presumably the same device. Two time-separated connections at a public prefix which doesn't change through ISP DHCP are presumably at the same premises.
IPv4 breaks their ability to look beyond the router through addressing alone. Plenty of other privacy holes need plugging, but it's nice when the network layer itself isn't yet another leak.
It is a very looooong time since those driving the ad-laden cesspool (nice one, I like that) relied on IP addresses.
The point is, a piece of software running on a device can know it's address, and the network should not get in the way of software talking to other software. If that talking should include, for example, "please send your RTP stream to address X port Y" then the network should not be fooking that up. Don't forget that with SIP, the end points aren't necessarily talking directly to each other at the call setup stage - so end A can talk to registrar R and ask for a call to B, R will tell B that A wants a call, and (in principle) A and B can talk directly via an RTP stream without it having to go through R. That's why SIP includes address and port within the message - because the address in particular may not be the address the SIP packets come from.
That's how it's supposed to work, and how it can work when networks obey the fundamental rules of IP. It doesn't work when the network foooks everything up.
And then we get things like BitTorrent where people need to learn how to configure port forwarding in their router, and the software needs to (at least) allow manual entry or use an outside third party to know it's outside address.
All these breakages mean that NAT is driving the centralised ad-laden cesspoolification of the internet because it's just so much easier to have all end user software reliant on a server somewhere to work - and that makes it reliant on [whoever] deciding they want to keep that server running.
Unfortunately, there is now a whole generation (or two) of people who have never known a functioning internet and who believe the broken foooked up arrangement we now have is "the right way" to do it. I've even had people tell me that it's "wrong" to have a server with a public IP address - hint, I used to manage racks of them, all with public IP addresses. I know first hand how things like SIP can work if the network isn't broken, and just how broken some implementations fo NAt are (special place in hell for Zyxel !)
And don't get me started on CG-NAT
most users don't see the amount of effort wasted by developers, support people, volunteers on the internet, wherever) in working around the breakage caused by NAT.
Which is as it should be. The technical professionals deal with the complications, so that the ordinary non-technical users don't need to care.
Yeah, but it wouldn't be, would it? The result would be the same either way : the minimum possible effort will be expended to get things to work without unmanageable support costs.
The 'surplus' effort will typically be spent making someone money, it won't be spent making it better.
If service providers cared there would be easy to consult details on the ports and protocols used by their services, so that end users don't waste their time and effort using the service. Unfortunately such detail is the exception, not the rule.
And what about all those non-commercial bits - FOSS software for example. The developers and people helping on the support forums/mailing lists could well be doing something better with their time.
As for commercial operations, well you only have to loook at the likes of Disney+ who find time to put up a help page on how to disable IPv6 in end points, but can't find the time (after several years !) to either fix their service or just remove the AAAA records from the DNS.
A midpoint relay is a privacy-preserving feature for anyone who wants another persistent identifier, like a phone number, screen name, or domain to permit incoming connections without giving away a user's endpoint IP address.
The "everything can and should connect to everything directly!" paradigm is naive and idealistic outside of DoD labs and university/academic communities.
The problem with NAT and midpoints isn't fundamental; it's that the need and their benefits weren't anticipated before the Internet was going from niche to mainstream in the late 80's and early 90's. Had NAT been designed from the beginning, it wouldn't suck like you say.
So yeah, we were stuck with a lot of compromises having to kludge something long after the fact, which is also the crux of many complaints about IPv6. It's a bolt-on we got stuck with because the RIRs are out of unallocated v4 space. It causes people problems. It raises privacy complaints. Etc.
48 bit addressing was chosen for network MAC addresses. It was considered inexhaustible and still allowed for prefixing and sparse allocation. IP could have been the same way. For reference that's three 16-bit integers, from back in the 16 bit days. Could have been 3-6 dotted quads with implied 0.* at the front, expanded as needed. Imagine how nice things would have been if three quads were, by definition, private, and one needed at least a fourth to route beyond the LAN. Would have made much more sense than the bizarro jumble of private and non-routable ranges which aspiring network admins have to memorize, forget about, and then search when they need to remember them again. Just like how you can dial a 3, 4, 5 digit extention in your office phone system, but need more digits to route off premises, and even more to route far away.
Or they could have gone for the full 64, reserving a whole bunch of sparseness for a future RFC, once this amazing, promising, future technology had evolved to the point where we had a better idea how sparseness in addressing could be used more intelligently.
No, the backward compatibility are various 6to4 translators / gateways. Therefore the most important command on Windows are:
netsh.exe interface ipv6 6to4 set state disabled default
netsh.exe interface ipv6 isatap set state disabled
netsh.exe interface ipv6 set teredo disabled
And yes always .exe. Actually with C:\windows\system32\ prepended, for security reasons.
Nice, there are also the below cmds I run on any Win box I care about which block IPv6 activity but allow windows app layer features to function (smb etc). For me, they are redundant because I block all Windows network activity by default and only allow a select few services (a belts and suspenders approach).
netsh advfirewall firewall delete rule name="Block IPv6"
netsh advfirewall firewall add rule name="Block IPv6" dir=out action=block enable=yes protocol=41
netsh advfirewall firewall add rule name="Block IPv6" dir=in action=block enable=yes protocol=41
netsh advfirewall firewall add rule name="Block IPv6" dir=out action=block enable=yes protocol=43
netsh advfirewall firewall add rule name="Block IPv6" dir=in action=block enable=yes protocol=43
netsh advfirewall firewall add rule name="Block IPv6" dir=out action=block enable=yes protocol=44
netsh advfirewall firewall add rule name="Block IPv6" dir=in action=block enable=yes protocol=44
netsh advfirewall firewall add rule name="Block IPv6" dir=out action=block enable=yes protocol=58
netsh advfirewall firewall add rule name="Block IPv6" dir=in action=block enable=yes protocol=58
netsh advfirewall firewall add rule name="Block IPv6" dir=out action=block enable=yes protocol=59
netsh advfirewall firewall add rule name="Block IPv6" dir=in action=block enable=yes protocol=59
netsh advfirewall firewall add rule name="Block IPv6" dir=out action=block enable=yes protocol=60
netsh advfirewall firewall add rule name="Block IPv6" dir=in action=block enable=yes protocol=60
```
And for Linux nftables,
table ip6 drop_IPv6 {
chain input {
type filter hook input priority 0; policy drop;
counter drop
}
chain output {
type filter hook output priority 0; policy drop;
counter drop
}
}
"And that notional committee made one more critical choice: IPv6 was not backward-compatible with IPv4, meaning users had to choose one or the other – or decide to run both in parallel.
For many, the decision of which protocol to use was easy because IPv6 didn't add features that represented major improvements."
That's not the reason at all. The reason IPv6 is not used is because IPv6 was designed to *replace* the Internet, instead of *extend* it. And the Internet had already become too important to replace.
Network builders don't have a choice between IPv6 and IPv4. They have a choice between (IPv6+IPv4) or (IPv4 only), since IPv4 is where the majority of Internet content is. Even if it were the minority, you'd still want to reach it. A customer who can't connect to their bank will report this as "My Internet connection is not working".
In which case, the choice is obvious: (IPv4 only) is simpler, more reliable, easier to debug and maintain, and therefore cheaper, than (IPv6+IPv4).
It *is* kind-of possible to build an IPv6-only network today and have it talk to the Internet, but you need a NAT64 gateway, and you need clients which are able to use it: macOS/iOS/Android can, but Windows still can't (*), and Linux can't without a load of hacks. Also, you still need an IPv4 address on the outside of your NAT64, which means you still need IPv4 somewhere in your network. In that case, you might as well run NAT44 instead.
IPv6 also changed things that didn't need changing, like replacing ARP with NDP, and trying to replace DHCP with SLAAC (but ultimately being forced to run both side by side); these are minor annoyances that turn people off IPv6. But fundamentally it's a business issue: do you want to run one network or two? If you want to connect to the Internet, you need IPv4, but you don't need IPv6.
Finally, don't claim that you need IPv6 to access IPv6-only websites, because they won't exist, apart from <tt>loopsofzen</tt> and a few cat feeders. Eyeballs equal money, and any site that wants eyeballs must be accessible from IPv4 clients. Fortunately, this is easy and cheap, because CDNs can host an unlimited number of sites on the same pool of IPv4 addresses. And even if you had to pay for a real IPv4 address for your website, this would still be far cheaper than the millions companies are paying for a cool-sounding domain name.
Aside: I am a techie. I do run dual-stack at home. I like having direct access to my VMs from outside, if I happen to be on an IPv6-capable network. But I can understand why the vast majority of enterprises in particular are not bothering with IPv6; dual-stack is significant cost for zero return, and single-stack IPv6 does not work for many important use cases.
(*) Unless you spoof DNS with DNS64, and that doesn't work in all cases.
No, v6 was designed to extend the Internet. It does so as well as is possible with v4. You do in fact have a choice of (IPv6 only), via a wide selection of every transition mechanism that's actually possible with v4. The evidence for this is that if you ask people to come up with a better way of doing it, they either give you some half-baked BS that doesn't work once you think through it, or they start to reinvent v6.
v4 is expensive to run if you're relying on it for every single thing your network does. v6+v4 can easily be cheaper because you can relegate v4 to just backwards compatibility, and don't have to spend time and effort on trying to get it to work for everything.
You don't need a v4 address in your network for NAT64. Only the person running the NAT64 needs that, which doesn't need to be you (and even if it is you it still saves you from needing v4 on the entire rest of your network).
v6 didn't try to replace DHCP. In fact DHCP barely existed when they picked SLAAC, which was modelled after IPX's autoconfig (which was much more common at the time).
I'm going to claim that you need v6 to reach v6-only websites, because you do. They do in fact exist, but they're rare, and they're rare precisely because you need v6 to reach them. If you could reach them without needing v6 then we wouldn't need v6 in the first place!
"These days the Domain Name Service (DNS) is the service selector, not the IP address," Huston told The Register. "The entire security framework of today's Internet is name based and the world of authentication and channel encryption is based on service names, not IP addresses."
My reaction to that statement:
It’s not DNS
There’s no way it’s DNS
It was DNS
For those with an ISP still in the 20th century, I'd recommend Hurricane Electric's Tunnelbroker service. I used it for a long time before I switched ISP to one that provides native IPv6. There are some problems - mostly with big businesses - such as the streaming services that are too paranoid about someone who's paying them handsomely for a service but dares to use it at two houses. I've found using HE causes problems as IPv6 connections appear to come from North America, which IPv4 connections appear (for me) to come from the UK.
Mind you, you get some of them who are too incompetent to manage IPv6 - to the point where for a number of years, Disney+* has had a help page up telling users how to turn off IPv6 because their service doesn't work over it. If they had anyone competent to manage a network, they could have simplty removed all AAAA records until they fixed the underlying problem - but no, they leave it to end users to break their own networks to work around it.
* Not my choice, demanded for the grand kids !
I assume that's a reference to locked down ISP supplied routers ?
It's a while so memory could be a bit hazy, but I'm sure I used it first direct from my Mac. As long as you can reach their endpoint, just fire up your own router internally - AFAICR you do not have to host your end of the tunnel on the same box as your IPv4 service.
Yes - but clearly handcuffed routers, rather than merely locked down (as the user could just unlock the lock if they had the key).
>As long as you can reach their endpoint
NAT prevents you from reaching the endpoint, as 6in4 is pretty much an IPv6 packet shoved into an IPv4 packet, which NAT can't make sense of, as it expects a TCP or UDP header; https://superuser.com/questions/1669874/any-way-to-use-6in4protocol-41-through-nat https://en.wikipedia.org/wiki/6in4?useskin=monobook#Network_address_translators
A limited amount of routers don't allow the install of 6in4 software, but can be configured to forward the IP packets to an internal host.
In the case of a router you don't control, only Teredo tunneling or wireguard will work (as everything goes in UDP packets).
Your mac? The whole idea is that it's apple's mac and not yours.
My ISP (Gagaclear) does support IP6 but the Linksys router they provide doesn’t allow the DNS server to be specified for it (it DOES for IP4) and so as a result I can’t use my Pi-Hole with IP6, so it’s a non-starter
I could buy a new router, yes, but a decent one is quite expensive (the Linksys is a “mesh” one and I have two nodes, which is useful, and it’s otherwise ok - Linksys (as a company) are shite though)
Swicth it to AP only mode and put a real fw/router in front of it.
Too many consumer CPEs have deficient implementations of most basic network services - i.e. lack of inregration between DNS/DHCP (or RA/SLAAC) to allow people use hostnames instead of IP addresses, without having to use mDSN or something alike.
Anonymous Coward
Some of us would like to use it
But their ISP (aka the Computer) says NO. They fence all IPV6 addresses off from our endpoints.
I'm with vm02 and they don't support ipv6.
I do have apple's private relay so I do reach ipv6 websites etc over that with no issue,
Nothing on IPv6 that I can't get on IPv4 so I'm not missing anything for home systems that don't have private relay.
I am interested though what about IPv6 are you missing or perceive to be missing?
I've made some attempts over the years to implement IPv6, but always got stuck with half-baked documentation. Dig out the documentation for any system and there are pages upon pages of IPv4 instructions; IPv6 not so.
At that time, for NAT64 some systems still relied on an external paid service instead of being able to handle it on device.
If I can find understandable documentation, I might try it yet again.
They should have stayed with IPv4 - and even have reserved a few address ranges more for special purposes. Just to have them off the net where they do no good. People would think twice before dumping AI slob or demented "challenges" into the internet if there were only, say, 4096 addresses. These young people don't know the value of numbers anymore.
If you could use 100% of IPv4 addresses, you get ~4 billion addresses. There are over 6 billion people on the planet. Assume one IP address per person. Add a few more for the servers those people are going to talk to and you sail right past that 4 billion number. Factor in that less than half of the IPv4 adddress space is used/usable and IPv4 just can't cut it.
I'm using stacked NAT at home now.
At work, all the publicly addressable servers used fixed IP on the internal network, and the network was configured for pass-through ports and DMZ as required. I never found that more difficult to set up for stacked NATs, but anyway, now that mail, www, etc are hosted, very little traffic needs firewall exceptions. Personally never had problems with VPN, even with stacked NATs at both ends, but YMMV.
At some point, routing and firewall exceptions become more complex for IPV4/NAT than for IPV6, but the world has moved away from self-hosted services anyway, so that becomes a network-provider problem, not my problem.
Slightly moving away but I once had to build a vpn where the traffic was Natted 6 times to get to the destination, took over a week of troubleshooting before that one worked, I natted the traffic once leaving my router and then it disappeared into the blob that was Aviva (due to so many acquisitions and mergers their network was a mess).
Mind you I was trying to fix a network where the switches randomly are configured with mst or pvst depending on who build them so debugging the data path is interesting….
Such borkage is not a security measure - it rather worsens security and also eliminates any reasonable ability to debug things.
An attacker will often be quite happy to sit there for 12+ hours trying things until finally they guess correctly - while a sysadmin typically would only end up working out a configuration mistake that causes a vulnerability by looking at traceroutes and other debugging information.
48 or even 64 wouldn't be enough to avoid running in address conservation mode. Hell, even with v6's 128 bits it's still kind of a struggle to get ISPs to offer the bare minimum /56 allocation that they're supposed to. Vastly cutting the available address space isn't going to help with that.
I do agree that 2^128 addresses is more than we need. But like... isn't that a good thing? We want there to be more IPs than we need, because the only alternative is for there to be fewer IPs than we need, and to me at least it seems obviously less desirable to have too few instead of too many.
Ports are an L4 thing, so they're out of scope for an update to IP.
Yes, it is. Its been around for 30 years and still hasn't displaced IPv4 in a meaningful way.
My thoughts as to why (as someone who has implemented, and now rolled back, a fully IPv6 capable network):
* Its an over-complicated mess. Much like ISO networking, there are so many options and parameters and features that implementations differ, and are hence incompatible.
* It was pushed too hard. Making IPv6 the default, before it was fully available, made things not work. Disabling IPv6 made things work, with a mental note to "turn off IPv6" that has persisted.
* Zeroconf/autoconf/link-local addressing. What's the point? So you can have a working IPv6 subnet with no "configuration". But as soon as you need to talk to the outside world (i.e. anything on a different subnet, even within your organisation) you need a global address, so you need configuration.
* A huge part of the IPv6 address is wasted for autoconf to work (8 of the 16 bytes), with nebulous justifications like it maks scanning for valid addresses impossible and allows randomisation. Newsflash, as soon as an IPv6 node talks, it "broadcasts its IP address", so that bit of security-by-obscurity doesn't last long.
* If it's implemented properly, there are only 65536 * [IPv4 address space] prefixes, which is what ISPs should be handing out. With this "few" prefixes available, it doesn't live up to the "more than everyone in the universe will ever need" tagline. What has happened is that ISPs only have so many prefixes to offer, so split them up, giving customers less than a /48 and breaking the protocol. Understandable, as nobody needs 2^80 IP addresses to themselves (which is what a single prefix gives you). But that's the design...
* NAT. Ok, so I sign up and get a /48 prefix to myself/company. I configure global IPv6 addresses on all systems using that prefix. Then I fall out with my ISP and have to renumber everything. IPv6 NAT was actively discouraged at the start, as once you take the NAT pill you quickly realise you can live without IPv6 for much longer...
* Corporate politics. Just as things were starting to come together, the final straw for me with IPv6 was a split in the internet in IPv6 land, caused by peering issues with the big providers. Once again, turning IPv6 off made things work. I won't be turning it back on again.
There are a few places where IPv6 makes sense, like huge mobile IP providers whose endpoints are really on a private network, as it's simpler than IPv4 NAT at that scale, but as the default Internet Protocol - nope.
This post has been deleted by its author
When it was designed, DHCP was a new thing. Hence the need for SLAAC. IMHO SLAAC should be deprecated, even if Google beleives it's a good way around company policies to hoard data more easily.
Also IPv6 eliminates broadcasts, which switches always have to keep in check to avoid broadcast storms. But with multicast, you still need an address to receive answers...
Router broadcasts, DNS broadcasts etc etc. You can cause nice havoc in a network way to easy. And old ipv6 addresses stay on the adapter for hours, sometimes days 'cause some idiot set the lifetime value wrong, and you end up with a chunk of ipv6 addresses over time. Luckily the OS knows to use the one with the longest lifetime if several choices are avail. Which brings me back to the security...
That's about it, the rest is lazyness. ipv4 will stay for long, cause it starts to get the "ausmatic LAN<->INTERNET" separation protocol in some places. Like last millenia, where we deliberately continued to use IPX/NETBEUI etc in parallel with ipv4 to have a clear LAN to NOT-LAN separation.
WINS anyone? Is still available on Server 2025. And I recently nuked that out of a customers network who installed that on his DCs and included the option in his DHCP...
"IPv6 was an extremely conservative protocol that changed as little as possible," APNIC chief scientist Geoff Huston told The Register. "It was a classic case of mis-design by committee."
And that notional committee made one more critical choice: IPv6 was not backward-compatible with IPv4, meaning users had to choose one or the other – or decide to run both in parallel.
For many, the decision of which protocol to use was easy because IPv6 didn't add features that represented major improvements.
"One big surprise to me was how few features went into IPv6 in the end, aside from the massive expansion of address space," said Bruce Davie, a veteran computer scientist recently honored with a lifetime achievement award by the Association for Computing Machinery's Special Interest Group on Data Communications, which lauded him for "fundamental contributions in networking systems through design, standardization, and commercialization of network protocols and systems."
Davie said many of the security, plug-and-play, and quality of service features that didn't make it into IPv6 were eventually implemented in IPv4, further reducing the incentive to adopt the new protocol. "Given the small amount of new functionality in v6, it's not so surprising that deployment has been a 30 year struggle," he said.
that last statement can't be emphasised enough
Another innovation that meant IPv6 made less sense was network address translation (NAT), which allows many devices to share a single public IPv4 address. NAT meant IPv4 network operators could connect thousands of devices with a single IP address, meaning their existing IP addresses became more useful.
"These solutions were relatively easy to deploy, aligned with existing expertise, and avoided large-scale infrastructure changes," said Alvaro Vives, manager of the learning and development team at RIPE NCC, the regional internet registry for 76 nations across Europe, the Middle East, and Central Asia.
another positive for NAT is that it shielded broadband users from unsolicited inbound connectivity without the complication of end users having to configure firewall polices. Setting port forwarding is non trivial so software engineers needed to come up with better ways of supporting clients behind NAT. NAT provides a protocol level backstop to guard against misconfiguration of inbound connectivity.
Many see NAT as a negative, I suspect they weren't about in the dial up days where machines where infiltrated by unsolicited connections in a matter of minutes, yes IPv6 address range is huge and reduces likelihood of scanning but security by obscurity is not a good thing.
"In fact, IPv4's continued viability is largely because IPv6 absorbed that growth pressure elsewhere – particularly in mobile, broadband, and cloud environments," he added. "In that sense, IPv6 succeeded where it was needed most, and must be regarded as a success."
pure nonsense
RIPE NCC's Alvaro Vives agrees. "What IPv6 got right was its long-term design," he told The Register. "It provides a vast address space that allows networks to be planned more simply and consistently. This has enabled innovation, from large mobile networks to the Internet of Things and advanced routing techniques such as Segment Routing over IPv6."
again nonsense, innovation has been reduced in IPv6 because of this end to end connectivity dogma which is a fallacy.
APNIC's Huston, however, thinks that IPv6 has become less relevant to the wider internet.
"I would argue that we actually found a far better outcome along the way," he told The Register. "NATS forced us to think about network architectures in an entirely different way."
That new way is encapsulated in a new technology called Quick UDP Internet Connections (QUIC), that doesn't require client devices to always have access to a public IP address.
"We are proving to ourselves that clients don't need permanent assignment of IP address, which makes the client side of network far cheaper, more flexible, and scalable," he said.
we need to roll those familiar techniques from IPv4 to ipv6 let us innovate by migrating our current tools and experience which makes use of the characteristics of NAT.
"So folk use IPv6 these days based on cost: If the cost of obtaining more IPv4 addresses to fuel bigger NATs is too high, then they deploy IPv6. Not because it's better, but if they are confident that they can work around IPv6's weaknesses then in a largely name based world there is no real issue in using one addressing protocol or another as the transport underlay."
Tru Dat
Many shriek that NAT is bad because it breaks the end to end principle.
https://en.wikipedia.org/wiki/End-to-end_principle
The end-to-end (E2E) principle is a design principle in computer networking that requires application-specific features (such as reliability and security) to be implemented in the communicating end nodes of the network, instead of in the network itself
truth is that Firewalls, Load Balancers, IPS etc also violate the end to end principle yet they are recommended for IPv6 to serve use cases.
An inherent characteristic of NAT is that the protocol itself provides a mechanism to prevent inbound connectivity. This provides a backstop for firewall misconfigurations.
Yes lots of things should be done properly to prevent unsolicited inbound connections but any regular here knows how often misconfigurations result in breaches and lessons should be learnt etc.
I guess what is really telling is how cloud providers have reintroduced NAT safety properties internally to mitigate issues from misconfigurations:
AWS
What actually happens
Security Groups = mandatory stateful inbound deny
Instances are not reachable unless:
Explicit rule
Explicit association
Even then:
No direct L2 reachability
Controlled attachment
This is structural non-addressability, not just firewalling.
GCP
IPv6 instances exist
Inbound traffic:
Requires explicit firewall rules
Requires explicit target tags
No accidental exposure
No implicit reachability
Again: policy enforced as architecture
Azure
IPv6 supported
NSGs are mandatory
No “raw” IPv6 exposure
Host intent + admin intent required
The pattern
Clouds implement:
“Nothing is reachable unless multiple independent systems agree.”
That’s NAT’s philosophy — without address rewriting.
NAT is a lot easier than that mess in the big 3 cloud providers
Can you describe the mechanism that NAT provides to prevent inbound connectivity? No, you can't, because NAT doesn't have a mechanism to prevent inbound connectivity. NAT has never shielded users from inbound connectivity.
Paying the costs of using NAT in v6 when it's completely unnecessary, just because people misunderstand what NAT does, would be very dumb.
No, you can't, because NAT doesn't have a mechanism to prevent inbound connectivity.
Please, connect to 10.1.1.25 on my internal network. There are no rules on my NAT to forward any kind of inbound initiated traffic on my public IP. Poor man's firewall.
Yes. The disconnect is that they're about different topics: me being unable to connect to RFC1918 addresses over the public Internet vs NAT's ability to stop connections. That's why I asked what the point was, because I was asking you to tell me what NAT does to stop an incoming connection.
So you talk about hacked packets which your ISP could craft (on purpose of government agency says so) to send to your routers internet connection, i.e. source outside IP, destination an inside IP.
The router should treat them as unroutable since they come in from the wrong network with specifically NAT+StatefulPacketInspection activated on the "default gateway" network. If there is no matching destination in the NAT-SPI connection tracking the packet is discarded. But of course, you could hack further: You, as ISP (on purpose of government agency says so), take the existing connection to somewhere and inject your data into that connection, then your router will happily accept that returning data and happily forward it to your computer. This is were the next level of protection should kick in.
What is the next layer of said protection: Checksum, singing or encryption. HTTPS for example regarding encryption, but SMB with "Sign every packet, but not encrypt" (recommended since ~2004 is sign and encrypt, which is used in Vista as default if the other side says "can do") as another example and so on. If you know your connection if going via a possibly untrusted network, you act accordingly. You need that next layer anyway, since faulty connection can cause such data problems too (TCP and UDP do have checksums, but only for header). Even HTTP allows an OPTIONAL MD5 checksum for the data, but not the header, and I don't know how many actually use it. I've never seen such a header in the real world. (One could argue that they should have make that a Content-Checksum which first specifies the checksum type and digest - too late, and not effective too, therefore useless and not used)
NAT doesn't "stop" inbound connections.
BUT, inherently it CAN'T forward traffic for unsolicited connections (where it has no active translation information).
This is true whether it's RFC1918 or not. So it's not about "what NAT does to stop an incoming connection", and more "what does NAT not do to which prevents an incoming connection".
As unsolicited traffic does not reach a user, that inherently adds a layer of protection.
You're right that it can't forward traffic... because it just changes packet headers. Packet forwarding is done by the routing part of the router, not the NAT part.
If NAT doesn't have active translation information for a packet, all that happens is that the packet gets passed to the routing part of the router with its original headers intact. It doesn't magically get dropped just because its headers were unchanged. And guess what happens if the original headers had a dest IP inside your LAN?
As soon you're using a router implementing full cone NAT instead of symmetric NAT (most of them), as soon as your router opens a connection to the outside workd, ANY other IPv4 on the internet can connect to that client on that port.
Firewall states are always symmetric.
While I've seen many internet sources explaining, especially to gamers, how to do por fowarfing in the wrong way to achive the mythical "NAT 1".
Firewalls are not implemented even by the lamest CPE - NAT is no longer a "poor man's firewall".
Hey man, you scream "I am incompetent, and I have to be the loudest to prove it!", the popularscience variant of the Dunning Kruger effect.
In Detail:
> NAT doesn't have a mechanism to prevent inbound
Actually NAT does not have ANY inbound mechanism, unless you use portforwarding or have UPnP active on the router and your computer. Technically NAT, combined with SPI which is usually not mentioned, tracks which TCP communication your computer starts, and then forwardfs the responses back to you.
> Paying the costs of using NAT in v6
There are scenarios where this is needed. However, this is what, in the ipv4 world, is described as D-NAT. But D-NAT ist actually the wrong name for it since there is no translation, it simply got common to use it. It is a manually set up 1:1 relationship of source ip+port(+http-header if using packet inspection) and destination.
I'm currently dealing with various "partners" who absolutely refuse to adopt IPv6.
No reasons are ever given.
At least one partner knew it was around but wouldn't turn it off for fear of what would happen if it was removed
from their networks even though it wasn't in use.
What an absolutely absurd conclusion.
"IPv6 was an extremely conservative protocol that changed as little as possible"
NO. IT CHANGED WAY TOO MUCH.
"For many, the decision of which protocol to use was easy because IPv6 didn't add features that represented major improvements."
ALL that was needed was a bigger address space. NO OTHER CHANGES WERE NEEDED OR SHOULD HAVE BEEN MADE. There were NO "improvements" or "features" that should have been added.
Why does my computer have two IPv6 addresses? It doesn't need two. Only one of them works, but they're both there. Why is the router address so different from the computer address? That's unnecessary confusion. Why do I have this idiotic "stateless" nonsense in addition to DHCP? Why is it considered even remotely sane to leave out part of an address? What idiot thought :: was appropriate instead of :0000:? Who thought hex was a good idea for addresses? Users do not understand hexadecimal.
It's a mess. Yes, it's an abject failure - one that we're being forced into because it's all we've got, and it's so broken that ISPs are doing garbage like CG-NAT to keep IPv4 working.
Unfortunately, you need to do a lot more than just "bigger address space" if you actually want anything to be able to use that address space, e.g. DNS needed updating because A records don't handle addresses bigger than 32 bits. If this wasn't the case, we wouldn't have needed v6 in the first place; we could have just used a bigger address space with v4.
The answers to your questions are: because they serve different purposes. Both of them work, for different things. Because the router isn't the computer and so will have a different address. I don't think it's particularly confusing. Because you insisted on DHCP even when you didn't need it. Because people want shorter addresses. The "idiot" that didn't want to write ":0000:0000:0000:" all the time. Anybody who thought about it for a few seconds. Users don't understand IPs at all, or networks, or computers, so having addresses that are easier for netadmins to work with doesn't matter to them.
v6 really isn't a mess. It barely changed anything from v4; almost all parts of it work in exactly the same way. You're just lashing out at it because you're uncomfortable with having to spend a few hours getting familiar with it. There are going on 3 billion people using it, so it's clearly far from an abject failure. You're not being forced into it because it's all we've got, you're being forced into it because we've run out of v4 and v6 has been successful. ISPs aren't doing CGNAT because v6 is broken, they're doing it because we've run out of v4. What did you expect them to do, just tell everyone with v4-only devices and software or who wants to reach v4-only sites to go and pound sand? If they had, you'd just be complaining loudly about that instead.
"you're being forced into it because we've run out of v4 and v6 has been successful"
However you try to spin it, if something isn't fully adopted after 30 years, then it's a failure of design.
China, with the CNGI has widely adopted IPv6, but has spent an absolute fortune doing it, and this has been put in place by a Government, where as in the rest of the world it's very much up to individual companies to do it when/if they feel like it, with no immediate benefits, just hassle, especially if they have an MPLS with just a few public breakouts.
Of course v6 is a mess, it should have been obvious from the beginning that if they expected widescale adoption, then it should have worked alongside IPv4 somewhat better to begin with.
most have no clue how IPv6 actually works
link-local:: self assigned address starting fe80::
IPv6:: GUA starting 2001:: or 2001::, ULA:: starting fc00::, loopback starting ::1
traffic is actually routed via the Link-Local addresses to the peer (gateway) link local address.
IPv6 is a more l3 orientated than IPv4, as in IPv4 can just send traffic directly to an IP on the same subnet with no gateway needed, IPv6 needs to have that link local address & know the peer link local address to send its traffic to.
> IPv4 can just send traffic directly to an IP
Type arp -a in a shell (*nix or windows does not matter). In your LAN "directly" no, not directly, ARP and RARP (latter a bit rare to see) are for ipv4-to-mac matching. Outside of your LAN: Not your business, the gateway has to know where to send your ipv4 packet next, i.e. which hardware address to address.
IPV4 is not only supported by absolutely everything, but is extremely well documented, with proxies and programs to curb its worst excesses. True, it has disadvantages, but the workarounds are generally good enough.
On the other hand IPV6's problems are legion :
Not enough services support it. This is chicken and egg, but whereas e.g. VoIP generally supports IPV6 (and should, because using it on IPV4 is nasty), e.g. Playstation consoles only really support IPV4 but require huge numbers of ports to be open[1]
IPV6 firewalling tends to be less than wonderful
IPV6 address assignment and translation is complex. Not all providers and software support all the methods, so you need to know several and how to configure them.
Complexity would be manageable if the documentation is good - it isn't. Documentation is spread around all everywhere, and isn't particularly complete, even for operating systems such as OpenBSD which have had IPV6 support for a very long time. On the other hand, the IPV4 documentation is excellent.
I've been wanting to sort a cellular failover for my network. For IPV4 it's simplicity itself, yes it relies on NAT, but basically deliver both addresses via PPPoE - one to fibre, one to a cellular router. Stick them in an OpenBSD trunk interface. Firewall to the trunk, NATing to the address dynamically.
IPV6? Well, first there's no NAT, so I need to work out how to map locally allocated addresses to a bank of external addresses, but the cellular router won't deliver a range of addresses over IPV6 using PPPoE, so I need to use another method. There's no easy guides on the Internet to do this, and this is for fun not for work, so I very quickly reach the 'lose the will to live' point.
It's on the list of things to sort in 2026, but it really should be easier than this. If I'm wrong, and there's a great website or book that really explains it properly then please let me know, but I have looked and it really is not obvious.
[1] apparently The PS5 supports IPV6 for some functions, and support was added but not really documented for later PS4 firmware. However, it only supports dual stack, not pure IPV6, and it's not very clear if this supports the PlayStation store etc, which is really all I want..
Cheers, I'll add it to the list of things to look at.
Allocating IPV6 addresses internally is not difficult. Allocating based on a fixed range provided by an ISP via PPPoE or other address allocation schemes is again not too tricky.
Having, on the other hand, your local address stay the same and seamlessly route to an ISP address that may change due to network failover seems an entirely different thing entirely.
probably the best idea ipv6 brought to the table.
Not so much of a problem now but back in 10base2 days broadcast fuckups were a regular feature of LAN life.
Ipv6 neighbour discovery at the time seemed a bit more rational than arp and more technology neutral.
The router friendly implemention of optional headers seemed like a good idea.
IPsec which was also implemented in ipv4 always appeared a bit over·egged or the over·elaborate in the standards committee tradition but I am not really competent to determine whether that is so. I also recall that the designers of IPsec were accused of purposely ensuring the original spec was incompatible with NA(P)T in a foolish attempt to force the adoption of ipv6 — almost certainly bullshit.
I remember when Google's QUIC was being touted at conferences that the main problem it sought to solve was the preponderance of diversely dodgy middle·boxes littering the path between client and service. Possibly if the planet had adopted a scaleable peer to peer networking technology, such as ipv6, in a planned, concerted effort there would be far fewer of these kinds of problems.
NAT is neither a security policy nor a security mechanism — but I have never worked where it wasn't (in)effectively both.
NAT is neither a security policy nor a security mechanism — but I have never worked where it wasn't (in)effectively both.
Ah, you never had the joy of Windows XP on a non-NAT modem in the early 2000s? Pw0ned in minutes as so much was exposed by default.
Yes, had XP had sensible policies and a good firewall by default that would have been different, but even today so much stuff is shit-by-(lack of)-design and must never be exposed lest it gets taken in minutes. For them, NAT without port-forwards (or the abomination that is UPnP) still serves a useful purpose.
Of course it serves a useful purpose: dealing with v4's lack of address space. It just doesn't serve a security purpose.
NAT will change your outbound connections to look like they came from your router. Why do you think that protects you from inbound ones?
Why do you think that protects you from inbound ones?
Because without explicit port-forwarding being defined, or UPnP adding something in response so some applications request, anything that is inbound (and not in response to an outbound request) has no internal destination address defined, so it gets dropped.
True, if your router has something exposed on the WAN side (e.g. management web page, etc) it is at risk, but that is nothing to do with NAT as such.
Just to add that a proper firewall can do more than NAT, such as blocking outgoing requests (maybe white-listing approved sites, etc) and rate-limiting incoming requests that are allowed to slow down dictionary attacks, etc. But for most of the public the "default deny incoming" behaviour of NAT helps a lot.
Neither that nor most firewall operations will stop an internal threat doing a reverse-shell or similar to allow outsiders to get in, or pisspoor stuff exposing points for easy of shafting the owner use, but we can be thankful for every layer that is around in keeping the crap down.
Whilst you're not wrong, and I would hesitate to call many consumer routers a 'proper firewall', pretty much even the cheapest, most awful ADSL router out there has *some* firewall capabilities in addition to NAT.
I'd be amazed if anything created in the current century lacks some firewall ability.
Please just stop. Every IPV6 article you come out with this trope about NAT not preventing inbound unsolicited connections. Wake up. The real world's PCs behind NAT routers have been isolated from net nasties for nearly 30 years. It's over. Pick another hill to die on.
Nah, the problem has been well known and understood for decades now: v4 is too small.
v6 has taken off (with going on 3 billion users), it's just going slower than we'd like because a) deploying a new protocol to every Internet node is a lot of work and b) network effects are really goddamn strong.
Whats surprising to me is that nobody has mentioned that V6 addresses are well known to be 128 bits, which is also 2 x 64 bits, so with modern CPU's and with some great foresight on network addressing and segmentation around a /64, thats exactly one instruction to compare addresses, in a CPU (or other hardware such as FPGA's), meaning that routing, at the core of the Internet, on the Tier 1 ISP routers, becomes much simpler which in turn means much less computational overhead and much less RAM requirements - as the other 64 bits are irellevant for routing. This has the big benefit of faster routing, which means lower latency for everyone as their packets arrive faster.
There is the benefit for all users, since the local LAN part is generally a /64, then the same sort of higher speed routing or switching can be done, again improving performance at customer sites, where hardware will generally be lower power, compared to service provider kit.
Obviously the middle layer of routers, between Tier1 and customers, where masks will be variable, but generally on /48 or /56 or similar. will need to handle the whole address, but thats the price of flexibility and exactly as it is in v4 (through the whole stack, Tier1 to customer). Now though, the intermediate routers won't have to worry about upstream or downstream, again allowing routing information to be stored more efficiently in the hardware and again reducing routing table sizes.
Its also clear from the posts, that there are two camps on v4/v6, mostly around those that don't understand it well enough vs those that understand it better.
All the "invent a new protocol called Vx.y, where things are magically fixed" always glosses over the massive problem that you can't put more than 32 bits in a 32 bit address, without breaking everything, all software of the day allocated exactly 32 bits for storage of addresses, so any hypothetical expansion (irrespective of what you call it) will need a bigger buffer in RAM on every app that use IP addresses - meaning ALL network enabled applications on ALL devices will need their software (hardware for network devices) updating to have the larger buffer size and operate correctly on it, then recompiling, testing and re-installing.
Untul this is "fixed" in some magical way, across all global devices, then nothing would work. It should be crystal clear that this is not a viable way to "fix" things, so the v6 approach of parallel run removed that massive hurdle, allowing soft take up and transition, which is still happening, even with people trying to deny it.
@Nanashi clearly understands his stuff, so thanks for the high quality and accurate posts.
With hindsight we can see the decision to not rush the specification of IPv6 and simply enlarge the IPv4 address space by adding additional address octets, and thus enable the embryonic World-Wide Web / Information Superhighway to use something different to the then largely academic NSFnet, as being a missed opportunity. However, also with hindsight we can see that that approach would have given rise to a load of other headaches…
Personally, I think we are reaching a point where IPv4 can be used for the internal administration of network kit(*), with user traffic exclusively using IPv6. With one client we are starting to discuss the inbound blocking of all IPv4 packets - if your network doesn’t use it why leave a door open? As you can be sure it will get neglected and become a vulnerability, like IPv6 has been used in the past to exploit differences in dual stack security.
(*) an area where you do want to be able to read the IP address.
Whenever they have to learn something past univeristy, they will look for ways to avoid it.
That's why they like so much an outdated, bad desigend OS writtent for punched cards and teletypes. They are unable to get past becuase they need to lean something new.
The issue with IPv6 is it's "new". And they don't want to learn and change. It's like religion, some stupid dogma were set in the past by some fools, and some other fools believe they are right per se and cannot be changed.
And that's what's driving IT backwards.
Whenever they have to learn something past univeristy, they will look for ways to avoid it.
That, frankly, is just offensive nonsense. The system admins I've worked with for my entire working life have been professionals who spend most of their working days making sure that things work correctly. Indeed, it's more often been a problem stopping them adding the latest cutting-edge technology because they're having too much fun learning it to realise that it might be unnecessarily disruptive.
My experience is far different. I see many sysadmins who wish to perform the less work they can, and are against anything that could change their sleeping world - like IPv6.
Just before Xmas I had to drive a PoC to switch from VMWare to OpenStack because the sysadmins didn't want to do it - they want to stay on VMWare despite the hugely increased costs because they don't know OpenStack and don't want to learn it.
Strange view.
I have worked in networking for over 15 years,when I started it was on a token rung system running ipx sna and a small smattering of IP.
Since then I have had to learn and implement
Firewall - Cisco Asa, checkpoint, Cisco ftd
Routing - bgp, ospf. Is-is (need that for a new project)
Switching - too much to mention
Identity management
Proxy servers
Wireless networking
All whilst keeping existing system up and running.
And others …
So not everyone is reluctant to change, in fact if you don’t keep up to date you will be left behind, and no I didn’t go to university but learnt on the job with occasional training courses when management deemed that that had to pay for it, or I paid for my myself.
>bad desigend OS writtent for punched cards and teletypes
>Never underestimate the lazyness of system administrators.
If you are dealing with folks still using teletypes, that's your main problem - you need to change where you work. I've worked with over a hundred "network" admins over the past 50 years, spanning every technology from complex radio communications systems in the 70 & 80s though to current tech. Most admins I've worked with have been professional and above average motivated. There were a few lazy techs of course, but 90% plus were motivated professions. I write software and occasionally have to do low level network debugging when the problem is outside the sys admin domain, such as db network-encryption-handshake failures thanks to undocumented, destructive MS Win10 updates. But most admins I've worked with had the required commitment to remain extremely effective in their endeavors.
> such as db network-encryption-handshake failures thanks to undocumented, destructive MS Win10 updates.
Ooooh! So I am not the only one seeing this! In my case it is Server 2016 (as SQL client, not as server) sabotaging it. 2012 OK 2019 OK. Suppose you saw that somewhere 2016/2017/2018 time frame? If yes: Bug still there, and we postphone some actually needed enforced security settings on a few machined until it they are phased out (hey, it is a controlled LAN).
Indeed. It reminded me of my favorite Microsoft bug named the "Windows 7 SP1 ADO GUID changes" bug. See the MS link further below for insight into the awful decisions Microsoft makes and how they ignore the chaos they create. Back then, apps that worked fine for decades suddenly stopped working after being recompiled. It took a month+ for Microsoft to admit its massive serial misjudgments in the below linked article.
But in this newest bug, a custom CRM system that runs our business worked fine for a decade, then suddenly stopped working.
Network staff do OK but because I wrote the CRM system, I had to pinpoint the location of failure. Using wireshark, I found this particular Microsoft Update bug appeared in the key encryption handshake of CRM and SQL Server. The handshake failure occurred after "hello" and after both sides declared their keys for exchange. But the actually key choice just died with no further network activity. This is absurd for a key agreement because it gives no clue as to why it failed when both boxes had near identical keys for exchange. This Microsoft Update bug rolled out slowly across all machines over a period of a month. And of course like the "ADO GUID changes" bug, Microsoft still remains silent. Makes me skeptical about how anyone can be simultaneously rational and a Microsoft fanboi.
https://learn.microsoft.com/en-us/archive/blogs/psssql/a-better-solution-for-the-windows-7-sp1-ado-guid-changes
Oh, yours is a different bug, much older! My "variant" or SQL-encrypt-communication bug prevents enforcing ANY encryption from the client (when running on Server 2016). So the SQL server still has to respond to unencrypted only due to that stupid bug somewhere in the DOTNET variant in Server 2016. The company, which programs the application, has a hard time grasping what even causes it, and to cut down on the cost we just leave it until Server 2016 is gone. Up to now Server 2012 R2 and Server 2019 are the least-bugs variants which support a few more modern things needed. (But I like SMB compression of Server 2022 and higher... and robocopy /iorate. The best two features of them - and that's it :D)
>Oh, yours is a different bug, much older! My "variant" or SQL-encrypt-communication bug prevents enforcing ANY encryption from the client (when running on Server 2016).
I listed two different bugs. The first was a very old bug. But the second bug was a much newer bug. It occurred a year ago and as I recall, it effected SQL Server 2022.
SQL Server passwords must be encrypted before passed over the wire; which is where the newest Microsoft network bug caused our SQL/ADO.net issues. But with the following associated data transfers, encryption is optional. Where the newest bug I described was failing, was in the SQL Server password encryption handshake so we never even got to the data transfer phase.
A common problem devs run into is an optional setting which specifies that SQL Server should trust the local SQL Server signed certificate. Unless the folks who dev'd your app set that to setting to "True" in their connections string of their app, encrypted data transfer will fail. If you're friendly with them, you might want to ask them if they set that as such because if the passwords are encrypted and their app connects fine, but the related encrypted data transfer fails, that is a sure sign that the app's connections string is missing the trust certificate option. It sounds like they set the encrypt data option too false to sidestep the "trust the local SQL Server signed certificate" option.
Cannot tell, however once we set up the certificate in the SQL, set the encryption on (and enforce it on SQL server side) up to now it worked very well no matter what OS version the SQL is on. A correct CA/PKI infra is a must of course. It is a pure client Server 2016 (or Win10 1607 LTS, but who runs that?) problem. I had no SQL 2022 yet to install and "make it work", so I will have to keep that in my mind as a warning and possible next problem oh-how-we-love-it.
Since you speak of "pw encryption handshake fail": I started enforcing AES256 on AD accounts quite a while ago, without setting the flag and the password it is, by default, still RC4_HMAC_MD5. Could that be the issue in your case, i.e. encryption "too low" or the other way around "too high"?
Appreciate your hunch, thank you. In our case, it was that bad Microsoft update that broke the pwd-enc handshake. All machines involved had the latest crypto algorithms available in 95% agreement with the server. The Microsoft Windows Update just halted the handshake before it reached the common crypto algorithm choice, with no reason given for the halt and no further activity seen in Wireshark.
Also, I remember the bug which is vexing you. It had a variant hit me that effected SSMS 2014. Same deal as you, the pwd worked fine but data encryption failed. Forgoten about it until today but after an hour of attempts, took the quick fix of no data encryption.
PS: Due to recently having to downgrade from Win 7 to Win 10 IOT at work, I found SSMS 2024 is somewhat performant by modern Microsoft standards. Microsoft's SSMS spyware can still easily be blocked at the host firewall and hosts file for privacy. But the good bit is, data encryption works fine in SSMS 2024 when the accept sql cert is checked. Also, In the next version of SSMS, Microsoft intends to bloat it with AI slop-ware, so archive a copy of SSMS 2024 to disk while you can. The last I looked at it a eight months ago, the next version is a bloated mess containing massive multi-GB installer files.
> so archive a copy of SSMS 2024 to disk while you can.
So, 2024, that is:
SSMS-Setup-ENU SQL Server Management Studio 20 20.2.1 (20.2.37.0).exe ~473 MB. Surprise, the SSMS 16 was over 900 MB, how did they shrink the installer? Just better packing I suspect.
And the next version 21, latest installer is a freackazoiding-downloader-only 4.3 MB, and indeed offers "Hey AI!" as first option. You have to vs_SSMS.exe --layout C:\SSMS21_21.6.17_(21.6.36603.0)_Layout --all to get it. Woah 2.32, this has gone bad.
And 22, current, 2.65 GB after the full download...
(Source: https://sqlserverbuilds.blogspot.com/2018/01/sql-server-management-studio-ssms.html lucky search engine fu)
Thanks for the hint, looks like all downloads are still there, down to SSMS16. I backuped the previous versions (down to SQL 2003 I think...) somewhere too, bad experiences when someone kills the installer to soon and then it suddenly gets very important 'cause you need some component for migration...
>how did they shrink the installer? Just better packing I suspect.
Yes that sounds right because 2024 is as just over a GB in the install dir, plus whatever other files are littered everywhere else.
Concur on 2024 being 20.2.37.0. It is as "fast" as 2014 which isn't saying much, because both are feature packed bloated slow dogs still forcing you to click 2x as much as the more efficient circa 1990s sql tools.
>And 22, current, 2.65 GB after the full download...
That sounds about what I remember it being 2GB+, sheesh. But with all telemetry coupled to AI, SMSS should now help us a lot. Issue a create table command and AI now randomly drops several tables instead. Bad bot!@#~!
If the 50 year old teletype still works and has all necessary features, and new gear can't make a better resiliency argument, then what's the problem?
The way vendors operate today, the replacement will cost a fortune, require costly training and migration consulting, then have to be replaced again in a few years when it's EOL'ed and security updates stop so admins who don't want to lose their job are forced to tell the boss that the only option is a costly forced upgrade to the new platform.
It's also being maintained by someone different than whomever installed it.
If the new-new-new admin pushes to replace long-running gear with something that screws up, then he owns the failure when the PHB comes knocking. Survival in office politics is one thing they don't teach in the classroom.
Same goes for IPv6. Why would a network admin want to risk an IPv6 transition fiasco unless the enterprise actually needs IPv6?
Most enterprises don't have an *actual* need for IPv6 and would be fine putting it off for another few decades.
Goodness, if you're going to budget for something new, bright, and shiny, at least make it cool. Readers can debate whether they like or hate configuring/administering it, but I doubt many people are having 42% more fun reading El Reg right now because in the back of their minds they know the connection is on v6 not v4.
You might want t read what I actually wrote instead of what you think I wrote. Because I never stated the existing tech needed to be altered. The issue with which my comment addressed was the OP's "perceived" laziness IT folk who support teletypes; along with his interpretation of what that reflected.
Perceiving sarcasm and snark in comments is often missed. But the thrust behind my comment was snark because I speculate the OP is trolling due to his extreme, unbalanced, unrealistic views of laziness in IT workers; and it being based on those who work in teletype environs. Call me extremely skeptical. Call me slightly sarcastic. Call me opinionated.
And... your comment was preaching to the choir. I strictly use IPv4 and block all IPv6 at all firewall levels (see my other comment in this forum post about that subject). I also strictly use old tech because for me for now, new tech provides no additional utility. I have a license for VS2022 but instead still use VS2013 (along with VS6 from the 1990s due to one vintage app-system which still works fine). When I need Windows at home, I strictly use Windows 7. As far as hardware, I make my living on a decade old Thinkpad W520, which is also my newest PC. For CS6 etc, I use an old Lenovo S30. As if that was not old enough, I also use a ancient circa 2002 custom build with quad core Px processor; used for backups which never lost a single bit. You are preaching to the choir.
Only in an hightly asymmetrical internet where endpoints are herds to be exploited for the advantage of a a few - the Internet designed by Google, Facebook & C. No surprise QUIC was developed by Google. And HTTP is not the only useful protocol.
One ot the issues with IPv6 is ANY client as a routable address - so they can start to get rid of centralized servers designed to hoard data from users and make money from them.
NAT, especially coupled with dynamic addresses, and even worse with CG-NAT, is a useful technique to avoid peple can start to deploy their own servers, especially since FTTH gave them enough bandwidth.
Expect Google & C. to find ways to neuter IPv6 advangates.
I think 128 bits is just tooooooo looooooong. I'd have gone for 80 bits myself: a fixed 48-bit network number and a 32-bit host number (the usual 4 billion) within that. Does any organisation, really anywhere, need more than 4 billion addresses across its networks? All the other benefits of IPv6 could be basically the same, but maybe we could chuck in a few improvements. Bingo, IPv7!
The widespread use of IPv4 NAT had the side effect of making life harder for advertisers, data harvesters, and similar ilk, who cannot assume that all connections from one address originate from the same device.
It's not a first-line privacy measure, but it does break certain assumptions which force the enemy to implement other measures, like device fingerprinting, client-side accounts, etc. Guess what? We can fight those too.
Defense in depth requires more than one tool in the toolbox. Given the state of privacy on the Internet, we need more tools, not fewer.
I always disable IPv6 and would for this reason alone.
Yeah, I can configure a firewall. But I've been around long enough to know I can also misconfigure a firewall or might not notice immediately if something goes wrong. I don't need most my gear to be globally reachable.
I've also been around long enough to know most users don't and that their poor security practices can quickly become everyone else's problem. IPv4 NAT wasn't designed as a security measure, but it the real world, it's played a huge role in frustrating the miscreant bot lords and worm writers.
>” Yeah, I can configure a firewall.”
Problem 101: what are the firewall rules needed for MS Windows, for example, to work? I ask as I don’t remember reading about or seeking a complete list of ports and addresses used by Windows, the services that require them etc. It’s the reason why personal firewalls like Outpost had a learning mode, where it regarded ALL traffic seen as valid and so created an appropriate allow rule, obviously, if you didn’t use something during the learn period…
I can tell you that :D. Reason: I need(ed) that for NetQoS and ipv6 to adjust every time the internet reconnected. Task Scheduler, trigger on event 4004 in "Microsoft-Windows-NetworkProfile/Operational", and then you do the right adjusting of the names firewall rule (in my case netqos was adjusted to new IP).
That's a fairly poor example to be honest - Windows is one platform that is quite well documented on the server side. Unless, of course, you meant 'any possible program that can run under Windows' which would be a bit silly.
Windows networking protocols aren't the problem. Programs that rely on RPC ('open every UDP port from 20000 through 65535') or insist on uPnP being enabled are the issue.
My personal network is locked down quite hard. No queries to external DNS or NTP other than via the internal servers. Only the ports required to provide services are open. It's broken a number of things, including streaming services.
Do these well funded services, used by hundreds of millions of people, have a reference as to what ports they use? Do they fuck. Instead they just say 'failed to connect' and provide zero detail on what is required. You also wouldn't believe (or probably you would) the sheer number of servers Google tries to connect to for gmail IMAP, it's literally dozens.
>what are the firewall rules needed for MS Windows
In most all OSes, far fewer ports require opening than the default host firewall settings allow. For internet browsing, only a few ports are required by default. First, block all outgoing and incoming by default. Then, allow out only 80,8080,443,53,68,123. Windows 7 and possibly 10 can be made private and safe to be connected to the internet, but it requires detailed knowledge and seven+ hours of fine tuning. Setting up its firewall for security is only step 1 of 200. And except for the fact that MS firewall contains MS covert allow-rules, Windows host firewall is among the best; it is exceptionally, intelligently designed.
You learned this claptrap as they stuffed it in all the exams ,and who wants a borderline fail on a dumbarse ipv6 question?
Maybe AI can think about it now as I instantly forgot it afterward and never dealt with it in a job.
Its one of those I know what it looks like issues. Like identifying different dogs or trees. You know,bollox.
I've been running IPv6 at home for something like 20 years, originally using 6to4 over dialup and now using a /56 network from my ISP (a major decider for me to use this ISP).
On the very rare occasions when I do need to specify an actual address at home I do tend to fall back to IPv4 but that's really just when my home DNS isn't available for some reason. This is rare though.
The one thing that does give me grief at the moment is Microsoft. For some reason Microsoft seems to have stuffed up their IPv6 routing so I have long delays while my browser falls back to IPv4 when I'm stupid enough to stray onto a site that's hosted on the Azure cloud. This wouldn't be a bad thing but I still earn a few bob each week looking after Windows machines for a local school. This forces me to look at their drivel from time to time. Maybe Microsoft is secretly trying to kill IPv6? OK, incompetence is a much more likely explanation here given their proven form.
Everything else works fine. In particular, if you happen to be looking at a long list of 'received by' headers when tinkering with email, I notice that most email hops these days seem to be over IPv6.
Perhaps more surprising is that when I used to teach networking, there where people in the teaching profession in quite high places that insisted as a piece of religious truth that IPv6 was dead and and should never be taught. I found that it worked fine to always discuss the two together since they are essentially the same (apart from address length). They both use the same 16 bit port numbers for TCP and UDP and all the higher level protocols are exactly the same.
The big argument for globally addressable devices (as I see it) are proper peer-to-peer voice and messaging protocols that avoid any sort of central mediation from corporation of choice to help find each other. Not sure quite how this should work, but I do know that the current trend in IT tech is to need subscriptions for all manner of 'services' that will all disappear when the vendor goes TITSUP in a few years time.
> For some reason Microsoft seems to have stuffed up their IPv6 routing so I have long delays while my browser falls back to IPv4
No, this is actually the RFC "prefer ipv6 over ipv4 if avail", since Windows XP/Server 2003 (even Windows 2000 can ipv6, but that is an extra package). Microsoft is following the RFC exactly as it should.
What you may want is prefer ipv4 over ipv6. This is a two step process with different methods, you may have to use both.
Variant 1, prefer ipv4: reg.exe add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters" /v DisabledComponents /t REG_DWORD /d 0x00000020 /f
Variant 2, ipv6 prefix policies (note: highest precedence comes first) (EDIT: Note 2: I had to add "." at the beginning else ElReg stupid forum software even kills preceding ALT-255 space):
C:\>netsh interface ipv6 show prefixpolicies
Der aktive Status wird abgefragt...
Vorgänger Label Präfix
---------- ----- --------------------------------
. 50 4 ::ffff:0:0/96
. 40 0 ::1/128
. 30 1 ::/0
. 20 2 2002::/16
. 5 5 2001::/32
. 3 13 fc00::/7
. 1 11 fec0::/10
. 1 3 ::/96
. 1 12 3ffe::/16
No you can adjust the prefix policy. I don't have to adjust mine since they are correct, however I know some "helpers" might mess around in Windows without knowing in depth, but the command would be (for each prefix listed):
netsh interface ipv6 set prefixpolicy 2001::/32 5 5
I even wrote a powershell script to correct both since I needed it for more machines where a software thought it had to optimize around.
Linux should have similar, but I have no linux here any more (was heavy linux user from first slackware CD up to ~2010), but "ip something blah" should offer roughly the same prefixlist, maybe naming it "priority" or "ipv6-prefix-metric" or whatever, in the end the same.
Reading these comments is fascinating. It’s like watching a town hall meeting where the tenants of a crumbling tenement block angrily vote against indoor plumbing because they’ve grown emotionally attached to the bucket.
To the "Just add more bits/IPv4.5" crowd: You are bargaining with math. You cannot change the header length without breaking every ASIC and router on the planet. If you have to replace the hardware anyway, why replace it with a hack?
To the "NAT is Security" crowd: Please stop. NAT is not a firewall. It is a translation table. It permits outbound malware C2 traffic just fine. Relying on NAT for security is like relying on a maze to keep burglars out of your house instead of locking the front door. It is a comfort blanket for those who never learned how to write a firewall rule.
But the real tragedy here is the economic blindness.
While you are all patting yourselves on the back for "holding the line" against IPv6, the brokers and legacy holders are laughing all the way to the bank. You are engaging in Stockholm Syndrome with your landlords.
The "Asset" is Dead: The IPv4 market peaked in 2022. It is no longer a growth asset; it is a tool for managing legacy debt.
The "Rent" is Forever: Every day you delay IPv6, you are locking your organization into a permanent tax payable to the "Slum Lords" of the internet—the entities hoarding /8s and leasing them back to you at extortionate rates.
The "Complexity" is Yours: You complain about IPv6 complexity while managing CGNAT states, split-horizon DNS, and overlapping RFC1918 spaces. You have normalized the pain of the slum so much you don't even feel it anymore.
Geoff Huston calls this "success" because the internet didn't break. That’s not success; that’s just managing the decline. The rest of the world (mobile networks, IoT, Asia) is moving to a modern infrastructure. Feel free to stay behind and memorize your dotted quads, but don't pretend it's a technical decision. It's just professional obsolescence.
> But the real tragedy here is the economic blindness.
> While you are all patting yourselves on the back for "holding the line" against IPv6, the brokers and legacy holders are laughing all the way to the bank. You are engaging in Stockholm Syndrome with your landlords.
I'll happily pay less than the cost of a cup of coffee each month for an IPv4 address which doesn't leak information about end devices and which the ISP rotates through via DHCP on a frequent basis, on top of every other measure. It's called layered defense.
I already pay more than that every month for a VPN.
I already spend way more than that on each month for extra VPSes which relay Tor traffic.
I already pay extra for extra IPv4 addresses so Tor users in non-free countries can connect.
The real hostage takers on the Internet are the privacy invaders who have turned the infosphere into a cesspool filled with tracking, clickbait, advertising, and AI slop.
Would happily pay for news, too, if the billing gateway doesn't demand way too much information to send journalists $5. Been reading El Reg for 25 years. Been blocking their ads for 25 years. Wish I could have sent them a privacy-preserving micropayment every month for the last 25 years because good information is worth it. Seriously, $5 or $10 a month is nothing for an IT professional to protect personal information. Whether it's for news, VPN, IPv4, etc.
What's your time worth?
How much time have you wasted with IPv6 for no benefit?
For various reasons I didn't see this story sooner, so I expect nobody will ever read this comment, but:
1. IPv6 didn't turn 30 in 2025; the IPv6 decision was announced in July 1994 at the IETF in Toronto.
2. Since Google sees more than 49% of its users connecting via IPv6, and that doesn't include China, it's more of a success than a failure. We expected from the very beginning that v4 and v6 would coexist for many years. That's a feature, not a bug.
3. There is no grey market in IPv6 addresses. That in itself should be a pretty convincing argument. There are half as many IPv4 addresses as there are living people. How silly!
IPv6 rules.
> Since Google sees more than 49% of its users connecting via IPv6, and that doesn't include China, it's more of a success than a failure.
The Internet has split into two.
There's a TV broadcast network: Google, Apple, Netflix, Spotify, Facebook. These sites account for a large propertion of total traffic by volume. These install CDN nodes very close to the customers - often inside the ISP networks. For them, Internet is just "last mile" content delivery; they often have their own private links between data centres. And these are the sites which have deployed IPv6.
Then there's the rest of the Internet: where you find banks and shops and restaurants and other businesses. Most of this part does *not* run IPv6.
So it's not surprising that Google see a substantial proportion of IPv6: it reflects that a sizeable proportion of Youtube watchers have dual stack at home (usually without realising it). But offices, hotels, enterprises ... not so much.
> 2. Since Google sees more than 49% of its users connecting via IPv6, and that doesn't include China, it's more of a success than a failure. We expected from the very beginning that v4 and v6 would coexist for many years. That's a feature, not a bug.
...which reflects IPv6 deployment on frequently-replaced smartphones under the near-complete hardware and software control of the manufacturer and carrier, all on a network where putting multiple customer-owned devices behind one piece of CPE wasn't an issue. Deployment is plateauing, and will continue to, because IPv6 remains actively undesirable in many other instances.
The IPv6 committee shot itself in the foot waging such a hard crusade against NAT and DHCP, thinking they'd be greeted as liberators.
A firewall can solve the problem of packets being globally routable to end devices, but we're keeping our IPv4 NAT because we don't want those devices being globally addressable, either.
But the committee wanted to force a campus-dream paradigm of global addressability on everyone, and to make matters worse, broke the paradigm of local addresses being agnostic of the WAN portion / prefix. That's doubly bad when a static WAN IP is a bug, not a feature.
Fortunately IPv4 will be around at least another 30 years and we'll continue using it for its desirable features. I'll keep turning IPv6 off on every device I touch. Hasn't caused a problem yet.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
