[mod.protocols.tcp-ip] the IEEE/Blue Book problem: an idea

ROMKEY@XX.LCS.MIT.EDU.UUCP (02/07/87)

I think things aren't as grim as I originally thought they were.
Here's some background, and why.

I believe we need to switch over to IEEE formats on ethernet, away
from Blue Book, IF companies are going to be selling 802.3 to 802.5
MAC-level bridges. If two machines running IP on a token ring and an
ethernet can't talk to one another via the bridge, we're going to be
shot on sight (and complained at, too). [Personally, I'd rather just
ignore the whole issue, but I think if we do then we're going
to end up with a lot of broken networks.]

I believed there was a nasty problem in converting the IP encapsulation
format, but now I think I know a way around it. The problem is that
while it's easy to receive both Blue Book and IEEE IP packets at the
same time (just accept both packet formats), it's difficult to decide
which format to transmit. You could have a switch in the operating system
or network code that sets this, but that's not good enough; it needs to be
on a per-host basis.

This had me very worried, since this sort of transition would be TRULY PAINFUL.
There would be many problems with two TCP hosts on the same cable
not being able to talk to one another, and I think it would mean
general setbacks to the TCP/IP "cause".
Then I had an inspiration based on the way that 4.3 Unix negotiates the use of
trailers.

First, add a flag to each entry in your ARP cache showing whether the host
speaks IEEE or Blue Book formats. Then, when you want to send a packet to a
host:
	1. See if the host is in your ARP cache. If it is, send the packet
	   formatted according to the setting of this flag.

	2. If it isn't, try sending an IEEE ARP at the host. If this
	   succeeds, put an entry in the ARP cache, and note that the
	   host likes IEEE formats.

	3. If it doesn't respond, try sending a Blue Book ARP at the
	   host. Again, if it succeeds, put an entry in the ARP cache
	   and note that the host likes Blue Book formats.

	4. If it doesn't succeed, then do whatever it is you do when
	   ARP fails.

Note that this algorithm only wants to be followed on an ethernet or IEEE 802.3
network, not on token ring or the other 802 networks. Also, for this to work,
all IEEE ARP packets all have the same ARP hardware type field, regardless of
which IEEE network they're on. As a side note, receivers do not distinguish
between IEEE ARP and Blue Book ARP based on the hardware types, because the
ARP's are *also* encapsulated differently in each case, so a Blue Book-only
host will throw away any IEEE ARP's it gets. This doesn't really matter,
but it might not be obvious from some of my previous messages on this
subject.

One (hopefully last) question: what would happen if a MAC-level
bridge had to forward a Blue Book packet to, say, an 802.5 ring?

Finally, I don't recommend anyone follow the algorithm I have
described above unless it receives some sort of official endoresment.

John Romkey			FTP Software, Inc.
(617) 864-1711			PO Box 150
UUCP: romkey@mit-vax.UUCP	Kendall Square Branch
ARPA: romkey@xx.lcs.mit.edu	Boston, MA, 02142
-------