把服务放在封闭的内网是一种牺牲便捷性、比较偷懒的方法。但之所以这么多人推荐，正是因为其简单、有用，可以避免 IPv4 最普遍的暴力端口扫描等风险。
Gitlab 的设计初衷肯定是面向公网的。但既然面向公网，维护者就要做好相应的安全措施，而不是明知存在隐患还有侥幸心理。
权益和义务是对等的。开源免费的大型项目能及时修复无心之失的漏洞，对免费的使用者而言就已经尽到了义务。
选用小众的项目，安全性未必提升，可能反而下降。

可以参考这类监控网站 https://ping0.cc/

@cwek 还是没看出来，这相比公网 IPv6+防火墙的方案有什么额外的好处？

@ggp1ot2 关键是 NAS 的安全配好，比如设好防火墙，或者配个证书用 HTTPS 连接。楼主家的其他设备，比如电视，它应该也不会没事去访问恶意网站，除了内网只有服务商和 ISP 知道它的公网 IPv6 。至于手机，现代操作系统的安全防护也足够了。毕竟手机连流量和公共 WIFI 的时候不可能再去装个防火墙。

IPv6 是 SLAAC 的话内网设备风险不大，至于路由器本身可以扫一下看看有没有开放的端口

这家是怎么做到比运营商自己 App 的提速功能便宜这么多的

@cwek 如果需要第三方借助打洞、或者不停包发保活，想做到低能耗低延时是困难的。对外连接总是有风险，但我前面也论述了，IPV6 下外网直连的攻击面会小很多，相比之下设备自身的风险更加凸显。我还不是太理解你的方案，增加了前缀转换的步骤，能提供什么防火墙给不了的功能？

@cwek 我觉得这样可能不太好，会增加物联网设备跨子网联动的复杂度和延迟

@abc8678 “手中的设备的 IPv6 地址” “是 ipv4 在访问我。我明明没有 ipv4 的公网”

@abc8678 我的群晖自从没了公网 IPv4 以后，仅有公网 IPv6 就没出过什么日志。看了下你发的其他帖子，还是建议去调查你 NAS 的地址是怎么被捅出去的。否则要么惶惶不可终日，要么使用非常不便，难以兼顾。

@baobao1270 我是觉得 NAT 反而让大家习惯于“安全”的内网，一定程度上忽视了终端安全的建设。这样在终端移动到陌生网络或在网关配置失误时反而会出现更大的危险。

自动化端口暴露的需求还是广泛存在的，要穿越的就是 ip6tables 。

家用场景的前缀总是会变，本来就要适配动态的 IP 报告机制，所以在这里我不当作“长期固定”。当然你表达的可能是“后缀长期固定”。正如前面所说的，在端口暴露自动配置机制还不怎么可用的现在执行白名单防火墙，配置的复杂度过高但安全提升不那么明显，对于有一定网络知识的用户也很折腾，不应该是推荐的最佳实践。所以我认为用户不必过于指望家用路由具有 v6 防火墙高级功能，但厂商把更多底层做成 UI 供高级用户选用，我并不反对。

大众使用 SLAAC 、喜欢折腾使用 DHCPv6 的分法我觉得可能不太合适。喜欢折腾的人家里还是有不参与到折腾的人和设备，统一改成 DHCPv6 反而削弱了隐私扩展，更何况还有故意不支持 DHCPv6 的 Android 。如果家里没有这样的设备，全部都是服务端，那直接固定后缀应该就可以了。当然，这种场景一般会用企业级路由器，也超出了本帖的讨论范围。

@v2tudnew
我也是因为曾经想沿用 IPv4 的经验，发现配置异常繁琐才产生如此见解的。比如主帖里提到的“可以根据终端 MAC 自动配置的方案”，就是曾经试图寻找但未能实现的尝试。
只不过面临这样的困难，你我设想的路线不同。你的设想是强化私网与广域网的屏障，构造一个安全的内网，通过更多功能改善用户的体验。我的设想是取消网关上的安全边界，按照公网的标准防范，通过 IPv6 的隐私扩展和强化终端的建设来维护安全。现况与这两个设想都有一定的距离，未来会怎么发展，也只能交给时间了。

@v2tudnew 当然，你的见解也具有启发性。可以设想未来有一天，路由器和各类应用都广泛支持 PCP 机制，用户无需手动添加例外同时又可以进行管理，那默认禁止入站会是一个更优的选项。在这一天到来之前，我还是觉得有一个 IPv6 防火墙总开关就够了。

@v2tudnew 没有绝对的安全，我的举例是在说明安全和方便的取舍问题
Windows RID 劫持是公网暴露端口就能被利用的漏洞么？我在说的是能使公网回访攻击产生危害漏洞出现的概率。我不是开发者，只是在实践中产生了对 IPv6 的防火墙策略的见解。

最后这个问题没看懂，什么叫“需要用户配置 IP 地址”，我什么时候提出过这个需求？

