From owner-dhcp-v6@bucknell.edu Tue Nov 7 11:05:09 2000 Received: from mail.bucknell.edu ([134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA13107; Tue, 7 Nov 2000 11:05:08 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id eA7G1sb01750; Tue, 7 Nov 2000 11:01:54 -0500 (EST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id eA7G1lb14430; Tue, 7 Nov 2000 11:01:47 -0500 (EST) Received: from rdroms-nt.cisco.com (ch2-dhcp133-146.cisco.com [161.44.133.146]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id LAA20556; Tue, 7 Nov 2000 11:01:28 -0500 (EST) Message-Id: <4.3.1.2.20001107104924.00b3e910@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Tue, 07 Nov 2000 10:59:24 -0500 To: DHCPv6 discussion list From: Ralph Droms Subject: Meeting in San Diego Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Remember that the cutoff for acceptance of I-Ds to be published before the San Diego IETF is 11/24 (rev -00 docs must be submitted by 11/17)... As is our custom, I have scheduled two DHC WG sessions - one for DHCPv4 issues (Monday, 12/11, 0930-1100) and one for DHCPv6 issues (Tuesday, 12/12. 0930-1100). If you have an agenda item for either meeting, please forward it to me so I can put together schedules for the two meetings. - Ralph From owner-dhcp-v4@bucknell.edu Tue Nov 7 11:07:01 2000 Received: from mail.bucknell.edu ([134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA13908 for ; Tue, 7 Nov 2000 11:07:00 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id eA7G1sb20995; Tue, 7 Nov 2000 11:01:54 -0500 (EST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id eA7G1lb14430; Tue, 7 Nov 2000 11:01:47 -0500 (EST) Received: from rdroms-nt.cisco.com (ch2-dhcp133-146.cisco.com [161.44.133.146]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id LAA20556; Tue, 7 Nov 2000 11:01:28 -0500 (EST) Message-Id: <4.3.1.2.20001107104924.00b3e910@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Tue, 07 Nov 2000 10:59:24 -0500 To: DHCPv4 discussion list From: Ralph Droms Subject: Meeting in San Diego Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Reply-To: rdroms@cisco.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Remember that the cutoff for acceptance of I-Ds to be published before the San Diego IETF is 11/24 (rev -00 docs must be submitted by 11/17)... As is our custom, I have scheduled two DHC WG sessions - one for DHCPv4 issues (Monday, 12/11, 0930-1100) and one for DHCPv6 issues (Tuesday, 12/12. 0930-1100). If you have an agenda item for either meeting, please forward it to me so I can put together schedules for the two meetings. - Ralph From owner-dhcp-v4@bucknell.edu Wed Nov 8 10:57:40 2000 Received: from mail.bucknell.edu ([134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA14226 for ; Wed, 8 Nov 2000 10:57:40 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id eA8FqQb04185; Wed, 8 Nov 2000 10:52:27 -0500 (EST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id eA8FqAb28488 for ; Wed, 8 Nov 2000 10:52:10 -0500 (EST) Received: from kkinnear-nt (ch2-dhcp133-101.cisco.com [161.44.133.101]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id KAA11047; Wed, 8 Nov 2000 10:51:54 -0500 (EST) Message-Id: <4.2.0.58.20001108104010.01c7ed30@funnel.cisco.com> X-Sender: kkinnear@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Wed, 08 Nov 2000 10:52:43 -0500 To: DHCPv4 discussion list From: Kim Kinnear Subject: Final Failover draft conference call -- next week! Cc: kkinnear@cisco.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Reply-To: kkinnear@cisco.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN ***** ** Conference Call Announcement to discuss the ** Failover draft -- you *must* reply to participate! ***** On October 27, we held a conference call to discuss the failover draft. I produced minutes for that call which I distributed to this list. If you want another copy, let me know and I'll send you one. The current failover draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-failover-07.txt During that call, we discussed the possibility of having another call this week -- yesterday or today, Nov. 7 or 8. Turns out that didn't work out, as we couldn't get the right set of folks together with sufficient notice to make it work. We are going to try one more time to get this call together on Tuesday, November 14, at 12pm-3pm EST. The current agenda is: 1. Experience with implementing the -07 draft. Proposal for the call: Tuesday, November 14, 2000 12pm-3pm EST This is not an interim working group meeting (in IETF parlance), but rather a "design group" meeting. This means that any decisions made have to be ratified by the entire working group (which is how we've always done it anyway). ************************************************** Conference Call Announcement YOU MUST REPLY TO PARTICIPATE (I have to reserve conference call slots) ************************************************** If you want to participate, I need usual email from you with answers to the following questions: 1. Your name(s), affiliation, and TIME ZONE (e.g., EST, PST). 2. The topics in the current failover draft which you would like to discuss in a conference call. Please order a list by priority. Examples might be: conflict resolution, initialization between partner servers, etc. 3. Will the above dates work for you? If not, please make some alternative proposals -- recognizing that time is short. These will be toll free calls inside of the continental US. If you are outside of the toll free area, and would need financial assistance as a condition of participation in such a call, please mention that and we'll see what we can work out. Send your reply *only* to kkinnear@cisco.com (i.e., do *not* reply to the whole dhcp-v4 list!). Thanks! ************************************************ Along about Friday November 10 or Monday November 13, I'll let all of the respondents know if the proposed dates worked, schedule the actual phone calls if they did, and distribute the phone numbers. Anyone will be able to participate after that time (after they contact me) of course. Cheers -- Kim Kim Kinnear Cisco Systems Chelmsford, MA 01824 (978) 244-8376 kkinnear@cisco.com From owner-dhcp-v6@bucknell.edu Fri Nov 10 16:42:09 2000 Received: from mail.bucknell.edu ([134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA17680; Fri, 10 Nov 2000 16:42:09 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id eAALcwb09336; Fri, 10 Nov 2000 16:38:58 -0500 (EST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id eAALcnb13224 for ; Fri, 10 Nov 2000 16:38:49 -0500 (EST) Received: from rdroms-nt.cisco.com (ch2-dhcp133-146.cisco.com [161.44.133.146]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id QAA11827 for ; Fri, 10 Nov 2000 16:38:33 -0500 (EST) Message-Id: <4.3.1.2.20001107110830.00acae50@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Fri, 10 Nov 2000 16:38:45 -0500 To: DHCPv6 discussion list From: Ralph Droms Subject: Update on status of DHCPv6 spec Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Mike, Jim and I have been working diligently to complete a revision of the DHCPv6 spec in time for the IETF meeting in San Diego. Our plan is to: * publish the draft before the 11/24 deadline * hold a design team teleconference early during the week of 12/4 to work through as many open issues as possible * bring the draft and the results of the design team teleconference to the WG for review at the IETF meeting in San Diego I will announce availability of the revised draft and details of the design team teleconference early next week. - Ralph From owner-dhcp-v6@bucknell.edu Fri Nov 10 21:43:32 2000 Received: from mail.bucknell.edu ([134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA29440; Fri, 10 Nov 2000 21:43:31 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id eAB2exb30872; Fri, 10 Nov 2000 21:40:59 -0500 (EST) Received: from lespaul.process.com (lespaul.process.com [192.42.95.27]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id eAB2ehb06779 for ; Fri, 10 Nov 2000 21:40:43 -0500 (EST) Received: by lespaul.process.com with Internet Mail Service (5.5.2650.21) id ; Fri, 10 Nov 2000 21:40:28 -0500 Message-ID: <63D30D6E10CFD11190A90000F805FE86036072CE@lespaul.process.com> From: Bernie Volz To: DHCPv6 discussion list Subject: RE: Update on status of DHCPv6 spec Date: Fri, 10 Nov 2000 21:40:27 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Ralph: Thanks for the update and thanks to you, Mike, and Jim for working on the draft! - Bernie Volz -----Original Message----- From: Ralph Droms [mailto:rdroms@cisco.com] Sent: Friday, November 10, 2000 4:39 PM To: DHCPv6 discussion list Subject: Update on status of DHCPv6 spec Mike, Jim and I have been working diligently to complete a revision of the DHCPv6 spec in time for the IETF meeting in San Diego. Our plan is to: * publish the draft before the 11/24 deadline * hold a design team teleconference early during the week of 12/4 to work through as many open issues as possible * bring the draft and the results of the design team teleconference to the WG for review at the IETF meeting in San Diego I will announce availability of the revised draft and details of the design team teleconference early next week. - Ralph From owner-dhcp-v4@bucknell.edu Mon Nov 13 13:08:33 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA21533 for ; Mon, 13 Nov 2000 13:08:32 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id eADI3qb10889; Mon, 13 Nov 2000 13:03:52 -0500 (EST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id eADI3nb18041 for ; Mon, 13 Nov 2000 13:03:49 -0500 (EST) Received: from kkinnear-nt (ch2-dhcp133-101.cisco.com [161.44.133.101]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id NAA07725; Mon, 13 Nov 2000 13:03:33 -0500 (EST) Message-Id: <4.2.0.58.20001113125427.03402620@funnel.cisco.com> X-Sender: kkinnear@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Mon, 13 Nov 2000 13:04:22 -0500 To: DHCPv4 discussion list From: Kim Kinnear Subject: Final Failover Draft Conference Call, Tuesday November 14 Cc: kkinnear@cisco.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Reply-To: kkinnear@cisco.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN The final failover draft conference call (for this revision, anyway) will take place tomorrow Tuesday November, 14, at 12:00 EST, and last for up to 3 hours. For most of you, that is tomorrow. The people that have responded to me and can attend tomorrow's call are: Ted Lemon Greg Rabil Richard Jones Ralph Droms (possibly first hour) Mark Stapp (first two hours at least) I have sent them the call info just prior to this post. These other people attended the Oct 27 meeting, and so I will also send them the phone information as well: Bernie Volz Steve Gonczi Thomas Narten Topic(s) for the Nov 14 meeting are (so far): a) Experience in implementing the failover draft. If you want to attend the Tuesday Nov. 14 call and your name was not on the above list, please send me email (if I missed someone, I apologize). Cheers -- Kim Kim Kinnear Cisco Systems (978) 244-8376 From owner-dhcp-v4@bucknell.edu Tue Nov 14 07:36:06 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA28433 for ; Tue, 14 Nov 2000 07:36:05 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id eAECVkb18622; Tue, 14 Nov 2000 07:31:47 -0500 (EST) Received: from sr14.nsw-remote.bigpond.net.au ([24.192.3.29]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id eAECVUb00658 for ; Tue, 14 Nov 2000 07:31:30 -0500 (EST) Received: from ned (CPE-144-132-216-240.nsw.bigpond.net.au [144.132.216.240]) by sr14.nsw-remote.bigpond.net.au (Pro-8.9.3/8.9.3) with SMTP id XAA11373 for ; Tue, 14 Nov 2000 23:31:03 +1100 (EDT) Message-Id: <4.2.2.20001114232421.00acf968@pop-server.nsw.bigpond.net.au> X-Sender: gned@pop-server.nsw.bigpond.net.au X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Tue, 14 Nov 2000 23:34:48 +1100 To: DHCPv4 discussion list From: Ned Subject: handling multiple dhcp servers under windows In-Reply-To: <200011090606.eA966ub24744@mail.bucknell.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Reply-To: gned@bigpond.net.au Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN hey everyone, this may seem like an odd situation but after connecting my cable modem to our ethernet hub we end up with effectively 2 dhcp servers on the network. I would like each of the clients to be able to access the internet either by connecting directly to the cable modem (through the hub with a login client) or through the server which is already logged in. The most obvious difficult arises from there being more than one DHCP server on the network - how does the Windows 2000 client choose which one to obtain an IP address from? And is it possible to make one of the dhcp servers the "default" one to the clients, given that I cannot control the dhcp server which is behind the cable modem. I have tried unplugging the server and when I refresh my IP, I get one from the cable modem but if the NT4 server and cable modem are both plugged in at the same time and I refresh the IP again, I always get an IP from the cable modem. I have even tried modifying every mention of the internal DHCP server to the cable modem dhcp server in the registry (under the TCP/IP service) but it still reverts to the internal DHCP server. Perhaps a slightly trickier problem is that of file sharing. The NT4 server serves a multitude of files to which access is required regardless of whether the client is connected to the internet through the server or through the cable modem. Since my local IPs are on a different subnet to the IPs handed out by the cable mdoem dhcp server, the traditional "internal" file server is not accessible while connected through the cable modem (both are accessible from an internal IP). I have noticed that it's possible to assign a network card more than one IP address but for me, the only solution would be to use two network cards (which I do and don't like) each connected to the different subnets. Is it possible to have one network card not only with two IPs on different subnets, but also one obtained via DHCP and one assigned? This feature doesn't seem readily available under NT4 and I'm wondering why. any help is appreciated. cheers, Ned From owner-dhcp-v4@bucknell.edu Wed Nov 15 14:44:43 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA21030 for ; Wed, 15 Nov 2000 14:44:43 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id eAFJdgO18179; Wed, 15 Nov 2000 14:39:42 -0500 (EST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id eAFJdVO21675 for ; Wed, 15 Nov 2000 14:39:32 -0500 (EST) Received: from kkinnear-nt (ch2-dhcp133-101.cisco.com [161.44.133.101]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA09141; Wed, 15 Nov 2000 14:39:16 -0500 (EST) Message-Id: <4.2.0.58.20001115110335.01cf4110@funnel.cisco.com> X-Sender: kkinnear@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Wed, 15 Nov 2000 14:40:05 -0500 To: DHCPv4 discussion list From: Kim Kinnear Subject: Minutes from failover draft Nov. 14 conf. call Cc: kkinnear@cisco.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Reply-To: kkinnear@cisco.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN We held a conference call yesterday (Tuesday, Nov. 14 2000) concerning the failover draft: http://www.ietf.org/internet-drafts/draft-ietf-dhc-failover-07.txt This was the final conference call before the -08 draft is submitted. We had a bit of a rocky start since I had managed to mis-schedule the conference call bridge, but we finally got started about 30 minutes late. The following people attended some or all of the meeting (and a big thanks to all of them): Ralph Droms DHC WG chair EST droms@bucknell.com Richard Jones Checkpoint Software PST richardj@sea.checkpoint.com Kim Kinnear Cisco Systems EST kkinnear@cisco.com Ted Lemon Nominum MST mellon@nominum.org Greg Rabil Lucent Technologies EST grabil@lucent.com Mark Stapp Cisco Systems EST mjs@cisco.com Sri Hary Vengadasubbu Cisco Systems EST srihary@cisco.com Bernie Volz IPWorks EST volz@ipworks.com The agenda was: a) Issues learned from implementing the -06/07 draft. Here are the minutes (which I've written in third person for, believe it or not, clarity): ---------------------------------------------------------- This meeting largely revolved around Ted Lemon telling the rest of us his comments on the draft, based on his experience of implementing the major elements of the -06 and -07 versions of the draft. Ted's overall comments were that, in general, he found the draft to be solid enough to implement from (modulo his further comments). We went through it page by page, and for completeness I will replicate that information here. The page numbers refer to the -07 version of the draft. I've ordered it by page number, not the order of discussion in the meeting. ----------------- Pg. 68: Table 7.9.1 Need to be fixed to say that the reject-reason option MUST be sent if it is a rejected packet, and MUST NOT be sent otherwise. ----------------- Pg. 83: Startup doesn't talk about states than partner down. In particular, for other connected states (other than NORMAL, which is mentioned), what do you do when you come up (since by definition you are not connected then)? Kim agreed to clarify that in the draft. ----------------- Pg. 86: The state RESOLUTION-INTERRUPTED does not appear in the table. Kim said that the RESOLUTION-INTERRUPTED state was a new state, and clearly he missed some places in integrating it into the draft, but that he would ensure that it appeared in all of the proper places. ----------------- Pg. 87: Ted said that he thought that the time that is listed as "the current time", should be "the time the server came up". These could be different in this case because there is an UPDREQALL->UPDDONE sequence between when the server came up and the current time. Kim said that he would think about this and almost certainly change it to the "time the server came up", or explain why that could not be done in the draft. ----------------- Issue: Kim mentioned that a related issue to this section was that many servers would implement failover with a "partner-up-to-date" bit, to distinguish IP addresses which were or were not up to date at the partner. This approach works just fine -- except when the partner server changes or has no memory of any previous information. While the UPDREQALL message was invented to solve this problem, it doesn't cover many cases, e.g., when due to a reconfiguration of a server an IP address moves from one pool to another, and the pools have different failover partners. Kim offered a failover-endpoint sequence number as a possible solution to this problem, and said that he would be thinking about how much of this to put in the draft and how much was just an implementation issue. But that he would put *something* in the draft so that people wouldn't have to stumble over this problem as he did. ----------------- Pg. 87: Ted said "What happens if the communications are interrupted if you are in RECOVER state?". Kim said that you stay there, but Ted pointed out that this was not explicit in the draft, just implicit from the lack of a transition arc from the RECOVER state in the state transition diagram. Kim said he would clarify this. ----------------- Pg. 91: Ted said that he had a situation where two servers would go into COMMUNICATIONS-INTERRUPTED state and NORMAL state and back again. He felt that it probably wasn't the draft's fault, but it still happened and he finally fixed it. Kim said that he would see if the draft could be tightened up in this area. ----------------- Pg. 91: Ted said that if you were in PARTNER-DOWN state and received a SHUTDOWN message (i.e., state) from the partner server, that the transition into PARTNER-DOWN state was not well documented. Kim said that he would clarify this, at least in the text, and *maybe* in the state transition diagram picture. ----------------- Pg. 95: Ted said that, with loadbalancing enabled, if the two servers transitioned into NORMAL state at different times (much different anyway), that the loadbalancing wouldn't work right. Kim and the group discussed this and decided to add a new state something like POTENTIAL-CONFLICT-DONE for the primary, such that it would be responsive to *all* requests (like COMMUNICATIONS-INTERRUPTED), and it would hang out here until the secondary was ready to go to NORMAL state, when they would both go to NORMAL together. This is analogous to the RECOVER/RECOVER-DONE synchronization point (which is needed for a different reason). ------------------ Pg. 97: Ted said that you could make transitions into SHUTDOWN state from lots of other states, but that wasn't called out anywhere. Kim said that he would fix this problem. ------------------- Pg. 108: In the hash bucket assignment algorithm, it doesn't say what server the hash bucket bits are for -- the primary or secondary. It implies that they are the bits that are on for the secondary. Kim said that he would make this clearer, and add text on page 26 about this as well. ------------------- Issue: The group talked about the problem where a lease which was leased by the secondary expires and goes back to the primary, and then the client which wanted it asks the secondary for it (because of load balancing). We discussed that this was more or less the way it had to be, because the more important issue is to have the secondary have enough addresses to allocate to clients, and to do that you have to give the secondary leases soon after they are allocated and not necessarily wait for some leases to expire. That said, we decided to put words in the draft to the effect that the primary should attempt to send leases to the secondary that have been leases by the secondary in the past and who's most recent client would end up being processed by the secondary due to load balancing. ------------------ Issue: Ted talked about how he was thinking of another state like BACKUP-RESERVED for IP addresses which would indicate it was leased as a dynamic BOOTP lease. We talked about why he would want to know this, and the reasons were strong (so that he could consider a client with a client-id and one without a client-id to be the "same" client if the MAC addresses compared equivalent and it was a dynamic BOOTP lease). This is another "flag" for an IP address, kind of like the reserved flag. Since Kim had promised Steve G. that he would build in a flags byte if there was another flag (and remove the BACKUP-RESERVED) state as a way to handle reserved leases, Kim decided to add that flags byte now. (Thought it may have 16 bits to start). ------------------------------- That's it for now. A *big* thanks to all who attended, especially Ted who dug through his notes and code to pass along this really useful information. Cheers -- Kim From owner-dhcp-v4@bucknell.edu Mon Nov 20 15:13:17 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA08517 for ; Mon, 20 Nov 2000 15:13:17 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id eAKK8fO27679; Mon, 20 Nov 2000 15:08:41 -0500 (EST) Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id eAKK8WO02255 for ; Mon, 20 Nov 2000 15:08:32 -0500 (EST) Received: from 157.54.9.108 by mail5.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 20 Nov 2000 12:08:11 -0800 (Pacific Standard Time) Received: by INET-IMC-05 with Internet Mail Service (5.5.2651.58) id ; Mon, 20 Nov 2000 12:08:15 -0800 Message-ID: <5F1EEFAFB3573A46812FE84EF29C9AF501CDE7CA@red-msg-05.redmond.corp.microsoft.com> From: Matthew Williamson To: DHCPv4 discussion list Subject: draft-ietf-dhc-csr-02.txt Date: Mon, 20 Nov 2000 12:08:03 -0800 X-Mailer: Internet Mail Service (5.5.2651.58) Reply-To: mattwi@microsoft.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Hello All, >From reading the draft draft-ietf-dhc-csr-02.txt ( http://www.ietf.org/internet-drafts/draft-ietf-dhc-csr-02.txt ), I've drawn the conclusion that it sunsetted te old classed based option 33 in favor of a classless based routing scheme. Has this been made final? From owner-dhcp-v4@bucknell.edu Mon Nov 20 15:57:13 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA15789 for ; Mon, 20 Nov 2000 15:57:13 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id eAKKrEO22892; Mon, 20 Nov 2000 15:53:14 -0500 (EST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id eAKKr1O16451 for ; Mon, 20 Nov 2000 15:53:01 -0500 (EST) Received: from rdroms-nt.bucknell.edu (ch2-dhcp133-146.cisco.com [161.44.133.146]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id PAA27273; Mon, 20 Nov 2000 15:52:34 -0500 (EST) Message-Id: <4.3.1.2.20001120153955.00ae6200@mail.bucknell.edu> X-Sender: droms@mail.bucknell.edu X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Mon, 20 Nov 2000 15:45:38 -0500 To: DHCPv4 discussion list From: Ralph Droms Subject: Re: draft-ietf-dhc-csr-02.txt In-Reply-To: <5F1EEFAFB3573A46812FE84EF29C9AF501CDE7CA@red-msg-05.redmon d.corp.microsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Reply-To: droms@bucknell.edu Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN At 12:08 PM 11/20/00 -0800, Matthew Williamson wrote: > From reading the draft draft-ietf-dhc-csr-02.txt ( >http://www.ietf.org/internet-drafts/draft-ietf-dhc-csr-02.txt ), I've drawn >the conclusion that it sunsetted te old classed based option 33 in favor of >a classless based routing scheme. Yes - this new option will be preferred over option 33; we don't have a mechanism in place to formally withdraw old options. >Has this been made final? It has gone through one WG last call; submission to the IESG is pending completion of some changes based on comments received during that last call. - Ralph From owner-dhcp-v4@bucknell.edu Tue Nov 21 16:53:14 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA11180 for ; Tue, 21 Nov 2000 16:53:13 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id eALLmIO00043; Tue, 21 Nov 2000 16:48:18 -0500 (EST) Received: from king.pbc.com ([63.207.108.70]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id eALLm3O02956 for ; Tue, 21 Nov 2000 16:48:03 -0500 (EST) Received: from pacband.com ([192.168.11.55]) by king.pbc.com (8.9.3/8.9.3) with ESMTP id NAA21100 for ; Tue, 21 Nov 2000 13:46:53 -0800 Message-ID: <3A1AED4C.AD87DF23@pacband.com> Date: Tue, 21 Nov 2000 13:46:52 -0800 From: Burcak Beser Reply-To: Burcak@pbc.com Organization: Pacific Broadband Communications X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: DHCPv4 discussion list Subject: [Opinion Request] DHCP Option for PacketCable VoIP Client Configuration Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit (Sorry for the last minute broadcast. -nbb) Per 47th IETF minutes I would like to get opinions related to the draft 'DHCP Option for PacketCable VoIP Client Configuration' (http://search.ietf.org/internet-drafts/draft-ietf-dhc-packetcable-00.txt). I am preparing a new draft which only includes small changes in the suboption fields. Thanks in advance, Burcak Beser Pacific Broadband Communications ------------------------ : DHCP Option for PacketCable VoIP Client Configuration Burcak Beser ------------ This new option is used to hand out different configurations behind one IP address. The author will ask for review on WG mailing list. From owner-dhcp-v4@bucknell.edu Wed Nov 22 11:34:37 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA21556 for ; Wed, 22 Nov 2000 11:34:36 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id eAMGV3O19531; Wed, 22 Nov 2000 11:31:04 -0500 (EST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id eAMGUoO26205 for ; Wed, 22 Nov 2000 11:30:51 -0500 (EST) Received: from kkinnear-nt (ch2-dhcp133-83.cisco.com [161.44.133.83]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id LAA02762; Wed, 22 Nov 2000 11:30:33 -0500 (EST) Message-Id: <4.2.0.58.20001122112340.01ce54f0@funnel.cisco.com> X-Sender: kkinnear@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Wed, 22 Nov 2000 11:31:22 -0500 To: DHCPv4 discussion list From: Kim Kinnear Subject: what's new in draft-ietf-dhc-failover-08.txt Cc: kkinnear@cisco.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Reply-To: kkinnear@cisco.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN I just submitted the -08 version of the failover draft: draft-ietf-dhc-failover-08.txt. It will no doubt be available on the IETF web site in a few days. I will be more than happy to send a copy of it to anyone who simply can't wait for it to wend its way through to the IETF site. The point of this email is to give anyone interested the list of what changed in this revision, which I've listed below. Cheers -- Kim --------------------------------------------------------- Changes to DHCP failover draft in November 2000 revision: 1. Removed BACKUP-RESERVED IP address state, and added IP-flags option to contain a RESERVED and a BOOTP flag. Modified text to remove BACKUP-RESERVED state and add words for RESERVED and BOOTP flag. 2. Added a new section 5.4, IP address allocations between servers, which explains in considerably more detail the reasoning behind the IP address allocations process between server as well as the specific techniques that should be used by the primary and secondary servers in dealing with available addresses. Included directions to consider loadbalancing and the most recent client MAC address when making decisions as to which server gets which addresses. 3. Added section 5.13, What is sent in response to an UPDREQ or UPDREQALL message, to better explain the issues surrounding change of failover partner and how to handle total update of failover partner. 4. Fixed Table 7.9.1 to have two columns, one for accept and one for reject to make it agree with the text and to respond to Ted's comments. 5. Fixed startup section to talk about states than partner down. In particular, for other connected states (other than NORMAL, which is mentioned). Corrected RECOVER state to show it as either communications OK and no OK in figure 9.2-1. Also renumbered the steps to get them in order. 6. Added the state RESOLUTION-INTERRUPTED to the table in 9.4.3. 7. Added information on what to do if in RECOVER state and communications is interrupted. 8. In section 9.5.2, made the time listed as "the current time" be "the time the server came up". These could be different in this case because there is an UPDREQALL->UPDDONE sequence between when the server came up and the current time. 9. Added information to the NORMAL state in the text and in the transition diagram on how to handle the SHUTDOWN and PAUSED transitions that might be received from another server. 10. Ted said that you could make transitions into SHUTDOWN state from lots of other states, but that wasn't called out anywhere. When looking into this, Kim realized that you don't really transition into SHUTDOWN or PAUSED state, but rather tell your partner that (but leave your own current state the same). Added some words to the intro of the figure 9.2-1 describing this. 11. Clarified the hash-bucket-assignment option as being directed to the secondary server. 12. Added a new state, CONFLICT-DONE, to handle differing degree of responsiveness as primary transitions out of POTENTIAL-CONFLICT state. This is analogous to the RECOVER/RECOVER-DONE synchronization point (which is needed for a different reason). Modified the state transition diagram as well as added a new section describing the state. 13. Added new port 847 in place of port TBD throughout the draft. 14. Tied reject reasons to sections of the draft where they appear, and (in general), included specifics of numbers and message text in the text of the draft. ------------------- Pg. 91: Ted said that he had a situation where two servers would go into COMMUNICATIONS-INTERRUPTED state and NORMAL state and back again. He felt that it probably wasn't the draft's fault, but it still happened and he finally fixed it. Kim said that he would see if the draft could be tightened up in this area. He didn't find anything to change. From owner-dhcp-v4@bucknell.edu Thu Nov 23 06:54:15 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA24048 for ; Thu, 23 Nov 2000 06:54:15 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id eANBoJO10878; Thu, 23 Nov 2000 06:50:19 -0500 (EST) Received: from mxtlv1.corrigent.com ([199.203.64.33]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id eANBo7O14032 for ; Thu, 23 Nov 2000 06:50:07 -0500 (EST) Received: by mxtlv1.corrigent.com with Internet Mail Service (5.5.2650.21) id ; Thu, 23 Nov 2000 13:48:30 +0200 Message-ID: <8FA6CEF9A4E42B48A5F8DC038655B35320C2BC@mxtlv1.corrigent.com> From: Ofer Dayan To: DHCPv4 discussion list Subject: DHCP SW Package. Date: Thu, 23 Nov 2000 13:48:29 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="windows-1255" Reply-To: Oferd@corrigent.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Hi All, I am looking for a DHCP 3rd party software package for embedded environment (VxWorks OS). Could anyone recommend on any specific vendor? Thanks Ofer Dayan, RT Software engineer Corrigent Systems, Inc. tel +972 3 6084713 mailto:oferd@corrigent.com From owner-dhcp-v6@bucknell.edu Thu Nov 23 21:10:03 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA17421; Thu, 23 Nov 2000 21:10:03 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id eAO273O23727; Thu, 23 Nov 2000 21:07:03 -0500 (EST) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id eAO26oO10915 for ; Thu, 23 Nov 2000 21:06:50 -0500 (EST) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130]) by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id SAA00781 for ; Thu, 23 Nov 2000 18:06:35 -0800 (PST) Received: from mailman.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.10.1/8.10.1) with ESMTP id eAO26iA03021 for ; Thu, 23 Nov 2000 18:06:44 -0800 (PST) Received: from rdroms-nt.cisco.com (ssh-sj1.cisco.com [171.68.225.134]) by mailman.cisco.com (8.9.3/8.9.1) with ESMTP id SAA20322 for ; Thu, 23 Nov 2000 18:06:33 -0800 (PST) Message-Id: <4.3.1.2.20001122120109.00bcd520@funnel.cisco.com> X-Sender: rdroms@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Thu, 23 Nov 2000 21:06:32 -0500 To: DHCPv6 discussion list From: Ralph Droms Subject: -16 rev of DHCPv6 spec; design team teleconference Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN I've published the -16 rev of the DHCPv6 spec later today. The changes to this document are based primarily on the results of the design team teleconference of 8/31 and subsequent WG mailing list discussion. I've included a summary of changes at the end of this message. I am planning another design team teleconference for 12/5, 12noon-3PM EST. The purpose for this teleconference is to discuss the changes in the -16 rev, with the goal of identifying and resolving as many outstanding issues as possible. The results of the teleconference will be reported at the WG meeting in San Diego. Any unresolved issues from the teleconference will be discussed during the WG meeting. Cisco Systems is happy to host the design team teleconference in Chelmsford, MA. In addition to a conference room in Chelmsford, we will have conference call capability to accommodate those who can't attend in person. and will be happy to reimburse those outside the U.S. for their calls. If you want to participate in the call on 12/5, please contact me for the phone number and conference ID. More details will follow next week. - Ralph PS If you're just *dying* to get a copy of the -16 rev, try ftp://ftp.eg.bucknell.edu/pub/draft-ietf-dhc-dhcpv6-16.txt ===== 23. Changes in this draft This section describes the changes between this version of the DHCPv6 specification and draft-ietf-dhc-dhcpv6-15.txt. 23.1. Order of sections New sections have been added at the end of this document to minimize changes in section numbering. Those sections will be rearranged in a future revision. 23.2. Reconfigure message DHCP Reconfigure and Reconfigure-reply messages and the associated mechanisms have been removed from this draft of the specification. 23.3. Releasable resources ``Releasable resources'' have been removed from this draft. 23.4. DHCP message header A common fixed DHCP message header has been defined. Not all fields are used in all messages. 23.5. Design goals The second sentence in the 8th design goal bullet has been removed. 23.6. Overview Section 8.2 (DHCP agents) has been removed. DHCP clients no longer need to know about specific DHCP agents. Section 8.3 has been modified to reflect the new encapsulating mechanism through which relays forward client messages to servers. Section 8.6 and 8.7 have been modified to describe ``identity associations''. Section 8.8 has been modified to reflect the deletion of ``reconfigure'' and ``reconfigure-reply'' messages. 23.7. Message formats, 9 Message formats have been changed. All messages share a common fixed message header followed by options. 23.8. Solicit and Advertise messages, (section 10) The description of the message exchanges have been changed to reflect: - New relay behavior - encapsulated client messages - Use of IAs 23.9. Prefix advertisement Servers no longer advertise prefixes. 23.10. Identity Associations Section 9.11 describes IAs in detail. A definition of ``IA'' has been added to section 2. The description of messages exchanges have been extended to include IAs. The IA option is defined in section 22.2 23.11. Extensions renamed options; defined in this document ``extensions'' are now called ``options''; the options referenced in this document are defined in section 22. 23.12. Transaction-ID ranges Solicit, Advertise, Request, Reply, Release and Reconfigure-init messages all use an unsigned 16-bit integer ``Transaction-ID''. Transaction-IDs generated by clients are considered to be chosen from a different namespace than those chosen by servers. There is no need to restrict clients and servers to select Transaction-IDs from specific ranges to avoid conflicts. 23.13. Release messages and relays Release/Reply messages are forwarded through relays. This mechanism eliminates the need for an 'R' bit. 23.14. Discovering relay agents Clients no longer learn the identity of relay agents. When the client only has a link-local address (e.g., the client has no assigned addresses), it now multicasts Request message, which is then forwarded by a relay agent on the same link. From owner-dhcp-v4@bucknell.edu Fri Nov 24 07:04:22 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA11198 for ; Fri, 24 Nov 2000 07:04:21 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id eAOC0aO20273; Fri, 24 Nov 2000 07:00:36 -0500 (EST) Received: from stud.fh-muenchen.de (IDENT:root@[141.39.248.60]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id eAOC0QO23173 for ; Fri, 24 Nov 2000 07:00:26 -0500 (EST) Received: from localhost (ld@localhost) by stud.fh-muenchen.de (8.11.0/8.8.7) with ESMTP id eAOBxt705074 for ; Fri, 24 Nov 2000 12:59:55 +0100 Date: Fri, 24 Nov 2000 12:59:51 +0100 (CET) From: =?ISO-8859-1?Q?Lars_D=FCsing?= To: DHCPv4 discussion list Subject: DHCP using MAC-pools? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: ld@stud.fh-muenchen.de Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi! Is it possible to limit DHCP-leases only to predefined mac-adresses (but not bind them to a fixed IP-Adress!) Our problem is, we have some thousands of computers, and want only registered computers to get an DHCP-lease. Thanks in advance, Lars Duesing students office of the university of applied sciences, munich -----BEGIN PGP SIGNATURE----- Version: PGP 6.5.8 iQA/AwUBOh5YOiO+29uibNrEEQINuwCeK2CuGq5xQauBVM8W2TQ4GmDhXYwAoMvl CoJ2PSlEjHBoJdovKxnj2ZoE =SsBf -----END PGP SIGNATURE----- From owner-dhcp-v4@bucknell.edu Sun Nov 26 09:33:25 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA14122 for ; Sun, 26 Nov 2000 09:33:25 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id eAQESPO13268; Sun, 26 Nov 2000 09:28:25 -0500 (EST) Received: from lespaul.process.com (lespaul.process.com [192.42.95.27]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id eAQESIO27607 for ; Sun, 26 Nov 2000 09:28:18 -0500 (EST) Received: by lespaul.process.com with Internet Mail Service (5.5.2650.21) id ; Sun, 26 Nov 2000 09:28:02 -0500 Message-ID: <63D30D6E10CFD11190A90000F805FE860360739C@lespaul.process.com> From: Bernie Volz To: DHCPv4 discussion list Cc: "'dhcp-v4@bucknell.edu'" Subject: Feedback on draft-ietf-dhc-leasequery-00.txt Date: Sun, 26 Nov 2000 09:27:58 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Reply-To: Volz@ipworks.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Kim/Rich: This draft looks very good - I haven't read it cover-to-cover (skimmed parts, read others). You might want to reword section 6.3, in particular: In order to accommodate DHCPLEASEQUERY messages sent to a DHCP Fail- over secondary server [FAILOVER] when the primary server is down, the primary server MUST communicate the Relay Agent Information option (82) values to the secondary server via the DHCP Failover BNDUPD mes- sages. This should really be written to indicate that either partner must do this, not just the primary to the secondary. Especially with Load Balancing, this must happen in both directions (whomever does the leasing must communicate with the partner). Also, what happens in the case of a lazy update not having made it to the peer by the time a DHCPLEASEQUERY is received? If the secondary leased the address to a client but has not send the BNDUPD to the primary, the primary might respond with address not leased when it technically was leased. Perhaps one solution is that the relay agent should really query the other server as well should it get a DHCPACK without an associated client? Or, another solution is to have a special response that indicates 'address owned by partner, please check with it' - this could be done by the primary if the requested IP address is in the 'backup' state (owned by secondary) and by the secondary if the address is in the 'free' state (owned by primary). Would likely require another option code though. Or, perhaps one could overload the next server address (siaddr) with the failover partner's address - the relay can then check to see if that address was the queried DHCP server's or not, if not query that next server address (this does get a bit tricky in multi-homed environments). In section 7, Security, you might also suggest that DHCP servers be configurable with a list of the ip-addresses of the devices allowed to request DHCPLEASEQUERYs. While not a great security mechanism, it does improve things somewhat. One could require that the giaddr is the same as the UDP datagram's source address and that that address is in the list of allowed addreses. (Adding the giaddr/source address check avoids nasty denial of service attacks on both the DHCP server and relay-agent!) - Bernie Volz From owner-dhcp-v4@bucknell.edu Sun Nov 26 17:23:38 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA10001 for ; Sun, 26 Nov 2000 17:23:38 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id eAQMIMO25256; Sun, 26 Nov 2000 17:18:22 -0500 (EST) Received: from lespaul.process.com (lespaul.process.com [192.42.95.27]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id eAQMIGO21104 for ; Sun, 26 Nov 2000 17:18:16 -0500 (EST) Received: by lespaul.process.com with Internet Mail Service (5.5.2650.21) id ; Sun, 26 Nov 2000 17:18:00 -0500 Message-ID: <63D30D6E10CFD11190A90000F805FE86036073A5@lespaul.process.com> From: Bernie Volz To: DHCPv4 discussion list Subject: RE: [Opinion Request] DHCP Option for PacketCable VoIP Client Con figuration Date: Sun, 26 Nov 2000 17:17:54 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Reply-To: Volz@ipworks.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Here are some comments: 1. The abstract needs to be improved. I'm not sure what the first sentence is trying to say? Seems like the Introduction section could serve as the abstract? 2. The DNS sub-fields section states that they must be in IPv4 address format, yet the table in 6.3 shows that either the FQDN:port or [a.b.c.d]:port format is allowed. Shouldn't it just show [a.b.c.d]:port. Also, exactly what's the difference between these DNS servers and the normal DNS servers configurable with DHCP Option 6 (Domain Name Server Option, see RFC 2132 section 3.8). Why can't those DNS servers be used? Is there a reason why you need another set? If none are configured with these sub-fields, should the VoIP client use the DHCP Option 6 ones? 3. I assume the brackets around the internet-address are required? And the port number (:port) is optional? While the text implies this, it might be worth while to make it perfectly clear. Examples of the various legal formats might help. For example, the following are valid values that can be used: 132.151.1.19 132.151.1.19:53 ietf.org ietf.org:53 4. The text in section 5 regarding the format of the option and then the sub-options within the option data could be more explicit. While we probably all know what you mean, it would be good to be extremely explicit. I suggest the latest DHCP Relay Agent Information Option draft (http://search.ietf.org/internet-drafts/draft-ietf-dhc-agent-options-12.txt) for text that you can likely borrow from. 5. In 6., it says "For example, the standard DNS UDP port number is 42/udp.". The DNS UDP port number is 53, not 42. 42 is the old host name server. From IANA: name 42/tcp Host Name Server name 42/udp Host Name Server nameserver 42/tcp Host Name Server nameserver 42/udp Host Name Server domain 53/tcp Domain Name Server domain 53/udp Domain Name Server 6. In other drafts that have used a single option to encode 'sub-options' have called them sub-options. I suggest you rename sub-fields to be sub-options? See the latest DHCP Relay Agent Information Option draft (http://search.ietf.org/internet-drafts/draft-ietf-dhc-agent-options-12.txt) . 7. I'm not sure about the heading for 6.4 (Procedure for adding call control server types). Why isn't this sub-fields (or sub-options)? Also, this information should be in an IANA Considerations section (again, see the DHCP Relay Agent Information Option draft as you can probably just 'borrow' that text). 8. Aren't you missing the standard 'full-copyright statement' for Internet-Drafts? Also, does 3Com or anyone claim any Intellectual Property Rights regarding this draft? If so, you'll need to identify that. 9. You might clean up the formatting a bit. Currently, page headings sometimes don't have any blank lines around them and it makes reading the text difficult when a heading appears in the middle of the text. Also, you're often missing 'a' or 'the' or similar words in some of the sentences that would make them read better. Other than the above, the concepts behind the draft are basically sound (IMHO). Hope that's what you were looking for. - Bernie Volz Ericsson, DNS & DHCP Development Unit -----Original Message----- From: Burcak Beser [mailto:Burcak@pacband.com] Sent: Tuesday, November 21, 2000 4:47 PM To: DHCPv4 discussion list Subject: [Opinion Request] DHCP Option for PacketCable VoIP Client Configuration (Sorry for the last minute broadcast. -nbb) Per 47th IETF minutes I would like to get opinions related to the draft 'DHCP Option for PacketCable VoIP Client Configuration' (http://search.ietf.org/internet-drafts/draft-ietf-dhc-packetcable-00.txt). I am preparing a new draft which only includes small changes in the suboption fields. Thanks in advance, Burcak Beser Pacific Broadband Communications ------------------------ : DHCP Option for PacketCable VoIP Client Configuration Burcak Beser ------------ This new option is used to hand out different configurations behind one IP address. The author will ask for review on WG mailing list. From owner-dhcp-v6@bucknell.edu Mon Nov 27 08:34:25 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA08605; Mon, 27 Nov 2000 08:34:25 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id eARDVCO02781; Mon, 27 Nov 2000 08:31:13 -0500 (EST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id eARDUkO28391 for ; Mon, 27 Nov 2000 08:30:46 -0500 (EST) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id FAA23565 for ; Mon, 27 Nov 2000 05:30:29 -0800 (PST) Received: from mailman.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.10.1/8.10.1) with ESMTP id eARDUbA12834 for ; Mon, 27 Nov 2000 05:30:37 -0800 (PST) Received: from rdroms-nt.cisco.com (ssh-sj1.cisco.com [171.68.225.134]) by mailman.cisco.com (8.9.3/8.9.1) with ESMTP id FAA04225 for ; Mon, 27 Nov 2000 05:30:26 -0800 (PST) Message-Id: <4.3.1.2.20001127082938.00bdde60@localhost> X-Sender: rdroms@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Mon, 27 Nov 2000 08:30:06 -0500 To: DHCPv6 discussion list From: Ralph Droms Subject: -16 rev of DHCPv6 spec; design team teleconference Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN (This is a resend in case the original got lost in your flood of vacation e-mail... - RD) I've published the -16 rev of the DHCPv6 spec later today. The changes to this document are based primarily on the results of the design team teleconference of 8/31 and subsequent WG mailing list discussion. I've included a summary of changes at the end of this message. I am planning another design team teleconference for 12/5, 12noon-3PM EST. The purpose for this teleconference is to discuss the changes in the -16 rev, with the goal of identifying and resolving as many outstanding issues as possible. The results of the teleconference will be reported at the WG meeting in San Diego. Any unresolved issues from the teleconference will be discussed during the WG meeting. Cisco Systems is happy to host the design team teleconference in Chelmsford, MA. In addition to a conference room in Chelmsford, we will have conference call capability to accommodate those who can't attend in person. and will be happy to reimburse those outside the U.S. for their calls. If you want to participate in the call on 12/5, please contact me for the phone number and conference ID. More details will follow next week. - Ralph PS If you're just *dying* to get a copy of the -16 rev, try ftp://ftp.eg.bucknell.edu/pub/draft-ietf-dhc-dhcpv6-16.txt ===== 23. Changes in this draft This section describes the changes between this version of the DHCPv6 specification and draft-ietf-dhc-dhcpv6-15.txt. 23.1. Order of sections New sections have been added at the end of this document to minimize changes in section numbering. Those sections will be rearranged in a future revision. 23.2. Reconfigure message DHCP Reconfigure and Reconfigure-reply messages and the associated mechanisms have been removed from this draft of the specification. 23.3. Releasable resources ``Releasable resources'' have been removed from this draft. 23.4. DHCP message header A common fixed DHCP message header has been defined. Not all fields are used in all messages. 23.5. Design goals The second sentence in the 8th design goal bullet has been removed. 23.6. Overview Section 8.2 (DHCP agents) has been removed. DHCP clients no longer need to know about specific DHCP agents. Section 8.3 has been modified to reflect the new encapsulating mechanism through which relays forward client messages to servers. Section 8.6 and 8.7 have been modified to describe ``identity associations''. Section 8.8 has been modified to reflect the deletion of ``reconfigure'' and ``reconfigure-reply'' messages. 23.7. Message formats, 9 Message formats have been changed. All messages share a common fixed message header followed by options. 23.8. Solicit and Advertise messages, (section 10) The description of the message exchanges have been changed to reflect: - New relay behavior - encapsulated client messages - Use of IAs 23.9. Prefix advertisement Servers no longer advertise prefixes. 23.10. Identity Associations Section 9.11 describes IAs in detail. A definition of ``IA'' has been added to section 2. The description of messages exchanges have been extended to include IAs. The IA option is defined in section 22.2 23.11. Extensions renamed options; defined in this document ``extensions'' are now called ``options''; the options referenced in this document are defined in section 22. 23.12. Transaction-ID ranges Solicit, Advertise, Request, Reply, Release and Reconfigure-init messages all use an unsigned 16-bit integer ``Transaction-ID''. Transaction-IDs generated by clients are considered to be chosen from a different namespace than those chosen by servers. There is no need to restrict clients and servers to select Transaction-IDs from specific ranges to avoid conflicts. 23.13. Release messages and relays Release/Reply messages are forwarded through relays. This mechanism eliminates the need for an 'R' bit. 23.14. Discovering relay agents Clients no longer learn the identity of relay agents. When the client only has a link-local address (e.g., the client has no assigned addresses), it now multicasts Request message, which is then forwarded by a relay agent on the same link. From owner-dhcp-v4@bucknell.edu Mon Nov 27 10:23:05 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA12050 for ; Mon, 27 Nov 2000 10:23:04 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id eARFHmO01165; Mon, 27 Nov 2000 10:17:48 -0500 (EST) Received: from firewall.ma.virata.com (agranat.com [198.113.147.2]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id eARFHiO02535 for ; Mon, 27 Nov 2000 10:17:45 -0500 (EST) Received: from ma.virata.com (alice.agranat.com [10.21.0.130]) by firewall.ma.virata.com (8.9.0/8.9.0) with ESMTP id KAA25164; Mon, 27 Nov 2000 10:17:28 -0500 Received: (from worley@localhost) by ma.virata.com (8.8.5/8.8.5) id KAA14736; Mon, 27 Nov 2000 10:17:28 -0500 Date: Mon, 27 Nov 2000 10:17:28 -0500 Message-Id: <200011271517.KAA14736@ma.virata.com> X-Authentication-Warning: alice.ma.virata.com: worley set sender to worley@alice.ma.virata.com using -f From: Dale Worley To: DHCPv4 discussion list CC: dhcp-v4@bucknell.edu In-reply-to: <8FA6CEF9A4E42B48A5F8DC038655B35320C2BC@mxtlv1.corrigent.com> (message from Ofer Dayan on Thu, 23 Nov 2000 13:48:29 +0200) Subject: Re: DHCP SW Package. References: <8FA6CEF9A4E42B48A5F8DC038655B35320C2BC@mxtlv1.corrigent.com> Reply-To: worley@agranat.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN From: Ofer Dayan I am looking for a DHCP 3rd party software package for embedded environment (VxWorks OS). Could anyone recommend on any specific vendor? Doesn't VxWorks have DHCP built in? Dale -- Dale R. WORLEY Project Manager - UPnP Virata Corp. Applications Infrastructure http://emweb.com From owner-dhcp-v6@bucknell.edu Tue Nov 28 10:42:11 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA26732; Tue, 28 Nov 2000 10:42:10 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id eASFanO26551; Tue, 28 Nov 2000 10:36:49 -0500 (EST) Received: from lespaul.process.com (lespaul.process.com [192.42.95.27]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id eASFaPO02974 for ; Tue, 28 Nov 2000 10:36:26 -0500 (EST) Received: by lespaul.process.com with Internet Mail Service (5.5.2650.21) id ; Tue, 28 Nov 2000 10:36:10 -0500 Message-ID: <63D30D6E10CFD11190A90000F805FE86036073D2@lespaul.process.com> From: Bernie Volz To: DHCPv6 discussion list Subject: RE: -16 rev of DHCPv6 spec Date: Tue, 28 Nov 2000 10:36:09 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Ralph and others ... here's some comments on the -16 spec. In general, this looks GREAT! Excellent job! Sorry that these comments are in no particular order. - In most of the message headers, there is the 16-byte client-link-local address. What about dropping the first 64-bits of this (the prefix)? It would save 8-bytes/packet. This is just a thought - there might be good reasons NOT to do this. But on the other hand, it would remove the need for servers/relays to validate that the prefix is the link local - instead, they pre-append the prefix when they need to use it as a link-local address. So, if we were to do this, we'd call this 64-bit field "interface ID" or something similar (at least based on RFC 2373 terminology). >From RFC 2373, it appears that link local doesn't really consume the full 64-bits before the interface-id, instead only the first 10 bits are really specified (with the next 54-bits being zero, though it is not clear that is REQUIRED). | 10 | | bits | 54 bits | 64 bits | +----------+-------------------------+----------------------------+ |1111111010| 0 | interface ID | +----------+-------------------------+----------------------------+ - Section 9.10 calls the message "Server-forward" message. Yet most of the text uses "Relay-reply". Please fix. Relay-reply is used almost exclusively in the rest of the text. - Section 22.2's diagram has a "pref. len". Yet this field is not defined anywhere in the list of fields. Was this an error in the diagram? Or was this to be the "prefix length"? If pref. len is prefix length, you might want to consider what to use as an abbreviation since then pref. could be "prefix" or "preferred" (as in preferred lifetime). Also, if this is "prefix length", then the format of address/prefix length is REVERSED from that used in the Relay-Forward/Server-Forward (see sections 9.9 and 9.10). Might be nice to have it consistent in always having prefix length/address (or address/prefix length). In RFC 2461, for prefix advertisements, the prefix appears before the address. - In section 23.7, the claim is made that "add messages share a comment fixed message header followed by options." This is not true (unless one assumes that the fixed message header is the 1-byte msg-type field). See Section 9.9 and 9.10 as they don't share the common message header. Might is be wise to consider changing the Relay-forward/Server-forward messages to use the common header? Though likely most of the fields would be 0's so it may be a waste. - In section 9.2 and 9.4, it might be best to move the "See sections 14.4 and 15.3 for information ..." under the "preference" definition text. Also, perhaps some indication that higher values indicate "more" preference to the server are worth nothing in these descriptions? - In section 9.5, there is a "P (unused) MUST be 0" in the definitions that doesn't belong. - In section 9.9, shouldn't there be some more details around the "relay-address"? This address must be carefully chosen by the relay to reflect the network on which the client is located. As most interfaces are bound to have many addresses, picking the proper address may be a bit involved. This will likely be a major issue for relays and the configuration of DHCP in IPv6 networks. For example, use of the relay's link-local address for the interface is no good. But, are locally scoped address potentially legal? Or must this be a fully routable (Internet-routable) address? - It is not clear why section 9.11 is where it is. Section 9 does say it is "Message Formats and Identity Associations" but I would think it best to put the Identity Association in a separate section. - In section 10.3.1, setting a transaction id is not specified. Implied action is to set it to 0 (The client sets all other fields to zero). - In section 10.3.3, there are several mentions of "advertising availability of IP address" ... how is this done (perhaps there will or is an option that will provide this information?). Also, if this capability DOES exist, isn't Ted's Discussion point in section 10.5.2 null and void? - Finally, there are a bunch of minor typos and like errors. But I've ignored those for now as I think most of those will get addressed in the -17 draft. If you want me to send my list sometime, let me know. And I still need to more carefully review section 11 to 17 and thus may have further comments. But, again, nice job and I think we're making excellent progress. - Bernie Volz Ericsson DNS & DHCP Development Unit From owner-dhcp-v6@bucknell.edu Tue Nov 28 12:18:24 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA06135; Tue, 28 Nov 2000 12:18:23 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id eASHF3O16561; Tue, 28 Nov 2000 12:15:03 -0500 (EST) Received: from lespaul.process.com (lespaul.process.com [192.42.95.27]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id eASHEoO28345 for ; Tue, 28 Nov 2000 12:14:50 -0500 (EST) Received: by lespaul.process.com with Internet Mail Service (5.5.2650.21) id ; Tue, 28 Nov 2000 12:14:34 -0500 Message-ID: <63D30D6E10CFD11190A90000F805FE86036073D6@lespaul.process.com> From: Bernie Volz To: DHCPv6 discussion list Subject: RE: -16 rev of DHCPv6 spec (Part 2) Date: Tue, 28 Nov 2000 12:14:34 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Ralph and others: Had some more time to finish the document review. Here's some additional comments: - In section 8.3, "Relays receive the Solicit and Request messages ...", they also receive Release messages (and perhaps others in the future). - In section 11.4.2, if the client fails to get a response from Request messages, should it fall back to the Solicit state or perhaps use any 'cached' information from previous Solicits to contact a lower preference server? I would think that the clients should not "stop" requesting addresses just because they can't contact a server. If an application requests an address, it should have a means to specify some timeout or other means to abort the request. If the client has just booted and is trying to get addresses, it should continue to try forever (perhaps backing off in how frequently it does Solicit / Request sequences). - In section 11.4.3, where is this 'status' field? Isn't this to be carried in an option? Also, if the request is successful, does a status need to be sent (if in an option)? Also, what's the impact if there are multiple IAs specified in the request and some are successful and others aren't (for whatever reason?)? - In section 11.4.4, what's the "(The client always forwards Release messages to the server through a relay; see section 11.5)" all about? 11.5 provides no useful information in this regard. Also, what if there is no relay? Also, should a client always use a link local address when sending a release? If so that should be stated (in that case a relay is required if the server is not on the link). - In section 11.4.5 and 11.4.6, it should state clearly that a client MUST stop using the addresses when sending a Release (whether or not a Reply is received). - In section 11.4.8, add 'send' ... "it may [send] a Request message". And, drop 'to' in "The server returns [to] IA(s)...". - In section 11.4.9, what if the 'old' server is not reachable (such as it was reached via a link-local address and you're now on a different link)? Or perhaps the server was a scoped address? Shouldn't there be some more thoughts about this? I think this needs some more consideration about what the best mechanism to determine what to do is. For example, if there are Router Advertisements, perhaps the client can determine whether its 'current' addresses are still valid and base a decision on that? If there are no Router Advertisements, perhaps the client should start at Solicit. If the same server responds, it can continue using it (regardless of the preference values)? Microsoft's Windows 2000 client uses the router address - it 'pings' the router address (with a hop limit of 1 I suspect) and if it gets a response, it assumes it is still on the same subnet. This is a nice approach and generally works very well. - In section 11.4.10, add 'may' ... "The server [may] remove addresses from the IA ...". Also, "If the server does not assign an explicit value to T1 or T2 ...". How is that done? The option has fixed fields for T1 and T2. Perhaps you're allowing these to have some magic value (such as 0 or all bits 1?)? If so, that isn't mentioned in the option text (section 22.2). - In section 11.5.1, some thought might be needed regarding the address issue (see previous set of comments). For example, depending on the server the request is forwarded to, the relay-address / prefix length might need to be different. So, the text is probably a bit too simplistic. Again, we should discuss this issue. - In section 11.6.3, again the 'status' field is discussed. Where is it in the message? An option? Also, the forward (relay) message names here don't match other sections. - In section 12, I think you should be staying if new prefixes are added to a link. As you indicating, adding new links is meaningless (if a client gets a new link, it would need to start IPv6 on that link and hence would do DHCP if so specified). The issue for servers and Reconfigures is if new prefixes are added (or old ones removed or depreciated). - In section 12.4.4, some text should be added about having the server 'pace' unicast Reconfigure-Init messages. If there are 100's of clients on a link, the server should send the 100's of reconfigure-init messages 'slowly' (perhaps 10/second or some such number). Also, using the transaction-id from the Reconfigure-Init message in Request messages can cause problems (collisions) with client generated values. While you might argue that it doesn't matter, it may in some instances and therefore we should be careful about this. One solution might be to have a 'Reconfigure-Init Transaction ID' option to carry that transaction ID and thus the number space between client and server don't collide. Also, this aids the server in understanding that this Request was generated by a 'Reconfigure-Init'. - In section 12.4.5, what about Multicast implications? If the Reconfigure-Init is multicast, should a server retransmit it? If so, clients might need to remember recent Reconfigure-Init transaction ids so they know if they've received a duplicate? Or is the server restricted to ONE multicast message and then needs to switch to unicast? This also applies to section 12.5.1 - check for duplicates? - In section 12.5.2, does the client need to pause under all cases before sending the Request? Or just if multicast received. - In section 12.5.4, isn't this just the usual Reply processing? - In section 14.2, more details on what is and is not cachable should be added. - In section 14.3, I see there being 3 sources of values: - Defaults (per RFC) - Server (per option) - Client configuration How do these interact? Which as priority over the other. I think it is clear that the Defaults are lowest on the food chain. But, should a client's configuration prevent using server supplied values? Perhaps this is a client policy issue? - In section 14, would an additional section on how to generate IAs be useful? We had long discussions about this on the mailing list and there really isn't much said about this in the specification. - In section 15, would an additional section on how to assign addresses be appropriate? I'm not saying we should force servers to adhere to a convention, but what about providing some guidelines? Are servers supposed to use the EUI-64 identifier or not when generating addresses? ... - In sectin 17.4, what about considering an option to carry this information? That way, servers MAY use it to change their behavoir but they need not rely on it. Clients MAY supply it if they want servers to consider this? I'm happy if the discussion decides that this is a REQUIRED piece of information (but then I'd still put it in an option). Thats it for now. - Bernie Volz Ericsson DNS & DHCP Development Unit From owner-dhcp-v6@bucknell.edu Tue Nov 28 13:16:42 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA24743; Tue, 28 Nov 2000 13:16:41 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id eASIDjO23752; Tue, 28 Nov 2000 13:13:45 -0500 (EST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id eASIDTO18046 for ; Tue, 28 Nov 2000 13:13:29 -0500 (EST) Received: from sunmail1.Sun.COM ([129.145.1.2]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA11285 for ; Tue, 28 Nov 2000 10:13:24 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.89.31]) by sunmail1.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6.1-sunmail1) with ESMTP id KAA23660 for ; Tue, 28 Nov 2000 10:13:20 -0800 (PST) Received: from lillen (lillen.Eng.Sun.COM [129.146.86.161]) by jurassic.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) with SMTP id eASIDKj836304 for ; Tue, 28 Nov 2000 10:13:20 -0800 (PST) Date: Tue, 28 Nov 2000 10:12:55 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: -16 rev of DHCPv6 spec; design team teleconference To: DHCPv6 discussion list In-Reply-To: "Your message with ID" <4.3.1.2.20001122120109.00bcd520@funnel.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Ralph, I hope I can attend the telecon. Can you send me the phone number etc. Thanks, Erik From owner-dhcp-v4@bucknell.edu Wed Nov 29 06:32:51 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA02775 for ; Wed, 29 Nov 2000 06:32:50 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id eATBRlO16231; Wed, 29 Nov 2000 06:27:47 -0500 (EST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id eATBRUO12516 for ; Wed, 29 Nov 2000 06:27:30 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29584; Wed, 29 Nov 2000 06:27:19 -0500 (EST) Message-Id: <200011291127.GAA29584@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: DHCPv4 discussion list Cc: dhcp-v4@bucknell.edu From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dhc-failover-08.txt Date: Wed, 29 Nov 2000 06:27:19 -0500 Sender: owner-dhcp-v4@bucknell.edu X-Sender: nsyracus@cnri.reston.va.us X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN --NextPart A New 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 : DHCP Failover Protocol Author(s) : R. Droms, K. Kinnear, M. Stapp, B. Volz, S. Gonczi, G. Rabil, M. Dooley, A. Kapur Filename : draft-ietf-dhc-failover-08.txt Pages : 126 Date : 28-Nov-00 DHCP [RFC 2131] allows for multiple servers to be operating on a single network. Some sites are interested in running multiple servers in such a way so as to provide redundancy in case of server failure. In order for this to work reliably, the cooperating primary and secondary servers must maintain a consistent database of the lease information. This implies that servers will need to coordinate any and all lease activity so that this information is synchronized in case of failover. This document defines a protocol to provide such synchronization between two servers. One server is designated the 'primary' server, the other is the 'secondary' server. This document also describes a way to integrate the failover protocol with the DHCP load balancing approach. This document is a substantial reorganization as well as a technical and editorial revision of draft-ietf-dhc-failover-05.txt. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-failover-08.txt Internet-Drafts are also 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-failover-08.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dhc-failover-08.txt". NOTE: The mail server at ietf.org 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. 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@ietf.org" Content-Type: text/plain Content-ID: <20001128133543.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-failover-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-failover-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001128133543.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-dhcp-v4@bucknell.edu Wed Nov 29 19:53:50 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA24208 for ; Wed, 29 Nov 2000 19:53:49 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id eAU0mtO24804; Wed, 29 Nov 2000 19:48:55 -0500 (EST) Received: from mail-out2.apple.com (mail-out2.apple.com [17.254.0.51]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id eAU0mpO05433 for ; Wed, 29 Nov 2000 19:48:51 -0500 (EST) Received: from mailgate2.apple.com (A17-129-100-225.apple.com [17.129.100.225]) by mail-out2.apple.com (8.9.3/8.9.3) with ESMTP id QAA21409 for ; Wed, 29 Nov 2000 16:48:50 -0800 (PST) Received: from scv3.apple.com (scv3.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.1.2) with ESMTP id for ; Wed, 29 Nov 2000 16:48:50 -0800 Received: from [17.201.23.37] (chesh1.apple.com [17.201.23.37]) by scv3.apple.com (8.9.3/8.9.3) with SMTP id QAA22037 for ; Wed, 29 Nov 2000 16:48:46 -0800 (PST) Message-Id: <200011300048.QAA22037@scv3.apple.com> Subject: Comments on draft-ietf-dhc-csr-03.txt Date: Wed, 29 Nov 2000 16:48:47 -0800 x-sender: cheshire@mail.apple.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Stuart Cheshire To: DHCPv4 discussion list Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Reply-To: cheshire@apple.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN > When an IP host (the source host) wishes to transmit a > packet to another IP host (the destination), it first checks the IP > address of the destination host to see if it is on a subnet to > which the source host is connected. If the destination host's IP > address is not on a subnet to which the source host is connected, > then the source host consults its routing table to determine the IP > address of the router that should be used to forward the packet to > the destination host. This is a minor detail, but this is not true on many systems, such as Linux, for example. Linux simply consults the routing table, and the kernel obeys the instructions there about whether to send the packet directly on an attached link or via a gateway. For example, here's the routing table from my Linux machine: >[cheshire@chesh2 cheshire]$ route >Kernel IP routing table >Destination Gateway Genmask Flags Metric Ref Use Iface >17.201.20.0 * 255.255.252.0 U 0 0 0 eth0 >127.0.0.0 * 255.0.0.0 U 0 0 0 lo >default nathanf2 0.0.0.0 UG 0 0 0 eth0 The reason that it sends packets directly to hosts on 17.201.20/22 is because the routing table tells it to, not because it "first checks the IP address of the destination host to see if it is on a subnet to which the source host is connected." I could quite easily change the routing table to tell the kernel to do something different if I wanted, and it would obey those instructions. Sometimes for debugging it can be useful to send packets via some gateway machine, even when the destination is on the same Ethernet. I suggest we just delete that paragraph, since it is purely explanatory background material, and not central to explaining the DHCP CSR option. ----- > The Static Routes option does not provide a subnet mask for each To avoid reader confusion, why not say "The old Static Routes option" or "The original Static Routes option" to make it totally clear that this is describing the flaw in the old option. ----- > DHCP clients that support ARPing > as described here MUST ignore the Router option (option code 3) if > the Router option contains the client's own IP address. > If the DHCP server returns a Router option, clients that support > the Classless Static Routes option MUST use the default route(s) > listed in the Router option in addition to the routes listed > in the Classless Static Routes option. These two statements (from different parts of the draft) seem contradictory. If the DHCP server returns a Router option, the client MUST use it, unless it is the magic "enable all-ARP mode" address, in which case the client MUST NOT use it. If that's what we mean, perhaps we should say so explicitly in a single sentence. What if the address in the Router option is 0.0.0.0? That's a synonym for the client's own IP address, right, and also enables "all-ARP mode". Should the client ignore that as well? This case of sometimes you use the option and sometimes you don't seems potentially confusing. Might it be simpler to say that the CSR option completely replaces BOTH the old Static Route Option and the old Router option? If you use CSR, then you use it for all routes, including the default one. We could then change the following text: > DHCP > clients that support this option MUST NOT install the routes > specified in the Static Routes option (option code 33) if both a > Static Routes option and the Classless Static Routes option are > provided. > > DHCP clients that support this option and that send a DHCP > Parameter Request List option MUST request both this option and the > Router option [2] in the DHCP Parameter Request List. DHCP clients > that support this option and send a parameter request list MUST NOT > request the Static Routes option. > > If the DHCP server returns a Router option, clients that support > the Classless Static Routes option MUST use the default route(s) > listed in the Router option in addition to the routes listed > in the Classless Static Routes option. To: > If the Classless Static Routes option is provided, DHCP clients > that support this option MUST ignore all Static Routes options > (option code 33) and Router options (option code 3), if any, > appearing in the packet. > > DHCP clients that support this option and that send a DHCP > Parameter Request List option MUST request this option and > MUST NOT request the Router option or the Static Routes option. A DHCP server administrator who has to support both old and new clients can then simply use the Router and Static Routes options to configure the old clients, and the CSR option to configure the new clients, and there's no confusing overlap between the two. Stuart Cheshire * Wizard Without Portfolio, Apple Computer * Chairman, IETF ZEROCONF * www.stuartcheshire.org From owner-dhcp-v4@bucknell.edu Thu Nov 30 05:56:25 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA27562 for ; Thu, 30 Nov 2000 05:56:24 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id eAUApsO08235; Thu, 30 Nov 2000 05:51:54 -0500 (EST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id eAUApmO26864 for ; Thu, 30 Nov 2000 05:51:48 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25373; Thu, 30 Nov 2000 05:51:45 -0500 (EST) Message-Id: <200011301051.FAA25373@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: DHCPv4 discussion list Cc: dhcp-v4@bucknell.edu From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dhc-dhcpv6-16.txt Date: Thu, 30 Nov 2000 05:51:44 -0500 Sender: owner-dhcp-v4@bucknell.edu X-Sender: nsyracus@cnri.reston.va.us X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN --NextPart A New 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 (DHCPv6) Author(s) : J. Bound, M. Carney, C. Perkins, R. Droms Filename : draft-ietf-dhc-dhcpv6-16.txt Pages : 54 Date : 29-Nov-00 The Dynamic Host Configuration Protocol for IPv6 (DHCP) enables DHCP servers to pass configuration parameters such as IPv6 network addresses to IPv6 nodes. It offers the capability of automatic allocation of reusable network addresses and additional configuration flexibility. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-16.txt Internet-Drafts are also 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-16.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dhc-dhcpv6-16.txt". NOTE: The mail server at ietf.org 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. 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@ietf.org" Content-Type: text/plain Content-ID: <20001129114004.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-dhcpv6-16.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-dhcpv6-16.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001129114004.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-dhcp-v4@bucknell.edu Thu Nov 30 05:56:57 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA27835 for ; Thu, 30 Nov 2000 05:56:57 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id eAUArHO03937; Thu, 30 Nov 2000 05:53:18 -0500 (EST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id eAUAprO20230 for ; Thu, 30 Nov 2000 05:51:53 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25426; Thu, 30 Nov 2000 05:51:51 -0500 (EST) Message-Id: <200011301051.FAA25426@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: DHCPv4 discussion list Cc: dhcp-v4@bucknell.edu From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dhc-csr-03.txt Date: Thu, 30 Nov 2000 05:51:50 -0500 Sender: owner-dhcp-v4@bucknell.edu X-Sender: nsyracus@cnri.reston.va.us X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN --NextPart A New 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 : The Classless Static Route Option for DHCP Author(s) : T. Lemon Filename : draft-ietf-dhc-csr-03.txt Pages : Date : 29-Nov-00 This document defines a new DHCP option which is passed from the DHCP Server to the DHCP Client to configure a list of static routes in the client. This option supersedes the Static Route option (option 33) defined in [2]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-csr-03.txt Internet-Drafts are also 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-csr-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dhc-csr-03.txt". NOTE: The mail server at ietf.org 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. 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@ietf.org" Content-Type: text/plain Content-ID: <20001129114014.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-csr-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-csr-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001129114014.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-dhcp-v4@bucknell.edu Thu Nov 30 13:12:31 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA06076 for ; Thu, 30 Nov 2000 13:12:31 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id eAUI7EO20463; Thu, 30 Nov 2000 13:07:14 -0500 (EST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id eAUI7AO07204 for ; Thu, 30 Nov 2000 13:07:10 -0500 (EST) Received: from rdroms-nt.cisco.com (ch2-dhcp133-146.cisco.com [161.44.133.146]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id NAA20696; Thu, 30 Nov 2000 13:06:54 -0500 (EST) Message-Id: <4.3.1.2.20001130130213.00c3f100@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Thu, 30 Nov 2000 13:03:39 -0500 To: DHCPv4 discussion list From: Ralph Droms Subject: IPSRA WG LAST CALL: draft-ietf-ipsec-dhcp-08.txt Cc: Paul Hoffman / VPNC Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Reply-To: rdroms@cisco.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN (Forwarded for Paul Hoffman. - RD) Greetings, DHCP folks. The IPSRA WG has begun its WG last call on draft-ietf-ipsec-dhcp-08.txt. Instead of running the discussion on two lists, I would invite any of you with comments to subscribe and post comments on this draft to the IPSRA mailing list. Please see for information on the WG and mailing list. --Paul Hoffman, Director --VPN Consortium From owner-dhcp-v4@bucknell.edu Thu Nov 30 15:22:09 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA00701 for ; Thu, 30 Nov 2000 15:22:09 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id eAUKH8O15271; Thu, 30 Nov 2000 15:17:08 -0500 (EST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id eAUKGqO16589; Thu, 30 Nov 2000 15:16:52 -0500 (EST) Received: from rdroms-nt.cisco.com (ch2-dhcp133-146.cisco.com [161.44.133.146]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id PAA09518; Thu, 30 Nov 2000 15:16:36 -0500 (EST) Message-Id: <4.3.1.2.20001130150914.00b0c3a0@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Thu, 30 Nov 2000 15:10:27 -0500 To: DHCPv4 discussion list From: Ralph Droms Subject: DHC WG meetings in San Diego Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Reply-To: rdroms@cisco.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Information about the DHC WG meetings in San Diego is now available at http://www.dhcp.org/0012-meeting.html If you would like to be added to the agenda, please send me a request for time as soon as possible. - Ralph From owner-dhcp-v6@bucknell.edu Thu Nov 30 15:22:10 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA00700; Thu, 30 Nov 2000 15:22:09 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id eAUKH8O11527; Thu, 30 Nov 2000 15:17:09 -0500 (EST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id eAUKGqO16589; Thu, 30 Nov 2000 15:16:52 -0500 (EST) Received: from rdroms-nt.cisco.com (ch2-dhcp133-146.cisco.com [161.44.133.146]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id PAA09518; Thu, 30 Nov 2000 15:16:36 -0500 (EST) Message-Id: <4.3.1.2.20001130150914.00b0c3a0@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Thu, 30 Nov 2000 15:10:27 -0500 To: DHCPv6 discussion list From: Ralph Droms Subject: DHC WG meetings in San Diego Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Information about the DHC WG meetings in San Diego is now available at http://www.dhcp.org/0012-meeting.html If you would like to be added to the agenda, please send me a request for time as soon as possible. - Ralph