Path: utzoo!mnetor!uunet!husc6!bbn!uwmcsd1!ig!jade!ucbvax!NCSA.UIUC.EDU!timk
From: timk@NCSA.UIUC.EDU (Tim Krauskopf)
Newsgroups: comp.protocols.tcp-ip
Subject: EtherTalk broadcast invasion
Message-ID: <8712312007.AA15323@zaphod.ncsa.uiuc.edu>
Date: 31 Dec 87 20:07:26 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 43


Here are some facts which should interest anyone running Ethernet networks,
especially those who have a lot of MAC level bridges.

How will EtherTalk broadcast packets affect you?

1.  AppleTalk over Ethernet, known as EtherTalk, has a registered Ethernet
    packet type of Hex 809B.  Your network analyzer probably doesn't
    recognize this one yet, but you will want it soon.

2.  RTMP is the AppleTalk routing information scheme.  It calls for a broadcast
    packet every 10 seconds.  We can live with this one, we know other routers
    do this, but what interval would you like to encourage Apple to use?  I
    would like to see these packets closer to one minute apart.  

3.  Look out for AARP broadcasts!  Apple has a registered AppleTalk Address
    Resolution Protocol (AARP) packet type for Ethernet (Hex 80F3) and the
    packet format looks a lot like ARP.  There is a special broadcast packet
    under AARP called a "probe" which prompted this warning message.

    When EtherTalk is initialized (machine is booted), an EtherTalk node must
    defend its unique 8-bit node number.  Probe packets are sent out to try
    to identify any machine with a matching node number.  If no machine 
    responds, then the number is assumed to be unique.

    Here's the kicker:  The official EtherTalk specification calls for 20
    retries of this broadcast packet spaced at intervals of 1/30th of a
    second.  Measurements confirm this is true for all of the EtherTalk
    implementations that we have.  So, you get a 20 packet broadcast storm
    every time a Mac is booted.  

What effect will this have on our networks?  What about when there are 100
Macs on the same physical wire as your Suns?  This obviously is of some
concern because we get bug reports from people who have noticed.  Our
problem is that EtherTalk sometimes chooses to defend its node number when
our NCSA Telnet application is launched.  Then we get blamed for an EtherTalk
problem.  Note for Ethernet snoopers:   If the packet type is 80F3 or 809B,
then we didn't generate it.  We only generate IP (0800) and ARP (0806)
packet types.

Tim Krauskopf                                        timk@ncsa.uiuc.edu (ARPA)
National Center for Supercomputing Applications      14013@ncsavmsa (BITNET)
(217)244-0638