@v2tudnew
对，是可以 UDP 打洞，只不过各环节都要增加复杂度。比如在 BT 中，就需要一个没有防火墙的 peer 做中介。（ https://libtorrent-discuss.narkive.com/HqyhMO7B/libtorrent-does-libtorrent-support-hole-punching ）如果大家都指望打洞方案，那可连接性就可想而知了。
顺便一提，NAT-PMP 有支持 IPv6 的后继者（ Port Control Protocol ），但不太清楚目前路由支持的情况。

参考之前的永恒之蓝，微软已经发更新之后 WannaCry 才开始传播，而且主要是内网扩散。IPv6 回访攻击要能实现，对漏洞的要求应该更高。相比之下，防止应用程序漏洞的作用倒相对大一点。如果某程序开了没有限制来源的公网访问端口、通过了系统防火墙的许可、出现了未修复的危险安全漏洞、没有配置打洞机制或防火墙例外，同时用户主动访问的网站或中间的网关被攻击者掌握，且攻击者进行了扫描并正好知道这个漏洞，那有白名单防火墙会更安全。
我的意思是说，网关白名单防火墙的方案对用户和开发者增加了太多复杂性，但提升的安全性不大。操作系统的防火墙依然存在，所以掀屋顶的比喻不是很恰当，要我看更像是把围墙拆了变街区。

你提公共 WIFI 的场景我有点不理解。如果你在考虑把设备放置于陌生网络中的风险，那更应该加强设备自身的防护（零信任思想），而不是依赖网关来营造“安全”的边界。

@v2tudnew 主动暴露端口通过 IP 才能访问并不等于 DDNS ，例如 BT 、IPFS 、通话、对战等产品也用得上，不一定是专业级需求。
UPnP 和 NAT-PMP 是安全和便利性权衡的经典案例（ https://docs.netgate.com/pfsense/en/latest/services/upnp.html ），这表明自动配置端口的需求是广泛存在的，为此可以牺牲一点安全性。
用户访问恶意网站被回访，然后被攻陷的可能性当然存在。对于应用程序级的高危漏洞，如果已经存在 IPv6 时代的类 UPnP 机制，那也可能会被自动放通而中招，网关有没有防火墙可能区别不大。
至于操作系统的高危漏洞，这一般是大新闻（如永恒之蓝），有很多限制条件（比如 Win 防护墙 445 的入站规则限定为本地子网），会很快发布升级补丁。未公开的 0day 不太可能攻击普通用户。而且恶意网站的攻击需要有主动访问恶意网站的行为，不像 IPv4 那样会“躺枪”。所以我觉得风险是可控的，并不是为了方便而忽视危险的极端。
我主帖已经提到，服务端场景下 IPv6 地址是长期固定的。加之地址会被 DNS 公开，有一个高级的网关防火墙还是有意义的。

@v2tudnew
Win 的防火墙好歹还需要同意，UPnP 这种开了以后就是自动配的。你觉得开发者就不应该去管路由器防火墙，但是用户用不了首先会找开发者而不是路由器。即使 IPv6 支持比较好的那些路由器，想让普通用户简单学会也称不上容易，用户搞不懂说不定还是全部关掉了事。

安全与便利是一对矛盾，如何取舍需要智慧。我发本帖的目的在于指出，在 IPv6 下端口暴露被攻击的风险大大降低，而正确配置防火墙的门槛比 IPv4 NAT 还要高，否则很多 IPv6 的优势就无法发挥。对于家庭的应用场景，默认放通入站相比默认拒绝设置例外，对开发者和用户来说都是更好的权衡。在 IPv6 下还要搞防火墙，是不信任硬件自身的防火墙，所以再加一道额外防护措施的小众专业级需求，我觉得不应该成为通行做法。当然，各位分享自己的权衡考量，也有助于大家做出更好的判断。

@v2tudnew 监听端口向用户请求授权可以在操作系统内实现，比如现在的 Windows Denfender Firewall 。
IPv6 的高级防火墙即使存在，家庭用户中也只有很小的比例会配置。IPv4 时代的自动端口规则协议大多不适用 IPv6 ，即使未来出现了，那还要考虑不同路由厂家的支持情况、如何配置多级路由等。可以说 NAT 的老毛病很多都回来了。
IPv6 下的打洞相比 IPv4 NAT 确实会简单一点，但作为开发者，肯定还是希望少碰到这种事情。

@loopinfor 这就是我说的“主动访问被探测并发起回访”，也是隐私扩展提出临时 IPv6 地址的原因。

@delpo 典型的服务端需求建议用固定地址，典型的客户端需求建议用动态地址。但是还存在很多客户端需求比如 BT 、Sync 、VoIP 、PS4 ，他们既需要放通端口以提供便利，又可能有隐私顾虑不宜长期固定。家庭宽带的前缀本来就是会变的，如果不是要配置防火墙白名单，后缀的变动本来也不会增加多少问题。路由设成 DHCPv6 不是很推荐，因为地址空间小、安卓设备可能获取不了 IPv6 等，还不如直接固定后缀。

@LnTrx 更正：Windows 默认采用的是 RFC4941 的方案，地址随机但相对稳定。部分 Linux 类操作系统默认用的是 RFC7721 ，会随着网络环境（如前缀）而变化。