bruce@ssc-vax.UUCP (Bruce Stock) (05/12/88)
Does anyone have any wisdom to share regarding the ability of TCP/IP versions based on Ethernet 2 frame formats to communicate with 802 (.2).3 based versions ( on the same network)? I just got a flyer for the Wollongong WIN/H3000 software (FTP, Telnet, SMTP) for the HP 3000 series of computers. This package uses the underlying 802 (.2).3 frame formats of HP's TCP/IP implementation for its lower layers. Most ( all?) other TCP implementations seem to use the Ethernet 2 frame formats and would probably not communicate with this package. Any experience to relate? It would seem that HP's TCP/IP implementation is grossly out of step with prevailing practice in the TCP arena. Are there any reasons to choose it, based on either short term or long term considerations? Bruce E. Stock Boeing Aerospace uw-beaver!ssc-vax!bruce
karn@thumper.bellcore.com (Phil R. Karn) (05/14/88)
In my humble opinion, IEEE 802.2/3 is yet another standards committee that the world would have been far better off without. The changes they made to DIX (DEC-Intel-Xerox) Ethernet, already a well-proven de-facto industry standard, were utterly gratuitious. The existing 16-bit type field provided plenty of expansion room to build whatever additional capability they wanted while maintaining compatibility with existing protocol encapsulation formats. The new "length" field not only breaks compatibility, but is useless, redundant information for the protocols that already ran on Ethernet since they have their own type fields. (If a length field was considered necessary for other protocols, it could have been provided AFTER the type field, and only for certain new values in the type field). Because the DIX Ethernet type fields are invalid as 802.3 length values, it is possible to write packet receiver code that will accept, say, IP datagrams in either DIX or 802.3 framing, but real problems come when you need to decide how to SEND packets to another host you haven't spoken to before. I see only one easy answer to the gratuitous compatibility problems imposed by 802.3: IGNORE IT! Also be sure to tell the manufacturers why. Maybe someday the standards-mongers will get the message. (Begin Bernstein music here) Someday, somehow, somewhere... Phil
vjs@rhyolite.SGI.COM (Vernon Schryver) (05/17/88)
In article <1080@thumper.bellcore.com>, karn@thumper.bellcore.com (Phil R. Karn) writes: > I see only one easy answer to the gratuitous compatibility problems > imposed by 802.3: IGNORE IT! ... Yes, but...some vendors are already supporting it. I'm told by some of our customers that Gould/SEL machines can do either 'Ethernet 1 or 802.3' (meaning either lengths or types), depending on boot-time configuration, and cannot send even raw ethernet packets of one kind when configured for the other. I've heard more distressing claims about WIN/TCP for HP-3000's. This may not be true about either (it's only our customers beating up on us, demanding interoperability), but it will no doubt eventually be true of some machines. It's likely we, at SGI, can figure out how to make our drivers hear either the old form or RFC-1042. What should we do for output? -Add an option to ifconfig which tells the driver to speak RFC-1042? -A per-driver, system configuration option? -Some kind of hack for ARP like that for trailers? Send both kinds of ARP request and guess out what each destination wants by what you get back? But that makes the MTU for the link kind of variable. It might be confusing when two such machines talk to each other--depending on timing, they might get different conclusions about each other. What about proxy-ARP? It might be nice if the 4.3bsd compatible vendors could be consistent. If the problem has been solved, please forgive me, and tell me the solution. Vernon Schryver Silicon Graphics vjs@sgi.com or {pyramid,decwrl,research,allegra,adobe,sun}!sgi!vjs
hedrick@athos.rutgers.edu (Charles Hedrick) (05/19/88)
I certainly agree that 802.3 is useless, and we should have stuck with DEC-Intel-Xerox Ethernet. However what seems to be happening in practice is that older protocols are ignoring 802.3, and newer ones are using it. Thus no incompatibility actually happens. That is, TCP/IP, PUP, and DECnet phase IV are using the Ethernet standards, while ISO and DECnet phase V will presumably use 802.3. For token rings, etc., that have no existing base of TCP/IP implementations, it appears that only an 802.3 encapsulation will be used. So we should not have compatibility problems in practice. That assumes no vendors get overly eager in their standard-following and try to do an 802.3 encapsulation for Ethernet. HP did that, and lost obviously enough that I think other vendors will be discouraged from following suit.
norm@atom.hpl.hp.COM (Norman Kincl) (05/21/88)
> I certainly agree that 802.3 is useless, and we should have stuck with > DEC-Intel-Xerox Ethernet. However what seems to be happening in > practice is that older protocols are ignoring 802.3, and newer ones > are using it. Thus no incompatibility actually happens. That is, > TCP/IP, PUP, and DECnet phase IV are using the Ethernet standards, > while ISO and DECnet phase V will presumably use 802.3. For token > rings, etc., that have no existing base of TCP/IP implementations, it > appears that only an 802.3 encapsulation will be used. So we should > not have compatibility problems in practice. That assumes no vendors > get overly eager in their standard-following and try to do an 802.3 > encapsulation for Ethernet. HP did that, and lost obviously enough > that I think other vendors will be discouraged from following suit. Are you not confusing 802.3 with 802.2? 802.3 (physical layer) is essentially identical to Ethernet physical layer (the grounding pin is different and there is one other difference in there somewhere). It is not hard to make a card that can be fully compatible with both. Most cards these days don't really care if they are connected via an transceiver cable to a transceiver (Ethernet) or via an AUI cable to a MAU (802.3). 802.2 (data link layer) is where the problem comes in. Though you can have a system that speaks both quite fluently (eg. HP9000 or cisco box), most systems do not do that and provide only one of those data link layers (usually Ethernet). (There is no such thing as 802.3 token ring---that comes under 802.5)
miket@ccicpg.UUCP (Mike Tracy) (05/21/88)
in article <14933@sgi.SGI.COM>, vjs@rhyolite.SGI.COM (Vernon Schryver) says: > > In article <1080@thumper.bellcore.com>, karn@thumper.bellcore.com (Phil R. Karn) writes: >> I see only one easy answer to the gratuitous compatibility problems >> imposed by 802.3: IGNORE IT! ... > > Yes, but...some vendors are already supporting it. I'm told by some of > our customers that Gould/SEL machines can do either 'Ethernet 1 or > 802.3' (meaning either lengths or types), depending on boot-time > configuration, and cannot send even raw ethernet packets of one kind > when configured for the other. Are you sure they don't mean ethenet 2 ? Many vendors claim to be 802.3 compatable but actually are only compatable up to the frame format. All of the electrical stuff, CSMA/CD, etc. is 802.3 but they use they standard ethernet frame format (i.e. type instead of length). Probably, if they are running Unix, they are ethernet 2. Otherwise, it makes it hard to talk to other Unix boxes. :-> -- Michael D. Tracy CCI Computers (714)458-7282 9801 Muirlands Boulevard Irvine, CA 92718 uunet!ccicpg!miket
cire@CLASH.CISCO.COM (05/25/88)
>> To: hedrick@rutgers.edu (Charles Hedrick) >> Cc: tcp-ip@sri-nic.ARPA >> Subject: Re: 802 (.2).3 TCP/IP >> Date: Fri, 20 May 88 10:42:45 PDT >> From: Norman Kincl <norm@atom.hpl.hp.com> >> >> > while ISO and DECnet phase V will presumably use 802.3. For token >> > rings, etc., that have no existing base of TCP/IP implementations, it >> > appears that only an 802.3 encapsulation will be used. So we should Whoops. That is 802.5 which has an encapsulation that is significantly different than 802.3. I am in the process of implementing this stuff for cisco. On top of the 802.5 lives 802.2 which is what I think you are really talking about. I plan on using 802.2 with the SNAP extension to allow essentialy an ethernet type field. >> > not have compatibility problems in practice. That assumes no vendors >> > get overly eager in their standard-following and try to do an 802.3 >> > encapsulation for Ethernet. HP did that, and lost obviously enough >> > that I think other vendors will be discouraged from following suit. >> cisco also implements 802.2 encapsulations for Ethernet. We use the SNAP extensions to properly identify what type the packet is. >> Are you not confusing 802.3 with 802.2? 802.3 (physical layer) is >> ... >> 802.2 (data link layer) is where the problem comes in. Though you can have >> a system that speaks both quite fluently (eg. HP9000 or cisco box), most >> systems do not do that and provide only one of those data link layers >> (usually Ethernet). Much of what was written is really talking 802.2 while saying 802.3 -c cire|eric Eric B. Decker cisco Systems Menlo Park, California email: cire@cisco.com uSnail: 1360 Willow Rd., Menlo Park, CA 94025 Phone : (415) 326-1941
hedrick@ATHOS.RUTGERS.EDU (Chuck Hedrick) (05/27/88)
I've just looked at RFC1042 again. While it is true that I have in the past tended to confuse 802.3 and 802.3, it's not clear that I did so in this message. In a paragraph at the end of the RFC, it uses language very similar to mine, referring to an 802.3 and an Ethernet link layer as separate standards. Since 802.3 includes wording saying that there is a length code rather than a type code, I generally consider that the term 802.3 is properly applied only to systems whose software actually do that. This is of course normally coupled with 802.2 as well. I did not mean to imply that 802.3 was used over token ring, etc. Obviously there are other 802.x standards for these other media. What I was trying to say was that in my view, RFC1042-style encapsulation will be used for all newer media, but that traditional 10MHz Ethernet implementations should continue to use the traditional encapsulation and not the one defined in RFC1042 (which while it may use the same basic ARP packets, presumes the use of 802.3 and in most cases 802.2, so that the headers put in front of the ARP packets would make it not interoperable with a system such as 4.3 BSD).
dino@CDCCENTR.BITNET (Dino Farinacci - Control Data - CDCNET TCP/IP Development) (06/25/88)
This is in response to ssc-vax!bruce@beaver.cs.washington.edu's
memo <1919@ssc-vax.UUCP>:
When we (CDC) initially started support of TCP/IP in CDCNET
we made the decision to support all three of the Ethernet
header formats. We were informed with the direction of OSI
standards that 802.2/802.3 was the way to go. Our CDCNET
systems already supported this header format but we needed to
include Ethernet 2 and SNAP headers.
We felt the effort was trivial for incoming frames. Just
check the ether type field in the 802.3 (or version 2
header). If the value was greater than 1518 (maximum length
Ethernet frame), then the header format was Ethernet 2.
Otherwise it was 802.2/802.3. If 802.2 was present than
another check is done to determine if a SNAP header follows.
If so, use the ether type field in the SNAP as one would in
the Ethernet 2 case. If no SNAP, use the 8-bit SAP value in
the 802.2 to multiplex to the correct user.
For outgoing frames, one does not know what header format the
destination system supports. If it was our own system, it
didn't matter (we supported all of them). There are two ways
we allowed this information to be provided. One, staticly
configure the header format with the IP address/ Ethernet
address. Or two, let ARP find out. Obviously it was less of
a burden to the Network Administrator if ARP did it. The
disadvantage was that ARP broadcasts two ARP requests, each
with a differnet header format (Ethernet 2 and SNAP - there
is not an 8-bit 802.2 SAP value assigned for ARP). When the
reply is received, the IP address/Ethernet address and header
format is cached.
We did this over a year and a half ago anticipating that
workstation vendors would go to the SNAP. However,
everything I've heard from the TCP/IP interoperability
conferences indicates no one cares about it and everything
works fine as it is today.
Dino Farinacci
Control Data Corp.
CDCNET TCP/IP Design and Development
Sunnyvale, CA.
408-744-5375
------------------------------------------------------------------703