Having spent a lot of time looking at technology transitions in an attempt to understand how to make them happen, I find that the discussion here is unfortunately misguided. Transitioning SMTP service to IPv6 only is ultimately futile because there is no way to break from dual stack to IPv6 only.
I run a lot of prisoner dilemma type simulations trying to get a handle on the outcomes. Yes, I know Rational Choice is nonsense as far as human behavior goes but the predictions it makes do converge with reality.
The fundamental problem here is that if I am running any sort of large mail service, I am evaluated on deliverability by my customers, not by the protocols I use. If 5% of email servers are IPv4 only, I have to support them or my deliverability will fail and I will get complaints. IPv4 addresses are not a scarce commodity as far as operators of mail services goes and so IPv4 will always be with us as far as SMTP is concerned.
So if my IPv4 server is going to continue to be supported, why go to the effort of moving to IPv6? A secondary factor is likely the fact that constraining the address range to 32 bits makes spam control vastly easier for the receivers. So I would not be surprised if refusing to accept IPv6 is a thing some group will insist on.
I don't see this as a problem worth getting wound up about because being stuck with IPV4 is a heck of a lot less inconvenient than being stuck with SMTP. Its like suggesting we must convert the car to run on electric instead of gas when the immediate problem is it lacks floor pans.
Replacing SMTP with a new messaging system is a futile endeavor as well. But that is not the only option. The important thing in SMTP is that it is open service: users of any service provider can send mail to users of any other service provider and at least in principle if not in practice, anyone can be a service provider.
We have MOQ which is 90% of an end-to-end secure transport for voice and video but it lacks the presence capabilities required to provide a voice/video communications service. And that infrastructure could support asynchronous chat, mail and large file transfer as well. Replacing SMTP is futile but introducing an all in one solution that meets all the user's communications needs is merely difficult.
I do have drafts and running code for everything except for the MOQ interactions. But that should not be that difficult to achieve. I will be at Dublin and should be able to demonstrate parts of my system there. I have written all the hard parts, provisioning keys to devices, exchanging them between users, etc. I have the presence system designed but not finished coding. Moving from presence to support chat to handing off a shared primary secret and IP endpoints to a MOQ client is really not difficult. If someone knows of a C# library for MOQ or a wrapper I could use, I might be able to get that working as well.
People can argue about the futility of such an exercise, especially those of us who have actually run the numbers. But if there is a demand for a genuinely open agile communications suite, I am not aware of anyone else in IETF orbit working on a proposal.
Oh and yes, it does provide an IPv6 transition strategy but that is a feature of the support built in for enabling future schemes for defeating traffic analysis which if you think about it is basically a form of NAT on steroids. If Alice and Bob are going to establish a covert channel through some sort of baffle network, it makes sense to allow them to connect via IPv4 or IPv6. Because Alice and Bob never communicate directly, it means Alice can talk to Bob when she is on an IPv4 only network and he is on IPv6 only.
On Mon, Jul 1, 2024 at 9:46 AM Keith Moore <moore@xxxxxxxxxxxxxxxxxxxx> wrote:
On 7/1/24 09:35, Salz, Rich wrote:
You are an ISP. You have finite resources. Which is more important, L4S or IPv6? Pick one. The systems interoperate. Not having IPv6 is not a barometer or capability at all; at most it's a concession to engineering reality.There's that world "reality" again. In my experience, most of the time that word is used, it's a lie.
Bottom line: IPv6 is THE migration path away from IPv4 and its inherent problem of address exhaustion. Any service provider not supporting IPv6 by now is deliberately creating its own obsolescence.
