Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!bbn!oberon!cit-vax!ucla-cs!zen!ucbvax!OPAL.BERKELEY.EDU!minshall
From: minshall@OPAL.BERKELEY.EDU
Newsgroups: comp.protocols.tcp-ip
Subject: Re: Separation of Layers
Message-ID: <8711051739.AA26748@opal.berkeley.edu>
Date: Thu, 5-Nov-87 12:38:57 EST
Article-I.D.: opal.8711051739.AA26748
Posted: Thu Nov  5 12:38:57 1987
Date-Received: Thu, 12-Nov-87 05:44:24 EST
References: <8711050031.AA11673@PARIS.MIT.EDU>
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 47


>...
> Alternatively if possible I would probably like to move calls off the
> ISDN medium onto the ethernet medium if a dead network suddenly became
> alive.  
> 
> But given that IP and TCP are apparently really only one layer it
> can't be done.  
> 
> In any case the problem probably isn't too important since ISDN is too
> slow to be useful for real networking.  Of course for multihomed hosts
> the reliability issue might be important, but I guess it just can't be
> done.

No, TCP and IP are not one layer.

Back in the days of experimental ethernets, there were only 8 bits of
addressing in the ethernet packets.  The way of mapping an IP address
to an ethernet address was to use the lower order 8 bits of the IP
address as the ethernet address (though actually what really happened
was that the ethernet address was assigned to the lower order 8 bits
of the IP address).

You wouldn't argue that the ethernet and IP were really one layer; however,
the mapping between IP address and ethernet address was merely that of
extracting - a projection.

On current ethernet, a projection from the 32-bit IP address space won't
work, since the map needs to be onto, and the ethernet address space
is 48 bits.  So, we have ARP.

A TCP address is composed of two parts: a 32-bit IP address, and an
8-bit port identifier.  To convert a TCP address into an IP address
is, again, a projection.

That this is so does not somehow merge the two layers into one.  They are
two layers.

(By the way, a machine is certainly free to send a packet on an interface
with address 128.32.13.4, and give it an IP source address of 10.0.3.4;
this is even justified if that machine has an interface with "address"
10.0.3.4 and that interface is down and there is an already existing
connection to a local port of 10.0.3.4.  However, you are correct in
assuming that in this situation, the connection partner will probably
not survive the fact that the 10.0.3.4 interface has gone down - unless
the sender uses IP source routing and the partner remembers the last
source route received on the connection.)