@anonex NAT6 的外网 IP 不是同一个嘛

@jousca 没有现成的方案，也不理解为啥有这种需求。
可以给个思路，比如通过指定容器的 MAC 来决定各容器的 EUI-64 后缀：
docker run --rm --net=macvlan01 --mac-address 00:11:22:33:44:55 busybox sh -c "sleep 5;ip addr"
理论上完全可以开几百个不同 IP 的 docker （可能会耗尽 IPv4 的内网 IP ）

看了眼 https://www.zxinc.org/lir/ ，IPv4 PA /24 差不多是 IPv6 PA /33 。如果简单按比例算，那 IPv4 /32 接近于 IPv6 /41 .

理想情况下，安全措施做到位，再分离 IP 的增益不是很明显。
但现状是，单就论玩 NAS 的，各种监听[::]、主机防火墙放开、弱密码甚至默认密码都不鲜见。即使有这方面的知识，也容易有侥幸心理或者不方便而无法做到完善。比如常见虚拟组网方案在不少场景还是不太方便，如果给亲友下载个东西总不能发个 tailscale ，宿主还是得暴露几个入站。
所以，IPv6 地址的隔离至少应能帮助一些人规避掉一个明显的攻击面。这个攻击面其实 IPv4 也有，但 IPv6 的防火墙配置更容易疏忽，而且利用 IPv6 超大的地址空间也能给出新的解决方案。

即便没被攻破也可能刺探到不少信息。试想以下流程：

1. 通过 tracker 获知用户 IP
理论上可以知道哪个 IP 在下什么种。

2. 扫描获得用户 IP 的端口分布
从开了什么服务可以对用户有一个初步的了解。

3. 通过 https 端口获得域名证书
直接 IP 访问有效的 https 口，成品 NAS 大概率返回的是域名证书，而且至少 UI 上没处可改 ssl_reject_handshake 。

4. 通过域名获得更多信息
NAS 的域名大概率是 DDNS ，这样就可以持续追踪，架空了 IPv6 随机可变的优势。即使现在主机固若金汤，也保不齐未来会出纰漏。域名本身还能进一步挖出更多信息，如果 beian 了更是一步实名。

@iniwex 前面已经讲过了，目的是分配一个独立的 IPv6 。

@jousca 防火墙只要是人配的就可能有失误。我的主机存在有入站需求的端口，即使防火墙正确、应用安全到位也可能有 0day ，即使没有被攻破从报文也能分析出很多信息。总之增加一个隔离没什么坏处。
这不是说只做本机防护不安全，而是说利用 IPv6 的特性有望更安全。

对于 IPv4 ，公网-私网在光猫转换：
部分光猫的端口转发、防火墙存在功能不足
层层 NAT 有时存在性能问题
软件的自动化开端口只配置下级路由，光猫还需手动处理

对于 IPv6 ，公网要光猫下发到每台机器：
部分无法正常、自适应下发前缀，自身获取的前缀长度也未必对
下级路由用穿透模式又会受限于光猫的功能，有的甚至连 DNS 都有问题
防火墙功能普遍缺乏

如果没有碰到上述问题，那路由模式也挺好

@endif0 Syncthing 最大的优势是可以在设备间同步，万一 NAS 挂了也不会彻底停摆
对 Syncthing 来说 NAS 的最大意义是时刻在线，保持版本一致，也方便做快照 /历史版本

self-hosted 设备开 80 、443

这下变成对管理员的图灵测试了

看起来像是具体产品的问题，不像是 AC+AP 方案的问题

不建议单纯依赖内网来保证安全

光猫在运营商原本配置下能否获得前缀？

如果没有其他读写竞争，应该不至于拖不动进度条。但故障率、性能、价格相比 3.5 寸都缺乏优势。

@Garrix 可以，但也只对懂行的人中的少部分人有必要