系统与基础设施apenwarr.ca
IPv6 曾是一个好设计的那个世界
The world in which IPv6 was a good design (2017)
2019 — 2020，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
Avery Pennarun（apenwarr）这篇文章回顾 IPv6 的设计前提：它诞生于一个假设地址稀缺、端到端直连有价值的"世界"，但真实互联网走向了 NAT、中间盒和覆盖网络，所以 IPv6 的许多设计理由在事后看并不成立。文中还讨论了 IP 与以太网的分层、ARP 的作用，以及移动性等需求其实用 IPv4 加 NAT 也能实现（作者自己在勘误中承认）。
为什么经久不衰：它把"协议设计与其时代假设"的关系讲得很清楚，是理解 IPv6 为何迟迟难以普及、NAT 与端到端之争的经典长文，多年后仍常被引用和辩论。
HN 评论精选
不同意文章前提，认为覆盖网络会让 IPv6 无关紧要，并用亲身经历为 ARP 与以太网辩护。
好文，我在这上面花的时间和 Avery 差不多久，很遗憾第一次它上首页时错过了。本想在这里写长篇回应，还是留到博客里（简短版：我强烈不同意我所理解的文章前提，认为人们不该等 IETF 批准才能构建新的网络层，相当确信不存在所谓的"分层违规"，并认为覆盖网络现在/最终会让 IPv6 变得无关紧要）。所以在这个帖子里我只挑些小毛病。以太网并不像文章写得那么糟糕，ARP 也不是毫无意义！比如 1990 年代我做技术负责的 ISP，靠一个简易的代理 ARP 策略路由器，就把数据中心和公司办公室在芝加哥市内搬迁而无需重新编址；IP 纯粹主义者会反对说我们没按上帝的意思用 OSPF，但它能用，而且可能比后来替换它的正规路由协议更可靠。
tptacek查看英文原文
What a great post, about something I've been working on almost as long as Avery. I'm sad I missed it the first time it came around. I was going to write a long response here, but I think I'll save that for a blog post (short summary: I disagree vehemently with what I believe the premise here to be, think that people shouldn't be waiting for the IETF to give them permission to build new network layers, am fairly certain there's no such thing as a "layering violation", and think overlay networks are/will-ultimately make IPv6 irrelevant). So on this thread I'll just pick some nits. Ethernet networking is not as gross as it's made out here. ARP isn't entirely pointless! For instance, at the ISP I ran tech for in the 1990s, I was able to pretty seamlessly move our "data center" and corporate offices across Chicago without renumbering just by exploiting ARP (I wrote a dumb proxy ARP policy router). We did similar things to route traffic to the particular terminal services customers were dialing into, or to the ISDN router who's PRI happened to service a particular customer. An IP purist would object that we weren't using OSPF the way God intended us to, but it worked and was probably more reliable than the bona fide routing protocols we replaced that with. This narrative also, I think, gives short shrift to DHCP, which does a lot more than pick IP addresses out for new endpoints, but also pretty much fully configures their IP connection. If you had to tech support 10,000 random customers in the era before DNS servers were transparently assigned at connection, you're not pining for the simple elegance of RARP. Also: nobody should care about "IGMP-snooping bridges", since IP multicast is and always was hopeless.
NAT 的状态维护成本被低估，IPv6 的分层无状态路由才是真正价值。
作者后来加的勘误说"本节其实不需要 IPv6，用 IPv4 加 NAT 也能跑"，这不太公平。IPv4 加 NAT 需要在关键中间路由器上维护大量状态，大家大概都遇到过 NAT 路由器重启丢状态、状态表溢出之类的问题。IPv6 唯一绝对的价值是 128 位地址让路由可以保持更分层、更无状态；虽然因为我们现在给 IP 地址附加信任度（多亏垃圾邮件发送者），地址碎片化会发生，但 IANA 和主要 ISP 能让这个过程足够慢，让软硬件能力跟得上。这解决不了移动性问题，但为移动性方案提供了很大好处，别低估 NAT 带来的系统复杂度成本；IPv6 目前那些不必要的复杂性也会随时间简化。
wahern查看英文原文
> Edit 2017-08-16: It turns out that nothing in this section requires IPv6. It would work fine with IPv4 and NAT, even roaming across multiple NATs. That's not quite fair. IPv4 and NAT require maintaining a lot of state at critical intermediate routers. I'm sure we've all experienced (perhaps regularly) a NAT'ing router losing state because of a reboot, state tables overflowing, or similar hiccups. The one absolutely redeeming quality of IPv6 is that with 128 bits routing can be kept much more hierarchical and stateless. Fragmentation will occur and is occurring because we now apply trust metrics to IP addresses (thanks, spammers!) so there's value in owning transferable subnets, but I think IANA and major ISPs can keep the fragmentation process slow enough that hardware/software capabilities can stay apace, preserving a largely stateless, hierarchical routing infrastructure. That doesn't solve the mobility problem, but it does provide significant benefits to mobility solutions. Don't underestimate the cost of NAT'ing in terms of systems complexity. NAT'ing isn't the type of layer, like ethernet MAC addressing, that we'll always be stuck with. It's also worth pointing out that some of the [now] unnecessary complexity of IPv6 will fall away over time. IPv6 will get simpler as time progresses, as it already has.
IPv6 本身不复杂，痛苦来自被迫双栈；"IPv4 加地址位"才是最糟方案。
我不觉得 IPv6 复杂，它比 IPv4 更容易理解，而且基本是开箱即用。我的经验里困难只来自一件事：你几乎永远无法纯用 IPv6，总得双栈，而 IPv4 加 IPv6 一定比只用 IPv4 复杂。我曾有机会在纯 IPv6 环境里做方案，用起来很愉快：不用担心子网大小，也不用担心和第三方工具撞地址段。至于"要是当初只给 IPv4 加更多地址位就好了"，我实在不理解：那会带来 IPv6 的所有问题（必须确保所有软硬件都支持新的不兼容格式），却拿不到它的任何好处，是真正的两头不讨好。NAT 大概是最佳折中，用端口号勉强扩展地址信息，但显然是丑陋且有诸多限制的权宜之计。
simias查看英文原文
I don't find IPv6 complicated, if anything it's a lot easier to grasp than IPv4 and it basically comes with batteries included. The difficulty in my experience stems from one thing and one thing only: you can almost never go full IPv6. You always have to dual stack IPv4/IPv6, and of course IPv4 + IPv6 is always strictly more complicated than just IPv4. I've had the opportunity to develop a solution using an IPv6-only environment and it was a pleasure to work with. No need to worry about the size of your subnets or clashing with 3rd party tools using the same address space etc... >Wouldn't it be better if it had just been IPv4 with more address bits? I often hear that but I genuinely don't get it. This change would effectively give you all the problems with IPv6 (i.e. you have to make sure all your hardware and software equipment can deal with the new, backward-incompatible format) without all the niceties that IPv6 provides. It's genuinely the worst of both worlds. NAT is probably the best compromise you can get, using the port number to sort-of extend the address information to identify several computers with the same IP, but it's obviously an ugly hack with many limitations.
IPv6 的端到端理想是错误方向，应拥抱 NAT 的不对称性并改进它。
在我看来，IPv6 那个完全点对点互联的梦想才是走错了路，他们本该顺着 NAT 走。NAT 之所以好，是因为它充当外部网络的抽象层：本地节点彼此通信，完全不必关心外部网络的细节。而且大多数本地网络在本地与外部之间本就存在根本的不对称：大多数节点只需要连出去，不需要被连入。128 位地址基本上让 DNS 变成必需品，而用 DNS 时没人在意主机的地址，只想能连上对面。完全点对点是不切实际的幻想：没人愿意自己的整个本地网络不加防火墙就暴露给整个互联网，而有了防火墙，就又回到和 NAT 一样的打洞问题。所以他们该做的是拥抱 NAT 和这种不对称，并想办法改进它，而不是试图消灭它。
magicalhippo查看英文原文
To me it feels like the IPv6 dream of a fully peer-to-peer connected network was the wrong turn. Instead I think they should have rolled with NAT. NAT is great because it acts as an abstraction layer for the external network, in that the nodes on the local network can talk to each other and be blissfully ignorant of the details of the external network. And for the majority of local networks there's a fundamental asymmetry between the local and external network. The majority of nodes on local networks only ever need to connect _out_ to the external network, they don't need incoming connections. Going to 128bit addresses essentially makes DNS required. And when using DNS nobody really cares about the address of the host. They just want to be able to talk to the host on the other end, whatever it is. Being fully peer-to-peer is a pipe dream. Nobody wants their entire local network exposed to the entire internet without a firewall. And with a firewall comes the exact same hole-punching problem that NAT has. So that's the problem they should have tried to solve better, I think. They should have embraced NAT and the inherent network asymmetry, and found ways to make it better rather than trying to abolish it. Embraced that DNS needs to play a more central role than it does today, because nobody really cares about addresses.
历次讨论
同类还值得读
TTY 揭秘（2008）
The TTY demystified (2008)
经典文章深入剖析了 Unix/Linux 中 TTY 子系统的工作原理，包括线路规程、终端驱动、信号与控制字符等机制。
系统与基础设施上首页 11 次 · 2009–2025linusakesson.net编辑精选为什么 GNU grep 这么快
Why GNU grep is Fast
FreeBSD 邮件列表上一篇广为流传的帖子，解释 GNU grep 为什么快：核心在于 Boyer-Moore 字符串搜索算法配合精心优化的内部循环和 I/O，让程序在搜索时“…
系统与基础设施上首页 9 次 · 2010–2022lists.freebsd.orgXplain：为普通人讲解 X11
Xplain – Explaining X11 for the rest of us
《Xplain》是作者（HN 用户 Jasper_）写的一系列 X11 长文，用他在浏览器中重建的 X11 绘图模型做交互演示，讲解 X11 的绘图模型与窗口系统设计。
系统与基础设施上首页 6 次 · 2013–2020magcius.github.io编辑精选旋风教程：为 Linux 创建极小 ELF 可执行文件（1999）
A Whirlwind Tutorial on Creating Really Teensy ELF Executables for Linux (1999)
breadbox 写于 1999 年的经典教程，主题是如何为 Linux 手工构造并裁剪出体积极小的 ELF 可执行文件。
系统与基础设施上首页 6 次 · 2007–2025muppetlabs.comPostgreSQL 内部原理
The internals of PostgreSQL
《The Internals of PostgreSQL》是一本免费在线书籍，系统讲解 PostgreSQL 的内部实现，包括查询处理、并发控制、WAL、缓冲区管理等核心机制。
系统与基础设施上首页 5 次 · 2017–2025interdb.jp编辑精选