adam@its63b.ed.ac.uk (ERCF02 Adam Hamilton) (01/01/70)
> Date: Wed, 5 Aug 87 11:24:18 CDT > From: sandrock@uxc.cso.uiuc.edu (Mark Sandrock) > > It sounds like you are claiming that DEC preempts Ethernet hardware > addresses which have been officially assigned to other vendors, but > I have yet to see a specific example of such an address. Is it asking > to much either to see an example or else have everyone drop this claim? > >Sure. There is a Symbolics 3600 at our site that has an Ethernet >hardware address of 08-00-05-03-00-38. The 08-00-05- portion was >assigned to Symbolics by the Ethernet number Czar for use by Symbolics >for its Ethernet interfaces. That is the "official" hardware address of >the interface on that machine. That machine also has a DNA address of >41.69. Because of the way DNA works, the booting procedure for the >machine changes the Ethernet address of the interface to >AA-00-04-00-45-A4. Therefore, DNA has preempted our officially assigned >address. In IEEE802 and also XEROX Blue book, the format of an Ethernet address is defined as having two special bits; these are the first two to be transmitted. Note that bits in an octet are transmitted LEAST significant bit first, therefore these bits are the LEAST significant bits of the first octet. The first bit signifies whether the address is individual or local, the second signifies whether the address is globally (value 0) or locally administered. In the above example (AA-00- etc.) the second bit is set, therefore the address is locally administered. All address allocations to manufacturers are globally administered. All VMS machines I have seen have addresses which start AA-00. All this means that DECnet style addresses are NOT globally unique (as discussed) but do NOT use values which are globally administered. This should make no difference unless the same address is used on more than one Ethernet when a bridge (specifically selective frame-level repeater) may well get confused. Presumably this bit was put in for DEC's benefit, but I'm just guessing here.
DCP@QUABBIN.SCRC.SYMBOLICS.COM (David C. Plummer) (08/10/87)
Date: 7 Aug 87 14:00:44 GMT
From: mcvax!ukc!its63b!adam@seismo.css.gov (ERCF02 Adam Hamilton)
In IEEE802 and also XEROX Blue book, the format of an Ethernet address
is defined as having two special bits; these are the first two to be
transmitted. Note that bits in an octet are transmitted
LEAST significant bit first, therefore these bits are the LEAST
significant bits of the first octet.
The first bit signifies whether the address is individual or local,
the second signifies whether the address is globally (value 0) or locally
administered. In the above example (AA-00- etc.) the second bit is set,
therefore the address is locally administered.
All address allocations to manufacturers are globally administered.
All VMS machines I have seen have addresses which start AA-00. All this
means that DECnet style addresses are NOT globally unique (as discussed)
but do NOT use values which are globally administered. This should make no
difference unless the same address is used on more than one Ethernet
when a bridge (specifically selective frame-level repeater) may well get
confused.
Presumably this bit was put in for DEC's benefit, but I'm just
guessing here.
I guess I'm hopelessly out of date. My copy of the Blue Book is Version
1.0, Sepetmber 30, 1980. In it, in section 6.2.1 on page 21, there is
no mention of this second bit being for local/global administration. In
fact, of the physical address it says
"A station's physical address should be distinct from the
physical address of any other station on @i(any) Ethernet."
The italics are in the book. Time marches on... standards change...sy.Ken@CU20B.COLUMBIA.EDU (Ken Rossman) (08/11/87)
"A station's physical address should be distinct from the physical address of any other station on @i(any) Ethernet." The italics are in the book. Time marches on... standards change... It would seem to me that it would be hopelessly difficult to try to administer a flat global set of ethernet addresses, and that some sort of mechanism, such as the global/local bits at the beginning would have to exist. In any case, regardless of how a spec says it SHOULD be, the real world appears to be allocating blocks of ethernet addresses to vendors to be used as they (or their customers) see fit. Along slightly different lines, I fail to see how the global ethernet addressing scheme, whether managed as a flat address space or in some hierarchical fashion, hasn't blown up yet. I mean there just aren't that many addresses available. Just as an isolated example, what happens to ethernet addresses on failing boards? We've probably had the ethernet board on one of our -20's replaced three times already. Am I to believe that DEC Field Service records these hardware addresses, and when bad boards come back that can't be repaired, they tell some global address administrator that this particular hardware address has now been freed and can be used again? /Ken -------
DCP@QUABBIN.SCRC.SYMBOLICS.COM (David C. Plummer) (08/11/87)
There are a lot more Ethernet addresses than Internet addresses, and I don't hear people screaming (yet) that we're running out of Internet addresses. (I do remember screaming that there weren't enough class A subnets, and later screaming that we had to be careful about doling out class B and C addresses because of fixed-size non-replacable tables in some older gateway implementations. Anyway...) The V1.0 Ethernet allowed for 2^23 vendors. That's 8 million vendors. Each vendor gets 2^24 addresses. That's 16 million addresses. It's conceivable that a vendor could run out of addresses, and my solution would be to give the vendor another (or several more) chunks of 2^24 addresses. Even if every person on the planet (about 2^32 people) had 64 machines (2^6) and got a new address for each machine every year, the Ethernet address space (2^47) allows for 2^(47-32-6) = 2^9 = 512 years of such (farfetched) activity. This is why the addressing hasn't "blown up yet," to use your phrase. There is therefore no need to recycle hardware addresses if a particular board (e.g., your DEC-20's) is unfixable. As for your DEC-20 board, replacing a board and/or changing an Ethernet hardware address for a host works pretty well if you use a dynamic protocol->hardware address translation mechanism such as ARP. The minor problem being the transition time until the hosts learn of the new address, and this problem is discussed in the RFC.