Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15090; 1 Mar 95 21:22 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa15086; 1 Mar 95 21:22 EST Received: from sol.cs.bucknell.edu by CNRI.Reston.VA.US id aa19388; 1 Mar 95 21:22 EST Received: from shiva1.cac.washington.edu by sol.cs.bucknell.edu (4.1/Bucknell-2.0) id ; Wed, 1 Mar 95 21:08:21 EST Received: by shiva1.cac.washington.edu (5.65+UW95.02/UW-NDC Revision: 2.32 ) id AA13345; Wed, 1 Mar 95 18:08:11 -0800 Date: Wed, 1 Mar 1995 18:08:07 -0800 (PST) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: John Carlson To: host-conf@sol.cs.bucknell.edu Subject: Client identifier In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Several years ago, the University of Washington began using bootp to issue "permanent" IP addresses to PCs running client software written by an employee of the UW. Since the software was first introduced, thousands of IPs have been issued via this software (there are currently ~15,000 hosts connected to the campus net, many of which obtained IPs by other means). Among other things, the server was designed to help with administrative tracking by using the clients MAC address. It has been my experience that use of the MAC address as a tracking device is NOT a good thing. As the quote from section 4.2 of rfc1541 below suggests, hardware interfaces are often moved about and so tracking by MAC address becomes riddled with inaccuracies. I would like to see both rfc1541 and rfc1533 (see excerpt below) state explicitly that the client identifier option (granted "option" is a bit of a misnomer) be mandatory and that it not be the MAC address. If there is a strong desire to use the MAC address within the identifier string, perhaps the MAC address could be combined with some other string, such as the value of the rightmost 3 bits of the current time at the initial dhcp request or a user entered string or ... etc. rfc1541 (draft-ietf-dhc-dhcp-00.txt) 4.2 [...] to use unique identifiers in the 'client identifier' option. Use of 'chaddr' as the client's unique identifier may cause unexpected results, as that identifier may be associated with a hardware interface that could be moved to a new client. Some sites may choose to use a manufacturer's serial number as the 'client identifier', to avoid unexpected changes in a clients network address due to transfer of hardware interfaces among computers. Sites may also choose to use [...] rfc1533 9.12 [...] It is expected that this field will typically contain a hardware type and hardware address, but this is not required. Current legal values for hardware types are defined in [22]. [...] johnc ------------------------------------------------------------------------------- John D. Carlson Networks and Distributed Computing EMAIL: johnc@cac.washington.edu University of Washington BELL: (206) 685-6204 4545 15th Ave NE FAX: (206) 685-4044 Seattle, WA 98105   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14660; 2 Mar 95 17:05 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa14656; 2 Mar 95 17:05 EST Received: from sol.cs.bucknell.edu by CNRI.Reston.VA.US id aa16324; 2 Mar 95 17:05 EST Received: from netmail2.microsoft.com by sol.cs.bucknell.edu (4.1/Bucknell-2.0) id ; Thu, 2 Mar 95 16:51:11 EST Received: by netmail2.microsoft.com (5.65/25-eef) id AA18964; Thu, 2 Mar 95 13:51:59 -0800 Received: by netmail2 using fxenixd 1.0 Thu, 02 Mar 95 13:51:59 PST Message-Id: <9503022111.AA28958@itgmsm> Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: jamesg@microsoft.com To: host-conf@sol.cs.bucknell.edu Subject: RE: Client identifier Date: Thu, 02 Mar 95 13:11:00 PST X-Mailer: Microsoft Mail V3.0 John, I'm not sure I completely understand your concerns, but I basically disagree. The MAC address -- with whatever decoration a particular implementation desires -- is far and away the BEST client identifier. 1) It is unique. 2) It is known by the client. Nothing else really fits the bill. If you create another client id in a way that takes user input, then you are defeating one purpose of DHCP. You've just eliminated setup/tracking of IP addresses and replaced it by setup/tracking client ids. What's the point? -------------------------------------------- Furthermore, I don't really see the problem expressed in the example. If you swap netcards, then boot back up -- then using some form of MAC address as ID -- you get a NEW address. The MAC address is NOT going to have multiple IP addresses allocated to it, no matter how many times you swap. Admittedly, MAC addresses are not user friendly for administration purposes, like identifying where a machine sits. That's one reason we save hostname information to the database also. --------------------------------------------- The fundamental problem here seems to be a notion that machines somehow need to sit at the same IP address permanently. Historically this has been true. But there's no particular reason for it, and with portables it makes no sense whatsoever. The fact that IP required this logical address that folks had to setup and know is a negative (and ridiculous) feature of TCP/IP. Now with DHCP we are containing the damage. (Still waiting for dynamic DNS.) I've really tried hard to convery this information to our customers, but there's always a few folks locked into their historical mindset, who just don't get it. If there's something that could usefully be added to the draft, I'd suggest a big flashing neon sign: INFINITE leases (permenent IP address) are STUPID and LAME. That's why it's called DYNAMIC Host Configuration Protocol. jim ---------- |From: John Carlson |To: host-conf |Subject: Client identifier |Date: Wednesday, March 01, 1995 6:08PM | | |Several years ago, the University of Washington began using bootp to |issue "permanent" IP addresses to PCs running client software written |by an employee of the UW. Since the software was first introduced, |thousands of IPs have been issued via this software (there are currently |~15,000 hosts connected to the campus net, many of which obtained IPs by |other means). Among other things, the server was designed to help with |administrative tracking by using the clients MAC address. It has been my |experience that use of the MAC address as a tracking device is NOT a good |thing. As the quote from section 4.2 of rfc1541 below suggests, hardware |interfaces are often moved about and so tracking by MAC address becomes |riddled with inaccuracies. | |I would like to see both rfc1541 and rfc1533 (see excerpt below) state |explicitly that the client identifier option (granted "option" is a bit |of a misnomer) be mandatory and that it not be the MAC address. If there |is a strong desire to use the MAC address within the identifier string, |perhaps the MAC address could be combined with some other string, such as |the value of the rightmost 3 bits of the current time at the initial dhcp |request or a user entered string or ... etc. | | |rfc1541 (draft-ietf-dhc-dhcp-00.txt) 4.2 | |[...] | to use unique identifiers in the 'client identifier' option. Use of | 'chaddr' as the client's unique identifier may cause unexpected | results, as that identifier may be associated with a hardware | interface that could be moved to a new client. Some sites may choose | to use a manufacturer's serial number as the 'client identifier', to | avoid unexpected changes in a clients network address due to transfer | of hardware interfaces among computers. Sites may also choose to use |[...] | | |rfc1533 9.12 | |[...] | It is expected that this field will typically contain a hardware type | and hardware address, but this is not required. Current legal values | for hardware types are defined in [22]. |[...] | | |johnc |--------------------------------------------------------------------------- ---- |- |John D. Carlson |Networks and Distributed Computing EMAIL: johnc@cac.washington.edu |University of Washington BELL: (206) 685-6204 |4545 15th Ave NE FAX: (206) 685-4044 |Seattle, WA 98105 |   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa16160; 2 Mar 95 18:26 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa16156; 2 Mar 95 18:26 EST Received: from sol.cs.bucknell.edu by CNRI.Reston.VA.US id aa17776; 2 Mar 95 18:26 EST Received: from shiva1.cac.washington.edu by sol.cs.bucknell.edu (4.1/Bucknell-2.0) id ; Thu, 2 Mar 95 18:12:20 EST Received: by shiva1.cac.washington.edu (5.65+UW95.02/UW-NDC Revision: 2.32 ) id AA14533; Thu, 2 Mar 95 15:12:16 -0800 Date: Thu, 2 Mar 1995 15:12:15 -0800 (PST) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: John Carlson To: jamesg@microsoft.com Cc: host-conf@sol.cs.bucknell.edu Subject: RE: Client identifier In-Reply-To: <9503022111.AA28958@itgmsm> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Jim, Thanks for the reply. I think I may not have been very clear in my original message. I did *not* intend to suggest that I would like to replace tracking of ip addresses with tracking of client ids. And I did not intend to convey that permanent addresses are a good thing. In fact, I'm very much looking forward to the potential benefits to be derived from dhcp's leasing scheme. We plan to accomadate users drifting from dorm room to classroom to lab to ..., each carrying some version of portable computer and acquiring an IP for each occasion. In fact, I see value in obtaining the MAC address of an host. It can come in handy when tracking problems (eg. use in examining a router arp cache, sniffer output,...). My concern has to do with using the MAC address as a portion of the database key, mapping to values associated with this particular system (eg. the issued IP). I would like to see this key be as stable as possible. Please see my comments below. On Thu, 2 Mar 1995 jamesg@microsoft.com wrote: > Date: Thu, 02 Mar 95 13:11:00 PST > From: jamesg@microsoft.com > To: host-conf@sol.cs.bucknell.edu > Subject: RE: Client identifier > > > > John, > > I'm not sure I completely understand your concerns, but I basically > disagree. > > The MAC address -- with whatever decoration a particular implementation > desires -- is far and away the BEST client identifier. > 1) It is unique. > 2) It is known by the client. > > Nothing else really fits the bill. If it is true that nothing else fits these two criteria, then I would have to agree that the MAC address would need to be used. > If you create another client id in a > way that takes user input, then you are defeating one purpose of DHCP. I agree. Plug-n-play is crucial. That is why I suggested the possible use of some number of bits of current time combined with the MAC address (assuming nothing other than the MAC address fits the two criteria you list above) as one method. However, the resulting value would need to be permanently stored (by some means). > You've just eliminated setup/tracking of IP addresses and replaced it by > setup/tracking client ids. What's the point? What I want to do is use a unique, persistent value as a key into a database which will allow me to track a set of parameters associated with a given system. I want to eliminate the use of the MAC address as a portion of this key as it has proven to be extremely volatile in some environments. So I guess I don't understand your assessment. > > -------------------------------------------- > > Furthermore, I don't really see the problem expressed in the example. If > you swap netcards, then boot back up -- then using some form of MAC address > as ID -- you get a NEW address. This is true. On the otherhand, I have trouble with the idea that each time a system is shutdown it sends a DHCPRELEASE. This implies that every system with a DNS registered name will cause a change in the DNS database whenever someone turns off the power to their PC. In our environment, where potentially thousands of systems will fit this scenario, I see a rather stressful situation for the DNS. (at a large university, where classes all begin and end at nearly the same time, imgine thousands of users starting and stopping their laptops, nearly simultaneously, as they move from one net to another [yes, classrooms, if not already, will be wired]). > The MAC address is NOT going to have > multiple IP addresses allocated to it, no matter how many times you swap. Good point (with the additional qualifier "on a given net"). > > Admittedly, MAC addresses are not user friendly for administration purposes, > like identifying where a machine sits. That's one reason we save hostname > information to the database also. > > --------------------------------------------- > > The fundamental problem here seems to be a notion that machines somehow need > to sit at the same IP address permanently. Historically this has been > true. But there's no particular reason for it, and with portables it makes > no sense whatsoever. The fact that IP required this logical address that > folks had to setup and know is a negative (and ridiculous) feature of > TCP/IP. Now with DHCP we are containing the damage. (Still waiting for > dynamic DNS.) Agreed. > > I've really tried hard to convery this information to our customers, but > there's always a few folks locked into their historical mindset, who just > don't get it. > > If there's something that could usefully be added to the draft, I'd suggest > a big flashing neon sign: > > INFINITE leases (permenent IP address) are STUPID and LAME. I pretty much agree, but I feel that we need to try and understand what exactly will be required of the DNS. > > That's why it's called DYNAMIC Host Configuration Protocol. Sounds right to me. johnc > > jim > > ---------- > |From: John Carlson > |To: host-conf > |Subject: Client identifier > |Date: Wednesday, March 01, 1995 6:08PM > | > | > |Several years ago, the University of Washington began using bootp to > |issue "permanent" IP addresses to PCs running client software written > |by an employee of the UW. Since the software was first introduced, > |thousands of IPs have been issued via this software (there are currently > |~15,000 hosts connected to the campus net, many of which obtained IPs by > |other means). Among other things, the server was designed to help with > |administrative tracking by using the clients MAC address. It has been my > |experience that use of the MAC address as a tracking device is NOT a good > |thing. As the quote from section 4.2 of rfc1541 below suggests, hardware > |interfaces are often moved about and so tracking by MAC address becomes > |riddled with inaccuracies. > | > |I would like to see both rfc1541 and rfc1533 (see excerpt below) state > |explicitly that the client identifier option (granted "option" is a bit > |of a misnomer) be mandatory and that it not be the MAC address. If there > |is a strong desire to use the MAC address within the identifier string, > |perhaps the MAC address could be combined with some other string, such as > |the value of the rightmost 3 bits of the current time at the initial dhcp > |request or a user entered string or ... etc. > | > | > |rfc1541 (draft-ietf-dhc-dhcp-00.txt) 4.2 > | > |[...] > | to use unique identifiers in the 'client identifier' option. Use of > | 'chaddr' as the client's unique identifier may cause unexpected > | results, as that identifier may be associated with a hardware > | interface that could be moved to a new client. Some sites may choose > | to use a manufacturer's serial number as the 'client identifier', to > | avoid unexpected changes in a clients network address due to transfer > | of hardware interfaces among computers. Sites may also choose to use > |[...] > | > | > |rfc1533 9.12 > | > |[...] > | It is expected that this field will typically contain a hardware type > | and hardware address, but this is not required. Current legal values > | for hardware types are defined in [22]. > |[...] > | > | > |johnc > |--------------------------------------------------------------------------- > ---- > |- > |John D. Carlson > |Networks and Distributed Computing EMAIL: johnc@cac.washington.edu > |University of Washington BELL: (206) 685-6204 > |4545 15th Ave NE FAX: (206) 685-4044 > |Seattle, WA 98105 > | >   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa18035; 2 Mar 95 22:13 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa18031; 2 Mar 95 22:13 EST Received: from sol.cs.bucknell.edu by CNRI.Reston.VA.US id aa21635; 2 Mar 95 22:13 EST Received: from hadar.process.com by sol.cs.bucknell.edu (4.1/Bucknell-2.0) id ; Thu, 2 Mar 95 21:55:29 EST Message-Id: <9503030255.AA08298@sol.cs.bucknell.edu> Date: Thu, 2 Mar 1995 21:54 -0500 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Hiroto Shibuya To: host-conf@sol.cs.bucknell.edu Subject: Duplicated client identifier with DHCPDISCOVER X-Vms-To: host-conf X-Vms-Cc: SHIBUYA A question concerning proccessing of DHCPDISCOVER message by the server. What if the server lookup the client identifier in the lease database and find an active record, and then receives a response for pinging that address? It is possible that more than one client were misconfigured with a same client identifier and there is already another one who obtained a lease under the same identifier. Since client identifier must be identical in the database, I cannot offer other address either. Since I cannot NACK in response to DHCPDISCOVER, the best I can do is not to respond to the request and record the error? -- Hiroto Shibuya Process Software Corporation   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa19336; 2 Mar 95 22:46 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa19332; 2 Mar 95 22:46 EST Received: from sol.cs.bucknell.edu by CNRI.Reston.VA.US id aa22092; 2 Mar 95 22:46 EST Received: from ginger.kirc.wide.ad.jp by sol.cs.bucknell.edu (4.1/Bucknell-2.0) id ; Thu, 2 Mar 95 22:34:43 EST Received: (from wkenji@localhost) by ginger.kirc.wide.ad.jp (8.6.9+2.4W/3.3W8) id MAA01474; Fri, 3 Mar 1995 12:34:39 +0900 Date: Fri, 3 Mar 1995 12:34:39 +0900 Message-Id: <199503030334.MAA01474@ginger.kirc.wide.ad.jp> Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Kenji Wakamiya To: host-conf@sol.cs.bucknell.edu Subject: Re: Size of a DHCP/BOOTP admin-domain In-Reply-To: <9502281903.AA18699@itgmsm> References: <9502281903.AA18699@itgmsm> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Hello, Thank you for many response to my question. I'm surprising at the answers that are much larger than I had guessed. jamesg> I think even 2000 is pretty conservative. I've stress tested jamesg> with 30,000 clients each on two subnets. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ (It's a result of simulation?) I also think like that order if paying attention only to the CPU load. But, "DHCP/BOOTP Systems" suffer more various factors, such as network traffic around the server, etc. jamesg> Then servers, at least ours, will be gated by how fast is jamesg> their database access. Yes, that is also an important factor. jamesg> I've seen as few as 1000 clients all trying to rediscover or jamesg> renew cause us problems. (We're working on some jamesg> optimizations.) I change my question to more concretely. For instance, after a power cut, if 1,000 or 30,000 diskless-workstations/X-teminals begin booting at a time, can the server and the network endure the load and the traffic? If they can, then client's waiting time for backoff is proper range? In other words, when we consider such circumstances (peak time), what time is that the multiple-server mechanism is required? (without regard for meaning as backup) thanks. - Kenji Wakamiya, Fujitsu Laboratories Ltd. E-mail: wkenji@flab.fujitsu.co.jp / NIFTY-Serve: NAB02402, GFF01145   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa27019; 3 Mar 95 1:17 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa27015; 3 Mar 95 1:17 EST Received: from sol.cs.bucknell.edu by CNRI.Reston.VA.US id aa24341; 3 Mar 95 1:17 EST Received: from fgwmail.fujitsu.co.jp by sol.cs.bucknell.edu (4.1/Bucknell-2.0) id ; Fri, 3 Mar 95 01:06:39 EST Received: from fdmmail.fujitsu.co.jp by fgwmail.fujitsu.co.jp (8.6.9+2.4W/3.3W5-MX941209-Fujitsu Mail Gateway) id PAA23325; Fri, 3 Mar 1995 15:06:24 +0900 Received: from ace.yk.fujitsu.co.jp by fdmmail.fujitsu.co.jp (8.6.9+2.4W/3.3W5-MX950127-Fujitsu Domain Mail Master) id PAA08167; Fri, 3 Mar 1995 15:06:23 +0900 Received: from shido.yk.fujitsu.co.jp (shido.yk.fujitsu.co.jp [133.162.37.9]) by ace.yk.fujitsu.co.jp (8.6.9+2.4W/3.3W9-95030309) with SMTP id PAA02053 for ; Fri, 3 Mar 1995 15:06:50 +0900 Received: by shido.yk.fujitsu.co.jp (4.1/6.4J.5) id AA12273; Fri, 3 Mar 95 14:50:31 JST Date: Fri, 3 Mar 95 14:50:31 JST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Higashikado Yoshiki Message-Id: <9503030550.AA12273@shido.yk.fujitsu.co.jp> To: host-conf@sol.cs.bucknell.edu Cc: higashi@shido.yk.fujitsu.co.jp Subject: The source port number of DHCP server Hi folks, I have a question concerning with the source port number of DHCP server. I think the destination port number of DHCP messages are defined in previous document( RFC1541 etc.). But I haven not seen any description of the source port number of DHCP message from SERVER. Is there any description about that number ? Thanks, higashi@ace.yk.fujitsu.co.jp   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08116; 3 Mar 95 13:44 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa08112; 3 Mar 95 13:44 EST Received: from sol.cs.bucknell.edu by CNRI.Reston.VA.US id aa12238; 3 Mar 95 13:44 EST Received: from netmail2.microsoft.com by sol.cs.bucknell.edu (4.1/Bucknell-2.0) id ; Fri, 3 Mar 95 13:28:01 EST Received: by netmail2.microsoft.com (5.65/25-eef) id AA25962; Fri, 3 Mar 95 10:28:51 -0800 Received: by netmail2 using fxenixd 1.0 Fri, 03 Mar 95 10:28:47 PST Message-Id: <9503031743.AA00413@itgmsm> Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: jamesg@microsoft.com To: wkenji@ginger.kirc.wide.ad.jp Cc: host-conf@sol.cs.bucknell.edu Subject: Re: Size of a DHCP/BOOTP admin-domain Date: Fri, 03 Mar 95 09:42:00 PST X-Mailer: Microsoft Mail V3.0 Kenji, Specific answers below. But the main points: 1) In throwing around 30,000 clients, I was mainly trying to reiterate Mike's point that DHCP is a low overhead per client protocol. Generally a DHCP server should be able to run on another server box, without much trouble. (In our setup, we run them on the same boxes as our NetBIOS name servers (WINS) which are sucking all the CPU). 2) The power failure problem is implicitly solved by the DHCP protocol. It's not a big problem. jim ---------- |From: wkenji |To: host-conf |Subject: Re: Size of a DHCP/BOOTP admin-domain |Date: Friday, March 03, 1995 12:34PM | |Hello, | | Thank you for many response to my question. I'm surprising at the | answers that are much larger than I had guessed. | |jamesg> I think even 2000 is pretty conservative. I've stress tested |jamesg> with 30,000 clients each on two subnets. | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | (It's a result of simulation?) I also think like that order if | paying attention only to the CPU load. But, "DHCP/BOOTP Systems" | suffer more various factors, such as network traffic around the | server, etc. Unfortunately, upper management is still balking at my request for 60,000 client test boxes. Sometimes I just can't get these guys off the dime. Fortunately, however, while they were off in budget meetings, I wrote a set of DHCP test tools, to configure, send, recv and respond to DHCP packets. I use this mostly to test adherence to the protocol, but also to setup stress scenarios with various numbers of clients. Some clients would DISCOVER and do nothing, others DISCOVER and renew repeatedly. Some would reboot a bunch. A few would DISCOVER and RELEASE and reDISCOVER. Sixty thousand just seemed like a safe number that would cover even what the largest corporations our government agencies would likely have covered by one server. My point wasn't any particular number -- the 30,000/30,000 was a random test scenario with some arbitrary number of packets exchanged -- rather more echoing Mike's point that DHCP on a per client basis is not network or CPU intensive. For normal fairly stable configuration with a reasonable lease time, it approaches two packets per reboot. |jamesg> I've seen as few as 1000 clients all trying to rediscover or |jamesg> renew cause us problems. (We're working on some |jamesg> optimizations.) | | I change my question to more concretely. For instance, after a | power cut, if 1,000 or 30,000 diskless-workstations/X-teminals begin | booting at a time, can the server and the network endure the load | and the traffic? If they can, then client's waiting time for | backoff is proper range? | | In other words, when we consider such circumstances (peak time), | what time is that the multiple-server mechanism is required? | (without regard for meaning as backup) This is an excellent question. But Ralph solved this in the design of the REBOOT semantics. A the simple power failure is NOT a big deal as the clients can boot back up -- and use their current address -- without the server responding. The server doesn't have to be handle all the requests (it might even just be booting back up itself.) The, much less likely, problem we had trouble with was where the server was off-line or disconnected from the net for a long fraction of the lease time, so that 1000 client's were all hanging around trying to rediscover. As I indicated we've noticed we didn't handle it all that well -- a lot of unnecessary packets get sent. We've just made a fix for this to make our queuing more intelligent in these cases, but i've yet to give it a good test to see whether it works well. Frankly I do not think it's a big issue. I think the best solution to this is multiple servers with adequate address space (not always available if client's are on the Internet) and later the DHCP server-to-server protocol. jim |thanks. | |- Kenji Wakamiya, Fujitsu Laboratories Ltd. | E-mail: wkenji@flab.fujitsu.co.jp / NIFTY-Serve: NAB02402, GFF01145 |   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa25017; 4 Mar 95 2:00 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa20063; 3 Mar 95 22:58 EST Received: from sol.cs.bucknell.edu by CNRI.Reston.VA.US id aa23003; 3 Mar 95 22:58 EST Received: from sphinx.ece.wisc.edu by sol.cs.bucknell.edu (4.1/Bucknell-2.0) id ; Fri, 3 Mar 95 22:48:02 EST Received: from F181-162.net.wisc.edu by sphinx.ece.wisc.edu (WE5:5.65c/ES5) id AA05238; Fri, 3 Mar 1995 21:47:58 -0600 Date: Fri, 3 Mar 1995 21:47:58 -0600 Message-Id: <199503040347.AA05238@sphinx.ece.wisc.edu> X-Sender: burger@sphinx.ece.wisc.edu X-Mailer: Windows Eudora Version 1.4.4 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: host-conf@sol.cs.bucknell.edu Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Dick Burger Subject: RE: Client identifier >> That's why it's called DYNAMIC Host Configuration Protocol. Would somebody mind clearing up a simple(ton) question? I keep hearing that one major advantage of DHCP over BOOTP is that the addresses are allocated dynamically. Yet it seems to me that both algorithms must ultimately be allocating from a pool of available IP addresses. What makes DHCP more dynamic than BOOTP? I realize this a RTFM sort of question, but I have done some reading on BOOTP and DHCP, and still can't see the clear distinction. thanks, dB   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10833; 6 Mar 95 15:00 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa10829; 6 Mar 95 15:00 EST Received: from sol.cs.bucknell.edu by CNRI.Reston.VA.US id aa13084; 6 Mar 95 15:00 EST Received: from shiva1.cac.washington.edu by sol.cs.bucknell.edu (4.1/Bucknell-2.0) id ; Mon, 6 Mar 95 14:33:11 EST Received: by shiva1.cac.washington.edu (5.65+UW95.02/UW-NDC Revision: 2.32 ) id AA25820; Mon, 6 Mar 95 11:33:01 -0800 Date: Mon, 6 Mar 1995 11:33:00 -0800 (PST) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: John Carlson To: Dick Burger Cc: host-conf@sol.cs.bucknell.edu Subject: RE: Client identifier In-Reply-To: <199503040347.AA05238@sphinx.ece.wisc.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Dick, In my opinion, the most significant promising improvement of dhcp over bootp is the ability to issue addresses for a finite period of time, which eliminates the need for manual intervention when reaping addresses at some later date. Perhaps this is an additional feature (over bootp) people think of when suggesting, in the context of bootp vs. dhcp, that dhcp is dynamic. johnc On Fri, 3 Mar 1995, Dick Burger wrote: > Date: Fri, 3 Mar 1995 21:47:58 -0600 > From: Dick Burger > To: host-conf@sol.cs.bucknell.edu > Subject: RE: Client identifier > > > >> That's why it's called DYNAMIC Host Configuration Protocol. > > > Would somebody mind clearing up a simple(ton) question? I keep hearing that > one major advantage of DHCP over BOOTP is that the addresses are allocated > dynamically. Yet it seems to me that both algorithms must ultimately be > allocating from a pool of available IP addresses. What makes DHCP more > dynamic than BOOTP? > > I realize this a RTFM sort of question, but I have done some reading on > BOOTP and DHCP, and still can't see the clear distinction. > > thanks, > dB > >   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10618; 7 Mar 95 14:26 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa10614; 7 Mar 95 14:26 EST Received: from sol.cs.bucknell.edu by CNRI.Reston.VA.US id aa12464; 7 Mar 95 14:26 EST Received: from shiva1.cac.washington.edu by sol.cs.bucknell.edu (4.1/Bucknell-2.0) id ; Tue, 7 Mar 95 14:02:53 EST Received: by shiva1.cac.washington.edu (5.65+UW95.02/UW-NDC Revision: 2.32 ) id AA13923; Tue, 7 Mar 95 11:02:52 -0800 Date: Tue, 7 Mar 1995 11:02:49 -0800 (PST) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: John Carlson To: host-conf@sol.cs.bucknell.edu Subject: DHCPDECLINE In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Has anyone, writing a server implementation, addressed the issue of limiting the ability of a rogue client from using: 4.3.3 DHCPDECLINE message If the server receives a DHCPDECLINE message, the client has discovered through some other means that the suggested network address is already in use. The server MUST mark the network address as not available and SHOULD notify the local system administrator of a possible configuration problem. to create a denial of service situation? Is this a tractable problem? Thanks, johnc   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15998; 20 Mar 95 2:35 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa15994; 20 Mar 95 2:35 EST Received: from sol.cs.bucknell.edu by CNRI.Reston.VA.US id aa18192; 20 Mar 95 2:35 EST Received: from nasu.sfc.wide.ad.jp by sol.cs.bucknell.edu (4.1/Bucknell-2.0) id ; Mon, 20 Mar 95 02:16:39 EST Received: from sfc.wide.ad.jp by nasu.sfc.wide.ad.jp (8.6.9/2.7W) id QAA03331; Mon, 20 Mar 1995 16:16:35 +0900 Return-Path: Message-Id: <199503200716.QAA03331@nasu.sfc.wide.ad.jp> To: host-conf@sol.cs.bucknell.edu, bsdi-users@bsdi.com Subject: WIDE version DHCP software release! Reply-To: dhcp-dist@wide.ad.jp X-Mailer: Mew beta version 0.82+ on Emacs 19.28.1, Mule 2.2 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Date: Mon, 20 Mar 1995 16:15:27 +0900 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Akihiro Tominaga WIDE Project have implemented DHCP software and prepared for release, and now we are pleased to announce the release. Our implementation, WIDE DHCP version 1.2.1 has following features; a. Packege includes all module (server, client, relay agent) with Full Source Code. b. They are running on SunOS 4.1.3, BSD/OS 2.0, BSD/386 1.1 and other BSD UNIX without re-configuration of Kernel. c. Basically, they are available as free (there are some restrictions). And also you can re-distribute them. (*1) Package is available via anonymous ftp from; ftp://sh.wide.ad.jp/WIDE/free-ware/dhcp/dhcp-1.2.1.tar.gz Please send any comments, bug reports and questions to dhcp-dist@wide.ad.jp. (*1) There are some restrictions. Please see LICENSE at the end of this message. -- WIDE Project. Keio UNIV. Akihiro Tominaga (tomy@sfc.wide.ad.jp) *** LICENSE, from here *** ========================================================================== READ THE FOLLOWING LICENSE AGREEMENT CAREFULLY BEFORE INSTALLING AND/OR USING THE SOFTWARE. By installing and/or using the software, you indicate your acceptance of the following "Usage and Redistribution License Agreement of the WIDE Project DHCP Implementation Package" ("Agreement"). If you do not agree to the terms of this Agreement, promptly delete the software from your computer and cease use of the software. ====================================================================== Usage and Redistribution License Agreement of the WIDE Project DHCP Implementation Package February 1995. (1) The Usage and Redistiribution License Agreement of the WIDE Project DHCP Implementation Package permits you to make and use an unlimited number of copies of the WIDE Project DHCP software package identified (hereafter referred to as "SOFTWARE") for your internal use provided that: (a) the SOFTWARE is not modified in any way and (b) All copyright notices are maintained on every copy of the SOFTWARE. (2) The SOFTWARE (includes all source code, documentation, object files and any other files incorporated into the SOFTWARE) is owned by Akihiro Tominaga ("the AUTHOR") and WIDE Project and is protected by Japan copyright laws and international treaty provisions. You may not rent or lease the SOFTWARE, but you may redistribute the SOFTWARE provided you do not make any modifications to the SOFTWARE. (3) You may not use or include this SOFTWARE in whole or in part for any of your software products. Commercial use of the SOFTWARE requires specific permission from both the author and the WIDE Project. You must contact the WIDE Project if you wish to use the SOFTWARE for your product. You may not use the SOFTWARE and the name of the WIDE Project in advertising or publicity pertaining to the SOFTWARE and documentation without specific, written prior authorization. (4) You may modify the source code of the SOFTWARE only for your internal use. You may not distribute your modifications to the SOFTWARE. Your modifications must be notified to the WIDE Project. (5) NO WARRANTIES. TO THE MAXIMUM EXTENT PERMITTED BY APPLICABLE LAW, THE WIDE PROJECT AND THE AUTHOR OF THE SOFTWARE DISCLAIM ALL WARRANTIES, EITHER EXPRESS OR IMPLIED INCLUDING BUT NOT LIMITED TO IMPLIED WARRANTIES OF MERCHANTABILTIY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. NEITHER THE WIDE PROJECT NOR THE AUTHOR OF THE SOFTWARE SHALL BE LIABLE FOR ANY DAMAGES WHATSOEVER, INCLUDING DIRECT, INDIRECT, LOST PROFITS OR INFORMATION, BUSINESS INTERRUPTION, OR OTHER PECUNIARY LOSS, EVEN IF THE WIDE PROJECT AND THE AUTHOR HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. THE WIDE PROJECT AND THE AUTHOR OF THE SOFTWARE MAKE NO REPRESENTATIONS ABOUT THE SUITABILITY OF THIS SOFTWARE AND DOCUMENTATION FOR ANY PURPOSE WITHOUT EXPRESS OR IMPLIED WARRANTY. *** to here ***   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05195; 22 Mar 95 11:10 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa05191; 22 Mar 95 11:10 EST Received: from sol.cs.bucknell.edu by CNRI.Reston.VA.US id aa08856; 22 Mar 95 11:10 EST Received: from kantti.helsinki.fi by sol.cs.bucknell.edu (4.1/Bucknell-2.0) id ; Wed, 22 Mar 95 10:55:10 EST Received: from karhu.Helsinki.FI (jjmaenpa@karhu [128.214.4.13]) by kantti.helsinki.fi (8.6.10+Emil1.1/8.6.5) with SMTP id RAA17626 for ; Wed, 22 Mar 1995 17:54:44 +0200 Date: Wed, 22 Mar 1995 17:54:41 +0200 (EET) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Jari Maenpaa X-Sender: jjmaenpa@karhu.Helsinki.FI To: host-conf@sol.cs.bucknell.edu Subject: unsubscribe Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII unsubscribe Jari.Maenpaa@cs.helsinki.fi   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09645; 22 Mar 95 14:58 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa09641; 22 Mar 95 14:58 EST Received: from sol.cs.bucknell.edu by CNRI.Reston.VA.US id aa13498; 22 Mar 95 14:58 EST Received: from mail1.digital.com by sol.cs.bucknell.edu (4.1/Bucknell-2.0) id ; Wed, 22 Mar 95 14:30:18 EST Received: from xirtlu.zk3.dec.com by mail1.digital.com; (5.65 EXP 2/22/95 for V3.2/1.0/WV) id AA08001; Wed, 22 Mar 1995 11:21:57 -0800 Received: by xirtlu.zk3.dec.com; id AA07916; Wed, 22 Mar 1995 14:20:47 -0500 Message-Id: <9503221920.AA07916@xirtlu.zk3.dec.com> To: host-conf@sol.cs.bucknell.edu Cc: bound@zk3.dec.com Subject: DHCPv6 Draft Version 2 Date: Wed, 22 Mar 95 14:20:41 -0500 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: bound@zk3.dec.com X-Mts: smtp Folks, ID will be announced later this week. What I have done is put a copy at gatekeeper.dec.com /pub/DEC/IPv6. For your early review too. The copy on gatekeeper also has the change-bars in that version of the draft from the previous version per the input. We will be presenting an overview of this draft and hot issues at Danvers IETF and assume folks have read the draft. thanks /jim   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01579; 23 Mar 95 8:27 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa01575; 23 Mar 95 8:27 EST Received: from sol.cs.bucknell.edu by CNRI.Reston.VA.US id aa04354; 23 Mar 95 8:27 EST Received: from thdhub.HomeDepot.COM by sol.cs.bucknell.edu (4.1/Bucknell-2.0) id ; Thu, 23 Mar 95 08:12:47 EST Received: from cpfsat2a4.homedepot.com by thdhub.HomeDepot.COM with SMTP (1.38.193.5/16.2) id AA28127; Thu, 23 Mar 1995 08:13:11 -0500 Posted-Date: Thu, 23 Mar 1995 08:13:45 EST Received-Date: Thu, 23 Mar 1995 08:13:11 -0500 Received: from AT2A4/SMTP by at2a4 (Mercury 1.11); Thu, 23 Mar 95 8:13:56 est Received: from SMTP by AT2A4 (Mercury 1.11); Thu, 23 Mar 95 8:13:47 est Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Hale, C.A." Organization: The Home Depot To: host-conf@sol.cs.bucknell.edu Date: Thu, 23 Mar 1995 08:13:45 EST Subject: Priority: normal X-Mailer: Pegasus Mail/Windows (v1.11a) Message-Id: <1F18B093973@at2a4> In response to Danvers IETF DHCP IPv6, where can to retrieve the evaluation copy? I've tried "gatekeeper.dec.com via FTP.   Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa13449; 23 Mar 95 17:32 EST Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa16463; 23 Mar 95 17:32 EST Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id ab13429; 23 Mar 95 17:32 EST Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa13006; 23 Mar 95 17:28 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: host-conf@sol.cs.bucknell.edu Sender:ietf-announce-request@IETF.CNRI.Reston.VA.US From: Internet-Drafts@CNRI.Reston.VA.US Reply-to: Internet-Drafts@CNRI.Reston.VA.US Subject: I-D ACTION:draft-ietf-dhc-dhcpv6-01.txt Date: Thu, 23 Mar 95 17:28:34 -0500 X-Orig-Sender: cclark@CNRI.Reston.VA.US Message-ID: <9503231728.aa13006@IETF.CNRI.Reston.VA.US> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Title : Dynamic Host Configuration Protocol for IPv6 Author(s) : J. Bound, Y. Rekhter, S. Thomson Filename : draft-ietf-dhc-dhcpv6-01.txt Pages : 16 Date : 03/22/1995 The Dynamic Host Configuration Protocol for IPv6 (DHCPv6): provides a mechanism to autoconfigure inter-link Host IPv6 addresseses [IPv6-ADDR], provides parameters to autoregister [DYN-DNS-UPD] and receive Domain Name System (DNS) [RFC-1034&1035] Host names, and provides a mechanism to specify additional configuration options in the protocol. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dhc-dhcpv6-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-dhc-dhcpv6-01.txt Internet-Drafts directories are located at: o Africa Address: ftp.is.co.za (196.4.160.2) o Europe Address: nic.nordu.net (192.36.148.17) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-dhc-dhcpv6-01.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. For questions, please mail to Internet-Drafts@cnri.reston.va.us. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19950323172203.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-dhcpv6-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-dhcpv6-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19950323172203.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart--   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14363; 23 Mar 95 18:00 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa14359; 23 Mar 95 18:00 EST Received: from sol.cs.bucknell.edu by CNRI.Reston.VA.US id aa17447; 23 Mar 95 18:00 EST Received: from inet-gw-3.pa.dec.com by sol.cs.bucknell.edu (4.1/Bucknell-2.0) id ; Thu, 23 Mar 95 17:45:00 EST Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/24Feb95) id AA05036; Thu, 23 Mar 95 14:42:57 -0800 Received: by xirtlu.zk3.dec.com; id AA23837; Thu, 23 Mar 1995 17:41:21 -0500 Message-Id: <9503232241.AA23837@xirtlu.zk3.dec.com> To: "Hale, C.A." Cc: host-conf@sol.cs.bucknell.edu Subject: Re: In-Reply-To: Your message of "Thu, 23 Mar 95 08:13:45 EST." <1F18B093973@at2a4> Date: Thu, 23 Mar 95 17:41:15 -0500 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: bound@zk3.dec.com X-Mts: smtp I just checked again. Its on gatekeeper.dec.com (anon ftp). Then type: cd /pub/DEC/IPv6 Its in that dir? /jim   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa26873; 24 Mar 95 1:49 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa26869; 24 Mar 95 1:49 EST Received: from sol.cs.bucknell.edu by CNRI.Reston.VA.US id aa24233; 24 Mar 95 1:49 EST Received: from coral.bucknell.edu by sol.cs.bucknell.edu (4.1/Bucknell-2.0) id ; Fri, 24 Mar 95 01:38:33 EST Received: from uvite49.bucknell.edu by coral.bucknell.edu; (5.65/1.1.8.2/29Aug94-0956AM) id AA02755; Fri, 24 Mar 1995 01:38:20 -0500 Message-Id: <9503240638.AA02755@coral.bucknell.edu> X-Sender: droms@sol.cs.bucknell.edu Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 24 Mar 1995 01:38:27 -0500 To: John Carlson , host-conf@sol.cs.bucknell.edu Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Ralph Droms Subject: Re: DHCPDECLINE I imagine there are a bunch of denial of service attacks available through DHCP as currently described in the specification - spoofing servers come immediately to mind. We have discussed, but not yet designed, authentication mechanisms for DHCP protocol exchanges. - Ralph Droms ===== Has anyone, writing a server implementation, addressed the issue of limiting the ability of a rogue client from using: 4.3.3 DHCPDECLINE message If the server receives a DHCPDECLINE message, the client has discovered through some other means that the suggested network address is already in use. The server MUST mark the network address as not available and SHOULD notify the local system administrator of a possible configuration problem. to create a denial of service situation? Is this a tractable problem?   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa26911; 24 Mar 95 1:53 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa26907; 24 Mar 95 1:53 EST Received: from sol.cs.bucknell.edu by CNRI.Reston.VA.US id aa24294; 24 Mar 95 1:53 EST Received: from coral.bucknell.edu by sol.cs.bucknell.edu (4.1/Bucknell-2.0) id ; Fri, 24 Mar 95 01:40:02 EST Received: from uvite49.bucknell.edu by coral.bucknell.edu; (5.65/1.1.8.2/29Aug94-0956AM) id AA02779; Fri, 24 Mar 1995 01:38:31 -0500 Message-Id: <9503240638.AA02779@coral.bucknell.edu> X-Sender: droms@sol.cs.bucknell.edu Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 24 Mar 1995 01:38:38 -0500 To: Jonathan Wenocur , host-conf@sol.cs.bucknell.edu Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Ralph Droms Subject: Re: draft spec nits/questions At 9:00 PM 2/16/95 -0500, Jonathan Wenocur wrote: >A few little nits and questions for the new draft spec: > >1) 4.4.1 says the xid of the REQUEST has to be the same as the xid of >the OFFER (which is the same as the xid of the DISCOVER), but this >isn't shown in Table 4. Fixed. >2) Date on draft is Feb 1994 Fixed. >3) It might be helpful to indicate in Table 4 when each packet is >broadcast and when unicast. This is explained in the text but it's >hard to follow sometimes. I think this was already mentioned on the >list. Instead if adding text to table 4 (I couldn't think of a nice way to insert that detail into the table), I changed 4.4.1 to "Use of broadcast and unicast",and added a new paragraph explaining the use of broadcast for DHCPDISCOVER and DHCPREQUEST. >4) Here's a sort of obscure one: does the client need to make sure >that the options from the OFFER and the options from the ACK to its >REQUEST based on the OFFER are the same? Does the server have to >supply the same set of options in the OFFER and the ACK? Moreso, is >the ACK simply a mirror of the REQUEST (and the REQUEST a mirror of >the OFFER)? In particular, what should the client do if the lease >times in the OFFER and ACK are different, or is this not possible? >Maybe I'm just being paranoid. I guess the client can choose to check but shouldn't have to; if the client wants to ensure the parameters delivered in the ACK match those in the OFFER, the client can do the check. - Ralph Droms   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01566; 24 Mar 95 7:39 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa01562; 24 Mar 95 7:39 EST Received: from sol.cs.bucknell.edu by CNRI.Reston.VA.US id aa03704; 24 Mar 95 7:39 EST Received: from coral.bucknell.edu by sol.cs.bucknell.edu (4.1/Bucknell-2.0) id ; Fri, 24 Mar 95 07:24:18 EST Received: from uvite54.bucknell.edu by coral.bucknell.edu; (5.65/1.1.8.2/29Aug94-0956AM) id AA07581; Fri, 24 Mar 1995 07:24:07 -0500 Message-Id: <9503241224.AA07581@coral.bucknell.edu> X-Sender: droms@sol.cs.bucknell.edu Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 24 Mar 1995 07:24:14 -0500 To: "Edie E. Gunter" , host-conf@sol.cs.bucknell.edu Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Ralph Droms Subject: Re: Some proposed changes to November draft At 1:46 PM 2/24/95 -0500, Edie E. Gunter wrote: >I just got the latest draft and stumbled upon the new DHCPINFORM >and DHCPREVALIDATE messages. These are missing in tables 3 and 4. >What, if any, option restrictions apply to these new messages? I've added text describing the restrictions to the tables and the body of the specification. >Is it expected that an INFORM would look like a DISCOVER in that >the client may include a list of specific options it would like >to get from the server? Yes. >Since the REVALIDATE message is broadcast, is >it expected that a client will check the server id and only do >the revalidate if the server id is the same as the server >from which this client's lease was obtained, or is it intended that >one server's revalidate will cause all clients to revalidate >with their respective servers? If the latter, does this suggest >the need for a random delay in the 10,000 clients before they >all send off the REQUESTs, as is done at startup (see section 4.4.1)? Good point. In my opinion, any DHCPREVALIDATE should cause ALL clients to revalidate their parameters. It seems that this would be a relatively rare event, and that limiting the scope of a DHCPREVALIDATE would be restrictive (the netadmin would have to make sure all the servers issue DHCPREVALIDATE messages). I suppose there is a compromise - if a DHCPREVALIDATE message contains a server identifier, that identifier should be checked against the server that issued the client's binding; if not identifier is present, the client should revalidate immediately. I added some text about random delays to avoid congestion. - Ralph   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id ac00215; 24 Mar 95 10:48 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa03094; 24 Mar 95 9:56 EST Received: from [134.82.27.1] by CNRI.Reston.VA.US id aa01623; 24 Mar 95 9:56 EST Received: from ftp.com (wd40.ftp.com) by sol.cs.bucknell.edu (4.1/Bucknell-2.0) id ; Fri, 24 Mar 95 09:13:08 EST Received: from ftp.com by ftp.com ; Fri, 24 Mar 1995 09:13:05 -0500 Received: from mailserv-C.ftp.com by ftp.com ; Fri, 24 Mar 1995 09:13:05 -0500 Received: from mamros.cavedog.ftp.com by mailserv-C.ftp.com (5.0/SMI-SVR4) id AA18611; Fri, 24 Mar 95 09:16:27 EST Date: Fri, 24 Mar 95 09:16:27 EST Message-Id: <9503241416.AA18611@mailserv-C.ftp.com> To: host-conf@sol.cs.bucknell.edu Subject: DHCPREVALIDATE (was Re: Some proposed changes to November draft) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Shawn Mamros X-Orig-Sender: mamros@mailserv-c.ftp.com Repository: mailserv-C.ftp.com, [message accepted at Fri Mar 24 09:16:16 1995] Originating-Client: cavedog.ftp.com Content-Length: 2658 Ralph writes: >At 1:46 PM 2/24/95 -0500, Edie E. Gunter wrote: [...] >>Since the REVALIDATE message is broadcast, is >>it expected that a client will check the server id and only do >>the revalidate if the server id is the same as the server >>from which this client's lease was obtained, or is it intended that >>one server's revalidate will cause all clients to revalidate >>with their respective servers? If the latter, does this suggest >>the need for a random delay in the 10,000 clients before they >>all send off the REQUESTs, as is done at startup (see section 4.4.1)? > >Good point. In my opinion, any DHCPREVALIDATE should cause ALL clients to >revalidate their parameters. It seems that this would be a relatively rare >event, and that limiting the scope of a DHCPREVALIDATE would be restrictive >(the netadmin would have to make sure all the servers issue DHCPREVALIDATE >messages). I suppose there is a compromise - if a DHCPREVALIDATE message >contains a server identifier, that identifier should be checked against the >server that issued the client's binding; if not identifier is present, the >client should revalidate immediately. > >I added some text about random delays to avoid congestion. Maybe I'm being dense here, but... How is a broadcast DHCPREVALIDATE supposed to make it to clients that are on the other side of a relay agent? Some networks with DHCP clients possibly won't have any DHCP servers on the local net, and up until now there hasn't been any requirement that there must be a server on every net, thanks to the relay agents. In such cases, you're going to have to unicast a DHCPREVALIDATE to every client on those nets - yuck. Moreover, since some of us are already shipping DHCP clients that were written to the original RFC, and therefore don't support DHCPREVALIDATE, it seems to me that servers are going to have to be tolerant of clients that don't send a DHCPREQUEST in response to the DHCPREVALIDATE, and maintain the existing leases of those clients until their original expiration times (if they don't renew). I was out at Connectathon last week, where quite a few vendors did DHCP testing, and I heard more than one vendor express disagreement at the whole idea of DHCPREVALIDATE, since it completely reverses the "traditional" client-request-first-then-server-reply model that DHCP has followed up until now, and since almost any need for such a message can be handled by using shorter lease times (now that we've gotten rid of the at-least-one-hour restriction). I'll let those who more strongly oppose DHCPREVALIDATE than I do speak for themselves... -Shawn Mamros E-mail to: mamros@ftp.com   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03082; 24 Mar 95 12:19 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa03078; 24 Mar 95 12:19 EST Received: from sol.eg.bucknell.edu by CNRI.Reston.VA.US id aa04554; 24 Mar 95 12:19 EST Received: from coral.bucknell.edu by sol.eg.bucknell.edu (4.1/Bucknell-2.0) id ; Fri, 24 Mar 95 12:04:41 EST Received: from droms.bucknell.edu by coral.bucknell.edu; (5.65/1.1.8.2/29Aug94-0956AM) id AA24833; Fri, 24 Mar 1995 12:04:36 -0500 Message-Id: <9503241704.AA24833@coral.bucknell.edu> X-Sender: droms@sol.cs.bucknell.edu Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 24 Mar 1995 12:04:41 -0500 To: host-conf@sol.eg.bucknell.edu Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Ralph Droms Subject: New version of specification, Danvers meeting I've put out a new revision of the DHCP specification for anonymous FTP in ftp://sol.cs.bucknell.edu/dhcwg/draft-spec-mar-95.txt. I will submit this version as an I-D today. Please review the document for discussion at the Danvers meeting. Tentatively, we're scheduled to discuss DHCPv6, an option to support IPv4 mobility and the revised protocol spec during the Danvers meetings. The order of discussion isn't quite clear, yet. Please send suggestions direct to me for other topics you'd like to see on the agneda. - Ralph   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03093; 24 Mar 95 12:19 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa03089; 24 Mar 95 12:19 EST Received: from sol.eg.bucknell.edu by CNRI.Reston.VA.US id aa04559; 24 Mar 95 12:19 EST Received: from coral.bucknell.edu by sol.eg.bucknell.edu (4.1/Bucknell-2.0) id ; Fri, 24 Mar 95 12:04:48 EST Received: from droms.bucknell.edu by coral.bucknell.edu; (5.65/1.1.8.2/29Aug94-0956AM) id AA24827; Fri, 24 Mar 1995 12:04:32 -0500 Message-Id: <9503241704.AA24827@coral.bucknell.edu> X-Sender: droms@sol.cs.bucknell.edu Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 24 Mar 1995 12:04:35 -0500 To: Shawn Mamros , host-conf@sol.eg.bucknell.edu Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Ralph Droms Subject: Re: DHCPREVALIDATE (was Re: Some proposed changes to November draft) At 9:16 AM 3/24/95 -0500, Shawn Mamros wrote: >Maybe I'm being dense here, but... > >How is a broadcast DHCPREVALIDATE supposed to make it to clients that >are on the other side of a relay agent? Some networks with DHCP clients >possibly won't have any DHCP servers on the local net, and up until now >there hasn't been any requirement that there must be a server on every >net, thanks to the relay agents. In such cases, you're going to have >to unicast a DHCPREVALIDATE to every client on those nets - yuck. Well, there might be some other engineering solutions, like asking BOOTP relay agents to forward DHCPREVALIDATE messages. Is there a nice solution to the problem? I've left the current text in the draft spec because of time constraints. Let's talk about the issue between now and the Danvers meeting and come to a decision about it then, before moving the spec forward to "draft standard". - Ralph   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05196; 24 Mar 95 13:37 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa05191; 24 Mar 95 13:37 EST Received: from sol.eg.bucknell.edu by CNRI.Reston.VA.US id aa06151; 24 Mar 95 13:37 EST Received: from coral.bucknell.edu by sol.eg.bucknell.edu (4.1/Bucknell-2.0) id ; Fri, 24 Mar 95 13:18:52 EST Received: from droms.bucknell.edu by coral.bucknell.edu; (5.65/1.1.8.2/29Aug94-0956AM) id AA06908; Fri, 24 Mar 1995 13:18:49 -0500 Message-Id: <9503241818.AA06908@coral.bucknell.edu> X-Sender: droms@sol.cs.bucknell.edu Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 24 Mar 1995 13:18:52 -0500 To: host-conf@sol.eg.bucknell.edu Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Ralph Droms Subject: New revision of DHCP spec I've fixed the access permissions of the new draft ... sorry for the goof. - Ralph   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01225; 24 Mar 95 14:03 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa01219; 24 Mar 95 14:03 EST Received: from sol.eg.bucknell.edu by CNRI.Reston.VA.US id aa06852; 24 Mar 95 14:03 EST Received: from shiva1.cac.washington.edu by sol.eg.bucknell.edu (4.1/Bucknell-2.0) id ; Fri, 24 Mar 95 13:44:37 EST Received: by shiva1.cac.washington.edu (5.65+UW95.02/UW-NDC Revision: 2.32 ) id AA04207; Fri, 24 Mar 95 10:44:34 -0800 Date: Fri, 24 Mar 1995 10:44:33 -0800 (PST) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: John Carlson To: Ralph Droms Cc: Shawn Mamros , host-conf@sol.eg.bucknell.edu Subject: Re: DHCPREVALIDATE (was Re: Some proposed changes to November draft) In-Reply-To: <9503241704.AA24827@coral.bucknell.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII It would seem that there are a few problems with the DHCPREVALIDATE message (some already mentioned or implied): 1) Potentially large network bandwidth hit in situations with large quantities of dhcp clients and a central dhcp server. 2) No broadcast capabilities across relay agents in some cases. 3) Many clients may be asleep at the time of the "broadcast" and so wouldn't act appropriately, potentially causing further action by the server (and further net bandwidth usage). All three of these cases apply to the situation at the University of Washington. Clearly, we would not try to take advantage of the DHCPREVALIDATE message on our campus network. On the otherhand, a non-broadcast, per client, DHCPREVALIDATE message might prove useful. johnc ------------------------------------------------------------------------------- John D. Carlson Networks and Distributed Computing EMAIL: johnc@cac.washington.edu University of Washington BELL: (206) 685-6204 4545 15th Ave NE FAX: (206) 685-4044 Seattle, WA 98105 On Fri, 24 Mar 1995, Ralph Droms wrote: > Date: Fri, 24 Mar 1995 12:04:35 -0500 > From: Ralph Droms > To: Shawn Mamros , host-conf@sol.eg.bucknell.edu > Subject: Re: DHCPREVALIDATE (was Re: Some proposed changes to November draft) > > At 9:16 AM 3/24/95 -0500, Shawn Mamros wrote: > >Maybe I'm being dense here, but... > > > >How is a broadcast DHCPREVALIDATE supposed to make it to clients that > >are on the other side of a relay agent? Some networks with DHCP clients > >possibly won't have any DHCP servers on the local net, and up until now > >there hasn't been any requirement that there must be a server on every > >net, thanks to the relay agents. In such cases, you're going to have > >to unicast a DHCPREVALIDATE to every client on those nets - yuck. > > Well, there might be some other engineering solutions, like asking BOOTP > relay agents to forward DHCPREVALIDATE messages. Is there a nice solution > to the problem? > > I've left the current text in the draft spec because of time constraints. > Let's talk about the issue between now and the Danvers meeting and come to > a decision about it then, before moving the spec forward to "draft > standard". > > - Ralph > > > >   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13905; 24 Mar 95 23:02 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa13901; 24 Mar 95 23:02 EST Received: from sol.eg.bucknell.edu by CNRI.Reston.VA.US id aa16501; 24 Mar 95 23:02 EST Received: from watson.ibm.com by sol.eg.bucknell.edu (4.1/Bucknell-2.0) id ; Fri, 24 Mar 95 22:51:24 EST Received: from WATSON by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 1037; Fri, 24 Mar 95 22:50:50 EST Received: from YKTVMV by watson.vnet.ibm.com with "VAGENT.V1.0" id 8939; Fri, 24 Mar 1995 22:50:50 EST Received: from hawpub1.watson.ibm.com by yktvmv.watson.ibm.com (IBM VM SMTP V2R3) with TCP; Fri, 24 Mar 95 22:50:50 EST Received: by hawpub1.watson.ibm.com (AIX 3.2/UCB 5.64/930311) id AA43761; Fri, 24 Mar 1995 22:50:49 -0500 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Charlie Perkins Message-Id: <9503250350.AA43761@hawpub1.watson.ibm.com> To: host-conf@sol.eg.bucknell.edu, mobile-ip@tadpole.com Subject: Mobile Home Address option Date: Fri, 24 Mar 95 22:50:48 -0500 I've written up an Internet draft to detail a new option we've implemented for DHCP. The new option allows a mobile client to obtain a "home address", useful with mobile-IP, instead of an IP address closely tied to the current point of attachment to the Internet. The idea is that after getting a home address (and the address of an associated home agent) the mobile client can move about, using the mechanisms of mobile-IP to keep its network connections alive when moving from place to place. This option is not directly related to the use of DHCP to obtain "care-of addresses", which are also of use with mobile-IP. If you are interested, please see "draft-perkins-homeaddr-dhcpopt-00.txt", in your favorite Internet-draft repository, or available in the mobile-ip repository at software.watson.ibm.com. Regards, Charles Perkins   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03058; 27 Mar 95 9:47 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa03052; 27 Mar 95 9:47 EST Received: from sol.eg.bucknell.edu by CNRI.Reston.VA.US id aa06133; 27 Mar 95 9:47 EST Received: from interramp.com (pop3.interramp.com) by sol.eg.bucknell.edu (4.1/Bucknell-2.0) id ; Mon, 27 Mar 95 09:35:13 EST Received: from .interramp.com (ip110.herndon2.va.interramp.com) by interramp.com (4.1/SMI-4.1.3-PSI-pop-local) id AA21569; Sat, 25 Mar 95 23:03:03 EST Message-Id: <9503260403.AA21569@interramp.com> X-Sender: pp001237@pop3.interramp.com X-Mailer: Windows Eudora Version 1.4.4 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 25 Mar 1995 23:56:48 -0600 To: host-conf@sol.eg.bucknell.edu Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: David Willis Subject: Unsubscribe Unsubscribe David Willis   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03682; 27 Mar 95 10:04 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa03678; 27 Mar 95 10:04 EST Received: from sol.eg.bucknell.edu by CNRI.Reston.VA.US id aa06467; 27 Mar 95 10:04 EST Received: from sphinx.ece.wisc.edu by sol.eg.bucknell.edu (4.1/Bucknell-2.0) id ; Mon, 27 Mar 95 09:54:10 EST Received: by sphinx.ece.wisc.edu (WE5:5.65c/ES5) id AA17387; Fri, 24 Mar 1995 11:36:39 -0600 Date: Fri, 24 Mar 1995 11:36:39 -0600 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Dick Burger Message-Id: <199503241736.AA17387@sphinx.ece.wisc.edu> To: host-conf@sol.eg.bucknell.edu Subject: BOOTP-DHCP Hi, I asked a question a while back asking about the important differences between BOOTP and DHCP. Thought I'd post some of the replies, they might be of general interest. Dick Burger From David.Brownell@Eng.Sun.COM Sat Mar 4 10:03:11 1995 In BOOTP the addresses are preallocated, e.g. in /etc/hosts In DHCP they need not be preallocated. That is, DHCP (like its precursor DRARP) can be used to support installation of hosts on IP networks without per-host administrative intervention like finding an /etc/hosts (or DNS, ...) entry and assigning it and pushing the update. From uucp@netcom.com Mon Mar 6 04:43:43 1995 Dick, You ask, essentially, why is DHCP "more" dynamic than BOOTP. Here are two reasons: 1. In BOOTP you pre-allocate a binding of IP address and MAC address. This pre-supposes than the client is on a specific subnet. But suppose the client moves. Say the user has a highly portable machine and goes from one building to another. If the net changes the binding that has been established won't work. 2. The lease is finite, not infinite as with BOOTP. Then if you have more machines than IP addresses and many of them need access to the net for a short period of time they can be given short leases, do their work, then go down. The IP address may then be used for another client. This might be pertinent on, say, a factory floor. Rob. Dick, In my opinion, the most significant promising improvement of dhcp over bootp is the ability to issue addresses for a finite period of time, which eliminates the need for manual intervention when reaping addresses at some later date. Perhaps this is an additional feature (over bootp) people think of when suggesting, in the context of bootp vs. dhcp, that dhcp is dynamic. johnc From droms@bucknell.edu Fri Mar 24 00:38:22 1995 Basically, DHCP explicitly describes in the protocol spec a dynamic allocation mechanism, while BOOTP has had one grafted on "unofficially" with no changes to the BOOTP RFC. DHCP includes specific mechanisms for a style of allocation that allows for allocation of addresses that can be reused without netadmin intervention. - Ralph Droms   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03714; 27 Mar 95 10:06 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa03710; 27 Mar 95 10:06 EST Received: from sol.eg.bucknell.edu by CNRI.Reston.VA.US id aa06513; 27 Mar 95 10:06 EST Received: from shiva.shiva.com by sol.eg.bucknell.edu (4.1/Bucknell-2.0) id ; Mon, 27 Mar 95 09:56:34 EST Received: (jhw@localhost) by shiva.shiva.com (8.6.9/8.6.4) id KAA22654 for host-conf@sol.cs.bucknell.edu; Fri, 24 Mar 1995 10:59:28 -0500 Date: Fri, 24 Mar 1995 10:59:28 -0500 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Jonathan Wenocur Message-Id: <199503241559.KAA22654@shiva.shiva.com> To: host-conf@sol.eg.bucknell.edu Subject: Re: draft spec nits/questions >> Date: Fri, 24 Mar 1995 01:38:38 -0500 >> From: droms@bucknell.edu (Ralph Droms) >> >> >4) Here's a sort of obscure one: does the client need to make sure >> >that the options from the OFFER and the options from the ACK to its >> >REQUEST based on the OFFER are the same? Does the server have to >> >supply the same set of options in the OFFER and the ACK? Moreso, is >> >the ACK simply a mirror of the REQUEST (and the REQUEST a mirror of >> >the OFFER)? In particular, what should the client do if the lease >> >times in the OFFER and ACK are different, or is this not possible? >> >Maybe I'm just being paranoid. >> >> I guess the client can choose to check but shouldn't have to; if the client >> wants to ensure the parameters delivered in the ACK match those in the >> OFFER, the client can do the check. >> >> - Ralph Droms From a private e-mail exchange on this topic with someone else from the list: >> ... In my server, the lease times present in an OFFER and the >> corresponding (to a REQEUST) ACK will differ by the amount of time >> it takes to send the OFFER, receive the REQUEST and send the ACK. >> In most case, just a few seconds. Seems reasonable, and probably harmless. However, it begs the question of whether the parameters and options in the ACK must exactly match those in the OFFER. More specifically, should the client even check the parameters in the ACK? Should the client use the options from the OFFER or from the ACK? Or does this not matter? Ralph, you seem to be saying use the OFFER and ignore the ACK. That's probably easiest but I'm concerned this could result in differences between what the server and the client think the options are. I guess the real question is are there other servers which change values of the options at all between the OFFER and the ACK? -- Jonathan   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03732; 27 Mar 95 10:06 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa03728; 27 Mar 95 10:06 EST Received: from sol.eg.bucknell.edu by CNRI.Reston.VA.US id aa06520; 27 Mar 95 10:06 EST Received: from shiva.shiva.com by sol.eg.bucknell.edu (4.1/Bucknell-2.0) id ; Mon, 27 Mar 95 09:50:57 EST Received: (jhw@localhost) by shiva.shiva.com (8.6.9/8.6.4) id SAA01703; Fri, 24 Mar 1995 18:07:05 -0500 Date: Fri, 24 Mar 1995 18:07:05 -0500 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Jonathan Wenocur Message-Id: <199503242307.SAA01703@shiva.shiva.com> To: host-conf@sol.eg.bucknell.edu, jhw@shiva.shiva.com Subject: Re: draft spec nits/questions (Sorry if you get this more than once, first try didn't seem to make it through.) >> Message-Id: <9503240638.AA02779@coral.bucknell.edu> >> From: droms@bucknell.edu (Ralph Droms) >> >> [...] >> >> >4) Here's a sort of obscure one: does the client need to make sure >> >that the options from the OFFER and the options from the ACK to its >> >REQUEST based on the OFFER are the same? Does the server have to >> >supply the same set of options in the OFFER and the ACK? Moreso, is >> >the ACK simply a mirror of the REQUEST (and the REQUEST a mirror of >> >the OFFER)? In particular, what should the client do if the lease >> >times in the OFFER and ACK are different, or is this not possible? >> >Maybe I'm just being paranoid. >> >> I guess the client can choose to check but shouldn't have to; if the client >> wants to ensure the parameters delivered in the ACK match those in the >> OFFER, the client can do the check. >> >> - Ralph Droms >> From a private e-mail exchange on this topic with someone else on this list: > [...] In my server, the lease times present in an OFFER and the > corresponding (to a REQEUST) ACK will differ by the amount of time > it takes to send the OFFER, receive the REQUEST and send the ACK. > In most case, just a few seconds. This seems reasonable, and is probably fine since a few seconds won't make a difference (unless it's a really short lease!). But it begs the question of whether the ACK should be identical to the OFFER or not? Are there other servers which change the options at all between the OFFER and the ACK? Should a client simply ignore the options in the ACK? In other words, which set of params should the client trust: those in the OFFER, or those in the ACK? -- Jonathan   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05409; 27 Mar 95 11:25 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa05405; 27 Mar 95 11:25 EST Received: from sol.eg.bucknell.edu by CNRI.Reston.VA.US id aa08322; 27 Mar 95 11:25 EST Received: from hp.com by sol.eg.bucknell.edu (4.1/Bucknell-2.0) id ; Mon, 27 Mar 95 11:13:23 EST Received: from hpindavg.ptp.hp.com by hp.com with SMTP (1.37.109.15/15.5+ECS 3.3) id AA033460797; Mon, 27 Mar 1995 08:13:17 -0800 Received: by hpindavg.ptp.hp.com (1.38.193.4/15.5+IOS 3.22) id AA03586; Mon, 27 Mar 1995 08:13:16 -0800 Date: Mon, 27 Mar 1995 08:13:16 -0800 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: AP Anantharaman Message-Id: <9503271613.AA03586@hpindavg.ptp.hp.com> To: host-conf@sol.eg.bucknell.edu Subject: DHCP MTU Hi, I am looking at using DHCP to provide host configuration information to clients. The data link layer of the network we are planning to use is connectinon less and has a MTU size of 256 bytes. I am reading up on the DHCP RFC 1541 and find that the packet format requires that the DHCP packet have a length of at least 236 bytes before it gets to the options field. If we add the magic cookie and the Options Overload field to indicate that the options are present in the sname and file fields, it adds another 9 or more bytes with pad and end fields tagged on. To this we need to add the UDP, IP and link headers and as you can see, this easily exceeds the 256 byte MTU of the network. While reading RFC1533, I saw another option talked about in section 5.1. This is the "interface MTU Option". This option says that the minimum legal value for the MTU is 68. How does one reconcile the above para with this information ? Any help appreciated. ananth@ptp.hp.com (408) 746-5604   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05663; 27 Mar 95 11:38 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa05659; 27 Mar 95 11:38 EST Received: from sol.eg.bucknell.edu by CNRI.Reston.VA.US id aa09317; 27 Mar 95 11:38 EST Received: from UTKVX1.UTK.EDU by sol.eg.bucknell.edu (4.1/Bucknell-2.0) id ; Mon, 27 Mar 95 11:25:37 EST Received: from TCHM04A10.RMT.UTK.EDU ("port 1029"@TCHM04A10.RMT.UTK.EDU) by utkvx.utk.edu (PMDF V4.3-13 #9964) id <01HOLM2JLHS09JF0CI@utkvx.utk.edu>; Sun, 26 Mar 1995 17:34:21 -0500 (EST) Date: Sun, 26 Mar 1995 17:34:21 -0500 (EST) Date-Warning: Date header was inserted by utkvx.utk.edu Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Kief Morris Subject: X-Sender: kief@utkvx To: host-conf@sol.eg.bucknell.edu Message-Id: <01HOLM2LI2X29JF0CI@utkvx.utk.edu> Mime-Version: 1.0 X-Mailer: Windows Eudora Version 2.0.3 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7BIT unsubscribe   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05850; 27 Mar 95 11:47 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa05846; 27 Mar 95 11:47 EST Received: from sol.eg.bucknell.edu by CNRI.Reston.VA.US id aa11579; 27 Mar 95 11:47 EST Received: from relay.hp.com by sol.eg.bucknell.edu (4.1/Bucknell-2.0) id ; Mon, 27 Mar 95 11:35:40 EST Received: from hppadan.waterloo.hp.com by relay.hp.com with ESMTP (1.37.109.15/15.5+ECS 3.3) id AA053802136; Mon, 27 Mar 1995 08:35:36 -0800 Received: by hppadan.waterloo.hp.com (1.37.109.15/15.5+ECS 3.3) id AA205492129; Mon, 27 Mar 1995 11:35:29 -0500 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: David Lapp Message-Id: <199503271635.AA205492129@hppadan.waterloo.hp.com> Subject: Re: DHCP MTU To: AP Anantharaman Date: Mon, 27 Mar 1995 11:35:29 -0500 (EST) Cc: host-conf@sol.eg.bucknell.edu In-Reply-To: <9503271613.AA03586@hpindavg.ptp.hp.com> from "AP Anantharaman" at Mar 27, 95 08:13:16 am X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1214 > > I am looking at using DHCP to provide host configuration information to > clients. The data link layer of the network we are planning to use is > connectinon less and has a MTU size of 256 bytes. I am reading up on > the DHCP RFC 1541 and find that the packet format requires that the DHCP > packet have a length of at least 236 bytes before it gets to the options > field. If we add the magic cookie and the Options Overload field to > indicate that the options are present in the sname and file fields, it > adds another 9 or more bytes with pad and end fields tagged on. To > this we need to add the UDP, IP and link headers and as you can see, > this easily exceeds the 256 byte MTU of the network. > > While reading RFC1533, I saw another option talked about in section 5.1. > This is the "interface MTU Option". This option says that the minimum > legal value for the MTU is 68. How does one reconcile the above para > with this information ? Any help appreciated. > Probably the only solution is to use IP fragmentation. While it is probably preferable to not have the DHCP packet split into multiple IP datagrams it is permitted since it is built on UDP. Dave L.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06231; 27 Mar 95 12:03 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa06224; 27 Mar 95 12:03 EST Received: from sol.eg.bucknell.edu by CNRI.Reston.VA.US id aa12888; 27 Mar 95 12:03 EST Received: from Sun.COM by sol.eg.bucknell.edu (4.1/Bucknell-2.0) id ; Mon, 27 Mar 95 11:51:43 EST Received: from East.Sun.COM (east.East.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA13357; Sun, 26 Mar 95 08:28:59 PST Received: from suneast.East.Sun.COM by East.Sun.COM (4.1/SMI-4.1) id AA15302; Sun, 26 Mar 95 11:28:58 EST Received: from canoepoint.East.Sun.COM by suneast.East.Sun.COM (5.0/SMI-4.1-900117) id AA19382; Sun, 26 Mar 1995 11:28:57 +0500 Received: by canoepoint.East.Sun.COM (5.x/SMI-SVR4) id AA04440; Sun, 26 Mar 1995 11:30:33 -0500 Date: Sun, 26 Mar 1995 11:30:33 -0500 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Mike Carney - Sun BOS Software Message-Id: <9503261630.AA04440@canoepoint.East.Sun.COM> To: host-conf@sol.eg.bucknell.edu, mamros@ftp.com Subject: Re: DHCPREVALIDATE (was Re: Some proposed changes to November draft) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Md5: AiAE4JPTBumORfSVLi7yFg== Content-Length: 1227 I'm one of the vendors that Shawn mentions. Those of us at Connectathon (the second week, anyway, discussed this very issue as he mentions. As shawn points out, the server historically has been passive and the clients initiate all exchanges. DHCPREVALIDATE goes against this behavior. We've had numerous bakeoffs where we've proven interoperability of the spec less the recent DHCPINFORM and DHCPREVALIDATE messages. IMHO, I believe there are ways to achieve the acceptable behavior without adding these messages: 1) DHCPREVALIDATE. Shorten your lease time policy to level by which your clients will receive the updated information in an acceptable time frame. We use one hour for PC clients, and I'd envision 2 days for workstations, etc. Note that an advantage of this method over REVALIDATE is that client's will tend to attempt RENEW/REBIND at different times, whereas REVALIDATE is a "all at once" technique. (i'd hate to be the admin who makes a mistake configuring the parameters, then issues a REVALIDATE which hangs everyone's machine. ;^). 2) DHCPINFORM. The client sends a DISCOVER, collects the OFFERs, and uses the information contained therein (Sans the ip address) to configure various services, etc. Mike   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06232; 27 Mar 95 12:03 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa06223; 27 Mar 95 12:03 EST Received: from sol.eg.bucknell.edu by CNRI.Reston.VA.US id aa12886; 27 Mar 95 12:03 EST Received: from Sun.COM by sol.eg.bucknell.edu (4.1/Bucknell-2.0) id ; Mon, 27 Mar 95 11:53:54 EST Received: from East.Sun.COM (east.East.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA11971; Sun, 26 Mar 95 07:48:10 PST Received: from suneast.East.Sun.COM by East.Sun.COM (4.1/SMI-4.1) id AA14233; Sun, 26 Mar 95 10:48:08 EST Received: from canoepoint.East.Sun.COM by suneast.East.Sun.COM (5.0/SMI-4.1-900117) id AA19192; Sun, 26 Mar 1995 10:48:07 +0500 Received: by canoepoint.East.Sun.COM (5.x/SMI-SVR4) id AA04263; Sun, 26 Mar 1995 10:49:42 -0500 Date: Sun, 26 Mar 1995 10:49:42 -0500 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Mike Carney - Sun BOS Software Message-Id: <9503261549.AA04263@canoepoint.East.Sun.COM> To: johnc@cac.washington.edu, host-conf@sol.eg.bucknell.edu, droms@bucknell.edu Subject: Re: DHCPDECLINE Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Md5: jrwvl+ClI04SurNDYMeffw== Content-Length: 1189 >> >> >>Has anyone, writing a server implementation, addressed the issue of limiting >>the ability of a rogue client from using: >> >>4.3.3 DHCPDECLINE message >> >> If the server receives a DHCPDECLINE message, the client has >> discovered through some other means that the suggested network >> address is already in use. The server MUST mark the network >> address as not available and SHOULD notify the local system >> administrator of a possible configuration problem. >>to create a denial of service situation? Is this a tractable problem? Since there is no security in DHCP, I can't see how you could avoid this problem. If one has access to the network, there are all sorts of "nasty" things one could do - spoof a router, dhcp server, name server, whatever. Even if we had security, one could simply "short" the ethernet - I'd seen that happen accidently when someone plugged a phone into a UTP drop. Collisions went to 100% ;^) Security makes sense at higher levels - using kerberos or secure RPC for example. Other new protocols which involve encrypting the entire packet are currently evolving as well, and will do much to alleviate this problem. Mike   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06765; 27 Mar 95 12:37 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa06761; 27 Mar 95 12:37 EST Received: from sol.eg.bucknell.edu by CNRI.Reston.VA.US id aa13746; 27 Mar 95 12:37 EST Received: from watson.ibm.com by sol.eg.bucknell.edu (4.1/Bucknell-2.0) id ; Mon, 27 Mar 95 12:26:29 EST Message-Id: <9503271726.AA06658@sol.eg.bucknell.edu> Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 9363; Fri, 24 Mar 95 11:01:17 EST Date: Fri, 24 Mar 95 11:00:17 EST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: yakov@watson.ibm.com To: mamros@ftp.com, host-conf@sol.eg.bucknell.edu Subject: DHCPREVALIDATE (was Re: Some proposed changes to November draft) Ref: Your note of Fri, 24 Mar 95 09:16:27 EST Folks, DHCPREVALIDATE is just a packet. And as such it may be lost. Therefore, DHCP must provide *robust* operations in the assumption that when a server issues DHCPREVALIDATE, only *some* of the DHCP clients would receive it. Any assumptions stronger than this may be unrealistic. Yakov Rekhter.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa23616; 27 Mar 95 22:58 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa23610; 27 Mar 95 22:58 EST Received: from sol.eg.bucknell.edu by CNRI.Reston.VA.US id aa28781; 27 Mar 95 22:58 EST Received: from epilogue.com (quern.epilogue.com) by sol.eg.bucknell.edu (4.1/Bucknell-2.0) id ; Mon, 27 Mar 95 22:45:36 EST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Lowell Gilbert X-Orig-Sender: lowell@quern.epilogue.com To: Ralph Droms Cc: host-conf@sol.eg.bucknell.edu Subject: DHCPREVALIDATE Date: Mon, 27 Mar 95 22:44:52 -0500 Message-Id: <9503272244.aa10701@quern.epilogue.com> Some of the spec seems to assume that a client is using dynamic allocation and has a finite lease. For example, in a DHCPREVALIDATE broadcast, what about clients with infinite leases or clients not using dynamic allocation? Are they expected to be listening for such a message? For that matter, I'm sort of wondering where DHCPREVALIDATE and DHCPINFORM came from anyway. Neither the archives for this mailing list nor the minutes for working group meetings (at least -- none of the ones of which I have copies -- were there any between fall '93 and December '94?) contain any mention of either message until Ralph Droms' mid-February message about adding them to the spec. I'm not 100% sure that I understand what problems they're supposed to solve (well, actually, I *think* I understand...). Be well. Lowell Gilbert [trying hard to prepare for the IETF meeting, from the floor at Interop]   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02523; 28 Mar 95 8:44 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa02519; 28 Mar 95 8:44 EST Received: from sol.eg.bucknell.edu by CNRI.Reston.VA.US id aa05926; 28 Mar 95 8:44 EST Received: from coral.bucknell.edu by sol.eg.bucknell.edu (4.1/Bucknell-2.0) id ; Tue, 28 Mar 95 08:29:19 EST Received: from uvite49.bucknell.edu by coral.bucknell.edu; (5.65/1.1.8.2/29Aug94-0956AM) id AA22677; Tue, 28 Mar 1995 08:29:06 -0500 Message-Id: <9503281329.AA22677@coral.bucknell.edu> X-Sender: droms@sol.cs.bucknell.edu Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 28 Mar 1995 08:29:20 -0500 To: Lowell Gilbert Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Ralph Droms Subject: Re: DHCPREVALIDATE Cc: host-conf@sol.eg.bucknell.edu At 10:44 PM 3/27/95 -0500, Lowell Gilbert wrote: >For that matter, I'm sort of wondering where DHCPREVALIDATE and >DHCPINFORM came from anyway. We discussed these at the WG meeting in San Jose. The idea for DHCPREVALIDATE came from the IPv6 discussion, where "enterprise renumbering" is a hot topic, and the ability to change the network addresses of all the hosts in an organization is deemed important. The idea for DHCPINFORM was an outgrowth of the observation that there is currently no mechanism for directly obtaining local network parameters w/o particpating in the address allocation process (even starting in INIT-REBOOT state assumes that the DHCP client has a binding in the DHCP server database). - Ralph   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02533; 28 Mar 95 8:44 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa02529; 28 Mar 95 8:44 EST Received: from sol.eg.bucknell.edu by CNRI.Reston.VA.US id aa05936; 28 Mar 95 8:44 EST Received: from coral.bucknell.edu by sol.eg.bucknell.edu (4.1/Bucknell-2.0) id ; Tue, 28 Mar 95 08:30:07 EST Received: from uvite49.bucknell.edu by coral.bucknell.edu; (5.65/1.1.8.2/29Aug94-0956AM) id AA22968; Tue, 28 Mar 1995 08:29:57 -0500 Message-Id: <9503281329.AA22968@coral.bucknell.edu> X-Sender: droms@sol.cs.bucknell.edu Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 28 Mar 1995 08:30:11 -0500 To: host-conf@sol.eg.bucknell.edu Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Ralph Droms Subject: Agenda for Danvers Cc: mwalnut@CNRI.Reston.VA.US Monday, 4/3, 1330-1530: Charlie Perkins IP mobility and DHCP option 30 min Jim Bound DHCPv6 90 min Tuesday, 4/4, 1330-1530: Greg Minshall Server to server interaction model 60 min WG Items from the floor 30 min Ralph Droms DHCPREVALIDATE, DHCPINFORM 15 min Ralph Droms Recent changes to protocol spec 15 min   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02545; 28 Mar 95 8:44 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa02541; 28 Mar 95 8:44 EST Received: from sol.eg.bucknell.edu by CNRI.Reston.VA.US id aa05946; 28 Mar 95 8:44 EST Received: from coral.bucknell.edu by sol.eg.bucknell.edu (4.1/Bucknell-2.0) id ; Tue, 28 Mar 95 08:29:29 EST Received: from uvite49.bucknell.edu by coral.bucknell.edu; (5.65/1.1.8.2/29Aug94-0956AM) id AA22708; Tue, 28 Mar 1995 08:29:19 -0500 Message-Id: <9503281329.AA22708@coral.bucknell.edu> X-Sender: droms@sol.cs.bucknell.edu Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 28 Mar 1995 08:29:33 -0500 To: host-conf@sol.eg.bucknell.edu Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Ralph Droms Subject: New name for host-conf mailing list manager We've restructured our internal DNS hierarchy, renaming cs to eg. Thus,the host-conf mailing list site is now sol.eg.bucknell.edu. Although we will maintain an alias for host.cs.bucknell.edu, please begin using the new address for host-conf mail. - Ralph   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04147; 28 Mar 95 9:51 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa04064; 28 Mar 95 9:51 EST Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa07783; 28 Mar 95 9:50 EST Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03823; 28 Mar 95 9:49 EST Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa03229; 28 Mar 95 9:37 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: host-conf@sol.eg.bucknell.edu X-Orig-Sender:ietf-announce-request@IETF.CNRI.Reston.VA.US Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Internet-Drafts@CNRI.Reston.VA.US Reply-to: Internet-Drafts@CNRI.Reston.VA.US Subject: I-D ACTION:draft-ietf-dhc-dhcp-01.txt Date: Tue, 28 Mar 95 09:37:41 -0500 X-Orig-Sender: cclark@CNRI.Reston.VA.US Message-ID: <9503280937.aa03229@IETF.CNRI.Reston.VA.US> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Title : Dynamic Host Configuration Protocol Author(s) : R. Droms Filename : draft-ietf-dhc-dhcp-01.txt Pages : 44 Date : 03/27/1995 The Dynamic Host Configuration Protocol (DHCP) provides a framework for passing configuration information to hosts on a TCP/IP network. DHCP is based on the Bootstrap Protocol (BOOTP) [7], adding the capability of automatic allocation of reusable network addresses and additional configuration options [19]. DHCP captures the behavior of BOOTP relay agents [7, 23], and DHCP participants can interoperate with BOOTP participants [9]. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dhc-dhcp-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-dhc-dhcp-01.txt Internet-Drafts directories are located at: o Africa Address: ftp.is.co.za (196.4.160.2) o Europe Address: nic.nordu.net (192.36.148.17) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-dhc-dhcp-01.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. For questions, please mail to Internet-Drafts@cnri.reston.va.us. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19950327105208.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-dhcp-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-dhcp-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19950327105208.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart--   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04881; 28 Mar 95 10:35 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa04874; 28 Mar 95 10:35 EST Received: from sol.eg.bucknell.edu by CNRI.Reston.VA.US id aa09101; 28 Mar 95 10:35 EST Received: from io.salford.ac.uk by sol.eg.bucknell.edu (4.1/Bucknell-2.0) id ; Tue, 28 Mar 95 10:12:24 EST Message-Id: <9503281512.AA13876@sol.eg.bucknell.edu> Received: from salford.ac.uk by io.salford.ac.uk id <19108-0@io.salford.ac.uk>; Tue, 28 Mar 1995 16:09:30 +0100 Subject: Re: DHCPREVALIDATE To: Ralph Droms Date: Tue, 28 Mar 1995 16:09:22 +0100 (BST) Cc: lowell@epilogue.com, host-conf@sol.eg.bucknell.edu In-Reply-To: <9503281329.AA22677@coral.bucknell.edu> from "Ralph Droms" at Mar 28, 95 08:29:20 am X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1676 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Richard Letts X-Orig-Sender: R.J.Letts@salford.ac.uk Ralph Droms wrote.... > > At 10:44 PM 3/27/95 -0500, Lowell Gilbert wrote: > >For that matter, I'm sort of wondering where DHCPREVALIDATE and > >DHCPINFORM came from anyway. > > We discussed these at the WG meeting in San Jose. The idea for > DHCPREVALIDATE came from the IPv6 discussion, where "enterprise > renumbering" is a hot topic, and the ability to change the network > addresses of all the hosts in an organization is deemed important. The > idea for DHCPINFORM was an outgrowth of the observation that there is > currently no mechanism for directly obtaining local network parameters w/o > particpating in the address allocation process (even starting in > INIT-REBOOT state assumes that the DHCP client has a binding in the DHCP > server database). I don't see how this has a hope of working on large networks: a server initiates a DHCPREVALIDATE and a couple of hundred/thousand systems reply (even with a backoff scheme this is a fair bit of network traffic) the server has to rebroadcast the request several times to ensure all the clients heard it. the server then has to dispatch addresses to the clients in the correct sequence so hosts get new addresses before the routers connecting the network together get their addresses. Otherwise you are going to isolate parts of the network and that 'bit' is going to be unreachable Richard Letts ------------------------------------------------------------------------------- Network Manager mail: R.J.Letts@salford.ac.uk University of Salford phone: +44 161 745 5252 Great Britain fax: +44 161 745 5888   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05626; 28 Mar 95 10:45 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa05622; 28 Mar 95 10:45 EST Received: from sol.eg.bucknell.edu by CNRI.Reston.VA.US id aa09674; 28 Mar 95 10:45 EST Received: from bonsai.ccity.com by sol.eg.bucknell.edu (4.1/Bucknell-2.0) id ; Tue, 28 Mar 95 10:31:41 EST Message-Id: <9503281531.AA13926@sol.eg.bucknell.edu> Received: by bonsai.ccity.com (1.38.193.4/16.2) id AA02716; Tue, 28 Mar 1995 10:29:58 -0500 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Bryan Miller Subject: Question on leases To: host-conf@sol.eg.bucknell.edu Date: Tue, 28 Mar 95 10:29:58 EST Mailer: Elm [revision: 70.85] I've seen a lot of talk about how leases are implemented, but I have a seemingly trivial question about leases. I seen a lot of people say that leases are great because they can be given out and when the time is up, that address can be given out again. What keeps the device that was issued the IP address via a lease from continuing to use the IP address after the lease expires? Bryan   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06216; 28 Mar 95 11:05 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa06212; 28 Mar 95 11:05 EST Received: from sol.eg.bucknell.edu by CNRI.Reston.VA.US id aa10628; 28 Mar 95 11:05 EST Received: from Sun.COM by sol.eg.bucknell.edu (4.1/Bucknell-2.0) id ; Tue, 28 Mar 95 10:52:14 EST Received: from East.Sun.COM (east.East.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA19728; Tue, 28 Mar 95 07:52:07 PST Received: from suneast.East.Sun.COM by East.Sun.COM (4.1/SMI-4.1) id AA02330; Tue, 28 Mar 95 10:52:05 EST Received: from canoepoint.East.Sun.COM by suneast.East.Sun.COM (5.0/SMI-4.1-900117) id AA10066; Tue, 28 Mar 1995 10:52:03 +0500 Received: by canoepoint.East.Sun.COM (5.x/SMI-SVR4) id AA09796; Tue, 28 Mar 1995 10:53:41 -0500 Date: Tue, 28 Mar 1995 10:53:41 -0500 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Mike Carney - Sun BOS Software Message-Id: <9503281553.AA09796@canoepoint.East.Sun.COM> To: host-conf@sol.eg.bucknell.edu, bmiller@bonsai.ccity.com Subject: Re: Question on leases Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Md5: oeGWHf1svJfMPL2lgAEhAQ== Content-Length: 896 > >>I've seen a lot of talk about how leases are implemented, but I have a >>seemingly trivial question about leases. I seen a lot of people say that >>leases are great because they can be given out and when the time is up, that >>address can be given out again. What keeps the device that was issued the IP >>address via a lease from continuing to use the IP address after the lease >>expires? >> >>Bryan Typically there's an agent running which monitors the lease (the implementation of the RENEW/REBIND states in the spec). If it is unable to extend the lease, it shuts the interface down when the lease expires. If the client for some reason doesn't hold up its end of the "lease" bargain, the server will detect this when it tries to reuse what it considers an available address (via ICMP echo, typically), and mark the address as unusable and flag the administrator's attention. Mike   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07921; 28 Mar 95 12:40 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa07917; 28 Mar 95 12:40 EST Received: from sol.eg.bucknell.edu by CNRI.Reston.VA.US id aa14017; 28 Mar 95 12:40 EST Received: from shiva1.cac.washington.edu by sol.eg.bucknell.edu (4.1/Bucknell-2.0) id ; Tue, 28 Mar 95 12:23:12 EST Received: by shiva1.cac.washington.edu (5.65+UW95.02/UW-NDC Revision: 2.32 ) id AA06528; Tue, 28 Mar 95 09:20:21 -0800 Date: Tue, 28 Mar 1995 09:20:21 -0800 (PST) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: John Carlson To: Mike Carney - Sun BOS Software Cc: host-conf@sol.eg.bucknell.edu, bmiller@bonsai.ccity.com Subject: Re: Question on leases In-Reply-To: <9503281553.AA09796@canoepoint.East.Sun.COM> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 28 Mar 1995, Mike Carney - Sun BOS Software wrote: > Date: Tue, 28 Mar 1995 10:53:41 -0500 > From: Mike Carney - Sun BOS Software > To: host-conf@sol.eg.bucknell.edu, bmiller@bonsai.ccity.com > Subject: Re: Question on leases > ...... > If the client for some reason doesn't hold up its end of the "lease" bargain, > the server will detect this when it tries to reuse what it considers an > available address (via ICMP echo, typically), and mark the address as unusable > and flag the administrator's attention. > > Mike Mike, I wonder if the use of an active approach, such as an ICMP echo, on the part of the server to prevent IP conflicts, is sufficient or appropriate. It may not be sufficient since a confused system temporarily disassociated from the net (eg. disconnected, missed icmp, shutdown,...) would continue to use the reissued IP even after the server has made the effort to test for potential conflict. This approach may not be appropriate in some situations. Consider the situation in which thousands of requests arrive at a centrally located server, nearly simultaneously, a couple hundred per net. A specific example would be a large university with large classrooms wired for net access and all or many of the classes beginning at approximately the same time. Under these conditions, the server may spend an inordinate amount of time sending echo requests, waiting (true, the wait can be asynchronous) for destination unreachables or responses. And of course, each response (indicating potential conflict and hence potentially misconfigured client) requires even more work by the server. I believe that the client should be charged with testing the newly issued IP before excepting it and, as the RFC states, send a DHCPDECLINE in the event of a detected conflict. In fact, perhaps the client should test for potential conflict with each new session. johnc ------------------------------------------------------------------------------- John D. Carlson Networks and Distributed Computing EMAIL: johnc@cac.washington.edu University of Washington BELL: (206) 685-6204 4545 15th Ave NE FAX: (206) 685-4044 Seattle, WA 98105   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08057; 28 Mar 95 12:41 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa08049; 28 Mar 95 12:41 EST Received: from sol.eg.bucknell.edu by CNRI.Reston.VA.US id aa14070; 28 Mar 95 12:41 EST Received: from decvax.dec.com (decvax.zk3.dec.com) by sol.eg.bucknell.edu (4.1/Bucknell-2.0) id ; Tue, 28 Mar 95 12:24:27 EST Received: from styrax.zk3.dec.com by decvax.dec.com (5.65/DEC-ULTRIX-8/19/92) id AA13340; Tue, 28 Mar 1995 12:24:09 -0500 Received: from brigit.zk3.dec.com by alpha.zk3.dec.com; (5.65/1.1.8.2/15Sep94-0303PM) id AA11694; Tue, 28 Mar 1995 12:24:06 -0500 Received: from localhost by brigit.zk3.dec.com; (5.65/1.1.8.2/19Sep94-0246PM) id AA23564; Tue, 28 Mar 1995 11:59:56 -0500 Message-Id: <9503281659.AA23564@brigit.zk3.dec.com> To: Ralph Droms Cc: host-conf@sol.eg.bucknell.edu, mwalnut@CNRI.Reston.VA.US, conta@zk3.dec.com Subject: Re: Agenda for Danvers Date: Tue, 28 Mar 95 11:59:56 -0500 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: conta@zk3.dec.com X-Mts: smtp In-reply-to: Message of: "Tue, 28 Mar 95 08:30:11 EST." Message-Id: <9503281329.AA22968@coral.bucknell.edu> Subject: Agenda for Danvers Received From: droms@bucknell.edu (Ralph Droms) Sent To: host-conf@sol.eg.bucknell.edu cc: mwalnut@CNRI.Reston.VA.US -------- X-Sender: droms@sol.cs.bucknell.edu Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Monday, 4/3, 1330-1530: Charlie Perkins IP mobility and DHCP option 30 min Jim Bound DHCPv6 90 min Tuesday, 4/4, 1330-1530: Greg Minshall Server to server interaction model 60 min WG Items from the floor 30 min Ralph Droms DHCPREVALIDATE, DHCPINFORM 15 min Ralph Droms Recent changes to protocol spec 15 min   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08894; 28 Mar 95 13:14 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa08890; 28 Mar 95 13:14 EST Received: from [134.82.27.1] by CNRI.Reston.VA.US id aa14973; 28 Mar 95 13:14 EST Received: from Sun.COM by sol.eg.bucknell.edu (4.1/Bucknell-2.0) id ; Tue, 28 Mar 95 12:52:45 EST Received: from East.Sun.COM (east.East.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA18032; Tue, 28 Mar 95 09:52:16 PST Received: from suneast.East.Sun.COM by East.Sun.COM (4.1/SMI-4.1) id AA18676; Tue, 28 Mar 95 12:52:14 EST Received: from canoepoint.East.Sun.COM by suneast.East.Sun.COM (5.0/SMI-4.1-900117) id AA15957; Tue, 28 Mar 1995 12:52:12 +0500 Received: by canoepoint.East.Sun.COM (5.x/SMI-SVR4) id AA09916; Tue, 28 Mar 1995 12:53:50 -0500 Date: Tue, 28 Mar 1995 12:53:50 -0500 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Mike Carney - Sun BOS Software Message-Id: <9503281753.AA09916@canoepoint.East.Sun.COM> Subject: Re: DHCPREVALIDATE (was Re: Some proposed changes to November draft) To: host-conf@sol.eg.bucknell.edu, mamros@ftp.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Md5: 67YNz6RTWswvHXVjqABzvA== Content-Length: 1752 Send again - doesn't look like this made it the first time. ------------- Begin Forwarded Message ------------- From Mike.Carney@East Mon Mar 27 11:55 EST 1995 Date: Sun, 26 Mar 1995 11:30:33 -0500 From: Mike.Carney@East (Mike Carney - Sun BOS Software) To: host-conf@sol.eg.bucknell.edu, mamros@ftp.com Subject: Re: DHCPREVALIDATE (was Re: Some proposed changes to November draft) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Md5: AiAE4JPTBumORfSVLi7yFg== I'm one of the vendors that Shawn mentions. Those of us at Connectathon (the second week, anyway, discussed this very issue as he mentions. As shawn points out, the server historically has been passive and the clients initiate all exchanges. DHCPREVALIDATE goes against this behavior. We've had numerous bakeoffs where we've proven interoperability of the spec less the recent DHCPINFORM and DHCPREVALIDATE messages. IMHO, I believe there are ways to achieve the acceptable behavior without adding these messages: 1) DHCPREVALIDATE. Shorten your lease time policy to level by which your clients will receive the updated information in an acceptable time frame. We use one hour for PC clients, and I'd envision 2 days for workstations, etc. Note that an advantage of this method over REVALIDATE is that client's will tend to attempt RENEW/REBIND at different times, whereas REVALIDATE is a "all at once" technique. (i'd hate to be the admin who makes a mistake configuring the parameters, then issues a REVALIDATE which hangs everyone's machine. ;^). 2) DHCPINFORM. The client sends a DISCOVER, collects the OFFERs, and uses the information contained therein (Sans the ip address) to configure various services, etc. Mike ------------- End Forwarded Message -------------   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08963; 28 Mar 95 13:17 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa08955; 28 Mar 95 13:17 EST Received: from sol.eg.bucknell.edu by CNRI.Reston.VA.US id aa15047; 28 Mar 95 13:17 EST Received: from Sun.COM by sol.eg.bucknell.edu (4.1/Bucknell-2.0) id ; Tue, 28 Mar 95 13:00:48 EST Received: from East.Sun.COM (east.East.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA19782; Tue, 28 Mar 95 09:59:52 PST Received: from suneast.East.Sun.COM by East.Sun.COM (4.1/SMI-4.1) id AA19554; Tue, 28 Mar 95 12:59:49 EST Received: from canoepoint.East.Sun.COM by suneast.East.Sun.COM (5.0/SMI-4.1-900117) id AA16334; Tue, 28 Mar 1995 12:59:47 +0500 Received: by canoepoint.East.Sun.COM (5.x/SMI-SVR4) id AA09938; Tue, 28 Mar 1995 13:01:20 -0500 Date: Tue, 28 Mar 1995 13:01:20 -0500 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Mike Carney - Sun BOS Software Message-Id: <9503281801.AA09938@canoepoint.East.Sun.COM> To: Mike.Carney@east.sun.com, johnc@cac.washington.edu Subject: Re: Question on leases Cc: host-conf@sol.eg.bucknell.edu, bmiller@bonsai.ccity.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Md5: LXDkyG7Z8F0hHQ48X7fJRw== Content-Length: 1957 >>Mike, >> >>I wonder if the use of an active approach, such as an ICMP echo, on the >>part of the server to prevent IP conflicts, is sufficient or appropriate. In addition to the ICMP echo, clients typically ARP for the assigned address before accepting it, sending a DECLINE if it is in use. >> >>It may not be sufficient since a confused system temporarily disassociated >>from the net (eg. disconnected, missed icmp, shutdown,...) would continue >>to use the reissued IP even after the server has made the effort to test >>for potential conflict. That's true. However, when the client is reattached to the net and booted, it will be assigned a different address. >> >>This approach may not be appropriate in some situations. Consider the >>situation in which thousands of requests arrive at a centrally located >>server, nearly simultaneously, a couple hundred per net. A specific >>example would be a large university with large classrooms wired for net >>access and all or many of the classes beginning at approximately the same >>time. Under these conditions, the server may spend an inordinate amount of >>time sending echo requests, waiting (true, the wait can be asynchronous) for >>destination unreachables or responses. And of course, each response >>(indicating potential conflict and hence potentially misconfigured client) >>requires even more work by the server. The ICMP echo is only done on initial allocation. The server doesn't ping clients in the INIT-REBOOT state, or whom already have assigned, valid addresses. >> >>I believe that the client should be charged with testing the newly issued >>IP before excepting it and, as the RFC states, send a DHCPDECLINE in the >>event of a detected conflict. In fact, perhaps the client should test for >>potential conflict with each new session. >> See above - our implementations do both the arp from the client side and the ping from the server side. >> >>johnc Mike   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10895; 28 Mar 95 14:47 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa10888; 28 Mar 95 14:47 EST Received: from sol.eg.bucknell.edu by CNRI.Reston.VA.US id aa17128; 28 Mar 95 14:47 EST Received: from shiva1.cac.washington.edu by sol.eg.bucknell.edu (4.1/Bucknell-2.0) id ; Tue, 28 Mar 95 14:15:10 EST Received: by shiva1.cac.washington.edu (5.65+UW95.02/UW-NDC Revision: 2.32 ) id AA08779; Tue, 28 Mar 95 11:13:11 -0800 Date: Tue, 28 Mar 1995 11:13:10 -0800 (PST) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: John Carlson To: Mike Carney - Sun BOS Software Cc: Mike.Carney@east.sun.com, host-conf@sol.eg.bucknell.edu, bmiller@bonsai.ccity.com Subject: Re: Question on leases In-Reply-To: <9503281801.AA09938@canoepoint.East.Sun.COM> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 28 Mar 1995, Mike Carney - Sun BOS Software wrote: > Date: Tue, 28 Mar 1995 13:01:20 -0500 > From: Mike Carney - Sun BOS Software > To: Mike.Carney@East.Sun.COM, johnc@cac.washington.edu > Cc: host-conf@sol.eg.bucknell.edu, bmiller@bonsai.ccity.com > Subject: Re: Question on leases > > > >>Mike, > >> > >>I wonder if the use of an active approach, such as an ICMP echo, on the > >>part of the server to prevent IP conflicts, is sufficient or appropriate. > > In addition to the ICMP echo, clients typically ARP for the assigned address > before accepting it, sending a DECLINE if it is in use. Near the bottom of the message I sent, which you are responding to here, I mention that this client action is mentioned in the RFC and is a good thing. > > >> > >>It may not be sufficient since a confused system temporarily disassociated > >>from the net (eg. disconnected, missed icmp, shutdown,...) would continue > >>to use the reissued IP even after the server has made the effort to test > >>for potential conflict. > > That's true. However, when the client is reattached to the net and booted, > it will be assigned a different address. Good point, but I was also thinking of the gray area in which a client has not decided that it has been disconnected (eg. brief temporary failure, lost packet, buffer overflow at the NIC,...) or perhaps when the net has become segmented in such a way as to isolate the two systems. > >> > >>This approach may not be appropriate in some situations. Consider the > >>situation in which thousands of requests arrive at a centrally located > >>server, nearly simultaneously, a couple hundred per net. A specific > >>example would be a large university with large classrooms wired for net > >>access and all or many of the classes beginning at approximately the same > >>time. Under these conditions, the server may spend an inordinate amount of > >>time sending echo requests, waiting (true, the wait can be asynchronous) for > >>destination unreachables or responses. And of course, each response > >>(indicating potential conflict and hence potentially misconfigured client) > >>requires even more work by the server. > > The ICMP echo is only done on initial allocation. The server doesn't > ping clients in the INIT-REBOOT state, or whom already have assigned, valid > addresses. In the scenario outlined above, the frequency of address reuse on a per net basis could prove to be very high. Imagine students moving from classroom to classroom (net to net) obtaining and releasing addresses as they go. For the most part, won't these clients view themselves as being in the INIT state? > > >> > >>I believe that the client should be charged with testing the newly issued > >>IP before excepting it and, as the RFC states, send a DHCPDECLINE in the > >>event of a detected conflict. In fact, perhaps the client should test for > >>potential conflict with each new session. > >> > See above - our implementations do both the arp from the client side and > the ping from the server side. As the RFC alludes, arp'ing by the client is a good thing. Agreed. johnc > > >> > >>johnc > > Mike >   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12984; 28 Mar 95 16:05 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa12980; 28 Mar 95 16:05 EST Received: from sol.eg.bucknell.edu by CNRI.Reston.VA.US id aa18969; 28 Mar 95 16:05 EST Received: from IETF.nri.reston.VA.US (ietf.cnri.reston.va.us) by sol.eg.bucknell.edu (4.1/Bucknell-2.0) id ; Tue, 28 Mar 95 15:46:35 EST Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa11140; 28 Mar 95 14:55 EST To: Ralph Droms Cc: host-conf@sol.eg.bucknell.edu, mwalnut@CNRI.Reston.VA.US Subject: Re: Agenda for Danvers In-Reply-To: Your message of "Tue, 28 Mar 95 08:30:11 EST." <9503281329.AA22968@coral.bucknell.edu> Date: Tue, 28 Mar 95 14:55:12 -0500 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Megan Davies Walnut Message-Id: <9503281455.aa11140@IETF.CNRI.Reston.VA.US> Hi Ralph, The DHC agenda is now available via gopher and the web. The times below however are incorrect. Both Monday and Tuesday's sessions begin at 1300 and end at 1500. Megan >> Monday, 4/3, 1330-1530: **** (should be 1300-1500) >> >> Charlie Perkins IP mobility and DHCP option 30 min >> Jim Bound DHCPv6 90 min >> >> >> Tuesday, 4/4, 1330-1530: **** (should be 1300-1500) >> >> Greg Minshall Server to server interaction model 60 min >> WG Items from the floor 30 min >> Ralph Droms DHCPREVALIDATE, DHCPINFORM 15 min >> Ralph Droms Recent changes to protocol spec 15 min >> >> >>   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02156; 29 Mar 95 8:26 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa02151; 29 Mar 95 8:26 EST Received: from sol.eg.bucknell.edu by CNRI.Reston.VA.US id aa00497; 29 Mar 95 8:26 EST Received: from Sun.COM by sol.eg.bucknell.edu (4.1/Bucknell-2.0) id ; Wed, 29 Mar 95 08:12:22 EST Received: from East.Sun.COM (east.East.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA10190; Wed, 29 Mar 95 05:12:20 PST Received: from suneast.East.Sun.COM by East.Sun.COM (4.1/SMI-4.1) id AA23169; Wed, 29 Mar 95 08:12:18 EST Received: from canoepoint.East.Sun.COM by suneast.East.Sun.COM (5.0/SMI-4.1-900117) id AA09628; Wed, 29 Mar 1995 08:12:17 +0500 Received: by canoepoint.East.Sun.COM (5.x/SMI-SVR4) id AA11074; Wed, 29 Mar 1995 08:13:55 -0500 Date: Wed, 29 Mar 1995 08:13:55 -0500 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Mike Carney - Sun BOS Software Message-Id: <9503291313.AA11074@canoepoint.East.Sun.COM> To: host-conf@sol.eg.bucknell.edu Subject: Comments on newest options draft Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Md5: QiIvXYZcbeUmq/q4HnJjmQ== Content-Length: 236 Hi Folks, My comments on the rev of 1533. (1) The date reads 10/93 (page 1) (2) pg 24, section 9.[4,5]: The codes for these are x and y ;^). (3) pg 28. We're missing the descriptions for options 62-65. Mike Carney SunSoft   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02173; 29 Mar 95 8:27 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa02169; 29 Mar 95 8:26 EST Received: from sol.eg.bucknell.edu by CNRI.Reston.VA.US id aa00514; 29 Mar 95 8:26 EST Received: from Sun.COM by sol.eg.bucknell.edu (4.1/Bucknell-2.0) id ; Wed, 29 Mar 95 08:11:26 EST Received: from East.Sun.COM (east.East.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA10099; Wed, 29 Mar 95 05:11:20 PST Received: from suneast.East.Sun.COM by East.Sun.COM (4.1/SMI-4.1) id AA23113; Wed, 29 Mar 95 08:11:18 EST Received: from canoepoint.East.Sun.COM by suneast.East.Sun.COM (5.0/SMI-4.1-900117) id AA09592; Wed, 29 Mar 1995 08:11:17 +0500 Received: by canoepoint.East.Sun.COM (5.x/SMI-SVR4) id AA11069; Wed, 29 Mar 1995 08:12:55 -0500 Date: Wed, 29 Mar 1995 08:12:55 -0500 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Mike Carney - Sun BOS Software Message-Id: <9503291312.AA11069@canoepoint.East.Sun.COM> To: host-conf@sol.eg.bucknell.edu Subject: comments on March 1995 draft Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Md5: Oth2uN2WqGzTLTIjGla3+w== Content-Length: 2587 Hi Folks, Here are my comments regarding the March 1995 draft of the protocol spec. (1) pg 10, last paragraph: 'interprestedby' should be 'interpreted by' (2) pg 14, table 1: Description of siaddr says ip address of next server in boot process. Why put this in DHCPNAK?? Table 3, pg 29 conflicts with this (I think table 3 is the more logical description) (3) pg 16, Item 5, first para: ARGGH! The 'lease identification cookie' strikes again! (4) pg 21, first para: I think we should add text clarifying when a DHCPDECLINE is used - like only if the client detects the ip address assigned in the ACK is already in use. (Via arp). (5) pg 22, section 3.4: DHCPINFORM. I think we don't need an additional message. Just send a DHCPDISCOVER! a) pg 34, section 4.3.5: Should the server leave yiaddr blank? If the packet is always unicast, then this will work ok. (6) pg 22, section 3.5: DHCPREVALIDATE: I see lots of problems with this message: a) If it is broadcast, one hopes that the admin didn't make a mistake configuring the dhcp server, because all the hosts in the entire administrative domain are about to obtain incorrect information say nothing about the load on the servers. b) Up to now, all DHCP exchanges have been initiated by the client. This message throws this aspect of the protocol on its ear. See pg 25, para 3. What should the server put in the xid field? Secs field? What about the yiaddr field? Don't relay agents look at this field? c) If the administrator, through policy sets a lease time that is relatively short, then they will achieve what REVALIDATE is attempting, without the "all at once" nature of the broadcast REVALIDATE. (7) I thought we changed the term 'client class' to 'class identifier'. RFC 1533 talks about 'class identifier', whereas the protocol spec uses 'client class'. Uses in the protocol spec: a) pg 27, para 2 and para 4. b) pg 29, table 3. c) pg 32, bullet 3, last para in 4.3.1. d) pg 39, table 5. I don't care which term we use, but we should be consistent between the two specs. (8) pg 34, section 4.3.2, last bullet item. We should clarify that a REBIND request uses the limited broadcast address (all ones). (9) pg 35, section 4.4: What about DHCPREVALIDATE? (10) pg 36, figure 5: DHCPINFORM/DHCPREVALIDATE not shown. (11) pg 38, table 5: DHCPINFORM not listed. (12) pg 40, section 4.4.3, para 1: 'bradcasts' should be 'broadcasts' Mike Carney SunSoft   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05831; 29 Mar 95 9:52 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa05827; 29 Mar 95 9:52 EST Received: from sol.eg.bucknell.edu by CNRI.Reston.VA.US id aa04474; 29 Mar 95 9:52 EST Received: from inet-gw-2.pa.dec.com by sol.eg.bucknell.edu (4.1/Bucknell-2.0) id ; Wed, 29 Mar 95 09:27:17 EST Received: from xirtlu.zk3.dec.com by inet-gw-2.pa.dec.com (5.65/24Feb95) id AA10196; Wed, 29 Mar 95 06:24:20 -0800 Received: by xirtlu.zk3.dec.com; id AA09948; Wed, 29 Mar 1995 09:24:18 -0500 Message-Id: <9503291424.AA09948@xirtlu.zk3.dec.com> To: host-conf@sol.eg.bucknell.edu Subject: DHCPv6 : "Variable Configuration Data" Date: Wed, 29 Mar 95 09:24:12 -0500 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: bound@zk3.dec.com X-Mts: smtp While building the slides to discuss this ID I realized that replacing the string "Variable Configuration Data" with "Optional Configuration Data" will make discussion more clear. The focus on the word variable was that in IPv6 fragmentation is only end-to-end and will not be done at routers. Hence, if a DHCPv6 packet over UDP exceeds 576 octets (by providing optional configuration data which can be variable) UDP must invoke the IPv6 fragmentation header to transmit the data. This implies an implementation can use PMTU Discovery for UDP. Of course where links are > 576 you can send bigger packets. Other less elegant options exist but I think this is the one that should be used. /jim   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06045; 29 Mar 95 10:04 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa06041; 29 Mar 95 10:04 EST Received: from sol.eg.bucknell.edu by CNRI.Reston.VA.US id aa04726; 29 Mar 95 10:04 EST Received: from coral.bucknell.edu by sol.eg.bucknell.edu (4.1/Bucknell-2.0) id ; Wed, 29 Mar 95 09:44:53 EST Received: from uvite54.bucknell.edu by coral.bucknell.edu; (5.65/1.1.8.2/29Aug94-0956AM) id AA21586; Wed, 29 Mar 1995 09:44:36 -0500 Message-Id: <9503291444.AA21586@coral.bucknell.edu> X-Sender: droms@sol.cs.bucknell.edu Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 29 Mar 1995 09:44:54 -0500 To: Megan Davies Walnut Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Ralph Droms Subject: Re: Agenda for Danvers Cc: host-conf@sol.eg.bucknell.edu, mwalnut@CNRI.Reston.VA.US I'd like to make a small change in the DHC WG agenda for Danvers (I'll see if I can get the start and stop times right!). Laird McCullochwould like to talk to the WG about an authentication mechanism for DHCP clients and hosts on Tuesday: Monday, 4/3, 1300-1500: ------------------------ Charlie Perkins IP mobility and DHCP option 30 min Jim Bound DHCPv6 60 min Ralph Droms DHCPREVALIDATE, DHCPINFORM 15 min Ralph Droms Recent changes to protocol spec 15 min Tuesday, 4/4, 1300-1500: ------------------------ Greg Minshall Server to server interaction model 60 min Laird McCulloch DHCP client and server authentication 30 min WG Items from the floor 30 min   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13586; 30 Mar 95 15:37 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa13582; 30 Mar 95 15:37 EST Received: from sol.eg.bucknell.edu by CNRI.Reston.VA.US id aa23692; 30 Mar 95 15:37 EST Received: from IETF.nri.reston.VA.US (ietf.cnri.reston.va.us) by sol.eg.bucknell.edu (4.1/Bucknell-2.0) id ; Thu, 30 Mar 95 15:23:22 EST Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa12819; 30 Mar 95 15:18 EST To: Ralph Droms Cc: Megan Davies Walnut , host-conf@sol.eg.bucknell.edu Subject: Re: Agenda for Danvers In-Reply-To: Your message of "Wed, 29 Mar 95 09:44:54 EST." <9503291444.AA21586@coral.bucknell.edu> Date: Thu, 30 Mar 95 15:18:33 -0500 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Megan Davies Walnut Message-Id: <9503301518.aa12819@IETF.CNRI.Reston.VA.US> Hi Ralph, I made the adjustment and included an "last updated 3/20/95" line. Megan >> I'd like to make a small change in the DHC WG agenda for Danvers (I'll see >> if I can get the start and stop times right!). Laird McCullochwould like >> to talk to the WG about an authentication mechanism for DHCP clients and >> hosts on Tuesday: >> >> Monday, 4/3, 1300-1500: >> ------------------------ >> Charlie Perkins IP mobility and DHCP option 30 min >> Jim Bound DHCPv6 60 min >> Ralph Droms DHCPREVALIDATE, DHCPINFORM 15 min >> Ralph Droms Recent changes to protocol spec 15 min >> >> >> Tuesday, 4/4, 1300-1500: >> ------------------------ >> Greg Minshall Server to server interaction model 60 min >> Laird McCulloch DHCP client and server authentication 30 min >> WG Items from the floor 30 min >> >> >> >>