networking - ARP报文中的源MAC地址和封装时指定的源MAC地址有什么区别？

Question

我想了解 ARP 的工作原理和 ARP 数据包的格式。看下图中圈出的字段:

在这个例子中，他们在两个字段中给出了不同的 MAC 地址。我看不出这怎么可能？这两者在什么情况下会有所不同？

如果不是，为什么我们要在封装时添加冗余信息？

虽然我认为因为它们有不同的长度(一个固定 6 字节而另一个是可变的..为什么？？)它们必须用于不同的地址。

Answer 1

这可能是一个合法的错字。 ARP 报文中的地址长度是可变的，因为不同的二层协议(protocol)具有不同的地址长度。不要错误地只考虑以太网。

你应该学习RFC 826为了理解 ARP:

This protocol was originally designed for the DEC/Intel/Xerox 10MbitEthernet. It has been generalized to allow it to be used for othertypes of networks. Much of the discussion will be directed toward the10Mbit Ethernet. Generalizations, where applicable, will follow theEthernet-specific discussion.

查看强调的文字:

Why is it done this way??

Periodic broadcasting is definitely not desired. Imagine 100workstations on a single Ethernet, each broadcasting addressresolution information once per 10 minutes (as one possible set ofparameters). This is one packet every 6 seconds. This is almostreasonable, but what use is it? The workstations aren't generallygoing to be talking to each other (and therefore have 100 uselessentries in a table); they will be mainly talking to a mainframe, fileserver or bridge, but only to a small number of other workstations(for interactive conversations, for example). The protocol describedin this paper distributes information as it is needed, and only once(probably) per boot of a machine.

This format does not allow for more than one resolution to be done inthe same packet. This is for simplicity. If things were multiplexedthe packet format would be considerably harder to digest, and much ofthe information could be gratuitous. Think of a bridge that talksfour protocols telling a workstation all four protocol addresses,three of which the workstation will probably never use.

This format allows the packet buffer to be reused if a reply isgenerated; a reply has the same length as a request, and several ofthe fields are the same.

The value of the hardware field (ar$hrd) is taken from a list for thispurpose. Currently the only defined value is for the 10Mbit Ethernet(ares_hrd$Ethernet = 1). There has been talk of using this protocolfor Packet Radio Networks as well, and this will require another valueas will other future hardware mediums that wish to use this protocol.

For the 10Mbit Ethernet, the value in the protocol field (ar$pro) istaken from the set ether_type$. This is a natural reuse of theassigned protocol types. Combining this with the opcode (ar$op) wouldeffectively halve the number of protocols that can be resolved underthis protocol and would make a monitor/debugger more complex (seeNetwork Monitoring and Debugging below). It is hoped that we willnever see 32768 protocols, but Murphy made some laws which don't allowus to make this assumption.

In theory, the length fields (ar$hln and ar$pln) are redundant, sincethe length of a protocol address should be determined by the hardwaretype (found in ar$hrd) and the protocol type (found in ar$pro). It isincluded for optional consistency checking, and for network monitoringand debugging (see below).

The opcode is to determine if this is a request (which may cause areply) or a reply to a previous request. 16 bits for this isoverkill, but a flag (field) is needed.

The sender hardware address and sender protocol address are absolutely necessary. It is these fields that get put in atranslation table.

The target protocol address is necessary in the request form of thepacket so that a machine can determine whether or not to enter thesender information in a table or to send a reply. It is notnecessarily needed in the reply form if one assumes a reply is onlyprovoked by a request. It is included for completeness, networkmonitoring, and to simplify the suggested processing algorithmdescribed above (which does not look at the opcode until AFTER puttingthe sender information in a table).

The target hardware address is included for completeness and networkmonitoring. It has no meaning in the request form, since it is thisnumber that the machine is requesting. Its meaning in the reply formis the address of the machine making the request. In someimplementations (which do not get to look at the 14.byte ethernetheader, for example) this may save some register shuffling or stackspace by sending this field to the hardware driver as the hardwaredestination address of the packet.

There are no padding bytes between addresses. The packet data shouldbe viewed as a byte stream in which only 3 byte pairs are defined tobe words (ar$hrd, ar$pro and ar$op) which are sent most significantbyte first (Ethernet/PDP-10 byte style).

RFC 826已由 RFC 5227 更新和 RFC 5494 .