DDNS 的本质就是通过 API 更新 DNS 记录。只要能获取到地址、构造 API 请求，自然就不成问题。

如果是混凝土墙，5GHz 信号还是不好说。

@hello365 站点没跑路？

@malash --mac-source 可以指定外网入站内网设备的 MAC 么？

合规的情况下推荐 Syncthing （双端同时在线）

丢包率如何

阿里云开个按需计费的服务器不就行了

捐进不考虑？

运营商给的前缀是动态的，更新周期各地不同，慢的可达一个月。如配置正确，机器自身的 IPv6 地址即是公网。

@malash 感谢你提供的信息，“关注点分离”是值得留意的。传统网关是路由+防火墙，在 IPv6+移动互联网的当下，个人认为终端与网关应该在防火墙层面进一步解耦。IPv4+NAT 的方案不少可以照搬到 IPv6 ，但看到 NAT 时代搞出来的各种麻烦事居然还要在 IPv6 时代延续，我还是感到十分头疼。具体的麻烦就不再复述了。本文是想提示大家，不一定要沿袭过去的做法，活用 IPv6 的新特性也是一条可能的方向。

白群内网穿透有中国大陆的节点

@neroxps 现在广泛售卖的路由器能匹配后缀的不多。现代操作系统有的后缀是会跟着前缀变的，需要关掉隐私扩展。NAT 时代的自动化端口映射大多不兼容 IPv6 ，例如 PCP 在网关和应用的支持都比较少，所以开端口基本就要手动。

@malash 一机多 IP 是针对 PC 、NAS 等现代操作系统场景。我没有建议在家庭场景监听指定的 IP 。简单的物联网设备没有服务间隔离的问题，也不太会随便主动外访，默认的 SLAAC 一般就行了。
内网一般就指局域网，你指的可能是可公网入站和仅内网入站，但重新定义概念恐怕会引发混乱。防火墙的低支持度、需要固定后缀、自动化打洞等问题和可移动设备接入外部网络的风险我就不再赘述了。至少对我来说，如果有防火墙可根据 MAC 地址来配置，才会觉得比较方便。

@jobmailcn 其实文中已经提过，例如内网设备要开 bt 、ipfs ，这些软件能知道你设了个 frp 么？是不是也要配置一番，除非 All in 网关。但如果很在意安全性，在网关监听外网端口反而不推荐。因为网关是整个内网较容易被发现的设备，如果网关自身的入站端口有安全弱点，同时下属设备都假设内网的安全性，那恐怕更加危险。

@mxT52CRuqR6o5 以上设置的初衷是防止应用暴露主机 IP ，导致主机上其他有弱点的入站端口被发现，所以安全性提升是有的。沙箱是防止应用的端口被攻陷、获取高权限后在主机侵染其他应用，这是另一层面的安全性。

一处笔误：NAP → NDP

楼里提了很多其他软件，如果楼主觉得自己的解决方案更胜一筹，不妨用后做个详细对比

@jyeric 同一主机内为不同应用单独分配 IPv6 是一个值得研究的问题，目前比较成熟的经验还比较少。
对于服务端场景，可以沿用多 IPv4 主机的经验，例如在写端口监听时直接指定 IPv6 地址。
对于应用端场景，我能想到的做法主要还是虚拟化。例如 VMware 下开的虚拟机，设为桥接模式就会获得与主机不同的 IPv6 地址，从而实现分离。对于 Docker 来说固定前缀比较好配，动态前缀可能需要依赖脚本，例如 https://github.com/wido/docker-ipv6 （未验证过）。

所谓“IPv6 扫不到”是跟 IPv4 相比的。在 IPv4 下，扫遍全网是可行的。如果常用端口配置薄弱，分分钟就被人端了。IPv6 地址空间非常大，除非掌握很具体的信息，扫段几乎是不现实的。

楼主指出 IPv6 可能通过应用主动暴露，这个风险是真实存在的。安装各类应用的设备，主要是有用户操作的（ PC ）或者本来就面向外网的设备（ NAS ），这些设备基本都有安全机制。即便没有，攻击面相比公网 IPv4 还是小很多，攻击的实现和范围受到很多限制。就像是在 IPv4 下的 DMZ 主机，很多人把常用端口调到非标准端口就完事了。尽管十分草率，但被攻陷的概率也会小很多。

当然，更高的安全性是值得追求的。个人认为 IPv6 时代的不应该继续假设内网是安全的，而应该基于“零信任”，做好机器本身的安全防护和验证。特别是对于经常移动的设备，它们的上级网关本来就不可控，虚幻的安全感可能反而导致翻车。如果还是担心，也可以借助 IPv6 超大地址空间的优势，给 bt 、ipfs 这类应用分配独立的地址（如虚拟机），从而仅把安全的的、与敏感数据隔离的服务暴露给外部。