By the way, it doesn't matter if both devices are in the same subnet since a PC should never ARP for an IP address not in its subnet; it will send an ARP for the configured gateway IP address, instead of a destination IP address not in its subnet.
Packet Reception:
When an address resolution packet is received, the receiving Ethernet
module gives the packet to the Address Resolution module which goes
through an algorithm similar to the following. Negative conditionals
indicate an end of processing and a discarding of the packet.
?Do I have the hardware type in ar$hrd? Yes: (almost definitely)
[optionally check the hardware length ar$hln] ?Do I speak the
protocol in ar$pro? Yes:
[optionally check the protocol length ar$pln]
Merge_flag := false
If the pair <protocol type, sender protocol address> is
already in my translation table, update the sender
hardware address field of the entry with the new
information in the packet and set Merge_flag to true.
?Am I the target protocol address?
Yes:
If Merge_flag is false, add the triplet <protocol type,
sender protocol address, sender hardware address> to
the translation table.
?Is the opcode ares_op$REQUEST? (NOW look at the opcode!!)
Yes:
Swap hardware and protocol fields, putting the local
hardware and protocol addresses in the sender fields.
Set the ar$op field to ares_op$REPLY
Send the packet to the (new) target hardware address on
the same hardware on which the request was received.
Notice that the <protocol type, sender protocol address, sender
hardware address> triplet is merged into the table before the opcode
is looked at. This is on the assumption that communcation is
bidirectional; if A has some reason to talk to B, then B will probably
have some reason to talk to A. Notice also that if an entry already
exists for the <protocol type, sender protocol address> pair, then the
new hardware address supersedes the old one. Related Issues gives
some motivation for this.
Generalization: The ar$hrd and ar$hln fields allow this protocol and
packet format to be used for non-10Mbit Ethernets. For the 10Mbit
Ethernet <ar$hrd, ar$hln> takes on the value <1, 6>. For other
hardware networks, the ar$pro field may no longer correspond to the
Ethernet type field, but it should be associated with the protocol
whose address resolution is being sought.
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).
Best Answer
AS for point 1. well, maybe you could craft a IP header which check sum result would be 1, looking at the algorithm used (which is described in the RFC you linked), but if you expect somebody to do it for you, good luck...
Regarding point 2. you have to look at RFC2119 where it is said :
So it is up to the person that implement its version of an IP stack to decide which errors are reported or not. I have no idea if someone ever wrote an IPv4 stack with checksum error reporting trough ICMP but I doubt it.
My understanding is that if a checksum is bad, the packet should be dropped, and that's all. Re-transmission will be managed by upper layer if needed (generally by TCP).