rwolski@lll-crg.llnl.gov (Richard Wolski) (04/03/91)
Profuse apologies to those of you who have seen this before. I am posting this request for a friend with a somewhat unreliable news feed. Thanks for your patience, Rich =============================================== Sorry if you have seen this before, but my news feed has been flakey lately and I haven't seen it posted. Hi. I have some questions about bootp that someone out there might be able to answer. Is the bootp 2.1 (cmu) the must current version? What other versions are there out there (and where can I get them)? Is bootp the most widely used protocol to boot up network devices? Are there others? Has anyone run up against the 64 byte limitation of vendor specific data? If so, what did you do you about it? What is the method for specifying a vendor magic cookie (do you have to modify the boop server source?). Thanks any information will be appreciated! If I get responses, I will post the replies. Emily Hipp ehipp@wrs.com
ww0n+@ANDREW.CMU.EDU (Walter Lloyd Wimer III) (04/05/91)
Emily, > Hi. > I have some questions about bootp that someone out > there might be able to answer. > Is the bootp 2.1 (cmu) the must current version? > What other versions are there out there > (and where can I get them)? Bootpd 2.1 is the most recent release of bootpd from CMU. I have not had time to work on it in quite a while, but I will again eventually. The IETF Dynamic Host Configuration Working Group is working on a new Dynamic Host Configuration Protocol (DHCP) based on BOOTP. I will eventually be writing and releasing a DHCP server which will work with DHCP clients and old BOOTP clients. A number of people have suggested improvements to CMU's bootpd. Several have added their own local extensions or ported it to other operating systems (Unix System V, MS-DOS, VMS). Unfortunately, there hasn't been much effort to coordinate these versions or gather them together in a single place (largely my fault for being unable to devote the time). As such, I don't really know where to find these other versions. I know of no independently-developed BOOTP servers; all seem to be derivations of the Stanford/CMU bootpd for BSD Unix. (Someone please correct me if I am wrong!) The CMU distribution of bootpd is available via anonymous FTP from LANCASTER.ANDREW.CMU.EDU (128.2.13.21) in the file pub/bootp.2.1.tar. This is actually a slightly newer version which calls itself 2.1a. It includes just a few minor bug fixes which were often reported to me. > Is bootp the most widely used protocol > to boot up network devices? Are there others? RARP provides another alternative for assigning IP addresses to booting hosts. It only deals with the IP address assignment issue (unlike BOOTP which can also pass information such as the subnet mask, default router(s), etc.). RARP is a link-layer protocol, so it cannot work across routers like BOOTP can. There are other protocols which deal with various aspects of the network boot problem. The DHC "Problem Statement" Internet Draft touches on some of them. This was available via anonymous FTP from NNSC.NSF.NET in the internet-drafts/ directory, but seems to have disappeared (it probably expired). > Has anyone run up against the 64 byte limitation > of vendor specific data? If so, what did you > do you about it? Yes, CMU certainly has and I know others have. The DHCWG is trying to address this problem as well. One suggestion has been to modify both BOOTP clients and servers to simply send larger packets. In many instances, the network manager knows the minimum MTU (Maximum Transmission Unit) between the BOOTP server and a given client. The BOOTP server could be configured with this information and could then send a packet up to that size. I must stress that, so far, this is only a suggestion and is not guaranteed to work in all environments, etc., etc. Another suggestion is to use the vendor field to communicate a file name containing configuration information and then use TFTP or something to transfer that file. > What is the method for specifying a vendor > magic cookie (do you have to modify > the boop server source?). Yes; this is really the only way if you don't want to use the CMU or RFC1084/RFC1048 formats. Bootpd does contain some code to let you specify an arbitrary vendor magic cookie, but there is no way to then specify what actual information should go in the remaining 60 octets. This is one of those features that was sort-of half-implemented and then forgotten/abandoned. Note that you can stick with RFC1084/RFC1048 format and define your own custom tags with the generic tag ":Tn=xxxx:" bootptab construct. From RFC1084: Reserved Fields (Tag: 128-254, Data: N bytes of undefined content) Specifies additional site-specific information, to be interpreted on an implementation-specific basis. This should follow all data with the preceding generic tags 0- 127). > Thanks any information will be appreciated! > If I get responses, I will post the replies. There is also a mailing list devoted to open discussion about BOOTP and questions such as yours. The submission address is: bootp@andrew.cmu.edu In the Internet tradition, please send requests to be added to or removed from the mailing list to: bootp-request@andrew.cmu.edu > Emily Hipp > ehipp@wrs.com Walt Wimer Network Development Carnegie Mellon University
barmar@think.com (Barry Margolin) (04/05/91)
In article <Ibyt2Ki00WCp44dZAH@andrew.cmu.edu> ww0n+@ANDREW.CMU.EDU (Walter Lloyd Wimer III) writes: >RARP provides another alternative for assigning IP addresses to booting >hosts. It only deals with the IP address assignment issue (unlike BOOTP >which can also pass information such as the subnet mask, default >router(s), etc.). RARP is a link-layer protocol, so it cannot work >across routers like BOOTP can. Why couldn't an RARP server rebroadcast the RARP request on another subnet, and then forward the response back to the original host? BOOTP's "routing" is done at the application layer, because IP-layer routing requires the client to know most of the information it is trying to find out from the BOOTP server. Since BOOTP does its routing at the application layer, so could RARP. -- Barry Margolin, Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar