Nach dem Vortrag von Wilhelm Boeddinghaus zu CLAT für Windows auf dem Berliner Adminstammtisch stellt sich mir jetzt die Frage, wo nehme ich 9 Windows11-Kisten mit aktivierten Beta-Insider-Preview her?
#ipv6only #ipv6 #clat #windows11
After the talk by Wilhelm Boeddinghaus about CLAT for Windows at the Berliner Admin Stammtisch I am wondering how to get 9 windows 11 boxes with beta-insider-preview?
That's the question.
W.B. was opening my eyes.
I have seen the
::c0:0:100:0
::c0:0:200:0
but I thought it is a kind of leet speak for clat, but it is 192.0.0.1 192.0.0.2 and so on.
So I don't know what happens with 8 or 9 devices, since 192.0.0.0 is already the virtual default gw.
I see. Those are following the /64 mappings in RFC 6052. This is not exactly the purpose that RFC 6052 is intended for. And you already identified the scalability challenges of that approach.
I am guessing they use duplicate-address-detection to ensure two machines don’t pick the same address. if that guess is correct you can easily verify what happens. Just make have a machine use all of the addresses ending in c0:0:0:0 ti c0:0:700:0 before the test machine connects to the network.
If the implementation is even just a little bit sensible it will see that its preferred IPv6 addresses are already in use and pick a random IPv6 address instead. It can still use any address in the 192.0.0.0/29 range locally.
DAD works, but nothing more.
Or in other words: At the moment it is not possible to use more than one Windows-PC with IPv6-mostly-support (Preview only ) in a IPv6-mostly or IPv6-only Network.
By accident a host may use one of the other mapped IPv4 addresses (out of 192.0.0.0/29) . But in general it takes the first one anywhere.
and W.B. is right: MS has to fix that problem before it gets released for the masses
Wait, so:
They're assigning an additional v6 address to the CLAT, but then they're encoding the CLAT v4 address (in 192.0.0.0/29) into that v6 address for some reason? E.g. the 2001:a61:4b7:63ec:c0:0:100:0(Bevorzugt) address in the screenshot?
Like, why???
The whole point functioning there is, afaik, that the CLAT v4 address is supposed to be locally significant only, and therefore the actual size of the v4 CLAT address range is irrelevant. Why would they intentionally do something to make this locally-significant address into something significant to the whole network?
Encoding the client IPv4 address into the IPv6 address used for CLAT makes sense if the CLAT is intended to support multiple clients.
So I am guessing they have some mixup between different deployment scenarios: A single CLAT serving all clients on a network vs every client host running their own CLAT.
Maybe some part of the code was originally intended to use the IPv4 address of a physical interface, but once it no longer acquires any IPv4 address from the DHCP server that code falls back to the IPv4 address from the CLAT interface - which is not unique.
I can imagine other deployment scenarios where this code might fail as well. Imagine a number of machines with two network interfaces trying to share the internet connection. If all of those machines are connected to the same IPv6-only network and each do CLAT for clients on distinct LAN segments, then the IPv4 addresses from those distinct LAN segments leaks onto the IPv6-only network and will cause conflicts if those LAN segments happen to be using the same IPv4 addresses.
All of this could be fixed by routing a /96 (or shorter) prefix to each CLAT. But that would require prefix-delegation to each individual host. Another way to address it would be for the CLAT to do stateful NAT in order to only need a single IPv6 address.
Regardless of what solution you prefer, I think we agree that it is sub-optimal to ship code that won’t work in the network configuration you are most likely to encounter in real life.
@hugo
Yes, they do.
The host with that entry: 2001:a61:4b7:63ec:c0:0:100:0(Dupliziert) doesn't work.
Why they are doing this?
I don't know.
It must be early state of the preview.
Thomas Schäfer
kasperd
Hugo Slabbert ⚠️