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

[Brian Candler <[e-mail]>]

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.