Re: [v6ops] How to make an elegant IPv4 outage

On Sun, Jun 14, 2026 at 12:45 PM Franck Martin <[email protected]>
wrote:

> My internal network is segmented into a series of VLANs so that the IoT
> devices cannot touch the production network. Each VLAN has a separate
> prefix 10.x.*.*. If a device has IPv6 service, the IPv6 address will be in
> a /24 with the lower 32 bits being its net 10 suffix.
>
> And this isn't just some scheme PHB thunk up, it is pretty much the way
> people deploy the hardware just as named.config.local is the place most
> people list out the zone files for their local domains.
>
>
> And the security of those devices is questionable at best. Like you I
> don’t see it changing soon. When you are in the shop, there is no way to
> figure out if any device has IPv6 support, but I know they will want me to
> open a cloud account, to manage this device. Nothing can work locally
> (because they sell time on those device for scrapping the Internet for our
> AI overlords?).
>

As an applications guy, I recognize the fact that there are many situations
where it is simply impossible to make the system work unless there is a
part of it rooted on a service that is available 24/365 with a static IPv4
address. I do not expect that to change and so I work within that
constraint and instead look at ways to eliminate the switching costs that
give the service provider pricing power in that situation.

I am building out a service so other people don't need to do that. But if
you choose to use my prototype service and decide you don't like my SLA,
you can switch at any time you choose without any switching cost provided
only that you have your own DNS name registration.

As an application provider, I need a place that is separate from the device
where my code runs that can provide at minimum discovery and presence
services and it is handy to have some storage. But as a user, I do not need
to have those services from Microsoft, Apple and Google, all three of which
I am using today because the cost of not doing so is much higher than
paying for them. And I might even be prepared to tolerate that indefinitely
if two of the providers I bought over $1500 worth of IoT gear had decided
on a forced obsolescence strategy in the hope of forcing me to pay for
upgrades.

So my architecture consists of:

1) A brand which tells people 'this application/device will work with the
open service'

2) An application that manages public AND PRIVATE keys for the end user so
they have 100% control over the trust endpoints of their communications.

3) An open cloud service that provides a dead drop allowing applications to
exchange messages with other users/devices even if the other endpoint is
currently offline that the user chooses and can change at any time they
choose without switching costs.

4) An open cloud service that provides the DNS layer management for the
internal and external networks.

I am fully aware that this approach conflicts with the commercial ambitions
of some parties. But I am also aware of many other commercial parties which
will do better under my approach. And remember that when we built the Web,
we knew full well that it conflicted directly with the 'Interactive TV'
proposed by Time Warner.