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

--===============9025282456414513507==
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_63DEAA51-8131-4053-9E2F-5DD86509179A"

--Apple-Mail=_63DEAA51-8131-4053-9E2F-5DD86509179A
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8



> On Jun 14, 2026, at 09:35, Phillip Hallam-Baker =
<[email protected]> wrote:
>=20
>=20
>=20
> On Fri, Jun 12, 2026 at 9:53=E2=80=AFPM Brian E Carpenter =
<[email protected] <mailto:[email protected]>> =
wrote:
>> Erik,
>>=20
>> On 13-Jun-26 02:19, Erik Nygren wrote:
>> > + v6ops
>> >=20
>> > On the topic of the original draft =
(https://datatracker.ietf.org/doc/html/draft-martin-retry-over-ipv6-01 =
<https://datatracker.ietf.org/doc/html/draft-martin-retry-over-ipv6-01>):
>> >=20
>> > 1) I wonder if this is pointing towards a desire to either start =
sunset4 back up again, or to charter work within some existing WG =
(v6ops, 6man, others?) to pick back up on where sunset4 left off, =
specifically looking for technology solutions and operational =
recommendations to provide a path towards phasing out IPv4 in various =
environments. =20
>>=20
>> I really hope not. I think we have learnt that attacking currently =
working solutions is self-defeating, which is ultimately why sunset4 =
failed.
>=20
> Exactly. The problem I have seen all along is that what the Internet =
users need is a mechanism that allows them to interact in a larger =
Internet without any impact on their user experience whatsover and this =
has been interpreted inside the IETF as 'force everyone to transition to =
IPv6 for everything, everywhere'.
>=20
>=20
> My experience deploying a high end prosumer network in the house tells =
me that IPv4 is never going to go away and it is futile to expect =
otherwise.
>=20
> The border gateways have a capacity of ~1000 client devices, I am =
currently using 72 IP addresses after a purge but don't anticipate using =
more than 250 in the near future.
>=20
> All the interior routing of addresses uses private addresses. I could =
wire a static IP address direct to an internal host but since I have to =
pay $20/mo for each block of 4 static IPv4 addresses, that would be a =
waste and limit internal administration. In 1995, a DNS server was a =
specific host, now it is one virtual machine floating around a cluster =
of Proxmox hosts.
>=20
> So instead, I have rules that map split the ports out to the hosts =
that service them. And here we get to the part that makes transitioning =
to IPv6 on the Internal network highly unlikely: 10.x.0.y is so much =
easier to remember than anything in IPv6 space.
>=20
> 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.
>=20
> 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=E2=80=99t 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?).

>=20
> The mental model I think appropriate is IPv4 is high level language =
and IPv6 if machine code.
>=20
> Yes we are going to be using IPv6 in the Internet to come. But the =
reason we haven't run out of IPv4 addresses so far is that most of the =
devices are mobile clients and those work just fine on an IPv6 =
connection with a carrier grade NAT to talk to legacy IPv4 only sites.
>=20
> I will be making my services available over IPv6 as soon as I can find =
an ISP that will give me the necessary static IP/64. But my expectation =
is that I won't ever need to interact with them directly as an =
administrator on the internal network, it will be purely limited to the =
network gateway interface.
>=20
> The net is that while IPv6 will gain deployment, IPv4 will retain its =
mindshare and I do not expect that to change for at least another =
century.

Interesting,

Reading a few more comments on that subject.

It feels to me anyone should be able to request an IPv6 allocation to =
the local RIR AND then ask to have it routed by its provider. Until =
then, the provider will try to lock the customer, as they always have =
done.

Market forces at play here.

When I was in Fiji, like 20 years ago, I requested an IPv6 allocation, =
setup 2 servers in the USA with BGP access, and setup tunnels from 3 =
providers to these servers. I had IPv6 and BGP over tunnels, something =
none of the local providers wanted to give me.


--Apple-Mail=_63DEAA51-8131-4053-9E2F-5DD86509179A
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

