Tell HN：Hacker News 现已支持 IPv6

HN 启用 IPv6 与基础设施

• HN 现在通过 IPv6 提供流量；一些用户通过浏览器工具和直接的 IPv6 访问进行了确认。
• 站点曾短暂位于 Cloudflare 之后（例如在一次 DDoS 期间），这也可能提供了 IPv6；现在看起来又重新直接提供流量。
• DNS A/AAAA 的 TTL 设为 1 秒；有人推测这是为了负载均衡，但没有明确证据表明有多个 IP。
• 一些用户在切换后报告了连接问题，通常与配置错误的家用路由器或旧的 6to4 设置有关。

TLS 与协议支持

• HN 目前还不支持 TLS 1.3；据说此前的尝试因为在企业 TLS 拦截代理后面出现故障而被回滚。
• 有人认为应当在保留 1.2 的同时重新启用 TLS 1.3，因为如今大多数 MITM 设备都已支持它。

浏览器工具与扩展安全

• IPvFoo 扩展常被提及，用于快速显示 IPv4 与 IPv6 的使用情况。
• 围绕其“读取和更改所有网站上的数据”权限的讨论，引发了对扩展被接管、自动更新以及恶意买家的担忧。
• 建议的缓解措施包括：代码审查、侧载、禁用自动更新。

IPv6 地址空间、分配与子网划分

• 争论点在于“undecillions”数量的地址是否真的可能被耗尽。
• 对超大规模分配（例如把 IPv6 /16 分给单一公司）以及长期浪费的担忧；也有人质疑 RIR 政策与透明度。
• 对强制 /64 子网存在强烈分歧：一些人认为这是浪费并希望更小的子网；另一些人强调 /64 的技术原因（SLAAC、路由硬件、安全属性）。

运行行为：SLAAC、DHCPv6、家用网络

• 许多家用 ISP 只给 /64，这使多 LAN 组网更复杂；指南说 /56 或 /48 更合适。
• SLAAC（要求 /64）与 DHCPv6 之间存在张力；Android 不支持 DHCPv6 是一个痛点。
• 人们很难把自动配置的 IPv6 地址整合进本地 DNS；一些人使用 ULA、mDNS 或静态地址。

性能与延迟

• 普遍共识是：额外的报头字节对延迟影响可以忽略；差异主要由路由、NAT 和硬件决定。
• 多次引用（Google、Facebook）表明，由于路径更优且减少了 CGNAT，IPv6 的平均延迟往往低于 IPv4。
• 有些人报告了特定提供商的 IPv6 问题（例如有缺陷的固件、规模不足的 IPv6 基础设施）。

安全、NAT 与隐私

• 争论 IPv4 NAT 是否真的能显著提升安全性；几位用户指出，没有防火墙的 NAT 很弱，或很容易被绕过。
• IPv6 家庭网络通常使用有状态防火墙而不是 NAT；有些人担心暴露 IoT 设备，另一些人则强调超大的子网规模和默认阻止的防火墙。
• IPv6 隐私扩展（轮换地址）在一定程度上弥补了 NAT“隐蔽性”的丧失，但通过其他手段进行跟踪仍然存在。

采用、用户体验与对 IPv6 设计的批评

• 支持者赞赏端到端寻址、更简单的 homelab DNS（LAN/WAN 使用同一地址）、使用十六进制更容易做子网计算，以及消除 hairpin NAT。
• 怀疑者认为 IPv6 使防火墙、DNS 和多 LAN 家庭网络更复杂，并且在 IPv4 仍然可用时没有明显收益。
• 许多人不喜欢地址表示法，觉得输入/记忆 IPv6 很痛苦；也有人反驳说应该使用 DNS 和 mDNS。
• 反复出现的“带更多八位组的 IPv4”提案被批评为技术上站不住脚，本质上是在重新制造当前双栈的复杂性。

迁移策略与 IPv4 的未来

• 一些人认为 IPv6“失败”了，因为它既没有消灭 IPv4，也没有完全解决地址耗尽；另一些人则认为双栈是必要的，而 IPv6 已经在减少对 IPv4 的需求（例如 IPv6-only 服务器、移动网络）。
• 预期 IPv4 会 धीरे慢地变成遗留技术：更多 IPv6-only 服务、IPv4 位于 NAT64/4-in-6 之后，最终 IPv4-only 用户的体验会变差。
• 一些长期运维人员指出，核心互联网协议演进非常缓慢，并认为拖累 IPv6 普及的主要不是技术，而是商业和运营惯性。