From owner-dhcp-v4@bucknell.edu Tue Aug 1 11:36:43 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12156 for ; Tue, 1 Aug 2000 11:36:43 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e71FWWi06901; Tue, 1 Aug 2000 11:32:32 -0400 (EDT) Received: from lukla.Sun.COM (lukla.Sun.COM [192.18.98.31]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e71FWKi11675 for ; Tue, 1 Aug 2000 11:32:20 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA22674 for ; Tue, 1 Aug 2000 09:32:18 -0600 (MDT) From: Vipul.Gupta@eng.sun.com Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id IAA02443 for ; Tue, 1 Aug 2000 08:25:16 -0700 (PDT) Received: from rambo (rambo [129.146.122.232]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with ESMTP id IAA21852; Tue, 1 Aug 2000 08:25:15 -0700 (PDT) Date: Tue, 1 Aug 2000 08:25:15 -0700 (PDT) Message-ID: <530959210.965143515899.JavaMail.root@rambo> To: DHCPv4 discussion list Subject: Public Key auth for DHCP Cc: Vipul.Gupta@eng.sun.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Reply-To: Vipul.Gupta@eng.sun.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit There has been some discussion recently on public-key authentication for DHCP. I have a draft already which (unfortunately) expired recently. I can reissue it after I get back from the IETF. vipul p.s. the draft is draft-gupta-dhcp-auth-02.txt and was presented in Oslo. I'll mail a pointer to it later today. From owner-dhcp-v6@bucknell.edu Tue Aug 1 18:02:25 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14838 for ; Tue, 1 Aug 2000 18:02:25 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e71Lvhi09010; Tue, 1 Aug 2000 17:57:43 -0400 (EDT) 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 e71Lvai10166 for ; Tue, 1 Aug 2000 17:57:36 -0400 (EDT) Received: from sunmail1.Sun.COM ([129.145.1.2]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA22883 for ; Tue, 1 Aug 2000 14:57:34 -0700 (PDT) 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 OAA08565 for ; Tue, 1 Aug 2000 14:57:31 -0700 (PDT) Received: from jurassic.Eng.Sun.COM (esun1as-be.Central.Sun.COM [129.147.34.142]) by jurassic.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e71LvQ8437447 for ; Tue, 1 Aug 2000 14:57:27 -0700 (PDT) From: Erik Nordmark Message-Id: <200008012157.e71LvQ8437447@jurassic.eng.sun.com> Date: Tue, 1 Aug 2000 14:57:25 -0700 To: DHCPv6 discussion list Subject: DHCPv6 comment - X-address in release X-Mailer: Sun NetMail 2.3 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit 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 Content-Transfer-Encoding: 7bit The release message has an R flag to indicate whether the X-address is the address of the relay or of the client. I don't think the R bit is needed. The request message can do without one and I don't see why the release message needs to be different. If I'm correct then the X-address field can be renamed to relay-address with the same semantics as in the request message. This points to something that could be clarified in the spec: In some cases the protocol uses the addresses in the IPv6 header, for instance a request message not sent through a relay. It would be useful to make it clear in the draft to specify the addresses that go in the IPv6 header. For example, RFC 2461 contains such information. Erik From owner-dhcp-v6@bucknell.edu Wed Aug 2 09:12:42 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05256 for ; Wed, 2 Aug 2000 09:12:41 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e72D8Yi20349; Wed, 2 Aug 2000 09:08:34 -0400 (EDT) Received: from ztxmail02.ztx.compaq.com (ztxmail02.ztx.compaq.com [161.114.1.206]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e72D8Li00057 for ; Wed, 2 Aug 2000 09:08:21 -0400 (EDT) Received: by ztxmail02.ztx.compaq.com (Postfix, from userid 12345) id A745C3840; Wed, 2 Aug 2000 08:08:05 -0500 (CDT) Received: from anw.zk3.dec.com (alpha.zk3.dec.com [16.140.128.4]) by ztxmail02.ztx.compaq.com (Postfix) with ESMTP id 630AE3B15 for ; Wed, 2 Aug 2000 08:08:05 -0500 (CDT) Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM) id JAA0001461501; Wed, 2 Aug 2000 09:07:21 -0400 (EDT) From: Jim Bound Message-Id: <200008021307.JAA0001461501@anw.zk3.dec.com> To: DHCPv6 discussion list Subject: DSTM : IPv6 Dual Stack Transition Method Date: Wed, 02 Aug 2000 09:07:20 -0400 X-Mts: smtp 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 Folks, see: http://ietf.org/internet-drafts/draft-ietf-ngtrans-dstm-02.txt This will be discussed at the NGTRANS meeting this p.m. The above defines a new DHCPv6 extension to support when the mechanism provides clients IPv4-Mapped addresses in a deployed IPv6 network. regards, /jim From owner-dhcp-v6@bucknell.edu Wed Aug 2 09:45:06 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16525 for ; Wed, 2 Aug 2000 09:45:06 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e72Dgdi20718; Wed, 2 Aug 2000 09:42:39 -0400 (EDT) Received: from zmamail02.zma.compaq.com (zmamail02.zma.compaq.com [161.114.64.102]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e72DgOi08584 for ; Wed, 2 Aug 2000 09:42:24 -0400 (EDT) Received: by zmamail02.zma.compaq.com (Postfix, from userid 12345) id 70CA9926; Wed, 2 Aug 2000 09:42:09 -0400 (EDT) Received: from anw.zk3.dec.com (alpha.zk3.dec.com [16.140.128.4]) by zmamail02.zma.compaq.com (Postfix) with ESMTP id 3FF4916F2 for ; Wed, 2 Aug 2000 09:42:09 -0400 (EDT) Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM) id JAA0001465507; Wed, 2 Aug 2000 09:42:08 -0400 (EDT) From: Jim Bound Message-Id: <200008021342.JAA0001465507@anw.zk3.dec.com> To: DHCPv6 discussion list Subject: Results in my mind of DHCPv6 Meeting Date: Wed, 02 Aug 2000 09:42:08 -0400 X-Mts: smtp 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 Hi Folks, Well this was an eye opening meeting. This is my view of the key issues. The authors also had another eye opening meeting with the Chair and others after the dhc6 WG meeting. #1 DHCPv6 is a market requirement and we need to get a WG cosensus spec done quickly that can be implemented quickly. At the meeting I stated that we did not have to worry about catching the next train to ship DHCPv6. I WAS WRONG. After speaking with several WG members and listening, and connecting with several customer type IPv6 test beds the WG needs to get this spec done A.S.A.P. and reach consensus. #2 The WG does not have consensus that the more complicated parts of DHCPv6 which are different than the DHCPv4 model is a good architecture idea. It may be possible to reach consensus locating these parts (to be defined in other mail later) and take them out of the initial draft for consensus to get an implementable spec for the market A.S.A.P. #3 Stream-line DHCPv6 or develop a competing proposal. I think fine tuning the current spec working with members of the WG who have volunteered to help unofficially (to be worked and provided by the Chair later) is the best approach to achieve dhcpv6 consensus and get a spec all implementors will write code to is the optimal approach to meet the IPv6 market needs. #4 An integration of the DHCPv4 learnings within DHCPv6. What we have done here was not enough for some WG members and that was good input. Mike Carney had sent mail before the previous draft of what we felt dhcpv4 did good and what dhcpv4 does the market would like done better. Then contrasted dhcpv6 with dhcpv4 and suggested some resolution. I think Mike should resend that mail and we can expand or detract and use as input to the WG to begin that discussion again. The Chair is going to set up an interim WG meeting A.S.A.P. My hope is we can address these key issues as a team and get the IPv6 market a spec we can all implement quickly and move onto standards track and permit future extensibility we can work on together to evolve dhcpv6. My input to you is we need to make sure dhcpv6 can be extended from the core protocol I believe we can develop quickly. I will have a dhcpv6 state diagram for the WG in about 2 weeks and will provide some IPv6 input to you all for the discussion. THis is not now for the draft but for discussion with the WG. regards, /jim From owner-dhcp-v4@bucknell.edu Wed Aug 2 12:54:31 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22551 for ; Wed, 2 Aug 2000 12:54:31 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e72Gp9i22208; Wed, 2 Aug 2000 12:51:10 -0400 (EDT) Received: from lukla.Sun.COM (lukla.Sun.COM [192.18.98.31]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e72Gosi16632 for ; Wed, 2 Aug 2000 12:50:54 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA06038 for ; Wed, 2 Aug 2000 10:50:51 -0600 (MDT) From: Vipul.Gupta@Eng.Sun.COM Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id JAA17144 for ; Wed, 2 Aug 2000 09:50:50 -0700 (PDT) Received: from rambo (rambo [129.146.122.232]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with ESMTP id JAA14190; Wed, 2 Aug 2000 09:50:48 -0700 (PDT) Date: Wed, 2 Aug 2000 09:50:48 -0700 (PDT) Message-ID: <530942745.965235049743.JavaMail.root@rambo> To: DHCPv4 discussion list Subject: Public-key auth draft Cc: Vipul.Gupta@Eng.Sun.COM Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Reply-To: Vipul.Gupta@Eng.Sun.COM Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit A copy of the (now expired) draft describing public-key authentication for DHCP is available at http://playground.sun.com/~vgupta/docs.html I'll resubmit this draft after consulting with the WG chair. thanks, vipul From owner-dhcp-v4@bucknell.edu Wed Aug 2 13:19:23 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01129 for ; Wed, 2 Aug 2000 13:19:23 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e72HIRi30122; Wed, 2 Aug 2000 13:18:27 -0400 (EDT) Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e72HIIi06559 for ; Wed, 2 Aug 2000 13:18:18 -0400 (EDT) Received: from 157.54.9.100 by mail3.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 02 Aug 2000 10:16:43 -0700 (Pacific Daylight Time) Received: by INET-IMC-03 with Internet Mail Service (5.5.2651.58) id ; Wed, 2 Aug 2000 10:17:07 -0700 Message-ID: From: Matthew Williamson To: DHCPv4 discussion list Subject: Question: draft-ietf-dhc-csr-02.txt Date: Wed, 2 Aug 2000 10:16:06 -0700 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, I was wondering why there isn't a provision for metrics in draft-ietf-dhc-csr-02.txt, or if anyone's discussed adding them? thanks, Matthew -----Original Message----- From: Vipul.Gupta@Eng.Sun.COM [mailto:Vipul.Gupta@Eng.Sun.COM] Sent: Wednesday, August 02, 2000 9:51 AM To: DHCPv4 discussion list Cc: Vipul.Gupta@Eng.Sun.COM Subject: Public-key auth draft A copy of the (now expired) draft describing public-key authentication for DHCP is available at http://playground.sun.com/~vgupta/docs.html I'll resubmit this draft after consulting with the WG chair. thanks, vipul From owner-dhcp-v4@bucknell.edu Wed Aug 2 13:46:08 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09730 for ; Wed, 2 Aug 2000 13:46:08 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e72HhJi32711; Wed, 2 Aug 2000 13:43:19 -0400 (EDT) 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 e72HhBi01041 for ; Wed, 2 Aug 2000 13:43:12 -0400 (EDT) Received: by lespaul.process.com with Internet Mail Service (5.5.2650.21) id ; Wed, 2 Aug 2000 13:42:55 -0400 Message-ID: <63D30D6E10CFD11190A90000F805FE8602BEBFC6@lespaul.process.com> From: Bernie Volz To: DHCPv4 discussion list Cc: DHCPv4 discussion list Subject: RE: Question: draft-ietf-dhc-csr-02.txt Date: Wed, 2 Aug 2000 13:42:54 -0400 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 Interesting idea but the question is what metrics did you want? Just a hop count type metric (such as used by Windows ROUTE ADD?). Ted ... what about considering this. One byte would be sufficient (per route). It does make the option data longer and also means that the DHCP Server would have to have this (static) information configured for the option. I'm neutral on this as I believe these routes are static and there is likely to be one route per 'destination'. And, active routing protocols are of more use to convey this type of information (such as RIP listeners). But, it is just as easy to always specify a value of 1 for these. If we're really keen on conserving bits in this option (and want to add this), one idea might be to use some of the subnet length bits for this. Since the subnet length requires 5 bits (0..31), we could use the remaining 3 bits to specify the metric. This would give a metric from 0 to 7 (or 1 to 8). This should be sufficient for most cases. This encoding would make it painful for people entering the data to the servers, but does compress the data. I'm not really in favor of this approach, but suggest it for those that feel this is important to add and want to keep the length of the option down. On the plus side, those that don't care about the metric simply specify the subnet mask and a 0 metric is mapped to 1 when the route is added. Note: As a side issue [on the issue of using a router address of 0.0.0.0 to mean "link-local" address], we could use a bit in the subnet length field to indicate whether the router address is present or not. If not present, this would mean it is on the interface being configured and hence you'd avoid having to send the router address (as 0.0.0.0). Of course, this would not be good if we encoded the metric in these bits since two bits for a metric is likely not enough. - Bernie Volz -----Original Message----- From: Matthew Williamson [mailto:mattwi@microsoft.com] Sent: Wednesday, August 02, 2000 1:16 PM To: DHCPv4 discussion list Subject: Question: draft-ietf-dhc-csr-02.txt Hello, I was wondering why there isn't a provision for metrics in draft-ietf-dhc-csr-02.txt, or if anyone's discussed adding them? thanks, Matthew -----Original Message----- From: Vipul.Gupta@Eng.Sun.COM [mailto:Vipul.Gupta@Eng.Sun.COM] Sent: Wednesday, August 02, 2000 9:51 AM To: DHCPv4 discussion list Cc: Vipul.Gupta@Eng.Sun.COM Subject: Public-key auth draft A copy of the (now expired) draft describing public-key authentication for DHCP is available at http://playground.sun.com/~vgupta/docs.html I'll resubmit this draft after consulting with the WG chair. thanks, vipul From owner-dhcp-v4@bucknell.edu Fri Aug 4 15:09:53 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29614 for ; Fri, 4 Aug 2000 15:09:53 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e74J5gi01336; Fri, 4 Aug 2000 15:05:42 -0400 (EDT) Received: from lukla.Sun.COM (lukla.Sun.COM [192.18.98.31]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e74J5Ri06165 for ; Fri, 4 Aug 2000 15:05:27 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA23916; Fri, 4 Aug 2000 13:05:24 -0600 (MDT) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id MAA06843; Fri, 4 Aug 2000 12:04:34 -0700 (PDT) Received: from nobel (nobel [129.146.122.141]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id MAA19876; Fri, 4 Aug 2000 12:04:33 -0700 (PDT) Message-Id: <200008041904.MAA19876@nasnfs.eng.sun.com> Date: Fri, 4 Aug 2000 11:53:22 -0700 (PDT) From: Vipul Gupta Reply-To: Vipul Gupta Subject: Re: Public-key auth draft To: DHCPv4 discussion list Cc: dhcp-v4@bucknell.edu MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: NiB929nCzDJJ7UOI6vT0uQ== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4_28 SunOS 5.8 sun4u sparc Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN I am entirely to blame for letting this draft expire. After its presentation in Oslo there was enough interest to make it a working group document. I even exchanged some email with the WG chair seeking his input on the changes required for that transition. Unfortunately, soon after that, I got tied up with another project at work and let the draft submission deadlines slip. I should have more time now to work on this draft and incorporate WG feedback. As for the dependance on the continuation code, subsequent posts on the mailing list indicated that the existing spec allows for options to be longer than 255 bytes by including the same option code multiple times (whether or not existing implementations do what the spec says, I don't know) thanks, vipul > From: Richard Johnson > MIME-Version: 1.0 > Content-Transfer-Encoding: 7bit > Date: Wed, 2 Aug 2000 15:39:36 -0700 (PDT) > To: Vipul.Gupta@eng.sun.com > Subject: Re: Public-key auth draft > > Vipul.Gupta@ENG.SUN.COM writes: > > > > A copy of the (now expired) draft describing > > public-key authentication for DHCP is > > available at > > > > http://playground.sun.com/~vgupta/docs.html > > > > I'll resubmit this draft after consulting > > with the WG chair. > > Thanks. By the way, why did this expire? Was it apathy or maybe the > dependance on the DHCP Continuation code made it just too complex of > an issue? Maybe people weren't convinced it was needed? > > Maybe it's *not* needed. I just got to thinking recently about what > has happened at a few IETFs already when someone accidently (or not) > runs a DHCP server on the net. It just seems that public key > authentication of the DHCP server would squash this problem in no > time. Especially if the server always uses the same key so it's > completely predictable as what it will be. > > /raj From owner-dhcp-v6@bucknell.edu Sat Aug 5 02:47:04 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA03796 for ; Sat, 5 Aug 2000 02:47:04 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e756iEi12478; Sat, 5 Aug 2000 02:44:14 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e756i2i17646 for ; Sat, 5 Aug 2000 02:44:03 -0400 (EDT) Received: from grosse.bisbee.fugue.com (user-2ivebi7.dialup.mindspring.com [165.247.46.71]) by toccata.fugue.com (8.9.3/8.6.11) with ESMTP id FAA16182 for ; Fri, 4 Aug 2000 05:50:59 -0700 (PDT) Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.9.3+3.2W/8.6.11) with ESMTP id CAA00983 for ; Sat, 5 Aug 2000 02:42:23 -0400 (EDT) Message-Id: <200008050642.CAA00983@grosse.bisbee.fugue.com> To: DHCPv6 discussion list Subject: Announcing DHCPv6 interim meeting in August Date: Sat, 05 Aug 2000 02:42:23 -0400 From: Ted Lemon 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 [Sorry this took so long - I had a little run-in with listproc...] During the WG meeting on DHCPv6 in Pittsburgh, several things became clear: (1) We need DHCPv6 ASAP - within the next six months, at the latest. (2) We do not have consensus now, and we aren't going to get it without some major changes. After the WG meeting, some of us stuck around (all WG meeting participants were invited) and talked about how to proceed. We did our best not to talk about substantive protocol issues, but rather about how to get from where we are now to having a proposed standard in six months. What I proposed, and what the people in the group agreed to, is that we can't waste time with competing proposals - we need to figure out how to take the existing draft and make it something that people will want to implement, and will agree to in the WG. The way we are going to accomplish this is as follows: (1) Everybody who is strongly interested is going to read the current draft over carefully, if they haven't already, or if only as a means of accomplishing (2): (2) Each of us is going to make a list of the things that are in the draft that aren't okay with us, and a list of things that are not in the draft that we would like to see in the draft. (3) We will each publish this information on the DHCPv6 mailing list. (4) About two or three weeks from now (Ralph will announce the date and location - we are tentatively shooting for August 22nd), we are going to have a teleconference. We are going to go into the teleconference prepared to compromise. We are going to walk out of the conference _with_ a compromise. Any IETF member is invited to participate, but we need to be very clear about this: you *must* do your homework. I say this as someone who is as guilty as the rest, but we can't afford to have hypothetical discussions here - this is the real deal. If you have ideas that can go in later drafts, please figure out how to make sure that the current draft doesn't preclude them, and be prepared to spend minimal time talking about them. Please be prepared for the possibility that you will not walk out of the meeting with everything you want, and decide up front in a very serious way which things you really, really need, and which things would just be kind of nice. I am directing this not only at the authors of the draft, but those who have not been directly involved in authoring the draft, but have strong ideas about it, which includes me. You have my promise that I will hold myself to this. The only things that I consider non-negotiable going into this discussion are: (1) We will have a draft that's ready to go to PS by the next IETF. (2) It will be something that people will be willing to implement. (3) It will work. Thanks! _MelloN_ From owner-dhcp-v4@bucknell.edu Sat Aug 5 21:35:36 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA00389 for ; Sat, 5 Aug 2000 21:35:36 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e761Wii06611; Sat, 5 Aug 2000 21:32:44 -0400 (EDT) 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 e761WXi28651; Sat, 5 Aug 2000 21:32:33 -0400 (EDT) Received: from rdroms-nt.cisco.com (rtp-dial-1-99.cisco.com [10.83.97.99]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id VAA12470; Sat, 5 Aug 2000 21:32:15 -0400 (EDT) Message-Id: <4.3.1.2.20000805092114.00b5bee0@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Sat, 05 Aug 2000 09:22:56 -0400 To: DHCPv4 discussion list From: Ralph Droms Subject: Presentations at WG meetings 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 If you gave a presentation at last week's WG meetings, please forward a copy (if available in digital form) to me for inclusion with the WG minutes. Thanks... - Ralph From owner-dhcp-v6@bucknell.edu Sat Aug 5 21:35:53 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA00458 for ; Sat, 5 Aug 2000 21:35:53 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e761Wii15106; Sat, 5 Aug 2000 21:32:44 -0400 (EDT) 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 e761WXi28651; Sat, 5 Aug 2000 21:32:33 -0400 (EDT) Received: from rdroms-nt.cisco.com (rtp-dial-1-99.cisco.com [10.83.97.99]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id VAA12470; Sat, 5 Aug 2000 21:32:15 -0400 (EDT) Message-Id: <4.3.1.2.20000805092114.00b5bee0@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Sat, 05 Aug 2000 09:22:56 -0400 To: DHCPv6 discussion list From: Ralph Droms Subject: Presentations at WG meetings 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 If you gave a presentation at last week's WG meetings, please forward a copy (if available in digital form) to me for inclusion with the WG minutes. Thanks... - Ralph From owner-dhcp-v6@bucknell.edu Mon Aug 7 00:21:45 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA03661 for ; Mon, 7 Aug 2000 00:21:45 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e774I7i18441; Mon, 7 Aug 2000 00:18:08 -0400 (EDT) Received: from ztxmail02.ztx.compaq.com (ztxmail02.ztx.compaq.com [161.114.1.206]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e774I3i20774 for ; Mon, 7 Aug 2000 00:18:03 -0400 (EDT) Received: by ztxmail02.ztx.compaq.com (Postfix, from userid 12345) id 1EFB2426F; Sun, 6 Aug 2000 23:17:48 -0500 (CDT) Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by ztxmail02.ztx.compaq.com (Postfix) with ESMTP id A99BF3FCC for ; Sun, 6 Aug 2000 23:17:47 -0500 (CDT) Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM) id AAA0000675021; Mon, 7 Aug 2000 00:16:28 -0400 (EDT) From: Jim Bound Message-Id: <200008070416.AAA0000675021@anw.zk3.dec.com> To: DHCPv6 discussion list Subject: Re: Announcing DHCPv6 interim meeting in August In-reply-to: Your message of "Sat, 05 Aug 2000 02:42:23 EDT." <200008050642.CAA00983@grosse.bisbee.fugue.com> Date: Mon, 07 Aug 2000 00:16:27 -0400 X-Mts: smtp 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 Great message Ted. thank you very much (and Ralph too). /jim From owner-dhcp-v4@bucknell.edu Mon Aug 7 01:16:41 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01689 for ; Mon, 7 Aug 2000 01:16:40 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e775D8i11453; Mon, 7 Aug 2000 01:13:08 -0400 (EDT) Received: from laxmls02.socal.rr.com (laxmls02.socal.rr.com [24.30.163.11]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e775Cwi21348 for ; Mon, 7 Aug 2000 01:12:58 -0400 (EDT) Received: from [192.168.1.4] (sc-24-24-233-88.socal.rr.com [24.24.233.88]) by laxmls02.socal.rr.com (8.10.1/8.10.1) with ESMTP id e775CH002595 for ; Sun, 6 Aug 2000 22:12:17 -0700 (PDT) X-Sender: mikeford@pop-server.socal.rr.com Message-Id: In-Reply-To: <200008041904.MAA19876@nasnfs.eng.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 6 Aug 2000 22:04:21 -0800 To: DHCPv4 discussion list From: Mike Ford Subject: DHCP servers and clients Reply-To: mikeford@socal.rr.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Sorry to intrude, but after a week on this list its becoming clear its either the wrong place to ask DHCP questions, or that basic questions are extremely rare. I'll toss out my question hoping the later, monitor the list for another week, then quietly slink away. I am running NetBSD 1.4.2 on a mac IIci as a simple NAT firewall for my cablemodem (Socal Road Runner), and I am curious about having the DHCP server for my local network get information from the DHCP client that talks to the cable modem. Is there something I should be running that will pass information like the DNS addresses from client to server? Thanks for information, or directions to the correct list to ask at. From owner-dhcp-v4@bucknell.edu Mon Aug 7 13:15:50 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21948 for ; Mon, 7 Aug 2000 13:15:50 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e77HCNi15344; Mon, 7 Aug 2000 13:12:23 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e77HC9i17691 for ; Mon, 7 Aug 2000 13:12:09 -0400 (EDT) Received: from grosse.bisbee.fugue.com (user-2ive022.dialup.mindspring.com [165.247.0.66]) by toccata.fugue.com (8.9.3/8.6.11) with ESMTP id QAA24518; Sun, 6 Aug 2000 16:19:03 -0700 (PDT) Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.9.3+3.2W/8.6.11) with ESMTP id NAA01022; Mon, 7 Aug 2000 13:11:42 -0400 (EDT) Message-Id: <200008071711.NAA01022@grosse.bisbee.fugue.com> To: DHCPv4 discussion list cc: DHCPv4 discussion list Subject: Re: DHCP servers and clients In-Reply-To: Message from Mike Ford of "Sun, 06 Aug 2000 22:04:21 -0800." Date: Mon, 07 Aug 2000 13:11:42 -0400 From: Ted Lemon Reply-To: mellon@nominum.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN > I am curious about having the DHCP server for my local network get > information from the DHCP client that talks to the cable modem. There's currently no way to do that, although it would be cool, wouldn't it? You should really ask questions like this either on the ISC DHCP server mailing list (since that's what comes with NetBSD) or on a NetBSD mailing list. dhcp-v4 is the IETF DHC working group mailing list for discussing the DHCPv4 protocol, not a support group. _MelloN_ From owner-dhcp-v6@bucknell.edu Tue Aug 8 08:43:27 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22212 for ; Tue, 8 Aug 2000 08:43:27 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e781Boi23285; Mon, 7 Aug 2000 21:11:50 -0400 (EDT) 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 e781Bmi18452 for ; Mon, 7 Aug 2000 21:11:48 -0400 (EDT) Received: from rdroms-nt.cisco.com (sj-dial-1-153.cisco.com [171.68.179.154]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id VAA18039 for ; Mon, 7 Aug 2000 21:11:30 -0400 (EDT) Message-Id: <4.3.1.2.20000804152113.00ad5100@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Mon, 07 Aug 2000 21:13:59 -0400 To: DHCPv6 discussion list From: Ralph Droms Subject: Interim WG meeting 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 As Ted Lemon wrote in an earlier message, several members of the WG held a frank and productive meeting immediately after the scheduled WG meeting on 8/1 in Pittsburgh. My thanks especially to Ted for coaching us through some tough but fruitful dialogue and to the authors of the current spec - Mike Carney, Jim Bound and Charlie Perkins - as well as Bernard Aboba, Mark Stapp snd everyone else who attended. This message is the formal announcement of the DHC WG interim meeting on DHPVv6 that Ted mentioned in his message. The goal of this meeting is to facilitate the production of a DHCPv6 specification, published as an Internet Draft, that is ready for WG discussion at the San Diego IETF and WG last call immediately thereafter. To accomplish this goal at the meeting, members of the working group will: 1) Develop a final list of operational features to be retained, removed or added to DHCPv6 2) Make whatever other recommendations deemed necessary to produce a specification document ready for WG last call 3) Adopt a firm schedule and milestones for the revision, publication and discussion of the specification at the San Diego IETF Cisco Systems is happy to host the interim meeting 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. We need to pick a date and time for the meeting soon, so the meeting can take place as soon as possible. I would like to find a time during the week of 8/21 for the meeting - let's say noon-4PM EDT. If you expect to attend, please send me a message by 8/9 letting me know that you will attend and give me dates during the week of 8/21 that you would prefer, that would be acceptable, and that are unacceptable to you. - Ralph Droms From owner-dhcp-v4@bucknell.edu Tue Aug 8 10:38:52 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15685 for ; Tue, 8 Aug 2000 10:38:52 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e78EYgi04776; Tue, 8 Aug 2000 10:34:42 -0400 (EDT) Received: from web5401.mail.yahoo.com (web5401.mail.yahoo.com [216.115.106.132]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e78EYbi12249 for ; Tue, 8 Aug 2000 10:34:38 -0400 (EDT) Message-ID: <20000808143422.26496.qmail@web5401.mail.yahoo.com> Received: from [194.196.100.101] by web5401.mail.yahoo.com; Tue, 08 Aug 2000 16:34:22 CEST Date: Tue, 8 Aug 2000 16:34:22 +0200 (CEST) From: =?iso-8859-1?q?Fabrice=20Kah?= Subject: how to simulate multiple DHCP clients ? To: DHCPv4 discussion list MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Reply-To: fabrice_kah@yahoo.fr Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 8bit hello, In order to test a DHCP server, I need to simulate multiple DHCP clients (50 to 500 at the same time). I would like to know if it is possible to do this using only a few workstations, with a few network cards. I tried to do this using a windowsNT workstation, by changing the value HKEY_LOCAL_MACHINE/System/CurrentControlSet/Services/IBMTRP1/Parameters/Tcpip/DhcpClientIdentifier in the registery, but this doesn't seem to work for more than 3 clients. Can anyone help me or tell me if there is a way to do this on Solaris or on Linux ? ___________________________ Fabrice KAH fabrice.kah@fr.ibm.com +33 (0) 4 92 11 41 04 ___________________________________________________________ Do You Yahoo!? Achetez, vendez! À votre prix! Sur http://encheres.yahoo.fr From owner-dhcp-v4@bucknell.edu Tue Aug 8 11:21:22 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14536 for ; Tue, 8 Aug 2000 11:21:22 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e78FIMi17194; Tue, 8 Aug 2000 11:18:22 -0400 (EDT) Received: from mail2.aracnet.com (IDENT:root@mail2.aracnet.com [216.99.193.35]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e78FIBi16442 for ; Tue, 8 Aug 2000 11:18:11 -0400 (EDT) Received: from connectnet.com (conx.aracnet.com [216.99.200.135]) by mail2.aracnet.com (8.9.3/8.9.3) with ESMTP id IAA09030 for ; Tue, 8 Aug 2000 08:18:14 -0700 Message-ID: <399024DA.2D4AF42E@connectnet.com> Date: Tue, 08 Aug 2000 08:18:50 -0700 From: C J Considine X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: DHCPv4 discussion list Subject: Re: how to simulate multiple DHCP clients ? References: <20000808143422.26496.qmail@web5401.mail.yahoo.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Reply-To: conx@connectnet.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 8bit Just pretend to be a DHCP forwarding agent. Then you can script as many clients as you want without messing with multiple MAC addresses. All you really lose is client pingability and server ARP table overhead. It is also possible to hack the DHCP client to run multiple interfaces with funny MAC addresses, but what does it gain? We built a database of test packets and responses, with 10 second lease times it tests quickly. Fabrice Kah wrote: > > hello, > > In order to test a DHCP server, I need to simulate > multiple DHCP clients (50 to 500 at the same time). I > would like to know if it is possible to do this using > only a few workstations, with a few network cards. > I tried to do this using a windowsNT workstation, by > changing the value > HKEY_LOCAL_MACHINE/System/CurrentControlSet/Services/IBMTRP1/Parameters/Tcpip/DhcpClientIdentifier > in the registery, but this doesn't seem to work for > more than 3 clients. Can anyone help me or tell me if > there is a way to do this on Solaris or on Linux ? > ___________________________ > Fabrice KAH > fabrice.kah@fr.ibm.com > +33 (0) 4 92 11 41 04 > > ___________________________________________________________ > Do You Yahoo!? > Achetez, vendez! À votre prix! Sur http://encheres.yahoo.fr From owner-dhcp-v6@bucknell.edu Wed Aug 9 12:26:54 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12320 for ; Wed, 9 Aug 2000 12:26:54 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e79GN2i10325; Wed, 9 Aug 2000 12:23:03 -0400 (EDT) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e79GMii10876 for ; Wed, 9 Aug 2000 12:22:49 -0400 (EDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id e79GMS628720 for ; Wed, 9 Aug 2000 18:22:28 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id SAA12361 for ; Wed, 9 Aug 2000 18:22:27 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.9.3/8.9.3) with ESMTP id SAA19205 for ; Wed, 9 Aug 2000 18:24:21 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200008091624.SAA19205@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: DHCPv6 discussion list Subject: Re: Announcing DHCPv6 interim meeting in August In-reply-to: Your message of Sat, 05 Aug 2000 02:42:23 EDT. <200008050642.CAA00983@grosse.bisbee.fugue.com> Date: Wed, 09 Aug 2000 18:24:20 +0200 Sender: owner-dhcp-v6@bucknell.edu Reply-To: dhcp-v6@bucknell.edu X-Sender: Francis.Dupont@enst-bretagne.fr X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN In your previous mail you wrote: The way we are going to accomplish this is as follows: (1) Everybody who is strongly interested is going to read the current draft over carefully, if they haven't already, or if only as a means of accomplishing (2): => I strongly agree! (2) Each of us is going to make a list of the things that are in the draft that aren't okay with us, and a list of things that are not in the draft that we would like to see in the draft. => I have already sent this to authors... The only thing I can add is: get rid of the crazy Posix time stuff! (3) We will each publish this information on the DHCPv6 mailing list. => I don't understand why we need (4) because obviously the previous steps, including this one (3), were NOT done! I know a face to face meeting is better than a mailing list but the problem is not we were not able to reach an agreement in the mailing-list: the mailing-list was near dead before Michael burst of mails... (4) About two or three weeks from now (Ralph will announce the date and location - we are tentatively shooting for August 22nd), we are going to have a teleconference. We are going to go into the teleconference prepared to compromise. We are going to walk out of the conference _with_ a compromise. => teleconference (not easy with participants on at least 3 continents) seems to have been replaced by an interim meeting. Any IETF member is invited to participate, but we need to be very clear about this: you *must* do your homework. I say this as someone who is as guilty as the rest, but we can't afford to have hypothetical discussions here - this is the real deal. => the homework has been done here (:-)... I am considering to distrib our implementation (done by a student in a bit more than 2 months with all the hairy address stuff). Regards Francis.Dupont@enst-bretagne.fr From owner-dhcp-v6@bucknell.edu Wed Aug 9 12:28:23 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12381 for ; Wed, 9 Aug 2000 12:28:23 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e79GPXi11564; Wed, 9 Aug 2000 12:25:33 -0400 (EDT) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e79GPRi04278 for ; Wed, 9 Aug 2000 12:25:27 -0400 (EDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id e79GPB620888 for ; Wed, 9 Aug 2000 18:25:11 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id SAA12381 for ; Wed, 9 Aug 2000 18:25:10 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.9.3/8.9.3) with ESMTP id SAA19241 for ; Wed, 9 Aug 2000 18:27:04 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200008091627.SAA19241@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: DHCPv6 discussion list Subject: Re: Interim WG meeting In-reply-to: Your message of Mon, 07 Aug 2000 21:13:59 EDT. <4.3.1.2.20000804152113.00ad5100@funnel.cisco.com> Date: Wed, 09 Aug 2000 18:27:04 +0200 Sender: owner-dhcp-v6@bucknell.edu Reply-To: dhcp-v6@bucknell.edu X-Sender: Francis.Dupont@enst-bretagne.fr X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN In your previous mail you wrote: If you expect to attend, please send me a message by 8/9 letting me know that you will attend and give me dates during the week of 8/21 that you would prefer, that would be acceptable, and that are unacceptable to you. => I can't come (I have to keep some travel money for San Diego IETF)... Francis.Dupont@enst-bretagne.fr From owner-dhcp-v4@bucknell.edu Wed Aug 9 13:22:19 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14276 for ; Wed, 9 Aug 2000 13:22:18 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e79HIvi06376; Wed, 9 Aug 2000 13:18:57 -0400 (EDT) Received: from proxy1.bigplanet.com (proxy1.bigplanet.com [216.169.193.161]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e79HIoi25044 for ; Wed, 9 Aug 2000 13:18:50 -0400 (EDT) Received: from bigplanet.net (soulspace.bigplanet.com) by proxy1.bigplanet.com (Sun Internet Mail Server sims.3.5.1999.07.30.00.05.p8) with ESMTP id <0FZ100C2FC2ZY7@proxy1.bigplanet.com> for dhcp-v4@bucknell.edu; Wed, 9 Aug 2000 11:18:35 -0600 (MDT) Date: Wed, 09 Aug 2000 11:22:27 -0600 From: "Larry H. Raab" Subject: Running redundent DHCP servers... Sender: owner-dhcp-v4@bucknell.edu To: DHCPv4 discussion list Message-id: <39919353.69A992AA@bigplanet.net> MIME-version: 1.0 X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i686) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit X-Accept-Language: en Reply-To: larry.raab@bigplanet.net X-Sender: larry@soulspace.bigplanet.com X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit I need to set up a 2nd DHCP server for redundency (sp?) Is there a way to put the 2nd server is a state that only comes up if the first one comes down? Or is there a way to load balance between the 2 servers? Thanks, Larry Raab From owner-dhcp-v4@bucknell.edu Wed Aug 9 15:36:20 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17685 for ; Wed, 9 Aug 2000 15:36:20 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e79JX8i32436; Wed, 9 Aug 2000 15:33:08 -0400 (EDT) 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 e79JX6i27104 for ; Wed, 9 Aug 2000 15:33:06 -0400 (EDT) Received: by lespaul.process.com with Internet Mail Service (5.5.2650.21) id ; Wed, 9 Aug 2000 15:32:51 -0400 Message-ID: <63D30D6E10CFD11190A90000F805FE8602BEBFFE@lespaul.process.com> From: Bernie Volz To: DHCPv4 discussion list Subject: RE: Running redundent DHCP servers... Date: Wed, 9 Aug 2000 15:32:50 -0400 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 Well, look at draft-ietf-dhc-failover-07.txt and draft-ietf-dhc-loadb-02.txt. However, only a few servers exist that implement the failover concepts (Cisco and IPWorks) and I don't believe any exist that implement the load balancing concept. There are some options, though not great, with 'standard' servers. Splitting the lease pool and running both servers is one option (though it does have issues when a server is down and requires other care, as well as potentially large lease pools). - Bernie Volz IPWorks, Inc. -----Original Message----- From: Larry H. Raab [mailto:larry.raab@bigplanet.net] Sent: Wednesday, August 09, 2000 1:22 PM To: DHCPv4 discussion list Subject: Running redundent DHCP servers... I need to set up a 2nd DHCP server for redundency (sp?) Is there a way to put the 2nd server is a state that only comes up if the first one comes down? Or is there a way to load balance between the 2 servers? Thanks, Larry Raab From owner-dhcp-v4@bucknell.edu Wed Aug 9 15:50:34 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18033 for ; Wed, 9 Aug 2000 15:50:34 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e79Jnpi24476; Wed, 9 Aug 2000 15:49:51 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e79Jngi06746 for ; Wed, 9 Aug 2000 15:49:42 -0400 (EDT) Received: from grosse.bisbee.fugue.com (user-2ive2ge.dialup.mindspring.com [165.247.10.14]) by toccata.fugue.com (8.9.3/8.6.11) with ESMTP id SAA04776; Tue, 8 Aug 2000 18:56:35 -0700 (PDT) Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.9.3+3.2W/8.6.11) with ESMTP id PAA00542; Wed, 9 Aug 2000 15:47:21 -0400 (EDT) Message-Id: <200008091947.PAA00542@grosse.bisbee.fugue.com> To: DHCPv4 discussion list cc: DHCPv4 discussion list Subject: Re: Running redundent DHCP servers... In-Reply-To: Message from Bernie Volz of "Wed, 09 Aug 2000 15:32:50 EDT." <63D30D6E10CFD11190A90000F805FE8602BEBFFE@lespaul.process.com> Date: Wed, 09 Aug 2000 15:47:21 -0400 From: Ted Lemon Reply-To: mellon@nominum.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN > However, only a few servers exist that implement the failover concepts > (Cisco and IPWorks) and I don't believe any exist that implement the load > balancing concept. The latest version of the ISC/Nominum server does support this, but the support is brand new, and so it's a bit early to start deploying it in production. _MelloN_ From owner-dhcp-v4@bucknell.edu Wed Aug 9 18:12:27 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22042 for ; Wed, 9 Aug 2000 18:12:25 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e79M9Bi05185; Wed, 9 Aug 2000 18:09:11 -0400 (EDT) Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.125]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e79M99i27364 for ; Wed, 9 Aug 2000 18:09:09 -0400 (EDT) Received: from 157.54.9.101 by mail1.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 09 Aug 2000 15:07:48 -0700 (Pacific Daylight Time) Received: by INET-IMC-01 with Internet Mail Service (5.5.2651.58) id ; Wed, 9 Aug 2000 15:08:42 -0700 Message-ID: <5F1EEFAFB3573A46812FE84EF29C9AF52E9187@red-msg-05.redmond.corp.microsoft.com> From: Matthew Williamson To: DHCPv4 discussion list Cc: David Eitelbach Subject: RE: Question: draft-ietf-dhc-csr-02.txt Date: Wed, 9 Aug 2000 15:08:27 -0700 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 Your assumption is correct on the metric usage we're looking for. There are three reasons I believe this is a good idea: 1) Watching some posts as to the use of this, I saw a couple of needs somewhere in the order of "For networks that are designed in such a way that multiple routers are used to eventually go to the same place from one subnet... 2) If it sits in the router table, it would probably make sense to place it in here as well. 3) An Admin may want to throw it in there for multiple routers used in a failover scenerio. Thanks, m@ -----Original Message----- From: Bernie Volz [mailto:Volz@ipworks.com] Sent: Wednesday, August 02, 2000 10:43 AM To: DHCPv4 discussion list Cc: DHCPv4 discussion list Subject: RE: Question: draft-ietf-dhc-csr-02.txt Interesting idea but the question is what metrics did you want? Just a hop count type metric (such as used by Windows ROUTE ADD?). Ted ... what about considering this. One byte would be sufficient (per route). It does make the option data longer and also means that the DHCP Server would have to have this (static) information configured for the option. I'm neutral on this as I believe these routes are static and there is likely to be one route per 'destination'. And, active routing protocols are of more use to convey this type of information (such as RIP listeners). But, it is just as easy to always specify a value of 1 for these. If we're really keen on conserving bits in this option (and want to add this), one idea might be to use some of the subnet length bits for this. Since the subnet length requires 5 bits (0..31), we could use the remaining 3 bits to specify the metric. This would give a metric from 0 to 7 (or 1 to 8). This should be sufficient for most cases. This encoding would make it painful for people entering the data to the servers, but does compress the data. I'm not really in favor of this approach, but suggest it for those that feel this is important to add and want to keep the length of the option down. On the plus side, those that don't care about the metric simply specify the subnet mask and a 0 metric is mapped to 1 when the route is added. Note: As a side issue [on the issue of using a router address of 0.0.0.0 to mean "link-local" address], we could use a bit in the subnet length field to indicate whether the router address is present or not. If not present, this would mean it is on the interface being configured and hence you'd avoid having to send the router address (as 0.0.0.0). Of course, this would not be good if we encoded the metric in these bits since two bits for a metric is likely not enough. - Bernie Volz -----Original Message----- From: Matthew Williamson [mailto:mattwi@microsoft.com] Sent: Wednesday, August 02, 2000 1:16 PM To: DHCPv4 discussion list Subject: Question: draft-ietf-dhc-csr-02.txt Hello, I was wondering why there isn't a provision for metrics in draft-ietf-dhc-csr-02.txt, or if anyone's discussed adding them? thanks, Matthew -----Original Message----- From: Vipul.Gupta@Eng.Sun.COM [mailto:Vipul.Gupta@Eng.Sun.COM] Sent: Wednesday, August 02, 2000 9:51 AM To: DHCPv4 discussion list Cc: Vipul.Gupta@Eng.Sun.COM Subject: Public-key auth draft A copy of the (now expired) draft describing public-key authentication for DHCP is available at http://playground.sun.com/~vgupta/docs.html I'll resubmit this draft after consulting with the WG chair. thanks, vipul From owner-dhcp-v4@bucknell.edu Thu Aug 10 04:24:10 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12437 for ; Thu, 10 Aug 2000 04:24:10 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e7A8L5i26708; Thu, 10 Aug 2000 04:21:05 -0400 (EDT) Received: from web5402.mail.yahoo.com (web5402.mail.yahoo.com [216.115.106.140]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e7A8Kni10867 for ; Thu, 10 Aug 2000 04:20:49 -0400 (EDT) Message-ID: <20000810082033.8546.qmail@web5402.mail.yahoo.com> Received: from [194.196.100.114] by web5402.mail.yahoo.com; Thu, 10 Aug 2000 10:20:33 CEST Date: Thu, 10 Aug 2000 10:20:33 +0200 (CEST) From: =?iso-8859-1?q?Fabrice=20Kah?= Subject: Re: how to simulate multiple DHCP clients ? To: DHCPv4 discussion list MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Reply-To: fabrice_kah@yahoo.fr Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 8bit How do I pretend to be a DHCP forwarding agent? Is it possible to do this on a windows NT workstation? I managed to make a DHCP forwarding agent using a Cisco router, but this doesn't help. thank you for your help. Fabrice KAH fabrice.kah@fr.ibm.com +33 (0) 4 92 11 41 04 --- C J Considine a écrit : > Just pretend to be a DHCP forwarding agent. Then > you can script > as many clients as you want without messing with > multiple MAC > addresses. All you really lose is client pingability > and server > ARP table overhead. It is also possible to hack the > DHCP client > to run multiple interfaces with funny MAC addresses, > but what > does it gain? We built a database of test packets > and responses, > with 10 second lease times it tests quickly. > > Fabrice Kah wrote: > > > > hello, > > > > In order to test a DHCP server, I need to simulate > > multiple DHCP clients (50 to 500 at the same > time). I > > would like to know if it is possible to do this > using > > only a few workstations, with a few network cards. > > I tried to do this using a windowsNT workstation, > by > > changing the value > > > HKEY_LOCAL_MACHINE/System/CurrentControlSet/Services/IBMTRP1/Parameters/Tcpip/DhcpClientIdentifier > > in the registery, but this doesn't seem to work > for > > more than 3 clients. Can anyone help me or tell me > if > > there is a way to do this on Solaris or on Linux ? > > ___________________________ > > Fabrice KAH > > fabrice.kah@fr.ibm.com > > +33 (0) 4 92 11 41 04 > > > > > ___________________________________________________________ > > Do You Yahoo!? > > Achetez, vendez! À votre prix! Sur > http://encheres.yahoo.fr > ===== ____________________________________________ Fabrice Kah 355, Chemin des Serens 06610 La Gaude - FRANCE tel. (0033)4.93.24.82.97 port. (0033)6.63.06.99.04 ___________________________________________________________ Do You Yahoo!? Achetez, vendez! À votre prix! Sur http://encheres.yahoo.fr From owner-dhcp-v4@bucknell.edu Thu Aug 10 06:54:43 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14405 for ; Thu, 10 Aug 2000 06:54:43 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e7AApki32721; Thu, 10 Aug 2000 06:51:46 -0400 (EDT) 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 e7AApci04886 for ; Thu, 10 Aug 2000 06:51:38 -0400 (EDT) Received: from rdroms-nt.bucknell.edu (rtp-dial-1-63.cisco.com [10.83.97.63]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id GAA08616; Thu, 10 Aug 2000 06:51:10 -0400 (EDT) Message-Id: <4.3.1.2.20000810065056.00b20c10@mail.bucknell.edu> X-Sender: droms@mail.bucknell.edu X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Thu, 10 Aug 2000 06:53:29 -0400 To: DHCPv4 discussion list From: Ralph Droms Subject: Re: how to simulate multiple DHCP clients ? In-Reply-To: <20000810082033.8546.qmail@web5402.mail.yahoo.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 10:20 AM 8/10/00 +0200, Fabrice Kah wrote: >How do I pretend to be a DHCP forwarding agent? >Is it possible to do this on a windows NT workstation? I don't know if it's possible to configure NT to act as a forwarding agents and as multiple clients. You may need a special application that generates and receives DHCP client messages. A student of mine wrote such a tool - jDHCP - but he graduated and it's not available on line this AM. I expect to move the code and make it publicly accessible again later today. I'll post a note with the new location for the code later today... - Ralph Droms From owner-dhcp-v6@bucknell.edu Thu Aug 10 08:54:43 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19313 for ; Thu, 10 Aug 2000 08:54:42 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e7ACpgi15855; Thu, 10 Aug 2000 08:51:42 -0400 (EDT) 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 e7ACpTi24231; Thu, 10 Aug 2000 08:51:29 -0400 (EDT) Received: from rdroms-nt.cisco.com (rtp-dial-1-63.cisco.com [10.83.97.63]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id IAA16647; Thu, 10 Aug 2000 08:51:12 -0400 (EDT) Message-Id: <4.3.1.2.20000810084550.00affa00@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Thu, 10 Aug 2000 08:48:20 -0400 To: DHCPv6 discussion list From: Ralph Droms Subject: Interim WG meeting Cc: dhcp-v4@bucknell.edu 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'm reposting this message, with a copy to dhcp-v4, because I've only heard from four potential participants so far. If you have interest in participating, *please* get back to me today with your schedule so we can pick a date and time. We need to accomplish the goals of this meeting *soon* if we're going to get DHCPv6 on track before other events overtake it. - RD) This message is the formal announcement of the DHC WG interim meeting on DHPVv6 that Ted mentioned in his message. The goal of this meeting is to facilitate the production of a DHCPv6 specification, published as an Internet Draft, that is ready for WG discussion at the San Diego IETF and WG last call immediately thereafter. To accomplish this goal at the meeting, members of the working group will: 1) Develop a final list of operational features to be retained, removed or added to DHCPv6 2) Make whatever other recommendations deemed necessary to produce a specification document ready for WG last call 3) Adopt a firm schedule and milestones for the revision, publication and discussion of the specification at the San Diego IETF Cisco Systems is happy to host the interim meeting 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. We need to pick a date and time for the meeting soon, so the meeting can take place as soon as possible. I would like to find a time during the week of 8/21 for the meeting - let's say noon-4PM EDT. If you expect to attend, please send me a message by 8/9 letting me know that you will attend and give me dates during the week of 8/21 that you would prefer, that would be acceptable, and that are unacceptable to you. - Ralph Droms From owner-dhcp-v4@bucknell.edu Thu Aug 10 08:54:49 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19326 for ; Thu, 10 Aug 2000 08:54:49 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e7ACpgi16890; Thu, 10 Aug 2000 08:51:42 -0400 (EDT) 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 e7ACpTi24231; Thu, 10 Aug 2000 08:51:29 -0400 (EDT) Received: from rdroms-nt.cisco.com (rtp-dial-1-63.cisco.com [10.83.97.63]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id IAA16647; Thu, 10 Aug 2000 08:51:12 -0400 (EDT) Message-Id: <4.3.1.2.20000810084550.00affa00@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Thu, 10 Aug 2000 08:48:20 -0400 To: DHCPv4 discussion list From: Ralph Droms Subject: Interim WG meeting Cc: dhcp-v4@bucknell.edu 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 (I'm reposting this message, with a copy to dhcp-v4, because I've only heard from four potential participants so far. If you have interest in participating, *please* get back to me today with your schedule so we can pick a date and time. We need to accomplish the goals of this meeting *soon* if we're going to get DHCPv6 on track before other events overtake it. - RD) This message is the formal announcement of the DHC WG interim meeting on DHPVv6 that Ted mentioned in his message. The goal of this meeting is to facilitate the production of a DHCPv6 specification, published as an Internet Draft, that is ready for WG discussion at the San Diego IETF and WG last call immediately thereafter. To accomplish this goal at the meeting, members of the working group will: 1) Develop a final list of operational features to be retained, removed or added to DHCPv6 2) Make whatever other recommendations deemed necessary to produce a specification document ready for WG last call 3) Adopt a firm schedule and milestones for the revision, publication and discussion of the specification at the San Diego IETF Cisco Systems is happy to host the interim meeting 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. We need to pick a date and time for the meeting soon, so the meeting can take place as soon as possible. I would like to find a time during the week of 8/21 for the meeting - let's say noon-4PM EDT. If you expect to attend, please send me a message by 8/9 letting me know that you will attend and give me dates during the week of 8/21 that you would prefer, that would be acceptable, and that are unacceptable to you. - Ralph Droms From owner-dhcp-v6@bucknell.edu Thu Aug 10 10:35:09 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25232 for ; Thu, 10 Aug 2000 10:35:08 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e7AEV0i28767; Thu, 10 Aug 2000 10:31:00 -0400 (EDT) Received: from alfa.itea.ntnu.no (alfa.itea.ntnu.no [129.241.18.10]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e7AEUoi04855 for ; Thu, 10 Aug 2000 10:30:50 -0400 (EDT) Received: by alfa.itea.ntnu.no id QAA0000027020; Thu, 10 Aug 2000 16:30:48 +0200 (MET DST) From: Stig Venås Date: Thu, 10 Aug 2000 16:30:48 +0200 To: DHCPv6 discussion list Subject: prefix length in dhcpv6-15 Message-ID: <20000810163048.A15369@itea.ntnu.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i 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 Hi I'm reading through draft-ietf-dhc-dhcpv6-15.txt, the issues I have so far are: The text says implisitly that the prefix-len field in the solicit message sent by a client is 0, but I think it should be stated more clearly. In 10.3.3 it says: Once a client has selected Advertise message(s), the client will typically store information about each server, such as relay address and prefix length, server preference value, networks advertised, when the advertisement was received, and so on. Depending on the requirements of the client's invoking user, the client MAY initiate a configuration exchange with the server(s) immediately, or MAY defer this exchange until later. I don't see how the client knows the prefix length, and I can't see why it would store it either. Stig -- Stig Venaas UNINETT From owner-dhcp-v4@bucknell.edu Thu Aug 10 11:04:36 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26658 for ; Thu, 10 Aug 2000 11:04:35 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e7AF3ji16917; Thu, 10 Aug 2000 11:03:45 -0400 (EDT) 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 e7AF3ei10935 for ; Thu, 10 Aug 2000 11:03:40 -0400 (EDT) Received: by lespaul.process.com with Internet Mail Service (5.5.2650.21) id ; Thu, 10 Aug 2000 11:03:25 -0400 Message-ID: <63D30D6E10CFD11190A90000F805FE8602BEC011@lespaul.process.com> From: Bernie Volz To: DHCPv4 discussion list Subject: RE: Interim WG meeting Date: Thu, 10 Aug 2000 11:03:24 -0400 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 I would be very interested in participating, but will be away on vacation 8/13-8/27 and not likely to have phone access during much of this time. I realize that scheduling might be an issue, so if a date works for others and not me, go ahead. - Bernie -----Original Message----- From: Ralph Droms [mailto:rdroms@cisco.com] Sent: Thursday, August 10, 2000 8:48 AM To: DHCPv4 discussion list Cc: dhcp-v4@bucknell.edu Subject: Interim WG meeting (I'm reposting this message, with a copy to dhcp-v4, because I've only heard from four potential participants so far. If you have interest in participating, *please* get back to me today with your schedule so we can pick a date and time. We need to accomplish the goals of this meeting *soon* if we're going to get DHCPv6 on track before other events overtake it. - RD) This message is the formal announcement of the DHC WG interim meeting on DHPVv6 that Ted mentioned in his message. The goal of this meeting is to facilitate the production of a DHCPv6 specification, published as an Internet Draft, that is ready for WG discussion at the San Diego IETF and WG last call immediately thereafter. To accomplish this goal at the meeting, members of the working group will: 1) Develop a final list of operational features to be retained, removed or added to DHCPv6 2) Make whatever other recommendations deemed necessary to produce a specification document ready for WG last call 3) Adopt a firm schedule and milestones for the revision, publication and discussion of the specification at the San Diego IETF Cisco Systems is happy to host the interim meeting 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. We need to pick a date and time for the meeting soon, so the meeting can take place as soon as possible. I would like to find a time during the week of 8/21 for the meeting - let's say noon-4PM EDT. If you expect to attend, please send me a message by 8/9 letting me know that you will attend and give me dates during the week of 8/21 that you would prefer, that would be acceptable, and that are unacceptable to you. - Ralph Droms From owner-dhcp-v4@bucknell.edu Thu Aug 10 11:54:41 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29957 for ; Thu, 10 Aug 2000 11:54:41 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e7AFpSi30908; Thu, 10 Aug 2000 11:51:28 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e7AFp7i20766 for ; Thu, 10 Aug 2000 11:51:15 -0400 (EDT) Received: from grosse.bisbee.fugue.com (user-2ive00m.dialup.mindspring.com [165.247.0.22]) by toccata.fugue.com (8.9.3/8.6.11) with ESMTP id OAA08645; Wed, 9 Aug 2000 14:58:00 -0700 (PDT) Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.9.3+3.2W/8.6.11) with ESMTP id LAA00501; Thu, 10 Aug 2000 11:48:57 -0400 (EDT) Message-Id: <200008101548.LAA00501@grosse.bisbee.fugue.com> To: DHCPv4 discussion list cc: DHCPv4 discussion list Subject: Re: how to simulate multiple DHCP clients ? In-Reply-To: Message from =?iso-8859-1?q?Fabrice=20Kah?= of "Thu, 10 Aug 2000 10:20:33 +0200." <20000810082033.8546.qmail@web5402.mail.yahoo.com> Date: Thu, 10 Aug 2000 11:48:56 -0400 From: Ted Lemon Reply-To: mellon@nominum.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN > How do I pretend to be a DHCP forwarding agent? > Is it possible to do this on a windows NT workstation? You're going to have to write some code. I'd suggest doing it on Linux or BSD rather than NT, because if you do that there is freely-available code from which you can start - for example, the ISC DHCP distribution. _MelloN_ From owner-dhcp-v4@bucknell.edu Thu Aug 10 12:04:59 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01723 for ; Thu, 10 Aug 2000 12:04:58 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e7AG4Ci19889; Thu, 10 Aug 2000 12:04:12 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e7AG49i08155 for ; Thu, 10 Aug 2000 12:04:09 -0400 (EDT) Received: from grosse.bisbee.fugue.com (user-2ive00m.dialup.mindspring.com [165.247.0.22]) by toccata.fugue.com (8.9.3/8.6.11) with ESMTP id PAA08712; Wed, 9 Aug 2000 15:11:02 -0700 (PDT) Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.9.3+3.2W/8.6.11) with ESMTP id MAA00542; Thu, 10 Aug 2000 12:01:59 -0400 (EDT) Message-Id: <200008101601.MAA00542@grosse.bisbee.fugue.com> To: DHCPv4 discussion list cc: DHCPv4 discussion list Subject: Re: Interim WG meeting In-Reply-To: Message from Bernie Volz of "Thu, 10 Aug 2000 11:03:24 EDT." <63D30D6E10CFD11190A90000F805FE8602BEC011@lespaul.process.com> Date: Thu, 10 Aug 2000 12:01:58 -0400 From: Ted Lemon Reply-To: mellon@nominum.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN > I realize that scheduling might be an issue, so if a date works for others > and not me, go ahead. I'd really like to see you participate, Bernie. Given that we only have four takers so far, perhaps we can be flexible... :') _MelloN_ From owner-dhcp-v6@bucknell.edu Thu Aug 10 12:07:08 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02156 for ; Thu, 10 Aug 2000 12:07:07 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e7AG68i09176; Thu, 10 Aug 2000 12:06:08 -0400 (EDT) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e7AG64i21772 for ; Thu, 10 Aug 2000 12:06:04 -0400 (EDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id e7AG5m619809 for ; Thu, 10 Aug 2000 18:05:48 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id SAA22103 for ; Thu, 10 Aug 2000 18:05:47 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.9.3/8.9.3) with ESMTP id SAA24100 for ; Thu, 10 Aug 2000 18:07:46 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200008101607.SAA24100@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: DHCPv6 discussion list Subject: Re: prefix length in dhcpv6-15 In-reply-to: Your message of Thu, 10 Aug 2000 16:30:48 +0200. <20000810163048.A15369@itea.ntnu.no> Date: Thu, 10 Aug 2000 18:07:46 +0200 Sender: owner-dhcp-v6@bucknell.edu Reply-To: dhcp-v6@bucknell.edu X-Sender: Francis.Dupont@enst-bretagne.fr X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN In your previous mail you wrote: I'm reading through draft-ietf-dhc-dhcpv6-15.txt, the issues I have so far are: => the prefix-len stuff is buggy but not for this reason. The text says implisitly that the prefix-len field in the solicit message sent by a client is 0, but I think it should be stated more clearly. => 10.3.1. begins with a zeroed buffer then as the client doesn't set the prefix-len field it sends the solicit with a zero prefix-len... In 10.3.3 it says: Once a client has selected Advertise message(s), the client will typically store information about each server, such as relay address and prefix length, server preference value, networks advertised, when the advertisement was received, and so on. I don't see how the client knows the prefix length, => agree and I can't see why it would store it either. => the prefix-len is supposed to be used in order to recognize the link of off-link clients. This doesn't work because: - only the solicit message has a prefix-len client - if a prefix-len field is added in request messages then it should be added in advertisements too (your point), etc. - servers don't create/keep/... a database entry when they receive a solicit (they do this when they receive a request) then the prefix-len is not in messages used for database lookups... My proposal is to replace the prefix + prefix-len by the link for the database key (the other part of the key is the client link-local address). There are two kinds of links: - directly attached links (with on-link clients): the link is determined by the interface from which the packet was received. - not directly attached links (with off-link clients): the configuration file gives the list of the subnets of the link and the server finds a subnet (then a link) which matches with the relay address. The last point fails only when: - there are multi-link subnets (this is explicitely not supported, a statement will be added in the non-goal section, and there is no IPv6 multi-link subnets today then it doesn't matter). - an address can match more than one subnet, I think this is a nice case of configuration error (ie. this should never happen). A prefix-len can speed up subnet matching but is not necessary then my proposal (IMHO) is only simpler and less confusing. (a subnet is specified by a prefix, ie.
/, 0 <= d <= 128, the 128-d last bits of the address should be zeroed. Matching is done by the comparison of the d first bits, with a prefix-len matching begins by the check of equality with d (faster on the paper, don't forget than the prefix-len will be almost always 64 :-)). Regards Francis.Dupont@enst-bretagne.fr From owner-dhcp-v4@bucknell.edu Thu Aug 10 12:29:55 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03986 for ; Thu, 10 Aug 2000 12:29:54 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e7AGRFi11423; Thu, 10 Aug 2000 12:27:15 -0400 (EDT) Received: from honts307.wal-mart.com (honts307.wal-mart.com [146.132.234.37]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e7AGR0i07664 for ; Thu, 10 Aug 2000 12:27:00 -0400 (EDT) Received: from fwnts001.wal-mart.com ([146.132.235.8]) by honts307.wal-mart.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id QJAYM622; Thu, 10 Aug 2000 11:31:42 -0500 Received: from honts387.homeoffice.wal-mart.com by fwnts001.wal-mart.com via smtpd (for mailout.wal-mart.com [146.132.235.35]) with SMTP; 10 Aug 2000 16:26:40 UT Received: from honts305.homeoffice.wal-mart.com (unverified) by honts387.homeoffice.wal-mart.com (Content Technologies SMTPRS 4.1.5) with ESMTP id for ; Thu, 10 Aug 2000 11:23:47 -0500 Received: by HONTS305.homeoffice.wal-mart.com with Internet Mail Service (5.5.2650.21) id ; Thu, 10 Aug 2000 11:26:39 -0500 Message-ID: From: Nathan Lane To: DHCPv4 discussion list Subject: RE: Interim WG meeting Date: Thu, 10 Aug 2000 11:26:38 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Reply-To: ndlane@wal-mart.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN I'll be on vacation 8/13 to 8/21 but I'd like to participate for sure. -Nathan Lane Wal-Mart Stores, Inc. ********************************************************************** This email and any files transmitted with it are confidential and intended solely for the individual or entity to whom they are addressed. If you have received this email in error destroy it immediately. ********************************************************************** From owner-dhcp-v6@bucknell.edu Thu Aug 10 12:47:18 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04518 for ; Thu, 10 Aug 2000 12:47:17 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e7AGkei02493; Thu, 10 Aug 2000 12:46:40 -0400 (EDT) Received: from mail.ultradns.com (mail.ultradns.net [64.41.145.150]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e7AGkci27554 for ; Thu, 10 Aug 2000 12:46:39 -0400 (EDT) Received: (qmail 9673 invoked from network); 10 Aug 2000 16:46:37 -0000 Received: from nat-external.ultradns.net (HELO ULTRADNS6PMNFK) (216.15.7.195) by mail.ultradns.com with SMTP; 10 Aug 2000 16:46:37 -0000 From: "Barr Hibbs" To: DHCPv6 discussion list Subject: RE: Interim WG meeting Date: Thu, 10 Aug 2000 09:46:42 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: <4.3.1.2.20000810084550.00affa00@funnel.cisco.com> 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 Content-Transfer-Encoding: 7bit [Ralph Droms] > I would like to find a time during the week of 8/21 for > the meeting - let's say noon-4PM EDT. If you expect to attend, > please send me a message by 8/9 letting me know that you will > attend and give me dates during the week of 8/21 that you would > prefer, that would be acceptable, and that are unacceptable to you. > pretty much any day and time is fine for a conference call... --Barr From owner-dhcp-v4@bucknell.edu Thu Aug 10 13:41:59 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06309 for ; Thu, 10 Aug 2000 13:41:58 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e7AHYsi28901; Thu, 10 Aug 2000 13:34:54 -0400 (EDT) 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 e7AHYli32590; Thu, 10 Aug 2000 13:34:47 -0400 (EDT) Received: from sunmail1.Sun.COM ([129.145.1.2]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA16385; Thu, 10 Aug 2000 10:34:43 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.81.144]) by sunmail1.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6.1-sunmail1) with ESMTP id KAA27293; Thu, 10 Aug 2000 10:34:42 -0700 (PDT) Received: from dhcptest86-c (dhcptest86-c.Eng.Sun.COM [129.146.86.200]) by jurassic.eng.sun.com (8.11.0+Sun/8.11.0) with SMTP id e7AHYdo248996; Thu, 10 Aug 2000 10:34:39 -0700 (PDT) Date: Thu, 10 Aug 2000 10:34:15 -0700 (PDT) From: "Michael W. Carney" Reply-To: "Michael W. Carney" Subject: RE: Interim WG meeting To: DHCPv4 discussion list Cc: DHCPv4 discussion list , dhcp-v6@bucknell.edu, Volz@ipworks.com In-Reply-To: "Your message with ID" <63D30D6E10CFD11190A90000F805FE8602BEC011@lespaul.process.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Hi Ralph, Thomas said that we had to have 1 month notice before having an interim meeting. We might get better participation if we schedule this after labor day. People tend to take the last few weeks of aug. off. FWIW, Mike From owner-dhcp-v6@bucknell.edu Thu Aug 10 13:42:12 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06327 for ; Thu, 10 Aug 2000 13:42:12 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e7AHYsi17371; Thu, 10 Aug 2000 13:34:54 -0400 (EDT) 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 e7AHYli32590; Thu, 10 Aug 2000 13:34:47 -0400 (EDT) Received: from sunmail1.Sun.COM ([129.145.1.2]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA16385; Thu, 10 Aug 2000 10:34:43 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.81.144]) by sunmail1.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6.1-sunmail1) with ESMTP id KAA27293; Thu, 10 Aug 2000 10:34:42 -0700 (PDT) Received: from dhcptest86-c (dhcptest86-c.Eng.Sun.COM [129.146.86.200]) by jurassic.eng.sun.com (8.11.0+Sun/8.11.0) with SMTP id e7AHYdo248996; Thu, 10 Aug 2000 10:34:39 -0700 (PDT) Date: Thu, 10 Aug 2000 10:34:15 -0700 (PDT) From: "Michael W. Carney" Reply-To: "Michael W. Carney" Subject: RE: Interim WG meeting To: DHCPv6 discussion list Cc: DHCPv4 discussion list , dhcp-v6@bucknell.edu, Volz@ipworks.com In-Reply-To: "Your message with ID" <63D30D6E10CFD11190A90000F805FE8602BEC011@lespaul.process.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 Hi Ralph, Thomas said that we had to have 1 month notice before having an interim meeting. We might get better participation if we schedule this after labor day. People tend to take the last few weeks of aug. off. FWIW, Mike From owner-dhcp-v4@bucknell.edu Thu Aug 10 14:27:40 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09596 for ; Thu, 10 Aug 2000 14:27:40 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e7AIF6i08666; Thu, 10 Aug 2000 14:15:06 -0400 (EDT) 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 e7AIF1i00791 for ; Thu, 10 Aug 2000 14:15:01 -0400 (EDT) Received: from sunmail1.Sun.COM ([129.145.1.2]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA08587 for ; Thu, 10 Aug 2000 11:15:00 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.82.166]) by sunmail1.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6.1-sunmail1) with ESMTP id LAA08354 for ; Thu, 10 Aug 2000 11:15:00 -0700 (PDT) Received: from reggae (reggae.Eng.Sun.COM [129.146.86.243]) by jurassic.eng.sun.com (8.11.0+Sun/8.11.0) with SMTP id e7AIEwo260494 for ; Thu, 10 Aug 2000 11:14:58 -0700 (PDT) Message-Id: <200008101814.e7AIEwo260494@jurassic.eng.sun.com> Date: Thu, 10 Aug 2000 11:14:34 -0700 (PDT) From: Jason Goldschmidt Reply-To: Jason Goldschmidt Subject: Re: how to simulate multiple DHCP clients ? To: DHCPv4 discussion list MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: HweFoGe9y9hmuakuv7YvCQ== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4 SunOS 5.8 sun4u sparc Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN >I don't know if it's possible to configure NT to act as a forwarding agents >and as multiple clients. You may need a special application that generates >and receives DHCP client messages. A student of mine wrote such a tool - >jDHCP - but he graduated and it's not available on line this AM. I expect >to move the code and make it publicly accessible again later today. I'll >post a note with the new location for the code later today... this package that Ralph speaks of can be found at: http://www.dhcp.org/javadhcp/download/manyclients-1.0.tar.gz and http://www.dhcp.org/javadhcp/download/manyclients-1.0.zip the app was written using JDHCP-1.0.1 (which is included in the tar bar) ... it will generate N clients each with a random MAC address the usage is: java manyclients Thanks, Jason Goldschmidt jgoldsch@eng.sun.com > >- Ralph Droms > ********************************** Jason Goldschmidt * Internet Engineering: QoS Group * 650-786-3502 * jgoldsch@eng.sun.com * ********************************** From owner-dhcp-v4@bucknell.edu Thu Aug 10 18:27:00 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15281 for ; Thu, 10 Aug 2000 18:26:59 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e7AMNki02582; Thu, 10 Aug 2000 18:23:46 -0400 (EDT) Received: from e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.104]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e7AMNfi05456 for ; Thu, 10 Aug 2000 18:23:41 -0400 (EDT) Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e4.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id SAA167628 for ; Thu, 10 Aug 2000 18:23:34 -0400 From: hoyoung@us.ibm.com Received: from D51MTA04.pok.ibm.com (d51mta04.pok.ibm.com [9.117.200.32]) by northrelay02.pok.ibm.com (8.8.8m3/NCO v4.92) with SMTP id SAA36004 for ; Thu, 10 Aug 2000 18:23:38 -0400 Received: by D51MTA04.pok.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 85256937.007AFFEB ; Thu, 10 Aug 2000 18:23:29 -0400 X-Lotus-FromDomain: IBMUS To: DHCPv4 discussion list Message-ID: <85256937.007AFB47.00@D51MTA04.pok.ibm.com> Date: Thu, 10 Aug 2000 17:23:25 -0500 Subject: DHCP relay agent in multi-hop environment Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Reply-To: hoyoung@us.ibm.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN All, How doe the DHCP relay argent work in the environment where the DHCP server is several switches(layer 3)/routers away from the users? For example, if I have a hierarchical network model (core switches/routers-distribution switches/routers--access switches/routers-client), dhcp servers are hanging off the core, how would the relay agent work in this model? Or would it work at all? thanks! Hannah ----- I/T Network Support, IBM Global Services SDC-North, Rochester, MN Phone 507-253-4100 Tieline 553-4100 From owner-dhcp-v4@bucknell.edu Thu Aug 10 18:50:15 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15506 for ; Thu, 10 Aug 2000 18:50:15 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e7AMnbi05630; Thu, 10 Aug 2000 18:49:37 -0400 (EDT) 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 e7AMnYi18270 for ; Thu, 10 Aug 2000 18:49:34 -0400 (EDT) Received: by lespaul.process.com with Internet Mail Service (5.5.2650.21) id ; Thu, 10 Aug 2000 18:49:19 -0400 Message-ID: <63D30D6E10CFD11190A90000F805FE8602BEC019@lespaul.process.com> From: Bernie Volz To: DHCPv4 discussion list Subject: RE: DHCP relay agent in multi-hop environment Date: Thu, 10 Aug 2000 18:49:18 -0400 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 It would work just fine. The relays need to be at the "edge" (on each network). Routers are often relays. The relays forward packets to the servers, which are at configured addresses (the relays are given the addresses). The network routing handles delivering these packets to the servers since they are unicast (and back from the servers to the relays, again since they are unicast packets). Once the relay receives a reply, it sends it out to the client (either via unicast or via broadcast). -----Original Message----- From: hoyoung@us.ibm.com [mailto:hoyoung@us.ibm.com] Sent: Thursday, August 10, 2000 6:23 PM To: DHCPv4 discussion list Subject: DHCP relay agent in multi-hop environment All, How doe the DHCP relay argent work in the environment where the DHCP server is several switches(layer 3)/routers away from the users? For example, if I have a hierarchical network model (core switches/routers-distribution switches/routers--access switches/routers-client), dhcp servers are hanging off the core, how would the relay agent work in this model? Or would it work at all? thanks! Hannah ----- I/T Network Support, IBM Global Services SDC-North, Rochester, MN Phone 507-253-4100 Tieline 553-4100 From owner-dhcp-v6@bucknell.edu Fri Aug 11 16:03:25 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02313 for ; Fri, 11 Aug 2000 16:03:24 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e7BJxoi31845; Fri, 11 Aug 2000 15:59:50 -0400 (EDT) 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 e7BJxai17612 for ; Fri, 11 Aug 2000 15:59:36 -0400 (EDT) Received: from rdroms-nt.cisco.com (ch2-dhcp133-161.cisco.com [161.44.133.161]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id PAA07965; Fri, 11 Aug 2000 15:59:20 -0400 (EDT) Message-Id: <4.3.1.2.20000811115017.00b47e70@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Fri, 11 Aug 2000 16:01:17 -0400 To: DHCPv6 discussion list From: Ralph Droms Subject: Proceeding with work on the DHCPv6 spec Cc: narten@RALEIGH.IBM.COM, Erik.Nordmark@ENG.SUN.COM 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 been getting some pushback from the IESG about the interim WG meeting we've planned for the week of 8/21. The IESG has developed some guidelines for WG meetings, some of which we haven't met or will be unable to meet: * IESG/AD approval * 30 day advance notice on the IETF mailing list * Published agenda So, stepping back for a second, I heard us agree in the impromptu DHCPv6 meeting in Pittsburgh that our ultimate goal is to get a protocol spec out for in time for a last round of WG discussion in San Diego and WG last call by the end of December. I suggest we take the following steps to accomplish that goal: 1) A design team uses a conference call to put together a proposal for work on the spec that includes: * Criteria and process for developing a list of changes to the spec; example criteria for inclusion (and design) or exclusion of a particular feature might include: - Is this a feature clearly required in the next six months or can it be added as an extension later - Is this a feature new to DHCPv6 and is the feature required by IPv6 - Is the design of this feature based on DHCPv4 experience Process issues might include requiring a justification for features that differ from DHCPv4 design * Timeline for milestones to meet before the San Diego meeting * Interim meeting to discuss spec after revision based on WG list of changes (see 3, below) 2) The WG adopts the proposal 3) The WG develops a list of changes to the spec based on the adopted ground rules; this list of changes becomes instructions to the authors for revising the spec 4) The authors rev the spec and publish a new draft doc 5) The WG holds an interim meeting to discuss the revised spec; the product of the meeting is instructions to the authors for another revision of the specification 6) The authors rev the spec and publish for final WG discussion in San Diego From owner-dhcp-v4@bucknell.edu Fri Aug 11 20:55:29 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09129 for ; Fri, 11 Aug 2000 20:55:29 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e7C0ooi13294; Fri, 11 Aug 2000 20:50:51 -0400 (EDT) Received: from [192.83.249.51] (amplifynet.com [192.83.249.51]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e7C0ohi21064 for ; Fri, 11 Aug 2000 20:50:43 -0400 (EDT) Received: from anet1.amplifynet.com by [192.83.249.51] via smtpd (for marge.bucknell.edu [134.82.9.1]) with SMTP; 12 Aug 2000 00:43:13 UT Received: from amplifynet.com (PRATAP [172.16.1.97]) by anet1.amplifynet.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id PYBDMHLB; Fri, 11 Aug 2000 17:48:58 -0700 Message-ID: <39949EFD.7E350295@amplifynet.com> Date: Fri, 11 Aug 2000 17:49:01 -0700 From: Pratap Devatha X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: DHCPv4 discussion list Subject: can the DatagramID be the same in client and server packet Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Reply-To: pdevatha@amplifynet.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 8bit Hi, Iam trying to debug a DHCP server. Following is part of capture on a sniffer. First is the request from the client and the second reply from server. I observed that in both the packets, "DatagramID= 5b8". Should this be a problem???? Thanking U, Pratap Client Packet tick=293961 Pkt= 212 of 212 C2 size= 342 = 0x156 prot=8 === E H € D C 4zR 7 ! & c Sc5 = & 2 8 Kyle < MSFT 987 ,./+M ! 7 ====V_H=45 TOS_IPLengt= 0 DatagramID= 5b8, Frg Area=0, TOL=80, Prot-id=11 Hdr-cksum=a081 SIP= 0.0.0.0 DIP= 255.255.255.255 UDP msg SPort=68, TPort=67 HDRLen=0x3401, CheckSum=0x527a Mac Src = 0: 1: 2:26:a6: 8 dest = ff:ff:ff:ff:ff:ff Server Packet tick=293965 Pkt= 213 of 213 C1 size= 582 = 0x246 prot=8 === E 8 € C D $V 7 ! & c Sc 5 : ; 'P3 Q€6 H, . ! 7 7J ==== ====V_H=45 TOS_IPLengt= 0 DatagramID= 5b8, Frg Area=0, TOL=80, Prot-id=11 Hdr-cksum=9dd1 SIP= 172.16.3.2 DIP= 255.255.255.255 UDP msg SPort=67, TPort=68 HDRLen=0x2402, CheckSum=0xa956 Mac Src = 8: 0:3e: 3: 2: 2 dest = ff:ff:ff:ff:ff:ff From owner-dhcp-v4@bucknell.edu Tue Aug 15 10:24:34 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15749 for ; Tue, 15 Aug 2000 10:24:33 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e7FEKhi16800; Tue, 15 Aug 2000 10:20:43 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e7FEKbi10304 for ; Tue, 15 Aug 2000 10:20:38 -0400 (EDT) Received: from grosse.bisbee.fugue.com (user-2iveb68.dialup.mindspring.com [165.247.44.200]) by toccata.fugue.com (8.9.3/8.6.11) with ESMTP id NAA28087; Mon, 14 Aug 2000 13:27:26 -0700 (PDT) Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.9.3+3.2W/8.6.11) with ESMTP id OAA00241; Mon, 14 Aug 2000 14:01:40 -0400 (EDT) Message-Id: <200008141801.OAA00241@grosse.bisbee.fugue.com> To: DHCPv4 discussion list cc: DHCPv4 discussion list Subject: Re: can the DatagramID be the same in client and server packet In-Reply-To: Message from Pratap Devatha of "Fri, 11 Aug 2000 17:49:01 PDT." <39949EFD.7E350295@amplifynet.com> Date: Mon, 14 Aug 2000 14:01:40 -0400 From: Ted Lemon Reply-To: mellon@nominum.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN > I observed that in both the packets, "DatagramID= 5b8". Should this > be a problem???? I sincerely doubt that this is the problem. (I assume you are having a problem... :') If you have a problem, why not tell us what it is, and maybe we can help you. Actually, unless you're asking about protocol issues (i.e., you're an implementor), it's usually better not to ask here - if you are using the ISC DHCP server, send mail to dhcp-server@isc.org (you have to subscribe first). If you are using some other server, the dhcp-interest@isc.org mailing list is appropriate. If this is a protocol question, I'm sorry for dumping all this extraneous information on you. :'} _MelloN_ From owner-dhcp-v6@bucknell.edu Tue Aug 15 10:25:54 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15763 for ; Tue, 15 Aug 2000 10:25:54 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e7FEMxi09289; Tue, 15 Aug 2000 10:22:59 -0400 (EDT) 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 e7FEMoi16026 for ; Tue, 15 Aug 2000 10:22:50 -0400 (EDT) Received: from rdroms-nt.cisco.com (ch2-dhcp133-161.cisco.com [161.44.133.161]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id KAA09378; Tue, 15 Aug 2000 10:22:34 -0400 (EDT) Message-Id: <4.3.1.2.20000815100108.00b50ad0@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Tue, 15 Aug 2000 10:24:57 -0400 To: DHCPv6 discussion list From: Ralph Droms Subject: Proceeding with work on the DHCPv6 spec Cc: narten@RALEIGH.IBM.COM, Erik.Nordmark@ENG.SUN.COM 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'm reposting my message about moving forward with DHCPv6, because I've seen *no* reaction whatsoever - either mailed to me personally or posted to the mailing list. So, if you have an opinion about this plan, if you want to clarify or amplify something I've written, if you want to propose an alternative plan, please speak up! - Ralph ===== I've been getting some pushback from the IESG about the interim WG meeting we've planned for the week of 8/21. The IESG has developed some guidelines for WG meetings, some of which we haven't met or will be unable to meet: * IESG/AD approval * 30 day advance notice on the IETF mailing list * Published agenda So, stepping back for a second, I heard us agree in the impromptu DHCPv6 meeting in Pittsburgh that our ultimate goal is to get a protocol spec out for in time for a last round of WG discussion in San Diego and WG last call by the end of December. I suggest we take the following steps to accomplish that goal: 1) A design team uses a conference call to put together a proposal for work on the spec that includes: * Criteria and process for developing a list of changes to the spec; example criteria for inclusion (and design) or exclusion of a particular feature might include: - Is this a feature clearly required in the next six months or can it be added as an extension later - Is this a feature new to DHCPv6 and is the feature required by IPv6 - Is the design of this feature based on DHCPv4 experience Process issues might include requiring a justification for features that differ from DHCPv4 design * Timeline for milestones to meet before the San Diego meeting * Interim meeting to discuss spec after revision based on WG list of changes (see 3, below) 2) The WG adopts the proposal 3) The WG develops a list of changes to the spec based on the adopted ground rules; this list of changes becomes instructions to the authors for revising the spec 4) The authors rev the spec and publish a new draft doc 5) The WG holds an interim meeting to discuss the revised spec; the product of the meeting is instructions to the authors for another revision of the specification 6) The authors rev the spec and publish for final WG discussion in San Diego From owner-dhcp-v4@bucknell.edu Tue Aug 15 16:52:02 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24754 for ; Tue, 15 Aug 2000 16:52:01 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e7FKlci24006; Tue, 15 Aug 2000 16:47:38 -0400 (EDT) Received: from basmail.basystems.com (basmail.basystems.com [209.211.220.7]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e7FKlWi13541 for ; Tue, 15 Aug 2000 16:47:32 -0400 (EDT) Received: from basystems.com ([12.17.204.129]) by basmail.basystems.com (Netscape Messaging Server 3.62) with SMTP id 236 for ; Tue, 15 Aug 2000 16:48:52 -0400 Message-ID: <3999ADE3.44CDB578@basystems.com> Date: Tue, 15 Aug 2000 14:53:55 -0600 From: "Rich Rommes" Reply-To: rich@basystems.com X-Mailer: Mozilla 4.72 [en]C-CCK-MCD {Sony} (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: DHCPv4 discussion list Subject: Static address allocation regardless of GIADDR 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 Folks: Is there a way to statically allocate an address to a client and have the DHCP server ignore the GIADDR so that it allocates an address regardless of what subnet is represented by the GIADDR field ? This is for those case where the router can only pass a single GIADDR even though it has multiple sub-interfaces. Please excuse me if this question has been asked before, and could someone point me to the archives ? Thanks, Rich. -- Richard Rommes Broadband Access Systems (BAS) Director of Business Development and Network Architecture Phone 303-884-6141 Email: rich@basystems.com Pager: 888-952-0555 FAx: 303-681-2295 www.basystems.com From owner-dhcp-v4@bucknell.edu Tue Aug 15 17:32:57 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27645 for ; Tue, 15 Aug 2000 17:32:57 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e7FLUDi25004; Tue, 15 Aug 2000 17:30:13 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e7FLU1i16722 for ; Tue, 15 Aug 2000 17:30:01 -0400 (EDT) Received: from grosse.bisbee.fugue.com (adsl-151-202-89-231.bellatlantic.net [151.202.89.231]) by toccata.fugue.com (8.9.3/8.6.11) with ESMTP id UAA29105; Mon, 14 Aug 2000 20:36:51 -0700 (PDT) Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.9.3+3.2W/8.6.11) with ESMTP id RAA01544; Tue, 15 Aug 2000 17:27:46 -0400 (EDT) Message-Id: <200008152127.RAA01544@grosse.bisbee.fugue.com> To: DHCPv4 discussion list cc: DHCPv4 discussion list Subject: Re: Static address allocation regardless of GIADDR In-Reply-To: Message from "Rich Rommes" of "Tue, 15 Aug 2000 14:53:55 MDT." <3999ADE3.44CDB578@basystems.com> Date: Tue, 15 Aug 2000 17:27:45 -0400 From: Ted Lemon Reply-To: mellon@nominum.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN > Is there a way to statically allocate an address to a > client and have the DHCP server ignore the GIADDR so that it allocates > an address regardless of what subnet is represented by the GIADDR field > ? This is for those case where the router can only pass a single GIADDR > even though it has multiple sub-interfaces. > Please excuse me if this question has been asked before, > and could someone point me to the archives ? I don't know of any DHCP servers that _don't_ support this - it's a very common configuration! :') On the ISC/Nominum DHCP server, you need to use the shared-network statement. I think Microsoft calls these superscopes. I don't know much about the other DHCP servers that are available, so I can't tell you how to figure out how to configure them - sorry about that. BTW, as you can probably see from my rather general answer, it's usually better to go to a mailing list or support service that's specific to your DHCP server rather than asking for help on the IETF DHCP working group mailing list (this mailing list). The ISC DHCP server is supported on the dhcp-server@isc.org mailing list; Nominum and Microsoft both charge for support. _MelloN_ From owner-dhcp-v4@bucknell.edu Wed Aug 16 10:55:23 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26747 for ; Wed, 16 Aug 2000 10:55:22 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e7GEppi21580; Wed, 16 Aug 2000 10:51:51 -0400 (EDT) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e7GEpmi09567 for ; Wed, 16 Aug 2000 10:51:48 -0400 (EDT) Received: from northrelay01.pok.ibm.com (northrelay01.pok.ibm.com [9.117.200.21]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id KAA57306 for ; Wed, 16 Aug 2000 10:51:33 -0400 From: hoyoung@us.ibm.com Received: from D51MTA04.pok.ibm.com (d51mta04.pok.ibm.com [9.117.200.32]) by northrelay01.pok.ibm.com (8.8.8m3/NCO v4.92) with SMTP id KAA72930 for ; Wed, 16 Aug 2000 10:51:40 -0400 Received: by D51MTA04.pok.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 8525693D.0051A16E ; Wed, 16 Aug 2000 10:51:37 -0400 X-Lotus-FromDomain: IBMUS To: DHCPv4 discussion list Message-ID: <8525693D.0051A00C.00@D51MTA04.pok.ibm.com> Date: Wed, 16 Aug 2000 09:51:43 -0500 Subject: Unauthorized DHCP servers Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Reply-To: hoyoung@us.ibm.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN I'm a little confused as for how a dhcp client decides to accept a reply from legal and illegal servers. It seems to me, in a case of an unauthorized dhcp server on a local segment as the client, the client always pick the NAK from the unauthorized server. Is it simply because of distance/hops since the unauthorized server is on the same wire as the client, while the authorized server is one or two hops away from the client? If so, why the delta time shows that the client actually receives the reply packets from the legal server first when I do a sniffer trace? Here is some background. Let's say, an unauthorized dhcp server is sitting on the same segment as the dhcp client, whereas the authorized servers sites on a different segment as the client. The client has to go through the router/relay agent to get to the legal server. When the client sends broadcast messages out, both the legal and illegal servers will receive the broadcast message and try to reply back to the client. Question: In the case of the illegal server, since it's local to the client, would it send unicast pack to the client or would it flood the reply message on to the wire and let the client decide? In the case of the legal server, since it's on a separate segment as the client, it will unicast it's reply packet to the relay agent, the relay agent then either unicast or broadcast to the client. Now how the relay agent decide whether to unicast or broadcast the packet to the client? thanks for your help! Hannah From owner-dhcp-v4@bucknell.edu Wed Aug 16 11:08:22 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27301 for ; Wed, 16 Aug 2000 11:08:20 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e7GF7fi20338; Wed, 16 Aug 2000 11:07:41 -0400 (EDT) Received: from proxy1.bigplanet.com (proxy1.bigplanet.com [216.169.193.161]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e7GF7Ti22210 for ; Wed, 16 Aug 2000 11:07:29 -0400 (EDT) Received: from bigplanet.net (soulspace.bigplanet.com) by proxy1.bigplanet.com (Sun Internet Mail Server sims.3.5.1999.07.30.00.05.p8) with ESMTP id <0FZE0029B4OF7R@proxy1.bigplanet.com> for dhcp-v4@bucknell.edu; Wed, 16 Aug 2000 09:07:27 -0600 (MDT) Date: Wed, 16 Aug 2000 09:11:50 -0600 From: "Larry H. Raab" Subject: Address Exclusion. Sender: owner-dhcp-v4@bucknell.edu To: DHCPv4 discussion list Message-id: <399AAF36.39CB45D6@bigplanet.net> MIME-version: 1.0 X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i686) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit X-Accept-Language: en Reply-To: larry.raab@bigplanet.net X-Sender: larry@soulspace.bigplanet.com X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit Is there a command to exclude address from a scope? Like if I have range 10.0.0.5 10.0.0.50 But need to exclude 10.0.0.20 - 10.0.0.25 Thanks From owner-dhcp-v4@bucknell.edu Wed Aug 16 18:07:21 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04545 for ; Wed, 16 Aug 2000 18:07:20 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e7GM4Ci11493; Wed, 16 Aug 2000 18:04:12 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e7GM40i06590 for ; Wed, 16 Aug 2000 18:04:00 -0400 (EDT) Received: from grosse.bisbee.fugue.com (adsl-151-202-89-231.bellatlantic.net [151.202.89.231]) by toccata.fugue.com (8.9.3/8.6.11) with ESMTP id VAA03446; Tue, 15 Aug 2000 21:09:19 -0700 (PDT) Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.9.3+3.2W/8.6.11) with ESMTP id SAA00602; Wed, 16 Aug 2000 18:00:17 -0400 (EDT) Message-Id: <200008162200.SAA00602@grosse.bisbee.fugue.com> To: DHCPv4 discussion list cc: DHCPv4 discussion list Subject: Re: Address Exclusion. In-Reply-To: Message from "Larry H. Raab" of "Wed, 16 Aug 2000 09:11:50 MDT." <399AAF36.39CB45D6@bigplanet.net> Date: Wed, 16 Aug 2000 18:00:17 -0400 From: Ted Lemon Reply-To: mellon@nominum.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN This sounds like an ISC DHCP server question - perhaps you should ask on the ISC DHCP server mailing list: dhcp-server@isc.org. _MelloN_ From owner-dhcp-v4@bucknell.edu Fri Aug 18 01:21:48 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA13561 for ; Fri, 18 Aug 2000 01:21:48 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e7I5ISi19661; Fri, 18 Aug 2000 01:18:28 -0400 (EDT) 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 e7I5IMi27728 for ; Fri, 18 Aug 2000 01:18:22 -0400 (EDT) Received: from rdroms-nt.bucknell.edu (sjck-dial-gw5-18.cisco.com [10.19.238.19]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id BAA14485; Fri, 18 Aug 2000 01:17:58 -0400 (EDT) Message-Id: <4.3.1.2.20000817221341.00aec9f0@mail.bucknell.edu> X-Sender: droms@mail.bucknell.edu X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Thu, 17 Aug 2000 22:20:20 -0700 To: DHCPv4 discussion list From: Ralph Droms Subject: Use of option 61 in DHCP authentication Cc: DHCPv4 discussion list In-Reply-To: References: <14725.47959.37256.738608@kitab.cisco.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 Bill - rev -14 of the draft calls for the use of option 61 in authentication protocol 1, with a reference an expired draft by Mike Henry, "DHCP Option 61 UUID Type Definition" , which defines the syntax for expressing a UUID within option 61. I don't see where it's necessary to use the UUID form of identification, unless you're trying to guarantee unique identification. Would it be acceptable to change the draft to allow the use of any style of client identifier in option 61? - Ralph From owner-dhcp-v4@bucknell.edu Fri Aug 18 02:25:41 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24091 for ; Fri, 18 Aug 2000 02:25:40 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e7I6Mli06721; Fri, 18 Aug 2000 02:22:47 -0400 (EDT) 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 e7I6Mki24129 for ; Fri, 18 Aug 2000 02:22:46 -0400 (EDT) Received: from rdroms-nt.cisco.com (sjck-dial-gw5-18.cisco.com [10.19.238.19]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id CAA16782 for ; Fri, 18 Aug 2000 02:22:29 -0400 (EDT) Message-Id: <4.3.1.2.20000817231719.00b074f0@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Thu, 17 Aug 2000 23:23:22 -0700 To: DHCPv4 discussion list From: Ralph Droms Subject: Authentication option 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 In the description of client behavior (section 5.5.1 of draft-ietf-dhc-authentication-14.txt), the current draft specifies that the client may not use any DHCPOFFER messages that fail the authentication validation: 2. The client MUST validate any DHCPOFFER messages that include authentication information using the mechanism specified in section 5.3. The client MUST discard any messages which fail to pass validation and MAY log the validation failure. The client selects one DHCPOFFER message as its selected configuration. If none of the DHCPOFFER messages received by the client include authentication information, the client MAY choose an unauthenticated message as its selected configuration. The client SHOULD be configurable to accept or reject unauthenticated DHCPOFFER messages. I've received a suggestion that the use of DHCPOFFER messages that fail validation should be a client policy; that is, a client should be allowed to use those messages if, for instance, no DHCPOFFERs are received that pass validation. Is it acceptable to the WG to make the suggested change? - Ralph From owner-dhcp-v4@bucknell.edu Fri Aug 18 03:59:26 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24825 for ; Fri, 18 Aug 2000 03:59:26 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e7I7uHi02185; Fri, 18 Aug 2000 03:56:17 -0400 (EDT) Received: from sigma.cisco.com (sigma.cisco.com [171.69.63.142]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e7I7uFi09136 for ; Fri, 18 Aug 2000 03:56:15 -0400 (EDT) Received: from andreawlap (sj-dial-4-17.cisco.com [171.68.181.146]) by sigma.cisco.com (8.8.8-Cisco List Logging/8.8.8) with SMTP id AAA08612 for ; Fri, 18 Aug 2000 00:55:53 -0700 (PDT) From: "Andrea Westerinen" To: DHCPv4 discussion list Subject: Policy Terminology Draft Date: Fri, 18 Aug 2000 00:59:37 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Reply-To: andreaw@cisco.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit The Policy Framework WG has created an I-D to try to disambiguate policy terminology across all IETF Work Groups. This draft is located at: http://www.ietf.org/internet-drafts/draft-ietf-policy-terminology-00.txt In creating the draft, the team tried to look across all RFCs and WGs to gain an understanding of policy and its applicability, and consolidate definitions. At the Pittsburgh Policy Framework session, it was recommended that this draft be forwarded to all work groups where it may be applicable. (If you receive multiple copies, my apologies.) Please look the draft over, and if you have feedback, please reply to me and/or to the policy mail list (policy@raleigh.ibm.com). Some questions to be considered are ... Are there definitions that should be updated? Are there additional terms that should be defined? For the current terms in the draft, please try to use these terms consistently. Our goal is to take this draft through the standards process and have it serve a function similar to RFC2828. Thanks. Andrea Westerinen Policy Terminology Draft Editor From owner-dhcp-v4@bucknell.edu Fri Aug 18 10:03:29 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28651 for ; Fri, 18 Aug 2000 10:03:29 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e7IDxZi10962; Fri, 18 Aug 2000 09:59:35 -0400 (EDT) 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 e7IDxNi30806 for ; Fri, 18 Aug 2000 09:59:23 -0400 (EDT) Received: from kkinnear-nt (ch2-dhcp133-90.cisco.com [161.44.133.90]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id JAA13466; Fri, 18 Aug 2000 09:59:07 -0400 (EDT) Message-Id: <4.2.0.58.20000818095449.0206e400@funnel.cisco.com> X-Sender: kkinnear@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Fri, 18 Aug 2000 09:59:58 -0400 To: DHCPv4 discussion list From: Kim Kinnear Subject: Re: Authentication option Cc: DHCPv4 discussion list , kkinnear@cisco.com In-Reply-To: <4.3.1.2.20000817231719.00b074f0@funnel.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 At 11:23 PM 8/17/00 -0700, Ralph Droms wrote: >In the description of client behavior (section 5.5.1 of draft-ietf-dhc-authentication-14.txt), the current draft specifies that the client may not use any DHCPOFFER messages that fail the authentication validation: > > 2. The client MUST validate any DHCPOFFER messages that include > authentication information using the mechanism specified in section > 5.3. The client MUST discard any messages which fail to pass > validation and MAY log the validation failure. The client selects one > DHCPOFFER message as its selected configuration. If none of the > DHCPOFFER messages received by the client include authentication > information, the client MAY choose an unauthenticated message as its > selected configuration. The client SHOULD be configurable to accept > or reject unauthenticated DHCPOFFER messages. > >I've received a suggestion that the use of DHCPOFFER messages that fail validation should be a client policy; that is, a client should be allowed to use those messages if, for instance, no DHCPOFFERs are received that pass validation. Is it acceptable to the WG to make the suggested change? This change sounds quite reasonable to me -- if the client is trying to authenticate DHCP servers, that in itself is a policy decision on the part of the client. Given that, if it chooses to then *not* require an authenticated DHCP server, that is perfectly reasonable. Of course, it *could* do this with a new, non-authenticated DHCPDISCOVER, but why bother? That just increases network traffic to no useful end. As part of this change, the draft probably should include language that says "and the client SHOULD inform the user" that an unvalidated (or whatever you want to call it) DHCPOFFER was used. Kim >- Ralph > From owner-dhcp-v4@bucknell.edu Fri Aug 18 10:15:39 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28820 for ; Fri, 18 Aug 2000 10:15:38 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e7IEF6i03717; Fri, 18 Aug 2000 10:15:06 -0400 (EDT) Received: from stanmsr4.telecom.sna.samsung.com (host8.samsungtelecom.com [209.39.48.8]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e7IEEsi11439 for ; Fri, 18 Aug 2000 10:14:54 -0400 (EDT) Received: by stanmsr4.telecom.sna.samsung.com with Internet Mail Service (5.5.2650.21) id ; Fri, 18 Aug 2000 09:14:35 -0500 Message-ID: <3058B3212471D411AAAB0008C7A4FCCA57173F@stanmsr4.telecom.sna.samsung.com> From: Bob Evans To: DHCPv4 discussion list Subject: Any C++ Client Source Code? Date: Fri, 18 Aug 2000 09:14:35 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Reply-To: revans@sta.samsung.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN I am integrating ISC's C source into our C++ environment (Solaris). This is proving to be a tedious exercise. Are there any C++/Unix sources available for DHCP clients? We need to develop a customized client for our application. Thanks, Bob. - ============================ Bob Evans, Principal Engineer Distributed Processing Environment Team Network Systems Lab Samsung Telecommunications America 1130 E. Arapaho Road Richardson, TX 75081 From owner-dhcp-v4@bucknell.edu Fri Aug 18 11:24:55 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00366 for ; Fri, 18 Aug 2000 11:24:55 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e7IFLdi31000; Fri, 18 Aug 2000 11:21:39 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e7IFLPi09492 for ; Fri, 18 Aug 2000 11:21:25 -0400 (EDT) Received: from grosse.bisbee.fugue.com ([149.123.118.98]) by toccata.fugue.com (8.9.3/8.6.11) with ESMTP id OAA10862; Thu, 17 Aug 2000 14:28:13 -0700 (PDT) Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.9.3+3.2W/8.6.11) with ESMTP id LAA00484; Fri, 18 Aug 2000 11:19:16 -0400 (EDT) Message-Id: <200008181519.LAA00484@grosse.bisbee.fugue.com> To: DHCPv4 discussion list cc: DHCPv4 discussion list Subject: Re: Authentication option In-Reply-To: Message from Ralph Droms of "Thu, 17 Aug 2000 23:23:22 PDT." <4.3.1.2.20000817231719.00b074f0@funnel.cisco.com> Date: Fri, 18 Aug 2000 11:19:16 -0400 From: Ted Lemon Reply-To: mellon@nominum.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN > I've received a suggestion that the use of DHCPOFFER messages that fail > validation should be a client policy; that is, a client should be allowed > to use those messages if, for instance, no DHCPOFFERs are received that > pass validation. Is it acceptable to the WG to make the suggested change? I think this is right, except that there are actually at least two ways validation can fail: it can fail because the client doesn't have the key needed to validate, and it can fail because the client has the key, and the signature doesn't check out. I don't know if it makes sense to distinguish between these two cases, but perhaps it does - if the signature doesn't check out, it probably means the client or server is misconfigured, and should be fixed. Also, it's fairly axiomatic in the security world that if authentication fails, you make it very clear to whomever is depending on authentication that it has failed, and let them decide how to proceed (unless you have just defaulted to not proceeding at all). It would be bad to give the user the impression that everything's okay when it's not. _MelloN_ From owner-dhcp-v4@bucknell.edu Fri Aug 18 11:31:58 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00557 for ; Fri, 18 Aug 2000 11:31:58 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e7IFV4i20200; Fri, 18 Aug 2000 11:31:04 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e7IFUni30848 for ; Fri, 18 Aug 2000 11:30:50 -0400 (EDT) Received: from grosse.bisbee.fugue.com ([149.123.118.98]) by toccata.fugue.com (8.9.3/8.6.11) with ESMTP id OAA10903; Thu, 17 Aug 2000 14:37:37 -0700 (PDT) Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.9.3+3.2W/8.6.11) with ESMTP id LAA00528; Fri, 18 Aug 2000 11:28:40 -0400 (EDT) Message-Id: <200008181528.LAA00528@grosse.bisbee.fugue.com> To: DHCPv4 discussion list cc: DHCPv4 discussion list Subject: Re: Any C++ Client Source Code? In-Reply-To: Message from Bob Evans of "Fri, 18 Aug 2000 09:14:35 CDT." <3058B3212471D411AAAB0008C7A4FCCA57173F@stanmsr4.telecom.sna.samsung.com> Date: Fri, 18 Aug 2000 11:28:40 -0400 From: Ted Lemon Reply-To: mellon@nominum.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN > I am integrating ISC's C source into our C++ environment (Solaris). This is > proving to be a tedious exercise. It seems like it would be about a day's work, right? > Are there any C++/Unix sources available > for DHCP clients? We need to develop a customized client for our > application. There is a Java DHCP library that might help you, but of course that would require rototilling as well. Can't you just slap 'extern "C" {}' around the dhclient declarations? _MelloN_ From owner-dhcp-v4@bucknell.edu Fri Aug 18 11:43:16 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00826 for ; Fri, 18 Aug 2000 11:43:15 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e7IFgOi25586; Fri, 18 Aug 2000 11:42:24 -0400 (EDT) Received: from stanmsr4.telecom.sna.samsung.com (host8.samsungtelecom.com [209.39.48.8]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e7IFg8i25288 for ; Fri, 18 Aug 2000 11:42:08 -0400 (EDT) Received: by stanmsr4.telecom.sna.samsung.com with Internet Mail Service (5.5.2650.21) id ; Fri, 18 Aug 2000 10:41:50 -0500 Message-ID: <3058B3212471D411AAAB0008C7A4FCCA571741@stanmsr4.telecom.sna.samsung.com> From: Bob Evans To: DHCPv4 discussion list Cc: DHCPv4 discussion list Subject: RE: Any C++ Client Source Code? Date: Fri, 18 Aug 2000 10:41:50 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Reply-To: revans@sta.samsung.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Hi Ted, > Can't you just slap > 'extern "C" {}' > around the dhclient declarations? It's not quite so simple. In addition to the above, I have to: 1) add function signatures inside the function definitions and delete them underneath: void f(a) int a; { ...to... void f(int a) { 2) the C++ keywords "new" and "class" are used as variables/structs throughout the code, for example, in common/memory.c. I have to remap these to something different. 3) I have to add many explicit casts which the C++ compiler is demanding. Thanks, Bob. > -----Original Message----- > From: Ted Lemon [mailto:mellon@nominum.com] > Sent: Friday, August 18, 2000 10:29 AM > To: revans@sta.samsung.com > Cc: DHCPv4 discussion list > Subject: Re: Any C++ Client Source Code? > > > > > I am integrating ISC's C source into our C++ environment > (Solaris). This is > > proving to be a tedious exercise. > > It seems like it would be about a day's work, right? > > > Are there any C++/Unix sources available > > for DHCP clients? We need to develop a customized client for our > > application. > > There is a Java DHCP library that might help you, but of course that > would require rototilling as well. Can't you just slap > 'extern "C" {}' > around the dhclient declarations? > > _MelloN_ > From owner-dhcp-v4@bucknell.edu Fri Aug 18 11:57:00 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01056 for ; Fri, 18 Aug 2000 11:56:59 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e7IFsQi31139; Fri, 18 Aug 2000 11:54:26 -0400 (EDT) Received: from stanmsr4.telecom.sna.samsung.com (host8.samsungtelecom.com [209.39.48.8]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e7IFsDi22511 for ; Fri, 18 Aug 2000 11:54:13 -0400 (EDT) Received: by stanmsr4.telecom.sna.samsung.com with Internet Mail Service (5.5.2650.21) id ; Fri, 18 Aug 2000 10:53:55 -0500 Message-ID: <3058B3212471D411AAAB0008C7A4FCCA571742@stanmsr4.telecom.sna.samsung.com> From: Bob Evans To: DHCPv4 discussion list Subject: RE: Any C++ Client Source Code? Date: Fri, 18 Aug 2000 10:53: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: revans@sta.samsung.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Whoa ! Just tried placing the extern "C" wrapper around the entire source module, and it seems to be working w/o the other changes I was suggesting. Thanks, Ted. > -----Original Message----- > From: Bob Evans [mailto:revans@sta.samsung.com] > Sent: Friday, August 18, 2000 10:42 AM > To: DHCPv4 discussion list > Cc: DHCPv4 discussion list > Subject: RE: Any C++ Client Source Code? > > > Hi Ted, > > Can't you just slap > > 'extern "C" {}' > > around the dhclient declarations? > > It's not quite so simple. In addition to the above, I have to: > 1) add function signatures inside the function definitions > and delete them > underneath: > void f(a) > int a; { > ...to... > void f(int a) { > 2) the C++ keywords "new" and "class" are used as variables/structs > throughout the code, for example, in common/memory.c. I have > to remap these > to something different. > 3) I have to add many explicit casts which the C++ compiler > is demanding. > > Thanks, Bob. > > > > -----Original Message----- > > From: Ted Lemon [mailto:mellon@nominum.com] > > Sent: Friday, August 18, 2000 10:29 AM > > To: revans@sta.samsung.com > > Cc: DHCPv4 discussion list > > Subject: Re: Any C++ Client Source Code? > > > > > > > > > I am integrating ISC's C source into our C++ environment > > (Solaris). This is > > > proving to be a tedious exercise. > > > > It seems like it would be about a day's work, right? > > > > > Are there any C++/Unix sources available > > > for DHCP clients? We need to develop a customized client for our > > > application. > > > > There is a Java DHCP library that might help you, but of course that > > would require rototilling as well. Can't you just slap > > 'extern "C" {}' > > around the dhclient declarations? > > > > _MelloN_ > > > From owner-dhcp-v4@bucknell.edu Fri Aug 18 12:03:03 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01279 for ; Fri, 18 Aug 2000 12:03:02 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e7IG2Vi26165; Fri, 18 Aug 2000 12:02:31 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e7IG2Hi23258 for ; Fri, 18 Aug 2000 12:02:17 -0400 (EDT) Received: from grosse.bisbee.fugue.com ([149.123.118.98]) by toccata.fugue.com (8.9.3/8.6.11) with ESMTP id PAA11022; Thu, 17 Aug 2000 15:09:06 -0700 (PDT) Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.9.3+3.2W/8.6.11) with ESMTP id MAA00632; Fri, 18 Aug 2000 12:00:09 -0400 (EDT) Message-Id: <200008181600.MAA00632@grosse.bisbee.fugue.com> To: DHCPv4 discussion list cc: DHCPv4 discussion list Subject: Re: Any C++ Client Source Code? In-Reply-To: Message from Bob Evans of "Fri, 18 Aug 2000 10:41:50 CDT." <3058B3212471D411AAAB0008C7A4FCCA571741@stanmsr4.telecom.sna.samsung.com> Date: Fri, 18 Aug 2000 12:00:09 -0400 From: Ted Lemon Reply-To: mellon@nominum.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN The latest DHCP code is moving away from K&R, and in fact won't build on K&R compilers. So I'm all in favor of any efforts to de-K&R the code, and would be happy to work with you on this (although I don't have time to do it myself, unfortunately). This would mean that at least you wouldn't have to redo this work in future versions. > 2) the C++ keywords "new" and "class" are used as variables/structs > throughout the code, for example, in common/memory.c. I have to remap these > to something different. Good point. Again, this is something that should be fixed - there's no reason why the code should be gratuitously incompatible with C++. > 3) I have to add many explicit casts which the C++ compiler is demanding. Again, I have tried very hard to make the very latest code, which is only available from anoncvs, compile even with an extremely pedantic compiler. Working from that code, the set of these errors that I would expect you to find should be much smaller than with, e.g., 3.0b1pl17 or 2.0pl4. _MelloN_ From owner-dhcp-v4@bucknell.edu Fri Aug 18 12:04:10 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01297 for ; Fri, 18 Aug 2000 12:04:10 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e7IG3Li26052; Fri, 18 Aug 2000 12:03:21 -0400 (EDT) Received: from stanmsr4.telecom.sna.samsung.com (host8.samsungtelecom.com [209.39.48.8]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e7IG3Bi05875 for ; Fri, 18 Aug 2000 12:03:11 -0400 (EDT) Received: by stanmsr4.telecom.sna.samsung.com with Internet Mail Service (5.5.2650.21) id ; Fri, 18 Aug 2000 11:02:53 -0500 Message-ID: <3058B3212471D411AAAB0008C7A4FCCA571743@stanmsr4.telecom.sna.samsung.com> From: Bob Evans To: DHCPv4 discussion list Subject: RE: Any C++ Client Source Code? Date: Fri, 18 Aug 2000 11:02:52 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Reply-To: revans@sta.samsung.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Well, it (wrapping with extern "C") worked for common/nit.c, but not options.c. I'll stop this chatter now - sorry. Bob. > -----Original Message----- > From: Bob Evans [mailto:revans@sta.samsung.com] > Sent: Friday, August 18, 2000 10:54 AM > To: DHCPv4 discussion list > Subject: RE: Any C++ Client Source Code? > > > Whoa ! > Just tried placing the extern "C" wrapper around the entire > source module, > and it seems to be working w/o the other changes I was suggesting. > Thanks, Ted. > > > -----Original Message----- > > From: Bob Evans [mailto:revans@sta.samsung.com] > > Sent: Friday, August 18, 2000 10:42 AM > > To: DHCPv4 discussion list > > Cc: DHCPv4 discussion list > > Subject: RE: Any C++ Client Source Code? > > > > > > Hi Ted, > > > Can't you just slap > > > 'extern "C" {}' > > > around the dhclient declarations? > > > > It's not quite so simple. In addition to the above, I have to: > > 1) add function signatures inside the function definitions > > and delete them > > underneath: > > void f(a) > > int a; { > > ...to... > > void f(int a) { > > 2) the C++ keywords "new" and "class" are used as variables/structs > > throughout the code, for example, in common/memory.c. I have > > to remap these > > to something different. > > 3) I have to add many explicit casts which the C++ compiler > > is demanding. > > > > Thanks, Bob. > > > > > > > -----Original Message----- > > > From: Ted Lemon [mailto:mellon@nominum.com] > > > Sent: Friday, August 18, 2000 10:29 AM > > > To: revans@sta.samsung.com > > > Cc: DHCPv4 discussion list > > > Subject: Re: Any C++ Client Source Code? > > > > > > > > > > > > > I am integrating ISC's C source into our C++ environment > > > (Solaris). This is > > > > proving to be a tedious exercise. > > > > > > It seems like it would be about a day's work, right? > > > > > > > Are there any C++/Unix sources available > > > > for DHCP clients? We need to develop a customized > client for our > > > > application. > > > > > > There is a Java DHCP library that might help you, but of > course that > > > would require rototilling as well. Can't you just slap > > > 'extern "C" {}' > > > around the dhclient declarations? > > > > > > _MelloN_ > > > > > > From owner-dhcp-v4@bucknell.edu Fri Aug 18 12:37:02 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01847 for ; Fri, 18 Aug 2000 12:37:01 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e7IGY6i29007; Fri, 18 Aug 2000 12:34:06 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e7IGY3i03374 for ; Fri, 18 Aug 2000 12:34:04 -0400 (EDT) Received: from grosse.bisbee.fugue.com ([149.123.118.98]) by toccata.fugue.com (8.9.3/8.6.11) with ESMTP id PAA11112; Thu, 17 Aug 2000 15:40:51 -0700 (PDT) Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.9.3+3.2W/8.6.11) with ESMTP id MAA00700; Fri, 18 Aug 2000 12:31:54 -0400 (EDT) Message-Id: <200008181631.MAA00700@grosse.bisbee.fugue.com> To: DHCPv4 discussion list cc: DHCPv4 discussion list Subject: Re: Any C++ Client Source Code? In-Reply-To: Message from Bob Evans of "Fri, 18 Aug 2000 10:53:54 CDT." <3058B3212471D411AAAB0008C7A4FCCA571742@stanmsr4.telecom.sna.samsung.com> Date: Fri, 18 Aug 2000 12:31:54 -0400 From: Ted Lemon Reply-To: mellon@nominum.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN > Just tried placing the extern "C" wrapper around the entire source module, > and it seems to be working w/o the other changes I was suggesting. *grin* _MelloN_ From owner-dhcp-v4@bucknell.edu Fri Aug 18 13:29:58 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03004 for ; Fri, 18 Aug 2000 13:29:58 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e7IHRQi09488; Fri, 18 Aug 2000 13:27:26 -0400 (EDT) Received: from mail.ultradns.com (mail.ultradns.net [64.41.145.150]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e7IHRGi04784 for ; Fri, 18 Aug 2000 13:27:16 -0400 (EDT) Received: (qmail 28719 invoked from network); 18 Aug 2000 17:27:11 -0000 Received: from nat-external.ultradns.net (HELO ULTRADNS6PMNFK) (216.15.7.195) by mail.ultradns.com with SMTP; 18 Aug 2000 17:27:11 -0000 From: "Barr Hibbs" To: DHCPv4 discussion list Subject: RE: Unauthorized DHCP servers Date: Fri, 18 Aug 2000 10:27:19 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400 In-reply-to: <8525693D.0051A00C.00@D51MTA04.pok.ibm.com> Importance: Normal Reply-To: rbhibbs@ultraDNS.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit > -----Original Message----- > From: hoyoung@us.ibm.com > Sent: Wednesday, August 16, 2000 7:52 AM > > I'm a little confused as for how a dhcp client decides to accept a reply > from legal and illegal servers. It seems to me, in a case of an > unauthorized dhcp server on a local segment as the client, the client > always pick the NAK from the unauthorized server. Is it simply > because of distance/hops since the unauthorized server is on the same > wire as the client, while the authorized server is one or two hops away > from the client? If so, why the delta time shows that the client actually > receives the reply packets from the legal server first when I do a sniffer > trace? > ...there really are no hard and fast rules governing the mechanism by which a DHCP client selects which IP address lease offer it will accept when soliciting lease offers in an environment with multiple servers. Forgetting about DHCP Authentication for the moment, the client is free to accept or decline any offered lease. If the client has no prior experience (that is, has not previously been connected to any network segment) it will generally attempt to use the first address lease offered it. The client sends a gratuitous ARP request packet and waits for a reply. If a reply is received, the client should decline the address, as it obviously is already in use. The absence of a reply, unfortunately, does not guarantee that the address is available, especially in those environments utilizing switches and routers whose ARP caches may not be fully initialized. It is possible for a client (though I know of none that do this) to issue multiple gratuitous ARP requests to circumvent timing problems with ARP cache initialization. Clients may use any criteria they wish to select an offered IP address lease, including server address and any other information that can be gleaned from the DHCPOFFER packet, so it is quite possible to select an offered lease from a bogus or rogue DHCP server. Many clients remember the server from which it last accepted an offer, so those clients will be biased towards selecting offers from that server on subsequent discover-offer-request-ack cycles. Using the Microsoft client as an example, the user may be required to issue the two commands, "ipconfig /release" and "ipconfig /renew" to eliminate the bias. This is why a "closer" server is sometimes ignored by a client. > Here is some background. Let's say, an unauthorized dhcp server > is sitting on the same segment as the dhcp client, whereas the > authorized servers sites on a different segment as the client. The > client has to go through the router/relay agent to get to the legal > server. When the client sends broadcast messages out, both the > legal and illegal servers will receive the broadcast message and > try to reply back to the client. > > Question: > In the case of the illegal server, since it's local to the client, > would it send unicast pack to the client or would it flood the > reply message on to the wire and let the client decide? > ...because the client does not yet have an IP address, unicasts are not possible, but, as most servers can determine the source (local or gatewayed) it would be possible for the server to choose between an "all-nets" broadcast or a subnet broadcast, but usually the DHCP server leaves that decision to the underlying IP stack installed on the server host. In answer to your question, the client always decides. > In the case of the legal server, since it's on a separate segment as the > client, it will unicast it's reply packet to the relay agent, the relay > agent then either unicast or broadcast to the client. Now how the relay > agent decide whether to unicast or broadcast the packet to the client? > ...Again, a relay agent can't unicast to a host lacking an IP address, and probably doesn't make the choice of an all-nets versus subnet broadcast, leaving that to the underlying IP stack. for an example of a relay agent implementation, check out the Internet Software Consortium's DHCPD distribution. Hope that helps.... --Barr From owner-dhcp-v4@bucknell.edu Fri Aug 18 13:48:23 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03560 for ; Fri, 18 Aug 2000 13:48:23 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e7IHlSi14876; Fri, 18 Aug 2000 13:47:28 -0400 (EDT) Received: from mail.ultradns.com (mail.ultradns.net [64.41.145.150]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e7IHlHi11828 for ; Fri, 18 Aug 2000 13:47:17 -0400 (EDT) Received: (qmail 29207 invoked from network); 18 Aug 2000 17:47:16 -0000 Received: from nat-external.ultradns.net (HELO ULTRADNS6PMNFK) (216.15.7.195) by mail.ultradns.com with SMTP; 18 Aug 2000 17:47:16 -0000 From: "Barr Hibbs" To: DHCPv4 discussion list Subject: RE: Any C++ Client Source Code? Date: Fri, 18 Aug 2000 10:47:24 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400 In-reply-to: <200008181600.MAA00632@grosse.bisbee.fugue.com> Importance: Normal Reply-To: rbhibbs@ultraDNS.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit > The latest DHCP code is moving away from K&R, and in fact won't build > on K&R compilers. So I'm all in favor of any efforts to de-K&R the > code, and would be happy to work with you on this (although I don't > have time to do it myself, unfortunately). This would mean that at > least you wouldn't have to redo this work in future versions. > ...interesting..... One of my local modifications (because we originally had to compile on ANSI-only mainframes) was to install ANSI function prototyping throughout, and to segregate the K&R style code so as to preserve the original while primarily using ANSI > > 3) I have to add many explicit casts which the C++ compiler is > demanding. > > Again, I have tried very hard to make the very latest code, which is > only available from anoncvs, compile even with an extremely pedantic > compiler. > ...to deal with our flakely mainframe compiler, which went nutso over casts, I had to do exactly the same thing... as well as change a number of macro definitions (like TIME) which interfered with defined system calls believe me I understand how much work is involved in doing this!! --Barr From owner-dhcp-v4@bucknell.edu Fri Aug 18 14:50:32 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04797 for ; Fri, 18 Aug 2000 14:50:32 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e7IIldi15389; Fri, 18 Aug 2000 14:47:39 -0400 (EDT) Received: from mail.ultradns.com (mail.ultradns.net [64.41.145.150]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e7IIlUi13725 for ; Fri, 18 Aug 2000 14:47:30 -0400 (EDT) Received: (qmail 31252 invoked from network); 18 Aug 2000 18:47:29 -0000 Received: from nat-external.ultradns.net (HELO ULTRADNS6PMNFK) (216.15.7.195) by mail.ultradns.com with SMTP; 18 Aug 2000 18:47:29 -0000 From: "Barr Hibbs" To: DHCPv4 discussion list Subject: RE: Use of option 61 in DHCP authentication Date: Fri, 18 Aug 2000 11:47:37 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400 In-reply-to: <4.3.1.2.20000817221341.00aec9f0@mail.bucknell.edu> Importance: Normal Reply-To: rbhibbs@ultraDNS.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit > -----Original Message----- > From: Ralph Droms > Sent: Thursday, August 17, 2000 10:20 PM > > Bill - rev -14 of the draft calls for the use of option 61 in > authentication protocol 1, with a reference an expired draft by > Mike Henry, > "DHCP Option 61 UUID Type Definition" > , which defines the syntax for > expressing a UUID within option 61. > > I don't see where it's necessary to use the UUID form of identification, > unless you're trying to guarantee unique identification. Would it be > acceptable to change the draft to allow the use of any style of client > identifier in option 61? > ...I agree: we should not use an expired I-D as part of authentication protocol 1: if there is consensus that we need to improve the uniqueness of the client identifier to be more "universal" for authentication and other purposes, let's just tackle that issue directly. --Barr From owner-dhcp-v4@bucknell.edu Fri Aug 18 15:08:27 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05210 for ; Fri, 18 Aug 2000 15:08:27 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e7IJ7qi25055; Fri, 18 Aug 2000 15:07:52 -0400 (EDT) Received: from mail.ultradns.com (mail.ultradns.net [64.41.145.150]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e7IJ7ai01145 for ; Fri, 18 Aug 2000 15:07:36 -0400 (EDT) Received: (qmail 32045 invoked from network); 18 Aug 2000 19:07:34 -0000 Received: from nat-external.ultradns.net (HELO ULTRADNS6PMNFK) (216.15.7.195) by mail.ultradns.com with SMTP; 18 Aug 2000 19:07:34 -0000 From: "Barr Hibbs" To: DHCPv4 discussion list Subject: RE: Authentication option Date: Fri, 18 Aug 2000 12:07:42 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400 In-reply-to: <4.3.1.2.20000817231719.00b074f0@funnel.cisco.com> Importance: Normal Reply-To: rbhibbs@ultraDNS.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit > -----Original Message----- > From: Ralph Droms > Sent: Thursday, August 17, 2000 11:23 PM > > In the description of client behavior (section 5.5.1 of > draft-ietf-dhc-authentication-14.txt), the current draft > specifies that the client may not use any DHCPOFFER messages > that fail the authentication validation: > > 2. The client MUST validate any DHCPOFFER messages that include > authentication information using the mechanism specified in section > 5.3. The client MUST discard any messages which fail to pass > validation and MAY log the validation failure. The client selects one > DHCPOFFER message as its selected configuration. If none of the > DHCPOFFER messages received by the client include authentication > information, the client MAY choose an unauthenticated message as its > selected configuration. The client SHOULD be configurable to accept > or reject unauthenticated DHCPOFFER messages. > > I've received a suggestion that the use of DHCPOFFER messages that fail > validation should be a client policy; that is, a client should be allowed > to use those messages if, for instance, no DHCPOFFERs are received that > pass validation. Is it acceptable to the WG to make the suggested change? > ...my only concern about wording that permits this is that we may be permitting unsophisticated users to inadvertently open themselves to vulnerabilities: 1. bogus server sends offer that fails authentication 2. client accepts offer, with bogus gateway address 3. bogus gateway sniffs packets, captures plaintext passwords, forwards spam, etc. Maybe if the text which allows this to be a local policy included a clear warning of the risks and benefits of implementing it, and I suggest that instead of "The client SHOULD be configurable to accept or reject unauthenticated DHCPOFFER messages," the SHOULD be replaced with MAY. Perhaps something like, "Clients with accept unauthenticated DHCPOFFER messages MAY be unintentionally compromising their own security, or be participating in malicious behavior such as distributed denial of service attacks. Local administrators should very carefully consider all risks before permitting this client behavior." --Barr From owner-dhcp-v4@bucknell.edu Fri Aug 18 15:28:44 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05883 for ; Fri, 18 Aug 2000 15:28:44 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e7IJQBi05316; Fri, 18 Aug 2000 15:26:11 -0400 (EDT) Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e7IJQ3i27883 for ; Fri, 18 Aug 2000 15:26:03 -0400 (EDT) Received: from rtpmail02.raleigh.ibm.com (rtpmail02.raleigh.ibm.com [9.37.172.48]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id PAA21726; Fri, 18 Aug 2000 15:25:18 -0400 Received: from rotala.raleigh.ibm.com (root@rotala.raleigh.ibm.com [9.37.60.3]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id PAA23184; Fri, 18 Aug 2000 15:25:18 -0400 Received: from rotala.raleigh.ibm.com (IDENT:narten@localhost.localdomain [127.0.0.1]) by rotala.raleigh.ibm.com (8.9.3/8.7/RTP-ral-1.0) with ESMTP id PAA07635; Fri, 18 Aug 2000 15:24:54 -0400 Message-Id: <200008181924.PAA07635@rotala.raleigh.ibm.com> To: DHCPv4 discussion list cc: DHCPv4 discussion list Subject: Re: Authentication option In-Reply-To: Message from "Barr Hibbs" of "Fri, 18 Aug 2000 12:07:42 PDT." Date: Fri, 18 Aug 2000 15:24:54 -0400 From: Thomas Narten Reply-To: narten@raleigh.ibm.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN > ...my only concern about wording that permits this is that we may be > permitting unsophisticated users to inadvertently open themselves to > vulnerabilities: > 1. bogus server sends offer that fails authentication > 2. client accepts offer, with bogus gateway address > 3. bogus gateway sniffs packets, captures plaintext passwords, forwards > spam, etc. yep. One way to handle this is to say you probably shouldn't do this, here is why, the default configuration must be not to. But, the current wording in the spec doesn't prevent the above threat anyway, so I'm not sure that is the right wording either. The current wording in the ID says that its a violation of the authentication spec to use the information if it contains an authentication option AND you can't authenticate it (for whatever reason). This means if all the DHCPOFFERS include authentication options, and you can't verify the authentication, you're out of luck. The text does say, however, that in this case if there are packets with WITHOUT authentication options, you can use those (as a last resort). That seems a bit inconsistent, and wouldn't protect you against the above threat anyway. So I don't view this is lessoning overall security. Also, you want to allow clients to ignore the authentication option for backwards compatability with the deployed base. Thus outlawing this for new clients seems messed up too. Thomas From owner-dhcp-v4@bucknell.edu Fri Aug 18 19:58:43 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10838 for ; Fri, 18 Aug 2000 19:58:42 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e7INtmi25175; Fri, 18 Aug 2000 19:55:49 -0400 (EDT) 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 e7INtXi30742 for ; Fri, 18 Aug 2000 19:55:33 -0400 (EDT) Received: from rdroms-nt.cisco.com (rtp-dial-1-163.cisco.com [10.83.97.163]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id TAA20776 for ; Fri, 18 Aug 2000 19:55:15 -0400 (EDT) Message-Id: <4.3.1.2.20000818125409.00b03420@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Fri, 18 Aug 2000 16:04:00 -0700 To: DHCPv4 discussion list From: Ralph Droms Subject: WG last call for DHCP load balancing 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 This message announces a DHC WG last call for DHCP load balancing, . The WG discussed this revision in Pittsburgh and agreed to go to WG last call. Please forward any comments you may have on this draft to dhcp-v4@bucknell.edu by Friday, September 2. - Ralph Droms From owner-dhcp-v4@bucknell.edu Fri Aug 18 19:59:31 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10858 for ; Fri, 18 Aug 2000 19:59:31 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e7INusi02420; Fri, 18 Aug 2000 19:56:54 -0400 (EDT) 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 e7INuBi25776 for ; Fri, 18 Aug 2000 19:56:11 -0400 (EDT) Received: from rdroms-nt.bucknell.edu (rtp-dial-1-163.cisco.com [10.83.97.163]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id TAA20794; Fri, 18 Aug 2000 19:55:23 -0400 (EDT) Message-Id: <4.3.1.2.20000818115736.00af9ba0@mail.bucknell.edu> X-Sender: droms@mail.bucknell.edu X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Fri, 18 Aug 2000 15:11:26 -0700 To: DHCPv4 discussion list From: Ralph Droms Subject: Re: Unauthorized DHCP servers In-Reply-To: <8525693D.0051A00C.00@D51MTA04.pok.ibm.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 09:51 AM 8/16/00 -0500, hoyoung@us.ibm.com wrote: >I'm a little confused as for how a dhcp client decides to accept a reply >from legal and illegal servers. The protocol spec in RFC 2131/2132 does not provide for any authentication through which a client can differentiate between authorized and unauthorized servers. There is an authentication option that is very close to acceptance as a standard; see draft-ietf-dhc-authentication-14.txt for details. > It seems to me, in a case of an >unauthorized dhcp server on a local segment as the client, the client >always pick the NAK from the unauthorized server. Is it simply because of >distance/hops since the unauthorized server is on the same wire as the >client, while the authorized server is one or two hops away from the >client? If so, why the delta time shows that the client actually receives >the reply packets from the legal server first when I do a sniffer trace? Typically, a DHCP client will select the server whose response arrives first at the client. The response from a server on the same network segment will typically get back to the client before the response forwarded by a relay agent from a server on a different network. >Question: >In the case of the illegal server, since it's local to the client, would it >send unicast pack to the client or would it flood the reply message on to >the wire and let the client decide? An RFC2131-compliant server or relay agent will unicast the DHCPOFFER, using the client's link-layer address and the IP address offered by the server, unless the BROADCAST bit is set or the server or relay agent is unable to use unicast. >In the case of the legal server, since it's on a separate segment as the >client, it will unicast it's reply packet to the relay agent, the relay >agent then either unicast or broadcast to the client. Now how the relay >agent decide whether to unicast or broadcast the packet to the client? The relay agent uses the same rules described above for deciding between unicast and broadcast. When you use a network analyzer to grab the DHCP messages, are you seeing responses from both the authorized and unauthorized servers? Are those messages broadcast or unicast? - Ralph Droms From owner-dhcp-v4@bucknell.edu Fri Aug 18 21:34:06 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13352 for ; Fri, 18 Aug 2000 21:34:06 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e7J1VJi08009; Fri, 18 Aug 2000 21:31:19 -0400 (EDT) Received: from codex.cis.upenn.edu (CODEX.CIS.UPENN.EDU [158.130.6.15]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e7J1VGi07559; Fri, 18 Aug 2000 21:31:16 -0400 (EDT) Received: from localhost (waa@localhost) by codex.cis.upenn.edu (8.10.1/8.10.1) with ESMTP id e7J1VFS05921; Fri, 18 Aug 2000 21:31:16 -0400 (EDT) Date: Fri, 18 Aug 2000 21:31:15 -0400 (EDT) From: "William A. Arbaugh" To: DHCPv4 discussion list cc: DHCPv4 discussion list Subject: Re: Use of option 61 in DHCP authentication In-Reply-To: <4.3.1.2.20000817221341.00aec9f0@mail.bucknell.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: waa@dsl.cis.upenn.edu Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN I was trying for a unique id so that we could handle intra-domain at some point in the future. Given that the uuid is not an RFC though, I have no problems with saying option 61. I would like to caveat it by explaining to people it's good to use a unique. ----------------------------------------------------------------------- Bill Arbaugh email: waa@dsl.cis.upenn.edu web: http://www.cis.upenn.edu/~waa ----------------------------------------------------------------------- On Thu, 17 Aug 2000, Ralph Droms wrote: > Bill - rev -14 of the draft calls for the use of option 61 in > authentication protocol 1, with a reference an expired draft by Mike Henry, > "DHCP Option 61 UUID Type Definition" > , which defines the syntax for > expressing a UUID within option 61. > > I don't see where it's necessary to use the UUID form of identification, > unless you're trying to guarantee unique identification. Would it be > acceptable to change the draft to allow the use of any style of client > identifier in option 61? > > - Ralph > > From owner-dhcp-v4@bucknell.edu Fri Aug 18 21:34:58 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13419 for ; Fri, 18 Aug 2000 21:34:57 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e7J1YRi09295; Fri, 18 Aug 2000 21:34:27 -0400 (EDT) Received: from codex.cis.upenn.edu (CODEX.CIS.UPENN.EDU [158.130.6.15]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e7J1YDi16160 for ; Fri, 18 Aug 2000 21:34:13 -0400 (EDT) Received: from localhost (waa@localhost) by codex.cis.upenn.edu (8.10.1/8.10.1) with ESMTP id e7J1Xni05941; Fri, 18 Aug 2000 21:33:49 -0400 (EDT) Date: Fri, 18 Aug 2000 21:33:48 -0400 (EDT) From: "William A. Arbaugh" To: DHCPv4 discussion list cc: DHCPv4 discussion list Subject: Re: Authentication option In-Reply-To: <200008181519.LAA00484@grosse.bisbee.fugue.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: waa@dsl.cis.upenn.edu Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN On Fri, 18 Aug 2000, Ted Lemon wrote: > > I think this is right, except that there are actually at least two > ways validation can fail: it can fail because the client doesn't have > the key needed to validate, and it can fail because the client has the > key, and the signature doesn't check out. I don't know if it makes > sense to distinguish between these two cases, but perhaps it does - if > the signature doesn't check out, it probably means the client or > server is misconfigured, and should be fixed. > We should distinguish these cases as a policy may decide to proceed differently based on the failure mode. > Also, it's fairly axiomatic in the security world that if > authentication fails, you make it very clear to whomever is depending > on authentication that it has failed, and let them decide how to > proceed (unless you have just defaulted to not proceeding at all). It > would be bad to give the user the impression that everything's okay > when it's not. > Agreed. We had log the event. Perhaps we should make it stronger- inform user? From owner-dhcp-v4@bucknell.edu Mon Aug 21 10:08:05 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01129 for ; Mon, 21 Aug 2000 10:08:04 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e7LE3Mi08533; Mon, 21 Aug 2000 10:03:22 -0400 (EDT) Received: from e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.104]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e7LE37i24836; Mon, 21 Aug 2000 10:03:08 -0400 (EDT) Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e4.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id KAA83070; Mon, 21 Aug 2000 10:02:56 -0400 From: hoyoung@us.ibm.com Received: from D51MTA04.pok.ibm.com (d51mta04.pok.ibm.com [9.117.200.32]) by northrelay02.pok.ibm.com (8.8.8m3/NCO v4.93) with SMTP id KAA16136; Mon, 21 Aug 2000 10:03:04 -0400 Received: by D51MTA04.pok.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 85256942.004D2B49 ; Mon, 21 Aug 2000 10:02:53 -0400 X-Lotus-FromDomain: IBMUS To: DHCPv4 discussion list cc: DHCPv4 discussion list Message-ID: <85256942.004D2A25.00@D51MTA04.pok.ibm.com> Date: Mon, 21 Aug 2000 09:03:00 -0500 Subject: Re: Unauthorized DHCP servers Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Reply-To: hoyoung@us.ibm.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN >In the case of the legal server, since it's on a separate segment as the >client, it will unicast it's reply packet to the relay agent, the relay >agent then either unicast or broadcast to the client. Now how the relay >agent decide whether to unicast or broadcast the packet to the client? The relay agent uses the same rules described above for deciding between unicast and broadcast. When you use a network analyzer to grab the DHCP messages, are you seeing responses from both the authorized and unauthorized servers? Are those messages broadcast or unicast? - Ralph Droms -------------------------- I saw responses from both the authorized and unauthorized servers and they both were broadcast. And it seems to me that the NAK came from the unauthorized server arrived later then the ACK from the authorized server. But the client pickup the NAK from the unauthorized server anyway... That's really what confused me. Hannah From owner-dhcp-v6@bucknell.edu Mon Aug 21 13:14:57 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04834 for ; Mon, 21 Aug 2000 13:14:57 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e7LHB9i09389; Mon, 21 Aug 2000 13:11:10 -0400 (EDT) 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 e7LHAsi20905; Mon, 21 Aug 2000 13:10:54 -0400 (EDT) Received: from rdroms-nt.cisco.com (ch2-dhcp133-127.cisco.com [161.44.133.127]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id NAA20583; Mon, 21 Aug 2000 13:10:36 -0400 (EDT) Message-Id: <4.3.1.2.20000821130823.00af0880@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Mon, 21 Aug 2000 13:09:44 -0400 To: DHCPv6 discussion list From: Ralph Droms Subject: *DRAFT* meeting minutes 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 A draft of the minutes from the DHC WG meetings in Pittsburgh is available at http://www.dhcp.org/0007-minutes.html Please reveiw the minutes and reply to me by this Thursday, 8/24 if you have any additionas or corrections. - Ralph From owner-dhcp-v4@bucknell.edu Mon Aug 21 13:15:04 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04846 for ; Mon, 21 Aug 2000 13:15:04 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e7LHBTi01515; Mon, 21 Aug 2000 13:11:29 -0400 (EDT) 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 e7LHAsi20905; Mon, 21 Aug 2000 13:10:54 -0400 (EDT) Received: from rdroms-nt.cisco.com (ch2-dhcp133-127.cisco.com [161.44.133.127]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id NAA20583; Mon, 21 Aug 2000 13:10:36 -0400 (EDT) Message-Id: <4.3.1.2.20000821130823.00af0880@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Mon, 21 Aug 2000 13:09:44 -0400 To: DHCPv4 discussion list From: Ralph Droms Subject: *DRAFT* meeting minutes 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 A draft of the minutes from the DHC WG meetings in Pittsburgh is available at http://www.dhcp.org/0007-minutes.html Please reveiw the minutes and reply to me by this Thursday, 8/24 if you have any additionas or corrections. - Ralph From owner-dhcp-v6@bucknell.edu Mon Aug 21 17:03:56 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09428 for ; Mon, 21 Aug 2000 17:03:56 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e7LL0ri14060; Mon, 21 Aug 2000 17:00:53 -0400 (EDT) Received: from ztxmail02.ztx.compaq.com (ztxmail02.ztx.compaq.com [161.114.1.206]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e7LL0ki12757 for ; Mon, 21 Aug 2000 17:00:46 -0400 (EDT) Received: by ztxmail02.ztx.compaq.com (Postfix, from userid 12345) id 567143E27; Mon, 21 Aug 2000 16:00:31 -0500 (CDT) Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by ztxmail02.ztx.compaq.com (Postfix) with ESMTP id 8067311F4; Mon, 21 Aug 2000 16:00:30 -0500 (CDT) Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM) id QAA0000544911; Mon, 21 Aug 2000 16:58:32 -0400 (EDT) From: Jim Bound Message-Id: <200008212058.QAA0000544911@anw.zk3.dec.com> To: DHCPv6 discussion list Cc: reinhard.scholl@etsi.fr Subject: IPv6 ETSI Test Event Web Page Pointer Date: Mon, 21 Aug 2000 16:58:32 -0400 X-Mts: smtp 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 ** PLEASE DO NOT RESPOND TO THIS MAIL ** Hi Folks, Even though UNH cannot participate in this test event our colleagues under the guidance of Francis Dupont at ENST in France have come to the aid of IPv6 developers (thank you ENST and Francis) and working with Reihhard Scholl there will be an IPv6 test event Oct 2-6. I believe this is a very important event and vendors should really try to attend. Plus it is in a nice place "French Riviera" not that there won't be a lot of hard work done of course. This is serious stuff folks and 3GPP needs our support and this test event. Please see the following URL: http://www.etsi.org/bake-off regards and thanks for your support, /jim From owner-dhcp-v4@bucknell.edu Mon Aug 21 19:34:06 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11113 for ; Mon, 21 Aug 2000 19:34:06 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e7LNV6i23848; Mon, 21 Aug 2000 19:31:06 -0400 (EDT) Received: from mail.ultradns.com (mail.ultradns.net [64.41.145.150]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e7LNV0i05974 for ; Mon, 21 Aug 2000 19:31:00 -0400 (EDT) Received: (qmail 27430 invoked from network); 21 Aug 2000 23:30:59 -0000 Received: from nat-external.ultradns.net (HELO ULTRADNS6PMNFK) (216.15.7.195) by mail.ultradns.com with SMTP; 21 Aug 2000 23:30:59 -0000 From: "Barr Hibbs" To: DHCPv4 discussion list Subject: RE: Use of option 61 in DHCP authentication Date: Mon, 21 Aug 2000 16:31:35 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: Importance: Normal X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400 Reply-To: rbhibbs@ultraDNS.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit > -----Original Message----- > From: William A. Arbaugh > Sent: Friday, August 18, 2000 6:31 PM > > I was trying for a unique id so that we could handle intra-domain at some > point in the future. Given that the uuid is not an RFC though, I have no > problems with saying option 61. I would like to caveat it by explaining > to people it's good to use a unique. > ...I agree as to the goal of uniqueness for intra-domain authentication, and will look at all of these again to see if I can help with some suggested wording.... --Barr From owner-dhcp-v4@bucknell.edu Mon Aug 21 20:01:48 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11290 for ; Mon, 21 Aug 2000 20:01:48 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e7M01Fi24784; Mon, 21 Aug 2000 20:01:15 -0400 (EDT) Received: from mail.ultradns.com (mail.ultradns.net [64.41.145.150]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e7M014i18344 for ; Mon, 21 Aug 2000 20:01:04 -0400 (EDT) Received: (qmail 28574 invoked from network); 22 Aug 2000 00:01:03 -0000 Received: from nat-external.ultradns.net (HELO ULTRADNS6PMNFK) (216.15.7.195) by mail.ultradns.com with SMTP; 22 Aug 2000 00:01:03 -0000 From: "Barr Hibbs" To: DHCPv4 discussion list Subject: RE: Authentication option Date: Mon, 21 Aug 2000 17:01:39 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: Importance: Normal X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400 Reply-To: rbhibbs@ultraDNS.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit > -----Original Message----- > From: William A. Arbaugh > Sent: Friday, August 18, 2000 6:34 PM > > > [Ted Lemon] > > I think this is right, except that there are actually at least two > > ways validation can fail .... I don't know if it makes sense to > > distinguish between these two cases.... > > > [Bill Arbaugh] > We should distinguish these cases as a policy may decide to proceed > differently based on the failure mode. > ...damn! Ted always has such good comments! I agree with both assessments, and that we should identify this as an area where local policy and other implementation considerations are important. > > Also, it's fairly axiomatic in the security world that if > > authentication fails, you make it very clear to whomever is depending > > on authentication that it has failed, and let them decide how to > > proceed (unless you have just defaulted to not proceeding at all). It > > would be bad to give the user the impression that everything's okay > > when it's not. > > > Agreed. We had log the event. Perhaps we should make it stronger- inform > user? > ...again, this is an implementation and local policy matter, but I agree that the text should identify the responsibility of the implementor to provide unambiguous behavior. Informing the user is useful in many circumstances, but I've become wary of how to phrase things in an RFC -- for fear that suggestions become hard requirements, or desirable behavior ignored because of an imprecise specification of urgency. Again, I'll try to re-read these sections to find some suggested wording.... --Barr From owner-dhcp-v4@bucknell.edu Tue Aug 22 01:27:36 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18241 for ; Tue, 22 Aug 2000 01:27:35 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e7M5Oei23296; Tue, 22 Aug 2000 01:24:40 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e7M5OWi00198 for ; Tue, 22 Aug 2000 01:24:32 -0400 (EDT) Received: from grosse.bisbee.fugue.com (206-97-58-133.ip.theriver.com [206.97.58.133]) by toccata.fugue.com (8.9.3/8.6.11) with ESMTP id EAA24785; Mon, 21 Aug 2000 04:31:16 -0700 (PDT) Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.9.3+3.2W/8.6.11) with ESMTP id BAA00736; Tue, 22 Aug 2000 01:09:52 -0400 (EDT) Message-Id: <200008220509.BAA00736@grosse.bisbee.fugue.com> To: DHCPv4 discussion list cc: DHCPv4 discussion list Subject: Re: Authentication option In-Reply-To: Message from "William A. Arbaugh" of "Fri, 18 Aug 2000 21:33:48 -0400." Date: Mon, 21 Aug 2000 22:09:51 -0700 From: Ted Lemon Reply-To: mellon@nominum.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN > Agreed. We had log the event. Perhaps we should make it stronger- inform > user? Well, of course it's dependent on context - you can't warn the user if there is no user. But I think this is what we want if it's possible. I don't know how one might suggest this in the specification. _MelloN_ From owner-dhcp-v4@bucknell.edu Tue Aug 22 07:13:45 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01053 for ; Tue, 22 Aug 2000 07:13:45 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e7MB7Zi30126; Tue, 22 Aug 2000 07:07:35 -0400 (EDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e7MB7Pi05083 for ; Tue, 22 Aug 2000 07:07:25 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00761; Tue, 22 Aug 2000 07:07:24 -0400 (EDT) Message-Id: <200008221107.HAA00761@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-userclass-10.txt Date: Tue, 22 Aug 2000 07:07:23 -0400 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 User Class Option for DHCP Author(s) : G. Stump, R. Droms, Y. Gu, R. Vyaghrapuri, A. Demirtjis, B. Beser, J. Privat Filename : draft-ietf-dhc-userclass-10.txt Pages : 5 Date : 21-Aug-00 This option is used by a DHCP client to optionally identify the type or category of user or applications it represents. The information contained in this option is an opaque field that represents the user class of which the client is a member. Based on this class, a DHCP server selects the appropriate address pool to assign an address to the client and the appropriate configuration parameters. This option should be configurable by a user. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-userclass-10.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-userclass-10.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-userclass-10.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: <20000821135303.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-userclass-10.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-userclass-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000821135303.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-dhcp-v4@bucknell.edu Tue Aug 22 07:28:54 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01374 for ; Tue, 22 Aug 2000 07:28:54 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e7MBSKi15672; Tue, 22 Aug 2000 07:28:20 -0400 (EDT) Received: from hygro.adsl.duke.edu (IDENT:root@hygro.adsl.duke.edu [152.16.64.159]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e7MBSEi26814 for ; Tue, 22 Aug 2000 07:28:14 -0400 (EDT) Received: from hygro.adsl.duke.edu (IDENT:narten@localhost.localdomain [127.0.0.1]) by hygro.adsl.duke.edu (8.9.3/8.9.3) with ESMTP id GAA01423; Tue, 22 Aug 2000 06:26:26 -0400 Message-Id: <200008221026.GAA01423@hygro.adsl.duke.edu> To: DHCPv4 discussion list cc: DHCPv4 discussion list Subject: Re: Authentication option In-Reply-To: Message from Ted Lemon of "Mon, 21 Aug 2000 22:09:51 PDT." <200008220509.BAA00736@grosse.bisbee.fugue.com> Date: Tue, 22 Aug 2000 06:26:26 -0400 From: Thomas Narten Reply-To: narten@raleigh.ibm.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN > > Agreed. We had log the event. Perhaps we should make it stronger- inform > > user? > Well, of course it's dependent on context - you can't warn the user if > there is no user. But I think this is what we want if it's > possible. I don't know how one might suggest this in the > specification. >From RFC 2119, the definition of SHOULD: 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. In the case at hand, one could certain add a sentence pointing out that in some cases there may not be an easily identifiable user... Thomas From owner-dhcp-v4@bucknell.edu Tue Aug 22 08:24:59 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03080 for ; Tue, 22 Aug 2000 08:24:59 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e7MCKVi29960; Tue, 22 Aug 2000 08:20:31 -0400 (EDT) Received: from gandalf.axion.bt.co.uk (gandalf.axion.bt.co.uk [132.146.17.29]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e7MCKQi18348 for ; Tue, 22 Aug 2000 08:20:26 -0400 (EDT) Received: from cbtlipnt01.btlabs.bt.co.uk by gandalf (local) with ESMTP; Tue, 22 Aug 2000 13:19:03 +0100 Received: by cbtlipnt01.btlabs.bt.co.uk with Internet Mail Service (5.5.2651.88) id <3GLRLNYH>; Tue, 22 Aug 2000 13:19:07 +0100 Message-ID: <5104D4DBC598D211B5FE0000F8FE7EB207E8994B@mbtlipnt02.btlabs.bt.co.uk> From: jerome.privat@bt.com To: DHCPv4 discussion list Subject: FW: I-D ACTION:draft-ietf-dhc-userclass-10.txt Date: Tue, 22 Aug 2000 13:15:50 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.88) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C00C32.B6014AD0" Reply-To: jerome.privat@bt.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN ------_=_NextPart_000_01C00C32.B6014AD0 Content-type: text/plain; charset="iso-8859-1" I have updated the User Class draft to take into account IESG comments as previously agreed on this mailing list (changed parts are the introduction and the security section). Thomas: can this ID be considered again by the IESG? Jerome -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Sent: 22 August 2000 12:07 To: DHCPv4 discussion list Cc: dhcp-v4@bucknell.edu Subject: I-D ACTION:draft-ietf-dhc-userclass-10.txt 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 User Class Option for DHCP Author(s) : G. Stump, R. Droms, Y. Gu, R. Vyaghrapuri, A. Demirtjis, B. Beser, J. Privat Filename : draft-ietf-dhc-userclass-10.txt Pages : 5 Date : 21-Aug-00 This option is used by a DHCP client to optionally identify the type or category of user or applications it represents. The information contained in this option is an opaque field that represents the user class of which the client is a member. Based on this class, a DHCP server selects the appropriate address pool to assign an address to the client and the appropriate configuration parameters. This option should be configurable by a user. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-userclass-10.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-userclass-10.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-userclass-10.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_000_01C00C32.B6014AD0 Content-type: message/rfc822 To: Subject: Date: Tue, 22 Aug 2000 13:19:07 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.88) Content-Type: multipart/mixed; boundary="----_=_NextPart_002_01C00C32.B6014AD0" ------_=_NextPart_002_01C00C32.B6014AD0 Content-type: text/plain; charset="us-ascii" ------_=_NextPart_002_01C00C32.B6014AD0 Content-type: application/octet-stream; name="ATT75128" Content-Disposition: attachment; filename="ATT75128" Content-type: message/external-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000821135303.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-userclass-10.txt ------_=_NextPart_002_01C00C32.B6014AD0 Content-type: message/external-body; site="internet-drafts"; dir="draft-ietf-dhc-userclass-10.txt"; mode="ftp.ietf.org"; access-type="anon-ftp" ------_=_NextPart_002_01C00C32.B6014AD0-- ------_=_NextPart_000_01C00C32.B6014AD0-- From owner-dhcp-v4@bucknell.edu Tue Aug 22 11:24:56 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08406 for ; Tue, 22 Aug 2000 11:24:56 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e7MFM5i29564; Tue, 22 Aug 2000 11:22:05 -0400 (EDT) Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e7MFLwi04158 for ; Tue, 22 Aug 2000 11:21:58 -0400 (EDT) Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id LAA32504; Tue, 22 Aug 2000 11:21:39 -0400 Received: from rotala.raleigh.ibm.com (root@rotala.raleigh.ibm.com [9.37.60.3]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id LAA33760; Tue, 22 Aug 2000 11:21:40 -0400 Received: from rotala.raleigh.ibm.com (IDENT:narten@localhost.localdomain [127.0.0.1]) by rotala.raleigh.ibm.com (8.9.3/8.7/RTP-ral-1.0) with ESMTP id LAA14261; Tue, 22 Aug 2000 11:20:23 -0400 Message-Id: <200008221520.LAA14261@rotala.raleigh.ibm.com> To: DHCPv4 discussion list cc: dhcp-v4@bucknell.edu Subject: Re: FW: I-D ACTION:draft-ietf-dhc-userclass-10.txt In-Reply-To: Message from jerome.privat@bt.com of "Tue, 22 Aug 2000 13:15:50 BST." <5104D4DBC598D211B5FE0000F8FE7EB207E8994B@mbtlipnt02.btlabs.bt.co.uk> Date: Tue, 22 Aug 2000 11:20:23 -0400 From: Thomas Narten Reply-To: narten@raleigh.ibm.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN > I have updated the User Class draft to take into account IESG comments > as previously agreed on this mailing list (changed parts are the > introduction and the security section). > Thomas: can this ID be considered again by the IESG? Yes, and thanks for the update. Looking at the changes, I note a couple of things that may well provoke additional discussion within the IESG: > Abstract > > This option is used by a DHCP client to optionally identify the type > or category of user or applications it represents. > The information contained in this option is an opaque field that > represents the user class of which the client is a member. > Based on this class, a DHCP server selects the appropriate address > pool to assign an address to the client and the appropriate > configuration parameters. This last sentence again suggests that the address a DHCP server gives out may depend on the provided user class. > 4. User Class option > > This option is used by a DHCP client to optionally identify the type > or category of user or applications it represents. > A DHCP server uses the User Class option to choose the address pool > it allocates an address from and/or to select any other > configuration option. And again here. While I don't think this document should prohibit doing the above, suggesting that this be done also requires having more text discussing the issues of doing so (this lack of discussion of the related issues is one of the issues the IESG had with the previous ID). For example, if you are going to tie QOS policy to specific addresses, there needs to be some sort of coordination between DHCP and the routers. This should be discussed somewhere. Also, since QOS has tangible value to end users, suitable protections are needed to ensure proper authentication. This should be discussed in more detail in the security considerations section. Note that in the case of giving out the "wrong" set of printers addresses to a client that uses the wrong user class identifier, there don't appear to be any serious implications. But if you give out the wrong address, the issues would appear to be quite different. Thomasp From owner-dhcp-v4@bucknell.edu Tue Aug 22 12:35:08 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10323 for ; Tue, 22 Aug 2000 12:35:08 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e7MGWEi14764; Tue, 22 Aug 2000 12:32:14 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e7MGW7i28144 for ; Tue, 22 Aug 2000 12:32:07 -0400 (EDT) Received: from grosse.bisbee.fugue.com (206-97-58-142.ip.theriver.com [206.97.58.142]) by toccata.fugue.com (8.9.3/8.6.11) with ESMTP id PAA25797; Mon, 21 Aug 2000 15:38:50 -0700 (PDT) Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.9.3+3.2W/8.6.11) with ESMTP id JAA00472; Tue, 22 Aug 2000 09:30:06 -0700 (MST) Message-Id: <200008221630.JAA00472@grosse.bisbee.fugue.com> To: DHCPv4 discussion list cc: DHCPv4 discussion list Subject: Re: FW: I-D ACTION:draft-ietf-dhc-userclass-10.txt In-Reply-To: Message from Thomas Narten of "Tue, 22 Aug 2000 11:20:23 -0400." <200008221520.LAA14261@rotala.raleigh.ibm.com> Date: Tue, 22 Aug 2000 09:30:05 -0700 From: Ted Lemon Reply-To: mellon@nominum.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN > > This option is used by a DHCP client to optionally identify the type > > or category of user or applications it represents. > > The information contained in this option is an opaque field that > > represents the user class of which the client is a member. > > Based on this class, a DHCP server selects the appropriate address > > pool to assign an address to the client and the appropriate > > configuration parameters. > This last sentence again suggests that the address a DHCP server gives > out may depend on the provided user class. Maybe I'm being a space cadet here, but why is this a problem? The IP address the server gives out also depends on the DHCP Requested Address option in some cases! It's perfectly reasonable for the client to request things, and what the server does depends on policy. What is it about this that needs to be fixed? Maybe the thing we want is to say that the client can "request" variations in how it is treated based on the user class option, and that whether or not the server honors these requests, and how, is a decision that should be left up to the server administrator. _MelloN_ From owner-dhcp-v4@bucknell.edu Tue Aug 22 12:49:55 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10512 for ; Tue, 22 Aug 2000 12:49:55 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e7MGnHi22919; Tue, 22 Aug 2000 12:49:17 -0400 (EDT) Received: from lukla.Sun.COM (lukla.Sun.COM [192.18.98.31]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e7MGnEi13486 for ; Tue, 22 Aug 2000 12:49:14 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA03757; Tue, 22 Aug 2000 10:49:12 -0600 (MDT) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id KAA10011; Mon, 21 Aug 2000 10:03:04 -0700 (PDT) Received: from sunray-mpkd (sunray-mpkd [129.146.6.31]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id KAA22788; Mon, 21 Aug 2000 10:02:18 -0700 (PDT) Message-Id: <200008211702.KAA22788@nasnfs.eng.sun.com> Date: Mon, 21 Aug 2000 10:02:19 -0700 (PDT) From: Vipul Gupta Reply-To: Vipul Gupta Subject: Re: Use of option 61 in DHCP authentication To: DHCPv4 discussion list Cc: Vipul.Gupta@eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: RdK9cQ9zAM/Pt6kTQbFZWw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.5 SunOS 5.7 sun4u sparc Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN As an example of a unique id, how about referencing the Network Access Identifier (NAI) defined in RFC 2486? This is already used to identify PPP users uniquely when they roam across domains. The draft at http://playground.sun.com/~vgupta/draft-gupta-dhcp-auth-01.txt which describes public-key based DHCP authentication also shows how the NAI may be passed in option 61 to identify DHCP clients that roam across multiple domains. regards, vipul > I was trying for a unique id so that we could handle intra-domain at some > point in the future. Given that the uuid is not an RFC though, I have no > problems with saying option 61. I would like to caveat it by explaining > to people it's good to use a unique. > > ----------------------------------------------------------------------- > Bill Arbaugh > email: waa@dsl.cis.upenn.edu > web: http://www.cis.upenn.edu/~waa > ----------------------------------------------------------------------- > > On Thu, 17 Aug 2000, Ralph Droms wrote: > > > Bill - rev -14 of the draft calls for the use of option 61 in > > authentication protocol 1, with a reference an expired draft by Mike Henry, > > "DHCP Option 61 UUID Type Definition" > > , which defines the syntax for > > expressing a UUID within option 61. > > > > I don't see where it's necessary to use the UUID form of identification, > > unless you're trying to guarantee unique identification. Would it be > > acceptable to change the draft to allow the use of any style of client > > identifier in option 61? > > > > - Ralph > > > > > From owner-dhcp-v4@bucknell.edu Tue Aug 22 12: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 ESMTP id MAA10597 for ; Tue, 22 Aug 2000 12:53:13 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e7MGqai10697; Tue, 22 Aug 2000 12:52:37 -0400 (EDT) Received: from gandalf.axion.bt.co.uk (gandalf.axion.bt.co.uk [132.146.17.29]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e7MGqNi19042 for ; Tue, 22 Aug 2000 12:52:23 -0400 (EDT) Received: from cbtlipnt01.btlabs.bt.co.uk by gandalf (local) with ESMTP; Tue, 22 Aug 2000 17:51:30 +0100 Received: by cbtlipnt01.btlabs.bt.co.uk with Internet Mail Service (5.5.2651.88) id <3GLRLYRR>; Tue, 22 Aug 2000 17:51:35 +0100 Message-ID: <5104D4DBC598D211B5FE0000F8FE7EB207E89950@mbtlipnt02.btlabs.bt.co.uk> From: jerome.privat@bt.com To: DHCPv4 discussion list Subject: RE: FW: I-D ACTION:draft-ietf-dhc-userclass-10.txt Date: Tue, 22 Aug 2000 17:48:20 +0100 X-Mailer: Internet Mail Service (5.5.2651.88) MIME-version: 1.0 Content-type: text/plain; charset="iso-8859-1" Reply-To: jerome.privat@bt.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Thomas, Would the following changes make the ID more acceptable by the IESG?: > Abstract > > This option is used by a DHCP client to optionally identify the type > or category of user or applications it represents. > The information contained in this option is an opaque field that > represents the user class of which the client is a member. > Based on this class, a DHCP server selects the appropriate address > pool to assign an address to the client and the appropriate > configuration parameters. would become Abstract This option is used by a DHCP client to optionally identify the type or category of user or applications it represents. The information contained in this option is an opaque field that represents the user class of which the client is a member. A DHCP server may, based on its administrator policy, use this class to select the configuration parameters it returns to the client. and > 4. User Class option > > This option is used by a DHCP client to optionally identify the type > or category of user or applications it represents. > A DHCP server uses the User Class option to choose the address pool > it allocates an address from and/or to select any other > configuration option. would become This option is used by a DHCP client to optionally identify the type or category of user or applications it represents. A DHCP server may, based on its administrator policy, use the User Class option to select the configuration parameters it returns to the client. Jerome -----Original Message----- From: Ted Lemon [mailto:mellon@nominum.com] Sent: 22 August 2000 17:30 To: DHCPv4 discussion list Cc: DHCPv4 discussion list Subject: Re: FW: I-D ACTION:draft-ietf-dhc-userclass-10.txt > > This option is used by a DHCP client to optionally identify the type > > or category of user or applications it represents. > > The information contained in this option is an opaque field that > > represents the user class of which the client is a member. > > Based on this class, a DHCP server selects the appropriate address > > pool to assign an address to the client and the appropriate > > configuration parameters. > This last sentence again suggests that the address a DHCP server gives > out may depend on the provided user class. Maybe I'm being a space cadet here, but why is this a problem? The IP address the server gives out also depends on the DHCP Requested Address option in some cases! It's perfectly reasonable for the client to request things, and what the server does depends on policy. What is it about this that needs to be fixed? Maybe the thing we want is to say that the client can "request" variations in how it is treated based on the user class option, and that whether or not the server honors these requests, and how, is a decision that should be left up to the server administrator. _MelloN_ From owner-dhcp-v4@bucknell.edu Tue Aug 22 12:57:18 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10664 for ; Tue, 22 Aug 2000 12:57:17 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e7MGuPi23407; Tue, 22 Aug 2000 12:56:25 -0400 (EDT) Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e7MGu8i16398 for ; Tue, 22 Aug 2000 12:56:08 -0400 (EDT) Received: from rtpmail01.raleigh.ibm.com (rtpmail01.raleigh.ibm.com [9.37.172.24]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id MAA32500; Tue, 22 Aug 2000 12:55:49 -0400 Received: from rotala.raleigh.ibm.com (root@rotala.raleigh.ibm.com [9.37.60.3]) by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id MAA25868; Tue, 22 Aug 2000 12:55:50 -0400 Received: from rotala.raleigh.ibm.com (IDENT:narten@localhost.localdomain [127.0.0.1]) by rotala.raleigh.ibm.com (8.9.3/8.7/RTP-ral-1.0) with ESMTP id MAA14772; Tue, 22 Aug 2000 12:54:34 -0400 Message-Id: <200008221654.MAA14772@rotala.raleigh.ibm.com> To: DHCPv4 discussion list cc: DHCPv4 discussion list Subject: Re: FW: I-D ACTION:draft-ietf-dhc-userclass-10.txt In-Reply-To: Message from Ted Lemon of "Tue, 22 Aug 2000 09:30:05 PDT." <200008221630.JAA00472@grosse.bisbee.fugue.com> Date: Tue, 22 Aug 2000 12:54:34 -0400 From: Thomas Narten Reply-To: narten@raleigh.ibm.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN > Maybe I'm being a space cadet here, but why is this a problem? The > IP address the server gives out also depends on the DHCP Requested > Address option in some cases! Hmm. What is the purpose of that option? Without knowing the history, I would think that option is to tell the server, "hey I was using address X before, if its OK with you, I'd like to get it again". Or something like that. The general issue is that clients shouldn't care what addresses they get. I.e., any address should work. Anytime the DHCP server uses something like the client ID to influence what address is given out, the implication is that different addresses are used in different ways (e.g., have different QOS, can punch through firewalls, are in access control lists for services, etc.) But now the DHCP server needs to be much more tightly coupled with other parts of the infrastructure (e.g., routers, firewalls, etc.) The current (and previous ID) says absolutely nothing about this bigger issue. What some of the IESG objected to was the implication that the ID suggested using the client ID to assign addresses that had special characteristics associated with it *without* discussing in a fair amount of detail the implication of all this. For example, if a site was using diffserv, how do the packets from address X get mapped into special diffserv PHBs? > It's perfectly reasonable for the client to request things, and what > the server does depends on policy. What is it about this that needs > to be fixed? This isn't the issue. Its the implication on other parts of the infrastructure beyound DHCP that are implied by having different classes of addresses a DHCP server is handing out. > Maybe the thing we want is to say that the client can "request" > variations in how it is treated based on the user class option, and > that whether or not the server honors these requests, and how, is a > decision that should be left up to the server administrator. If I understand "how it is treated" to mean that some clients get different service than others, then we heading in the problematical direction. It is not DHCP's job to regulate what kind of service a client gets. Its DHCP's job just to configure the client with necessary parameters. Hope this helps clarify things a bit more. Thomas From owner-dhcp-v4@bucknell.edu Tue Aug 22 13:01:31 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10848 for ; Tue, 22 Aug 2000 13:01:30 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e7MH0vi17639; Tue, 22 Aug 2000 13:00:57 -0400 (EDT) Received: from mail.ultradns.com (mail.ultradns.net [64.41.145.150]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e7MH0ti17734 for ; Tue, 22 Aug 2000 13:00:55 -0400 (EDT) Received: (qmail 5642 invoked from network); 22 Aug 2000 17:00:50 -0000 Received: from nat-external.ultradns.net (HELO ULTRADNS6PMNFK) (216.15.7.195) by mail.ultradns.com with SMTP; 22 Aug 2000 17:00:50 -0000 From: "Barr Hibbs" To: DHCPv4 discussion list Subject: RE: FW: I-D ACTION:draft-ietf-dhc-userclass-10.txt Date: Tue, 22 Aug 2000 10:00:50 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <200008221630.JAA00472@grosse.bisbee.fugue.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Reply-To: rbhibbs@ultraDNS.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit > -----Original Message----- > From: Ted Lemon > Sent: Tuesday, August 22, 2000 9:30 AM > [Jerome Privat] > > > Based on this class, a DHCP server selects the appropriate address > > > pool to assign an address to the client and the appropriate > > > configuration parameters. [Thomas Narten] > > This last sentence again suggests that the address a DHCP server gives > > out may depend on the provided user class. > [Ted Lemon] > Maybe I'm being a space cadet here, but why is this a problem? The > IP address the server gives out also depends on the DHCP Requested > Address option in some cases! It's perfectly reasonable for the > client to request things, and what the server does depends on policy. > What is it about this that needs to be fixed? > > Maybe the thing we want is to say that the client can "request" > variations in how it is treated based on the user class option, and > that whether or not the server honors these requests, and how, is a > decision that should be left up to the server administrator. > ...Agreed! Thomas: I don't think I'm missing the point here, but am open to corrections if I am -- the entire purpose of such options as the Vendor Class Identifier and User Class Identifier is to provide the server with additional information that the server may use to determine (1) which IP address to offer the client, and (2) which option values are returned in the offer. So, where is the problem with the wording in draft 10? --Barr From owner-dhcp-v4@bucknell.edu Tue Aug 22 13:49:46 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11839 for ; Tue, 22 Aug 2000 13:49:45 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e7MHkUi30864; Tue, 22 Aug 2000 13:46:30 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e7MHkLi01653 for ; Tue, 22 Aug 2000 13:46:21 -0400 (EDT) Received: from grosse.bisbee.fugue.com (206-97-58-142.ip.theriver.com [206.97.58.142]) by toccata.fugue.com (8.9.3/8.6.11) with ESMTP id QAA25941; Mon, 21 Aug 2000 16:51:34 -0700 (PDT) Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.9.3+3.2W/8.6.11) with ESMTP id KAA00577; Tue, 22 Aug 2000 10:42:49 -0700 (MST) Message-Id: <200008221742.KAA00577@grosse.bisbee.fugue.com> To: DHCPv4 discussion list cc: DHCPv4 discussion list Subject: Re: FW: I-D ACTION:draft-ietf-dhc-userclass-10.txt In-Reply-To: Message from Thomas Narten of "Tue, 22 Aug 2000 12:54:34 -0400." <200008221654.MAA14772@rotala.raleigh.ibm.com> Date: Tue, 22 Aug 2000 10:42:49 -0700 From: Ted Lemon Reply-To: mellon@nominum.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN > Hmm. What is the purpose of that option? Without knowing the history, > I would think that option is to tell the server, "hey I was using > address X before, if its OK with you, I'd like to get it again". Or > something like that. Yup. But it's an unsubstantiated claim, and typically the DHCP server doesn't check it. As long as the DHCP server has proper access control checks, this isn't a problem. > The general issue is that clients shouldn't care what addresses they > get. I.e., any address should work. Anytime the DHCP server uses > something like the client ID to influence what address is given out, > the implication is that different addresses are used in different ways > (e.g., have different QOS, can punch through firewalls, are in access > control lists for services, etc.) But now the DHCP server needs to be > much more tightly coupled with other parts of the infrastructure > (e.g., routers, firewalls, etc.) The current (and previous ID) says > absolutely nothing about this bigger issue. Hm. The example that I gave when I wrote up the User Class option in the DHCP Handbook (I think we deleted this because the option had been delayed (!)) was that you could configure clients to say whether or not they were in a certain department. For example, say you have a sales department, an engineering department, and an accounting department. These departments mostly exchange traffic with each other. You have all three departments on one wire, but each has a different IP subnet. Each department has its own printers, name servers, and so on. This is all handled with smart switches, so performance isn't an issue - as the network administrator, you don't want to have to constantly be switching wires around to keep one department on one subnet and another on another as people move around. There is no security issue here - it's not that sales isn't *allowed* on engineering's net - in fact, there is really only one net, with three virtual subnets that are seperated only by smart switches, so it would be trivial to get on the wrong net without any interaction with the DHCP server at all. It's just more convenient if everybody gets on the net they're supposed to be on. In this case, there is no QoS issue - it's simply a matter of convenience and consistency. This is not to say that nobody has ever talked about QoS, but this isn't why I wanted the option, and I don't think it's why most people want the option. The fact is that *any* option that uniquely identifies a client or can be used to classify a client can also be used to set up a completely insecure ad-hoc QoS system. I know, because I have customers doing it now, e.g. with the circuit ID sent back in the relay agent information option. That doesn't mean the circuit ID suboption is designed to be used for determining QoS, and it certainly doesn't mean that it *should* be used that way, or that that is its best use. _MelloN_ From owner-dhcp-v4@bucknell.edu Tue Aug 22 15:05:10 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13484 for ; Tue, 22 Aug 2000 15:05:10 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e7MJ1Gi31591; Tue, 22 Aug 2000 15:01:16 -0400 (EDT) Received: from mail.ultradns.com (mail.ultradns.net [64.41.145.150]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e7MJ1Fi09073 for ; Tue, 22 Aug 2000 15:01:15 -0400 (EDT) Received: (qmail 8217 invoked from network); 22 Aug 2000 19:01:14 -0000 Received: from nat-external.ultradns.net (HELO ULTRADNS6PMNFK) (216.15.7.195) by mail.ultradns.com with SMTP; 22 Aug 2000 19:01:14 -0000 From: "Barr Hibbs" To: DHCPv4 discussion list Subject: RE: FW: I-D ACTION:draft-ietf-dhc-userclass-10.txt Date: Tue, 22 Aug 2000 12:01:14 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <200008221654.MAA14772@rotala.raleigh.ibm.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Reply-To: rbhibbs@ultraDNS.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit > -----Original Message----- > From: Thomas Narten > Sent: Tuesday, August 22, 2000 9:55 AM > [Thomas Narten] > The general issue is that clients shouldn't care what addresses they > get. I.e., any address should work. Anytime the DHCP server uses > something like the client ID to influence what address is given out, > the implication is that different addresses are used in different ways > (e.g., have different QOS, can punch through firewalls, are in access > control lists for services, etc.) But now the DHCP server needs to be > much more tightly coupled with other parts of the infrastructure > (e.g., routers, firewalls, etc.) The current (and previous ID) says > absolutely nothing about this bigger issue. > ...true, the draft doesn't say anything at all about that, but we've been doing things like that for years in commercial use: giving clients an IP address from a specific pool based on their user characteristics, but without a class identifier to guide us, using what was available, usually the source subnet. To pretend that administrators and server implementors have never done this before and that unless it is discussed in a larger context this draft is somehow suspect is being pedantic, and completely misses the point that as networks become more complex, policy-based management rises in importance. In order to build policy mechanisms it is essential that administrators and implementors have as many bits of information as possible to enable intelligent policy decisions. [Thomas Narten] > What some of the IESG objected to was the implication that the ID > suggested using the client ID to assign addresses that had special > characteristics associated with it *without* discussing in a fair > amount of detail the implication of all this. > ...let's extend this argument a bit, stretching perhaps, to see where it might lead: if the DHCP server can't use every bit of information supplied to it by a client, or learned somehow from the environment or configuration data, to select an IP address to offer the client because that MIGHT overlap with other protocols such as differentiated services, policy management, or configuration using SNMP, then the IESG is effectively saying that local administrators CANNOT use DHCP to apply locally-determined policies to their own client population, but MUST wait for the jihad between the warring camps to end, the dust settle, and the winner to arise? I'm sorry, Thomas, but that is not reasonable. This really isn't an attempt to carve out a piece of the other WGs' charters, but a very practical way to differentiate among differing classes into which clients may be classified. If we can't use User Class Identifier to influence the server's choice of parameters to offer a client, why don't we also strike out Vendor Class Identifier? By this argument against User Classes, ANY parameter that MIGHT reflect a differentiation of service should be prohibited -- I'm thinking Default WWW Server and similar options, which certainly provide administrators a way to give different groups of their users different levels of service for web browsing and such. [Ted Lemon] > > It's perfectly reasonable for the client to request things, and what > > the server does depends on policy. What is it about this that needs > > to be fixed? > [Thomas Narten] > This isn't the issue. Its the implication on other parts of the > infrastructure beyound DHCP that are implied by having different > classes of addresses a DHCP server is handing out. > ...Jeez! That's always been true, even if we've never said it out loud before. I can influence apparent response time to a client simply by giving them a "distant" and slow name server -- a selection based on any data available to me when the client requests an address lease. Or, instead of giving someone a gateway address through a high-speed router, I could point them to one running on a 33 Mhz 80486. [Ted Lemon] > > Maybe the thing we want is to say that the client can "request" > > variations in how it is treated based on the user class option, and > > that whether or not the server honors these requests, and how, is a > > decision that should be left up to the server administrator. > [Thomas Narten] > If I understand "how it is treated" to mean that some clients get > different service than others, then we heading in the problematical > direction. It is not DHCP's job to regulate what kind of service a > client gets. Its DHCP's job just to configure the client with necessary > parameters. > ...If "necessary" were the complete criteria, I'd venture that at least half of the DHCP options would not exist. "Useful" has always been a better criteria, and the current state of the RFCs reflects much give and take, leaving us with a much richer set of options, many of which I suspect are NEVER used at all. It is useful to an administrator to be able to selectively assign networking parameters (IP address, gateways, name servers, etc.) based upon characteristics of their client population. If that were not the case, then why should we ever have allowed options like NFS parameters, which are not necessary to establish networking, but emininently useful, to be defined? The IESG can demand specific wording, and even insist that no variation in offered configuration parameters is permitted unless differentiated services is implemented (for example), but I doubt that would change any existing server implementation, making such a position irrelevant. --Barr From owner-dhcp-v4@bucknell.edu Tue Aug 22 15:16:49 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13797 for ; Tue, 22 Aug 2000 15:16:49 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e7MJGCi12279; Tue, 22 Aug 2000 15:16:12 -0400 (EDT) Received: from honts308.wal-mart.com (honts308.wal-mart.com [146.132.234.38]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e7MJG6i17557 for ; Tue, 22 Aug 2000 15:16:06 -0400 (EDT) Received: from fwnts001.wal-mart.com ([146.132.235.8]) by honts308.wal-mart.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id Q0K89W9B; Tue, 22 Aug 2000 14:24:25 -0500 Received: from honts386.homeoffice.wal-mart.com by fwnts001.wal-mart.com via smtpd (for mailout.wal-mart.com [146.132.235.35]) with SMTP; 22 Aug 2000 19:15:50 UT Received: from honts305.homeoffice.wal-mart.com (unverified) by honts386.homeoffice.wal-mart.com (Content Technologies SMTPRS 4.1.5) with ESMTP id for ; Tue, 22 Aug 2000 14:10:06 -0500 Received: by HONTS305.homeoffice.wal-mart.com with Internet Mail Service (5.5.2650.21) id ; Tue, 22 Aug 2000 14:15:50 -0500 Message-ID: From: Nathan Lane To: DHCPv4 discussion list Subject: RE: FW: I-D ACTION:draft-ietf-dhc-userclass-10.txt Date: Tue, 22 Aug 2000 14:15:45 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="ISO-8859-1" Reply-To: ndlane@wal-mart.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN [Thomas Narten] > Hmm. What is the purpose of that option? Without knowing the history, > I would think that option is to tell the server, "hey I was using > address X before, if its OK with you, I'd like to get it again". Or > something like that. > > The general issue is that clients shouldn't care what addresses they > get. I.e., any address should work. While I'd really, really like to believe this, it doesn't work that way now because of things like 1918 addressing, roaming clients, NAT, etc. Any address should work; but for what? An autoconfiguration IP will work on the local subnet with the specific prohibition that it never be routed past the local subnet boundary. A 1918 address will work within an enterprise, but not without. There must be a way for us to convey this information to the addressing server for appropriate selection. > Anytime the DHCP server uses > something like the client ID to influence what address is given out, > the implication is that different addresses are used in different ways [...] The current (and previous ID) says > absolutely nothing about this bigger issue. > Agreed; there is a much larger issue here that I feel should be addressed. As to whether or not this is the appropriate forum is the point, isn't it? When it comes down to the core of the issue, addresses are being overloaded to mean different things from different perspectives of the network. While our lives would be made much easier if an address were simply a 32-bit integer, they are not. We do not have guaranteed end-to-end connectivity anymore; the intelligence is both in the end point and the network. Should this issue be addressed in this draft? The last time this came up in July, I believe the consensus was to remove references to address selection; I had also proposed that an IP address be considered an "option" that could be selected by the DHCP server, though that may not be explicitly correct. Address selection in DHCP itself is only very loosely codified. Also I noted that many people are using every bit of information they can get from a client to determine what to do with them. [Thomas Narten] > What some of the IESG objected to was the implication that the ID > suggested using the client ID to assign addresses that had special > characteristics associated with it *without* discussing in a fair > amount of detail the implication of all this. For example, if a site > was using diffserv, how do the packets from address X get mapped into > special diffserv PHBs? > In product implementations I've seen these days there is a tremendous amount of heuristics going on to "fake state with stateless packets", label flows, "differentiate" service, etc. None of these products interoperate in any usable fashion, hence the great increase in single vendor hardware and software shops. The issue Thomas brings up is large, much larger than the DHCP option we are discussing. [Thomas Narten] > If I understand "how it is treated" to mean that some clients get > different service than others, then we heading in the problematical > direction. It is not DHCP's job to regulate what kind of service a > client gets. Its DHCP's job just to configure the client with necessary > parameters. > Correct me if I'm wrong, but aren't "necessary parameters" the parameters that give the client the services that they need? How do we then tell the client to modify those parameters once the services they need are no longer located where they once were or have changed function? Is there an overall, standardized mechanism for determining client service levels? Most of the ones I have seen are not widely implemented and bring up even larger issues (such as who controls the network? Is the network smart and the endpoints stupid or vice versa?) It's beginning to look like we may need a larger framework than just DHCP for configuring clients but there are major disagreements as to how to go about this. -Nathan Lane ********************************************************************** This email and any files transmitted with it are confidential and intended solely for the individual or entity to whom they are addressed. If you have received this email in error destroy it immediately. ********************************************************************** From owner-dhcp-v4@bucknell.edu Tue Aug 22 16:58:54 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15761 for ; Tue, 22 Aug 2000 16:58:54 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e7MKtwi22262; Tue, 22 Aug 2000 16:55:58 -0400 (EDT) Received: from honts307.wal-mart.com (honts307.wal-mart.com [146.132.234.37]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e7MKtmi18258 for ; Tue, 22 Aug 2000 16:55:49 -0400 (EDT) Received: from fwnts001.wal-mart.com ([146.132.235.8]) by honts307.wal-mart.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id QJAYY8WY; Tue, 22 Aug 2000 16:00:34 -0500 Received: from honts386.homeoffice.wal-mart.com by fwnts001.wal-mart.com via smtpd (for mailout.wal-mart.com [146.132.235.35]) with SMTP; 22 Aug 2000 20:55:15 UT Received: from honts305.homeoffice.wal-mart.com (unverified) by honts386.homeoffice.wal-mart.com (Content Technologies SMTPRS 4.1.5) with ESMTP id for ; Tue, 22 Aug 2000 15:49:29 -0500 Received: by HONTS305.homeoffice.wal-mart.com with Internet Mail Service (5.5.2650.21) id ; Tue, 22 Aug 2000 15:55:12 -0500 Message-ID: From: Nathan Lane To: DHCPv4 discussion list Subject: RE: Use of option 61 in DHCP authentication Date: Tue, 22 Aug 2000 15:54:27 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Reply-To: ndlane@wal-mart.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN [Barr Hibbs] > if there is consensus that we need to improve the uniqueness of > the client identifier to be more "universal" for authentication and other > purposes, let's just tackle that issue directly. > While I see a need for a globally unique identifier, we need to be careful with scoping conflicts with other protocols. The current scope for uniqueness on option 61 is "within the [undefined] administrative domain". We would have to codify the scope and subject it interaction with other administratively defined scopes. However, the authentication server's scope is likely to be larger than the DHCP server's, at least in many implementations I know of. Therefore, we would need to codify the scope and subject it to interaction. -Nathan ********************************************************************** This email and any files transmitted with it are confidential and intended solely for the individual or entity to whom they are addressed. If you have received this email in error destroy it immediately. ********************************************************************** From owner-dhcp-v4@bucknell.edu Tue Aug 22 17:23:34 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16100 for ; Tue, 22 Aug 2000 17:23:34 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e7MLN4i17176; Tue, 22 Aug 2000 17:23:04 -0400 (EDT) Received: from mail.ultradns.com (mail.ultradns.net [64.41.145.150]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e7MLLai02477 for ; Tue, 22 Aug 2000 17:21:36 -0400 (EDT) Received: (qmail 11047 invoked from network); 22 Aug 2000 21:21:34 -0000 Received: from nat-external.ultradns.net (HELO ULTRADNS6PMNFK) (216.15.7.195) by mail.ultradns.com with SMTP; 22 Aug 2000 21:21:34 -0000 From: "Barr Hibbs" To: DHCPv4 discussion list Subject: RE: Authentication option Date: Tue, 22 Aug 2000 14:21:34 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Reply-To: rbhibbs@ultraDNS.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit Bill et al., I promised to try my hand at some text to cover the point about notification of the user, so, here goes! --Barr =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- =-=-=-= 5.5.1 INIT state When in INIT state, the client uses protocol 1 as follows: 1. The client MUST include the authentication request option in its DHCPDISCOVER message along with option 61 [6] to identify itself uniquely to the server. 2. The client MUST validate any DHCPOFFER messages that include authentication information using the mechanism specified in section 5.3. The client MUST discard any messages which fail ***** to pass validation and MAY [SHOULD??] log the validation failure. The client selects one DHCPOFFER message as its selected configuration. If none of the DHCPOFFER messages received by the client include authentication information, the client MAY choose an unauthenticated message as its selected configuration. The client SHOULD be configurable to accept or ***** reject unauthenticated DHCPOFFER messages. The client SHOULD ***** log the acceptance of an unauthenticated message if it decides ***** to choose one. 3. The client replies with a DHCPREQUEST message that MUST include authentication information encoded with the same secret used by the server in the selected DHCPOFFER message. 4. The client MUST validate the DHCPACK message from the server. The client MUST discard the DHCPACK if the message fails to pass validation and MAY log the validation failure. If the DHCPACK fails to pass validation, the client MUST revert to INIT state and returns to step 1. The client MAY choose to remember which server replied with a DHCPACK message that failed to pass validation and discard subsequent messages from ***** that server. If the client chooses to remember a failed ***** message authentication, it SHOULD log that decision, and ***** SHOULD revert to normal operation with respect to that server ***** after receiving a properly authenticated message from that server. 5.5.2 INIT-REBOOT state When in INIT-REBOOT state, the client MUST use the secret it used in its DHCPREQUEST message to obtain its current configuration to generate authentication information for the DHCPREQUEST message. The client MAY choose to accept unauthenticated DHCPACK/DHCPNAK messages if no authenticated messages were received. The client MUST treat the receipt (or lack thereof) of any DHCPACK/DHCPNAK ***** messages as specified in section 3.2 of [1]. If the client chooses ***** to accept unauthenticated messages from a server, it SHOULD log that ***** decision. From owner-dhcp-v4@bucknell.edu Tue Aug 22 17:34:16 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16299 for ; Tue, 22 Aug 2000 17:34:15 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e7MLVgi30575; Tue, 22 Aug 2000 17:31:42 -0400 (EDT) Received: from mail.ultradns.com (mail.ultradns.net [64.41.145.150]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e7MLVci13379 for ; Tue, 22 Aug 2000 17:31:38 -0400 (EDT) Received: (qmail 11367 invoked from network); 22 Aug 2000 21:31:37 -0000 Received: from nat-external.ultradns.net (HELO ULTRADNS6PMNFK) (216.15.7.195) by mail.ultradns.com with SMTP; 22 Aug 2000 21:31:37 -0000 From: "Barr Hibbs" To: DHCPv4 discussion list Subject: RE: Use of option 61 in DHCP authentication Date: Tue, 22 Aug 2000 14:31:37 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Reply-To: rbhibbs@ultraDNS.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit > -----Original Message----- > From: Nathan Lane > Sent: Tuesday, August 22, 2000 1:54 PM > While I see a need for a globally unique identifier, we need to be > careful with scoping conflicts with other protocols. The current > scope for > uniqueness on option 61 is "within the [undefined] administrative domain". > We would have to codify the scope and subject it interaction with other > administratively defined scopes. > > However, the authentication server's scope is likely to be larger > than the DHCP server's, at least in many implementations I know of. > Therefore, we would need to codify the scope and subject it to > interaction. ...Agreed. I've just never been happy with the definition of option 61, so finding an opportunity to revisit it seemed fine to me! --Barr From owner-dhcp-v4@bucknell.edu Tue Aug 22 18:14:05 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16813 for ; Tue, 22 Aug 2000 18:14:04 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e7MM93i04614; Tue, 22 Aug 2000 18:09:03 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e7MM8si30047 for ; Tue, 22 Aug 2000 18:08:54 -0400 (EDT) Received: from grosse.bisbee.fugue.com (206-97-58-142.ip.theriver.com [206.97.58.142]) by toccata.fugue.com (8.9.3/8.6.11) with ESMTP id VAA26553 for ; Mon, 21 Aug 2000 21:15:32 -0700 (PDT) Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.9.3+3.2W/8.6.11) with ESMTP id PAA00981 for ; Tue, 22 Aug 2000 15:06:45 -0700 (MST) Message-Id: <200008222206.PAA00981@grosse.bisbee.fugue.com> To: DHCPv4 discussion list Subject: Re: FW: I-D ACTION:draft-ietf-dhc-userclass-10.txt In-Reply-To: Message from Nathan Lane of "Tue, 22 Aug 2000 14:15:45 EST." Date: Tue, 22 Aug 2000 15:06:45 -0700 From: Ted Lemon Reply-To: mellon@nominum.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN I really don't think we need to get into a jihad here about what server administrators should or shouldn't do. The option is useful, without ever talking about differentiating classes of service, and indeed I don't think that was ever the intention; rather, the intention was to provide a way of differentiating between clients based on the needs specified by the users of those clients; thus, "user class." It completely muddies the issue to bring all this other crap in, and that's why this option has lingered so long on the table. Can we please just blow off the differential service issue and admit that this option has perfectly valid uses regardless of that issue and needs to be finished? Thanks, _MelloN_ From owner-dhcp-v4@bucknell.edu Tue Aug 22 20:13:26 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17931 for ; Tue, 22 Aug 2000 20:13:26 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e7N0AZi04514; Tue, 22 Aug 2000 20:10:35 -0400 (EDT) Received: from schilling.ucdavis.edu (schilling.ucdavis.edu [169.237.105.1]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e7N0AIi00594 for ; Tue, 22 Aug 2000 20:10:18 -0400 (EDT) Received: from urd981891.ucdavis.edu ([169.237.84.172]) by schilling.ucdavis.edu (8.9.3/8.9.3/IT4.3.4) with SMTP id RAA06887; Tue, 22 Aug 2000 17:10:05 -0700 (PDT) Message-Id: <200008230010.RAA06887@schilling.ucdavis.edu> X-Sender: monikann@mailbox.ucdavis.edu X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 Date: Tue, 22 Aug 2000 17:10:00 -0700 To: DHCPv4 discussion list From: "Monika (Maria) Dorough" Subject: Re: FW: I-D ACTION:draft-ietf-dhc-userclass-10.txt Cc: DHCPv4 discussion list In-Reply-To: <200008221654.MAA14772@rotala.raleigh.ibm.com> References: <200008221630.JAA00472@grosse.bisbee.fugue.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Reply-To: madorough@ucdavis.edu Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Someone pleeaaze tell me how to get off this listserve!!!!! At 12:54 PM 08/22/2000 -0400, Thomas Narten wrote: >> Maybe I'm being a space cadet here, but why is this a problem? The >> IP address the server gives out also depends on the DHCP Requested >> Address option in some cases! > >Hmm. What is the purpose of that option? Without knowing the history, >I would think that option is to tell the server, "hey I was using >address X before, if its OK with you, I'd like to get it again". Or >something like that. > >The general issue is that clients shouldn't care what addresses they >get. I.e., any address should work. Anytime the DHCP server uses >something like the client ID to influence what address is given out, >the implication is that different addresses are used in different ways >(e.g., have different QOS, can punch through firewalls, are in access >control lists for services, etc.) But now the DHCP server needs to be >much more tightly coupled with other parts of the infrastructure >(e.g., routers, firewalls, etc.) The current (and previous ID) says >absolutely nothing about this bigger issue. > >What some of the IESG objected to was the implication that the ID >suggested using the client ID to assign addresses that had special >characteristics associated with it *without* discussing in a fair >amount of detail the implication of all this. For example, if a site >was using diffserv, how do the packets from address X get mapped into >special diffserv PHBs? > >> It's perfectly reasonable for the client to request things, and what >> the server does depends on policy. What is it about this that needs >> to be fixed? > >This isn't the issue. Its the implication on other parts of the >infrastructure beyound DHCP that are implied by having different >classes of addresses a DHCP server is handing out. > >> Maybe the thing we want is to say that the client can "request" >> variations in how it is treated based on the user class option, and >> that whether or not the server honors these requests, and how, is a >> decision that should be left up to the server administrator. > >If I understand "how it is treated" to mean that some clients get >different service than others, then we heading in the problematical >direction. It is not DHCP's job to regulate what kind of service a >client gets. Its DHCP's job just to configure the client with necessary >parameters. > >Hope this helps clarify things a bit more. > >Thomas > From owner-dhcp-v4@bucknell.edu Tue Aug 22 21:55:37 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19675 for ; Tue, 22 Aug 2000 21:55:36 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e7N1qmi06641; Tue, 22 Aug 2000 21:52:48 -0400 (EDT) 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 e7N1qci22590 for ; Tue, 22 Aug 2000 21:52:38 -0400 (EDT) Received: from rdroms-nt.bucknell.edu (rtp-dial-2-208.cisco.com [10.83.96.208]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id VAA16104; Tue, 22 Aug 2000 21:51:49 -0400 (EDT) Message-Id: <4.3.1.2.20000822215340.00b2b580@mail.bucknell.edu> X-Sender: droms@mail.bucknell.edu X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Tue, 22 Aug 2000 21:54:08 -0400 To: DHCPv4 discussion list From: Ralph Droms Subject: Re: FW: I-D ACTION:draft-ietf-dhc-userclass-10.txt Cc: DHCPv4 discussion list 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 You should send admin requests to listserv@bucknell.edu; e.g., to unsubscribe, send e-mail containing the message "unsubscribe dhcp-v4" - Ralph Droms At 05:10 PM 8/22/00 -0700, Monika (Maria) Dorough wrote: >Someone pleeaaze tell me how to get off this listserve!!!!! From owner-dhcp-v4@bucknell.edu Wed Aug 23 10:05:04 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11907 for ; Wed, 23 Aug 2000 10:05:04 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e7NDxwi10787; Wed, 23 Aug 2000 09:59:59 -0400 (EDT) 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 e7NDxqi04456 for ; Wed, 23 Aug 2000 09:59:52 -0400 (EDT) Received: from rdroms-nt.cisco.com (ch2-dhcp133-127.cisco.com [161.44.133.127]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id JAA27932; Wed, 23 Aug 2000 09:59:36 -0400 (EDT) Message-Id: <4.3.1.2.20000823095604.00b338c0@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Wed, 23 Aug 2000 10:01:54 -0400 To: DHCPv4 discussion list From: Ralph Droms Subject: WG last call for DHCP Option for SIP Servers Cc: "Dean Willis" , "Brian Rosen" , "Gautam Nair" , "Henning Schulzrinne" 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 (Posted for Dean Willis; please copy any responses to Dean, dwillis@dynamicsoft.com - RD) The initial WG last call of the DHCP option for SIP draft resulted in changes that significantly simplified the material. A revised draft, http://search.ietf.org/internet-drafts/draft-ietf-sip-dhcp-01.txt was posted in April. There have been essentially no comments on it to my knowledge. I am therefore announcing a working-group last call. Please review the draft. If no new issues are raised by September 7 (that's two weeks from this transmission), we will send the draft to the IESG. -- Dean Willis SIP WG Co-Chair From owner-dhcp-v4@bucknell.edu Wed Aug 23 15:30:59 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21963 for ; Wed, 23 Aug 2000 15:30:59 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e7NJQsi24704; Wed, 23 Aug 2000 15:26:54 -0400 (EDT) Received: from quadntweb.quadritek.com ([198.200.138.211]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e7NJQfi06962 for ; Wed, 23 Aug 2000 15:26:41 -0400 (EDT) Received: from agrabilnt ([198.200.138.254]) by quadntweb.quadritek.com (Post.Office MTA v3.5.3 release 223 ID# 0-59484U200L100S0V35) with SMTP id com for ; Wed, 23 Aug 2000 15:18:04 -0400 From: "A. Gregory Rabil" To: DHCPv4 discussion list Subject: RE: I-D ACTION:draft-ietf-dhc-subnet-option-06.txt Date: Wed, 23 Aug 2000 15:25:37 -0400 Message-ID: <043701c00d37$eaee6bf0$fe8ac8c6@quadritek.com> MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 In-Reply-To: <200006091109.HAA08474@ietf.org> Reply-To: grabil@lucent.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit Can anyone provide me with an update on this draft's status? I saw only that it was returned, with comments, by the IESG, for further revision. What changes are still required? Is there an option number assigned from IANA? Thanks, Greg Rabil From owner-dhcp-v4@bucknell.edu Wed Aug 23 16:09:16 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22394 for ; Wed, 23 Aug 2000 16:09:15 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e7NK6Ci07786; Wed, 23 Aug 2000 16:06:12 -0400 (EDT) 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 e7NK61i05351 for ; Wed, 23 Aug 2000 16:06:02 -0400 (EDT) Received: from rdroms-nt.bucknell.edu (ch2-dhcp133-127.cisco.com [161.44.133.127]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id QAA19353; Wed, 23 Aug 2000 16:05:45 -0400 (EDT) Message-Id: <4.3.1.2.20000823160640.00b26bb0@mail.bucknell.edu> X-Sender: droms@mail.bucknell.edu X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Wed, 23 Aug 2000 16:08:10 -0400 To: DHCPv4 discussion list From: Ralph Droms Subject: RE: I-D ACTION:draft-ietf-dhc-subnet-option-06.txt In-Reply-To: <043701c00d37$eaee6bf0$fe8ac8c6@quadritek.com> References: <200006091109.HAA08474@ietf.org> 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 The spec has been revised, but I still need a quick clarification about some specific wording before the doc is resubmitted. It has not yet been assigned an option number. - Ralph At 03:25 PM 8/23/00 -0400, A. Gregory Rabil wrote: >Can anyone provide me with an update on this draft's status? I saw only >that it was returned, with comments, by the IESG, for further revision. >What changes are still required? Is there an option number assigned from >IANA? From owner-dhcp-v4@bucknell.edu Wed Aug 23 17:57:37 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23460 for ; Wed, 23 Aug 2000 17:57:36 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e7NLssi30760; Wed, 23 Aug 2000 17:54:54 -0400 (EDT) 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 e7NLsoi19916 for ; Wed, 23 Aug 2000 17:54:50 -0400 (EDT) Received: from rdroms-nt.bucknell.edu (ch2-dhcp133-127.cisco.com [161.44.133.127]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id RAA02704; Wed, 23 Aug 2000 17:54:03 -0400 (EDT) Message-Id: <4.3.1.2.20000823174934.00b3cb30@mail.bucknell.edu> X-Sender: droms@mail.bucknell.edu X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Wed, 23 Aug 2000 17:56:25 -0400 To: DHCPv4 discussion list From: Ralph Droms Subject: Re: FW: I-D ACTION:draft-ietf-dhc-userclass-10.txt Cc: DHCPv4 discussion list In-Reply-To: <200008222206.PAA00981@grosse.bisbee.fugue.com> References: 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 Thomas - we seem to be at something of an impasse here. The current version of the draft says nothing specific about how the IP address and configuration parameters selected for a particular client might be used and doesn't explicitly mention differential service in any way. Similar mechanisms are used by DHCP servers today to choose an IP address based on other selection criteria. How can we work around the specific objections to the user-class option? One suggestion is to eliminate the reference to IP address in the user class draft, restricting its application to configuration parameters (in options) and specifically excluding the choice of IP address based on user class. We would need to gain WG consensus for that change. - Ralph At 03:06 PM 8/22/00 -0700, Ted Lemon wrote: >Can we please just blow off the differential service issue >and admit that this option has perfectly valid uses regardless of that >issue and needs to be finished? > > _MelloN_ From owner-dhcp-v4@bucknell.edu Thu Aug 24 09:41:54 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16963 for ; Thu, 24 Aug 2000 09:41:53 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e7ODc6i06783; Thu, 24 Aug 2000 09:38:06 -0400 (EDT) Received: from rmx614-mta.mail.com (rmx614-mta.mail.com [165.251.48.52]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e7ODbri17868 for ; Thu, 24 Aug 2000 09:37:53 -0400 (EDT) Received: from web277-ec (web277-ec.mail.com [165.251.32.153]) by rmx614-mta.mail.com (8.9.3/8.9.3) with SMTP id JAA12504 for ; Thu, 24 Aug 2000 09:37:53 -0400 (EDT) Message-ID: <383592926.967124272975.JavaMail.root@web277-ec> Date: Thu, 24 Aug 2000 09:37:52 -0400 (EDT) From: Rajeev Chawla To: DHCPv4 discussion list Subject: Finding servers Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: mail.com X-Originating-IP: 216.204.63.34 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mail.bucknell.edu id e7ODbri19475 Reply-To: rajeevchawla@email.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 8bit Hi, I am new to DHCP and have a few basic questions: Can I use DHCP to find all servers of a certain type, if I manually configure the IP addresses of these servers on the DHCP server? My understanding is that I will have to modify the DHCP client on my client devices to get these addresses from the DHCP server using ‘Vendor Specific Information’ option and 'dhcpinform'. Is there any other way in DHCP to do this? Can the servers dynamically register with the DHCP server (so that they don’t have to be manually configured and if they crash or become unreachable, DHCP server can age out that information)? Thanks, Rajeev ----------------------------------------------- FREE! The World's Best Email Address @email.com Reserve your name now at http://www.email.com From owner-dhcp-v4@bucknell.edu Thu Aug 24 14:02:47 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21616 for ; Thu, 24 Aug 2000 14:02:45 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e7OHxai06652; Thu, 24 Aug 2000 13:59:36 -0400 (EDT) Received: from fs-sd-exch2.coppermountain.com (fs-sd-exch1.coppermountain.com [209.246.224.234] (may be forged)) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e7OHxRi29096 for ; Thu, 24 Aug 2000 13:59:28 -0400 (EDT) Received: by mail.coppermountain.com with Internet Mail Service (5.5.2650.21) id ; Thu, 24 Aug 2000 10:59:17 -0700 Message-ID: <9FFFAB5D74FFD31191EA00D0B74178C89C5288@mail.coppermountain.com> From: Eric Michelsen To: DHCPv4 discussion list Subject: RE: FW: I-D ACTION:draft-ietf-dhc-userclass-10.txt Date: Thu, 24 Aug 2000 10:59:15 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Reply-To: emichelsen@coppermountain.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN I am totally stunned by this discussion. The userclass is simply a convenience for network administrators. It can be used for a huge set of things, many of which we can't even think of yet. Therefore, there are no "implications" one could describe for how it might be used, because different uses have totally different implications. But who cares, anyway? Administrators are responsible for the implications of all the decisions they make on their networks. This is no different than any one of a thousand other decisions administrators make. And in fact, userclass is far less insidious than trying to get your firewall filters set properly. I don't understand the big deal. Userclass is useful, and it hurts no one. If you're an idiot, you can confuse your network with it. Isn't that true of nearly ALL DHCP parameters? ... > The general issue is that clients shouldn't care what addresses they > get. I.e., any address should work. The clients may not care. It's probably the network administrators that care. > Anytime the DHCP server uses > something like the client ID to influence what address is given out, > the implication is that different addresses are used in different ways Sorry, but this is hogwash. The addresses are used for the administrator's convenience. I worked on a network where routers were *.1, engineering was *.10-*.29, marketing was *.80-*.99, and the dial-in server was *.254. The numbering was simply a convenience for the administrator. This is a total non-issue. > If I understand "how it is treated" to mean that some clients get > different service than others, then we heading in the problematical > direction. I agree that the wording should refer only to configuration, because that is what DHCP does: it configures. The wording should NOT refer to IP address specifically, because it is just part of configuration. But the implications of that configuration is entirely the responsibility of the network administrator, and in many ways, far beyond DHCP. This draft is not supposed to be a tutorial on IP pitfalls. From owner-dhcp-v6@bucknell.edu Thu Aug 24 17:23:36 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24138 for ; Thu, 24 Aug 2000 17:23:36 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e7OLKHi07497; Thu, 24 Aug 2000 17:20:17 -0400 (EDT) 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 e7OLKAi01005 for ; Thu, 24 Aug 2000 17:20:10 -0400 (EDT) Received: from rdroms-nt.cisco.com (ch2-dhcp133-163.cisco.com [161.44.133.163]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id RAA24186 for ; Thu, 24 Aug 2000 17:19:54 -0400 (EDT) Message-Id: <4.3.1.2.20000824163327.00afc3b0@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Thu, 24 Aug 2000 17:15:24 -0400 To: DHCPv6 discussion list From: Ralph Droms Subject: Design team teleconference on DHCPv6 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 Following up on the impromptu meeting on DHCPv6 in Pittsburgh, I've scheduled a DHCPv6 design team telephone-based teleconference for next Thursday, 8/31 between noon and 3PM, EDT. Our process for this teleconference will be based on Ted Lemon's plan for moving the DHCPv6 spec forward: (1) Everybody who is strongly interested is going to read the current draft over carefully, if they haven't already, or if only as a means of accomplishing (2): (2) Each of us is going to make a list of the things that are in the draft that aren't okay with us, and a list of things that are not in the draft that we would like to see in the draft. Criteria for inclusion (and design) or exclusion of a particular feature include: - Is this a feature clearly required in the next six months or can it be added as an extension later - Is this a feature new to DHCPv6 and is the feature required by IPv6 - Is the design of this feature based on DHCPv4 experience - What is the justification for features that differ from DHCPv4 design (3) We will each publish this information on the DHCPv6 mailing list. (4) Teleconference agenda: (a) Develop a list of specific changes to be made to the spec (b) Develop a timeline of milestones to be accomplished to bring the spec up for final WG review in San Diego Cisco System will host the teleconference with toll-free access within the U.S., and will be happy to reimburse those outside the U.S. for their calls. If you want to participate in the call on 8/31, please contact me for the phone number and conference ID. All participants will be expected to execute steps 1, 2 and 3 prior to next week's phone call, so I can put together a list of features that we can have on the table when we start talking at noon on 8/31. - Ralph From owner-dhcp-v4@bucknell.edu Fri Aug 25 07:26:06 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16371 for ; Fri, 25 Aug 2000 07:26:05 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e7PBLNi18634; Fri, 25 Aug 2000 07:21:23 -0400 (EDT) Received: from iaehv.iae.nl (iaehv.IAE.nl [194.151.64.2]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e7PBLCi11330 for ; Fri, 25 Aug 2000 07:21:12 -0400 (EDT) Received: from exchange1.industree.nl (simac1.iae.nl [194.151.73.56]) by iaehv.iae.nl (Postfix) with ESMTP id 9F87B7C23 for ; Fri, 25 Aug 2000 13:21:10 +0200 (CEST) Received: by EXCHANGE1 with Internet Mail Service (5.5.2448.0) id ; Fri, 25 Aug 2000 13:20:14 +0200 Message-ID: <0361C92ECB4FD311976A0000F87C29502DA3A7@EXCHANGE1> From: Adriaan van den Brand To: DHCPv4 discussion list Subject: RE: I-D ACTION:draft-ietf-dhc-subnet-option-06.txt Date: Fri, 25 Aug 2000 13:20:05 +0200 X-Mailer: Internet Mail Service (5.5.2448.0) Reply-To: Adriaan.van.den.Brand@industree.nl Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Too bad that it has been delayed for so long. I'm really waiting for it. The reason for this is that we run networks with thousands of routing cable modems all capable of performing dhcp relay. The normal dhcp relay is however, a pain in the *** because it requires all cable modems to have a unique (public) ip address on the PC side. Usually all cable modems can share the same ip address, running in a shared network, as it is only visible from the customers equipment. The modem itself is addressed only via a private ip address on the cable network. As IPv4 space is very scarce we need to be very efficient with ip addresses as well. I hope that the dhcp-subnet-option will be promoted really soon. If the option number is assigned, this will help us to get the implementation going asap. - Adriaan > -----Original Message----- > From: Ralph Droms [mailto:droms@bucknell.edu] > Sent: Wednesday, August 23, 2000 10:08 PM > To: DHCPv4 discussion list > Subject: RE: I-D ACTION:draft-ietf-dhc-subnet-option-06.txt > > > The spec has been revised, but I still need a quick > clarification about > some specific wording before the doc is resubmitted. It has > not yet been > assigned an option number. > > - Ralph > > > > At 03:25 PM 8/23/00 -0400, A. Gregory Rabil wrote: > >Can anyone provide me with an update on this draft's status? > I saw only > >that it was returned, with comments, by the IESG, for > further revision. > >What changes are still required? Is there an option number > assigned from > >IANA? > > > From owner-dhcp-v4@bucknell.edu Fri Aug 25 12:24:08 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23945 for ; Fri, 25 Aug 2000 12:24:08 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e7PGKci18834; Fri, 25 Aug 2000 12:20:39 -0400 (EDT) Received: from smtprch1.nortel.com (smtprch1.nortelnetworks.com [192.135.215.14]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e7PGKbi31335 for ; Fri, 25 Aug 2000 12:20:37 -0400 (EDT) Received: from zrchh190 by smtprch1.nortel.com; Fri, 25 Aug 2000 11:11:46 -0500 Received: from zcard00b.ca.nortel.com by zrchh190; Fri, 25 Aug 2000 11:14:43 -0500 Received: from netgww (NET-GWW [47.130.100.112]) by zcard00b.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id RFRK1ZYC; Fri, 25 Aug 2000 11:43:34 -0400 From: "Glenn Waters" To: DHCPv4 discussion list Cc: grabil Subject: RE: I-D ACTION:draft-ietf-dhc-subnet-option-06.txt Date: Fri, 25 Aug 2000 11:44:10 -0400 Message-ID: <000a01c00eab$50627480$7064822f@netgww> MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: <043701c00d37$eaee6bf0$fe8ac8c6@quadritek.com> X-Orig: Reply-To: gww@nortelnetworks.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit Some wording about the security implications of this option has been requested. I expect that wording to be complete in the next couple of days. Cheers, /gww -----Original Message----- From: A. Gregory Rabil [mailto:grabil@lucent.com] Sent: Wednesday, August 23, 2000 15:26 To: DHCPv4 discussion list Subject: RE: I-D ACTION:draft-ietf-dhc-subnet-option-06.txt Can anyone provide me with an update on this draft's status? I saw only that it was returned, with comments, by the IESG, for further revision. What changes are still required? Is there an option number assigned from IANA? Thanks, Greg Rabil From owner-dhcp-v4@bucknell.edu Fri Aug 25 14:02:24 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25836 for ; Fri, 25 Aug 2000 14:02:24 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e7PHxYi03592; Fri, 25 Aug 2000 13:59:34 -0400 (EDT) Received: from mail.ultradns.com (mail.ultradns.net [64.41.145.150]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e7PHxVi09352 for ; Fri, 25 Aug 2000 13:59:31 -0400 (EDT) Received: (qmail 30135 invoked from network); 25 Aug 2000 17:59:30 -0000 Received: from nat-external.ultradns.net (HELO ULTRADNS6PMNFK) (216.15.7.195) by mail.ultradns.com with SMTP; 25 Aug 2000 17:59:30 -0000 From: "Barr Hibbs" To: DHCPv4 discussion list Cc: "Dean Willis" Subject: RE: WG last call for DHCP Option for SIP Servers Date: Fri, 25 Aug 2000 10:59:48 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <4.3.1.2.20000823095604.00b338c0@funnel.cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Reply-To: rbhibbs@ultraDNS.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit > -----Original Message----- > From: Ralph Droms > Sent: Wednesday, August 23, 2000 7:02 AM > > > I am therefore announcing a working-group last call. Please review the > draft. If no new issues are raised by September 7 (that's two weeks from > this transmission), we will send the draft to the IESG. > > -- > Dean Willis > SIP WG Co-Chair > ...sorry to be so late in reviewing this, but I find no outstanding problems and recommend proceeding with this draft. --Barr From owner-dhcp-v4@bucknell.edu Fri Aug 25 22:45:18 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA05330 for ; Fri, 25 Aug 2000 22:45:18 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e7Q2gCi00734; Fri, 25 Aug 2000 22:42:12 -0400 (EDT) Received: from crash.ab.videon.ca (crash.ab.videon.ca [206.75.216.220]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e7Q2g8i30637 for ; Fri, 25 Aug 2000 22:42:08 -0400 (EDT) Received: from vid704.ab.videon.ca (vid704.ab.videon.ca [24.108.62.12]) by crash.ab.videon.ca (8.9.2/8.9.2) with ESMTP id UAA24531 for ; Fri, 25 Aug 2000 20:41:52 -0600 (MDT) Received: by vid704.ab.videon.ca with Internet Mail Service (5.5.2650.21) id <3YT3YC3X>; Fri, 25 Aug 2000 20:42:09 -0600 Message-ID: From: Laurence Brockman To: DHCPv4 discussion list Subject: Failover and DHC load balancing algorithm Date: Fri, 25 Aug 2000 20:42:08 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Reply-To: L.Brockman@videon.ca Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Does anyone know of a DHCP server that implements either the DHCP failover protocol outlined in the Internet Draft or the DHC load balancing algorithm outlined in it's respective Internet Draft? I am more interested in the load balancing algorithm or something similar that allows a load balancing scheme to be put in place (Reliably). Any ideas or suggestions (Sorry if this is a FAQ)... Thanks in advance, Laurence From owner-dhcp-v6@bucknell.edu Sun Aug 27 13:35:33 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10672 for ; Sun, 27 Aug 2000 13:35:33 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e7RHWDi10565; Sun, 27 Aug 2000 13:32:14 -0400 (EDT) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e7RHWBi18422 for ; Sun, 27 Aug 2000 13:32:11 -0400 (EDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id e7RHVt630215 for ; Sun, 27 Aug 2000 19:31:55 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id TAA28760 for ; Sun, 27 Aug 2000 19:31:54 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.9.3/8.9.3) with ESMTP id TAA10739 for ; Sun, 27 Aug 2000 19:32:39 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200008271732.TAA10739@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: DHCPv6 discussion list Subject: experimental code Date: Sun, 27 Aug 2000 19:32:39 +0200 Sender: owner-dhcp-v6@bucknell.edu Reply-To: dhcp-v6@bucknell.edu X-Sender: Francis.Dupont@enst-bretagne.fr X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN I've put our experimental code (wrote by an Indian student, Dhawal Kumar, in two months without prior IPv6 or DHCP knowledge) in anonymous FTP: ftp://ftp.inria.fr/network/ipv6/dhcpv6/ Francis.Dupont@enst-bretagne.fr From owner-dhcp-v6@bucknell.edu Mon Aug 28 01:06:09 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17641 for ; Mon, 28 Aug 2000 01:06:09 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e7S52mi21403; Mon, 28 Aug 2000 01:02:48 -0400 (EDT) Received: from zmamail02.zma.compaq.com (zmamail02.zma.compaq.com [161.114.64.102]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e7S52li07142 for ; Mon, 28 Aug 2000 01:02:47 -0400 (EDT) Received: by zmamail02.zma.compaq.com (Postfix, from userid 12345) id E030B4E1; Mon, 28 Aug 2000 01:02:31 -0400 (EDT) Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by zmamail02.zma.compaq.com (Postfix) with ESMTP id 8AAF9408 for ; Mon, 28 Aug 2000 01:02:31 -0400 (EDT) Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM) id BAA0000942723; Mon, 28 Aug 2000 01:02:28 -0400 (EDT) From: Jim Bound Message-Id: <200008280502.BAA0000942723@anw.zk3.dec.com> To: DHCPv6 discussion list Cc: bound@ZK3.DEC.COM Subject: DHCPv6 State Diagram (Client and Server) Date: Mon, 28 Aug 2000 01:02:26 -0400 X-Mts: smtp 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 My hope is these are useful for Thursday meeting. ftp:://sipper.zk3.dec.com/pub/dhcpv6_state.ppt Or you can anonymous ftp too. I will provide PDF version Monday night if you can't do .ppt's. regards, /jim From owner-dhcp-v4@bucknell.edu Mon Aug 28 10:01:06 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09321 for ; Mon, 28 Aug 2000 10:01:06 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e7SDuUi19381; Mon, 28 Aug 2000 09:56:30 -0400 (EDT) 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 e7SDuSi05796 for ; Mon, 28 Aug 2000 09:56:28 -0400 (EDT) Received: by lespaul.process.com with Internet Mail Service (5.5.2650.21) id ; Mon, 28 Aug 2000 09:56:12 -0400 Message-ID: <63D30D6E10CFD11190A90000F805FE8602BEC047@lespaul.process.com> From: Bernie Volz To: DHCPv4 discussion list Subject: RE: Failover and DHC load balancing algorithm Date: Mon, 28 Aug 2000 09:56:11 -0400 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 Laurence: I know of no implementations of the Load Balancing algorithm (though it should be relatively simple to add to an existing server). There are several implementations of the failover protocol. Ted Lemon has been working on adding that support to the ISC DHCP Server. Cisco and IPWorks have shipping implementations - though these use UDP and are based on an earlier version of the draft (03) with many enhancements based on later versions of the draft (we learned from our implementations and incorporated these into later drafts). There may be others out there that I'm not aware of (either shipping or under development). - Bernie Volz IPWorks, Inc. -----Original Message----- From: Laurence Brockman [mailto:L.Brockman@videon.ca] Sent: Friday, August 25, 2000 10:42 PM To: DHCPv4 discussion list Subject: Failover and DHC load balancing algorithm Does anyone know of a DHCP server that implements either the DHCP failover protocol outlined in the Internet Draft or the DHC load balancing algorithm outlined in it's respective Internet Draft? I am more interested in the load balancing algorithm or something similar that allows a load balancing scheme to be put in place (Reliably). Any ideas or suggestions (Sorry if this is a FAQ)... Thanks in advance, Laurence From owner-dhcp-v4@bucknell.edu Mon Aug 28 11:01:26 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11823 for ; Mon, 28 Aug 2000 11:01:25 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e7SEvOi04357; Mon, 28 Aug 2000 10:57:24 -0400 (EDT) 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 e7SEvMi10125; Mon, 28 Aug 2000 10:57:22 -0400 (EDT) Received: by lespaul.process.com with Internet Mail Service (5.5.2650.21) id ; Mon, 28 Aug 2000 10:57:06 -0400 Message-ID: <63D30D6E10CFD11190A90000F805FE8602BEC053@lespaul.process.com> From: Bernie Volz To: DHCPv4 discussion list Subject: RE: FW: I-D ACTION:draft-ietf-dhc-userclass-10.txt Date: Mon, 28 Aug 2000 10:57:05 -0400 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 Isn't an IP Address a "configuration parameter"? I think that would cover it - we don't explicitly state what can and can not be configured via this option -- that is policy. So simply saying that the user class option may be used by the server to determine the configuration parameters it returns to the client ought to do it? - Bernie Volz -----Original Message----- From: Ralph Droms [mailto:droms@bucknell.edu] Sent: Wednesday, August 23, 2000 5:56 PM To: DHCPv4 discussion list Cc: DHCPv4 discussion list Subject: Re: FW: I-D ACTION:draft-ietf-dhc-userclass-10.txt Thomas - we seem to be at something of an impasse here. The current version of the draft says nothing specific about how the IP address and configuration parameters selected for a particular client might be used and doesn't explicitly mention differential service in any way. Similar mechanisms are used by DHCP servers today to choose an IP address based on other selection criteria. How can we work around the specific objections to the user-class option? One suggestion is to eliminate the reference to IP address in the user class draft, restricting its application to configuration parameters (in options) and specifically excluding the choice of IP address based on user class. We would need to gain WG consensus for that change. - Ralph At 03:06 PM 8/22/00 -0700, Ted Lemon wrote: >Can we please just blow off the differential service issue >and admit that this option has perfectly valid uses regardless of that >issue and needs to be finished? > > _MelloN_ From owner-dhcp-v6@bucknell.edu Mon Aug 28 13:10:44 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16102 for ; Mon, 28 Aug 2000 13:10:41 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e7SH6Li13058; Mon, 28 Aug 2000 13:07:26 -0400 (EDT) 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 e7SH64i01837; Mon, 28 Aug 2000 13:06:04 -0400 (EDT) Received: from rdroms-nt.bucknell.edu (ch2-dhcp133-127.cisco.com [161.44.133.127]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id NAA26215; Mon, 28 Aug 2000 13:05:17 -0400 (EDT) Message-Id: <4.3.1.2.20000828125813.00b5fa70@funnel.cisco.com> X-Sender: droms@mail.bucknell.edu X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Mon, 28 Aug 2000 12:58:35 -0400 To: DHCPv6 discussion list From: Ralph Droms Subject: Minutes from DHC WG meetings in Pittsburgh Cc: dhcp-v4@bucknell.edu, dhcp-v6@bucknell.edu 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 Here are the minutes from the DHC (Dynamic Host Configuration) working group meetings in Pittsburgh, PA. - Ralph Droms ===== Meeting Manager: Ralph Droms (WG Chair) Minutes prepared by: Richard Jones Monday, Jul 31 at 1930-2200 (DHCPv4) ==================================== ANNOUNCEMENTS Ralph officially announced that he has taken a position with Cisco Systems in the Boston area. He has taken a one year leave of absence from Bucknell University, but expects it to extend beyond that time frame. He stated that acting as DHCP Working Group Chair is now officially a part of his job, so expects to devote more time to it. ACTIVITIES RFC 2855 (DHCP for IEEE 1394) is accepted by the IESG as a Proposed Standard. Drafts draft-ietf-dhc-nsso-05.txt and draft-ietf-dhc-authentication-14.txt have been submitted to the IESG for considerations as Proposed Standards. draft-ietf-dhc-new-opt-msg-02.txt is accepted by the IESG as a Best Current Practice (BCP) document. The following drafts have been returned, with comments, by the IESG for further revision: draft-ietf-dhc-subnet-option-06.txt draft-ietf-dhc-userclass-09.txt draft-ietf-dhc-pv4-reconfigure-01.txt will be revised based on feedback from WG Last Call before being submitted to the IESG. The DHCPv6 specification and the server-to-server drafts are currently under construction. DRAFT OPEN ISSUES Draft: DHCP-DNS Interaction Presenter: Mark Stapp The original draft has been broken out into two drafts, based on feedback from the Adelaide IETF meeting: the 'fqdn draft', draft-ietf-dhc-fqdn-option-00.txt, and the 'resolution' draft, draft-ietf-dhc-ddns-resolution-00.txt. The resolution draft references a dnsext draft, draft-ietf-dnsext-dhcid-rr-00.txt, which refreshes an expired draft. It is expected that these drafts will undergo one or more revisions before being ready for WG Last Call. It was suggested that a bit flag be added to the fqdn option format that allows a client to request that the server do no DNS updating at all for this request. Current option flags only specify that the client can request the server not update the A RR. The consensus was that this is fine, but that the server reserve the right to override the client request. It was suggested that the DHCID Resource Record be encoded in Base 64 rather than hexadecimal format. This was agreed upon, with Andreas Gustoffson volunteering to provide existing 'boilerplate' documentation for this provision. The question of having the server update other RR's than the A and PTR records was raised again. Also, the possible need for multiple PTR records was raised. It was agreed that these need to be discussed on the mailing list in greater detail. The question of whether or not a client can send multiple fqdn options in a request was raised. The prevailing opinion seemed to be opposed to this, especially since the current convention for multiple options in a DHCP packet only deals with options having lengths greater than the maximum option size, meaning that the values of all the multiple options are concatenated (which would not be the case here). This question will also be referred back to the list. Mark placed the following issues before the group: 1. Was the draft division the right thing to do? 2. Are there use cases (or scenarios) that need to be added to the resolution draft? 3. Who has implementation experiences they can share that will contribute to refining the draft? ACTION ITEMS - DHCP-DNS interaction AUTHOR: Add the flag bit to the fqdn option as requested. Change the encoding scheme for the DHCID RR as requested. Initiate mailing list discussions of the questions brought up in the meeting, and the ones the author brought to the meeting. Draft: DHCP Authentication using Kerberos draft-smedvinksy-dhc-kerbauth-00.txt Presentor: Poornima Lalwaney Poornima gave a detailed presentation of the draft. There is an existing Kerberos DHCP draft (draft-hornstein-dhc-kerbauth-02.txt). Poornima contrasted the two drafts, stating that the Hornstein draft posits a tight coupling between the DHCP server and the Kerberos state machine(s). The Medvinksy draft de-couples the server to a large degree by placing initial key management responsibilities on an 'iakerb proxy', which is specified in a current kerberos draft (draft-ietf-cat-iakerb-03.txt). The Medvinsky draft proposes using the client's hardware address in AS_REQ and TGS_REQ host address fields by using a negative value in the 'host address type' field, as specified by the IAKERB draft. The 'source IP address' field would be left at 0. It was noted that in order for the Medvinsky draft to succeed, the iakerb proxy draft must be modified. The proxy draft implies (but doesn't state explicitly) that the GSS API must be used to access proxy mechanisms. The Medvinsky draft would extend the proxy draft to allow 'raw' kerberos messages to be handled by the proxy as well. Ted Lemon advocated adoption of the Hornstein draft, because he feels that requiring modification of server behavior is preferable to requiring modification of client and/or relay behavior. It was noted that the authors of the Hornstein draft are not moving it forward; Ted offered to assume that responsibility. It was noted that there is not currently working group consensus on which draft to move forward. ACTION ITEMS - DHCP Authentication using Kerberos AUTHORS: The authors (or representatives) of both Kerberos drafts will prepare motivation/discussion documents that will be presented to the mailing list for discussion, with the goal of determining which draft should be moved forward. The documents will be available to the list by October 1, 2000, with this discussion to be resumed at the next IETF Meeting. WORKING GROUP CHARTER AND MILESTONES REVIEW Presentor: Ralph Droms The five main charter points were agreed upon by the group with the following changes/additions: 1. The issue of DHCP authentication is to be moved from a sub- category to a full charter requirement. 2. The LDAP and DHCP MIB projects will be added as full charter requirements. 3. The interaction between the DHCP WG and the IPV6 autoconf WG, while a major issue, is covered in the DHCPv6 charter point. The milestones list is outdated. Ralph will get date information from several people on the status of their respective drafts. Specific milestone issues include: a list of open issues concerning the review of the DHCP protocol for Standard is needed. This might be accomplished by publishing the list as an intermediate or informational I-D. The Classless Static Routes and NameServer Search drafts will shortly be ready for Working Group Last Call. The New Options Guidelines draft has been split into two drafts, and the goal is to have them ready for WG Last Call in the near future (i.e., before the next IETF meeting). ACTION ITEMS - Charter and Milestones AUTHOR: Ralph will modify the Charter and submit it to the list for comment. He will solicit date information from draft authors who are represented in the milestones list, update the milestones list and submit it to the list for comment. DRAFT: LDAP Schema draft-ietf-dhc-schema-02.txt Presentor: Bernie Volz A new version of this draft, based on detailed feedback from a couple of sources, will be issued in late August. ACTION ITEMS - LDAP Schema AUTHOR: will issue -03 version of the draft. DRAFT: Load Balancing draft-ietf-dhc-loadb-02.txt Presentor: Bernie Volz The -02 version of this draft has been published. It consists mostly of wording changes and cleanup. Bernie asks that this draft be sent to WG Last Call. DRAFT: Failover draft-ietf-dhc-failover-07.txt Presentor: Bernie Volz The -07 version of this draft has been published. It consists mostly of editorial changes, with minor technical changes. The draft's author was unable to attend, so discussion of the draft was postponed to the list, and likely to a conference call meeting to be held in the fall. Bernie stated that more discussion (and draft language) is needed to deal with the issue of reserved address handling, based on Cisco's current implementation experiences. The open issues, which are listed in the draft, are generally straightforward, and should be dealt with in the interim meeting. Area Director Thomas Narten stated that the IESG requires substantial advance notice for interim Working Group meetings, and a consideration of time constraints and convenience on a global level, to make working group meetings internationally inclusive. He clarified that this was not a criticism of the DHC group's handling of meetings, but rather a reiteration of requirements for how they should be announced and conducted. In general, meeting announcements should be made around a month in advance when possible, and in any case more than a week in advance. They should also try to take into account the problems of time zone differences between interested parties, in the case of conference calls. ACTION ITEMS - Failover AUTHOR: The draft's main author, Kim Kinnear, will post a meeting notice to the mailing list no later than early October. The format of the meeting will most likely be a conference call. DRAFT: DHCP Server MIB draft-ietf-dhc-server-mib-04.txt Presentor: Richard Barr Hibbs Barr stated that a new revision of this draft will be submitted in mid to late August. There have been delays due to disagreements over MIB content and implementation issues which are still in the process of resolution. The draft should be ready for WG Last Call after one more round of feedback on the upcoming revision, followed by a succeeding revision. It was asked whether or not the server MIB draft was considered a gating item for the DHCP protocol to go to Standard. Thomas stated that the IESG does not consider it so. ACTION ITEMS - Server MIB AUTHORS: prepare the next revision for submission before the end of August. DRAFT: DRCP draft-itsumo-drcp-00.txt Presentor: Subir Das Subir gave a detailed presentation on the Dynamic Registration and Configuration Protocol (DRCP). The primary objectives are improvement over DHCP in the areas of real-time speed, a reduction of bandwidth, and a minimization of broadcast usage. These objectives are primarily intended to benefit wireless- and mobility- oriented customers. The main differences of DRCP are: significantly reduced packet size, the possibility for a two-message rather than four-message exchange, and a difference in header format between client-to-server and server-to-client messages. The draft is still in its early stages. Subir stated that the authors are still working to refine their objectives and debating basic issues. The group responded by asking how many of these ideas could be considered for incorporation into the existing DHCP protocol. It was also pointed out that many of the ideas presented in this draft have interesting possibilities with regard to the DHCPv6 drafts. ACTION ITEMS - DRCP AUTHORS: The draft authors will work with Ralph to prepare a list of DRCP features that might be candidates for integration with the existing protocol. This will be submitted to the mailing list (time frame was not specified) for discussion. ------------------------------------------------------------------- Tuesday, Aug 1 at 0900-1130 (DHCPv6) ==================================== Meeting Manager: Ralph Droms (WG Chair) Presenter: Mike Carney, with Charlie Perkins and Jim Bound The agenda was: 1. Determine the DHCPv6 I-D drafts' readership 2. Discuss open issues with the drafts 3. Determine the next step for the drafts Mike established that fewer than ten per cent of the meeting attendees have read the latest DHCPv6 drafts, which were published in May of this year (draft-ietf-dhc-dhcpv6-15.txt, and draft-ietf-dhc-dhchpv6exts-12.txt). OPEN ISSUES Issue 1: Releasable resources Mike referred to a discussion section in the draft that treats the use of 'releasable resources' in a generic manner. In fact, the only releasable resource currently defined is IP address. There was a concern that the draft's treatment of the subject may be confusing, so Mike asked the group if the text should be changed. There was no comment, so the text remains as is. Issue 2: Client requests for multiple addresses, and any-time requests for addresses/parameters The draft protocol allows for, but does not require, that clients be capable of requesting multiple addresses in a transaction, and that they be able to contact a server and request addresses and/or parameters at any time. There was agreement that this adds complexity to the draft (see Complexity issue below). There was not consensus on whether or not this constitutes a gating issue, or how (or if) it should be approached. Issue 3: Client requests to multiple servers The draft protocol allow for, but does not require, that clients be able to make requests for addresses and parameters to different servers. When asked, Mike asserted that the capability was optional. Jim asserted that the draft is sufficiently clear on this. Mike suggested that the draft be reorganized to have clear sections for a 'core', or minimal, application of the protocol, followed by clearly-delineated sections describing more sophisticated possibilities. One meeting participant agreed strongly. There were no dissenting opinions. Issue 4: Dynamic client reconfiguration Mike asked the group if this issue has been adequately treated in the draft. He mentioned the two sections discussing passive and active renumbering scenarios, including the ability to limit the number of reconfigured clients by using recyclable multicast addresses. One comment was that the number of clients to be reconfigured may not be known beforehand, making the use of multicast difficult. The matter was left for further consideration. Issue 5: Clients, Duplicate Address Detection and address release The draft calls for clients who deduce address conflicts using a DAD mechanism to send a release message to the server, using a 'bad address' status. Mike asked the group if this would be adequate. There was no comment, so it was assumed to be okay. Issue 6: Enumeration of legal extensions for each message type Mike asked the group if the draft should explicitly list all valid extensions for each message type. It was pointed out that this approach doesn't scale well when new extensions are adopted. The suggestion was made and approved that the draft follow the technique of the DHCPv4 failover draft, which lists the 'options' that are mandatory for each message type, the 'options' that must NOT be supplied, and leaves all others as 'optional'. Issue 7: Multi-link subnets are explicitly not supported Mike asked the group for consensus on the explicit non-support in the draft for multi-link subnets. It was suggested that since the real issue here is that client DAD does not work in this case, that specific language be added to the draft to explain the non-support's motivation. Suggestion was approved. Issue 8: Do extensions need to be padded or aligned? Mike asserted that extensions are explicitly not to be padded, since the length field of an extension makes their size clear. String instances of extensions are not to be null terminated, and byte- or bit-alignment is not a requirement. It was suggested and approved that specific language to this effect be added to the extensions draft. Issue 9: Relay agents are not allowed to modify the contents of a message in flight. Mike asked the group if this was too restrictive. The consensus was that it is too restrictive, especially in the light of the DHCPv4 relay agent option (currently draft status) that explicitly has a relay agent adding to the 'options' field of a message. However, it was strongly suggested that language be added to the draft stating that having a relay agent modify a message has major implications for end-to-end authentication and integrity checking. Issue 10: More detailed description of client behavior when a transaction fails The draft currently provides little direction for clients when they receive a non-zero status after a transaction. Charlie stated that there is no protocol mechanism for this instance, and asked the group for guidance. There were suggestions made for and against having the client 'call somebody', with no clear agreement. There was agreement, though, that there should be a detailed mapping between error status values and some form of human-interpretable message, to make troubleshooting a reasonable proposition. Issue 11: Which method of DHCP authentication should be used? The current DHCPv6 draft has provisions for authentication methods. Mike asked the group to decide if these should stay, or if another method should be referenced. The consensus appeared to be that the draft's authentication mechanism should be removed and the current V4 DHCP authentication draft should be referenced. This draft is due to be considered for Proposed Standard by the IESG in the near future, and was considered a good bet. Ralph cautioned that things such as a relay agent modifying a message must be dealt with explicitly in the v6 draft. It was also suggested that a section be added to the extensions draft covering the translation from DHCPv4 option format to v6 extension format for the proposed authentication option. Issue 12: Implementation state diagrams Mike stated that there had been a request for state diagrams, but they have not been drawn up yet. The suggestion was made that the term 'implementation' is misleading, and should be changed. The term 'protocol state diagram' was suggested. There appeared to be consensus on that name. Issue 13: The extension carrying the DHCPv6 protocol version is missing Issue 14: Almost no feedback on the draft. Why? This issue was discussed in several ways throughout the meeting. There are several important sub-issues, which appeared to break down into two main themes: protocol complexity, and working group process. Protocol complexity There were several complaints concerning the complexity of the draft, and the difficulty of reviewing it. While it was pointed out that there are many more complicated drafts and standards, it was acknowledged that this draft could stand to be organized more clearly along the lines of what is 'core' protocol and what is 'allowable to a sophisticated client'. There did not appear to be consensus on whether or how this should be done, largely due to perceived serious time constraints on getting the draft to Proposed Standard. There were also many perceived 'barriers to implementation'. One problem cited was that of determining the 'core protocol'. Another was the perception of unnecessary complexity, e.g. the different header sizes for each message, and the potential presence or absence of header fields based on bit flags in the same header. The draft also leads people to infer that there is an API implied that interfaces applications and a DHCPv6 client. The authors agreed with this, but did not agree on how or whether the 'implicit' API should be treated in the draft. Two current implementations of the protocol were cited; one that exercises the 'full' protocol, and one that is partial. It was strongly pointed out that many more implementations are needed asap to gain more knowledge of the protocol's strengths and weaknesses. It was also pointed out that interoperability is crucial to the success or failure of the protocol. Working group process Observations were made that some non-author working group members feel that historically the DHCPv6 process has been non-inclusive, and that feedback, when given, has not been acknowledged or acted upon. The authors agreed to seriously consider this issue, and look quickly for solutions. Ralph suggested that perhaps the group should go back to an analysis of the differences between DHCPv4 and v6 in an effort to solidify and simplify the v6 draft. This was favored by some and viewed as a likely distraction by others, so consensus was not reached. It was pointed out that IPV6 development is accelerating rapidly. The time frame of six months was given as a practical limit for getting a Proposed Standard for DHCPv6 with much hope of having it be widely implemented. While the exact time frame was not agreed upon, there seemed to be consensus that there is not sufficient time for another major draft revision. It was suggested that an interim meeting between seriously concerned group members be scheduled approximately three weeks from this meeting date (around Aug. 21, 2000). Meeting participants are expected to have thoroughly studied the drafts, and to have well organized lists of expectations for how to proceed from here, so the next steps can be negotiated. ACTION ITEMS Issue 1: no action to be taken. Issue 2: no consensus. This remains a major open issue. Issue 3: no action to be taken. Issue 4: further consideration is needed to decide if the current draft's treatment of the issue is adequate. Issue 5: no action to be taken (draft language to be left as is). Issue 6: revise the extensions draft to use the enumeration technique suggested. Issue 7: add language to the protocol draft to express the reason for explicitly not supporting multi-link subnets. Issue 8: add language to the extensions draft reinforcing the length parameter's use, non-null termination of strings, and that byte- or word- alignment is not a requirement. Issue 9: change draft language to allow relay agents to modify messages in flight, but add strong cautionary language concerning the implications to authentication and integrity checks. Issue 10: solicit group input on client behavior in the case of 'transaction failure'. In the meantime, provide human-interpretable feedback that maps directly to the possible 'bad' status values. Issue 11: remove sections of the protocol draft specifying authentication behavior, and replace with a reference to the DHCPv4 authentication draft. Add language to the extensions draft making the translation from DHCPv4 'options' to v6 'extensions' to support the authentication draft, and add language concerning message fields that must be zeroed for integrity checks. This includes specific language dealing with the DHCPv4 relay agent option (currently draft). Issue 12: create 'Protocol State Diagrams'. Issue 13: add the protocol version extension to the extension draft. Issue 14: ALL CONCERNED GROUP MEMBERS: study the draft (if not already done), and prepare a list of concerns, suggestions and expectations. Prepare for an interim meeting, either in person or via conference call, towards the end of August, 2000. AUTHORS: consider methods of 'outreach' in order to get quality feedback in sufficient quantity. Ralph has offered to consult with the authors on ways to do this. From owner-dhcp-v4@bucknell.edu Mon Aug 28 13:11:14 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16118 for ; Mon, 28 Aug 2000 13:11:12 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e7SH6Li13227; Mon, 28 Aug 2000 13:06:21 -0400 (EDT) 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 e7SH64i01837; Mon, 28 Aug 2000 13:06:04 -0400 (EDT) Received: from rdroms-nt.bucknell.edu (ch2-dhcp133-127.cisco.com [161.44.133.127]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id NAA26215; Mon, 28 Aug 2000 13:05:17 -0400 (EDT) Message-Id: <4.3.1.2.20000828125813.00b5fa70@funnel.cisco.com> X-Sender: droms@mail.bucknell.edu X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Mon, 28 Aug 2000 12:58:35 -0400 To: DHCPv4 discussion list From: Ralph Droms Subject: Minutes from DHC WG meetings in Pittsburgh Cc: dhcp-v4@bucknell.edu, dhcp-v6@bucknell.edu 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 Here are the minutes from the DHC (Dynamic Host Configuration) working group meetings in Pittsburgh, PA. - Ralph Droms ===== Meeting Manager: Ralph Droms (WG Chair) Minutes prepared by: Richard Jones Monday, Jul 31 at 1930-2200 (DHCPv4) ==================================== ANNOUNCEMENTS Ralph officially announced that he has taken a position with Cisco Systems in the Boston area. He has taken a one year leave of absence from Bucknell University, but expects it to extend beyond that time frame. He stated that acting as DHCP Working Group Chair is now officially a part of his job, so expects to devote more time to it. ACTIVITIES RFC 2855 (DHCP for IEEE 1394) is accepted by the IESG as a Proposed Standard. Drafts draft-ietf-dhc-nsso-05.txt and draft-ietf-dhc-authentication-14.txt have been submitted to the IESG for considerations as Proposed Standards. draft-ietf-dhc-new-opt-msg-02.txt is accepted by the IESG as a Best Current Practice (BCP) document. The following drafts have been returned, with comments, by the IESG for further revision: draft-ietf-dhc-subnet-option-06.txt draft-ietf-dhc-userclass-09.txt draft-ietf-dhc-pv4-reconfigure-01.txt will be revised based on feedback from WG Last Call before being submitted to the IESG. The DHCPv6 specification and the server-to-server drafts are currently under construction. DRAFT OPEN ISSUES Draft: DHCP-DNS Interaction Presenter: Mark Stapp The original draft has been broken out into two drafts, based on feedback from the Adelaide IETF meeting: the 'fqdn draft', draft-ietf-dhc-fqdn-option-00.txt, and the 'resolution' draft, draft-ietf-dhc-ddns-resolution-00.txt. The resolution draft references a dnsext draft, draft-ietf-dnsext-dhcid-rr-00.txt, which refreshes an expired draft. It is expected that these drafts will undergo one or more revisions before being ready for WG Last Call. It was suggested that a bit flag be added to the fqdn option format that allows a client to request that the server do no DNS updating at all for this request. Current option flags only specify that the client can request the server not update the A RR. The consensus was that this is fine, but that the server reserve the right to override the client request. It was suggested that the DHCID Resource Record be encoded in Base 64 rather than hexadecimal format. This was agreed upon, with Andreas Gustoffson volunteering to provide existing 'boilerplate' documentation for this provision. The question of having the server update other RR's than the A and PTR records was raised again. Also, the possible need for multiple PTR records was raised. It was agreed that these need to be discussed on the mailing list in greater detail. The question of whether or not a client can send multiple fqdn options in a request was raised. The prevailing opinion seemed to be opposed to this, especially since the current convention for multiple options in a DHCP packet only deals with options having lengths greater than the maximum option size, meaning that the values of all the multiple options are concatenated (which would not be the case here). This question will also be referred back to the list. Mark placed the following issues before the group: 1. Was the draft division the right thing to do? 2. Are there use cases (or scenarios) that need to be added to the resolution draft? 3. Who has implementation experiences they can share that will contribute to refining the draft? ACTION ITEMS - DHCP-DNS interaction AUTHOR: Add the flag bit to the fqdn option as requested. Change the encoding scheme for the DHCID RR as requested. Initiate mailing list discussions of the questions brought up in the meeting, and the ones the author brought to the meeting. Draft: DHCP Authentication using Kerberos draft-smedvinksy-dhc-kerbauth-00.txt Presentor: Poornima Lalwaney Poornima gave a detailed presentation of the draft. There is an existing Kerberos DHCP draft (draft-hornstein-dhc-kerbauth-02.txt). Poornima contrasted the two drafts, stating that the Hornstein draft posits a tight coupling between the DHCP server and the Kerberos state machine(s). The Medvinksy draft de-couples the server to a large degree by placing initial key management responsibilities on an 'iakerb proxy', which is specified in a current kerberos draft (draft-ietf-cat-iakerb-03.txt). The Medvinsky draft proposes using the client's hardware address in AS_REQ and TGS_REQ host address fields by using a negative value in the 'host address type' field, as specified by the IAKERB draft. The 'source IP address' field would be left at 0. It was noted that in order for the Medvinsky draft to succeed, the iakerb proxy draft must be modified. The proxy draft implies (but doesn't state explicitly) that the GSS API must be used to access proxy mechanisms. The Medvinsky draft would extend the proxy draft to allow 'raw' kerberos messages to be handled by the proxy as well. Ted Lemon advocated adoption of the Hornstein draft, because he feels that requiring modification of server behavior is preferable to requiring modification of client and/or relay behavior. It was noted that the authors of the Hornstein draft are not moving it forward; Ted offered to assume that responsibility. It was noted that there is not currently working group consensus on which draft to move forward. ACTION ITEMS - DHCP Authentication using Kerberos AUTHORS: The authors (or representatives) of both Kerberos drafts will prepare motivation/discussion documents that will be presented to the mailing list for discussion, with the goal of determining which draft should be moved forward. The documents will be available to the list by October 1, 2000, with this discussion to be resumed at the next IETF Meeting. WORKING GROUP CHARTER AND MILESTONES REVIEW Presentor: Ralph Droms The five main charter points were agreed upon by the group with the following changes/additions: 1. The issue of DHCP authentication is to be moved from a sub- category to a full charter requirement. 2. The LDAP and DHCP MIB projects will be added as full charter requirements. 3. The interaction between the DHCP WG and the IPV6 autoconf WG, while a major issue, is covered in the DHCPv6 charter point. The milestones list is outdated. Ralph will get date information from several people on the status of their respective drafts. Specific milestone issues include: a list of open issues concerning the review of the DHCP protocol for Standard is needed. This might be accomplished by publishing the list as an intermediate or informational I-D. The Classless Static Routes and NameServer Search drafts will shortly be ready for Working Group Last Call. The New Options Guidelines draft has been split into two drafts, and the goal is to have them ready for WG Last Call in the near future (i.e., before the next IETF meeting). ACTION ITEMS - Charter and Milestones AUTHOR: Ralph will modify the Charter and submit it to the list for comment. He will solicit date information from draft authors who are represented in the milestones list, update the milestones list and submit it to the list for comment. DRAFT: LDAP Schema draft-ietf-dhc-schema-02.txt Presentor: Bernie Volz A new version of this draft, based on detailed feedback from a couple of sources, will be issued in late August. ACTION ITEMS - LDAP Schema AUTHOR: will issue -03 version of the draft. DRAFT: Load Balancing draft-ietf-dhc-loadb-02.txt Presentor: Bernie Volz The -02 version of this draft has been published. It consists mostly of wording changes and cleanup. Bernie asks that this draft be sent to WG Last Call. DRAFT: Failover draft-ietf-dhc-failover-07.txt Presentor: Bernie Volz The -07 version of this draft has been published. It consists mostly of editorial changes, with minor technical changes. The draft's author was unable to attend, so discussion of the draft was postponed to the list, and likely to a conference call meeting to be held in the fall. Bernie stated that more discussion (and draft language) is needed to deal with the issue of reserved address handling, based on Cisco's current implementation experiences. The open issues, which are listed in the draft, are generally straightforward, and should be dealt with in the interim meeting. Area Director Thomas Narten stated that the IESG requires substantial advance notice for interim Working Group meetings, and a consideration of time constraints and convenience on a global level, to make working group meetings internationally inclusive. He clarified that this was not a criticism of the DHC group's handling of meetings, but rather a reiteration of requirements for how they should be announced and conducted. In general, meeting announcements should be made around a month in advance when possible, and in any case more than a week in advance. They should also try to take into account the problems of time zone differences between interested parties, in the case of conference calls. ACTION ITEMS - Failover AUTHOR: The draft's main author, Kim Kinnear, will post a meeting notice to the mailing list no later than early October. The format of the meeting will most likely be a conference call. DRAFT: DHCP Server MIB draft-ietf-dhc-server-mib-04.txt Presentor: Richard Barr Hibbs Barr stated that a new revision of this draft will be submitted in mid to late August. There have been delays due to disagreements over MIB content and implementation issues which are still in the process of resolution. The draft should be ready for WG Last Call after one more round of feedback on the upcoming revision, followed by a succeeding revision. It was asked whether or not the server MIB draft was considered a gating item for the DHCP protocol to go to Standard. Thomas stated that the IESG does not consider it so. ACTION ITEMS - Server MIB AUTHORS: prepare the next revision for submission before the end of August. DRAFT: DRCP draft-itsumo-drcp-00.txt Presentor: Subir Das Subir gave a detailed presentation on the Dynamic Registration and Configuration Protocol (DRCP). The primary objectives are improvement over DHCP in the areas of real-time speed, a reduction of bandwidth, and a minimization of broadcast usage. These objectives are primarily intended to benefit wireless- and mobility- oriented customers. The main differences of DRCP are: significantly reduced packet size, the possibility for a two-message rather than four-message exchange, and a difference in header format between client-to-server and server-to-client messages. The draft is still in its early stages. Subir stated that the authors are still working to refine their objectives and debating basic issues. The group responded by asking how many of these ideas could be considered for incorporation into the existing DHCP protocol. It was also pointed out that many of the ideas presented in this draft have interesting possibilities with regard to the DHCPv6 drafts. ACTION ITEMS - DRCP AUTHORS: The draft authors will work with Ralph to prepare a list of DRCP features that might be candidates for integration with the existing protocol. This will be submitted to the mailing list (time frame was not specified) for discussion. ------------------------------------------------------------------- Tuesday, Aug 1 at 0900-1130 (DHCPv6) ==================================== Meeting Manager: Ralph Droms (WG Chair) Presenter: Mike Carney, with Charlie Perkins and Jim Bound The agenda was: 1. Determine the DHCPv6 I-D drafts' readership 2. Discuss open issues with the drafts 3. Determine the next step for the drafts Mike established that fewer than ten per cent of the meeting attendees have read the latest DHCPv6 drafts, which were published in May of this year (draft-ietf-dhc-dhcpv6-15.txt, and draft-ietf-dhc-dhchpv6exts-12.txt). OPEN ISSUES Issue 1: Releasable resources Mike referred to a discussion section in the draft that treats the use of 'releasable resources' in a generic manner. In fact, the only releasable resource currently defined is IP address. There was a concern that the draft's treatment of the subject may be confusing, so Mike asked the group if the text should be changed. There was no comment, so the text remains as is. Issue 2: Client requests for multiple addresses, and any-time requests for addresses/parameters The draft protocol allows for, but does not require, that clients be capable of requesting multiple addresses in a transaction, and that they be able to contact a server and request addresses and/or parameters at any time. There was agreement that this adds complexity to the draft (see Complexity issue below). There was not consensus on whether or not this constitutes a gating issue, or how (or if) it should be approached. Issue 3: Client requests to multiple servers The draft protocol allow for, but does not require, that clients be able to make requests for addresses and parameters to different servers. When asked, Mike asserted that the capability was optional. Jim asserted that the draft is sufficiently clear on this. Mike suggested that the draft be reorganized to have clear sections for a 'core', or minimal, application of the protocol, followed by clearly-delineated sections describing more sophisticated possibilities. One meeting participant agreed strongly. There were no dissenting opinions. Issue 4: Dynamic client reconfiguration Mike asked the group if this issue has been adequately treated in the draft. He mentioned the two sections discussing passive and active renumbering scenarios, including the ability to limit the number of reconfigured clients by using recyclable multicast addresses. One comment was that the number of clients to be reconfigured may not be known beforehand, making the use of multicast difficult. The matter was left for further consideration. Issue 5: Clients, Duplicate Address Detection and address release The draft calls for clients who deduce address conflicts using a DAD mechanism to send a release message to the server, using a 'bad address' status. Mike asked the group if this would be adequate. There was no comment, so it was assumed to be okay. Issue 6: Enumeration of legal extensions for each message type Mike asked the group if the draft should explicitly list all valid extensions for each message type. It was pointed out that this approach doesn't scale well when new extensions are adopted. The suggestion was made and approved that the draft follow the technique of the DHCPv4 failover draft, which lists the 'options' that are mandatory for each message type, the 'options' that must NOT be supplied, and leaves all others as 'optional'. Issue 7: Multi-link subnets are explicitly not supported Mike asked the group for consensus on the explicit non-support in the draft for multi-link subnets. It was suggested that since the real issue here is that client DAD does not work in this case, that specific language be added to the draft to explain the non-support's motivation. Suggestion was approved. Issue 8: Do extensions need to be padded or aligned? Mike asserted that extensions are explicitly not to be padded, since the length field of an extension makes their size clear. String instances of extensions are not to be null terminated, and byte- or bit-alignment is not a requirement. It was suggested and approved that specific language to this effect be added to the extensions draft. Issue 9: Relay agents are not allowed to modify the contents of a message in flight. Mike asked the group if this was too restrictive. The consensus was that it is too restrictive, especially in the light of the DHCPv4 relay agent option (currently draft status) that explicitly has a relay agent adding to the 'options' field of a message. However, it was strongly suggested that language be added to the draft stating that having a relay agent modify a message has major implications for end-to-end authentication and integrity checking. Issue 10: More detailed description of client behavior when a transaction fails The draft currently provides little direction for clients when they receive a non-zero status after a transaction. Charlie stated that there is no protocol mechanism for this instance, and asked the group for guidance. There were suggestions made for and against having the client 'call somebody', with no clear agreement. There was agreement, though, that there should be a detailed mapping between error status values and some form of human-interpretable message, to make troubleshooting a reasonable proposition. Issue 11: Which method of DHCP authentication should be used? The current DHCPv6 draft has provisions for authentication methods. Mike asked the group to decide if these should stay, or if another method should be referenced. The consensus appeared to be that the draft's authentication mechanism should be removed and the current V4 DHCP authentication draft should be referenced. This draft is due to be considered for Proposed Standard by the IESG in the near future, and was considered a good bet. Ralph cautioned that things such as a relay agent modifying a message must be dealt with explicitly in the v6 draft. It was also suggested that a section be added to the extensions draft covering the translation from DHCPv4 option format to v6 extension format for the proposed authentication option. Issue 12: Implementation state diagrams Mike stated that there had been a request for state diagrams, but they have not been drawn up yet. The suggestion was made that the term 'implementation' is misleading, and should be changed. The term 'protocol state diagram' was suggested. There appeared to be consensus on that name. Issue 13: The extension carrying the DHCPv6 protocol version is missing Issue 14: Almost no feedback on the draft. Why? This issue was discussed in several ways throughout the meeting. There are several important sub-issues, which appeared to break down into two main themes: protocol complexity, and working group process. Protocol complexity There were several complaints concerning the complexity of the draft, and the difficulty of reviewing it. While it was pointed out that there are many more complicated drafts and standards, it was acknowledged that this draft could stand to be organized more clearly along the lines of what is 'core' protocol and what is 'allowable to a sophisticated client'. There did not appear to be consensus on whether or how this should be done, largely due to perceived serious time constraints on getting the draft to Proposed Standard. There were also many perceived 'barriers to implementation'. One problem cited was that of determining the 'core protocol'. Another was the perception of unnecessary complexity, e.g. the different header sizes for each message, and the potential presence or absence of header fields based on bit flags in the same header. The draft also leads people to infer that there is an API implied that interfaces applications and a DHCPv6 client. The authors agreed with this, but did not agree on how or whether the 'implicit' API should be treated in the draft. Two current implementations of the protocol were cited; one that exercises the 'full' protocol, and one that is partial. It was strongly pointed out that many more implementations are needed asap to gain more knowledge of the protocol's strengths and weaknesses. It was also pointed out that interoperability is crucial to the success or failure of the protocol. Working group process Observations were made that some non-author working group members feel that historically the DHCPv6 process has been non-inclusive, and that feedback, when given, has not been acknowledged or acted upon. The authors agreed to seriously consider this issue, and look quickly for solutions. Ralph suggested that perhaps the group should go back to an analysis of the differences between DHCPv4 and v6 in an effort to solidify and simplify the v6 draft. This was favored by some and viewed as a likely distraction by others, so consensus was not reached. It was pointed out that IPV6 development is accelerating rapidly. The time frame of six months was given as a practical limit for getting a Proposed Standard for DHCPv6 with much hope of having it be widely implemented. While the exact time frame was not agreed upon, there seemed to be consensus that there is not sufficient time for another major draft revision. It was suggested that an interim meeting between seriously concerned group members be scheduled approximately three weeks from this meeting date (around Aug. 21, 2000). Meeting participants are expected to have thoroughly studied the drafts, and to have well organized lists of expectations for how to proceed from here, so the next steps can be negotiated. ACTION ITEMS Issue 1: no action to be taken. Issue 2: no consensus. This remains a major open issue. Issue 3: no action to be taken. Issue 4: further consideration is needed to decide if the current draft's treatment of the issue is adequate. Issue 5: no action to be taken (draft language to be left as is). Issue 6: revise the extensions draft to use the enumeration technique suggested. Issue 7: add language to the protocol draft to express the reason for explicitly not supporting multi-link subnets. Issue 8: add language to the extensions draft reinforcing the length parameter's use, non-null termination of strings, and that byte- or word- alignment is not a requirement. Issue 9: change draft language to allow relay agents to modify messages in flight, but add strong cautionary language concerning the implications to authentication and integrity checks. Issue 10: solicit group input on client behavior in the case of 'transaction failure'. In the meantime, provide human-interpretable feedback that maps directly to the possible 'bad' status values. Issue 11: remove sections of the protocol draft specifying authentication behavior, and replace with a reference to the DHCPv4 authentication draft. Add language to the extensions draft making the translation from DHCPv4 'options' to v6 'extensions' to support the authentication draft, and add language concerning message fields that must be zeroed for integrity checks. This includes specific language dealing with the DHCPv4 relay agent option (currently draft). Issue 12: create 'Protocol State Diagrams'. Issue 13: add the protocol version extension to the extension draft. Issue 14: ALL CONCERNED GROUP MEMBERS: study the draft (if not already done), and prepare a list of concerns, suggestions and expectations. Prepare for an interim meeting, either in person or via conference call, towards the end of August, 2000. AUTHORS: consider methods of 'outreach' in order to get quality feedback in sufficient quantity. Ralph has offered to consult with the authors on ways to do this. From owner-dhcp-v6@bucknell.edu Mon Aug 28 14:05:28 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17285 for ; Mon, 28 Aug 2000 14:05:21 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e7SHxri27249; Mon, 28 Aug 2000 14:01:07 -0400 (EDT) Received: from zmamail02.zma.compaq.com (zmamail02.zma.compaq.com [161.114.64.102]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e7SHxpi03526 for ; Mon, 28 Aug 2000 13:59:51 -0400 (EDT) Received: by zmamail02.zma.compaq.com (Postfix, from userid 12345) id 094B3C5E; Mon, 28 Aug 2000 13:59:36 -0400 (EDT) Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by zmamail02.zma.compaq.com (Postfix) with ESMTP id EC827E00 for ; Mon, 28 Aug 2000 13:59:35 -0400 (EDT) Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM) id NAA0001019489; Mon, 28 Aug 2000 13:59:22 -0400 (EDT) From: Jim Bound Message-Id: <200008281759.NAA0001019489@anw.zk3.dec.com> To: DHCPv6 discussion list Subject: RESEND: DHCPv6 State Diagrams Date: Mon, 28 Aug 2000 13:59:21 -0400 X-Mts: smtp 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 >Jim - I can't seem to access this file either through the URL or through >anonymous ftp. sipper.zk3.dec.com doesn't seem to allow anonymous FTP. > >- - Ralph Thanks Ralph... Sorry I sent this at 1 a.m...!!! >At 01:02 AM 8/28/00 -0400, you wrote: > >>My hope is these are useful for Thursday meeting. >> >>ftp:://sipper.zk3.dec.com/pub/dhcpv6_state.ppt >> >>Or you can anonymous ftp too. >> >>I will provide PDF version Monday night if you can't do .ppt's. >> Should have been: ftp:://sipper.zk3-x.dec.com/pub/dhcpv6_state.ppt I will add PDF version tonight. thanks /jim From owner-dhcp-v6@bucknell.edu Mon Aug 28 15:30:22 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19011 for ; Mon, 28 Aug 2000 15:30:21 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e7SJQii11702; Mon, 28 Aug 2000 15:26:44 -0400 (EDT) Received: from zmamail01.zma.compaq.com (zmamail01.zma.compaq.com [161.114.64.101]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e7SJQHi28451 for ; Mon, 28 Aug 2000 15:26:21 -0400 (EDT) Received: by zmamail01.zma.compaq.com (Postfix, from userid 12345) id 80CB42259; Mon, 28 Aug 2000 15:26:00 -0400 (EDT) Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by zmamail01.zma.compaq.com (Postfix) with ESMTP id 5598A23B0; Mon, 28 Aug 2000 15:26:00 -0400 (EDT) Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM) id PAA0001030265; Mon, 28 Aug 2000 15:24:24 -0400 (EDT) From: Jim Bound Message-Id: <200008281924.PAA0001030265@anw.zk3.dec.com> To: DHCPv6 discussion list Cc: reinhard.scholl@etsi.fr Subject: UPDATE: IPv6 ETSI Test Event Web Page Pointer Date: Mon, 28 Aug 2000 15:24:23 -0400 X-Mts: smtp 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 ** PLEASE DO NOT RESPOND TO THIS MAIL ** Folks, Just wanted to add that the test/interoperability suites that will be done for the attached will include test suites from Ericsson provided to Francis Dupont and his team. It will not just be a last minute effort for testing but a well thought out group of test assertions and procedures. Thank You Ericsson for your assistance on this IPv6 implementation effort. thanks /jim -------------------------------- Hi Folks, Even though UNH cannot participate in this test event our colleagues under the guidance of Francis Dupont at ENST in France have come to the aid of IPv6 developers (thank you ENST and Francis) and working with Reihhard Scholl there will be an IPv6 test event Oct 2-6. I believe this is a very important event and vendors should really try to attend. Plus it is in a nice place "French Riviera" not that there won't be a lot of hard work done of course. This is serious stuff folks and 3GPP needs our support and this test event. Please see the following URL: http://www.etsi.org/bake-off regards and thanks for your support, /jim From owner-dhcp-v4@bucknell.edu Mon Aug 28 16:07:48 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19715 for ; Mon, 28 Aug 2000 16:07:48 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e7SK43i01363; Mon, 28 Aug 2000 16:04:03 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e7SK3wi25443 for ; Mon, 28 Aug 2000 16:04:00 -0400 (EDT) Received: from grosse.bisbee.fugue.com (dhcp-226.rc.vix.com [204.152.187.226]) by toccata.fugue.com (8.9.3/8.6.11) with ESMTP id TAA21831; Sun, 27 Aug 2000 19:10:38 -0700 (PDT) Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.9.3+3.2W/8.6.11) with ESMTP id NAA09944; Mon, 28 Aug 2000 13:01:58 -0700 (MST) Message-Id: <200008282001.NAA09944@grosse.bisbee.fugue.com> To: DHCPv4 discussion list cc: DHCPv4 discussion list Subject: Re: Failover and DHC load balancing algorithm In-Reply-To: Message from Bernie Volz of "Mon, 28 Aug 2000 09:56:11 -0400." <63D30D6E10CFD11190A90000F805FE8602BEC047@lespaul.process.com> Date: Mon, 28 Aug 2000 13:01:58 -0700 From: Ted Lemon Reply-To: mellon@nominum.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN > There are several implementations of the failover protocol. Ted Lemon has > been working on adding that support to the ISC DHCP Server. We do have load balancing. I just used the algorithm in the draft. :') _MelloN_ From owner-dhcp-v6@bucknell.edu Mon Aug 28 16:10:30 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19744 for ; Mon, 28 Aug 2000 16:10:30 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e7SK98i30221; Mon, 28 Aug 2000 16:09:08 -0400 (EDT) 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 e7SK93i03434 for ; Mon, 28 Aug 2000 16:09:03 -0400 (EDT) Received: from rdroms-nt.bucknell.edu (ch2-dhcp133-127.cisco.com [161.44.133.127]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id QAA23157; Mon, 28 Aug 2000 16:08:47 -0400 (EDT) Message-Id: <4.3.1.2.20000828160855.00b55510@mail.bucknell.edu> X-Sender: droms@mail.bucknell.edu X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Mon, 28 Aug 2000 16:09:11 -0400 To: DHCPv6 discussion list From: Ralph Droms Subject: Re: RESEND: DHCPv6 State Diagrams In-Reply-To: <200008281759.NAA0001019489@anw.zk3.dec.com> 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 Thanks, Jim. That new URL works fine. - Ralph At 01:59 PM 8/28/00 -0400, Jim Bound wrote: > >Jim - I can't seem to access this file either through the URL or through > >anonymous ftp. sipper.zk3.dec.com doesn't seem to allow anonymous FTP. > > > >- - Ralph > >Thanks Ralph... Sorry I sent this at 1 a.m...!!! > > >At 01:02 AM 8/28/00 -0400, you wrote: > > > >>My hope is these are useful for Thursday meeting. > >> > >>ftp:://sipper.zk3.dec.com/pub/dhcpv6_state.ppt > >> > >>Or you can anonymous ftp too. > >> > >>I will provide PDF version Monday night if you can't do .ppt's. > >> > >Should have been: > >ftp:://sipper.zk3-x.dec.com/pub/dhcpv6_state.ppt > >I will add PDF version tonight. > >thanks >/jim From owner-dhcp-v4@bucknell.edu Mon Aug 28 17:18:18 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20719 for ; Mon, 28 Aug 2000 17:18:17 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e7SLFBi10724; Mon, 28 Aug 2000 17:15:11 -0400 (EDT) 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 e7SLEvi18454 for ; Mon, 28 Aug 2000 17:14:57 -0400 (EDT) Received: from rdroms-nt.bucknell.edu (ch2-dhcp133-127.cisco.com [161.44.133.127]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id RAA01198; Mon, 28 Aug 2000 17:13:54 -0400 (EDT) Message-Id: <4.3.1.2.20000828171229.00b89d60@mail.bucknell.edu> X-Sender: droms@mail.bucknell.edu X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Mon, 28 Aug 2000 17:15:48 -0400 To: DHCPv4 discussion list From: Ralph Droms Subject: Re: Finding servers In-Reply-To: <383592926.967124272975.JavaMail.root@web277-ec> 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 09:37 AM 8/24/00 -0400, Rajeev Chawla wrote: >Can I use DHCP to find all servers of a certain type, if I manually >configure the IP addresses of these servers on the DHCP server? Depending on the option (some options can only carry the address of one server), the DHCP server will send back a list of the servers configured for that option. > My >understanding is that I will have to modify the DHCP client on my client >devices to get these addresses from the DHCP server using 'Vendor Specific >Information' option and 'dhcpinform'. You may need to do a little research to find out how your particular client makes the parameters in DHCP options available to application programs. You shouldn't need to use the vendor specific option and DHCPINFORM. >Can the servers dynamically register with the DHCP server (so that they >don't have to be manually configured and if they crash or become >unreachable, DHCP server can age out that information)? Getting the addresses of other servers into the DHCP server is outside the scope of the DHCP spec... - Ralph Droms From owner-dhcp-v6@bucknell.edu Mon Aug 28 21:46:42 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24282 for ; Mon, 28 Aug 2000 21:46:41 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e7T1hHi24528; Mon, 28 Aug 2000 21:43:17 -0400 (EDT) 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 e7T1h1i32212 for ; Mon, 28 Aug 2000 21:43:01 -0400 (EDT) Received: from rdroms-nt.cisco.com (rtp-dial-2-195.cisco.com [10.83.96.195]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id VAA20952 for ; Mon, 28 Aug 2000 21:42:43 -0400 (EDT) Message-Id: <4.3.1.2.20000828213942.00b616e0@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Mon, 28 Aug 2000 21:40:58 -0400 To: DHCPv6 discussion list From: Ralph Droms Subject: Design team teleconference on DHCPv6 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 of the original announcement. Be sure to contact me prior to the time of the teleconference to get the number and conference ID. - RD) Following up on the impromptu meeting on DHCPv6 in Pittsburgh, I've scheduled a DHCPv6 design team telephone-based teleconference for next Thursday, 8/31 between noon and 3PM, EDT. Our process for this teleconference will be based on Ted Lemon's plan for moving the DHCPv6 spec forward: (1) Everybody who is strongly interested is going to read the current draft over carefully, if they haven't already, or if only as a means of accomplishing (2): (2) Each of us is going to make a list of the things that are in the draft that aren't okay with us, and a list of things that are not in the draft that we would like to see in the draft. Criteria for inclusion (and design) or exclusion of a particular feature include: - Is this a feature clearly required in the next six months or can it be added as an extension later - Is this a feature new to DHCPv6 and is the feature required by IPv6 - Is the design of this feature based on DHCPv4 experience - What is the justification for features that differ from DHCPv4 design (3) We will each publish this information on the DHCPv6 mailing list. (4) Teleconference agenda: (a) Develop a list of specific changes to be made to the spec (b) Develop a timeline of milestones to be accomplished to bring the spec up for final WG review in San Diego Cisco System will host the teleconference with toll-free access within the U.S., and will be happy to reimburse those outside the U.S. for their calls. If you want to participate in the call on 8/31, please contact me for the phone number and conference ID. All participants will be expected to execute steps 1, 2 and 3 prior to next week's phone call, so I can put together a list of features that we can have on the table when we start talking at noon on 8/31. - Ralph From owner-dhcp-v6@bucknell.edu Tue Aug 29 00:06:10 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA26942 for ; Tue, 29 Aug 2000 00:06:10 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e7T42mi03427; Tue, 29 Aug 2000 00:02:49 -0400 (EDT) Received: from ztxmail01.ztx.compaq.com (ztxmail01.ztx.compaq.com [161.114.1.205]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e7T42Ui06201 for ; Tue, 29 Aug 2000 00:02:31 -0400 (EDT) Received: by ztxmail01.ztx.compaq.com (Postfix, from userid 12345) id D9B1C4263; Mon, 28 Aug 2000 23:02:14 -0500 (CDT) Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by ztxmail01.ztx.compaq.com (Postfix) with ESMTP id 65772126F for ; Mon, 28 Aug 2000 23:02:14 -0500 (CDT) Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM) id AAA0000596557; Tue, 29 Aug 2000 00:01:42 -0400 (EDT) From: Jim Bound Message-Id: <200008290401.AAA0000596557@anw.zk3.dec.com> To: DHCPv6 discussion list Subject: PDF DHCPv6 State Diagrams Date: Tue, 29 Aug 2000 00:01:40 -0400 X-Mts: smtp 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 ftp://sipper.zk3-x.dec.com/pub/dhcpv6_state.PDF /jim From owner-dhcp-v4@bucknell.edu Tue Aug 29 07:43:29 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13701 for ; Tue, 29 Aug 2000 07:43:28 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e7TBdDi23821; Tue, 29 Aug 2000 07:39:13 -0400 (EDT) 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 e7TBcvi10022; Tue, 29 Aug 2000 07:38:57 -0400 (EDT) Received: from efra05-home.Germany.Sun.COM ([129.157.43.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA15661; Tue, 29 Aug 2000 04:38:53 -0700 (PDT) Received: from vayne (muc-isdn-20 [129.157.164.120]) by efra05-home.Germany.Sun.COM (8.8.8+Sun/8.8.8/ENSMAIL,v1.9) with SMTP id NAA08058; Tue, 29 Aug 2000 13:38:50 +0200 (MET DST) Date: Tue, 29 Aug 2000 13:48:19 +0200 (MET DST) From: Erik Guttman Reply-To: Erik Guttman Subject: Re: Finding servers To: DHCPv4 discussion list Cc: droms@bucknell.edu, erik.guttman@germany.sun.com In-Reply-To: "Your message with ID" <4.3.1.2.20000828171229.00b89d60@mail.bucknell.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN > >Can the servers dynamically register with the DHCP server (so that they > >don't have to be manually configured and if they crash or become > >unreachable, DHCP server can age out that information)? > > Getting the addresses of other servers into the DHCP server is outside the > scope of the DHCP spec... You can discover services with the service location protocol (SLPv2 - RFC 2608). This protocol handles dynamic registration and allows a client to request not only service 'by type,' but also 'by characteristic.' The client can issue a request with a 'search filter' so that only services which have the right software version, are in the right location, have an account for the given user, etc. will match the request. Most important, only those services which are *actually available* on the network will be discovered. DHCP provides a subset of these features. On a network where administrators can keep track of which services are up or down at any given time, and which services each client should be assigned DHCP is a great solution. On networks where decentralized operation is desirable or there are many services of the same kind but with different characteristics SLP is a good alternative. Erik Guttman From owner-dhcp-v6@bucknell.edu Tue Aug 29 13:24:56 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26571 for ; Tue, 29 Aug 2000 13:24:54 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e7THIai22692; Tue, 29 Aug 2000 13:18:50 -0400 (EDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e7THIRi29380 for ; Tue, 29 Aug 2000 13:18:27 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id KAA17406 for ; Tue, 29 Aug 2000 10:18:20 -0700 (PDT) Date: Tue, 29 Aug 2000 13:18:00 -0400 (EDT) From: Ralph Droms To: DHCPv6 discussion list Subject: Things I want to see in DHCPv6 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 Part of the deal in prepping for Thursday's DHCPv6 design team phone call is to develop a list of "things we want to see" in DHCPv6. So, here's my list: 1. Address model: * One interface, with a single unique identifier, can be assigned multiple addresses * Server knows exactly what addresses to assign to client * Client asks for "configuration", which includes assigned addresses * Client may extend leases on addresses individually 2. Messages and semantics * Rename messages and change semantics to match RFC2131 * Use message exchanges from RFC2131 * Change formats to optimize message size and carry IPv6 addresses 3. Relay agents - adopt DHCPv4 function: relay agents insert itnerface address in 'giaddr' and forward to DHCP servers 4. Authentication - adopt DHCPv4 delayed authentication from latest I-D 5. Discard references to "releasable resources" 6. Use same options/extension in DHCPv4 and DHCPv6 7. Use DHCPv4-style reconfiguration Reading the drafts is a prerequisite to participating in Thursday's phone call. Posting your own "things I want to see" list would be a good way to demonstrate you've read the drafts and you're truly interested in participating. I'll collate any submissions into a list that I will publish prior to Thursday's meeting. We'll use that list as part of our formal agenda for the phone call. To avoid rat-holes, mailing list discussion of the *merits* of list items will be disallowed. Requests for clarification are OK and will help us get consensus on the list of features to talk about on Thursday. - Ralph From owner-dhcp-v4@bucknell.edu Tue Aug 29 14:07:35 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27599 for ; Tue, 29 Aug 2000 14:07:34 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e7TI2Hi31339; Tue, 29 Aug 2000 14:02:17 -0400 (EDT) Received: from Arachnid.NTRG.com ([209.31.7.46]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e7TI22i05323; Tue, 29 Aug 2000 14:02:02 -0400 (EDT) Received: from ehsco.com (ferret.ntrg.com [192.168.10.10]) by Arachnid.NTRG.com (Netscape Messaging Server 3.62) with ESMTP id 591; Tue, 29 Aug 2000 11:01:54 -0700 Message-ID: <39ABFA8E.46F78E64@ehsco.com> Date: Tue, 29 Aug 2000 11:01:50 -0700 From: "Eric A. Hall" Organization: EHS Company X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: DHCPv4 discussion list CC: DHCPv4 discussion list , droms@bucknell.edu Subject: Re: Finding servers References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Reply-To: ehall@ehsco.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit > You can discover services with the service location protocol (SLPv2 - > RFC 2608). This protocol handles dynamic registration and allows a > client to request not only service 'by type,' but also 'by > characteristic.' The client can issue a request with a 'search filter' > so that only services which have the right software version, are in > the right location, have an account for the given user, etc. will > match the request. Most important, only those services which are > *actually available* on the network will be discovered. It might be a useful feature for somebody to put an SLP listener into a DHCP server, which would also solve the original poster's objective. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From owner-dhcp-v6@bucknell.edu Wed Aug 30 00: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 ESMTP id AAA08084 for ; Wed, 30 Aug 2000 00:32:51 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e7U4Tei32050; Wed, 30 Aug 2000 00:29:40 -0400 (EDT) Received: from zmamail01.zma.compaq.com (zmamail01.zma.compaq.com [161.114.64.101]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e7U4TPi01097 for ; Wed, 30 Aug 2000 00:29:25 -0400 (EDT) Received: by zmamail01.zma.compaq.com (Postfix, from userid 12345) id B8AFB1917; Wed, 30 Aug 2000 00:29:09 -0400 (EDT) Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by zmamail01.zma.compaq.com (Postfix) with ESMTP id 9F33A1953 for ; Wed, 30 Aug 2000 00:29:09 -0400 (EDT) Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM) id AAA0000826091; Wed, 30 Aug 2000 00:28:56 -0400 (EDT) From: Jim Bound Message-Id: <200008300428.AAA0000826091@anw.zk3.dec.com> To: DHCPv6 discussion list Subject: Re: Things I want to see in DHCPv6 In-reply-to: Your message of "Tue, 29 Aug 2000 13:18:00 EDT." Date: Wed, 30 Aug 2000 00:28:55 -0400 X-Mts: smtp 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 Hi Ralph, I would like to submit my state diagrams for people to use for clarification of the existing message types as needed at the meeting so I would ask that attendees have them at hand. Can you give us an example of the format for discussion during the meeting. I would assume for anyone who wants to remove/change things in DHCPv6 they would need to state why and why whats there is not going to work. Likewise those who wnat to keep things in DHCPv6 would also have to do the same. They key is to have fair and equal exchange of views. thanks /jim From owner-dhcp-v4@bucknell.edu Wed Aug 30 06:55:45 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23684 for ; Wed, 30 Aug 2000 06:55:45 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e7UAqZi16317; Wed, 30 Aug 2000 06:52:35 -0400 (EDT) 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 e7UAqIi08405; Wed, 30 Aug 2000 06:52:19 -0400 (EDT) Received: from efra05-home.Germany.Sun.COM ([129.157.43.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA20800; Wed, 30 Aug 2000 03:52:16 -0700 (PDT) Received: from vayne (muc-isdn-13 [129.157.164.113]) by efra05-home.Germany.Sun.COM (8.8.8+Sun/8.8.8/ENSMAIL,v1.9) with SMTP id MAA15619; Wed, 30 Aug 2000 12:52:12 +0200 (MET DST) Date: Wed, 30 Aug 2000 13:01:41 +0200 (MET DST) From: Erik Guttman Reply-To: Erik Guttman Subject: Re: Finding servers To: DHCPv4 discussion list Cc: Erik Guttman , DHCPv4 discussion list , droms@bucknell.edu In-Reply-To: "Your message with ID" <39ABFA8E.46F78E64@ehsco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN > > > You can discover services with the service location protocol (SLPv2 - > > RFC 2608). This protocol handles dynamic registration and allows a > > client to request not only service 'by type,' but also 'by > > characteristic.' The client can issue a request with a 'search filter' > > so that only services which have the right software version, are in > > the right location, have an account for the given user, etc. will > > match the request. Most important, only those services which are > > *actually available* on the network will be discovered. > > It might be a useful feature for somebody to put an SLP listener into a > DHCP server, which would also solve the original poster's objective. SLP has 3 entities: A 'UA' which *actively* requests services, a 'SA' which *passively* listens for requests, a 'DA' which - if it exists - announces itself (this is the only entity which announces itself). If there is a DA, the UAs unicast requests to it, and the SAs register with it. A DHCP server could be collocated with a 'DA' so that it could list services which were 'actually present' on the network. There are three problems with this model, all of which are *minor*: (1) DHCP servers receive only requests for services 'by type' Which services should be returned to DHCP clients when SLP registers different services of the same type. All? Some? (2) SLP security would be advisable, so that DHCP servers couldn't be trivially tricked into configuring DHCP clients with bogus services. As DHCP itself is insecure this is not a big issue. (3) SLP registrations are soft state - that is a service advertisement is only good for some time. The only soft state configuration which DHCP manages is address configuration. SLP returns how long service locations can be cached. DHCP has no mechanism to do this. So there is a possibility that service configuration obtained by DHCP would be 'stale' - the client should then ask for the config information again. The client would have no way to detect this except by trying to contact the service and failing. It is a *very good idea* to allow access to service location information consistently across different protocols. I propose writing a draft for 'BCP' RFC status which describes how a single back-end can be used to store service locations for consistent retrieval using SLP, DHCP, LDAP and DNS SRV RRs. This might lead to a common 'SLP service template' and 'LDAP schema' for Internet Services to aid in interoperability between these different protocols. Is there interest in this draft in the DHC WG? Should I write this as an individual contribution or seek to do it in another WG? Erik From owner-dhcp-v6@bucknell.edu Wed Aug 30 08:45:36 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27214 for ; Wed, 30 Aug 2000 08:45:35 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e7UCgUi24603; Wed, 30 Aug 2000 08:42:30 -0400 (EDT) Received: from ztxmail02.ztx.compaq.com (ztxmail02.ztx.compaq.com [161.114.1.206]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e7UCgEi10764 for ; Wed, 30 Aug 2000 08:42:14 -0400 (EDT) Received: by ztxmail02.ztx.compaq.com (Postfix, from userid 12345) id ECE172B67; Wed, 30 Aug 2000 07:41:56 -0500 (CDT) Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by ztxmail02.ztx.compaq.com (Postfix) with ESMTP id 837FE2BAF for ; Wed, 30 Aug 2000 07:41:56 -0500 (CDT) Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM) id IAA0000897479; Wed, 30 Aug 2000 08:41:43 -0400 (EDT) From: Jim Bound Message-Id: <200008301241.IAA0000897479@anw.zk3.dec.com> To: DHCPv6 discussion list Subject: DHCPv6 Appendix A Date: Wed, 30 Aug 2000 08:41:43 -0400 X-Mts: smtp 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 Folks, This will be pretty relevant for the design meeting too. Also parts like Multicast, Reconfigure, DNS Updates, etc were all part of the inherent design of DHCPv6 not add-ons. I also want to stress the "integration" of Stateful in this case DHCPv6 with the stateless code base deployed now in the market for IPv6 and that it is also useful for IPv6 Transition. The code Francis Dupont sent out also questions the statement about complexity objectively, but then Francis is a key IPv6 implementor to and understands IPv6 very well. This code base should carry some weight in our thinking process. Also Mike Carney is one of the key implementors of DHCPv4, who clearly has a good handle on both protocols and why DHCPv6 vs DHCPv4 engineering trade-offs were made. A. Comparison between DHCPv4 and DHCPv6 This appendix is provided for readers who will find it useful to see a model and architecture comparison between DHCPv4 [7, 1] and DHCPv6. There are three key reasons for the differences: o IPv6 inherently supports a new model and architecture for communications and autoconfiguration of addresses. o DHCPv6 benefits from the new IPv6 features. o New features were added to support the expected evolution and the existence of more complicated Internet network service requirements. IPv6 Architecture/Model Changes: o The link-local address permits a node to have an address immediately when the node boots, which means all clients have a source IP address at all times to locate an on-link server or relay. o The need for BOOTP compatibility and the broadcast flag have been removed. o Multicast and address scoping in IPv6 permit the design of discovery packets that would inherently define their range by the multicast address for the function required. o Stateful autoconfiguration has to coexist and integrate with stateless autoconfiguration supporting Duplicate Address Detection and the two IPv6 lifetimes, to facilitate the dynamic renumbering of addresses and the management of those addresses. o Multiple addresses per interface are inherently supported in IPv6. o Some DHCPv4 options are unnecessary now because the configuration parameters are either obtained through IPv6 Neighbor Discovery or the Service Location protocol [16]. DHCPv6 Architecture/Model Changes: o The message type is the first byte in the packet. o IPv6 Address allocations are now handled in a message extension as opposed to the message header. o Client/Server bindings are now mandatory and take advantage of the client's link-local address to always permit communications either directly from an on-link server, or from a off-link server through an on-link relay. o Servers are discovered by a client Solicit, followed by a server Advertise message o The client will know if the server is on-link or off-link. o The on-link relay may locate off-link server addresses from system configuration or by the use of a site-wide multicast packet. o ACKs and NAKs are not used. o The server assumes the client receives its responses unless it receives a retransmission of the same client request. This permits recovery in the case where the network has faulted. o Clients can issue multiple, unrelated Request messages to the same or different servers. o The function of DHCPINFORM is inherent in the new packet design; a client can request configuration parameters other than IPv6 addresses in the optional extension headers. o Clients MUST listen to their UDP port for the new Reconfigure message from servers. o New extensions have been defined. With the changes just enumerated, we can support new user features, including o Configuration of Dynamic Updates to DNS o Address deprecation, for dynamic renumbering. o Relays can be preconfigured with server addresses, or use of multicast. o Authentication o Clients can ask for multiple IP addresses. o Addresses can be reclaimed using the Reconfigure-init message. o Integration between stateless and stateful address autoconfiguration. o Enabling relays to locate off-link servers. /jim From owner-dhcp-v6@bucknell.edu Wed Aug 30 10:15:19 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00120 for ; Wed, 30 Aug 2000 10:15:19 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e7UEC5i22540; Wed, 30 Aug 2000 10:12:20 -0400 (EDT) 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 e7UEC2i02788 for ; Wed, 30 Aug 2000 10:12:02 -0400 (EDT) Received: by lespaul.process.com with Internet Mail Service (5.5.2650.21) id ; Wed, 30 Aug 2000 10:11:46 -0400 Message-ID: <63D30D6E10CFD11190A90000F805FE8602BEC069@lespaul.process.com> From: Bernie Volz To: DHCPv6 discussion list Subject: RE: Things I want to see in DHCPv6 Date: Wed, 30 Aug 2000 10:11:40 -0400 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 I essentially agree with Ralph on his list. Here are some additions/comments. - Use of multicast instead of broadcast (I'm not sure what our "base" for the list of things is so this may already be assumed). - Use of "client identifier". As I understand it, the current DHCPv6 specification uses the client's link local address as the identifier for the client. However, with all of the generation techniques I recall for IPv6 link local addresses, this usually means it is based on the interface's hardware address or randomly generated (for privacy). Therefore, while perhaps a unique identifier, it certainly isn't a "permanent" identifier for the client and hence not that useful from an administrative point of view. That's what the idea behind the IPv4 client identifier was. Perhaps there was a reason this concept was dropped (if so, why is not documented in Appendix A of the DHCPv6 draft)? - Cleaner and simpler message formats. In the new DHCPv6 draft, too many bits being used as flags - should be using more extensions/options. Too tight packing is being used (while saving bits is good, I think it went too far). One case of a simpler messages ... in the current DHCPv6, on a solicit message a client can set a bit to get the prefix list back (as an extension). Why have this bit? Why not simply have the client include the ERE extension in the solicit to request the prefix list extension. Consider if we have 50 allocatable resources that require similar semantics - do we have 50 bits available? Seems to me that using the ERE in this case is much more consistent with the way DHCP should work. A few other examples: - 9-bit solicit id. Why not just use 16-bits? - Why move solicit-id location between a Solicit and Advertise message (better to leave in same bits)? - Solicit/Advertise/Request/Reply/Release all have a very similar header but they are all different. Can't we have one header for these? For example: 1-byte msg-type, 1-byte flags/reserved, 2-byte transaction id 16-byte client's link local 16-byte relay-addrses 16-byte server-address I do want to see smaller packet formats - the BOOTP legacy should be discarded (as it was in the current DHCPv6 design). - Avoid stateful server (in terms of the protocol interaction). I believe there are some holes in the DHCPv6 design in terms of the "releasing of resources". If a duplicated Request is received by a server immediately after sending a Reply with allocations, the server has to know this was duplicated otherwise it might release the assigned addresses (since the Reply contained an address assignment, but the duplicated Request tells the server to release this (and any other) resources). - There are also to many was to release resources. While I think it is a nice design to allow "all" resources to be released, I don't see a need to have a "release all but". If the client knows the resources it has, it can simply release those that it not longer needs instead of doing an "all but". If the client doesn't know what resources it has, the solicit with "release all" is great to get rid of any old resources. - Where appropriate, keep v4 and v6 options/extensions "the same". Use the same option numbers. Use the same format (except for 16-bit type/length). - Consider the DRCP requirements. The current DHCPv6 spec does address several of these, such as more compact messages. - Finally, if I had my choice, I'd like to see a DHCPng were ONE new protocol can accommodate IPv4 and IPv6 address assignments. The protocol would allow operation over either IPv4 or IPv6 and address assignments can be done at the same time (regardless of which transport is being used). In the short term, I think this would speed the deployment (one code base and with benefits to the IPv4 community). One could argue that the v4 capability eventually will not be required. I buy that, but how long do you believe that will take? Now, I don't see that as a major change to the current DHCPv6 design. We just need to have extensions that request IPv4 vs IPv6 addresses and either move all addresses (such as relay-agent, etc) into extensions instead of in the fixed header or have a means to identify the addresses (perhaps simply using the IPv6-mapped-IPv4 (or whatever they are called) addresses). Perhaps even that isn't required because the server would know if the packet was received over a v4 transport, they must be v4 addresses and if on a v6 transport, they must be v6 addresses. I also have one item that I feel needs clarification on Ralph's list: > * One interface, with a single unique identifier, can be assigned > multiple addresses In IPv6, does this mean one address per prefix on the "interface" (with multiple prefixes being supported) or does it mean that the client can also obtain MULTIPLE addresses for the same prefix. I would hope both. It is not clear exactly how this would easily be achieved - how to tell the difference between a duplicate request (without caching transaction ids) and a request for a second (or third...) address. If done in a single request, having multiple IP Address Extensions could be used. But if done in multiple requests, it is not as easy. I guess it might first be worthwhile to consider why we need this - sounds like a useful feature, but would it be used and for what reasons? - Bernie Volz IPWorks, Inc. -----Original Message----- From: Ralph Droms [mailto:rdroms@cisco.com] Sent: Tuesday, August 29, 2000 1:18 PM To: DHCPv6 discussion list Subject: Things I want to see in DHCPv6 Part of the deal in prepping for Thursday's DHCPv6 design team phone call is to develop a list of "things we want to see" in DHCPv6. So, here's my list: 1. Address model: * One interface, with a single unique identifier, can be assigned multiple addresses * Server knows exactly what addresses to assign to client * Client asks for "configuration", which includes assigned addresses * Client may extend leases on addresses individually 2. Messages and semantics * Rename messages and change semantics to match RFC2131 * Use message exchanges from RFC2131 * Change formats to optimize message size and carry IPv6 addresses 3. Relay agents - adopt DHCPv4 function: relay agents insert itnerface address in 'giaddr' and forward to DHCP servers 4. Authentication - adopt DHCPv4 delayed authentication from latest I-D 5. Discard references to "releasable resources" 6. Use same options/extension in DHCPv4 and DHCPv6 7. Use DHCPv4-style reconfiguration Reading the drafts is a prerequisite to participating in Thursday's phone call. Posting your own "things I want to see" list would be a good way to demonstrate you've read the drafts and you're truly interested in participating. I'll collate any submissions into a list that I will publish prior to Thursday's meeting. We'll use that list as part of our formal agenda for the phone call. To avoid rat-holes, mailing list discussion of the *merits* of list items will be disallowed. Requests for clarification are OK and will help us get consensus on the list of features to talk about on Thursday. - Ralph From owner-dhcp-v4@bucknell.edu Wed Aug 30 14:03:19 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06061 for ; Wed, 30 Aug 2000 14:03:18 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e7UHwXi20715; Wed, 30 Aug 2000 13:58:33 -0400 (EDT) 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 e7UHwOi27566 for ; Wed, 30 Aug 2000 13:58:24 -0400 (EDT) Received: from rdroms-nt.bucknell.edu (ch2-dhcp133-127.cisco.com [161.44.133.127]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id NAA07646; Wed, 30 Aug 2000 13:57:36 -0400 (EDT) Message-Id: <4.3.1.2.20000830135723.00b15e00@mail.bucknell.edu> X-Sender: droms@mail.bucknell.edu X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Wed, 30 Aug 2000 14:00:03 -0400 To: DHCPv4 discussion list From: Ralph Droms Subject: RE: Authentication option In-Reply-To: References: 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 I read Barr's suggested text for 5.5.1 and reviewed the relevant mailing list messages, and wrote up the following candidate text to replace the current text in 5.5.1 I've included BARR's text for comparison. - Ralph 5.5.1 INIT state When in INIT state, the client uses protocol 1 as follows: 1. The client MUST include the authentication request option in its DHCPDISCOVER message along with the client identifier option (option code 61) [6] to identify itself uniquely to the server. 2. The client MUST perform the validation test described in section 5.3 on any DHCPOFFER messages that include authentication information. If one or more DHCPOFFER messages pass the validation test, the client chooses one of the offered configurations. Client behavior if no DHCPOFFER messages include authentication information or pass the validation test is controlled by local policy in the client. According to client policy, the client MAY choose to respond to a DHCPOFFER message that has not been authenticated. The decision to set local policy to accept unauthenticated messages should be made with care. Accepting an unauthenticated DHCPOFFER message can make the client vulnerable to spoofing and other attacks. If local users are not explicitly informed that the client has accepted an unauthenticated DHCPOFFER message, the users may incorrectly assume that the client has received an authenticated address and is not subject to DHCP attacks through unauthenticated messages. A client MUST be configurable to decline unauthenticated messages, and SHOULD be configured by default to decline unauthenticated messages. A client MAY choose to differentiate between DHCPOFFER messages with no authentication information and DHCPOFFER messages that do not pass the validation test; for example, a client might accept the former and discard the latter. If a client does accept an unauthenticated message, the client SHOULD inform any local users and SHOULD log the event. 3. The client replies with a DHCPREQUEST message that MUST include authentication information encoded with the same secret used by the server in the selected DHCPOFFER message. 4. If the client authenticated the DHCPOFFER it accepted, the client MUST validate the DHCPACK message from the server. The client MUST discard the DHCPACK if the message fails to pass validation and MAY log the validation failure. If the DHCPACK fails to pass validation, the client MUST revert to INIT state and returns to step 1. The client MAY choose to remember which server replied with a DHCPACK message that failed to pass validation and discard subsequent messages from that server. If the client accepted a DHCPOFFER message that did nt include authentication information or did not pass the validation test, the client MAY accept an unauthenticated DHCPACK message from the server. At 02:21 PM 8/22/00 -0700, Barr Hibbs wrote: >Bill et al., > >I promised to try my hand at some text to cover the point about notification >of the user, so, here goes! > >--Barr > >=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- >=-=-=-= > >5.5.1 INIT state > > When in INIT state, the client uses protocol 1 as follows: > > 1. The client MUST include the authentication request option in > its DHCPDISCOVER message along with option 61 [6] to identify > itself uniquely to the server. > > 2. The client MUST validate any DHCPOFFER messages that include > authentication information using the mechanism specified in > section 5.3. The client MUST discard any messages which fail >***** to pass validation and MAY [SHOULD??] log the validation failure. > The client selects one DHCPOFFER message as its selected > configuration. If none of the DHCPOFFER messages received by > the client include authentication information, the client MAY > choose an unauthenticated message as its selected > configuration. The client SHOULD be configurable to accept or >***** reject unauthenticated DHCPOFFER messages. The client SHOULD >***** log the acceptance of an unauthenticated message if it decides >***** to choose one. > > 3. The client replies with a DHCPREQUEST message that MUST include > authentication information encoded with the same secret used by > the server in the selected DHCPOFFER message. > > 4. The client MUST validate the DHCPACK message from the server. > The client MUST discard the DHCPACK if the message fails to > pass validation and MAY log the validation failure. If the > DHCPACK fails to pass validation, the client MUST revert to > INIT state and returns to step 1. The client MAY choose to > remember which server replied with a DHCPACK message that > failed to pass validation and discard subsequent messages from >***** that server. If the client chooses to remember a failed >***** message authentication, it SHOULD log that decision, and >***** SHOULD revert to normal operation with respect to that server >***** after receiving a properly authenticated message from that server. > >5.5.2 INIT-REBOOT state > > When in INIT-REBOOT state, the client MUST use the secret it used > in its DHCPREQUEST message to obtain its current configuration to > generate authentication information for the DHCPREQUEST message. > The client MAY choose to accept unauthenticated DHCPACK/DHCPNAK > messages if no authenticated messages were received. The client > MUST treat the receipt (or lack thereof) of any DHCPACK/DHCPNAK >***** messages as specified in section 3.2 of [1]. If the client chooses >***** to accept unauthenticated messages from a server, it SHOULD log that >***** decision. From owner-dhcp-v6@bucknell.edu Wed Aug 30 14:22:34 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06327 for ; Wed, 30 Aug 2000 14:22:33 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e7UILEi07354; Wed, 30 Aug 2000 14:21:14 -0400 (EDT) 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 e7UIKwi17807 for ; Wed, 30 Aug 2000 14:20:59 -0400 (EDT) Received: from rdroms-nt.cisco.com (ch2-dhcp133-127.cisco.com [161.44.133.127]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA11358 for ; Wed, 30 Aug 2000 14:20:43 -0400 (EDT) Message-Id: <4.3.1.2.20000830141709.00b08b60@mail.bucknell.edu> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Wed, 30 Aug 2000 14:22:41 -0400 To: DHCPv6 discussion list From: Ralph Droms Subject: Re: Things I want to see in DHCPv6 In-Reply-To: <200008300428.AAA0000826091@anw.zk3.dec.com> References: 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 At 12:28 AM 8/30/00 -0400, Jim Bound wrote: >I would like to submit my state diagrams for people to use for >clarification of the existing message types as needed at the meeting so >I would ask that attendees have them at hand. Sure - just to make sure everyone has seen the URLs, the docs are at: ftp://sipper.zk3-x.dec.com/pub/dhcpv6_state.ppt and ftp://sipper.zk3-x.dec.com/pub/dhcpv6_state.PDF >Can you give us an example of the format for discussion during the >meeting. Following Ted's proposal, I expect to have a list of features to be includes or excluded. I'll put that list together and e-mail it to list participants Thursday AM. During the phone call, we'll discuss the features in the list one-by-one to determine consensus on the disposition of each feature. I imagine the author of each list item will take the lead in explaining his position first, with followup by others on the phone call. - Ralph From owner-dhcp-v4@bucknell.edu Wed Aug 30 15:12:53 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07505 for ; Wed, 30 Aug 2000 15:12:50 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e7UJ8Oi32070; Wed, 30 Aug 2000 15:08:24 -0400 (EDT) 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 e7UJ8Ki13623; Wed, 30 Aug 2000 15:08:20 -0400 (EDT) Received: by lespaul.process.com with Internet Mail Service (5.5.2650.21) id ; Wed, 30 Aug 2000 15:08:04 -0400 Message-ID: <63D30D6E10CFD11190A90000F805FE8602BEC070@lespaul.process.com> From: Bernie Volz To: DHCPv4 discussion list Subject: RE: Authentication option Date: Wed, 30 Aug 2000 15:07:54 -0400 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 Ralph: I didn't go back through the messages on this topic, so I apologize if this has been discussed. But, I don't understand why anyone would ever want to accept messages that fail the authentication validation. I can understand using messages that do not have authentication information, but I can't understand why one would want to use messages where the authentication is corrupt or bogus (since I'd guess the rest of the packet is very suspect as well). I guess one argument FOR using this data is that if there are no other servers available, getting an address might be 'good'. (I assume in this case that the DHCPREQUEST would not be authenticated.) Though again, I'd seriously question the validatity of the data if the authentification fails to validate. Step 3 below might be clarified to read: 3. The client replies with a DHCPREQUEST message that MUST include authentication information encoded with the same secret used by the server in the selected DHCPOFFER message if the authentication was present and valid (otherwise, no authentication is used). Also, note the typo (nt instead of not) in step 4. - Bernie Volz -----Original Message----- From: Ralph Droms [mailto:droms@bucknell.edu] Sent: Wednesday, August 30, 2000 2:00 PM To: DHCPv4 discussion list Subject: RE: Authentication option I read Barr's suggested text for 5.5.1 and reviewed the relevant mailing list messages, and wrote up the following candidate text to replace the current text in 5.5.1 I've included BARR's text for comparison. - Ralph 5.5.1 INIT state When in INIT state, the client uses protocol 1 as follows: 1. The client MUST include the authentication request option in its DHCPDISCOVER message along with the client identifier option (option code 61) [6] to identify itself uniquely to the server. 2. The client MUST perform the validation test described in section 5.3 on any DHCPOFFER messages that include authentication information. If one or more DHCPOFFER messages pass the validation test, the client chooses one of the offered configurations. Client behavior if no DHCPOFFER messages include authentication information or pass the validation test is controlled by local policy in the client. According to client policy, the client MAY choose to respond to a DHCPOFFER message that has not been authenticated. The decision to set local policy to accept unauthenticated messages should be made with care. Accepting an unauthenticated DHCPOFFER message can make the client vulnerable to spoofing and other attacks. If local users are not explicitly informed that the client has accepted an unauthenticated DHCPOFFER message, the users may incorrectly assume that the client has received an authenticated address and is not subject to DHCP attacks through unauthenticated messages. A client MUST be configurable to decline unauthenticated messages, and SHOULD be configured by default to decline unauthenticated messages. A client MAY choose to differentiate between DHCPOFFER messages with no authentication information and DHCPOFFER messages that do not pass the validation test; for example, a client might accept the former and discard the latter. If a client does accept an unauthenticated message, the client SHOULD inform any local users and SHOULD log the event. 3. The client replies with a DHCPREQUEST message that MUST include authentication information encoded with the same secret used by the server in the selected DHCPOFFER message. 4. If the client authenticated the DHCPOFFER it accepted, the client MUST validate the DHCPACK message from the server. The client MUST discard the DHCPACK if the message fails to pass validation and MAY log the validation failure. If the DHCPACK fails to pass validation, the client MUST revert to INIT state and returns to step 1. The client MAY choose to remember which server replied with a DHCPACK message that failed to pass validation and discard subsequent messages from that server. If the client accepted a DHCPOFFER message that did nt include [nt --> not] authentication information or did not pass the validation test, the client MAY accept an unauthenticated DHCPACK message from the server. At 02:21 PM 8/22/00 -0700, Barr Hibbs wrote: >Bill et al., > >I promised to try my hand at some text to cover the point about notification >of the user, so, here goes! > >--Barr > >=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= - >=-=-=-= > >5.5.1 INIT state > > When in INIT state, the client uses protocol 1 as follows: > > 1. The client MUST include the authentication request option in > its DHCPDISCOVER message along with option 61 [6] to identify > itself uniquely to the server. > > 2. The client MUST validate any DHCPOFFER messages that include > authentication information using the mechanism specified in > section 5.3. The client MUST discard any messages which fail >***** to pass validation and MAY [SHOULD??] log the validation failure. > The client selects one DHCPOFFER message as its selected > configuration. If none of the DHCPOFFER messages received by > the client include authentication information, the client MAY > choose an unauthenticated message as its selected > configuration. The client SHOULD be configurable to accept or >***** reject unauthenticated DHCPOFFER messages. The client SHOULD >***** log the acceptance of an unauthenticated message if it decides >***** to choose one. > > 3. The client replies with a DHCPREQUEST message that MUST include > authentication information encoded with the same secret used by > the server in the selected DHCPOFFER message. > > 4. The client MUST validate the DHCPACK message from the server. > The client MUST discard the DHCPACK if the message fails to > pass validation and MAY log the validation failure. If the > DHCPACK fails to pass validation, the client MUST revert to > INIT state and returns to step 1. The client MAY choose to > remember which server replied with a DHCPACK message that > failed to pass validation and discard subsequent messages from >***** that server. If the client chooses to remember a failed >***** message authentication, it SHOULD log that decision, and >***** SHOULD revert to normal operation with respect to that server >***** after receiving a properly authenticated message from that server. > >5.5.2 INIT-REBOOT state > > When in INIT-REBOOT state, the client MUST use the secret it used > in its DHCPREQUEST message to obtain its current configuration to > generate authentication information for the DHCPREQUEST message. > The client MAY choose to accept unauthenticated DHCPACK/DHCPNAK > messages if no authenticated messages were received. The client > MUST treat the receipt (or lack thereof) of any DHCPACK/DHCPNAK >***** messages as specified in section 3.2 of [1]. If the client chooses >***** to accept unauthenticated messages from a server, it SHOULD log that >***** decision. From owner-dhcp-v6@bucknell.edu Wed Aug 30 15:13:41 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07517 for ; Wed, 30 Aug 2000 15:13:41 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e7UJB1i20486; Wed, 30 Aug 2000 15:11:01 -0400 (EDT) Received: from zmamail01.zma.compaq.com (zmamail01.zma.compaq.com [161.114.64.101]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e7UJAii31107 for ; Wed, 30 Aug 2000 15:10:44 -0400 (EDT) Received: by zmamail01.zma.compaq.com (Postfix, from userid 12345) id 5DBBF3836; Wed, 30 Aug 2000 15:10:27 -0400 (EDT) Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by zmamail01.zma.compaq.com (Postfix) with ESMTP id 429512336 for ; Wed, 30 Aug 2000 15:10:27 -0400 (EDT) Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM) id PAA0000942259; Wed, 30 Aug 2000 15:10:14 -0400 (EDT) From: Jim Bound Message-Id: <200008301910.PAA0000942259@anw.zk3.dec.com> To: DHCPv6 discussion list Cc: bound@ZK3.DEC.COM Subject: Re: Things I want to see in DHCPv6 In-reply-to: Your message of "Wed, 30 Aug 2000 14:22:41 EDT." <4.3.1.2.20000830141709.00b08b60@mail.bucknell.edu> Date: Wed, 30 Aug 2000 15:10:14 -0400 X-Mts: smtp 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 Hi Ralph, >Following Ted's proposal, I expect to have a list of features to be >includes or excluded. I'll put that list together and e-mail it to list >participants Thursday AM. During the phone call, we'll discuss the >features in the list one-by-one to determine consensus on the disposition >of each feature. I imagine the author of each list item will take the lead >in explaining his position first, with followup by others on the phone call. OK. How do those of us who "may" not support inclusion or removal or a change to an item respond technically why its a good or not-so-good idea. For example: I will argue one of the advantages as a programmer I like about the DHCPv6 message types is that I know the msg type immediately as a client or server implementation right after the UDP header. In DHCPv4 (ignoring the state machine issues) I have to look past the DHCPv4 header and see the option if I don't want to build a state machine. I know here at compaq in the technical community when engineers don't agree on a design issue we hear boths sides of a change thats what I am getting at. thanks /jim From owner-dhcp-v6@bucknell.edu Wed Aug 30 15:22:03 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07610 for ; Wed, 30 Aug 2000 15:22:03 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e7UJLKi04814; Wed, 30 Aug 2000 15:21:20 -0400 (EDT) Received: from leo.eg.bucknell.edu (dns.dhcp.org [134.82.56.120]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e7UJLBi25937 for ; Wed, 30 Aug 2000 15:21:11 -0400 (EDT) Received: from leo (leo [134.82.56.108]) by leo.eg.bucknell.edu (8.8.8+Sun/8.8.8) with ESMTP id PAA06094; Wed, 30 Aug 2000 15:21:10 -0400 (EDT) Date: Wed, 30 Aug 2000 15:21:10 -0400 (EDT) From: "Ralph E. Droms" X-Sender: droms@leo To: DHCPv6 discussion list cc: bound@ZK3.DEC.COM Subject: Re: Things I want to see in DHCPv6 In-Reply-To: <200008301910.PAA0000942259@anw.zk3.dec.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 On Wed, 30 Aug 2000, Jim Bound wrote: > >During the phone call, we'll discuss the > >features in the list one-by-one to determine consensus on the disposition > >of each feature. I imagine the author of each list item will take the lead > >in explaining his position first, with followup by others on the phone call. > > OK. How do those of us who "may" not support inclusion or removal or a > change to an item respond technically why its a good or not-so-good > idea. Ah - perhaps the word "followup" isn't clear. What I meant was "presentation of opposing and supporting opinions"; i.e., everybody gets a chance to talk about facts and opinions in opposition to or in support of the list item in question. - Ralph From owner-dhcp-v6@bucknell.edu Wed Aug 30 15:26:17 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07697 for ; Wed, 30 Aug 2000 15:26:12 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e7UJOhi02325; Wed, 30 Aug 2000 15:24:43 -0400 (EDT) Received: from kitab.cisco.com (kitab.cisco.com [171.69.187.233]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e7UJOWi12957 for ; Wed, 30 Aug 2000 15:24:32 -0400 (EDT) Received: (from raj@localhost) by kitab.cisco.com (8.9.3/8.9.2) id MAA11138; Wed, 30 Aug 2000 12:23:51 -0700 (PDT) (envelope-from raj) From: Richard Johnson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14765.24388.233799.596905@kitab.cisco.com> Date: Wed, 30 Aug 2000 12:23:48 -0700 (PDT) To: DHCPv6 discussion list Subject: Re: Things I want to see in DHCPv6 In-Reply-To: References: X-Mailer: VM 6.75 under 20.4 "Emerald" XEmacs Lucid 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 Content-Transfer-Encoding: 7bit I have a few general comments on the draft(s). I also have some more specific comments on the text but will send them directly to the authors instead. DHCPv6: * I would like to suggest that if the DHCPv6 protocol can be made to work for DHCPv4 as well (which I think it can with a small amount of effort), we could then use this as a sort of "DHCPng" and only allow new options in DHCPng unless there's a really good reason for including it in DHCPv4. This would strongly push everyone involved to implement DHCPng as fast as possible in order to gain support for new options. This is very similar to what the DNSEXT group is doing with eDNS. * Might it be useful to allow Reconfigure and Reconfigure-reply messages to be sent via a relay to client's which do not have such reachable IP addresses, in order to inform them of changes in non-releasable resources? The same thing could also go for Reconfigure-init to some extent. * Might a client send a Solicit in response to a Reconfigure-init? What if the topology changes such that this is necessary in order find a DHCP server with can allocate addresses on the new subnet? DHCPv6 Extensions: * In section 3 (DHCP Relay Considerations) the text reads: The DHCP Relay MUST NOT change any information in any DHCP Extension fields. All Extension information flows between DHCP Server and DHCP Client without modification by any Relay. I could easily envision some types of extensions which may REQUIRE a relay to change them. At lease we need to allow for a relay to ADD additional extensions, such as in the case of the "DHCP Relay Agent Information Option" of DHCPv4. * In section 4 (Releasable Resource Extensions) the text reads: A client MUST remember in non-volatile storage which server allocated which releasable resource, in order to appropriately manage the lease associated with that resource. What if the client doesn't have non-volatile storage? From owner-dhcp-v4@bucknell.edu Wed Aug 30 15:39:18 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07892 for ; Wed, 30 Aug 2000 15:39:17 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e7UJbVi28713; Wed, 30 Aug 2000 15:37:31 -0400 (EDT) Received: from leo.eg.bucknell.edu (leo.eg.bucknell.edu [134.82.56.108]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e7UJbUi25801 for ; Wed, 30 Aug 2000 15:37:30 -0400 (EDT) Received: from dns.dhcp.org (dns.dhcp.org [134.82.56.120]) by leo.eg.bucknell.edu (8.8.8+Sun/8.8.8) with ESMTP id PAA06100; Wed, 30 Aug 2000 15:37:28 -0400 (EDT) Date: Wed, 30 Aug 2000 15:37:28 -0400 (EDT) From: "Ralph E. Droms" X-Sender: droms@leo To: DHCPv4 discussion list cc: DHCPv4 discussion list Subject: RE: Authentication option In-Reply-To: <63D30D6E10CFD11190A90000F805FE8602BEC070@lespaul.process.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: droms@bucknell.edu Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN On Wed, 30 Aug 2000, Bernie Volz wrote: > But, I don't understand why anyone would ever want to > accept messages that fail the authentication validation. I can understand > using messages that do not have authentication information, but I can't > understand why one would want to use messages where the authentication is > corrupt or bogus (since I'd guess the rest of the packet is very suspect as > well). OK - I read the consensus from the previous conversation as wanting to allow local client policy to make the decision about both messages with no authentication and messages that fail authentication. I'm willing to change the text if the WG wants to allow the former and disallow the latter. > Step 3 below might be clarified to read: > > 3. The client replies with a DHCPREQUEST message that MUST include > authentication information encoded with the same secret used by > the server in the selected DHCPOFFER message if the authentication > was present and valid (otherwise, no authentication is used). That change makes sense... > Also, note the typo (nt instead of not) in step 4. Thanks for catching that typo. - Ralph From owner-dhcp-v6@bucknell.edu Wed Aug 30 15:49:41 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08090 for ; Wed, 30 Aug 2000 15:49:35 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e7UJjUi00578; Wed, 30 Aug 2000 15:45:30 -0400 (EDT) Received: from zmamail02.zma.compaq.com (zmamail02.zma.compaq.com [161.114.64.102]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e7UJj8i26774 for ; Wed, 30 Aug 2000 15:45:11 -0400 (EDT) Received: by zmamail02.zma.compaq.com (Postfix, from userid 12345) id D246A1FE; Wed, 30 Aug 2000 15:44:50 -0400 (EDT) Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by zmamail02.zma.compaq.com (Postfix) with ESMTP id 9365E1B93 for ; Wed, 30 Aug 2000 15:44:50 -0400 (EDT) Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM) id PAA0000947602; Wed, 30 Aug 2000 15:44:36 -0400 (EDT) From: Jim Bound Message-Id: <200008301944.PAA0000947602@anw.zk3.dec.com> To: DHCPv6 discussion list Cc: bound@ZK3.DEC.COM Subject: Re: Things I want to see in DHCPv6 In-reply-to: Your message of "Wed, 30 Aug 2000 10:11:40 EDT." <63D30D6E10CFD11190A90000F805FE8602BEC069@lespaul.process.com> Date: Wed, 30 Aug 2000 15:44:36 -0400 X-Mts: smtp 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 Hi Bernie, Response to Clarification question ONLY: Clarification >I essentially agree with Ralph on his list. Here are some >additions/comments. Ralph stated he wanted the 2131 message types but later you say you don't want the boot OP param and multicast is a good thing? Can you clarify more as I know Ralph better and I think I know what he is saying but not clear which way your going here and if you completely agree with Ralph or want to amend that agreement? Just for message "syntax" not semantics as I realize that stuff will have to be at the meeting. thanks Clarification: >I also have one item that I feel needs clarification on Ralph's list: >> * One interface, with a single unique identifier, can be assigned >> multiple addresses >In IPv6, does this mean one address per prefix on the "interface" (with >multiple prefixes being supported) or does it mean that the client can also >obtain MULTIPLE addresses for the same prefix. I would hope both. It is not >clear exactly how this would easily be achieved - how to tell the difference >between a duplicate request (without caching transaction ids) and a request >for a second (or third...) address. If done in a single request, having >multiple IP Address Extensions could be used. But if done in multiple >requests, it is not as easy. I guess it might first be worthwhile to >consider why we need this - sounds like a useful feature, but would it be >used and for what reasons? In IPv6 stateless the node first configures its EUID and for now implementations are doing the Aggregatable format for IPv6 which implies a 64bit EUID. This 64bit EUID is also used to create the nodes link-local address by adding an architectural defined constant FE80 to that and bingo one has a link-local address. If you watch many of the IPv6 nodes boot up at bake-offs when the OS is being loaded on the screen in the case of UNIX you see "configuring link-loal address" so by the time the login prompt appears the node has a link-local address and it is unique on the link via duplicate address detection and the node can converse on the link with any other node using its link local address. So lets assume for clarity that the EUID for mynode interface #1 is "34" when I attached the link-local prefix to it the link-local 128bit address is FE80::34 this would be the present client link-local address in the existing dhcpv6 messages. Then a router appears on the link and starts sending out Router Advertisements as ICMPv6 messages (no more ARP stuff) with a list of prefixes and sets the bit telling the nodes you can use these prefixes to configure your addresses. Lets say the router sent out the following prefixes: 3ffe::/64 2ffe::/64 So at mynode for interface #1 with EUID of 34 I can now configure addresses as follows: 3ffe::34 2ffe::34 And I don't have to run duplicate address detection again as I did for the link-local and as the EUID did not change. If I had interface #2 with EUID 53 on the SAME LINK I could configure two addresses for that interface as: 3ffe::53 2ffe::53 What IPv6 gurantees is that link-local addresses will not be duplicated on a link (IPv4 subnet). DHCPv6 has used the client link-local address as the dhcpv4 client identifier and we actually did a have a lot discussion on this years ago but that was before the Ipv6 Privacy paranoids got involved and anonymous address have been added to the mix. This presents a new issue as you succinctly pointed out and it did for all of our IPv6 implementations too. I will stop there per Ralphs suggestion to not discuss input yet. But at the meeting I can expound on how we have dealt with that for neighbor discovery and IP over foo issues. One of the unstated goals of dhcpv6 was to be able to emulate the same capabilities from a dhcpv6 server to a dhcpv6 client as the router did with prefixes. In addition to also using the existing dhcpv4 model where you give the client a complete 128bit address. The idea was to let the user to pick their pain. But the client in either model can communicate on the link always with multicast or unicast using its link-local address as its source address in the IPv6 header. Hence, it can get to onlink servers or to onlink relays or generically to agents on the link. Hope this was helpful, /jim From owner-dhcp-v6@bucknell.edu Wed Aug 30 15:53:40 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08137 for ; Wed, 30 Aug 2000 15:53:40 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e7UJpKi28757; Wed, 30 Aug 2000 15:51:20 -0400 (EDT) Received: from zmamail02.zma.compaq.com (zmamail02.zma.compaq.com [161.114.64.102]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e7UJoui27163; Wed, 30 Aug 2000 15:50:56 -0400 (EDT) Received: by zmamail02.zma.compaq.com (Postfix, from userid 12345) id D7484E82; Wed, 30 Aug 2000 15:50:40 -0400 (EDT) Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by zmamail02.zma.compaq.com (Postfix) with ESMTP id 7EAE71740; Wed, 30 Aug 2000 15:50:40 -0400 (EDT) Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM) id PAA0000948519; Wed, 30 Aug 2000 15:50:40 -0400 (EDT) From: Jim Bound Message-Id: <200008301950.PAA0000948519@anw.zk3.dec.com> To: DHCPv6 discussion list Cc: DHCPv6 discussion list Subject: Re: Things I want to see in DHCPv6 In-reply-to: Your message of "Wed, 30 Aug 2000 15:21:10 EDT." Date: Wed, 30 Aug 2000 15:50:39 -0400 X-Mts: smtp 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 Hi Ralph, >Ah - perhaps the word "followup" isn't clear. What I meant was >"presentation of opposing and supporting opinions"; i.e., everybody gets a >chance to talk about facts and opinions in opposition to or in support of >the list item in question. Great... yes that was what I was not sure of. 3 hours seems long but I bet we will use every minute of it. thanks /jim From owner-dhcp-v6@bucknell.edu Wed Aug 30 16:33:19 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08630 for ; Wed, 30 Aug 2000 16:33:19 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e7UKRJi01025; Wed, 30 Aug 2000 16:27:19 -0400 (EDT) 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 e7UKRFi23281 for ; Wed, 30 Aug 2000 16:27:15 -0400 (EDT) Received: by lespaul.process.com with Internet Mail Service (5.5.2650.21) id ; Wed, 30 Aug 2000 16:26:59 -0400 Message-ID: <63D30D6E10CFD11190A90000F805FE8602BEC071@lespaul.process.com> From: Bernie Volz To: DHCPv6 discussion list Subject: RE: Things I want to see in DHCPv6 Date: Wed, 30 Aug 2000 16:26:52 -0400 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 Jim: Regarding the RFC 2131 message types ... I assumed Ralph was not saying he wanted to use the RFC 2131 packet formats, just the message type names (ie, use the DHCPDISCOVER, DHCPOFFER, DHCPREQUEST, DHCPACK, ...) instead of the DHCPv6 terminology (SOLICIT, ADVERTISE, REQUEST, REPLY, ...). We're all familiar with the RFC2131 message names. And, agreed that we don't want to have to look way down into a message (such as with DHCPv4 / BOOTP) to determine the message type - the "op" or "msg-type" field should likely be the first byte to follow the UDP header. Thanks for the review of the address generation in IPv6. It is pretty much as I remember it (good that I don't have to re-read volumes of IPv6 documents since I haven't looked at them in a while). The issue for me is still the same ... the EUID is likely to change over time (because the interface is replaced, because of privacy concerns, because of Duplicate Address Detection, ...) and thus is not a "permanent" unique identifier for a system. So, if I want a certain box to always get a certain address (at least as long as the prefix is available) I'm in trouble. Perhaps a good question is why I would care what the IPv6 address assigned to a system is and I'm not sure that's easy to answer. BTW: Has anyone thought about whether DHCPv6 (or DHCPng) can or should be able to give out multicast or the IPv6 "cluster" addresses (or whatever they're called now if they still exist)? I would suspect that this would be a whole lot easier with DHCPv6 since the client could simply supply the appropriate prefix to obtain that address type? I'm not suggesting this as a requirement on my list (unless of course everything thinks it has value). I suspect these would be excellent extensions to consider down the road as additional "allocatable resources" and as long as the framework can accommodate it, probably best to ignore for now. - Bernie Volz IPWorks, Inc. -----Original Message----- From: Jim Bound [mailto:bound@zk3.dec.com] Sent: Wednesday, August 30, 2000 3:45 PM To: DHCPv6 discussion list Cc: bound@zk3.dec.com Subject: Re: Things I want to see in DHCPv6 Hi Bernie, Response to Clarification question ONLY: Clarification >I essentially agree with Ralph on his list. Here are some >additions/comments. Ralph stated he wanted the 2131 message types but later you say you don't want the boot OP param and multicast is a good thing? Can you clarify more as I know Ralph better and I think I know what he is saying but not clear which way your going here and if you completely agree with Ralph or want to amend that agreement? Just for message "syntax" not semantics as I realize that stuff will have to be at the meeting. thanks Clarification: >I also have one item that I feel needs clarification on Ralph's list: >> * One interface, with a single unique identifier, can be assigned >> multiple addresses >In IPv6, does this mean one address per prefix on the "interface" (with >multiple prefixes being supported) or does it mean that the client can also >obtain MULTIPLE addresses for the same prefix. I would hope both. It is not >clear exactly how this would easily be achieved - how to tell the difference >between a duplicate request (without caching transaction ids) and a request >for a second (or third...) address. If done in a single request, having >multiple IP Address Extensions could be used. But if done in multiple >requests, it is not as easy. I guess it might first be worthwhile to >consider why we need this - sounds like a useful feature, but would it be >used and for what reasons? In IPv6 stateless the node first configures its EUID and for now implementations are doing the Aggregatable format for IPv6 which implies a 64bit EUID. This 64bit EUID is also used to create the nodes link-local address by adding an architectural defined constant FE80 to that and bingo one has a link-local address. If you watch many of the IPv6 nodes boot up at bake-offs when the OS is being loaded on the screen in the case of UNIX you see "configuring link-loal address" so by the time the login prompt appears the node has a link-local address and it is unique on the link via duplicate address detection and the node can converse on the link with any other node using its link local address. So lets assume for clarity that the EUID for mynode interface #1 is "34" when I attached the link-local prefix to it the link-local 128bit address is FE80::34 this would be the present client link-local address in the existing dhcpv6 messages. Then a router appears on the link and starts sending out Router Advertisements as ICMPv6 messages (no more ARP stuff) with a list of prefixes and sets the bit telling the nodes you can use these prefixes to configure your addresses. Lets say the router sent out the following prefixes: 3ffe::/64 2ffe::/64 So at mynode for interface #1 with EUID of 34 I can now configure addresses as follows: 3ffe::34 2ffe::34 And I don't have to run duplicate address detection again as I did for the link-local and as the EUID did not change. If I had interface #2 with EUID 53 on the SAME LINK I could configure two addresses for that interface as: 3ffe::53 2ffe::53 What IPv6 gurantees is that link-local addresses will not be duplicated on a link (IPv4 subnet). DHCPv6 has used the client link-local address as the dhcpv4 client identifier and we actually did a have a lot discussion on this years ago but that was before the Ipv6 Privacy paranoids got involved and anonymous address have been added to the mix. This presents a new issue as you succinctly pointed out and it did for all of our IPv6 implementations too. I will stop there per Ralphs suggestion to not discuss input yet. But at the meeting I can expound on how we have dealt with that for neighbor discovery and IP over foo issues. One of the unstated goals of dhcpv6 was to be able to emulate the same capabilities from a dhcpv6 server to a dhcpv6 client as the router did with prefixes. In addition to also using the existing dhcpv4 model where you give the client a complete 128bit address. The idea was to let the user to pick their pain. But the client in either model can communicate on the link always with multicast or unicast using its link-local address as its source address in the IPv6 header. Hence, it can get to onlink servers or to onlink relays or generically to agents on the link. Hope this was helpful, /jim From owner-dhcp-v6@bucknell.edu Wed Aug 30 16:34:23 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08667 for ; Wed, 30 Aug 2000 16:34:23 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e7UKXli05477; Wed, 30 Aug 2000 16:33:47 -0400 (EDT) Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e7UKXji04666 for ; Wed, 30 Aug 2000 16:33:45 -0400 (EDT) Received: from research.telcordia.com (tdevil [192.4.12.150]) by thumper.research.telcordia.com (8.10.1/8.10.1) with ESMTP id e7UKUbR15352; Wed, 30 Aug 2000 16:30:40 -0400 (EDT) Message-ID: <39AD6EEA.89DD70F0@research.telcordia.com> Date: Wed, 30 Aug 2000 16:30:34 -0400 From: Tony McAuley X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: DHCPv6 discussion list CC: subir@research.telcordia.com Subject: Re: Things I want to see in DHCPv6 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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 Content-Transfer-Encoding: 7bit We would like to add a few more items for discussion (in addition to what has already been posted). This is based on our work on using DHCP in a wireless environment (DRCP). 1. We would like to see a smaller DHCP message header for B/W efficiency. One possibility is to eliminate the client link-local and relay addresses, and substitute a MAC address for identification. Any IP address information could be added as an option, which would also, as Bernie points out, simplify carrying IPv4 addresses too. 2. We would like to reduce the number of messages to configure a node. For example, include the address(es) of the DHCP server in the (Router) Advertisements, then the client could immediately unicast a request to the server. The Advertisement would also a) help roaming nodes detect the need to reconfigure and b) eliminates the need for clients to broadcast/multicast discoveries/soliciations. 3. To rapidly configure roaming users, we would like to avoid doing ND Neighbor Solicitation and Neighbor Advertisement, both for the link local addresses and the address given by DHCP. Maybe this is beyond the scope of DHC working group? We actually prefer DHCPv6 to IPv6 Stateless autoconfiguration because we believe it can be faster. A DHCP server might precheck the addresses it will assign to clients. 4. We would like to be able to configure a router's interface if it is on the same link as the DHCP server. 5. We would like to define a new interface to DHCP for doing things such as adding a new address pool, changing some configuration parameters, or being able to request a new address pool. Thanks Tony and Subir --------------------------------------------------------------------------- > From: Ralph Droms [mailto:rdroms@cisco.com] > Sent: Tuesday, August 29, 2000 1:18 PM > To: DHCPv6 discussion list > Subject: Things I want to see in DHCPv6 > > Part of the deal in prepping for Thursday's DHCPv6 design team phone call > is to develop a list of "things we want to see" in DHCPv6. From owner-dhcp-v6@bucknell.edu Wed Aug 30 17:05:43 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09188 for ; Wed, 30 Aug 2000 17:05:41 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e7UL30i03290; Wed, 30 Aug 2000 17:03:00 -0400 (EDT) Received: from ztxmail01.ztx.compaq.com (ztxmail01.ztx.compaq.com [161.114.1.205]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e7UL2si19626 for ; Wed, 30 Aug 2000 17:02:54 -0400 (EDT) Received: by ztxmail01.ztx.compaq.com (Postfix, from userid 12345) id 11E742ED9; Wed, 30 Aug 2000 16:02:39 -0500 (CDT) Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by ztxmail01.ztx.compaq.com (Postfix) with ESMTP id 771EF2E3A; Wed, 30 Aug 2000 16:02:38 -0500 (CDT) Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM) id RAA0000957773; Wed, 30 Aug 2000 17:02:25 -0400 (EDT) From: Jim Bound Message-Id: <200008302102.RAA0000957773@anw.zk3.dec.com> To: DHCPv6 discussion list Cc: "'dhcp-v6@bucknell.edu'" , bound@ZK3.DEC.COM, bound@ZK3.DEC.COM Subject: Re: Things I want to see in DHCPv6 In-reply-to: Your message of "Wed, 30 Aug 2000 16:26:52 EDT." <63D30D6E10CFD11190A90000F805FE8602BEC071@lespaul.process.com> Date: Wed, 30 Aug 2000 17:02:25 -0400 X-Mts: smtp 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 Hi Bernie, >Regarding the RFC 2131 message types ... I assumed Ralph was not saying he >wanted to use the RFC 2131 packet formats, just the message type names (ie, >use the DHCPDISCOVER, DHCPOFFER, DHCPREQUEST, DHCPACK, ...) instead of the >DHCPv6 terminology (SOLICIT, ADVERTISE, REQUEST, REPLY, ...). We're all >familiar with the RFC2131 message names. And, agreed that we don't want to >have to look way down into a message (such as with DHCPv4 / BOOTP) to >determine the message type - the "op" or "msg-type" field should likely be >the first byte to follow the UDP header. OH OK. I was going down the wrong path glad I asked. >Thanks for the review of the address generation in IPv6. It is pretty much >as I remember it (good that I don't have to re-read volumes of IPv6 >documents since I haven't looked at them in a while). The issue for me is >still the same ... the EUID is likely to change over time (because the >interface is replaced, because of privacy concerns, because of Duplicate >Address Detection, ...) and thus is not a "permanent" unique identifier for >a system. So, if I want a certain box to always get a certain address (at >least as long as the prefix is available) I'm in trouble. Perhaps a good >question is why I would care what the IPv6 address assigned to a system is >and I'm not sure that's easy to answer. It certainly is not an easy answer but I don't think it will take lots of hours either. But definitely an issue. Just btw us I will tell you I will make damn sure that in any IPv6 implementation I work on users will be able to ignore this entire fiasco if they so choose to. Its mostly a joke IMO. >BTW: Has anyone thought about whether DHCPv6 (or DHCPng) can or should be >able to give out multicast or the IPv6 "cluster" addresses (or whatever >they're called now if they still exist)? I would suspect that this would be >a whole lot easier with DHCPv6 since the client could simply supply the >appropriate prefix to obtain that address type? I'm not suggesting this as a >requirement on my list (unless of course everything thinks it has value). I >suspect these would be excellent extensions to consider down the road as >additional "allocatable resources" and as long as the framework can >accommodate it, probably best to ignore for now. Anycast addresses I think your referring too. Still illegal to assign them to anything but routers. This is poping up on another design team I am on in IPv6 space right now. I agree we need to make sure we do nothing to prevent giving them out for sure but also nothing really differentiates anycast from unicast except when its routed and that you cannot use it as IP source address. regards, /jim - Bernie Volz IPWorks, Inc. -----Original Message----- From: Jim Bound [mailto:bound@zk3.dec.com] Sent: Wednesday, August 30, 2000 3:45 PM To: DHCPv6 discussion list Cc: bound@zk3.dec.com Subject: Re: Things I want to see in DHCPv6 Hi Bernie, Response to Clarification question ONLY: Clarification >I essentially agree with Ralph on his list. Here are some >additions/comments. Ralph stated he wanted the 2131 message types but later you say you don't want the boot OP param and multicast is a good thing? Can you clarify more as I know Ralph better and I think I know what he is saying but not clear which way your going here and if you completely agree with Ralph or want to amend that agreement? Just for message "syntax" not semantics as I realize that stuff will have to be at the meeting. thanks Clarification: >I also have one item that I feel needs clarification on Ralph's list: >> * One interface, with a single unique identifier, can be assigned >> multiple addresses >In IPv6, does this mean one address per prefix on the "interface" (with >multiple prefixes being supported) or does it mean that the client can also >obtain MULTIPLE addresses for the same prefix. I would hope both. It is not >clear exactly how this would easily be achieved - how to tell the difference >between a duplicate request (without caching transaction ids) and a request >for a second (or third...) address. If done in a single request, having >multiple IP Address Extensions could be used. But if done in multiple >requests, it is not as easy. I guess it might first be worthwhile to >consider why we need this - sounds like a useful feature, but would it be >used and for what reasons? In IPv6 stateless the node first configures its EUID and for now implementations are doing the Aggregatable format for IPv6 which implies a 64bit EUID. This 64bit EUID is also used to create the nodes link-local address by adding an architectural defined constant FE80 to that and bingo one has a link-local address. If you watch many of the IPv6 nodes boot up at bake-offs when the OS is being loaded on the screen in the case of UNIX you see "configuring link-loal address" so by the time the login prompt appears the node has a link-local address and it is unique on the link via duplicate address detection and the node can converse on the link with any other node using its link local address. So lets assume for clarity that the EUID for mynode interface #1 is "34" when I attached the link-local prefix to it the link-local 128bit address is FE80::34 this would be the present client link-local address in the existing dhcpv6 messages. Then a router appears on the link and starts sending out Router Advertisements as ICMPv6 messages (no more ARP stuff) with a list of prefixes and sets the bit telling the nodes you can use these prefixes to configure your addresses. Lets say the router sent out the following prefixes: 3ffe::/64 2ffe::/64 So at mynode for interface #1 with EUID of 34 I can now configure addresses as follows: 3ffe::34 2ffe::34 And I don't have to run duplicate address detection again as I did for the link-local and as the EUID did not change. If I had interface #2 with EUID 53 on the SAME LINK I could configure two addresses for that interface as: 3ffe::53 2ffe::53 What IPv6 gurantees is that link-local addresses will not be duplicated on a link (IPv4 subnet). DHCPv6 has used the client link-local address as the dhcpv4 client identifier and we actually did a have a lot discussion on this years ago but that was before the Ipv6 Privacy paranoids got involved and anonymous address have been added to the mix. This presents a new issue as you succinctly pointed out and it did for all of our IPv6 implementations too. I will stop there per Ralphs suggestion to not discuss input yet. But at the meeting I can expound on how we have dealt with that for neighbor discovery and IP over foo issues. One of the unstated goals of dhcpv6 was to be able to emulate the same capabilities from a dhcpv6 server to a dhcpv6 client as the router did with prefixes. In addition to also using the existing dhcpv4 model where you give the client a complete 128bit address. The idea was to let the user to pick their pain. But the client in either model can communicate on the link always with multicast or unicast using its link-local address as its source address in the IPv6 header. Hence, it can get to onlink servers or to onlink relays or generically to agents on the link. Hope this was helpful, /jim From owner-dhcp-v6@bucknell.edu Wed Aug 30 17:18:12 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09330 for ; Wed, 30 Aug 2000 17:18:12 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e7ULHXi24468; Wed, 30 Aug 2000 17:17:34 -0400 (EDT) Received: from lukla.Sun.COM (lukla.Sun.COM [192.18.98.31]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e7ULHWi02871 for ; Wed, 30 Aug 2000 17:17:32 -0400 (EDT) Received: from eastmail1.East.Sun.COM ([129.148.1.240]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA04836; Wed, 30 Aug 2000 15:17:30 -0600 (MDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id RAA26030; Wed, 30 Aug 2000 17:17:29 -0400 (EDT) Received: from thunk.east.sun.com (localhost [127.0.0.1]) by thunk.east.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e7ULH0T104690; Wed, 30 Aug 2000 17:17:00 -0400 (EDT) Message-Id: <200008302117.e7ULH0T104690@thunk.east.sun.com> From: Bill Sommerfeld To: DHCPv6 discussion list cc: bound@ZK3.DEC.COM Subject: Re: Things I want to see in DHCPv6 In-reply-to: Your message of "Wed, 30 Aug 2000 17:02:25 EDT." <200008302102.RAA0000957773@anw.zk3.dec.com> Reply-to: sommerfeld@east.sun.com Date: Wed, 30 Aug 2000 17:16:59 -0400 Sender: owner-dhcp-v6@bucknell.edu X-Sender: sommerfeld@thunk.east.sun.com X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN regarding the state machine: flowcharts are one way to depict state-transitions; however, it's very easy to forget about certain kinds of events which may occur. In a past job, when I was working over a DHCPv4 client which had a badly broken state machine I found it extremely helpful to enumerate: - states - events - packet reception. - timer expiration. - ... I then filled my whiteboard with a big states vs events table (each "state" is a row; each event is a column), with actions ("send packet", "set timer", "switch to state Y", ...) in the intersections. it makes it very easy to figure out where there are holes in the state transition where the protocol can get "stuck" if you forget about a retransmission timer.. - Bill From owner-dhcp-v6@bucknell.edu Wed Aug 30 17:23:10 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09417 for ; Wed, 30 Aug 2000 17:23:10 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e7ULMdi31630; Wed, 30 Aug 2000 17:22:39 -0400 (EDT) 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 e7ULMQi00678 for ; Wed, 30 Aug 2000 17:22:26 -0400 (EDT) Received: by lespaul.process.com with Internet Mail Service (5.5.2650.21) id ; Wed, 30 Aug 2000 17:22:10 -0400 Message-ID: <63D30D6E10CFD11190A90000F805FE8602BEC074@lespaul.process.com> From: Bernie Volz To: DHCPv6 discussion list Cc: "'dhcp-v6@bucknell.edu'" Subject: RE: Things I want to see in DHCPv6 Date: Wed, 30 Aug 2000 17:22:02 -0400 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 >Just btw us I will tell you I will make damn sure that in any IPv6 >implementation I work on users will be able to ignore this entire fiasco >if they so choose to. Its mostly a joke IMO. Yes, I can see arguments in that direction. While fundamentally the idea is good (being able to uniquely identify a system), for almost all systems it doesn't really matter what address they get (in theory). For those few systems where addresses might be important, perhaps static or other configuration techniques are more appropriate anyway (I think that's the case in the IPv4 world). This is likely more of an issue in the IPv4 world (it is something people have come to expect) and my feeling that we do DHCPng is making me cling to it? I think some research could be in order ... how many sites really do use client identifiers (other than those that might be generated by systems from a mac address)? I can't really think of any offhand. PLEASE DO NOT SEND YOUR RESPONSES TO THIS QUESTION - NOW IS NOT THE TIME FOR THIS RESEARCH. - Bernie Volz IPWorks, Inc. -----Original Message----- From: Jim Bound [mailto:bound@zk3.dec.com] Sent: Wednesday, August 30, 2000 5:02 PM To: Bernie Volz Cc: 'dhcp-v6@bucknell.edu'; bound@zk3.dec.com; bound@zk3.dec.com Subject: Re: Things I want to see in DHCPv6 Hi Bernie, >Regarding the RFC 2131 message types ... I assumed Ralph was not saying he >wanted to use the RFC 2131 packet formats, just the message type names (ie, >use the DHCPDISCOVER, DHCPOFFER, DHCPREQUEST, DHCPACK, ...) instead of the >DHCPv6 terminology (SOLICIT, ADVERTISE, REQUEST, REPLY, ...). We're all >familiar with the RFC2131 message names. And, agreed that we don't want to >have to look way down into a message (such as with DHCPv4 / BOOTP) to >determine the message type - the "op" or "msg-type" field should likely be >the first byte to follow the UDP header. OH OK. I was going down the wrong path glad I asked. >Thanks for the review of the address generation in IPv6. It is pretty much >as I remember it (good that I don't have to re-read volumes of IPv6 >documents since I haven't looked at them in a while). The issue for me is >still the same ... the EUID is likely to change over time (because the >interface is replaced, because of privacy concerns, because of Duplicate >Address Detection, ...) and thus is not a "permanent" unique identifier for >a system. So, if I want a certain box to always get a certain address (at >least as long as the prefix is available) I'm in trouble. Perhaps a good >question is why I would care what the IPv6 address assigned to a system is >and I'm not sure that's easy to answer. It certainly is not an easy answer but I don't think it will take lots of hours either. But definitely an issue. Just btw us I will tell you I will make damn sure that in any IPv6 implementation I work on users will be able to ignore this entire fiasco if they so choose to. Its mostly a joke IMO. >BTW: Has anyone thought about whether DHCPv6 (or DHCPng) can or should be >able to give out multicast or the IPv6 "cluster" addresses (or whatever >they're called now if they still exist)? I would suspect that this would be >a whole lot easier with DHCPv6 since the client could simply supply the >appropriate prefix to obtain that address type? I'm not suggesting this as a >requirement on my list (unless of course everything thinks it has value). I >suspect these would be excellent extensions to consider down the road as >additional "allocatable resources" and as long as the framework can >accommodate it, probably best to ignore for now. Anycast addresses I think your referring too. Still illegal to assign them to anything but routers. This is poping up on another design team I am on in IPv6 space right now. I agree we need to make sure we do nothing to prevent giving them out for sure but also nothing really differentiates anycast from unicast except when its routed and that you cannot use it as IP source address. regards, /jim - Bernie Volz IPWorks, Inc. -----Original Message----- From: Jim Bound [mailto:bound@zk3.dec.com] Sent: Wednesday, August 30, 2000 3:45 PM To: DHCPv6 discussion list Cc: bound@zk3.dec.com Subject: Re: Things I want to see in DHCPv6 Hi Bernie, Response to Clarification question ONLY: Clarification >I essentially agree with Ralph on his list. Here are some >additions/comments. Ralph stated he wanted the 2131 message types but later you say you don't want the boot OP param and multicast is a good thing? Can you clarify more as I know Ralph better and I think I know what he is saying but not clear which way your going here and if you completely agree with Ralph or want to amend that agreement? Just for message "syntax" not semantics as I realize that stuff will have to be at the meeting. thanks Clarification: >I also have one item that I feel needs clarification on Ralph's list: >> * One interface, with a single unique identifier, can be assigned >> multiple addresses >In IPv6, does this mean one address per prefix on the "interface" (with >multiple prefixes being supported) or does it mean that the client can also >obtain MULTIPLE addresses for the same prefix. I would hope both. It is not >clear exactly how this would easily be achieved - how to tell the difference >between a duplicate request (without caching transaction ids) and a request >for a second (or third...) address. If done in a single request, having >multiple IP Address Extensions could be used. But if done in multiple >requests, it is not as easy. I guess it might first be worthwhile to >consider why we need this - sounds like a useful feature, but would it be >used and for what reasons? In IPv6 stateless the node first configures its EUID and for now implementations are doing the Aggregatable format for IPv6 which implies a 64bit EUID. This 64bit EUID is also used to create the nodes link-local address by adding an architectural defined constant FE80 to that and bingo one has a link-local address. If you watch many of the IPv6 nodes boot up at bake-offs when the OS is being loaded on the screen in the case of UNIX you see "configuring link-loal address" so by the time the login prompt appears the node has a link-local address and it is unique on the link via duplicate address detection and the node can converse on the link with any other node using its link local address. So lets assume for clarity that the EUID for mynode interface #1 is "34" when I attached the link-local prefix to it the link-local 128bit address is FE80::34 this would be the present client link-local address in the existing dhcpv6 messages. Then a router appears on the link and starts sending out Router Advertisements as ICMPv6 messages (no more ARP stuff) with a list of prefixes and sets the bit telling the nodes you can use these prefixes to configure your addresses. Lets say the router sent out the following prefixes: 3ffe::/64 2ffe::/64 So at mynode for interface #1 with EUID of 34 I can now configure addresses as follows: 3ffe::34 2ffe::34 And I don't have to run duplicate address detection again as I did for the link-local and as the EUID did not change. If I had interface #2 with EUID 53 on the SAME LINK I could configure two addresses for that interface as: 3ffe::53 2ffe::53 What IPv6 gurantees is that link-local addresses will not be duplicated on a link (IPv4 subnet). DHCPv6 has used the client link-local address as the dhcpv4 client identifier and we actually did a have a lot discussion on this years ago but that was before the Ipv6 Privacy paranoids got involved and anonymous address have been added to the mix. This presents a new issue as you succinctly pointed out and it did for all of our IPv6 implementations too. I will stop there per Ralphs suggestion to not discuss input yet. But at the meeting I can expound on how we have dealt with that for neighbor discovery and IP over foo issues. One of the unstated goals of dhcpv6 was to be able to emulate the same capabilities from a dhcpv6 server to a dhcpv6 client as the router did with prefixes. In addition to also using the existing dhcpv4 model where you give the client a complete 128bit address. The idea was to let the user to pick their pain. But the client in either model can communicate on the link always with multicast or unicast using its link-local address as its source address in the IPv6 header. Hence, it can get to onlink servers or to onlink relays or generically to agents on the link. Hope this was helpful, /jim From owner-dhcp-v4@bucknell.edu Wed Aug 30 17:25:46 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09447 for ; Wed, 30 Aug 2000 17:25:46 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e7ULNni14300; Wed, 30 Aug 2000 17:23:49 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e7ULNji26487 for ; Wed, 30 Aug 2000 17:23:45 -0400 (EDT) Received: from grosse.bisbee.fugue.com (dhcp-test3.nominum.com [204.152.187.167] (may be forged)) by toccata.fugue.com (8.9.3/8.6.11) with ESMTP id UAA02707; Tue, 29 Aug 2000 20:30:21 -0700 (PDT) Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.0/8.6.11) with ESMTP id e7ULNeM07623; Wed, 30 Aug 2000 14:23:40 -0700 (MST) Message-Id: <200008302123.e7ULNeM07623@grosse.bisbee.fugue.com> To: DHCPv4 discussion list cc: DHCPv4 discussion list Subject: Re: Authentication option In-Reply-To: Message from Bernie Volz of "Wed, 30 Aug 2000 15:07:54 -0400." <63D30D6E10CFD11190A90000F805FE8602BEC070@lespaul.process.com> Date: Wed, 30 Aug 2000 14:23:40 -0700 From: Ted Lemon Reply-To: mellon@nominum.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Hm. I think one advantage of not accepting options that fail to authenticate is that it forces people to fix their implementations if they're broken. A disadvantage is that if somebody has a really broken implementation that gets widely deployed, and they won't fix it, everybody else loses. So I think making this configurable is probably the better part of valor. Another point is: what if the kind of authentication being used by the server is not supported by the client, so authentication fails not because it is incorrect, but because it's not decodable. Is that the same as an unauthenticated packet, or is it the same as an authenticated packet whose authentication doesn't work? _MelloN_ From owner-dhcp-v6@bucknell.edu Wed Aug 30 17:30:19 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09481 for ; Wed, 30 Aug 2000 17:30:17 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e7ULTBi25340; Wed, 30 Aug 2000 17:29:11 -0400 (EDT) Received: from zmamail02.zma.compaq.com (zmamail02.zma.compaq.com [161.114.64.102]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e7ULT3i00744 for ; Wed, 30 Aug 2000 17:29:03 -0400 (EDT) Received: by zmamail02.zma.compaq.com (Postfix, from userid 12345) id 6116E1B1E; Wed, 30 Aug 2000 17:28:48 -0400 (EDT) Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by zmamail02.zma.compaq.com (Postfix) with ESMTP id 2F8C91A5D; Wed, 30 Aug 2000 17:28:48 -0400 (EDT) Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM) id RAA0000959600; Wed, 30 Aug 2000 17:28:16 -0400 (EDT) From: Jim Bound Message-Id: <200008302128.RAA0000959600@anw.zk3.dec.com> To: DHCPv6 discussion list Cc: subir@research.telcordia.com Subject: Re: Things I want to see in DHCPv6 In-reply-to: Your message of "Wed, 30 Aug 2000 16:30:34 EDT." <39AD6EEA.89DD70F0@research.telcordia.com> Date: Wed, 30 Aug 2000 17:28:16 -0400 X-Mts: smtp 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 Tony and Subir, Responding to your note as IPv6 expert, implementor, and IPv6 Working Group member not as DHCP WG member. >2. We would like to reduce the number of messages to configure a node. > For example, include the address(es) of the DHCP server in the > (Router) Advertisements, then the client could immediately > unicast a request to the server. The Advertisement would also a) help > roaming nodes detect the need to reconfigure and b) eliminates the > need for clients to broadcast/multicast discoveries/soliciations. This request is out of scope for this meeting. What your asking for here is a change to Neighbor Discovery protocol. You need to take that to the IPng list. This happens before DHCPv6 will even be started by IPv6. But I really like the idea a lot. But you might want to propose reducing the dhcpv6 message sizes for the same reason. >3. To rapidly configure roaming users, we would like to avoid doing > ND Neighbor Solicitation and Neighbor Advertisement, both for the > link local addresses and the address given by DHCP. Maybe this is > beyond the scope of DHC working group? We actually prefer DHCPv6 > to IPv6 Stateless autoconfiguration because we believe it can be > faster. A DHCP server might precheck the addresses it will assign > to clients. Again same comment. I am not sure not doing ND Solicitatin is a good idea it prevents black holes as offline comment. Hmmm. How do you come up with it can be faster. Don't get me wrong every customer I have checked with will use DHCPv6 initially and not Stateless simply for tight control and system mgmt thats why I am still working on it. Also for Mobile nodes. The only way I can see the performance win is if the clients are all attached by NBMA and Routing? (e.g. Cable, Set-Top Boxes etc...). I would be very interested as an engineer how you came up with its faster. Really!! I think I can see it for Mobile nodes that are dispersed too but form their own prefix set across multiple links. This is future work on IPng WG list/charter too. Example would be fleet of battleships where specific fighter craft in each squadron has its own prefix for team leader operations and are by definition mobile. Stateless autoconfig will not work for performance reasons because the discovery operations will not be optimal for the routes and better to have dedicated DHCP server. thanks /jim From owner-dhcp-v6@bucknell.edu Wed Aug 30 17:38:25 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09604 for ; Wed, 30 Aug 2000 17:38:24 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e7ULZDi28164; Wed, 30 Aug 2000 17:35:13 -0400 (EDT) Received: from zmamail01.zma.compaq.com (zmamail01.zma.compaq.com [161.114.64.101]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e7ULZ2i28717 for ; Wed, 30 Aug 2000 17:35:03 -0400 (EDT) Received: by zmamail01.zma.compaq.com (Postfix, from userid 12345) id 8F77C5AEE; Wed, 30 Aug 2000 17:34:47 -0400 (EDT) Received: from yquarry.zk3.dec.com (brrquarry.zk3.dec.com [16.141.56.3]) by zmamail01.zma.compaq.com (Postfix) with ESMTP id 56C8547A7; Wed, 30 Aug 2000 17:34:47 -0400 (EDT) Received: from localhost by yquarry.zk3.dec.com (8.8.8/1.1.22.3/11Mar00-0650AM) id RAA0000027590; Wed, 30 Aug 2000 17:34:47 -0400 (EDT) From: Jim Bound Message-Id: <200008302134.RAA0000027590@yquarry.zk3.dec.com> X-Authentication-Warning: yquarry.zk3.dec.com: localhost [127.0.0.1] didn't use HELO protocol To: DHCPv6 discussion list Cc: dhcp-v6@bucknell.edu, bound@ZK3.DEC.COM, bound@ZK3.DEC.COM Subject: Re: Things I want to see in DHCPv6 In-reply-to: Your message of "Wed, 30 Aug 2000 17:16:59 EDT." <200008302117.e7ULH0T104690@thunk.east.sun.com> Date: Wed, 30 Aug 2000 17:34:46 -0400 X-Mts: smtp 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 bill 100% agree with you. in fact I was going to do that and it was suggested to me to do the flowchart first and do the highlevel thing. I am timed out now to try to get it done by tomorrow. what we can do for the wg when we get to where folks are comfortable with what we are going to do is add this to any charts. or if there is still confusion after the meeting I will do it immediately. also not only is what you suggest more useful and complete but way better to look at than ascii artwork IMO. the flow chart is only a reference point for sure. /jim From owner-dhcp-v6@bucknell.edu Wed Aug 30 17:38:26 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09614 for ; Wed, 30 Aug 2000 17:38:25 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e7ULZhi14904; Wed, 30 Aug 2000 17:35:43 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e7ULZYi28568 for ; Wed, 30 Aug 2000 17:35:34 -0400 (EDT) Received: from grosse.bisbee.fugue.com (dhcp-test3.nominum.com [204.152.187.167] (may be forged)) by toccata.fugue.com (8.9.3/8.6.11) with ESMTP id UAA02737; Tue, 29 Aug 2000 20:41:55 -0700 (PDT) Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.0/8.6.11) with ESMTP id e7ULZDM07679; Wed, 30 Aug 2000 14:35:13 -0700 (MST) Message-Id: <200008302135.e7ULZDM07679@grosse.bisbee.fugue.com> To: DHCPv6 discussion list cc: DHCPv6 discussion list , bound@ZK3.DEC.COM Subject: Re: Things I want to see in DHCPv6 In-Reply-To: Message from Bill Sommerfeld of "Wed, 30 Aug 2000 17:16:59 -0400." <200008302117.e7ULH0T104690@thunk.east.sun.com> Date: Wed, 30 Aug 2000 14:35:13 -0700 From: Ted Lemon 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 think it would be a really good idea *not* to put a state diagram in the protocol spec. The problem is that then people will just read the state diagram, and not the text, and that means we have to make sure the state diagram completely and correctly expresses everything in the text, which is a hard goal to meet. I really like the idea in the failover protocol specification that each state just has a section explaining what events result in a transition from that state, and what the resulting state is in each case. _MelloN_ From owner-dhcp-v6@bucknell.edu Wed Aug 30 17:45:24 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09702 for ; Wed, 30 Aug 2000 17:45:24 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e7ULiWi24410; Wed, 30 Aug 2000 17:44:32 -0400 (EDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e7ULiSi04460 for ; Wed, 30 Aug 2000 17:44:28 -0400 (EDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id OAA05809; Wed, 30 Aug 2000 14:44:11 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id e7ULi7D07775; Wed, 30 Aug 2000 14:44:07 -0700 X-Virus-Scanned: Wed, 30 Aug 2000 14:44:07 -0700 Nokia Silicon Valley Email Exploit Scanner Received: from charliep.iprg.nokia.com (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(WTS.12.69) smtpd7hVwVX; Wed, 30 Aug 2000 14:44:03 PDT Sender: owner-dhcp-v6@bucknell.edu Message-ID: <39AD8026.4395DF11@iprg.nokia.com> Date: Wed, 30 Aug 2000 14:44:06 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: DHCPv6 discussion list CC: dhcp-v6@bucknell.edu, Jim Bound , Mike Carney Subject: Reasons for dynamic IPv6 address allocation for DHCPv6 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Reply-To: dhcp-v6@bucknell.edu X-Sender: charliep@iprg.nokia.com X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit Hello folks, Some people on the new DHCPv6 design team seem to be taking the viewpoint that managed IPv6 computers are going to be like desktops. >From that perspective, it's O.K. to revise the server's centralized IP address allocation policy and reboot the IPv6 computer whenever one needs a new IP address for some reason. Perhaps an exception will be made to allow network prefix renumbering to occur without rebooting. However, it seems quite likely that the future Internet will have a lot of highly configurable and mobile devices, for which the current static address configuration schemes being suggested will be inadequate. Some of the problem seems to stem from current preference of configuring all necessary client parameters at reboot time. What happens when the DHCPv6 client wants to run a synchronized application, and the server didn't give out the timeserver extension when the client rebooted? Why do we have to frame all application requirements in terms of what happens when the client reboots? This was a design goal for DHCPv6 -- to avoid tying all application needs to boot-time configuration. I am afraid that we're going back to boot-time constraints. It's a dark place, not healthy for mobile nodes. Regarding address allocation, the choices (as I understand them), are as follows: 1) Each computer will get an IPv6 address whenever it asks for it. If it asks twice, it will get two addresses. 2) Each computer will get the same list of IPv6 addresses no matter how often it asks. I _think_ that the proponents of (2) will require editing the server database before a DHCPv6 client could get another (new) address. This is being suggested as a matter of "simplicity". As a strong proponent of (1), and by the way as a strong proponent of highly reconfigurable embedded devices, I find this is a big step backwards from the existing DHCPv6 specification. Please note that any installation which favors (2) can trivially implement the appropriate policy even in the existing DHCPv6 specification. The discussion is not whether (2) is a useful model for network administration. No one disputes that (2) should be enabled by DHCPv6. No, instead, the discussion is whether (1) should even be allowed at all. The proponents of the supposed (in my opinion quite illusory) gain in simplicity wish to control address allocation policy to the extent that that DHCPv6 clients can never deviate from the pre-ordained list of addresses. Perhaps it will be "allowed" for clients to spoof new identities by representing themselves using new client identifiers. I offer a possible look at future address allocation policy. This is, of course, speculative, given that we have not evolved into the world of plentiful IPv6 addresses yet. First, I point out that anonymous addresses should (typically) be acquired and used once, by a single application, and not necessarily used again. Any policy by which a host computer is allocated a list of "anonymous addresses" by a DHCPv6 server, and gets the same list over and over again, is slightly cracked, again in my opinion. Designing a whole new DHCPv6 address allocation protocol for anonymous addresses certainly argues against any supposed gain in "simplicity". I think it is very likely that anonymous addresses on administered links have to be requested by the application at the time of execution, and not preallocated. Furthermore, any such address should be returned once it has been used (thus it is a "releasable resource"), or else requested with a short lifetime. DHCPv6 will likely be used to provide IPv6 care-of addresses on administered links. A mobile node may need to get a care-of address for each of its IPv6 home addresses, but we do not know enough to suppose that it always has to get a care-of address for each of its home addresses. It may use the same care-of address for more than one home address, or it may not. Sometimes it will want to get a care-of address for only one of its addresses, or two, or four, even if it might have 10 home addresses. For such a node to be constrained _by DHCPv6 protocol_ to always getting all of its care-of addresses from the server is highly suspect, and (worse) may imply some sort of preconfiguration of each mobile device at the DHCPv6 server. These are examples that are known today. In the future, there will be more. I almost hate to go into description, because after all the strife in DHCPv6 it could be I will be attacked as a dreamer who just does not understand existing practice. But damn the torpedoes and here I go. We do not _know_ all the ways that IPv6 addresses will be used. During this discussion, please keep in mind that future applications should be able to be dynamically loaded onto a host computer at any time. While many computers may not support such features, many other computers will. We should not have to design _two_ protocols for the different kinds of computers that use IPv6 addresses. I believe that IPv6 addresses will continue to embody a certain amount of context and identity (on behalf of the user). Thus, if an application wishes to create a separate context and avoid association with another application running on the same network node, the most natural thing will be for that application to configure a new IPv6 address. If the link is a managed link, then DHCPv6 has to provide for that. Each new (or sporadically used) identity may have special features: - security profile - QoS - special routing requirements (e.g. routing header) - remote profile management - separate billing It's not the job of the network layer feature configuration architect to limit these future choices. Thus, I claim that the direction, which has been very strongly encouraged by several DHCPv4 experts, towards eliminating IPv6 address configuration flexibility, is wrong. I hope that this note to the IPng working group will serve to raise the level of discussion so that the impending disaster can be averted. Lastly, I will mention that we can't tell the applications exactly how they ought to call DHCPv6 in order to get new addresses, because no one has yet designed the API. However, it would take a lot longer to get the API right, judging from the history of other APIs in the IPng group. That should not be a precondition for getting the protocol ready for initial deployment. Regards, Charlie P. From owner-dhcp-v6@bucknell.edu Wed Aug 30 17:47:11 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09718 for ; Wed, 30 Aug 2000 17:47:11 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e7ULkMi07254; Wed, 30 Aug 2000 17:46:22 -0400 (EDT) Received: from ztxmail02.ztx.compaq.com (ztxmail02.ztx.compaq.com [161.114.1.206]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e7ULkEi26252 for ; Wed, 30 Aug 2000 17:46:14 -0400 (EDT) Received: by ztxmail02.ztx.compaq.com (Postfix, from userid 12345) id C820DFFA; Wed, 30 Aug 2000 16:45:52 -0500 (CDT) Received: from yquarry.zk3.dec.com (brrquarry.zk3.dec.com [16.141.56.3]) by ztxmail02.ztx.compaq.com (Postfix) with ESMTP id 28502134E; Wed, 30 Aug 2000 16:45:52 -0500 (CDT) Received: from localhost by yquarry.zk3.dec.com (8.8.8/1.1.22.3/11Mar00-0650AM) id RAA0000028579; Wed, 30 Aug 2000 17:45:51 -0400 (EDT) From: Jim Bound Message-Id: <200008302145.RAA0000028579@yquarry.zk3.dec.com> X-Authentication-Warning: yquarry.zk3.dec.com: localhost [127.0.0.1] didn't use HELO protocol To: DHCPv6 discussion list Cc: "'Jim Bound'" , "'dhcp-v6@bucknell.edu'" , bound@ZK3.DEC.COM Subject: Re: Things I want to see in DHCPv6 In-reply-to: Your message of "Wed, 30 Aug 2000 17:22:02 EDT." <63D30D6E10CFD11190A90000F805FE8602BEC074@lespaul.process.com> Date: Wed, 30 Aug 2000 17:45:51 -0400 X-Mts: smtp 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 Hi Bernie, >>Just btw us I will tell you I will make damn sure that in any IPv6 >>implementation I work on users will be able to ignore this entire fiasco >>if they so choose to. Its mostly a joke IMO. WHOOPS. I was referencing the issue that joe-random-bad-guy will see my EUID go by on my book order to amazon.com and do evil things to my PC at home when I use IPv6. Politically the IETF has had to address this issue and Thomas has done a good job with the surgery to put this into IPv6 "privacy drafts", and we will have to make sure the code is there to do it. What I was saying is when the system comes up the user will get to respond: Do you care about this Privacy Junk and if you do I will be whacking your addresses every xxx minutes, but if you believe in personal responsibility and think this is not necessary we won't do this to you :----) >Yes, I can see arguments in that direction. While fundamentally the idea is >good (being able to uniquely identify a system), for almost all systems it >doesn't really matter what address they get (in theory). For those few >systems where addresses might be important, perhaps static or other >configuration techniques are more appropriate anyway (I think that's the >case in the IPv4 world). I agree and if dhcpv4 identifier works lets use it we were just trying to use what used to be pretty sure to be unique and also could be used to send to client on a local link. I don't care really we always have the IP header. I suggest we want to keep taking advantage of the architectural fact that IPv6 nodes do have IPv6 addresses for the link after they boot as part of the base protocol set. >This is likely more of an issue in the IPv4 world (it is something people >have come to expect) and my feeling that we do DHCPng is making me cling to >it? I think we need it for dhcpv6 too. Not commenting on dhcpng till the meeting. thanks /jim From owner-dhcp-v6@bucknell.edu Wed Aug 30 18:00:27 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09945 for ; Wed, 30 Aug 2000 18:00:27 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e7ULxVi31060; Wed, 30 Aug 2000 17:59:31 -0400 (EDT) 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 e7ULxJi03926 for ; Wed, 30 Aug 2000 17:59:29 -0400 (EDT) Received: from mjs-pc (mjs-pc.cisco.com [172.27.181.69]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id RAA11310 for ; Wed, 30 Aug 2000 17:59:03 -0400 (EDT) Message-Id: <4.2.0.58.20000830163902.0390fb20@funnel.cisco.com> X-Sender: mjs@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Wed, 30 Aug 2000 17:59:30 -0400 To: DHCPv6 discussion list From: Mark Stapp Subject: Re: Things I want to see in DHCPv6 In-Reply-To: <39AD6EEA.89DD70F0@research.telcordia.com> 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 These lists have been pretty interesting, and I like what's been suggested by Ralph and Bernie. My list is: 1. We should make every effort to accomodate both ipv4 and ipv6 addresses. There would be a great deal of value in a dhcpng that could support both address flavors. 2. A single fixed header, rather than different headers for different messages. The header should have a version byte (or bitfield), a flags field, and a length, possibly in quads. Fields that appear in every message might as well be in the header: the message type, for example, should be in the header. Some kind of link-local address (a MAC address or v6 link-local address) might as well be in the header, because it's going to have to appear once in every message anyway. In order to support (1), we should either exclude ip addresses from the header, relegating them to extensions, or define two initial header formats to carry the two different ip lengths. I'd like us to examine the possibility that most information would go into extensions. 3. Support a two-message lease binding - something like the "committed offer" that some of us were talking about in Pittsburgh. It sounded as if this would be a big help to the wireless folks. It also makes removing fields from the header and placing their data in extensions more palatable. I'd like to see language that allows a client to request a "committed" offer by setting a flag in the header. Servers which responded with offers that set that flag would have to have committed the binding to stable storage, and may have been configured with a different (shorter) lease/renew/rebind times to use in these bindings. 4. Simplify client releases: define a single way to "RELEASE" leases, with a "RELEASE" message. 5. Use the delayed authentication mechanism that dhcpv4 has been developing. 6. Simplify reconfiguration. I like the notion of 'reconfiguration multicast groups', but I'd prefer that clients which see a RECONFIGURE simply attempt to renew their leases, rather than enter a new set of states. It should be the server's responsibility to manage the number of clients which are being reconfigured simultaneously, and to retransmit (at appropriate intervals) RECONFIGUREs to those that it doesn't hear back from. 7. Consider ipv6 address compression. Is it likely that much of the data in a dhcp message that contains v6 addresses will be v6 addresses, and that some of those addresses will share prefixes? It seems as if these are natural candidates for in-packet compression (at least in messages from servers to clients). Since some other extension data will be fqdns, they may be candidates for compression too. 8. Support a client-identifier hierarchy, a la dhcpv4. Clients which wish to use a random or persistent id should be able to do so. Those clients will still have to supply a MAC (in ipv4) or link-local address (in ipv6) in order for replies to be addressed to them. If I understood Charlie's message correctly, an application could use this capability to obtain a 'new' dhcp address. Now, sometime I want someone to tell me more about applications that can poke the dhcp client on demand, and then tell the dhcp client and the stack to reserve the new address for its exclusive use. But _if_ that were possible, the client's use of a new client-id would let the _server_ allocate a new address. -- Mark From owner-dhcp-v6@bucknell.edu Wed Aug 30 18:08:15 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10068 for ; Wed, 30 Aug 2000 18:08:15 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e7UM7Bi18385; Wed, 30 Aug 2000 18:07:11 -0400 (EDT) Received: from mail.ultradns.com (mail.ultradns.net [64.41.145.150]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e7UM79i25382 for ; Wed, 30 Aug 2000 18:07:09 -0400 (EDT) Received: (qmail 24079 invoked from network); 30 Aug 2000 22:07:07 -0000 Received: from nat-external.ultradns.net (HELO ULTRADNS6PMNFK) (216.15.7.195) by mail.ultradns.com with SMTP; 30 Aug 2000 22:07:07 -0000 From: "Barr Hibbs" To: DHCPv6 discussion list Subject: RE: Design team teleconference on DHCPv6 Date: Wed, 30 Aug 2000 15:07:13 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <4.3.1.2.20000828213942.00b616e0@funnel.cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 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 Content-Transfer-Encoding: 7bit > -----Original Message----- > From: Ralph Droms > Sent: Monday, August 28, 2000 6:41 PM > > Be sure to contact me prior to the time of the teleconference > to get the number and conference ID. > > ...so, what is the number and conference ID? --Barr From owner-dhcp-v4@bucknell.edu Wed Aug 30 18:20:25 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10240 for ; Wed, 30 Aug 2000 18:20:25 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e7UMHLi11014; Wed, 30 Aug 2000 18:17:21 -0400 (EDT) Received: from mail.ultradns.com (mail.ultradns.net [64.41.145.150]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e7UMHBi24557 for ; Wed, 30 Aug 2000 18:17:13 -0400 (EDT) Received: (qmail 24354 invoked from network); 30 Aug 2000 22:17:09 -0000 Received: from nat-external.ultradns.net (HELO ULTRADNS6PMNFK) (216.15.7.195) by mail.ultradns.com with SMTP; 30 Aug 2000 22:17:09 -0000 From: "Barr Hibbs" To: DHCPv4 discussion list Subject: RE: Authentication option Date: Wed, 30 Aug 2000 15:17:14 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Reply-To: rbhibbs@ultraDNS.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit > -----Original Message----- > From: Ralph E. Droms > Sent: Wednesday, August 30, 2000 12:37 PM > > > On Wed, 30 Aug 2000, Bernie Volz wrote: > > But, I don't understand why anyone would ever want to > > accept messages that fail the authentication validation. > > I can understand using messages that do not have > > authentication information, but I can't understand why > > one would want to use messages where the authentication is > > corrupt or bogus (since I'd guess the rest of the packet is > > very suspect as well). > > OK - I read the consensus from the previous conversation as > wanting to allow local client policy to make the decision > about both messages with no authentication and messages that > fail authentication. I'm willing to change the text if the WG > wants to allow the former and disallow the latter. > ...my opinion is that clients and administrators probably do need a way to deal with those situations where something is broken and authentication doesn't work. Bernie: allowing a client to accept an unauthenticated message while notifying the user seems no more suspect than using unauthenticated clients and servers. I believe it is better to specifically allow this, insisting on useful notifications, than to ignore the possibility that authentication may break. > > Step 3 below might be clarified to read: > > > > 3. The client replies with a DHCPREQUEST message that > > MUST include authentication information encoded > > with the same secret used by the server in the > > selected DHCPOFFER message if the authentication > > was present and valid (otherwise, no authentication > > is used). > > That change makes sense... > ...agreed From owner-dhcp-v6@bucknell.edu Wed Aug 30 18:36:34 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10405 for ; Wed, 30 Aug 2000 18:36:34 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e7UMZTi30385; Wed, 30 Aug 2000 18:35:29 -0400 (EDT) Received: from zmamail01.zma.compaq.com (zmamail01.zma.compaq.com [161.114.64.101]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e7UMZGi09208 for ; Wed, 30 Aug 2000 18:35:16 -0400 (EDT) Received: by zmamail01.zma.compaq.com (Postfix, from userid 12345) id 05A4F58E1; Wed, 30 Aug 2000 18:35:01 -0400 (EDT) Received: from yquarry.zk3.dec.com (brrquarry.zk3.dec.com [16.141.56.3]) by zmamail01.zma.compaq.com (Postfix) with ESMTP id ADE7D231D; Wed, 30 Aug 2000 18:35:00 -0400 (EDT) Received: from localhost by yquarry.zk3.dec.com (8.8.8/1.1.22.3/11Mar00-0650AM) id SAA0000000031; Wed, 30 Aug 2000 18:34:59 -0400 (EDT) From: Jim Bound Message-Id: <200008302234.SAA0000000031@yquarry.zk3.dec.com> X-Authentication-Warning: yquarry.zk3.dec.com: localhost [127.0.0.1] didn't use HELO protocol To: DHCPv6 discussion list Cc: IPng Working Group , dhcp-v6@bucknell.edu, Jim Bound , Mike Carney Subject: Re: Reasons for dynamic IPv6 address allocation for DHCPv6 In-reply-to: Your message of "Wed, 30 Aug 2000 14:44:06 PDT." <39AD8026.4395DF11@iprg.nokia.com> Date: Wed, 30 Aug 2000 18:34:59 -0400 X-Mts: smtp 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 Charlie, Reference Point: -------------------------------- 1) Each computer will get an IPv6 address whenever it asks for it. If it asks twice, it will get two addresses. 2) Each computer will get the same list of IPv6 addresses no matter how often it asks. --------------------------------- As you already know and for the record I fully agree with all your "technical analysis" and also am a proponent of #1. You have also clearly articulated the reasoning why a different direction was selected in this instance than DHCPv4. Also what is very important architecturally as you stated, nothing in dhcpv6 prevents #2 at all. That being said it is also imperative we ship a spec by San Diego meeting that many implementors feel comfortable writing code to and showing up at our bake-offs at with running code in 2001. Hats off also to Francis Dupont and his team who have implemented this code and that should be a positive light and message to this community as Francis is one of our lead implementors for IPv6 for many years. Also as editor, implementor, and WG member for the IPv6 base API we all know APIs don't get done fast when you try to cover the future (e.g. Scoping, Anycast Effect) and to hold up any protocol for an API is just plain bad engineering trade-off judgement. We need to build the protocol and the API will come. Or look at the IPv6 Advanced API that is taking some time too. Not only that but wearing my product engineer hat it is very bad when you keep changing the API in an emerging market which we have done in IPv6 and we have mail from ISVs now that told us either stop or we give up on IPv6. So premature APIs are very dangerous in the market too. I think your mail should be part of the input to tomorrow's design interim meeting which I have the highest hopes for thorough and par excellence technical and architectural discussion will take place. Ralph Droms has done a good job putting together the agenda and is still collecting input and also the DHCPv4 implementors are reading the drafts. This is all goodness for IPv6 as I think many are totally convinced now that Stateless is not the only Plug N Play solution for IPv6 the market will want and need and my favorite metric "pay for". That in of itself has been a long hard battle in addition to building the protocol. I think it a good technical challenge to DHCPv6 for the folks who have lived with DHCPv4 implementations on the street, built them, or taught and configured them to ask the basic question of dhcpv6, why does the protocol leave any of the models inherent to DHCPv4. Also this protocol cannot be driven only by client/sever computing as was DHCPv4. I will not restate what you said so well but IPv6 and the Internet are about a lot more than client desktops, servers, and routers but about the Internet networking fabric that has evolved beyond any of the Pioneers expectations. DHCPv6 technically has to be extensibile and support the future needs of Mobile and Wireless devices where ever they may roam :-----). Talk to you at the meeting tomorrow. regards, /jim From owner-dhcp-v6@bucknell.edu Wed Aug 30 18:49:51 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10605 for ; Wed, 30 Aug 2000 18:49:47 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e7UMn3i16041; Wed, 30 Aug 2000 18:49:03 -0400 (EDT) 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 e7UMmni24203 for ; Wed, 30 Aug 2000 18:48:49 -0400 (EDT) Received: by lespaul.process.com with Internet Mail Service (5.5.2650.21) id ; Wed, 30 Aug 2000 18:48:34 -0400 Message-ID: <63D30D6E10CFD11190A90000F805FE8602BEC076@lespaul.process.com> From: Bernie Volz To: DHCPv6 discussion list Subject: RE: Reasons for dynamic IPv6 address allocation for DHCPv6 Date: Wed, 30 Aug 2000 18:48:26 -0400 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 Charlie: (I apologize in advance if this message violates the discussion rules.) I believe we need to support both address allocation capabilities and I don't believe the only time this information is needed is a boot time. And, I agree that the lack of an API standard shouldn't preclude these capabilities. The API will surely follow (perhaps requiring some time to become standardized). We do need to add these to our list of "Things I want to see in DHCPv6". While allocation choice 1 sounds nice, it can be extremely wasteful (in terms of allocatable resources). What if a client isn't receiving (or properly processing server responses) and keeps re-requesting addresses. Does that mean you want to allocate a new address for each request? Having the server remember transaction ids to detect duplicates doesn't solve the problem completely because the client could be crashing on receipt of the server's responses and that would mean different ids will be used. The questions really comes down to how does the server know what the intentions of the client are? I haven't yet figured out how the current DHCPv6 design communicates this (feel free to explain). I do think that current DHCPv4 model is rather restrictive (generally one address per "client"). I don't think this is appropriate longer term and for IPv6. One technique that could work, though it isn't optimum by any means, is to use the bulking technique we're proposing for the Failover protocol. An extension, such as the ip-address extension, is used as a boundary to mark the data associated with each address. So, extensions that follow apply to that address UNTIL another ip-address extension is encountered, in which case the extensions that follow it apply to that new address. Therefore, if a client wants to request three addresses is sends: ... header ... ere extension (global) ip-address extension 1 ere extension for address 1 ip-address extension 2 ere extension for address 2 ip-address extension 3 ere extension for address 3 When the server receives this request, is knows the client is requesting 3 addresses and either allocates all three or those that it can and returns the results. Now, the tricky part is what happens if the client wants a 4th address. One solution (though not optimum as mentioned) is for the client to send 4 ip-address extensions with the first 3 containing essentially renewals for those that it already has. The server then clearly understands that a 4th address is desired and can return it. Another option is to have a flag bit or different extension (or even message type) that says "new address" instead of a duplicate allocation. You could have a simple "REQUEST" message which gets the "base" resources. And you could have a "REQUEST-MORE" message that says 'get me something new'. This is a bit tricky because of lost messages and retransmissions so I'm not sure it is as good as the early suggestion to use multiple instances of the ip-address extension. NOTE: The above multiple-address requests really only apply (for IPv6) when an address on the same prefix is being requested. When different prefixes are used (and if only one address per prefix is desired), multiple simple requests work fine. - Bernie Volz IPWorks, Inc -----Original Message----- From: Charles E. Perkins [mailto:charliep@iprg.nokia.com] Sent: Wednesday, August 30, 2000 5:44 PM To: DHCPv6 discussion list Cc: dhcp-v6@bucknell.edu; Jim Bound; Mike Carney Subject: Reasons for dynamic IPv6 address allocation for DHCPv6 Hello folks, Some people on the new DHCPv6 design team seem to be taking the viewpoint that managed IPv6 computers are going to be like desktops. >From that perspective, it's O.K. to revise the server's centralized IP address allocation policy and reboot the IPv6 computer whenever one needs a new IP address for some reason. Perhaps an exception will be made to allow network prefix renumbering to occur without rebooting. However, it seems quite likely that the future Internet will have a lot of highly configurable and mobile devices, for which the current static address configuration schemes being suggested will be inadequate. Some of the problem seems to stem from current preference of configuring all necessary client parameters at reboot time. What happens when the DHCPv6 client wants to run a synchronized application, and the server didn't give out the timeserver extension when the client rebooted? Why do we have to frame all application requirements in terms of what happens when the client reboots? This was a design goal for DHCPv6 -- to avoid tying all application needs to boot-time configuration. I am afraid that we're going back to boot-time constraints. It's a dark place, not healthy for mobile nodes. Regarding address allocation, the choices (as I understand them), are as follows: 1) Each computer will get an IPv6 address whenever it asks for it. If it asks twice, it will get two addresses. 2) Each computer will get the same list of IPv6 addresses no matter how often it asks. I _think_ that the proponents of (2) will require editing the server database before a DHCPv6 client could get another (new) address. This is being suggested as a matter of "simplicity". As a strong proponent of (1), and by the way as a strong proponent of highly reconfigurable embedded devices, I find this is a big step backwards from the existing DHCPv6 specification. Please note that any installation which favors (2) can trivially implement the appropriate policy even in the existing DHCPv6 specification. The discussion is not whether (2) is a useful model for network administration. No one disputes that (2) should be enabled by DHCPv6. No, instead, the discussion is whether (1) should even be allowed at all. The proponents of the supposed (in my opinion quite illusory) gain in simplicity wish to control address allocation policy to the extent that that DHCPv6 clients can never deviate from the pre-ordained list of addresses. Perhaps it will be "allowed" for clients to spoof new identities by representing themselves using new client identifiers. I offer a possible look at future address allocation policy. This is, of course, speculative, given that we have not evolved into the world of plentiful IPv6 addresses yet. First, I point out that anonymous addresses should (typically) be acquired and used once, by a single application, and not necessarily used again. Any policy by which a host computer is allocated a list of "anonymous addresses" by a DHCPv6 server, and gets the same list over and over again, is slightly cracked, again in my opinion. Designing a whole new DHCPv6 address allocation protocol for anonymous addresses certainly argues against any supposed gain in "simplicity". I think it is very likely that anonymous addresses on administered links have to be requested by the application at the time of execution, and not preallocated. Furthermore, any such address should be returned once it has been used (thus it is a "releasable resource"), or else requested with a short lifetime. DHCPv6 will likely be used to provide IPv6 care-of addresses on administered links. A mobile node may need to get a care-of address for each of its IPv6 home addresses, but we do not know enough to suppose that it always has to get a care-of address for each of its home addresses. It may use the same care-of address for more than one home address, or it may not. Sometimes it will want to get a care-of address for only one of its addresses, or two, or four, even if it might have 10 home addresses. For such a node to be constrained _by DHCPv6 protocol_ to always getting all of its care-of addresses from the server is highly suspect, and (worse) may imply some sort of preconfiguration of each mobile device at the DHCPv6 server. These are examples that are known today. In the future, there will be more. I almost hate to go into description, because after all the strife in DHCPv6 it could be I will be attacked as a dreamer who just does not understand existing practice. But damn the torpedoes and here I go. We do not _know_ all the ways that IPv6 addresses will be used. During this discussion, please keep in mind that future applications should be able to be dynamically loaded onto a host computer at any time. While many computers may not support such features, many other computers will. We should not have to design _two_ protocols for the different kinds of computers that use IPv6 addresses. I believe that IPv6 addresses will continue to embody a certain amount of context and identity (on behalf of the user). Thus, if an application wishes to create a separate context and avoid association with another application running on the same network node, the most natural thing will be for that application to configure a new IPv6 address. If the link is a managed link, then DHCPv6 has to provide for that. Each new (or sporadically used) identity may have special features: - security profile - QoS - special routing requirements (e.g. routing header) - remote profile management - separate billing It's not the job of the network layer feature configuration architect to limit these future choices. Thus, I claim that the direction, which has been very strongly encouraged by several DHCPv4 experts, towards eliminating IPv6 address configuration flexibility, is wrong. I hope that this note to the IPng working group will serve to raise the level of discussion so that the impending disaster can be averted. Lastly, I will mention that we can't tell the applications exactly how they ought to call DHCPv6 in order to get new addresses, because no one has yet designed the API. However, it would take a lot longer to get the API right, judging from the history of other APIs in the IPng group. That should not be a precondition for getting the protocol ready for initial deployment. Regards, Charlie P. From owner-dhcp-v6@bucknell.edu Wed Aug 30 19:00:09 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10673 for ; Wed, 30 Aug 2000 19:00:08 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e7UMvVi22116; Wed, 30 Aug 2000 18:57:31 -0400 (EDT) Received: from mail.ultradns.com (mail.ultradns.net [64.41.145.150]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e7UMvHi08145 for ; Wed, 30 Aug 2000 18:57:17 -0400 (EDT) Received: (qmail 25218 invoked from network); 30 Aug 2000 22:57:16 -0000 Received: from nat-external.ultradns.net (HELO ULTRADNS6PMNFK) (216.15.7.195) by mail.ultradns.com with SMTP; 30 Aug 2000 22:57:16 -0000 From: "Barr Hibbs" To: DHCPv6 discussion list Subject: RE: Things I want to see in DHCPv6 Date: Wed, 30 Aug 2000 15:57:21 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 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 Content-Transfer-Encoding: 7bit 1. Same header format for Solicit, Advertise, Request, Reply, and Release messages. 2. Keep fields in same location for all message types. 3. Use of a unique identifier, one that is extremely unlikely to change, to identify a client. The DHCPv4 client identifier isn't globally unique, so we need a better definition of how to generate an identifier. 4. Where a DHCPv6 Extension is essentially identical to a DHCPv4 Option, use the same name for both. Otherwise, the DHCPv6 Extension names can be completely independent. 5. The message exchanges should be as brief as possible to support mobile users by: (1) reducing the number of messages if possible, (2) reducing the size of messages by careful construction of headers and incremental configuration, and (3) permitting a client to obtain 1-n addresses as needed rather than all at "boot" time. --Barr From owner-dhcp-v6@bucknell.edu Wed Aug 30 19:21:35 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10888 for ; Wed, 30 Aug 2000 19:21:35 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e7UNKqi13581; Wed, 30 Aug 2000 19:20:52 -0400 (EDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e7UNKbi21829 for ; Wed, 30 Aug 2000 19:20:37 -0400 (EDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id QAA14583; Wed, 30 Aug 2000 16:20:18 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id e7UNKGZ25059; Wed, 30 Aug 2000 16:20:16 -0700 X-Virus-Scanned: Wed, 30 Aug 2000 16:20:16 -0700 Nokia Silicon Valley Email Exploit Scanner Received: from Icharliep-1.iprg.nokia.com (205.226.22.18, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(WTS.12.69) smtpddM0fur; Wed, 30 Aug 2000 16:20:12 PDT Message-ID: <39AD95B1.61CE1C93@iprg.nokia.com> Date: Wed, 30 Aug 2000 16:16:01 -0700 From: "Charles E. Perkins" Organization: Nokia X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: DHCPv6 discussion list CC: "'dhcp-v6@bucknell.edu'" Subject: Re: Reasons for dynamic IPv6 address allocation for DHCPv6 References: <63D30D6E10CFD11190A90000F805FE8602BEC076@lespaul.process.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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 Content-Transfer-Encoding: 7bit Hello Bernie, Thanks for your note. Since I won't be there tomorrow, I will have to assume that technical discussion is a legitimate use for IETF mailing lists :-) Bernie Volz wrote: > While allocation choice 1 sounds nice, it can be extremely wasteful (in > terms of allocatable resources). What if a client isn't receiving (or > properly processing server responses) and keeps re-requesting addresses. > Does that mean you want to allocate a new address for each request? Having > the server remember transaction ids to detect duplicates doesn't solve the > problem completely because the client could be crashing on receipt of the > server's responses and that would mean different ids will be used. The server should keep track of all resources allocated per client, and it's able to identify its clients by (relay_address + lower client bits). If a client is crashing a lot, it should set the 'C' bit for each crash :-) If it doesn't do that, the server should probably enforce an upper limit on how many addresses to allocate. If the client fakes new interface identifiers each time, then I don't know what to do except track it down and administer many lashes with a wet noodle. Or you might use a user class identifier and require an authentication extension. > The questions really comes down to how does the server know what the > intentions of the client are? I haven't yet figured out how the current > DHCPv6 design communicates this (feel free to explain). I'll try, but please forgive me if I miss the point. - If a client asks for a new address, it should get one (within the limitations observed above) - If a client asks for an existing address, it should get a renewal. > Therefore, if a client wants to request three addresses is sends: > ... header ... > ere extension (global) > ip-address extension 1 > ere extension for address 1 > ip-address extension 2 > ere extension for address 2 > ip-address extension 3 > ere extension for address 3 > > When the server receives this request, is knows the client is requesting 3 > addresses and either allocates all three or those that it can and returns > the results. But it _could_ know that even if there were just 3 IP address extensions. > Now, the tricky part is what happens if the client wants a 4th address. It could just send another IP address extension. I don't think it has to include the previous IP addresses. Why would it? Somehow, I am thinking I didn't get the whole point of your question. Can you expand a little bit more? Regards, Charlie P. From owner-dhcp-v6@bucknell.edu Wed Aug 30 20:25:44 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11679 for ; Wed, 30 Aug 2000 20:25:44 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e7V0MTi01834; Wed, 30 Aug 2000 20:22:29 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e7V0MDi22596 for ; Wed, 30 Aug 2000 20:22:13 -0400 (EDT) Received: from grosse.bisbee.fugue.com (dhcp-test3.nominum.com [204.152.187.167] (may be forged)) by toccata.fugue.com (8.9.3/8.6.11) with ESMTP id XAA03078 for ; Tue, 29 Aug 2000 23:28:42 -0700 (PDT) Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.0/8.6.11) with ESMTP id e7V0M1M07948 for ; Wed, 30 Aug 2000 17:22:01 -0700 (MST) Message-Id: <200008310022.e7V0M1M07948@grosse.bisbee.fugue.com> To: DHCPv6 discussion list Subject: Re: Reasons for dynamic IPv6 address allocation for DHCPv6 In-Reply-To: Message from Bernie Volz of "Wed, 30 Aug 2000 18:48:26 -0400." <63D30D6E10CFD11190A90000F805FE8602BEC076@lespaul.process.com> Date: Wed, 30 Aug 2000 17:22:01 -0700 From: Ted Lemon 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 > When the server receives this request, is knows the client is requesting 3 > addresses and either allocates all three or those that it can and returns > the results. > > Now, the tricky part is what happens if the client wants a 4th address. This isn't tricky. All you need is to identify each address. So have the client send a client identifier, and an different address index for each address request. If it gets three addresses and later wants a fourth, it uses a new address index to get that one. I would suggest that if you want to clump addresses, you should define a clump option that encapsulates an entire packet, or something like that, rather than doing a special case on the ip address option. This avoids the artificial imposition of an ordering on how the options need to be laid out. _MelloN_ From owner-dhcp-v6@bucknell.edu Wed Aug 30 20:58:29 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12471 for ; Wed, 30 Aug 2000 20:58:24 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e7V0sli29803; Wed, 30 Aug 2000 20:54:47 -0400 (EDT) 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 e7V0sUi06885 for ; Wed, 30 Aug 2000 20:54:32 -0400 (EDT) Received: by lespaul.process.com with Internet Mail Service (5.5.2650.21) id ; Wed, 30 Aug 2000 20:54:14 -0400 Message-ID: <63D30D6E10CFD11190A90000F805FE8602BEC07A@lespaul.process.com> From: Bernie Volz To: DHCPv6 discussion list Subject: RE: Reasons for dynamic IPv6 address allocation for DHCPv6 Date: Wed, 30 Aug 2000 20:54:10 -0400 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 Ted: Yes, the "address index" is something I had thought about as well. It might actually be the simplest. It does require a server to record one more thing, but that isn't so bad. A server can easily implement a policy that limits clients to addresses - reject requests when the index is greater than (of course, that does require clients to number them sequentially and might not be wise). - Bernie -----Original Message----- From: Ted Lemon [mailto:mellon@nominum.com] Sent: Wednesday, August 30, 2000 8:22 PM To: DHCPv6 discussion list Subject: Re: Reasons for dynamic IPv6 address allocation for DHCPv6 > When the server receives this request, is knows the client is requesting 3 > addresses and either allocates all three or those that it can and returns > the results. > > Now, the tricky part is what happens if the client wants a 4th address. This isn't tricky. All you need is to identify each address. So have the client send a client identifier, and an different address index for each address request. If it gets three addresses and later wants a fourth, it uses a new address index to get that one. I would suggest that if you want to clump addresses, you should define a clump option that encapsulates an entire packet, or something like that, rather than doing a special case on the ip address option. This avoids the artificial imposition of an ordering on how the options need to be laid out. _MelloN_ From owner-dhcp-v6@bucknell.edu Wed Aug 30 21:17:25 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12917 for ; Wed, 30 Aug 2000 21:17:24 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e7V1Fri11495; Wed, 30 Aug 2000 21:15:53 -0400 (EDT) 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 e7V1Fei16533 for ; Wed, 30 Aug 2000 21:15:40 -0400 (EDT) Received: by lespaul.process.com with Internet Mail Service (5.5.2650.21) id ; Wed, 30 Aug 2000 21:15:24 -0400 Message-ID: <63D30D6E10CFD11190A90000F805FE8602BEC07B@lespaul.process.com> From: Bernie Volz To: DHCPv6 discussion list Cc: "'dhcp-v6@bucknell.edu'" Subject: RE: Reasons for dynamic IPv6 address allocation for DHCPv6 Date: Wed, 30 Aug 2000 21:15:15 -0400 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 >The server should keep track of all resources allocated per client, >and it's able to identify its clients by (relay_address + lower client bits). >If a client is crashing a lot, it should set the 'C' bit for each crash :-) >If it doesn't do that, the server should probably enforce an upper limit >on how many addresses to allocate. If the client fakes new interface >identifiers each time, then I don't know what to do except track it >down and administer many lashes with a wet noodle. Or you might >use a user class identifier and require an authentication extension. While setting the 'C' bit certainly works if you have only ONE type of allocatable resource, it doesn't work if you have many. For example, a client might have lost address information but not foobar information. OR, it might have remembered some of its addresses, but not all. So, it won't necessarily want to release everything (I guess that's perhaps were you'd use the release-all-but type of request). And, my previous issue for having to have a Server Transaction ID cache is also addressed in 15.4 and 15.1 - the transaction id is stored for a lease binding (as well as the client 'identifier'). Sorry I missed that earlier. This discussion does seem to be helping me get a better understanding of what currently is defined in DHCPv6 (hope it is helping others). And, the specification does seem to be cover all of these issues. Perhaps after some packet format and extensions (options) rework, I'll back the DHCPv6 specification. This version of the draft appears to be much more solid than I thought. Good job Charlie, Jim, and Mike!!! - Bernie Volz IPWorks, Inc. -----Original Message----- From: Charles E. Perkins [mailto:charliep@iprg.nokia.com] Sent: Wednesday, August 30, 2000 7:16 PM To: Bernie Volz Cc: 'dhcp-v6@bucknell.edu' Subject: Re: Reasons for dynamic IPv6 address allocation for DHCPv6 Hello Bernie, Thanks for your note. Since I won't be there tomorrow, I will have to assume that technical discussion is a legitimate use for IETF mailing lists :-) Bernie Volz wrote: > While allocation choice 1 sounds nice, it can be extremely wasteful (in > terms of allocatable resources). What if a client isn't receiving (or > properly processing server responses) and keeps re-requesting addresses. > Does that mean you want to allocate a new address for each request? Having > the server remember transaction ids to detect duplicates doesn't solve the > problem completely because the client could be crashing on receipt of the > server's responses and that would mean different ids will be used. The server should keep track of all resources allocated per client, and it's able to identify its clients by (relay_address + lower client bits). If a client is crashing a lot, it should set the 'C' bit for each crash :-) If it doesn't do that, the server should probably enforce an upper limit on how many addresses to allocate. If the client fakes new interface identifiers each time, then I don't know what to do except track it down and administer many lashes with a wet noodle. Or you might use a user class identifier and require an authentication extension. > The questions really comes down to how does the server know what the > intentions of the client are? I haven't yet figured out how the current > DHCPv6 design communicates this (feel free to explain). I'll try, but please forgive me if I miss the point. - If a client asks for a new address, it should get one (within the limitations observed above) - If a client asks for an existing address, it should get a renewal. > Therefore, if a client wants to request three addresses is sends: > ... header ... > ere extension (global) > ip-address extension 1 > ere extension for address 1 > ip-address extension 2 > ere extension for address 2 > ip-address extension 3 > ere extension for address 3 > > When the server receives this request, is knows the client is requesting 3 > addresses and either allocates all three or those that it can and returns > the results. But it _could_ know that even if there were just 3 IP address extensions. > Now, the tricky part is what happens if the client wants a 4th address. It could just send another IP address extension. I don't think it has to include the previous IP addresses. Why would it? Somehow, I am thinking I didn't get the whole point of your question. Can you expand a little bit more? Regards, Charlie P. From owner-dhcp-v6@bucknell.edu Wed Aug 30 21:24:16 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13042 for ; Wed, 30 Aug 2000 21:24:14 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e7V1MMi31817; Wed, 30 Aug 2000 21:22:22 -0400 (EDT) Received: from kitab.cisco.com (kitab.cisco.com [171.69.187.233]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e7V1M5i19135 for ; Wed, 30 Aug 2000 21:22:05 -0400 (EDT) Received: (from raj@localhost) by kitab.cisco.com (8.9.3/8.9.2) id SAA11653; Wed, 30 Aug 2000 18:20:55 -0700 (PDT) (envelope-from raj) From: Richard Johnson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14765.45813.818419.454727@kitab.cisco.com> Date: Wed, 30 Aug 2000 18:20:53 -0700 (PDT) To: DHCPv6 discussion list Subject: RE: Reasons for dynamic IPv6 address allocation for DHCPv6 In-Reply-To: <63D30D6E10CFD11190A90000F805FE8602BEC07A@lespaul.process.com> References: <63D30D6E10CFD11190A90000F805FE8602BEC07A@lespaul.process.com> X-Mailer: VM 6.75 under 20.4 "Emerald" XEmacs Lucid 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 Content-Transfer-Encoding: 7bit Bernie Volz writes: > Ted: > > Yes, the "address index" is something I had thought about as well. It might > actually be the simplest. It does require a server to record one more thing, > but that isn't so bad. A server can easily implement a policy that limits > clients to addresses - reject requests when the index is greater than > (of course, that does require clients to number them sequentially and > might not be wise). > > - Bernie Why not simply use one of the flag bits to say "this is a new request"? If it's not set, the server MAY reissue the same address it gave back last time. If it *is* set, the server MUST either issue a new address or reject the request. (I'm probably missing something obvious. :) /raj From owner-dhcp-v6@bucknell.edu Wed Aug 30 21:33:07 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13346 for ; Wed, 30 Aug 2000 21:33:06 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e7V1TWi08568; Wed, 30 Aug 2000 21:29:32 -0400 (EDT) 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 e7V1TTi03560 for ; Wed, 30 Aug 2000 21:29:29 -0400 (EDT) Received: by lespaul.process.com with Internet Mail Service (5.5.2650.21) id ; Wed, 30 Aug 2000 21:29:14 -0400 Message-ID: <63D30D6E10CFD11190A90000F805FE8602BEC07D@lespaul.process.com> From: Bernie Volz To: DHCPv6 discussion list Subject: RE: Reasons for dynamic IPv6 address allocation for DHCPv6 Date: Wed, 30 Aug 2000 21:29:07 -0400 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 See my other email (to Charlie and the mailing list) ... this actually is likely no longer an issue ... the DHCPv6 specification addresses it well. - Bernie -----Original Message----- From: Richard Johnson [mailto:raj@cisco.com] Sent: Wednesday, August 30, 2000 9:21 PM To: DHCPv6 discussion list Subject: RE: Reasons for dynamic IPv6 address allocation for DHCPv6 Bernie Volz writes: > Ted: > > Yes, the "address index" is something I had thought about as well. It might > actually be the simplest. It does require a server to record one more thing, > but that isn't so bad. A server can easily implement a policy that limits > clients to addresses - reject requests when the index is greater than > (of course, that does require clients to number them sequentially and > might not be wise). > > - Bernie Why not simply use one of the flag bits to say "this is a new request"? If it's not set, the server MAY reissue the same address it gave back last time. If it *is* set, the server MUST either issue a new address or reject the request. (I'm probably missing something obvious. :) /raj From owner-dhcp-v6@bucknell.edu Wed Aug 30 21:41:58 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA14264 for ; Wed, 30 Aug 2000 21:41:57 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e7V1eVi05797; Wed, 30 Aug 2000 21:40:31 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e7V1eQi09966 for ; Wed, 30 Aug 2000 21:40:26 -0400 (EDT) Received: from grosse.bisbee.fugue.com (dhcp-193.rc.vix.com [204.152.187.193]) by toccata.fugue.com (8.9.3/8.6.11) with ESMTP id AAA03219 for ; Wed, 30 Aug 2000 00:46:59 -0700 (PDT) Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.0/8.6.11) with ESMTP id e7V1eIM08152 for ; Wed, 30 Aug 2000 18:40:18 -0700 (MST) Message-Id: <200008310140.e7V1eIM08152@grosse.bisbee.fugue.com> To: DHCPv6 discussion list Subject: Re: Reasons for dynamic IPv6 address allocation for DHCPv6 In-Reply-To: Message from Bernie Volz of "Wed, 30 Aug 2000 20:54:10 -0400." <63D30D6E10CFD11190A90000F805FE8602BEC07A@lespaul.process.com> Date: Wed, 30 Aug 2000 18:40:18 -0700 From: Ted Lemon 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 > It does require a server to record one more thing, > but that isn't so bad. Indeed. I think it's better to require the server to store one more thing. We have learned from experience that sending more information is good in some cases - if we sent a state option with each DHCPv4 message, handling the DHCPREQUEST message would be *much* easier. _MelloN_ From owner-dhcp-v6@bucknell.edu Wed Aug 30 23:22:05 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA16301 for ; Wed, 30 Aug 2000 23:22:03 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e7V3Ifi11095; Wed, 30 Aug 2000 23:18:41 -0400 (EDT) Received: from ztxmail01.ztx.compaq.com (ztxmail01.ztx.compaq.com [161.114.1.205]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e7V3IZi04615 for ; Wed, 30 Aug 2000 23:18:35 -0400 (EDT) Received: by ztxmail01.ztx.compaq.com (Postfix, from userid 12345) id 354251D4F; Wed, 30 Aug 2000 22:18:20 -0500 (CDT) Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by ztxmail01.ztx.compaq.com (Postfix) with ESMTP id B24E91C4A for ; Wed, 30 Aug 2000 22:18:19 -0500 (CDT) Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM) id XAA0001002928; Wed, 30 Aug 2000 23:17:48 -0400 (EDT) From: Jim Bound Message-Id: <200008310317.XAA0001002928@anw.zk3.dec.com> To: DHCPv6 discussion list Cc: bound@ZK3.DEC.COM Subject: Re: Reasons for dynamic IPv6 address allocation for DHCPv6 In-reply-to: Your message of "Wed, 30 Aug 2000 21:15:15 EDT." <63D30D6E10CFD11190A90000F805FE8602BEC07B@lespaul.process.com> Date: Wed, 30 Aug 2000 23:17:47 -0400 X-Mts: smtp 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 thanks bernie we really did listen to folks too. I am sure we missed some input as it was a lot. Mike deserves the lion share of the credit. mike I think invented a mail parser/sorter to make sure we caught most of the input as the previous draft was way to long ago. we did not change some architectural points folks wanted but I think we need a meeting like tomorrow to get folks to tell us their thoughts. And we have to thank Thomas and Ralph for pushing all of us real hard to do this, me definitely included and I am pushed to work harder. but I am burning out on this and progress in anyway would envigorate me again. /jim From owner-dhcp-v6@bucknell.edu Thu Aug 31 09:37:13 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05887 for ; Thu, 31 Aug 2000 09:37:13 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e7VDTVi27219; Thu, 31 Aug 2000 09:29:32 -0400 (EDT) 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 e7VDTSi09808 for ; Thu, 31 Aug 2000 09:29:28 -0400 (EDT) Received: from rdroms-nt.cisco.com (ch2-dhcp133-127.cisco.com [161.44.133.127]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id JAA01369 for ; Thu, 31 Aug 2000 09:29:12 -0400 (EDT) Message-Id: <4.3.1.2.20000831092557.00b02480@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Thu, 31 Aug 2000 09:31:36 -0400 To: DHCPv6 discussion list From: Ralph Droms Subject: RE: Design team teleconference on DHCPv6 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 posted a couple of messages to my list of expected participants in this afternoon's teleconference. If you expect to participate and you didn't get these messages, or if you've decided you want to participate and haven't contacted me, please let me know. - Ralph From owner-dhcp-v4@bucknell.edu Thu Aug 31 10:29:37 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06626 for ; Thu, 31 Aug 2000 10:29:36 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e7VEPsi16859; Thu, 31 Aug 2000 10:25:54 -0400 (EDT) Received: from honts307.wal-mart.com (honts307.wal-mart.com [146.132.234.37]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e7VEPni09000 for ; Thu, 31 Aug 2000 10:25:49 -0400 (EDT) Received: from fwnts001-dmz.wal-mart.com ([146.132.235.8]) by honts307.wal-mart.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id QJAZCA2G; Thu, 31 Aug 2000 09:30:59 -0500 Received: from honts388.homeoffice.wal-mart.com by fwnts001-dmz.wal-mart.com via smtpd (for mailout.wal-mart.com [146.132.235.35]) with SMTP; 31 Aug 2000 14:25:27 UT Received: from honts305.homeoffice.wal-mart.com (unverified) by honts388.homeoffice.wal-mart.com (Content Technologies SMTPRS 4.1.5) with ESMTP id for ; Thu, 31 Aug 2000 09:25:27 -0500 Received: by HONTS305.homeoffice.wal-mart.com with Internet Mail Service (5.5.2650.21) id ; Thu, 31 Aug 2000 09:25:27 -0500 Message-ID: From: Nathan Lane To: DHCPv4 discussion list Subject: RE: Authentication option Date: Thu, 31 Aug 2000 09:25:14 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Reply-To: ndlane@wal-mart.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN I like the additional clairifications and the codifying of the client behavior from Barr. -Nathan ********************************************************************** This email and any files transmitted with it are confidential and intended solely for the individual or entity to whom they are addressed. If you have received this email in error destroy it immediately. ********************************************************************** From owner-dhcp-v6@bucknell.edu Thu Aug 31 11:52:04 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08415 for ; Thu, 31 Aug 2000 11:52:01 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e7VFlri20713; Thu, 31 Aug 2000 11:47:53 -0400 (EDT) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e7VFlbi12733 for ; Thu, 31 Aug 2000 11:47:37 -0400 (EDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id e7VFl9617342 for ; Thu, 31 Aug 2000 17:47:15 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id RAA05433 for ; Thu, 31 Aug 2000 17:47:08 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.9.3/8.9.3) with ESMTP id RAA28628 for ; Thu, 31 Aug 2000 17:48:12 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200008311548.RAA28628@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: DHCPv6 discussion list Subject: Re: Things I want to see in DHCPv6 Date: Thu, 31 Aug 2000 17:48:12 +0200 Sender: owner-dhcp-v6@bucknell.edu Reply-To: dhcp-v6@bucknell.edu X-Sender: Francis.Dupont@enst-bretagne.fr X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN I think I shall not be very politically correct because I come from the IPv6 world and *not* from the DHCP one (in fact I don't believe in DHCPv4, I always asked for static addresses at IETF meetings :-). The first point is we have two very different ways: - make a DHCPng for both IPv4 and IPv6 - make a statefull autoconfiguration protocol for IPv6 There are technical difficulties with the first option and the second is about something which has been needed in the IPv6 community for *years* then I'll arbitrary focus on the second path. * there is no good reason to copy DHCPv4 in DHCPv6 then my first proposal is to change the name in order to make this point clear. I'll use the name SFAC. * I insist: DHCPv6 is a wrong name because in IPv6 there is already a dynamic host configuration protocol. SFAC is the stateful part, ie. it does roughly the same thing but the state is not distributed in nodes, the state is retained and managed on a few servers. * SFAC doesn't need an unique identifier per interface because it has already one, the interface ID derived from EUI64. The EUI64 is not bound to the interface hardware, look at the nearest sparc if you need a proof. Of course if you have no IEEE-like hardware (using PPP for instance) it is good to use a stable storage for an identifier (I'd like to know where I can get the DHCPv4 'client identifier' if there is no stable storage available). This will work even it doesn't keep an immediate advantage of EUI64: global unicity (uniqueness?). * don't joke about the privacy draft, I don't believe it will be use (because it is simply not usable :-) in an environment where addresses are assigned by a management tool like a SFAC daemon. * I think SFAC has two major modes. In the first one it is used as a remplacement of stateless autoconfiguration, ie. it assigns exactly the same addresses, ... In the second mode it is used as a registration service, nodes will build their addresses as usual (ie. prefix+iid) but registered them to a SFAC server before using them. * an example for the second mode: the site is separated from the Internet by a firewall (filtering box, not a N..!). A packet can go through the firewall only if it has a registered address, then if someone blindly connects its laptop on a site subnet then he won't gain the priviledge to communicate with the outside... * there is already at least another (than IPv6 address) example of a releasable resource then keep them! * if we need to remove things, first kill the crazy POSIX time stuff. if we need to remove other things, delete extensions which can be easily done by the service location protocol. I think only the DNS stuff is useful because SFAC is a good DNS dynamic update agent. Regards Francis.Dupont@enst-bretagne.fr From owner-dhcp-v6@bucknell.edu Thu Aug 31 12:17:02 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08893 for ; Thu, 31 Aug 2000 12:17:01 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e7VGFvi00580; Thu, 31 Aug 2000 12:15:57 -0400 (EDT) Received: from uucp1.nwnexus.com (uucp1.nwnexus.com [206.63.63.110]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e7VGFmi12730 for ; Thu, 31 Aug 2000 12:15:48 -0400 (EDT) Received: from internaut.com (uucp@localhost) by uucp1.nwnexus.com (8.8.8/8.8.8) with UUCP id JAA13242 for bucknell.edu!dhcp-v6; Thu, 31 Aug 2000 09:15:47 -0700 (PDT) Received: from e1kj2.internaut.com by internaut.com (NX5.67e/NeXT-3.0) id AA02313; Thu, 31 Aug 00 08:55:14 -0800 From: "Bernard Aboba" To: DHCPv6 discussion list Subject: Client identifier Date: Thu, 31 Aug 2000 09:11:53 -0700 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-Msmail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <200008310140.e7V1eIM08152@grosse.bisbee.fugue.com> Importance: Normal X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400 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 Content-Transfer-Encoding: 7bit A comment on client identifier. This has several uses, one of which includes serving as the claim of identity for use in DHCP authentication. It seems awkward to me to have to rekey a client when they change their NIC. For that reason I would suggest not tying the client identifier to the EUI. A format that has been suggested in the past is concatenation of the hostname with an interface name and number. This has the advantage of being persistent across reboots as well as potentially NIC changes. From owner-dhcp-v6@bucknell.edu Thu Aug 31 12:17:03 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08887 for ; Thu, 31 Aug 2000 12:17:00 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e7VGG0i17670; Thu, 31 Aug 2000 12:16:00 -0400 (EDT) Received: from uucp1.nwnexus.com (uucp1.nwnexus.com [206.63.63.110]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e7VGFli02806 for ; Thu, 31 Aug 2000 12:15:49 -0400 (EDT) Received: from internaut.com (uucp@localhost) by uucp1.nwnexus.com (8.8.8/8.8.8) with UUCP id JAA13372; Thu, 31 Aug 2000 09:15:46 -0700 (PDT) Received: from e1kj2.internaut.com by internaut.com (NX5.67e/NeXT-3.0) id AA02249; Thu, 31 Aug 00 08:46:09 -0800 From: "Bernard Aboba" To: DHCPv6 discussion list Cc: Subject: RE: Things I want to see in DHCPv6 Date: Thu, 31 Aug 2000 09:02:49 -0700 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-Msmail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <63D30D6E10CFD11190A90000F805FE8602BEC071@lespaul.process.com> Importance: Normal X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400 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 Content-Transfer-Encoding: 7bit >BTW: Has anyone thought about whether DHCPv6 (or DHCPng) can or should be >able to give out multicast or the IPv6 "cluster" addresses (or whatever >they're called now if they still exist)? I would suggest not trying to solve MADCAPv6 issues with DHCPv6. The MALLOC WG initially tried to reuse DHCP formats for MADCAP and then decided to go their own way. Adding more constraints on the problem is likely to make it harder to solve and we've got enough on our plate already. From owner-dhcp-v6@bucknell.edu Thu Aug 31 12:17:03 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08892 for ; Thu, 31 Aug 2000 12:17:01 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e7VGFsi19648; Thu, 31 Aug 2000 12:15:54 -0400 (EDT) Received: from uucp1.nwnexus.com (uucp1.nwnexus.com [206.63.63.110]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e7VGFli27243 for ; Thu, 31 Aug 2000 12:15:47 -0400 (EDT) Received: from internaut.com (uucp@localhost) by uucp1.nwnexus.com (8.8.8/8.8.8) with UUCP id JAA13436 for bucknell.edu!dhcp-v6; Thu, 31 Aug 2000 09:15:46 -0700 (PDT) Received: from e1kj2.internaut.com by internaut.com (NX5.67e/NeXT-3.0) id AA02245; Thu, 31 Aug 00 08:46:06 -0800 From: "Bernard Aboba" To: DHCPv6 discussion list Subject: RE: Things I want to see in DHCPv6 Date: Thu, 31 Aug 2000 09:02:46 -0700 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-Msmail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <14765.24388.233799.596905@kitab.cisco.com> Importance: Normal X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400 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 Content-Transfer-Encoding: 7bit >* I would like to suggest that if the DHCPv6 protocol can be made to > work for DHCPv4 as well (which I think it can with a small amount > of effort), we could then use this as a sort of "DHCPng" and only > allow new options in DHCPng unless there's a really good reason for > including it in DHCPv4. This would strongly push everyone involved > to implement DHCPng as fast as possible in order to gain support > for new options. This is very similar to what the DNSEXT group is > doing with eDNS. This sounds like a really bad idea to me. Protocols need to stand on their own without having to hold hostages. If we're not confident that DHCPng will be deployed without this then its a sign that we've designed the wrong thing. I would note that DNSEXT is not a very good model since most of their work has not been widely deployed. >I could easily envision some types of extensions which may REQUIRE a >relay to change them. At lease we need to allow for a relay to ADD >additional extensions, such as in the case of the "DHCP Relay Agent >Information Option" of DHCPv4. You'd need to be careful not to invalidate DHCP authentication in the process, or end up requiring multiple authentication options, one for the ones the server sends, and another for the relay agent inserted ones. One of the things I like most about DHCPv4 is that these issues seem to have been thought through (and excess complexity avoided). From owner-dhcp-v6@bucknell.edu Thu Aug 31 12:17:07 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08890 for ; Thu, 31 Aug 2000 12:17:01 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e7VGG3i01512; Thu, 31 Aug 2000 12:16:03 -0400 (EDT) Received: from uucp1.nwnexus.com (uucp1.nwnexus.com [206.63.63.110]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e7VGFsi19867 for ; Thu, 31 Aug 2000 12:15:54 -0400 (EDT) Received: from internaut.com (uucp@localhost) by uucp1.nwnexus.com (8.8.8/8.8.8) with UUCP id JAA13416 for bucknell.edu!dhcp-v6; Thu, 31 Aug 2000 09:15:47 -0700 (PDT) Received: from e1kj2.internaut.com by internaut.com (NX5.67e/NeXT-3.0) id AA02309; Thu, 31 Aug 00 08:55:13 -0800 From: "Bernard Aboba" To: DHCPv6 discussion list Subject: RE: Things I want to see in DHCPv6 Date: Thu, 31 Aug 2000 09:11:53 -0700 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-Msmail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <4.2.0.58.20000830163902.0390fb20@funnel.cisco.com> Importance: Normal X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400 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 Content-Transfer-Encoding: 7bit >1. We should make every effort to accomodate both ipv4 and ipv6 addresses. >There would be a great deal of value in a dhcpng that could support both >address flavors. Can you provide a scenario in which this would be necessary? I've been presuming that a dual stack client that wanted an IPv4 address would use DHCPv4 over IPv4, and for IPv6, would use DHCPv6 over IPv6. Thus, I'm not clear on the need to include IPv4 options in DHCPv6. From owner-dhcp-v6@bucknell.edu Thu Aug 31 14:17:36 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11062 for ; Thu, 31 Aug 2000 14:17:32 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e7VIDFi02501; Thu, 31 Aug 2000 14:13:15 -0400 (EDT) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e7VID3i14561 for ; Thu, 31 Aug 2000 14:13:07 -0400 (EDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id e7VICf625731 for ; Thu, 31 Aug 2000 20:12:42 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id UAA06800 for ; Thu, 31 Aug 2000 20:12:41 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.9.3/8.9.3) with ESMTP id UAA29398 for ; Thu, 31 Aug 2000 20:12:40 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200008311812.UAA29398@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: DHCPv6 discussion list Subject: Re: Client identifier In-reply-to: Your message of Thu, 31 Aug 2000 09:11:53 PDT. Date: Thu, 31 Aug 2000 20:12:40 +0200 Sender: owner-dhcp-v6@bucknell.edu Reply-To: dhcp-v6@bucknell.edu X-Sender: Francis.Dupont@enst-bretagne.fr X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN In your previous mail you wrote: A comment on client identifier. This has several uses, one of which includes serving as the claim of identity for use in DHCP authentication. It seems awkward to me to have to rekey a client when they change their NIC. For that reason I would suggest not tying the client identifier to the EUI. => for server database lookup, an EUI64 is perfect but for security we need more an authenticator than an identifier but I agree we have to add an opaque and optional identifier (something like a IKE ID payload). A format that has been suggested in the past is concatenation of the hostname with an interface name and number. => just make it opaque. On my GSM I'd like to use the IMSI from the SIM. This has the advantage of being persistent across reboots as well as potentially NIC changes. => use a Sparc... (:-) Seriously interface IDs are not wired to NICs, MAC -> EUI64 -> interface ID is just a convenient/standard way to get an interface ID with good properties (but not the one you want), it is not the law even if some implementors (not me) don't provide enough freedom IMHO about this point. Thanks Francis.Dupont@enst-bretagne.fr From owner-dhcp-v4@bucknell.edu Thu Aug 31 15:17:29 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11929 for ; Thu, 31 Aug 2000 15:17:27 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e7VJCqi24892; Thu, 31 Aug 2000 15:12:53 -0400 (EDT) Received: from uucp1.nwnexus.com (uucp1.nwnexus.com [206.63.63.110]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e7VJCki27539 for ; Thu, 31 Aug 2000 15:12:46 -0400 (EDT) Received: from internaut.com (uucp@localhost) by uucp1.nwnexus.com (8.8.8/8.8.8) with UUCP id MAA22705; Thu, 31 Aug 2000 12:12:44 -0700 (PDT) Received: from e1kj2.internaut.com by internaut.com (NX5.67e/NeXT-3.0) id AA03344; Thu, 31 Aug 00 10:43:14 -0800 From: "Bernard Aboba" To: DHCPv4 discussion list Subject: RE: Authentication option Date: Thu, 31 Aug 2000 10:59:54 -0700 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-Msmail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <200008302123.e7ULNeM07623@grosse.bisbee.fugue.com> X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400 Reply-To: aboba@internaut.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit >Another point is: what if the kind of authentication being used by the >server is not supported by the client, so authentication fails not >because it is incorrect, but because it's not decodable. Is that the >same as an unauthenticated packet, or is it the same as an >authenticated packet whose authentication doesn't work? An authentication type mismatch isn't quite the same as an unauthenticated packet, because although you don't have the ability to verify the authentication, you do know that there is an authentication policy mismatch. The case to worry about is where the client demands a stronger form of authentication than the server is willing to supply. From owner-dhcp-v4@bucknell.edu Thu Aug 31 21:10:25 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA15110 for ; Thu, 31 Aug 2000 21:10:25 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e81122i11651; Thu, 31 Aug 2000 21:02:02 -0400 (EDT) Received: from codex.cis.upenn.edu (CODEX.CIS.UPENN.EDU [158.130.6.15]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8111ri11580 for ; Thu, 31 Aug 2000 21:01:53 -0400 (EDT) Received: from localhost (waa@localhost) by codex.cis.upenn.edu (8.10.1/8.10.1) with ESMTP id e810w6O18654; Thu, 31 Aug 2000 20:58:06 -0400 (EDT) Date: Thu, 31 Aug 2000 20:58:05 -0400 (EDT) From: "William A. Arbaugh" To: DHCPv4 discussion list cc: DHCPv4 discussion list Subject: RE: Authentication option In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: waa@dsl.cis.upenn.edu Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN > > An authentication type mismatch isn't quite the same > as an unauthenticated packet, because although you > don't have the ability to verify the authentication, > you do know that there is an authentication policy > mismatch. The case to worry about is where the client > demands a stronger form of authentication than the > server is willing to supply. > I propose the following: 1. An authentication mis-match should be treated in a similar fashion as if the server did not include authentication information. Any thing further and we're going done the security association negotiation trail (and it's a long one). 2. While I don't like the idea of accepting packets where the authentication option failed to verify, the server could just as well have sent the packet without authentication information and we would accept it (assumming the client would accept un-authenticated packets). Therefore, I propose that: a. If the client is configured to accept un-authenticated packets, then it MAY accept (if further configured) authenticated packets that fail to verify. We should stress that this is very dangerous and is only done for the sake of robustness. b. If the client is configured NOT to accept un-authenticated packets, then the client MUST NOT accept authenticated packets that fail to verify. Bill