以太网封装往事

注：机翻，未校对。

以太网封装往事

Henk Smit conscientiously pointed out a major omission I made when summarizing Peter Paluch’s excellent description of how bits get parsed in network headers:
Henk Smit 认真地指出了我在总结 Peter Paluch 对如何在网络标头中解析位的出色描述时所做的一个重大遗漏：

EtherType? What do you mean EtherType? There are/were 4 types of Ethernet encapsulation. Only one of them (ARPA encapsulation) has an EtherType. The other 3 encapsulations do not have an EtherType field.
以太类型？EtherType 是什么意思？有 4 种类型的以太网封装。其中只有一个（ARPA 封装）具有 EtherType。其他 3 个封装没有 EtherType 字段。

What is he talking about? Time for another history lesson [1].
他在说什么？是时候再上一堂历史课了 [1]。

Ethernet started as a bit of a science project [2]at the center of “just good enough” mentality sometimes known as Silicon Valley. To keep things simple, it used:
以太网最初是一个科学项目 [2]，处于 “足够好” 的心态中心，有时被称为硅谷。为了简单起见，它使用了：

• A preamble (to synchronize sender’s and receivers’ clocks)
  前导码（用于同步发送方和接收方的时钟）
  

• A start frame delimiter (to tell everyone to really start listening)
  起始帧分隔符（告诉每个人真正开始听）
  

• Source and destination MAC addresses
  源和目标 MAC 地址
  

• 2-byte field identifying higher-layer [3] protocol
  2 字节字段标识更高层 [3] 协议
  

• Payload
  有效载荷
  

• Frame Check Sequence
  帧检查序列
  

  The 2-byte field I mentioned above is called EtherType. ARPA encapsulation is a Cisco-speak for original Ethernet encapsulation, which could also be called DIX [4] Ethernet, or (probably most correctly) Ethernet II framing because the latest version of DIX Ethernet specification was Version 2, published in November 1982. After that, IEEE finally got their act together – it took them almost four years to “standardize” a shipping technology.
  我上面提到的 2 字节字段称为 EtherType。ARPA 封装是 Cisco 对原始以太网封装的称呼，也可以称为 DIX [4] 以太网，或（可能最正确） Ethernet II 框架，因为最新版本的 DIX 以太网规范是 1982 年 11 月发布的第 2 版。在那之后，IEEE 终于齐心协力 —— 他们花了将近四年的时间才 “标准化” 一项运输技术。
  

  Anyway, you might have noticed there’s something missing in the above list of Ethernet frame parts – there’s no end-of-frame delimiter. How do we know we got a valid frame? Remember the “just good enough” approach? Here’s how it works:
  无论如何，您可能已经注意到上面的以太网帧部件列表中缺少一些东西 —— 没有帧结束分隔符。我们怎么知道我们得到了一个有效的框架？还记得 “足够好” 的方法吗？其工作原理如下：
  

• Original shared-medium Ethernet (10BASE5 and 10BASE2) uses Manchester coding with a transition at the middle of each bit. If there’s no transition, the sender obviously stopped sending.
  
  原始共享介质以太网（10BASE5 和 10BASE2）使用曼彻斯特编码，每个位中间都有一个过渡。如果没有转换，发件人显然已停止发送。
  

• As the receiver is collecting bits into an incoming frame, it’s continuously calculating the Frame Check Sequence.
  当接收器将比特收集到传入帧中时，它会持续计算帧校验序列。
  

• If the receiver perceives the sender stopping at a byte boundary, and the calculated FCS matches the “verify value”, the receiver believes it got a valid frame.
  如果接收方察觉到发送方在字节边界处停止，并且计算出的 FCS 与 “验证值” 匹配，则接收方认为它得到了一个有效的帧。
  

  That was obviously not good enough for IEEE purists [5], but it’s hard to argue with shipping products when a competing standards body starts to standardize what you’ve been pondering for years, so they reached a “compromise”[6]:
  对于 IEEE 的纯粹主义者来说，这显然还不够好 [5]，但是当一个相互竞争的标准机构开始对你多年来一直在思考的东西进行标准化时，很难与已经发布产品争论，所以他们达成了 “妥协”[6]：
  

