IPv6 的 link-local 地址只在同一链路/网段内有效，因此同一个 fe80:: 地址还要靠 zone identifier（例如 %eth0）说明“是哪块接口”。2013 年的 RFC6874 试图把这种写法纳入 URI/URL 语法，并要求把 % 再 percent-encode 成 %25，所以常见形式会变成 http://[fe80::4%25eth0]/。但后来 RFC9844（2025）又废止了 RFC6874 的 URI 处理建议，认为浏览器实现者觉得这种语法不可行，只保留更泛化的 UI 处理原则。评论区还把问题延伸到 Go 的 net/url、os 级解析、rsync、shell 和 Windows UNC 等实际工具，说明争议不只在标准文本，而是在各层软件如何一致处理这些地址。
很多评论集中火力吐槽 IPv6 zone identifier 写进 URL 之后的编码规则。RFC6874 要求把 zone id 里的 % 再转成 %25，于是像 http://[fe80::4%25eth0]/ 这样的形式看起来又长又别扭。随后 RFC9844 又把 RFC6874 废掉，理由是浏览器实现者认为这种 URI 语法根本不现实，这等于把问题重新丢回模糊状态。大家还担心 % 本身就是转义符，多个解析/解码层叠在一起后，究竟该解几次已经没人说得清。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7] [来源8]
有评论指出，link-local 地址并不是纯粹的怪设计，在无路由器或只靠单机接入的场景里很有用。比如给 smart device 做 provisioning、在 cloud 环境里直接连设备、或者根据序列号和 MAC 通过 IPv6 找到设备后再单独配置 IPv4，这些都被提到是现实用途。也有人反驳说，配置良好的网络通常根本不需要它们，DNS 或 ULA（Unique Local Address）往往更实用。争议的核心是：fe80:: 这种地址会一直存在，而且还需要 zone id 才能知道它属于哪块网卡，这种“地址本身不够用”的感觉让人很不适应。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7] [来源8] [来源9]
不少人抱怨真正麻烦的不是 IPv6 地址本身，而是它进入日常工具后引发的一串兼容问题。URL 里用方括号区分 host 和 port，本来是为了解决冒号冲突，但这又和 shell 的文件名展开、rsync 用冒号分隔 host/path 等语法撞车。有人举例说在 macOS 旧版 rsync 上写 'user@[fe80::4]:/tmp' 还得额外加引号，否则 shell 会先把方括号当成模式展开。Windows 那边甚至还有 UNC（Universal Naming Convention）式的 ipv6-literal.net 变通写法，说明各平台都在用自己的办法绕这个坑。
有评论直接把问题归结为 IPv6 的冒号太多、方括号太多，看着就不顺眼。有人想倒回用点号，但马上被指出那会和域名混淆，而且 16 字节地址如果硬写成点号形式会变得长得离谱、几乎不可读。也有人承认这些语法都是为了避免 host 和 port、地址和域名互相冲突，代价就是可读性和易用性变差。最后不少回复干脆用玩笑收尾：IPv6 很麻烦，甚至“computers were a mistake”都成了顺口吐槽。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6]
zone identifier（zone ID）: IPv6 link-local 地址后面附加的接口标识，比如 %eth0，用来说明该地址属于哪块网卡或哪个作用域。
link-local address: 只在本地链路内有效的 IPv6 地址，常见前缀是 fe80::/10，通常需要 zone ID 才能唯一指向接口。
percent-encoding: URL/URI 里用 %XX 表示保留字符的编码方式；这里的争议点是 zone ID 里的 % 还得先编码成 %25。
RFC6874 / RFC9844: 两份关于 IPv6 zone identifier 如何表示在 URI/URL 中的标准；RFC6874 曾规定 %25 写法，RFC9844 后来废止了前者的 URI 语法指导。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。