Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!ucsd!ucbvax!HOGG.CC.UOREGON.EDU!jqj
From: jqj@HOGG.CC.UOREGON.EDU
Newsgroups: comp.protocols.tcp-ip
Subject: Re: choosing ethernet packet type automatically
Message-ID: <9009242042.AA20936@hogg.cc.uoregon.edu>
Date: 24 Sep 90 20:42:05 GMT
References: <9009240047.AA25144@asylum.sf.ca.us>
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 29

>The Hosts Requirements group talked about the issue and decided that
>if you want to run both encapsulations on one ethernet, they must be
>two different subnets
 ...
>I would recommend that if you want to support both, you create two
>different logical network interfaces that use the same physical
>interface, and have them use different encapsulations and different
>network numbers.

I wasn't there, but that's not my interpretation of rfc1122 as published.  If
your interpretation were correct, there would be no need for the requirement
that all hosts be able to hear Ethernet encapsulation.  My reading of the
paragraph referencing "two different logical networks on the same cable," is
that this appears as a justification fo NOT allowing 1042-only systems, not
as a recommendation for how to deal with 1042-only systems!

As I read it, the expectation is that you'll normally have a single subnet,
and that Ethernet is dominant; the assumption is that everybody normally uses
Ethernet, but that consenting systems might agree by some unspecified means
to use rfc1042 (possibly unidirectionally) for unicast traffic.  As I read
it, if you support rfc1042 at all you must support it by treating receipt
of such packets just as if they had been received in rfc894 encapsulation.

This interpretation is particularly plausible given the advent of
heterogenous bridging.  Most proposals for transparent bridging between
Ether/802.3 and other 802.x media (e.g. FDDI or IBM TR) imply that packets
(not just IP) generated on the Ethernet in 1042 encapsulation may arrive at
their destination on another Ethernet in Ethernet encapsulation.  This
breaks Appletalk II, of course, but was not supposed to break IP.