• Ethernet will retain it’s good-enough physical layer
  以太网将保留其足够好的物理层
  

• IEEE version of the Ethernet will have a belt-and-braces length field after the MAC addresses to verify that the frame truly has the right length.
  IEEE 版本的以太网将在 MAC 地址后有一个带括号长度字段，以验证帧是否确实具有正确的长度。
  

• EtherTypes will use values above 1500, so it will be evident whether we’re dealing with IEEE encapsulation or Ethernet II encapsulation[7].
  EtherTypes 将使用高于 1500 的值，因此我们处理的是 IEEE 封装还是 Ethernet II 封装 [7] 将一目了然。
  

  To be fair, there’s a better reason for the length field. Ethernet frames have a minimum length of 64 bytes[8]. Not a big deal – add padding to your protocol. Well, IBM didn’t like that argument; they wanted to keep sending SDLC/HDLC frames over LAN networkss[9].
  公平地说，长度字段有更好的理由。以太网帧的最小长度为 64 字节s[8]。没什么大不了的 - 在您的协议中添加填充。好吧，IBM 不喜欢这种说法；他们希望继续通过 LAN 网络发送 SDLC/HDLC 帧 s[9]。
  

  Anyway, at that point we still had a simple decision to make:
  无论如何，在这一点上，我们仍然有一个简单的决定要做出：
  

• Is the 16-bit value after MAC addresses higher than 1536s[10]? Must be an EtherType.
  MAC 地址后的 16 位值是否高于 1536 s[10]？必须是 EtherType。
  

