jbvb@VAX.FTP.COM (James Van Bokkelen) (08/11/89)
I was playing around at parsing the random RARP packets our 386i (SunOS 4.0) generates, and found that it wasn't using either of the "ar$op" values defined in RFC 903 for RARP (it defines 3 and 4, the 386i sends 5). While I understand "why" in general terms (what else is new), I am somewhat interested in knowing what 5 "officially" means (and 6, if they send it also). "YP request" and "YP reply", perhaps? jbvb
jkrey@VENERA.ISI.EDU (08/12/89)
jvbv:
ARP opcodes 5, 6, and 7 are assigned to dynamic reverse ARP.
Joyce.
DYNAMIC REVERSE ARP
Assignments:
Operation Code (op)
5 DRARP-Request
6 DRARP-Reply
7 DRARP-Errorbarmar@think.COM (Barry Margolin) (08/13/89)
In article <8908112249.AA00352@akamai.isi.edu> jkrey@VENERA.ISI.EDU writes: >ARP opcodes 5, 6, and 7 are assigned to dynamic reverse ARP. Is this documented in an RFC? I don't recall it. Barry Margolin Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar
db@helium.East.Sun.COM (David Brownell) (08/13/89)
In article <8908102042.AA04628@vax.ftp.com> jbvb@VAX.FTP.COM (James Van Bokkelen) writes: > I was playing around at parsing the random RARP packets our 386i (SunOS 4.0) > generates, and found that it wasn't using either of the "ar$op" values > defined in RFC 903 for RARP (it defines 3 and 4, the 386i sends 5). While > I understand "why" in general terms (what else is new), I am somewhat > interested in knowing what 5 "officially" means (and 6, if they send it also). > "YP request" and "YP reply", perhaps? The RFC for this is still sitting in folk's internal review piles ... looks like the IETF isn't the only process that needs streamlining to get RFCs out faster! (:-) Here's a capsule summary of Dynamic RARP, in fact the original proposal with minor updates. The RFC is more precise, accurate, and explanatory, and I certainly hope it gets out to Jon Postel soon. We propose a version of RARP to solve a specific problem arising when a system which is unknown on a given network tries to join it: there is no way for it to acquire an protocol address unless the system has been configured on the network by a third party. In our preferred model, systems may join or rejoin an arbitrary network without advance network preparation. Specific examples might be workstations being installed or relocated in a building housing multiple Ethernets. Joining a network must not ** require ** any administrative action. To solve the problem of acquiring an address, we propose a protocol with the working name of "Dynamic Reverse Address Resolution Protocol" (DRARP). The packet format and (on Ethernet and IEEE 802 networks) ethertype are those of RARP (hence the opcodes include those of ARP and RARP), but three new opcodes are defined: DRARP_REQUEST, DRARP_RESPONSE, and DRARP_ERROR: - DRARP_REQUEST (opcode 5) packets are exactly like RARP_REQUEST packets except for the operation code. They are a request to return either the published target protocol address corresponding to the target hardware address field, or one allocated on a temporary basis. - DRARP_RESPONSE (opcode 6) packets are responses to DRARP_REQUEST packets containing protocol addresses which are not guaranteed to be valid for more than an hour. These could be reallocated to another system after this time elapses, unless a separate protocol is used to ensure that this reallocation does not occur. (These addresses are termed "transient".) All DRARP servers on a network segment must return the same value in a DRARP_RESPONSE packet. - RARP_RESPONSE (opcode 4) packets may be sent in response to DRARP_REQUEST packets if the address returned is not subject to automatic reallocation. (These are termed "persistent". They get reallocated too, only LOTS more slowly.) - DRARP_ERROR (opcode 7) packets may be sent in response to DRARP_REQUESTs. The format is that of a RARP_RESPONSE, but the the target protocol address field is instead used to encode an error status describing why no target protocol address is being returned. The codes are all one byte long (on the grounds that all protocol addresses are at least one byte long). The currently defined codes are: DRARPERR_RESTRICTED (1) -- This network does not support dynamic address assignment. The response is definitive; the network is controlled so that no other response to a DRARP_REQUEST is possible right now. DRARPERR_NOADDRESSES (2) -- This network supports dynamic address assignment, but all available network (or subnetwork) protocol addresses have been allocated, so that none can be allocated now. DRARPERR_SERVERDOWN (3) -- A transient failure to allocate an address, due for example to a server being unavailable, or allocation just taking a long time. DRARPERR_MOVED (4) -- Analagous to DRARPERR_RESTRICTED, but with the additional information that the system is recognized as being on the "wrong" network. DRARPERR_FAILURE (5) -- Some other failure mode resulted in an inability to allocate an address. Assigning addresses using DRARP_RESPONSE requires a network-wide (or subnetwork-wide) address assignment authority. If such an authority is not present, no DRARP_RESPONSE or DRARP_ERROR packets may be sent. DRARP servers should probe for spurious DRARP servers, which might have a different idea of who the address authority is. They should probe the a network to see if a transient address has been seized by some other system before handing it out in a DRARP_RESPONSE packet. There are a number of problems that are tough in an Internet environment. For example, who really has authority to allocate addresses? AppleTalk only has transient addressing, but in IP land you can have addresses persistently allocated by someone you didn't think really had the authority. You can't rely on nameserver reverse address lookups on today's networks. Also, handing out transient addresses emphasizes what a bad idea it is to base any security scheme on IP addresses. On an Ethernet, you can always just grab an address you've got a hankering for, but somehow sites still keep trusting IP addresses. (Steve Bellovin's article had a lot more issues than just ARP level theft.) There are a number of additional problems to solve if you want to do any sort of automatic system installation, beyond just getting an address: - Getting the subnet mask. - Getting a router address. - Persistently allocating a name. - Sometimes, allocating server resources. - Selecting one of several zones on the network. - Proving the system's identity on the network. - Determining the system's role in running the network. AppleTalk standardizes the routing stuff (netmask, router address), but it's missing the concepts of persistent network entities and systems interdependence (a diskless client and its server). A system's whole network configuration changes every time it joins a network. Which isn't an inaccurate model for most systems (i.e. ones with disks), but it ends up looking rather Byzantine after a while even there. For the Sun386i, we got automatic system installation up to the point that you could do manual setup of one machine (the "master server") and the rest could either automatically install themselves, or tell you why they couldn't. It interoperates with existing networks ("just turn it off"). David Brownell dbrownell@sun.com Sun Entry Systems Software sun!suneast!db Billerica, MA
jkrey@VENERA.ISI.EDU (08/15/89)
The draft RFC by Sun Microsystems (specifically David Brownell) on DRARP is pending resubmission to the RFC Editor. JKREY
dab@VAX.FTP.COM (08/16/89)
It seems that BOOTP would have made a better base to do dynamic address assignment from than RARP. Why the choice? David Bridgham