rpk@mit-eddie.UUCP (Robert Krajewski) (05/16/84)
Newsgroups: net.lan Message-ID: <3316@fortune.UUCP> Date: Tue, 15-May-84 19:05:52 EDT If you are just buying controllers from some vendor such as 3Com or Interlan, not to worry. The controller comes with a default address which is (supposed to be) unique, set by the vendor. Note: If you are going to be a gateway host between two Ethernets, make sure your controllers can have the address overridden by host software, since it is very important that the same absolute physical address appear on both nets. (Usually, you go read the default addresses from all the controllers, pick one [the smallest? the "first"?], and write that to all of them.) This is probably not the right thing to do, especially when you considered that most major protocols will have their own software addresses for host which will not be trivially and correctly translatable into Ethernet hardware addresses. To interface Ethernet to a higher level protocol, one should look at Dave Plummer's Address Resolution Protocol, which is becoming a de facto standard. Like someone said before on this list, you've got to be smart if you have a gateway to another network (not neccessarily an Ethernet). For example: Chaosnet is a local area network that was first both hardware and software, but now can run with Ethernet II hardware. At MIT, both old Chaosnet cable and new Ethernet cable are subnets of the entire MIT Chaosnet. (Note that the Ethernets can also carry IP packets, which the pdp11 Chaosnet bridges ignore entirely.) So the Chaosnet hosts on the Ethernet need to fill in their hardware destination address in the Ethernet frames, and it does matter if the actual destination host has an Ethernet interface or an old Chaosnet interface. The packet has got to get to the bridge, which will know what to do with it when it looks at the higher-level Chaosnet address. [The parallel situatiuon in the Internet world is when J. Random Workstation is confronted with sending a IP datagram to, say, Stanford.] The general guideline is for the gateway respond with its own Ethernet hardware address when it gets any ARP request for a host not on the subnet to which it is connected. How the packet actually gets routing will be determined by the higher-level protocols involved. -- ``Bob'' (Robert P. Krajewski) ARPA: RpK@MC MIT Local: RpK@OZ UUCP: genradbo!miteddie!rpk or genradbo!miteddie!mitvax!rpk
rpw3@fortune.UUCP (05/19/84)
#R:mit-eddi:-185900:fortune:5900023:000:8277 fortune!rpw3 May 18 23:23:00 1984 I suppose I shouldn't have opened the subject without covering it a little more fully and carefully... For starters, I used "gateway host" when I should have said just "host". The statement is true for either, but the "gateway" was a non-sequitor and therefore a red herring. +-----response---------- | +-----original posting---------- | | Note: If you are going to be a gateway host between two | | Ethernets, make sure your controllers can have the address | | overridden by host software, since it is very important that | | the same absolute physical address appear on both nets. (Usually, | | you go read the default addresses from all the controllers, pick | | one [the smallest? the "first"?], and write that to all of them.) | +--------------- | | This is probably not the right thing to do, especially when you considered | that most major protocols will have their own software addresses for hosts | which will not be trivially and correctly translatable into Ethernet | hardware addresses. To interface Ethernet to a higher level protocol, one | should look at Dave Plummer's Address Resolution Protocol, which is | becoming a de facto standard. Like someone said before on this list, | you've got to be smart if you have a gateway to another network (not | neccessarily an Ethernet). +--------------- Sorry, you are correct in general (and Plummer's ARP is a nice solution to the general case), but I meant what I said for the specific case of the higher-level protocol being Xerox's XNS/ITP. See "Xerox Integration Standard: Internet Transport Protocols" (XSIS 028112), December 1981, page 16. A few quotes [with notes], in case you don't have it handy: - "Ethernet [physical] addresses are identical to the [XNS] Internet Datagram Protocol's 48-bit host number. When a host is connected to more than one Ethernet, its 48-bit level zero Ethernet address on all Ethernets is equal to its [level one] 48-bit host number. The procedures for acquiring such numbers are specified in Appendix B." (Appendix B just tells you to write the Ethernet Address Administrator's Office.) The scheme I gave earlier (of somehow picking on of the addresses on one of your Ethernet boards as your host number) is a hack, to be sure. While it guarantees that your host doesn't have the same number as any other, you must NOT change your Ethernet boards (at least the one whose address you used as a host number) without informing all the name servers in the world that your host number has changed. You MAY keep the same host number you began with, if you destroy the Ethernet board it came from (or the little ROM that held it) to make sure no one else EVER uses it. Most (all?) of the controller vendors allow you to (a) move the little ROM to the new board, (b) buy a new unique ROM, or (c) "check out" a unique number from their allocated space, if needed. You would then permanently store the host number in stable file storage (and on a piece of paper taped to the machine, just for safety? [see note at end]). I apologize for not making those points clear earlier. Xerox actually assumes it is CPU manufacturers, and not controller vendors, who will be assigning host numbers, but they address the same replacement issue: - "It is likely that the host number will be hardwired to some part of the machine -- the backplane or one of the processor boards. If this piece of hardware is replaced, it is likely that the host number of the machine and its associated software will change. Reinitialization of the software may then be necessary, but this is something that would typically have to be done if any other characteristic of the hardware changed. It is important to note that a machine's host number may change, but no two machines may have the same number at the same time." This identity of host numbers and physical addresses is deliberate. Remember that Xerox designed Ethernet and XNS to be small and fast to run on office machines, not (necessarily) big mainframes: - "Xerox internets will, for the most part, consist of Ethernets, and it is for this reason that Ethernet addresses are identical to 48-bit host numbers. This is an optimization and a convenience, and in no way compromises the generality of the architecture [7]. In fact, the management of Ethernet addresses is considerably simplified. When an internet packet is encapsulated for transmission over an Ethernet, there is no table-driven overhead in performing the necessary address translation. As a consequence, procedures and mechanisms for creating and managing the translation table in every machine connected only to an Ethernet are eliminated. When internet packets traverse other communication networks, table-driven translation may be necessary." Their reference [7] is: Yogen Dalal and Bob Printis, "48-bit Absolute Internet and Ethernet Host Numbers" (OPD-T8101) July 1981, to be published in the Proc. 7th Data Comm. Symposium, October 1981. This paper explains the rationale for 48 bits, and for the address/host-number identity. Unlike the ARPAnet IP/TCP, XNS/ITP host numbers do NOT have a network number in them. The mapping is assumed to be dynamic (as hosts are moved around between networks), and so is maintained in name servers (what Xerox calls "The Clearinghouse"). Conversely, the internet routers ONLY know about networks, not hosts. The routers are small and fast as a result, and the routing tables are small. Hosts need not know their network number, if they are connected only to a single Ethernet. Page 18 [italicized words are capitalized here]: - "A network number of UNKNOWN implies that the packet should be transmitted on the locally connected network(s). The network number UNKNOWN is a synonym for the network(s) to which the host is connected until the host discovers the SPECIFIC values." XNS network numbers are therefore "hints", not fixed attributes of a host. Note that the same caching strategies that are employed in Plummer's ARP are applicable to the host->network mapping, though possibly with longer timeouts. Page 22-3: - "If a host is connected to many networks, then an active socket within the host will have many equivalent network addresses, each one differing in the network field. The internetwork routing algorithm (see Section 4) treats the network number in the destination address of an internet packet as a partial route by which to deliver the packet. Therfore, whenever a service advertizes its network address [in a name server] it must take care to advertize all of them, and conversely if a consumer of a service cannot reach the service at one network address it must try the others before giving up [1; 10]." [refs to Clearinghouse] The identity of Ethernet address and XNS/ITP host number has not removed the address resolution problem, but it has (their claim would be) raised it to a level at which it is no longer a serious performance issue. For this reason (among others), XNS/ITP will probably continue to co-exist with IP/TCP, especially in the small office automation environment. Certainly Ethernet ARP will be needed for all other internet protocols besides XNS/ITP, but ARP should recognize, tolerate, and recommend that the physical Ethernet address of a host be the same on all connected Ethernets, since it is required if the host runs any XNS/ITP jobs. At the very least, ARP should be taught about the protocol type "ether_type$XEROX_XNS", as well as "ether_type$XEROX_PUP" (which is, from Xerox's point of view, obsolete). After all, Xerox recognizes "ether_type$DOD_INTERNET"... ;-} Rob Warnock UUCP: {ihnp4,ucbvax!amd70,hpda,harpo,sri-unix,allegra}!fortune!rpw3 DDD: (415)595-8444 USPS: Fortune Systems Corp, 101 Twin Dolphin Drive, Redwood City, CA 94065 ------ Note: Above, I mentioned writing host numbers down on paper. The following quote s from the Ethernet Specification itself (version 2.0, Appendix B): - "When Ethernet Addresses must be manually transcribed, it is desirable to append a checksum to detect transcription errors" They then give an algorithm for calculating a 2-byte checksum. It turns out to be the same as the internet datagram 16-bit 1's complement checksum!