Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!ucla-cs!ames!sdcsvax!ucbvax!QUABBIN.SCRC.SYMBOLICS.COM!DCP
From: DCP@QUABBIN.SCRC.SYMBOLICS.COM.UUCP
Newsgroups: comp.protocols.tcp-ip
Subject: question about berkeley TCP/IP
Message-ID: <870629095735.6.DCP@KOYAANISQATSI.S4CC.Symbolics.COM>
Date: Mon, 29-Jun-87 09:57:00 EDT
Article-I.D.: KOYAANIS.870629095735.6.DCP
Posted: Mon Jun 29 09:57:00 1987
Date-Received: Tue, 30-Jun-87 04:30:12 EDT
References: <@YMIR.BITNET:KVC@ENGVAX.SCG.HAC.COM>
Sender: daemon@ucbvax.BERKELEY.EDU
Distribution: world
Organization: The ARPA Internet
Lines: 20


    Date: Fri, 26 Jun 87 19:06 PDT
    From: Kevin Carosso <@YMIR.BITNET:KVC@ENGVAX.SCG.HAC.COM>

    When a SYN is sent to a Berkeley UNIX TCP/IP implementation (4.3 or 4.2)
    it appears that UNIX can send the SYN-ACK without having to ARP for the
    host it's ACKing.  Does it indeed add an entry to the ARP table when an
    ethernet IP packet comes in?  I'll buy that anything to cut down
    on ethernet broadcasts is a good thing...

    This may seem like a dumb question, but the code is a little opaque and
    I'm not a UNIX kernel hack.  I have a hypothesis which explains some behaviour
    I'm seeing with the TCP I maintain (CMU/Tek for VAX/VMS) and UNIX must be
    doing this if my theory's any good.

That can't really work in the face of gateways, since on input the
source IP address does not correspond to the hardware source address of
the gateway, and on output routing is taking place so that the packet is
sent to the gateway's IP address, which the sender doesn't necessarily
have a translation for and may not have it handy.