IIRC Samba started out working on interop with DEC Pathworks, which was somewhat compatible SMB implementation (devil in the details, Pathworks predates SMB ossifying into what it became in NT4 when there was a lot of customization by vendors).
This meant that early versions were compatible with Pathworks servers but not Windows ones (but Windows could be configured to work with Pathworks)
The firewall is very much a separate thing, and part of the efforts to make v6 properly available for home customers was introducing somewhat standard firewall setup that replicates what people think NAT does for security (and what NAT definitely does not do, if only by virtue of being broken by the classic connect/connect vs connect/listen connection)
The problem is that the scheduled end of ipv4 was reached in 1990.
But attempts at providing replacement were stymied - IETF went not-invented-here finally getting v6, while USGOV went with CLNS, and meanwhile vendors hemmed and hewed to avoid spending any money on actually implementing changes and then allowed NAT availability to crush arguments and mandates.
It was not possible to make a "superset" of IPv4, if only because one of the early major blockers was that BSD Sockets suck by leaking low-level details of addressing so you'd have exactly the same argument of "why should I bother writing entire second copy of connection code in my application" for any superset you want to imagine.
Similarly, we have 30 years of experience that vendors will happily break optional headers or flags.
I don't think this is how it would have played out at all.
I'm no expert on IPv4 or IPv6, but if they had designed IPv6 to be able to route fine to IPv4, we'd be OK.
It would at least give people an upgrade path where their old stuff that couldn't be patched / updated and were stuck on IPv4 could be slowly killed off in the path of least resistance down the dependency line.
This 'dual stack' approach doubled up on everything up front and meant we all had to do both during the transition (which has taken 30 years).
IPv6 explicitly supports all sorts of transitional technology, including being able to map v4 addresses to v6 that are used with translation gateways connecting from v6 to v4 (widely used in mobile networks to provide any v4 access).
That still requires that if you have used BSD Sockets before getaddrinfo was added (or like many, didn't learn about it for years) then you had to rewrite the parts of your application that are responsible for handling connections.
I've spent half a year getting nowhere on a discussion involving VPN-ing parts of the company just to have connectivity for specific services where part of the problem was lots and lots of overlapping 10./8 allocations - partially because everyone setting a "VPC" or some local dc network was doing individual 10./8, often "in name of simplicity".
With subnetting needs, possibly dealing with VPNs to other networks that might use 10./8, ISPs that might use 10./8 instead of CGNAT space (100.64./10), even the total incompetence of some contractors was not reducing how IPv4 was a problem.
And that's before you hit the part where Microsoft products have been IPv6 First since ~2008 and there are entire feature sets that are very interesting to bigger companies (like well integrated always-on vpn for laptops) that require working v6
They also had IPv9 with 20 byte addresses (160 bits) though some of that was consumed for common prefix announcing "this is a TUBA address". It was even something that was already supported by some hardware and software, as it was just dropping IP and replacing it with CLNP and transporting TCP and UDP over it (I think the most complex part was adapting ICMP-based tools).
Multiple networks do the same - Both T-Mobile (at least in EU) and Orange no longer actually support v4 other than through funky 464 and by funky I mean really funky at times.
US government has finally learnt from how vendors break the mandates and there's now IPv6 mandate if you want to sell to federal government, and waivers are only available for buyers not vendors, and individually every time.
This meant that early versions were compatible with Pathworks servers but not Windows ones (but Windows could be configured to work with Pathworks)
reply