Re: OT: Incoming/Outgoing route of IP subnet

[Kevin Buhr <buhr@telus.net>]

Alexander Steinert <stony8@gmx.de> writes:
> 
> I'm implementing an TCP/IP/ETH stack on a small device and wondered if I
> can simplify the ARP part and spare RAM by the assumption sketched
> above. One could remember the MAC src address of an incoming frame and
> use it as the MAC dest address for answering frames. No ARP requests
> would be necessary, only ARP answers.

I don't think you'll save RAM this way, at least as far as the ARP
table is concerned.  Instead of having one ARP table entry for each
machine on the local network including the gateway, you'll have an ARP
table entry for every machine that talks to you from anywhere (most
with MAC addresses pointing to the gateway).

And, for most applications, you can't get away with not implementing
ARP requests at all.  What if the ARP table fills and you have to drop
an entry needed for a connection where the next packet is expected to
come from you?  Under your suggested scheme, the connection will
mysteriously stall until you happen to get another packet from the
remote machine (which may never happen, in many applications).

You can save yourself the trouble of generating most ARP requests by
caching the source IP->MAC mapping of any ARP requests you receive.
See the "Packet Reception" section of RFC 826 and the talk about
bidirectional communication in the paragraph following the flow
chart.

-- 
Kevin <buhr@telus.net>