<html aria-label=3D"message body"><head><meta http-equiv=3D"content-type" =
content=3D"text/html; charset=3Dutf-8"></head><body =
style=3D"overflow-wrap: break-word; -webkit-nbsp-mode: space; =
line-break: after-white-space;"><br =
id=3D"lineBreakAtBeginningOfMessage"><div><br><blockquote =
type=3D"cite"><div>On Jun 14, 2026, at 09:35, Phillip Hallam-Baker =
&lt;[email protected]&gt; wrote:</div><br =
class=3D"Apple-interchange-newline"><div><div dir=3D"ltr"><div =
dir=3D"ltr"><div class=3D"gmail_default" =
style=3D"font-size:small"><br></div></div><br><div class=3D"gmail_quote =
gmail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr">On Fri, Jun =
12, 2026 at 9:53=E2=80=AFPM Brian E Carpenter &lt;<a =
href=3D"mailto:[email protected]">[email protected]</a=
>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" =
style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid =
rgb(204,204,204);padding-left:1ex">Erik,<br>
<br>
On 13-Jun-26 02:19, Erik Nygren wrote:<br>
&gt; + v6ops<br>
&gt; <br>
&gt; On the topic of the original draft (<a =
href=3D"https://datatracker.ietf.org/doc/html/draft-martin-retry-over-ipv6=
-01" rel=3D"noreferrer" =
target=3D"_blank">https://datatracker.ietf.org/doc/html/draft-martin-retry=
-over-ipv6-01</a> &lt;<a =
href=3D"https://datatracker.ietf.org/doc/html/draft-martin-retry-over-ipv6=
-01" rel=3D"noreferrer" =
target=3D"_blank">https://datatracker.ietf.org/doc/html/draft-martin-retry=
-over-ipv6-01</a>&gt;):<br>
&gt; <br>
&gt; 1) I wonder if this is pointing towards a desire to =
either&nbsp;start sunset4 back up again, or to charter work within some =
existing WG (v6ops, 6man, others?) to pick back up on where sunset4 left =
off, specifically looking for technology solutions and operational =
recommendations to provide a path towards phasing out IPv4 in various =
environments.&nbsp; <br>
<br>
I really hope not. I think we have learnt that attacking currently =
working solutions is self-defeating, which is ultimately why sunset4 =
failed.<br></blockquote><div><br></div><div><div class=3D"gmail_default" =
style=3D"font-size:small">Exactly. The problem I have seen all along is =
that what the Internet users need is a mechanism that allows them to =
interact in a larger Internet without any impact on their user =
experience whatsover&nbsp;and this has been interpreted inside the IETF =
as 'force everyone to transition to IPv6 for everything, =
everywhere'.</div></div><div><br></div><div><br></div><div =
class=3D"gmail_default" style=3D"font-size:small">My experience =
deploying a high end prosumer network in the house tells me that IPv4 is =
never going to go away and it is futile to expect otherwise.</div><div =
class=3D"gmail_default" style=3D"font-size:small"><br></div><div =
class=3D"gmail_default" style=3D"font-size:small">The border gateways =
have a capacity of ~1000 client devices, I am currently using 72 IP =
addresses after a purge but don't anticipate using more than 250 in the =
near future.<br><br>All the interior routing of addresses uses private =
addresses. I could wire a static IP address direct to an internal host =
but since I have to pay $20/mo for each block of 4 static IPv4 =
addresses, that would be a waste and limit internal administration. In =
1995, a DNS server was a specific host, now it is one virtual machine =
floating around a cluster of Proxmox hosts.</div><div =
class=3D"gmail_default" style=3D"font-size:small"><br></div><div =
class=3D"gmail_default" style=3D"font-size:small">So instead, I have =
rules that map split the ports out to the hosts that service them. And =
here we get to the part that makes transitioning to IPv6 on the Internal =
network highly unlikely: 10.x.0.y is so much easier to remember than =
anything in IPv6 space.<br><br>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.<br></div><div class=3D"gmail_default" =
style=3D"font-size:small"><br></div><div class=3D"gmail_default" =
style=3D"font-size:small">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&nbsp;is the place most people list out the zone files =
for their local =
domains.<br></div></div></div></div></blockquote><div><br></div>And the =
security of those devices is questionable at best. Like you I don=E2=80=99=
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?).</div><div><br><blockquote type=3D"cite"><div><div =
dir=3D"ltr"><div class=3D"gmail_quote gmail_quote_container"><div =
class=3D"gmail_default" style=3D"font-size:small"><br>The mental model I =
think appropriate is IPv4 is high level language and IPv6 if machine =
code.</div><div class=3D"gmail_default" =
style=3D"font-size:small"><br></div><div class=3D"gmail_default" =
style=3D"font-size:small">Yes we are going to be using IPv6 in the =
Internet to come. But the reason we haven't run out of IPv4 addresses so =
far is that most of the devices are mobile clients and those work just =
fine on an IPv6 connection with a carrier grade NAT to talk to legacy =
IPv4 only sites.</div><div class=3D"gmail_default" =
style=3D"font-size:small"><br></div><div class=3D"gmail_default" =
style=3D"font-size:small">I will be making my services available over =
IPv6 as soon as I can find an ISP that will give me the necessary static =
IP/64. But my expectation is that I won't ever need to interact with =
them directly as an administrator on the internal network, it will be =
purely limited to the network gateway interface.<br><br>The net is that =
while IPv6 will gain deployment, IPv4 will retain its mindshare and I do =
not expect that to change for at least another =
century.</div></div></div>
=
</div></blockquote><br></div><div>Interesting,</div><div><br></div><div>Re=
ading a few more comments on that subject.</div><div><br></div><div>It =
feels to me anyone should be able to request an IPv6 allocation to the =
local RIR AND then ask to have it routed by its provider. Until then, =
the provider will try to lock the customer, as they always have =
done.</div><div><br></div><div>Market forces at play =
here.</div><div><br></div><div>When I was in Fiji, like 20 years ago, I =
requested an IPv6 allocation, setup 2 servers in the USA with BGP =
access, and setup tunnels from 3 providers to these servers. I had IPv6 =
and BGP over tunnels, something none of the local providers wanted to =
give me.</div><br></body></html>=

--Apple-Mail=_63DEAA51-8131-4053-9E2F-5DD86509179A--


--===============9025282456414513507==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Disposition: inline

LS0gCldpdGFyZWEgbWFpbGluZyBsaXN0IC0tIHdpdGFyZWFAaWV0Zi5vcmcKVG8gdW5zdWJzY3Jp
YmUgc2VuZCBhbiBlbWFpbCB0byB3aXRhcmVhLWxlYXZlQGlldGYub3JnCg==

--===============9025282456414513507==--