• Otherwise, it’s an IEEE 802.2 packet.
  否则，它是 IEEE 802.2 数据包。
  

  OK, but what’s riding on top of an IEEE 802.2 packet? IEEE’s first idea was to take the OSI stack and put it on top of LAN networks – every packet would have a Source Service Access Point (SSAP) and Destination Service Access Point (DSAP). Why would you need two? Would IP stack ever send a packet to OSI stack? Of course not, but that’s what you get with an academic layered approach.
  好的，但是 IEEE 802.2 数据包之上有什么呢？IEEE 的第一个想法是将 OSI 堆栈放在 LAN 网络之上 - 每个数据包都有一个源服务接入点（SSAP）和目标服务接入点（DSAP）。为什么需要两个？IP 堆栈是否会向 OSI 堆栈发送数据包？当然不是，但这就是你通过学术分层方法得到的。
  

  There was just a bit of a hurdle: tons of companies were interested in Ethernet connectivity in those days, and all of them had proprietary protocols (just look at the reservation ranges for IANA IEEE 802 numbers), but there were only 128 available SAP numberss[11]. In a wonderful application of RFC 1925 Rule 6a, IEEE reserved SAP value 0xAA to mean SNAP Extension which really means we just wasted 6 bytes to tell you to look at the EtherType that follows.[12]
  只是有一点障碍：当时有大量公司对以太网连接感兴趣，而且它们都有专有协议（只需查看 IANA IEEE 802 号码的预订范围），但只有 128 个可用的 SAP 号码[11]。在 RFC 1925 规则 6a 的精彩应用中，IEEE 保留了 SAP 值 0xAA 表示 SNAP 扩展，这实际上意味着我们只是浪费了 6 个字节来告诉您查看下面的 EtherType。[12]
  

  So far we have three different Ethernet encapsulation. Hank mentioned four. Welcome to Novell IPX Raw Encapsulation SNAFU. They believed in the magic powers of IEEE (or needed a length field) but couldn’t be bothered waiting for IEEE to agree on LLC2 frame format – IPX payload directly follows the length field without any indication of what higher-layer protocol is riding in the Ethernet packet [13].
  到目前为止，我们有三种不同的以太网封装。汉克提到了四个。欢迎使用 Novell IPX Raw Encapsulation SNAFU。他们相信 IEEE 的魔力（或者需要一个长度字段），但懒得等待 IEEE 就 LLC2 帧格式达成一致 - IPX 有效载荷直接跟随长度字段，而没有任何指示以太网数据包中的更高层协议[13]。
  

  Fortunately (for everyone else who had to parse their stupidity) IPX packet header format included a checksum as the first two bytes of the packet, and Novell never implemented a proper checksum for IPX, so every IPX packet always started with 0xFFFF[14], which would be understood as global broadcast by anyone complying with 802.2 standards, but who’s counting.
  幸运的是（对于其他所有不得不解析其愚蠢的人）IPX 数据包标头格式包含校验和作为数据包的前两个字节，而 Novell 从未为 IPX 实现适当的校验和，因此每个 IPX 数据包总是以 0xFFFF[14] 开头，任何符合 802.2 标准的人都会将其理解为全球广播，但谁在计算。
  

  Does all of this matter? Not really unless you’re an Ethernet history addict, but it resulted in a nice consulting project for my company in 1990s [15].
  这些都重要吗？除非你是以太网历史瘾君子，否则不是真的，但它在 1990 年代为我的公司带来了一个不错的咨询项目 [15]。
  

  Local experts in IBM connectivity couldn’t make an IBM AIX server talk to a Cisco router. They were also too thrifty to invest in a protocol analyzer (that thing could cost around $10K in those days) and wanted to borrow ours. In the end we agreed we’d charge them a day of consulting services, come over with the Sniffer and figure out what’s going on. It took me a few moments to realize AIX used SNAP encapsulation, and a few minutes to figure out how to configure that on Cisco routers[16]. Problem solved.
  IBM 连接方面的本地专家无法让 IBM AIX 服务器与 Cisco 路由器通信。他们也太节俭了，无法投资协议分析仪（在那个年代，那东西可能要花费大约 10000 美元），并想借用我们的。最后，我们同意向他们收取一天的咨询服务费用，然后带着嗅探器过来，弄清楚发生了什么。我花了几分钟才意识到 AIX 使用了 SNAP 封装，又花了几分钟才弄清楚如何在 Cisco 路由器上配置它[16]。问题解决了。
  

  Just in case you’ll ever have to work with a 30-year-old IBM Unix server: the command to use is arp snap. Cisco IOS constructs layer-2 headers for individual IP next-hops from ARP entries, and the encapsulation used toward a next hop depends on the what encapsulation that next hop used in ARP request/reply. You cannot specify what encapsulation you want to use for IP, but you can specify which encapsulation (s) ARP requests will use. For some other gory details, see RFC 1042.
  以防万一您不得不使用已有 30 年历史的 IBM Unix 服务器：要使用的命令是 arp snap。Cisco IOS 为 ARP 条目中的单个 IP 下一跳构建第 2 层报头，用于下一跳的封装取决于 ARP 请求 / 应答中使用的下一跳的封装。您无法指定要用于 IP 的封装，但可以指定 ARP 请求将使用的封装。有关其他一些血腥的细节，请参阅 RFC 1042。
  

文中注释

[1]. Before someone asks: I started working with Ethernet in late 1980s, so I was a bit late to the party, but nevertheless had the “privilege” of working with thick yellow cable and vampire taps and lived through the nightmares of thin coax cables being charred by under-the-desk heaters. 在有人问之前：我在 1980 年代后期开始使用以太网，所以我来晚了一点，但仍然有 “特权” 使用粗黄色电缆和吸血鬼水龙头，并经历了细同轴电缆被桌子下的加热器烧焦的噩梦。

[2]. According to Wikipedia, Robert Metcalfe named it after the luminiferous aether once postulated to exist as an “omnipresent, completely-passive medium for the propagation of electromagnetic waves.”
根据维基百科，罗伯特・梅特卡夫（Robert Metcalfe）以发光的以太命名，该以太曾经被认为是 “无所不在的，完全被动的电磁波传播介质”。

[3]. A 7-layer purist would say oh, you mean a layer-3 protocol. Unfortunately we’ve seen applications riding directly on top of Ethernet, many of them coming from Digital (DEC), the infamous inventor of transparent bridge – the kludge needed to support them.
一个 7 层纯粹主义者会说，哦，你的意思是第 3 层协议。不幸的是，我们已经看到应用程序直接安装在以太网之上，其中许多来自数字（DEC），这是臭名昭著的透明桥的发明者 - 支持它们所需的 kludge。

