Re: [v6ops] Our IPv6-only home network and future experiments

[Vasilenko Eduard <[e-mail]>]

Hi Brian,
We could put aside NAT64 because you do not want to change it.

Effectively you are trying to solve 2 problems:

  1.  For the IPv4 on the destination side:
You would like to eliminate DNS64 because it is not secure.
Why put it into libc? DNS64 may be on the host, then DNS could be secure again.

  1.  For the literal IPv4 request on the source side:
You would like to put CLAT into libc instead of the host itself.
But how many applications use literals? Ping, traceroute, what else?
And for these few applications, you would like to bloat the basic libc functions.
Because it would simplify the kernel. Libc is effectively the part of the kernel anyway.
Well, I do not know what is better.

By the way, what if the application is developed with a different language that does not use libc. Should it fail with literals?
Or there is a need for modernization of all dynamic libraries in the world?

Ed/
From: Brian Candler <[e-mail]>
Sent: Monday, April 15, 2024 11:14
To: Vasilenko Eduard <[e-mail]>; Soni "They/Them" L. <[e-mail]>; IPv6 Operations <[e-mail]>
Subject: Re: [v6ops] Our IPv6-only home network and future experiments

On 15/04/2024 08:47, Vasilenko Eduard wrote:
OK. It looks like you want to avoid centralized DNS64, but still use NAT64 (and pref64).

We spend our lives trying to make the DNS trustworthy, but DNS64 destroys that by giving out fake information. In any case, DNS64 doesn't work for IP literals.

You should try running 464XLAT on an IPv6-only network some time: you can do "ping 8.8.8.8" and it works fine.

Most end-users don't use IP literals (even though https://1.1.1.1/ is a thing). But for sophisticated users, especially network engineers, it's an extremely useful thing to be able to use.



By the way, how NAT64 prefix would become available for libc *at the compilation time* (on a host in a different organization).
Or libc should get pref64 from the host at the run time?

The latter.

My doubt is still applicable:
If you have to change application then it is better to change it to IPv6.

The applications at the end-user (consumer) side are already IPv6-ready and don't need changing.

The problem here is that the vast majority of Internet content is only present with IPv4 addresses, and will be for a very long time - possibly forever.

At the consumer side, for the last 25+ years we've been telling people to run dual-stack. Most edge networks have rejected this, IMO quite understandably. They get all the pain (double addressing plans, double attack surface, double sets of firewall rules etc etc) with almost zero benefit, since everything they want is reachable via the IPv4 leg anyway.

Or to put it bluntly: dual stack is the problem, not the solution.

The only way I see out of this quandry is to make it realistic to run single-stack, IPv6-only networks at the access side. And that means having a usable mechanism to access IPv4-only content. An embedded CLAT gives this.

Traditional embedded CLATs appears as a local pseudo-device with IP address 192.0.2.2, and you point IPv4 default route at 192.0.2.1. macOS, iOS, Android all have this, and soon Windows. It works, but it's clunky, and it relies on an IPv4 stack in the kernel.

The initiative here is to try a different approach for Unix-like systems: one which is lightweight and requires fewer changes.

Regards,

Brian.