| 17 May 2026 |
 emily | oh yeah it would be a separate daemon for sure | 16:05:13 |
 raitobezarius | MAP-T | 16:05:13 |
| emily | I mean it's really just a matter of port forwarding on the v4 end | 16:05:22 |
| emily | right (omg why are there so many overlapping acronyms and similar-but-not-quite-identical mechanisms in this stuff) | 16:06:01 |
| raitobezarius | something something about the people writing them | 16:06:16 |
| raitobezarius | jool supports MAP-T | 16:06:23 |
| emily | correct me if I'm wrong, but MAP-T requires an explicit table of "this IPv4 addr + port → this IPv6 addr + port" right? | 16:06:23 |
| raitobezarius | port range, but yes | 16:06:36 |
| emily | so my question is more about: how can clients dynamically request such a forward | 16:06:44 |
| emily | so that you don't need static configuration for what in v6 land is just opening a listening socket | 16:06:56 |
| raitobezarius | i never heard about a dynamic protocol for this | 16:06:57 |
| raitobezarius | i only know about static allocations | 16:07:07 |
| raitobezarius | in MAP-T, the static allocation is such that you can reasonably preconfigure picking a port in the x*65k/n slice | 16:07:24 |
| emily | well depends how many clients and how many v4 addresses you have :D | 16:07:53 |
| emily | I think PCP is the correct shape (being the v6-aware successor to NAT-PMP/UPnP) but I'm just not sure if it can handle v6 on the internal end and v4 on the external | 16:08:34 |
| raitobezarius | yeah, I'm not super familiar with PCP | 16:08:58 |
| emily | If the PCP-controlled device is stateless (that is, it does not
establish any per-flow state, and simply rewrites the address and/or
port in a purely algorithmic fashion, including no rewriting), the
PCP server simply returns an answer indicating the external IP
address and port yielded by this stateless algorithmic translation.
This allows the PCP client to learn its external IP address and port
as seen by remote peers. Examples of stateless translators include
stateless NAT64, 1:1 NAT44, and NPTv6 [RFC6296], all of which modify
addresses but not port numbers, and pure firewalls, which modify
neither the address nor the port.
| 16:09:07 |
| emily | looks like it does envision there might be 6/4 mapping in there! | 16:09:15 |
| raitobezarius | the only way I achieved these things were static allocations via SIIT-DC or MAP-T | 16:09:20 |
| emily | my thinking is that if you have PCP hooked up to the NAT64, then you can also have shim UPnP/NAT-PMP servers that take normal v4 port-forwarding requests, translate them to PCP NAT64 requests, and then translate back | 16:10:42 |
| emily | so if you have kernel v4→v6 translation automatic port forwarding "just works" (maybe) | 16:11:08 |
| emily | "When the address field holds an IPv4 address, an IPv4-mapped IPv6 address [RFC4291] is used (::ffff:0:0/96). This has the first 80 bits set to zero and the next 16 set to one" | 16:11:52 |
| emily | okay yeah, so you can totally mix 6/4 with PCP | 16:12:00 |
| emily | fun! | 16:12:06 |
| emily | I wonder if you can get Linux to automatically make PCP requests for sockets listening on public IPs 😅 | 16:13:33 |
| 18 May 2026 |
 matthewcroughan - nix.zone | Anyone wanna help debug my tailscale? I can't use magicdns on d233902 | 13:47:16 |
| matthewcroughan - nix.zone | and I've bumped a few times, no real changes | 13:47:22 |
| matthewcroughan - nix.zone | IPs can still be pinged at all times, if I restart tailscaled then magicdns works again | 13:47:52 |
| matthewcroughan - nix.zone | Then after some time, a few minutes, magicdns stops working | 13:49:18 |
| matthewcroughan - nix.zone | resolvectl
Global
Protocols: +LLMNR +mDNS -DNSOverTLS DNSSEC=no/unsupported
resolv.conf mode: stub
Current DNS Server: 1.1.1.1#cloudflare-dns.com
Fallback DNS Servers: 1.1.1.1#cloudflare-dns.com 8.8.8.8#dns.google 9.9.9.9#dns.quad9.net 1.0.0.1#cloudflare-dns.com 8.8.4.4#dns.google 149.112.112.112#dns.quad9.net 2606:4700:4700::1111#cloudflare-dns.com 2001:4860:4860::8888#dns.google 2620:fe::fe#dns.quad9.net 2606:4700:4700::1001#cloudflare-dns.com 2001:4860:4860::8844#dns.google 2620:fe::9#dns.quad9.net
Link 50 (enp199s0f4u1u4)
Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6
Protocols: +DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: 192.168.5.1
DNS Servers: 192.168.5.1
Default Route: yes
Link 49 (tailscale0)
Current Scopes: DNS
Protocols: -DefaultRoute -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: 199.247.155.53
DNS Servers: 199.247.155.53 2620:111:8007::53
DNS Domain: tail91ecf.ts.net ~ts.net
Default Route: no
Link 2 (enp196s0)
Current Scopes: none
Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
Default Route: no
Link 5 (wlan0)
Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6
Protocols: +DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: 192.168.5.1
DNS Servers: 192.168.5.1
Default Route: yes
| 13:50:39 |
