| 17 May 2026 |
 emily | (relatedly, what's the state of the art for NAT64 at this point? did that NetworkManager etc. stuff or the kernel-space stuff happen?) | 16:03:18 |
 hexa | pcp is something your isp would need to support | 16:03:20 |
| hexa | nm nat64 support did not land in the current release | 16:03:37 |
| hexa | it will land in the next | 16:03:40 |
| emily | in this situation I'm imagining the gateway/router doing the NAT64 | 16:04:36 |
| emily | so it has a public v4 | 16:04:41 |
| emily | question is, how can clients ask "give me an exposed v4 port that forwards to this port on my v6, thanks" | 16:05:01 |
| hexa | I only tried jool so far, and I don't think it supports pcp | 16:05:02 |
| 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 |