[4]. DIX = Digital, Intel, Xerox – the initials of the three major companies pushing early Ethernet in alphabetical order. Even though Ethernet was invented within Xerox PARC, they still got the last place in the acronym.
DIX = Digital、Intel、Xerox – 按字母顺序排列的三大公司推动早期以太网的首字母缩写。尽管以太网是在施乐 PARC 内部发明的，但它们仍然在首字母缩略词中排在最后。︎

[5]. A hint: Token Ring frames have ending delimiter, as do FDDI frames.︎
提示：令牌环帧具有结束分隔符，FDDI 帧也是如此。︎

[6]. See also: a diplomatic explanation of what made ATM cells 53 bytes long ︎
参见： 对 ATM 信元长 53 字节的原因的外交解释 ︎

[7]. Don’t even think about asking what happens when jumbo frames use IEEE encapsulation.
甚至不要考虑当巨型帧使用 IEEE 封装时会发生什么。︎

[8]. We need a minimum frame length to make sure the sender detects a collision (and starts sending gobbledygook that will bork the FCS value) before it finishes sending the frame. The frame length is thus a function of transmission speed and collision domain size, which depended on cable lengths and the number of repeaters in an Ethernet segment. ︎
我们需要一个最小帧长度，以确保发送方在完成发送帧之前检测到冲突（并开始发送 gobbledygook，这将破坏 FCS 值）。因此，帧长度是传输速度和冲突域大小的函数，而冲突域大小取决于电缆长度和以太网段中继器的数量。︎

[9]. What could be better than taking a protocol that was designed for 1200-baud noisy modem connections and put it onto a 4 Mbps pretty reliable Token Ring LAN? Chalk it up to doing more with less mentality aka it costs too much to redesign our broken stuff.︎
当把设计用于 1200 波特噪声调制解调器连接的协议移植到 4 Mbps相对可靠的 Token Ring 局域网上，有什么比这更好的呢？把它归因于更高效利用资源的理念，也就是说，重新设计我们那些有问题的东西成本太高了。

[10]. Where did they get such a weird number? 1536 = 0x600, a value reserved for an old Xerox protocol
他们从哪里得到这么奇怪的数字？1536 = 0x600，为旧施乐协议保留的值 ︎

[11]. That’s what you get when you’re approaching a megabit transport technology with a 1200-baud design mindset and try to squeeze everything into one byte where you could easily have two. Oh, and of course every header field must have at least one reserved bit. ︎
这就是当你用1200 波特的设计思维来处理一个兆比特的传输技术时会得到的结果，并且试图将所有内容挤进一个字节里，而其实可以轻松地用两个字节来完成。当然，每个头部字段还必须至少有一个保留位。

[12]. In case you haven’t noticed: they wasted six bytes (plus the length field) because they tried to save two. Good job. ︎
如果你没有注意到：他们浪费了六个字节（加上长度字段），因为他们试图保存两个字节。干得好。︎

[13]. Who would want to run anything else but Novell Netware on a LAN anyway? ︎
无论如何，谁会想在局域网上运行除了 Novell Netware 之外的任何其他东西？︎

[14]. Which is how everyone else identified the idiots on the wire︎
这就是其他人如何在网络上识别出这些白痴的方式。

[15]. I also had to run through this explanation way too many times while delivering Router Software Configuration (and later ICND) course.
我也曾经在教授路由器软件配置（后来是ICND）课程时，不断地重复这个解释。

[16]. Cisco software had no ?-triggered help until Terry Slattery got a contract to rewrite its CLI parsers, so I had to go through the documentation. ︎
在 Terry Slattery 获得重写其 CLI 解析器的合同之前，思科软件没有得到任何帮助，因此我不得不阅读文档。︎

---

via：ipspace. Wednesday, October 26, 2022 07:43 UTC

https://blog.ipspace.net/2022/10/ethernet-encapsulations.html