braden@VENERA.ISI.EDU (10/04/88)
Hello. RFC-1048 "BOOTP Vendor Information Extensions" by Philip Prindeville defined additional BOOTP fields and a format for vendor-specific extensions. I would like to know if anyone out there (1) has implemented, or (2) plans to implement, any of the extensions described in this RFC. Thanks. Bob Braden
ddp+@ANDREW.CMU.EDU (Drew Daniel Perkins) (10/05/88)
It seems that quite a few people have implemented it or will be soon. I can think of atleast two vendors with RFC 1048 compliant clients, and I remember hearing from a few others. We (CMU) have a functional RFC 1048 BOOTP server that we will be distributing very soon. We are currently adding truly dynamic IP address assignment similar in concept to what MACs use. Drew
tmt@xpiinc.UUCP (Thomas M. Talpey) (10/06/88)
The new Visual V640 X Display Station (XDS) supports the BOOTP rfc1048 extensions plus the CMU vendor structure. Currently, the fields parsed are the gateway, netmask, and name servers, as only those are of interest to the device. The parameters are supplemented or overridden by user-provided local setup. If you haven't heard of the machine, it is an X (version 11) server running in a terminal, over Ethernet and SLIP. The code is completely in ROM and the machine does BOOTP (and RARP) if the IP address is not configured into its local setup. With the extensions provided by rfc1048, plus some help from the BOOTP server in providing an address, it is possible with no configuration to take the machine out of the box, plug it in, and come up running X. Most RARP and BOOTP servers currently require pre-configuration of the Ethernet addresses, however, and will not reply to an unknown device. Therefore an administrator must do something first, but BOOTP with rfc1048 makes the hard part painless. By the way, this machine begins a new Ethernet manufacturer ID field for those interested, Visual Technology has been assigned 00:00:22. Tom Talpey Xpi Inc. tmt@xpiinc.uu.net Info on V640 XDS: Visual Technology (508) 459-4903 (800) VISUAL-C
morgan@Jessica.stanford.edu (RL "Bob" Morgan) (10/07/88)
Drew Perkins writes: > It seems that quite a few people have implemented [BootP extensions] > or will be soon. I can think of at least two vendors with RFC 1048 > compliant clients, and I remember hearing from a few others. Which vendors? > We (CMU) have a functional RFC 1048 BOOTP server that we will be > distributing very soon. We are currently adding truly dynamic IP > address assignment similar in concept to what MACs use. Hmm. I've been thinking a lot about dynamic address assignment myself. I'd be curious to hear how (or if) you handle 1) ARP caches in hosts and gateways, as BootP clients cycle through dynamically assigned addresses; 2) redundancy (that is, can you have a backup dynamic address server?); 3) multiple subnet service (that is, is the server restricted to providing service to clients on its own subnet?). - RL "Bob" Morgan Networking Systems Stanford
mar@ATHENA.MIT.EDU (10/08/88)
We are examining dynamic address assignment here at Project Athena too. However, we are not happy with BootP and RARP because they require advance configuration of the servers. We are designing a new protocol for complete on-the-fly generation of new addresses along with assignment of netmask, broadcast address, and default gateway. Once the network interface is properly configured, it is possible to go through gateways to servers elsewhere for more information. Hopefully we will have a draft RFC available very soon. -Mark Rosenstein Project Athena Systems Development
croft@CSLI.STANFORD.EDU (10/08/88)
> From: <mar@ATHENA.MIT.EDU> > > We are examining dynamic address assignment here at Project Athena > too. However, we are not happy with BootP and RARP because they > require advance configuration of the servers. We are designing a new > protocol for complete on-the-fly generation of new addresses along... BOOTP protocol itself doesnt require advance configuration of the servers, it is simply that the original BOOTP server was written this way. As CMU mentioned, it is possible to write a BOOTP server that supports allocation and management of dynamic IP addresses. If you have a distributed server environment, the SERVERS might have a dynamic 'voting' style protocol that they use amongst themselves to divide allocation decisions. But this protocol could be separate from the client-oriented BOOTP, which is kept simple to fit within boot prom situations.
ddp+@ANDREW.CMU.EDU (Drew Daniel Perkins) (10/08/88)
> *Excerpts from ext.in.tcp-ip: 7-Oct-88 Re: BOOTP Extensions RL "Bob"* > *Morgan@labrea.s (901)* > 1) ARP caches in hosts and gateways, as BootP clients cycle through > dynamically assigned addresses; The ARP caches are expected to timeout faster than the BOOTP server timesout addresses. Reasonable ARP implementations should do this, although many ARP implementations out there are not that reasonable... > 2) redundancy (that is, can you have a backup dynamic address server?); Yes, we plan on having redundant servers. There are a number of possible ways to do this, and we plan on experimenting a bit to see which would be best. Possibilites are: 1. Uncoordinated servers each use a separate range of addresses. If the client doesn't use the address assigned by a particular server then it should time out quickly. 2. Statically assign or dynamically elect primary/secondary labels for servers. The secondary servers could watch to see if the primary dies using a separate protocol or based on the seconds-since-boot field in the BOOTP request. When the primary assigns an address it must also update the secondaries somehow. This also brings up the issue of keeping track of dynamic assignments across crashes. > 3) multiple subnet service (that is, is the server restricted to > providing service to clients on its own subnet?). No the server can serve multiple subnets using the gateway field in the BOOTP request in order to determine the source subnet. This does limit you to one dynamic subnet per cable though. Drew
deering@PESCADERO.STANFORD.EDU (Steve Deering) (10/09/88)
From <mar@ATHENA.MIT.EDU>: ...We are designing a new protocol for complete on-the-fly generation of new addresses along with assignment of netmask, broadcast address, and default gateway. ... In general, a single default gateway address is insufficient (assuming there is more than one gateway on the subnet), because that single gateway may fail, leaving the host unable to communicate off-subnet despite the presence of other operational gateways. The draft Host Requirements RFC recommends that a host be configured with a *set* of default gateway addresses. The Host Requirements working group is also working on a proposal for dynamic discovery of all operational gateways on a single subnet, using multicast or broadcast where available. Regarding on-the-fly generation of host addresses, doesn't the small size of IP addresses present a fundamental problem? Many networks are class C or subnetted class B, with only 8 bits of host number. If the host population is large or very volatile, you will have to recycle addresses, but in the absence of human administrative control, there is no way to determine reliably that an address is free for reassignment. You can't just poll an address to see if it is in use, because the user of the address may be temporarily unreachable from the system that assigns the addresses. Are you planning to handle address recycling? Steve