ARP报文包中的源MAC地址与封装时指定的源MAC地址有什么区别？
Difference between the source MAC address in an ARP message packet and the source MAC address specified while encapsulating it?
我想了解 ARP 的工作原理和 ARP 数据包的格式。看下图中圈出的字段：
在这个例子中，他们在两个字段中给出了不同的 MAC 地址。我看不出这怎么可能？这两者在什么情况下会有所不同？
如果不是，为什么我们要在封装时添加冗余信息？
虽然我确实认为因为它们有不同的长度（一个是固定的 6 字节而另一个是可变的..为什么？？）它们必须用于不同的地址。
这可能是一个合法的错字。 ARP 报文中的地址长度是可变的，因为不同的二层协议具有不同的地址长度。不要误以为只考虑以太网。
你应该研究 RFC 826 以了解 ARP：
This protocol was originally designed for the DEC/Intel/Xerox 10Mbit
Ethernet. It has been generalized to allow it to be used for other
types of networks. Much of the discussion will be directed toward the
10Mbit Ethernet. Generalizations, where applicable, will follow the
Ethernet-specific discussion.
查看强调的文字：
Why is it done this way??
Periodic broadcasting is definitely not desired. Imagine 100
workstations on a single Ethernet, each broadcasting address
resolution information once per 10 minutes (as one possible set of
parameters). This is one packet every 6 seconds. This is almost
reasonable, but what use is it? The workstations aren't generally
going to be talking to each other (and therefore have 100 useless
entries in a table); they will be mainly talking to a mainframe, file
server or bridge, but only to a small number of other workstations
(for interactive conversations, for example). The protocol described
in 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 in
the same packet. This is for simplicity. If things were multiplexed
the packet format would be considerably harder to digest, and much of
the information could be gratuitous. Think of a bridge that talks
four 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 is
generated; a reply has the same length as a request, and several of
the fields are the same.
The value of the hardware field (ar$hrd) is taken from a list for this
purpose. Currently the only defined value is for the 10Mbit Ethernet
(ares_hrd$Ethernet = 1). There has been talk of using this protocol
for Packet Radio Networks as well, and this will require another value
as will other future hardware mediums that wish to use this protocol.
For the 10Mbit Ethernet, the value in the protocol field (ar$pro) is
taken from the set ether_type$. This is a natural reuse of the
assigned protocol types. Combining this with the opcode (ar$op) would
effectively halve the number of protocols that can be resolved under
this protocol and would make a monitor/debugger more complex (see
Network Monitoring and Debugging below). It is hoped that we will
never see 32768 protocols, but Murphy made some laws which don't allow
us to make this assumption.
In theory, the length fields (ar$hln and ar$pln) are redundant, since
the length of a protocol address should be determined by the hardware
type (found in ar$hrd) and the protocol type (found in ar$pro). It is
included for optional consistency checking, and for network monitoring
and debugging (see below).
The opcode is to determine if this is a request (which may cause a
reply) or a reply to a previous request. 16 bits for this is
overkill, 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 a
translation table.
The target protocol address is necessary in the request form of the
packet so that a machine can determine whether or not to enter the
sender information in a table or to send a reply. It is not
necessarily needed in the reply form if one assumes a reply is only
provoked by a request. It is included for completeness, network
monitoring, and to simplify the suggested processing algorithm
described above (which does not look at the opcode until AFTER putting
the sender information in a table).
The target hardware address is included for completeness and network
monitoring. It has no meaning in the request form, since it is this
number that the machine is requesting. Its meaning in the reply form
is the address of the machine making the request. In some
implementations (which do not get to look at the 14.byte ethernet
header, for example) this may save some register shuffling or stack
space by sending this field to the hardware driver as the hardware
destination address of the packet.
There are no padding bytes between addresses. The packet data should
be viewed as a byte stream in which only 3 byte pairs are defined to
be words (ar$hrd, ar$pro and ar$op) which are sent most significant
byte first (Ethernet/PDP-10 byte style).
更新
我想了解 ARP 的工作原理和 ARP 数据包的格式。看下图中圈出的字段：
在这个例子中，他们在两个字段中给出了不同的 MAC 地址。我看不出这怎么可能？这两者在什么情况下会有所不同？
如果不是，为什么我们要在封装时添加冗余信息？
虽然我确实认为因为它们有不同的长度（一个是固定的 6 字节而另一个是可变的..为什么？？）它们必须用于不同的地址。
这可能是一个合法的错字。 ARP 报文中的地址长度是可变的，因为不同的二层协议具有不同的地址长度。不要误以为只考虑以太网。
你应该研究 RFC 826 以了解 ARP：
This protocol was originally designed for the DEC/Intel/Xerox 10Mbit Ethernet. It has been generalized to allow it to be used for other types of networks. Much of the discussion will be directed toward the 10Mbit Ethernet. Generalizations, where applicable, will follow the Ethernet-specific discussion.
查看强调的文字：
更新Why is it done this way??
Periodic broadcasting is definitely not desired. Imagine 100 workstations on a single Ethernet, each broadcasting address resolution information once per 10 minutes (as one possible set of parameters). This is one packet every 6 seconds. This is almost reasonable, but what use is it? The workstations aren't generally going to be talking to each other (and therefore have 100 useless entries in a table); they will be mainly talking to a mainframe, file server or bridge, but only to a small number of other workstations (for interactive conversations, for example). The protocol described in 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 in the same packet. This is for simplicity. If things were multiplexed the packet format would be considerably harder to digest, and much of the information could be gratuitous. Think of a bridge that talks four 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 is generated; a reply has the same length as a request, and several of the fields are the same.
The value of the hardware field (ar$hrd) is taken from a list for this purpose. Currently the only defined value is for the 10Mbit Ethernet (ares_hrd$Ethernet = 1). There has been talk of using this protocol for Packet Radio Networks as well, and this will require another value as will other future hardware mediums that wish to use this protocol.
For the 10Mbit Ethernet, the value in the protocol field (ar$pro) is taken from the set ether_type$. This is a natural reuse of the assigned protocol types. Combining this with the opcode (ar$op) would effectively halve the number of protocols that can be resolved under this protocol and would make a monitor/debugger more complex (see Network Monitoring and Debugging below). It is hoped that we will never see 32768 protocols, but Murphy made some laws which don't allow us to make this assumption.
In theory, the length fields (ar$hln and ar$pln) are redundant, since the length of a protocol address should be determined by the hardware type (found in ar$hrd) and the protocol type (found in ar$pro). It is included for optional consistency checking, and for network monitoring and debugging (see below).
The opcode is to determine if this is a request (which may cause a reply) or a reply to a previous request. 16 bits for this is overkill, 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 a translation table.
The target protocol address is necessary in the request form of the packet so that a machine can determine whether or not to enter the sender information in a table or to send a reply. It is not necessarily needed in the reply form if one assumes a reply is only provoked by a request. It is included for completeness, network monitoring, and to simplify the suggested processing algorithm described above (which does not look at the opcode until AFTER putting the sender information in a table).
The target hardware address is included for completeness and network monitoring. It has no meaning in the request form, since it is this number that the machine is requesting. Its meaning in the reply form is the address of the machine making the request. In some implementations (which do not get to look at the 14.byte ethernet header, for example) this may save some register shuffling or stack space by sending this field to the hardware driver as the hardware destination address of the packet.
There are no padding bytes between addresses. The packet data should be viewed as a byte stream in which only 3 byte pairs are defined to be words (ar$hrd, ar$pro and ar$op) which are sent most significant byte first (Ethernet/PDP-10 byte style).