From owner-dhcp-v4@bucknell.edu Tue Feb 1 07:32: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 HAA12795 for ; Tue, 1 Feb 2000 07:32:12 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id HAA12539; Tue, 1 Feb 2000 07:31:30 -0500 (EST) Received: from leo.eg.bucknell.edu (leo.eg.bucknell.edu [134.82.56.108]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id HAA09838 for ; Tue, 1 Feb 2000 07:31:03 -0500 (EST) Received: from droms-laptop (droms.eg.bucknell.edu [134.82.56.71]) by leo.eg.bucknell.edu (8.8.8+Sun/8.8.8) with ESMTP id HAA29730 for ; Tue, 1 Feb 2000 07:31:03 -0500 (EST) Message-Id: <4.2.2.20000201072903.00a6d660@mail.bucknell.edu> X-Sender: droms@mail.bucknell.edu X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Tue, 01 Feb 2000 07:29:38 -0500 To: DHCPv4 discussion list From: Ralph Droms Subject: I-D ACTION:draft-ietf-dhc-csr-00.txt 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 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Title : The Classless Static Route Option for DHCP Author(s) : T. Lemon Filename : draft-ietf-dhc-csr-00.txt Pages : 4 Date : 31-Jan-00 This document defines a new DHCP option which is passed from the DHCP Server to the DHCP Client to configure a list of static routes in the client. This option supersedes the Static Route option (option 33) defined in [2]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-csr-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dhc-csr-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dhc-csr-00.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: <20000131133823.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-csr-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-csr-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000131133823.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-dhcp-v4@bucknell.edu Tue Feb 1 07:36: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 HAA12922 for ; Tue, 1 Feb 2000 07:35:59 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id HAA00861; Tue, 1 Feb 2000 07:35:51 -0500 (EST) Received: from leo.eg.bucknell.edu (leo.eg.bucknell.edu [134.82.56.108]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id HAA04704 for ; Tue, 1 Feb 2000 07:32:53 -0500 (EST) Received: from droms-laptop (droms.eg.bucknell.edu [134.82.56.71]) by leo.eg.bucknell.edu (8.8.8+Sun/8.8.8) with ESMTP id HAA29734 for ; Tue, 1 Feb 2000 07:32:53 -0500 (EST) Message-Id: <4.2.2.20000201073140.00a4c1c0@mail.bucknell.edu> X-Sender: droms@mail.bucknell.edu X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Tue, 01 Feb 2000 07:32:49 -0500 To: DHCPv4 discussion list From: Ralph Droms Subject: WG last call: DHCP for IEEE 1394 (Reminder!!!) 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 (Please note that this last call will end Wednesday, 2/2 [tomorrow]... - RD) This is the DHC WG last call for the following document: http://www.ietf.org/internet-drafts/draft-ietf-ip1394-dhcp-02.txt This DHC WG last call will end 2/2. Please provide comments to the author, Kenji Fujisawa, and to this mailing list. This latest version of the document includes the authors response to comments from the DHC WG after the 7/99 WG meeting in Oslo. The document has passed the IEEE 1394 WG last call. Once the DHC WG last call completes, this document will be submitted to IESG for approval to become a Standards Track RFC and be accepted as an official DHCP Option. - Ralph Droms From owner-dhcp-v4@bucknell.edu Tue Feb 1 10:35: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 KAA22130 for ; Tue, 1 Feb 2000 10:35:21 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id KAA03317; Tue, 1 Feb 2000 10:34:49 -0500 (EST) Received: from alcor.process.com (alcor.process.com [192.42.95.16]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id KAA02005 for ; Tue, 1 Feb 2000 10:34:26 -0500 (EST) Received: by process.com (MX V5.1-X A2w8g) id 144; Tue, 1 Feb 2000 10:33:52 -0400 Sender: owner-dhcp-v4@bucknell.edu Date: Tue, 1 Feb 2000 10:33:52 -0400 From: Bernie Volz To: DHCPv4 discussion list CC: DHCP-V4@bucknell.edu Message-ID: <009E5028.4BE26F81.144@process.com> Subject: draft-ietf-dhc-csr-00.txt Reply-To: volz@process.com X-Sender: volz@process.com X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Ted: Thanks for producing this draft. Some comments: 1. In the option format diagram, you used 33 (the Static Routes option number). You should put in XX or something like that. 2. While I think we'd all assume that the subnet mask is supposed to have the NETWORK bits set, how about explicitly specifying that. In other words for a class C network, is it 255.255.255.0 or 0.0.0.255 (Cisco favors the 0.0.0.255 syntax in router configuration, so this is kind of important to specify, IMHO). 3. What about considering removing the subnet mask and instead specifying a subnet-mask-length. This would make each entry 9 bytes intead of 12. And, non-contiguous subnet masks are really not favored these days. 4. Should there be something said about host routes? Subnet mask of 255.255.255.255 (or subnet mask length of 32)? 5. Should there be something said about default routes (destination of 0.0.0.0)? This likely should be illegal, as it is for static routes, since these should be specified by the Router Option. [Or, should we also consider depreciating that and suggesting that these are placed in this new option - though at a significant byte expense - 8 extra bytes/route). I'd favor saying they are not allowed. 6. Should there be something said about a destination that has HOST bits set when applying the subnet mask? Should a DHCP client IGNORE that entry or treat the packet in error or should it install the "cleaned" route (by clearing the host bits). 7. Do we allow the router to be the DHCP Client itself? In which case, the client should assume that this is a "shared network" and there are multiple subnets on that physical cable. MIGHT we want to specify a shorthand for this to make DHCP Server configuration and option generation easier - if the Router is 0.0.0.0, the DHCP Client should assume that it is the router and hence that the subnet is directly reachable. 8. It is kind of odd that you do not reference any of the CIDR documents, such as RFC 1519. I think that's about it for now. Gee, and you thought that this would be quick and easy! Sorry. - Bernie Volz Process Software From owner-dhcp-v4@bucknell.edu Tue Feb 1 13:07: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 NAA27167 for ; Tue, 1 Feb 2000 13:07:54 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id NAA28024; Tue, 1 Feb 2000 13:07:02 -0500 (EST) Received: from toccata.fugue.com (toccata.fugue.com [204.152.188.66]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id NAA10767 for ; Tue, 1 Feb 2000 13:06:20 -0500 (EST) Received: from grosse.manhattan.fugue.com (tundruk.manhattan.fugue.com [160.79.19.71]) by toccata.fugue.com (8.9.3/8.6.11) with ESMTP id KAA28058; Tue, 1 Feb 2000 10:00:39 -0800 (PST) Received: from grosse.manhattan.fugue.com (localhost [127.0.0.1]) by grosse.manhattan.fugue.com (8.9.3/8.6.11) with ESMTP id NAA04397; Tue, 1 Feb 2000 13:06:13 -0500 (EST) Message-Id: <200002011806.NAA04397@grosse.manhattan.fugue.com> To: DHCPv4 discussion list cc: DHCP-V4@bucknell.edu Subject: Re: draft-ietf-dhc-csr-00.txt In-Reply-To: Message from Bernie Volz of "Tue, 01 Feb 2000 10:33:52 -0400." <009E5028.4BE26F81.144@process.com> Date: Tue, 01 Feb 2000 13:06:13 -0500 From: Ted Lemon Reply-To: mellon@isc.org Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN > 1. In the option format diagram, you used 33 (the Static Routes option > number). You should put in XX or something like that. D'oh! Ralph pointed this out to me, and I forgot to fix it. :'( > 2. While I think we'd all assume that the subnet mask is supposed to > have the NETWORK bits set, how about explicitly specifying that. In > other words for a class C network, is it 255.255.255.0 or 0.0.0.255 > (Cisco favors the 0.0.0.255 syntax in router configuration, so this is > kind of important to specify, IMHO). Good point. > 3. What about considering removing the subnet mask and instead > specifying a subnet-mask-length. This would make each entry 9 bytes > intead of 12. And, non-contiguous subnet masks are really not favored > these days. Hm. Interesting. I guess I'd have to say that I'd rather have the mask, because the fact that non-contiguous subnet masks aren't favored now doesn't mean nobody has a use for them. Can other folks comment on this point? > 4. Should there be something said about host routes? Subnet mask of > 255.255.255.255 (or subnet mask length of 32)? I don't know if it's necessary to say anything about this, but if you think it is, I'll add a paragraph. > 5. Should there be something said about default routes (destination of > 0.0.0.0)? This likely should be illegal, as it is for static routes, > since these should be specified by the Router Option. [Or, should we > also consider depreciating that and suggesting that these are placed in > this new option - though at a significant byte expense - 8 extra > bytes/route). I'd favor saying they are not allowed. I spent a bunch of time thinking about this. I don't like saying that a default route is illegal in the option, because this places a requirement on the server. I also don't like saying you shouldn't use default route and static routes together, because this also places a requirement on the server. I don't want the server to have to check this, and I particularly don't want a client to reject an offer because the author decided to be persnickety about this. So I kind of prefer leaving the behaviour undefined. I wouldn't mind putting a note in saying the server administrator SHOULD NOT configure a default route in the static route option. > 6. Should there be something said about a destination that has HOST bits > set when applying the subnet mask? Should a DHCP client IGNORE that > entry or treat the packet in error or should it install the "cleaned" > route (by clearing the host bits). Again, I think the best thing to do here would be to say that the server administrator SHOULD NOT do this, and leave the behaviour resulting from a violation of this SHOULD NOT unspecified. > 7. Do we allow the router to be the DHCP Client itself? In which case, > the client should assume that this is a "shared network" and there are > multiple subnets on that physical cable. MIGHT we want to specify a > shorthand for this to make DHCP Server configuration and option > generation easier - if the Router is 0.0.0.0, the DHCP Client should > assume that it is the router and hence that the subnet is directly > reachable. Wow. You want to put this knowledge in the DHCP server? This is a scary can of worms - if you want to do something like this, I think it needs to be a seperate draft, although it might be worthwhile to mention the possibility of a special meaning for 0.0.0.0 here. We'd have to be careful not to specify something in a way that would cause trouble later, though, or prevent this draft from advancing. > 8. It is kind of odd that you do not reference any of the CIDR > documents, such as RFC 1519. I read them over, and decided that they weren't relevant. They don't really talk about the mechanics of variable-width subnet masks - they just talk about an Internet backbone implementation strategy. I don't think you get any useful information that's germane to the topic of this option by reading them. I did actually reference the documents that specifically describe variable-width subnet masks. > I think that's about it for now. Gee, and you thought that this would be > quick and easy! Sorry. Not at all - you came up with some excellent comments! Thanks! I've included context diffs for the changes I've made based on your comments below. _MelloN_ *** draft-ietf-dhc-csr-00.txt~ Mon Jan 24 12:46:37 2000 --- draft-ietf-dhc-csr-00.txt Tue Feb 1 13:04:49 2000 *************** *** 117,125 **** destination. Code Len Destination 1 Subnet Mask 1 Router 1 ! +----+---+----+----+----+----+----+----+----+----+----+----+----+----+ ! | 33 | n | d1 | d2 | d3 | d4 | m1 | m2 | m3 | m4 | r1 | r2 | r3 | r4 | ! +----+---+----+----+----+----+----+----+----+----+----+----+----+----+ Destination 2 Subnet Mask 2 Router 2 +----+----+----+----+----+----+----+----+----+----+----+----+ --- 117,125 ---- destination. Code Len Destination 1 Subnet Mask 1 Router 1 ! +-----+---+----+----+----+----+----+----+----+----+----+----+----+----+ ! | TBD | n | d1 | d2 | d3 | d4 | m1 | m2 | m3 | m4 | r1 | r2 | r3 | r4 | ! +-----+---+----+----+----+----+----+----+----+----+----+----+----+----+ Destination 2 Subnet Mask 2 Router 2 +----+----+----+----+----+----+----+----+----+----+----+----+ *************** *** 128,139 **** --- 128,167 ---- In the above example, two static routes are specified. + Subnet masks specified in the Classless Static Routes option have + the one bit set for every bit in the mask that corresponds to the + network portion of IP addresses on the subnet being specified. So + for example, if a subnet has a network number of 10.17.64.0 and is + divided into 22 bits of network number and 10 bits of host number, + then the subnet mask would be 255.255.252.0. Host routes are + specified by a subnet mask of 255.255.255.255. + DHCP Client Behavior The DHCP client MAY use this option to install a set of static routes in its routing table. A DHCP client that implements this option SHOULD use this option in preference to the Static routes option if both are present in a reply from the DHCP server. + + DHCP Server administrator responsibilities + + The client's behaviour if both a Routers option and a Classless + Static Routes option default route (network number 0.0.0.0, network + mask 0.0.0.0) are specified is not defined in this document, so as + to avoid placing onerous requirements on the client and server + implementations. Therefore, the DHCP server administrator SHOULD + NOT configure the DHCP server so that it sends both a Routers + option and a Classless Static Routes option containing a default + route. Either no Routers option should be configured (this is + probably preferable in the near term, since only newer DHCP clients + will implement this option), or the Classless Static Routes option + should not contain a default route. + + The client's behaviour is also not defined in the case where the + server sends a classless static route in which some bits in the + network number are 1, and corresponding bits in the subnet mask are + zero. Therefore, DHCP server administrators SHOULD NOT configure + the DHCP server to send such a route. Security Considerations From owner-dhcp-v4@bucknell.edu Tue Feb 1 13:38: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 NAA28090 for ; Tue, 1 Feb 2000 13:38:49 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id NAA05011; Tue, 1 Feb 2000 13:37:37 -0500 (EST) Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id NAA06527 for ; Tue, 1 Feb 2000 13:37:33 -0500 (EST) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate.mot.com (VWALL-IN-motgate 2.0) with ESMTP id LAA05561 for ; Tue, 1 Feb 2000 11:37:31 -0700 (MST)] Received: [from noah.dma.isg.mot.com (noah.dma.isg.mot.com [150.21.2.29]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id LAA24789 for ; Tue, 1 Feb 2000 11:37:31 -0700 (MST)] Received: from dma.isg.mot.com (cabs1.dma.isg.mot.com [150.21.2.34]) by noah.dma.isg.mot.com (8.8.8+Sun/8.8.8) with ESMTP id NAA11949; Tue, 1 Feb 2000 13:37:29 -0500 (EST) Message-Id: <200002011837.NAA11949@noah.dma.isg.mot.com> To: DHCPv4 discussion list cc: mpatrick@dma.isg.mot.com Subject: Re: WG Last Call for "DHCP Relay Agent Information Option" I-D In-reply-to: Your message of "Fri, 28 Jan 2000 11:28:56 EST." <200001281628.LAA14340@grosse.manhattan.fugue.com> Date: Tue, 01 Feb 2000 13:37:29 -0500 From: "Michael W. Patrick" Reply-To: mpatrick@noah.dma.isg.mot.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Folks, I don't mind if the subnet mask option is moved to a separate draft. At the last IETF meeting, however, there was support both publicly and privately to keep it in. Is there anyone in the WG who would OBJECT to removing subnet mask sub-option for the initial relay agent option draft? In particular, Bernie Volz, Mike Carney, and Kim Kinnear, could you respond and give your opinion? Can you live without the subnet mask sub-option in the initial draft? -mike >>>>> "Ted" == Ted Lemon writes: > I respectfully request that the draft be withdrawn until my > objections to it, which I have expressed previously and in detail, > have been addressed. > To summarize, I believe that the implementation of the subnet mask > suboption has not been described completely, and is likely to result > in multiple non-interoperable implementations. The solution that I > propose is to seperate the subnet mask suboption into its own draft, > and try to do it justice there. I think it's a reasonable idea, but > it needs to be fleshed out some more. I don't want to see the Relay > Agent Information Option draft delayed until we have a better > specification for the subnet mask suboption. > In case anybody's thinking "aw, it's not such a big problem, why are > you so worried," please remember all the discussions we've had about > seemingly subtle points in RFC2132 like what the DHCP parameter > request list option does. The subnet mask suboption clearly has > wider implications, and yet the description of it is equally brief - > all that's described is the format of the option, and the meaning of > the bits in it. No requirements are placed on either the server or > the relay agent. This is a recipe for disaster. > I'm really sorry to be a stick-in-the-mud about this. Michael > Patrick has worked hard on this draft, and deserves some > satisfaction. It is partially my fault that we're at the point we > are at - if I had carefully read the several previous versions of > the draft in which the suboption was added, I could have raised my > objections sooner, and perhaps we could have fixed the wording in > time for the subnet mask suboption to be in the draft. However, > this fact is not a reason not to do the right thing - it is merely > evidence of a failure on my part, for which I apologize. > _MelloN_ From owner-dhcp-v4@bucknell.edu Tue Feb 1 15:23: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 PAA01646 for ; Tue, 1 Feb 2000 15:23:46 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id PAA01506; Tue, 1 Feb 2000 15:22:56 -0500 (EST) Received: from alcor.process.com (alcor.process.com [192.42.95.16]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id PAA25801 for ; Tue, 1 Feb 2000 15:22:48 -0500 (EST) Received: by process.com (MX V5.1-X A2w8g) id 117; Tue, 1 Feb 2000 15:22:09 -0400 Sender: owner-dhcp-v4@bucknell.edu Date: Tue, 1 Feb 2000 15:22:09 -0400 From: Bernie Volz To: DHCPv4 discussion list CC: DHCP-V4@bucknell.edu Message-ID: <009E5050.91C7F750.117@process.com> Subject: Re: draft-ietf-dhc-csr-00.txt Reply-To: volz@process.com X-Sender: volz@process.com X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Ted: >From: Ted Lemon > >> 3. What about considering removing the subnet mask and instead >> specifying a subnet-mask-length. This would make each entry 9 bytes >> intead of 12. And, non-contiguous subnet masks are really not favored >> these days. > >Hm. Interesting. I guess I'd have to say that I'd rather have the >mask, because the fact that non-contiguous subnet masks aren't favored >now doesn't mean nobody has a use for them. Can other folks comment >on this point? OK. Would be interesting to hear some feedback on this, but I do believe most everyone uses contiguous masks. >> 4. Should there be something said about host routes? Subnet mask of >> 255.255.255.255 (or subnet mask length of 32)? > >I don't know if it's necessary to say anything about this, but if you >think it is, I'll add a paragraph. I think it would be useful to say something (and you did in the revised text - thanks). >> 5. Should there be something said about default routes (destination of >> 0.0.0.0)? This likely should be illegal, as it is for static routes, >> since these should be specified by the Router Option. [Or, should we >> also consider depreciating that and suggesting that these are placed in >> this new option - though at a significant byte expense - 8 extra >> bytes/route). I'd favor saying they are not allowed. > >I spent a bunch of time thinking about this. I don't like saying >that a default route is illegal in the option, because this places a >requirement on the server. I also don't like saying you shouldn't >use default route and static routes together, because this also places >a requirement on the server. I don't want the server to have to >check this, and I particularly don't want a client to reject an offer >because the author decided to be persnickety about this. So I kind >of prefer leaving the behaviour undefined. I wouldn't mind putting a >note in saying the server administrator SHOULD NOT configure a default >route in the static route option. OK. >> 6. Should there be something said about a destination that has HOST bits >> set when applying the subnet mask? Should a DHCP client IGNORE that >> entry or treat the packet in error or should it install the "cleaned" >> route (by clearing the host bits). > >Again, I think the best thing to do here would be to say that the >server administrator SHOULD NOT do this, and leave the behaviour >resulting from a violation of this SHOULD NOT unspecified. Personally, I think it best to say: 1) An administrator SHOULD NOT do this. 2) A client MUST clean the destination before installing the route (unless the "stack" will do it for the client). >> 7. Do we allow the router to be the DHCP Client itself? In which case, >> the client should assume that this is a "shared network" and there are >> multiple subnets on that physical cable. MIGHT we want to specify a >> shorthand for this to make DHCP Server configuration and option >> generation easier - if the Router is 0.0.0.0, the DHCP Client should >> assume that it is the router and hence that the subnet is directly >> reachable. > >Wow. You want to put this knowledge in the DHCP server? This is a >scary can of worms - if you want to do something like this, I think it >needs to be a seperate draft, although it might be worthwhile to >mention the possibility of a special meaning for 0.0.0.0 here. We'd >have to be careful not to specify something in a way that would cause >trouble later, though, or prevent this draft from advancing. Sure - the DHCP Server already has this knowledge for proper operation. This may be manually configured for a subnet/shared network. Or, a server could determine some of this information automatically from its configuration data. The issues here are: 1) Do we allow these kinds of routes? 2) If so, the 0.0.0.0 for the router makes it easier for the administrator to configure (since they can do it on a subnet or shared network basis) or for the server to automically construct. If you use the traditional mention of using the client's local IP address, then the server would have to customize this option for each client. - Bernie Volz Process Software From owner-dhcp-v4@bucknell.edu Tue Feb 1 16: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 QAA05434 for ; Tue, 1 Feb 2000 16:43:25 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id QAA22840; Tue, 1 Feb 2000 16:42:11 -0500 (EST) Received: from alcor.process.com (alcor.process.com [192.42.95.16]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id QAA18403 for ; Tue, 1 Feb 2000 16:42:06 -0500 (EST) Received: by process.com (MX V5.1-X A2w8g) id 201; Tue, 1 Feb 2000 16:41:33 -0400 Sender: owner-dhcp-v4@bucknell.edu Date: Tue, 1 Feb 2000 16:41:33 -0400 From: Bernie Volz To: DHCPv4 discussion list CC: DHCP-V4@bucknell.edu Message-ID: <009E505B.A971DFCD.201@process.com> Subject: Re: WG Last Call for "DHCP Relay Agent Information Option" I-D Reply-To: volz@process.com X-Sender: volz@process.com X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN >Folks, > >I don't mind if the subnet mask option is moved to a separate draft. >At the last IETF meeting, however, there was support both publicly and >privately to keep it in. > >Is there anyone in the WG who would OBJECT to removing subnet >mask sub-option for the initial relay agent option draft? >In particular, Bernie Volz, Mike Carney, and Kim Kinnear, could >you respond and give your opinion? Can you live without the >subnet mask sub-option in the initial draft? > >-mike Mike: I can certainly live without the option being in the draft. Though, I don't have servere objections if it is left in. While I easily agree with Ted that more description or discussion on its intended usage and issues regarding it could be added, I feel what is there is clear. My areas of clarification are mostly around the server automatically creating a scope; but this may be considered a server issue and thus may be outside the scope of the draft/RFC. I do have one issue with the document ... what should a DHCP server do if it receives a RELAY AGENT option but the giaddr is 0? The document is clear about what a relay agent should do, but not about what a server itself should do. Is there any reason why a RELAY AGENT option would appear with a giaddr of 0 (doesn't that imply that the CLIENT added it and thus voids some of the assumptions). You might also fix 10.0, the author's address. There is "DS" after this on the title line. Regards, - Bernie Volz Process Software From owner-dhcp-v4@bucknell.edu Tue Feb 1 22:03: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 WAA14159 for ; Tue, 1 Feb 2000 22:03:31 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id WAA12384; Tue, 1 Feb 2000 22:03:09 -0500 (EST) Received: from leo.eg.bucknell.edu (leo.eg.bucknell.edu [134.82.56.108]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id WAA26856 for ; Tue, 1 Feb 2000 22:02:45 -0500 (EST) Received: from droms-laptop (host22.bvtc.ptd.net [209.173.2.22]) by leo.eg.bucknell.edu (8.8.8+Sun/8.8.8) with ESMTP id WAA00710 for ; Tue, 1 Feb 2000 22:02:44 -0500 (EST) Message-Id: <4.2.2.20000201220104.00a3e4b0@mail.bucknell.edu> X-Sender: droms@mail.bucknell.edu X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Tue, 01 Feb 2000 22:01:21 -0500 To: DHCPv4 discussion list From: Ralph Droms Subject: dhcp-v4 list archive 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 There is a web-based archive for the dhcp-v4 mailing list at http://www.listproc.bucknell.edu/cgi-bin/archdex?list=dhcp-v4 The search function is working now that the list archive is in production. Unfortunately, list threads are not followed from one month's archive to the next. - Ralph Droms From owner-dhcp-v6@bucknell.edu Tue Feb 1 22:10: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 WAA14239 for ; Tue, 1 Feb 2000 22:10:36 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id WAA29086; Tue, 1 Feb 2000 22:03:01 -0500 (EST) Received: from leo.eg.bucknell.edu (dns.dhcp.org [134.82.56.120]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id WAA04945 for ; Tue, 1 Feb 2000 22:02:44 -0500 (EST) Received: from droms-laptop (host22.bvtc.ptd.net [209.173.2.22]) by leo.eg.bucknell.edu (8.8.8+Sun/8.8.8) with ESMTP id WAA00707 for ; Tue, 1 Feb 2000 22:02:43 -0500 (EST) Message-Id: <4.2.2.20000201215818.00a70460@mail.bucknell.edu> X-Sender: droms@mail.bucknell.edu X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Tue, 01 Feb 2000 22:00:41 -0500 To: DHCPv6 discussion list From: Ralph Droms Subject: dhcp-v6 list archive 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 There is a web-based archive for the dhcp-v6 mailing list at http://www.listproc.bucknell.edu/cgi-bin/archdex?list=dhcp-v6 The search function is working now that the list archive is in production. Unfortunately, list threads are not followed from one month's archive to the next. - Ralph Droms From owner-dhcp-v4@bucknell.edu Wed Feb 2 02:24: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 CAA29876 for ; Wed, 2 Feb 2000 02:24:17 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id CAA19648; Wed, 2 Feb 2000 02:23:39 -0500 (EST) Received: from toccata.fugue.com (toccata.fugue.com [204.152.188.66]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id CAA29375 for ; Wed, 2 Feb 2000 02:23:25 -0500 (EST) Received: from grosse.manhattan.fugue.com (tundruk.manhattan.fugue.com [160.79.19.71]) by toccata.fugue.com (8.9.3/8.6.11) with ESMTP id XAA29948; Tue, 1 Feb 2000 23:17:47 -0800 (PST) Received: from grosse.manhattan.fugue.com (localhost [127.0.0.1]) by grosse.manhattan.fugue.com (8.9.3+3.2W/8.6.11) with ESMTP id BAA01156; Wed, 2 Feb 2000 01:45:23 -0500 (EST) Message-Id: <200002020645.BAA01156@grosse.manhattan.fugue.com> To: DHCPv4 discussion list cc: DHCPv4 discussion list Subject: Re: WG Last Call for "DHCP Relay Agent Information Option" I-D In-Reply-To: Message from Bernie Volz of "Tue, 01 Feb 2000 16:41:33 -0400." <009E505B.A971DFCD.201@process.com> Date: Wed, 02 Feb 2000 01:45:23 -0500 From: Ted Lemon Reply-To: mellon@isc.org Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN > My areas of clarification are mostly around the server automatically > creating a scope; but this may be considered a server issue and thus may > be outside the scope of the draft/RFC. This is precisely the problem, Bernie - specifying server behaviour does appear to be beyond the scope of the relay agent information options draft, but this option does imply behaviour on the part of the server, and to leave it unspecified is inappropriate. To leave it unspecified will likely cause major trouble in the future. > I can certainly live without the option being in the draft. Though, I > don't have servere objections if it is left in. While I easily agree > with Ted that more description or discussion on its intended usage and > issues regarding it could be added, I feel what is there is clear. Can you please boil this down to one of "yes, I want the draft left as is," "I abstain," or "no, I want the draft changed?" :'} Thanks! _MelloN_ From owner-dhcp-v4@bucknell.edu Wed Feb 2 09: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 JAA10045 for ; Wed, 2 Feb 2000 09:23:10 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id JAA05846; Wed, 2 Feb 2000 09:22:06 -0500 (EST) Received: from alcor.process.com (alcor.process.com [192.42.95.16]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id JAA12661 for ; Wed, 2 Feb 2000 09:21:16 -0500 (EST) Received: by process.com (MX V5.1-X A2w8g) id 133; Wed, 2 Feb 2000 09:20:42 -0400 Sender: owner-dhcp-v4@bucknell.edu Date: Wed, 2 Feb 2000 09:20:42 -0400 From: Bernie Volz To: DHCPv4 discussion list CC: DHCP-V4@bucknell.edu Message-ID: <009E50E7.3DA0363D.133@process.com> Subject: Re: WG Last Call for "DHCP Relay Agent Information Option" I-D Reply-To: volz@process.com X-Sender: volz@process.com X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Ted: >> My areas of clarification are mostly around the server automatically >> creating a scope; but this may be considered a server issue and thus may >> be outside the scope of the draft/RFC. > >This is precisely the problem, Bernie - specifying server behaviour >does appear to be beyond the scope of the relay agent information >options draft, but this option does imply behaviour on the part of the >server, and to leave it unspecified is inappropriate. To leave it >unspecified will likely cause major trouble in the future. I believe from a PROTOCOL standpoint, the document is clear. My issues are CONFIGURATION related. Creating a scope can be done manually or automatically. If done automatically, how are the ranges of addresses to be used determined, what options are associated with the scope, etc. This is all a configuration issue and we generally stay away from that in these documents. I don't see why we would want to constrain implementations to do what they feel is appropriate for their needs (whatever they may be). Basically, using ISC configuration like syntax, one might have: template subnet 255.255.192.0 { range 2 1022; option routers 1; } This would say when creating a subnet, declare a range of .2 to 3.254 (this is a template for a 22 bit mask) with a router at the .1 address. But, again, I don't see that the draft needs to specify this. Whatever it means to your server to create an appropriate scope is what should be done. The draft says that servers MAY (not SHOULD or MUST) do this. Perhaps if you are clear as to what issues you feel aren't addressed in the draft I can better understand your concerns. Your original message was exceedingly vague in my opinion. What are the "wider implications"? Why do you suspect that it is likely to result in "multiple non- interoperable implementations"? I could make these statements about anything that is proposed - back them up with concrete issues please! I agrue that the generic concept of creating a scope is clear; what isn't clear and is a server configuration issue is what in detail a server does when creating a scope (see above). >> I can certainly live without the option being in the draft. Though, I >> don't have servere objections if it is left in. While I easily agree >> with Ted that more description or discussion on its intended usage and >> issues regarding it could be added, I feel what is there is clear. > >Can you please boil this down to one of "yes, I want the draft left as >is," "I abstain," or "no, I want the draft changed?" :'} How about a fourth choice - "I don't care". Perhaps you would call that "I abstain". > >Thanks! > > _MelloN_ - Bernie From owner-dhcp-v4@bucknell.edu Wed Feb 2 10:09: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 KAA11719 for ; Wed, 2 Feb 2000 10:09:26 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id KAA31763; Wed, 2 Feb 2000 10:09:13 -0500 (EST) Received: from alcor.process.com (alcor.process.com [192.42.95.16]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id KAA14229 for ; Wed, 2 Feb 2000 10:08:58 -0500 (EST) Received: by process.com (MX V5.1-X A2w8g) id 368; Wed, 2 Feb 2000 10:08:14 -0400 Sender: owner-dhcp-v4@bucknell.edu Date: Wed, 2 Feb 2000 10:08:13 -0400 From: Bernie Volz To: DHCPv4 discussion list CC: DHCP-V4@bucknell.edu Message-ID: <009E50ED.E14DB1DD.368@process.com> Subject: Re: WG Last Call for "DHCP Relay Agent Information Option" I-D Reply-To: volz@process.com X-Sender: volz@process.com X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Oops: >Basically, using ISC configuration like syntax, one might have: > template subnet 255.255.192.0 { > range 2 1022; > option routers 1; > } That 255.255.192.0 should have been 255.255.252.0. (That's one reason I like the subnet mask-length better than these darn masks.) - Bernie From owner-dhcp-v4@bucknell.edu Wed Feb 2 12:52: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 MAA16713 for ; Wed, 2 Feb 2000 12:52:09 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id MAA16198; Wed, 2 Feb 2000 12:51:15 -0500 (EST) Received: from toccata.fugue.com (toccata.fugue.com [204.152.188.66]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id MAA01508 for ; Wed, 2 Feb 2000 12:51:04 -0500 (EST) Received: from grosse.manhattan.fugue.com (tundruk.manhattan.fugue.com [160.79.19.71]) by toccata.fugue.com (8.9.3/8.6.11) with ESMTP id JAA03915; Wed, 2 Feb 2000 09:45:21 -0800 (PST) Received: from grosse.manhattan.fugue.com (localhost [127.0.0.1]) by grosse.manhattan.fugue.com (8.9.3+3.2W/8.6.11) with ESMTP id MAA04894; Wed, 2 Feb 2000 12:50:56 -0500 (EST) Message-Id: <200002021750.MAA04894@grosse.manhattan.fugue.com> To: DHCPv4 discussion list cc: DHCP-V4@bucknell.edu Subject: Re: WG Last Call for "DHCP Relay Agent Information Option" I-D In-Reply-To: Message from Bernie Volz of "Wed, 02 Feb 2000 09:20:42 -0400." <009E50E7.3DA0363D.133@process.com> Date: Wed, 02 Feb 2000 12:50:56 -0500 From: Ted Lemon Reply-To: mellon@isc.org Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN > I believe from a PROTOCOL standpoint, the document is clear. >From the standpoint of the protocol by which the relay agent communicates to the DHCP server the subnet mask that it is using on the subnet to which the client is connected, I agree that this is so. However, this is not the entirety of the protocol. The point of a good protocol specification is that two practitioners in the field should both feel confident that they can say what the other's code will do, without ever having done an interoperability test, as long as both practitioners know that each other's code conforms to the standard. This is a high standard to shoot for, and maybe we can't perfectly reach it, but we should at least try. What I am saying is that by addressing strictly the wire format of an option, the subnet mask suboption specification doesn't try to achieve this goal, and this is why I want to discuss it further. My purpose in not participating in consensus here is not to perfect the specification of the subnet mask suboption right now. It's simply to recommend that we discuss it further, and try to specify it more completely. The reason that I give the parameter request list as an example is that the *format* of the parameter request list is perfectly described in RFC2132, but the *implications* of the parameter request list are not. I believe the subnet mask suboption has this same problem. I will mention a few places where I see problems with this suboption, but again, the purpose of this discussion is to pull the suboption out into its own draft and *then* nail it down properly, *not* to nail it down properly right now, so please do not argue the points I present below with me right now - just take them as examples of why the subnet mask suboption ought to be discussed further. First, what *else* is in the packet the router sends that interacts with this suboption? The giaddr comes to mind. What should the giaddr be? Should it be specified? Should the giaddr be one greater than the subnet number for the subnet, for example? Are any IP addresses on one of these subnets reserved? Is the .0 reserved? Is the .all-ones reserved? What about .0+1 and .all-ones-1? What does the server do if the router sends a subnet mask of /30, /31 or /32? What is the purpose of this suboption? Is it so that routers can dynamically add subnets, or just so that routers can inform the DHCP server as to their configuration, so that the DHCP server can confirm that it's configured correctly? Or so that the DHCP server can implicitly be configured by configuring the router - i.e., to push configuration information away from the server and out to the router? What are the implications if there are two DHCP servers doing failover? Both DHCP servers had better make the same assumptions, right? Do the servers do failover on the new subnet? What if there are two DHCP servers that *aren't* doing failover? What happens if somebody sends the DHCP server a forged packet with a giaddr of, say, 16.0 and a subnet mask of, say, 255.0? The ISC DHCP server currently preallocates memory for leases, assuming that it's better to crash on startup due to a lack of memory than to crash later. So it's going to allocate ~2^24 leases when it receives this packet. This is an instant denial of service attack. Should I go to lazy allocation of leases? Should there be a recommendation in the draft about this? A security considerations notice? What happens if there are redundant routers serving the subnet? What routers option does the DHCP server send? Does it track the IP addresses of routers from which it's received this option, and notice if two have IP addresses on the same subnet? What if it's already given one of these addresses out? What happens if two routers send conflicting information - one saying, for example, that 10.0.0.0 is a /24, while the other says it's a /16? How are dynamically-allocated subnets garbage collected? Are they? Yes, many of these points are operational concerns, but operations is part of the protocol. If the protocol specification doesn't address these issues, I can see that for many of these issues, there is the potential that one implementor will address the issue one way, and another implementor will address the issue another, and that the ways in which these issues are addressed will be sufficiently different that they will create interoperability problems. This is why I want to see a seperate draft for this option. I'd like to see these points addressed in the draft, or at least have a discussion about them before the suboption becomes a standard. _MelloN_ From owner-dhcp-v4@bucknell.edu Wed Feb 2 15:50: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 PAA21078 for ; Wed, 2 Feb 2000 15:50:31 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id PAA32453; Wed, 2 Feb 2000 15:48:44 -0500 (EST) Received: from alcor.process.com (alcor.process.com [192.42.95.16]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id PAA01270 for ; Wed, 2 Feb 2000 15:48:35 -0500 (EST) Received: by process.com (MX V5.1-X A2w8g) id 193; Wed, 2 Feb 2000 15:47:57 -0400 Sender: owner-dhcp-v4@bucknell.edu Date: Wed, 2 Feb 2000 15:47:55 -0400 From: Bernie Volz To: DHCPv4 discussion list CC: DHCP-V4@bucknell.edu Message-ID: <009E511D.55A969AD.193@process.com> Subject: Re: WG Last Call for "DHCP Relay Agent Information Option" I-D Reply-To: volz@process.com X-Sender: volz@process.com X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Ted: Thanks for sending (some) of your concerns. I'm afraid I can't refrain from at least discussing these issues some. >I will mention a few places where I see problems with this suboption, >but again, the purpose of this discussion is to pull the suboption out >into its own draft and *then* nail it down properly, *not* to nail it >down properly right now, so please do not argue the points I present >below with me right now - just take them as examples of why the subnet >mask suboption ought to be discussed further. > >First, what *else* is in the packet the router sends that interacts >with this suboption? The giaddr comes to mind. What should the >giaddr be? Should it be specified? Should the giaddr be one >greater than the subnet number for the subnet, for example? Are any >IP addresses on one of these subnets reserved? Is the .0 reserved? >Is the .all-ones reserved? What about .0+1 and .all-ones-1? What >does the server do if the router sends a subnet mask of /30, /31 or >/32? Re-read the draft. It says giaddr is required. How else could the network address be determined (giaddr is ANDed with the Agent Subnet Mask). Regarding which addresses are reserved (for broadcasts, for routers, etc), that was exactly my point as well. BUT, these are CONFIGURATION issues. Even for failover protocol, we assume both servers have the same configuration. And, that is why we added an option in the failover protocol to allow sending client options to the peer - if one server receives a client request and "creates a scope", by sending the BNDUPD to the peer, that peer would obviously need to do the same (and it is assumed that the peer would have the same configuration information). >What is the purpose of this suboption? Is it so that routers can >dynamically add subnets, or just so that routers can inform the DHCP >server as to their configuration, so that the DHCP server can confirm >that it's configured correctly? Or so that the DHCP server can >implicitly be configured by configuring the router - i.e., to push >configuration information away from the server and out to the router? Again, draft says: "Servers MAY use this mask field to automatically create scopes of assignable IP addreses. Use of this field avoids the need to have identical configuration of the logical IP subnets on which clients reside in both the relaying routers and the DHCP server. In this case, the router configuration defines the LISs (Logical IP Subnets), and the DHCP servers automatically discover the LISs from the relay agent options forwarded client DHCP requests." I would assume that there is an assumption that the server has SOME configuration information the (a) enables creation of scopes, and (b) provides rules for how to create the scopes (reserved addresses, etc). >What are the implications if there are two DHCP servers doing >failover? Both DHCP servers had better make the same assumptions, >right? Do the servers do failover on the new subnet? What if there >are two DHCP servers that *aren't* doing failover? Yes, but we're already assuming that anyway. And see above for how we've allowed for that to be communicated. >What happens if somebody sends the DHCP server a forged packet with a >giaddr of, say, 16.0 and a subnet mask of, say, 255.0? The ISC DHCP >server currently preallocates memory for leases, assuming that it's >better to crash on startup due to a lack of memory than to crash >later. So it's going to allocate ~2^24 leases when it receives this >packet. This is an instant denial of service attack. Should I go >to lazy allocation of leases? Should there be a recommendation in >the draft about this? A security considerations notice? I would again assume that configuration information would tell the server when it is allowed to create scopes and for what address ranges and subnet configurations - at least in the broad sense. As far as how you do lease allocation, etc, that is a server implementation issue. >What happens if there are redundant routers serving the subnet? What >routers option does the DHCP server send? Does it track the IP >addresses of routers from which it's received this option, and notice >if two have IP addresses on the same subnet? What if it's already >given one of these addresses out? Again, configuration issues. I'd assume if you're automatically creating subnets, you'd have details that say the first addresses are used for routers, etc. See my example "ISC-like" configuration template in my previous message. That was supposed to communicate this kind of configuration information. >What happens if two routers send conflicting information - one saying, >for example, that 10.0.0.0 is a /24, while the other says it's a /16? You've got problems. But that's no different than if I configure my DHCP server with different information from what I configure my routers. In fact, the whole idea here was to reduce configuration issues because the routers (relay agents) would know the details. >How are dynamically-allocated subnets garbage collected? Are they? Who are any addresses garbage collected? I think this would require manual intervention (such as by removing the subnet declarations that were dynamically created from the configuration file or whereever you're going to keep them between server reboots). >Yes, many of these points are operational concerns, but operations is >part of the protocol. If the protocol specification doesn't address >these issues, I can see that for many of these issues, there is the >potential that one implementor will address the issue one way, and >another implementor will address the issue another, and that the ways >in which these issues are addressed will be sufficiently different >that they will create interoperability problems. I don't see that much of the above would cause interoperability problems unless the configuration information produced different results. But, that's true of what goes on today. >This is why I want to see a seperate draft for this option. I'd like >to see these points addressed in the draft, or at least have a >discussion about them before the suboption becomes a standard. OK - we're discussing them. I don't know why noone else has chimed in one way or the other. This will be my last communication for a while on this issue as I do have other issues to address and this isn't exactly on my hot list of issues. - Bernie Volz From owner-dhcp-v4@bucknell.edu Wed Feb 2 16:08: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 QAA21452 for ; Wed, 2 Feb 2000 16:08:33 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id QAA18428; Wed, 2 Feb 2000 16:07:34 -0500 (EST) Received: from toccata.fugue.com (toccata.fugue.com [204.152.188.66]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id QAA19713 for ; Wed, 2 Feb 2000 16:07:22 -0500 (EST) Received: from grosse.manhattan.fugue.com (tundruk.manhattan.fugue.com [160.79.19.71]) by toccata.fugue.com (8.9.3/8.6.11) with ESMTP id NAA04757; Wed, 2 Feb 2000 13:01:41 -0800 (PST) Received: from grosse.manhattan.fugue.com (localhost [127.0.0.1]) by grosse.manhattan.fugue.com (8.9.3+3.2W/8.6.11) with ESMTP id QAA00611; Wed, 2 Feb 2000 16:07:17 -0500 (EST) Message-Id: <200002022107.QAA00611@grosse.manhattan.fugue.com> To: DHCPv4 discussion list cc: DHCP-V4@bucknell.edu Subject: Re: WG Last Call for "DHCP Relay Agent Information Option" I-D In-Reply-To: Message from Bernie Volz of "Wed, 02 Feb 2000 15:47:55 -0400." <009E511D.55A969AD.193@process.com> Date: Wed, 02 Feb 2000 16:07:17 -0500 From: Ted Lemon Reply-To: mellon@isc.org Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN > Re-read the draft. It says giaddr is required. How else could the > network address be determined (giaddr is ANDed with the Agent Subnet > Mask). No, you missed my point. My point is this: what *value* should giaddr have? Should what the server does depend on the value? To make it easy, consider that the router is relaying a request from following /24: 10.250.127.0. What should giaddr be? Must it be 10.250.127.1? Must it be 10.250.127.254? Can it have any value in the range [10.250.127.1,10.250.127.254]? > BUT, these are CONFIGURATION issues. Are they? Where does it say that? > Even for failover protocol, we assume both servers have the same > configuration. The failover protocol states this assertion directly, and discusses its implications. > "Servers MAY use this mask field to automatically create scopes of > assignable IP addreses. Use of this field avoids the need to have > identical configuration of the logical IP subnets on which clients > reside in both the relaying routers and the DHCP server. In this case, > the router configuration defines the LISs (Logical IP Subnets), and the > DHCP servers automatically discover the LISs from the relay agent > options forwarded client DHCP requests." What's a scope? What problem does this solve? I.e., why is it good to avoid the need to have identical configuration of the logical IP subnets on which clients reside in both the relaying routers and the DHCP server? Why is this the right way to solve the problem (e.g., as opposed to the multicast relay protocol that Eric Hall was working on)? > I would assume that there is an assumption that the server has SOME > configuration information the (a) enables creation of scopes, and > (b) provides rules for how to create the scopes (reserved addresses, > etc). You shouldn't have to assume. It should be specifically stated. > Yes, but we're already assuming that anyway. And see above for how > we've allowed for that to be communicated. Argh! There's that "assume" word again! > I would again assume that configuration information would tell the > server when it is allowed to create scopes and for what address ranges > and subnet configurations - at least in the broad sense. And again! > As far as how you do lease allocation, etc, that is a server > implementation issue. So there's no need to discuss the possibility of a DOS attack here? Why not? Drafts are supposed to have security considerations sections. This is one of the kinds of things that are discussed in such sections. > Again, configuration issues. I'd assume if you're automatically creating > subnets, you'd have details that say the first addresses are used > for routers, etc. See my example "ISC-like" configuration template in my > previous message. That was supposed to communicate this kind of > configuration information. The idea is to avoid unexpected results. It is possible, I think, to describe what the server should do in this case, or to say "the server MUST be configurable as to what addresses on a dynamically-created subnet are reserved for routers." And you didn't address the failover case, which I think is rather important. > You've got problems. But that's no different than if I configure my > DHCP server with different information from what I configure my > routers. This is true. > In fact, the whole idea here was to reduce configuration > issues because the routers (relay agents) would know the details. That's a reason to have a subnet mask suboption and check to make sure the server's idea of the subnet mask is the same as the relay agent's. It's not a reason to have the server allocate subnets on the fly. > >How are dynamically-allocated subnets garbage collected? Are they? > > Who are any addresses garbage collected? I think this would require > manual intervention (such as by removing the subnet declarations that > were dynamically created from the configuration file or whereever you're > going to keep them between server reboots). So this increases the administrative burden, because subnets can now be created by random errors, and someone has to go look for them to get rid of them in that case, right? _MelloN_ From owner-dhcp-v4@bucknell.edu Wed Feb 2 16:47: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 QAA22208 for ; Wed, 2 Feb 2000 16:47:16 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id QAA00812; Wed, 2 Feb 2000 16:45:49 -0500 (EST) Received: from sbcsmtp2.ptss.com (sbcsmtp2.ptss.com [204.107.19.24]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id QAA28456 for ; Wed, 2 Feb 2000 16:45:36 -0500 (EST) Received: from mail2.pacbell.com (mail2.pacbell.com [129.245.2.18]) by sbcsmtp2.ptss.com (8.8.8/8.8.8) with ESMTP id NAA12539 for ; Wed, 2 Feb 2000 13:44:36 -0800 (PST) Received: from msgnorth98.ffcrc.pacbell.com .(msgnorth98.ffcrc.pacbell.com [150.234.34.86]) by mail2.PacBell.COM (8.8.5/8.8.5-pb990306) with ESMTP id NAA16561 for ; Wed, 2 Feb 2000 13:45:11 -0800 (PST) Received: by msgnorth98.ffcrc.pacbell.com with Internet Mail Service (5.5.2448.0) id ; Wed, 2 Feb 2000 13:44:49 -0800 Message-ID: <11917F263658D2118AC000805FD4B706E75A37@msgsrv04.srv.PacBell.COM> From: "HIBBS, BARR (SBCSI)" To: DHCPv4 discussion list Subject: RE: WG Last Call for "DHCP Relay Agent Information Option" I-D Date: Wed, 2 Feb 2000 13:44:38 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain Reply-To: RBHIBBS@msg.pacbell.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN It's my opinion that most of the interoperability and usability problems that have arisen with DHCP are the result of wording in the RFC's that permit implementors to assume the intent of the authors/editors. This is not to say that there aren't great areas where the appropriate wording is "this is an implementation or local administrative matter," but rather to suggest that the converse simply isn't appropriate. That is, omitting some clarification when an RFC says MAY or SHOULD or MAY NOT or SHOULD NOT can certainly lead to trouble. An example (that we've beaten nearly to death already, so please don't start a new thread about it!) is the behavior of a server when a client changes subnets: is the server to replace (that is, expire) the existing lease or retain it as valid until the lease lifetime expires? I think most of us would agree that some clarification is appropriate, even if that clarification is "a matter for local administration." By explicitly including a statement, an implementor, network architect, or server administrator should be alerted to a possible area where different servers might behave in diverging manners. Okay.... I really have a problem with the assertion that address pools can be created dynamically, apparently by garbled packets. This seems to flow directly from the assumptions about server behavior, thus, that is a candidate for an explicit statement of implied behavior, so some revision of the text is appropriate. If we can't quickly resolve this, then Ted's suggestion to extract it from this draft and create a new one may be the best approach to avoid delaying the rest of the draft during Last Call. --Barr From owner-dhcp-v4@bucknell.edu Wed Feb 2 18:01: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 SAA23298 for ; Wed, 2 Feb 2000 18:01:09 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id RAA10906; Wed, 2 Feb 2000 17:59:43 -0500 (EST) Received: from mail-out2.apple.com (mail-out2.apple.com [17.254.0.51]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id RAA28114 for ; Wed, 2 Feb 2000 17:59:31 -0500 (EST) Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out2.apple.com (8.9.3/8.9.3) with ESMTP id OAA03683 for ; Wed, 2 Feb 2000 14:59:23 -0800 (PST) Received: from scv1.apple.com (scv1.apple.com) by mailgate1.apple.com (mailgate1.apple.com- SMTPRS 2.0.15) with ESMTP id for ; Wed, 02 Feb 2000 14:59:02 -0800 Received: from [17.201.23.37] (chesh1.apple.com [17.201.23.37]) by scv1.apple.com (8.9.3/8.9.3) with SMTP id OAA27665 for ; Wed, 2 Feb 2000 14:59:01 -0800 (PST) Message-Id: <200002022259.OAA27665@scv1.apple.com> Subject: Re: draft-ietf-dhc-csr-00.txt Date: Wed, 2 Feb 2000 14:59:02 -0800 x-sender: cheshire@mail.apple.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Stuart Cheshire To: DHCPv4 discussion list MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Reply-To: cheshire@apple.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN >> 6. Should there be something said about a destination that has HOST bits >> set when applying the subnet mask? Should a DHCP client IGNORE that >> entry or treat the packet in error or should it install the "cleaned" >> route (by clearing the host bits). > >Again, I think the best thing to do here would be to say that the >server administrator SHOULD NOT do this, and leave the behaviour >resulting from a violation of this SHOULD NOT unspecified. I would like wording that says clients MUST silently ignore any static routes that are offered with non-zero bits in the host part. If you leave the behaviour unspecified, and then we find later that static routes with non-zero host bits produce some particular kind of weird behaviour on Windows machines, and weird network administrators start relying on that weird behaviour, then the Mac OS DHCP client gets slammed in the press for not being "compatible" with the "industry standard". Since I plan to implement this option, and since I plan to silently ignore any static routes with non-zero host bits, it would make my life easier if the document stated explicitly that this is the right thing to do (or if not, tell me what I should do with them). Stuart Cheshire * Web Page * Wizard Without Portfolio, Apple Computer From owner-dhcp-v4@bucknell.edu Wed Feb 2 19: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 TAA23850 for ; Wed, 2 Feb 2000 19:03:23 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id SAA29437; Wed, 2 Feb 2000 18:21:37 -0500 (EST) Received: from toccata.fugue.com (toccata.fugue.com [204.152.188.66]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id SAA08976 for ; Wed, 2 Feb 2000 18:21:24 -0500 (EST) Received: from grosse.manhattan.fugue.com (tundruk.manhattan.fugue.com [160.79.19.71]) by toccata.fugue.com (8.9.3/8.6.11) with ESMTP id PAA05438; Wed, 2 Feb 2000 15:15:44 -0800 (PST) Received: from grosse.manhattan.fugue.com (localhost [127.0.0.1]) by grosse.manhattan.fugue.com (8.9.3+3.2W/8.6.11) with ESMTP id SAA01209; Wed, 2 Feb 2000 18:21:19 -0500 (EST) Message-Id: <200002022321.SAA01209@grosse.manhattan.fugue.com> To: DHCPv4 discussion list cc: DHCPv4 discussion list Subject: Re: draft-ietf-dhc-csr-00.txt In-Reply-To: Message from Stuart Cheshire of "Wed, 02 Feb 2000 14:59:02 PST." <200002022259.OAA27665@scv1.apple.com> Date: Wed, 02 Feb 2000 18:21:19 -0500 From: Ted Lemon Reply-To: mellon@isc.org Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN > If you leave the behaviour unspecified, and then we find later that > static routes with non-zero host bits produce some particular kind of > weird behaviour on Windows machines, and weird network administrators > start relying on that weird behaviour, then the Mac OS DHCP client gets > slammed in the press for not being "compatible" with the "industry > standard". It seems unlikely, but not so unlikely that I can't relate. :') I've added a note about this - see below. _MelloN_ *** draft-ietf-dhc-csr-00.txt~ Tue Feb 1 13:04:49 2000 --- draft-ietf-dhc-csr-00.txt Wed Feb 2 18:19:13 2000 *************** *** 143,148 **** --- 143,155 ---- option SHOULD use this option in preference to the Static routes option if both are present in a reply from the DHCP server. + The DHCP client SHOULD check each route to determine if are any + bits in the destination network number whose value is one whose + corresponding value in the subnet mask is zero, and SHOULD NOT + install any routes for which this is the case. For example, the + client should not install a route with a destination of + 129.210.377.4 and a subnet mask of 255.255.255.0. + DHCP Server administrator responsibilities The client's behaviour if both a Routers option and a Classless From owner-dhcp-v4@bucknell.edu Wed Feb 2 19:09: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 TAA23929 for ; Wed, 2 Feb 2000 19:08:58 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id SAA26914; Wed, 2 Feb 2000 18:16:04 -0500 (EST) Received: from sbcsmtp2.ptss.com (sbcsmtp2.ptss.com [204.107.19.24]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id SAA24892 for ; Wed, 2 Feb 2000 18:15:54 -0500 (EST) Received: from mail2.pacbell.com (mail2.pacbell.com [129.245.2.18]) by sbcsmtp2.ptss.com (8.8.8/8.8.8) with ESMTP id PAA29077 for ; Wed, 2 Feb 2000 15:15:07 -0800 (PST) Received: from msgnorth98.ffcrc.pacbell.com .(msgnorth98.ffcrc.pacbell.com [150.234.34.86]) by mail2.PacBell.COM (8.8.5/8.8.5-pb990306) with ESMTP id PAA01742 for ; Wed, 2 Feb 2000 15:15:43 -0800 (PST) Received: by msgnorth98.ffcrc.pacbell.com with Internet Mail Service (5.5.2448.0) id ; Wed, 2 Feb 2000 15:15:21 -0800 Message-ID: <11917F263658D2118AC000805FD4B706E75A39@msgsrv04.srv.PacBell.COM> From: "HIBBS, BARR (SBCSI)" To: DHCPv4 discussion list Subject: FW: WG Last Call for "DHCP Relay Agent Information Option" I-D Date: Wed, 2 Feb 2000 15:15:20 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain Reply-To: RBHIBBS@msg.pacbell.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN > It's my opinion that most of the interoperability and usability problems > that have arisen with DHCP are the result of wording in the RFC's that > permit implementors to assume the intent of the authors/editors. This is > not to say that there aren't great areas where the appropriate wording is > "this is an implementation or local administrative matter," but rather to > suggest that the converse simply isn't appropriate. That is, omitting > some clarification when an RFC says MAY or SHOULD or MAY NOT or SHOULD NOT > can certainly lead to trouble. > > An example (that we've beaten nearly to death already, so please don't > start a new thread about it!) is the behavior of a server when a client > changes subnets: is the server to replace (that is, expire) the existing > lease or retain it as valid until the lease lifetime expires? > > I think most of us would agree that some clarification is appropriate, > even if that clarification is "a matter for local administration." By > explicitly including a statement, an implementor, network architect, or > server administrator should be alerted to a possible area where different > servers might behave in diverging manners. > > Okay.... I really have a problem with the assertion that address pools > can be created dynamically, apparently by garbled packets. This seems to > flow directly from the assumptions about server behavior, thus, that is a > candidate for an explicit statement of implied behavior, so some revision > of the text is appropriate. > > If we can't quickly resolve this, then Ted's suggestion to extract it from > this draft and create a new one may be the best approach to avoid delaying > the rest of the draft during Last Call. > > --Barr > > From owner-dhcp-v4@bucknell.edu Wed Feb 2 20:04: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 UAA24386 for ; Wed, 2 Feb 2000 20:04:27 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id UAA08921; Wed, 2 Feb 2000 20:03:02 -0500 (EST) Received: from alcor.process.com (alcor.process.com [192.42.95.16]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id UAA27656 for ; Wed, 2 Feb 2000 20:02:57 -0500 (EST) Received: by process.com (MX V5.1-X A2w8g) id 14; Wed, 2 Feb 2000 20:00:15 -0500 Sender: owner-dhcp-v4@bucknell.edu Date: Wed, 2 Feb 2000 20:00:14 -0500 From: Bernie Volz To: DHCPv4 discussion list CC: DHCP-V4@bucknell.edu Message-ID: <009E5140.9584BC5D.14@process.com> Subject: Re: draft-ietf-dhc-csr-00.txt Reply-To: volz@process.com X-Sender: volz@process.com X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Stuart: I fully agree with you. We MUST spell out the expected behavoir. I have no problem in these routes being ignored if that is the stated behavoir. I assume you mean that the individual route is ignored, not the entire list of routes in the option? We should be clear about this as well. Isn't Ralph collecting ideas for revising 2131/2132? This should be added to the list. - Bernie Volz ---- >>> 6. Should there be something said about a destination that has HOST bits >>> set when applying the subnet mask? Should a DHCP client IGNORE that >>> entry or treat the packet in error or should it install the "cleaned" >>> route (by clearing the host bits). >> >>Again, I think the best thing to do here would be to say that the >>server administrator SHOULD NOT do this, and leave the behaviour >>resulting from a violation of this SHOULD NOT unspecified. > >I would like wording that says clients MUST silently ignore any static >routes that are offered with non-zero bits in the host part. > >If you leave the behaviour unspecified, and then we find later that >static routes with non-zero host bits produce some particular kind of >weird behaviour on Windows machines, and weird network administrators >start relying on that weird behaviour, then the Mac OS DHCP client gets >slammed in the press for not being "compatible" with the "industry >standard". > >Since I plan to implement this option, and since I plan to silently >ignore any static routes with non-zero host bits, it would make my life >easier if the document stated explicitly that this is the right thing to >do (or if not, tell me what I should do with them). > >Stuart Cheshire From owner-dhcp-v4@bucknell.edu Wed Feb 2 20:10: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 UAA24428 for ; Wed, 2 Feb 2000 20:10:13 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id UAA06196; Wed, 2 Feb 2000 20:09:09 -0500 (EST) Received: from alcor.process.com (alcor.process.com [192.42.95.16]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id UAA24649 for ; Wed, 2 Feb 2000 20:08:59 -0500 (EST) Received: by process.com (MX V5.1-X A2w8g) id 70; Wed, 2 Feb 2000 20:08:27 -0500 Sender: owner-dhcp-v4@bucknell.edu Date: Wed, 2 Feb 2000 20:08:25 -0500 From: Bernie Volz To: DHCPv4 discussion list Message-ID: <009E5141.B9F9CF0F.70@process.com> Subject: Re: WG Last Call for "DHCP Relay Agent Information Option" I-D Reply-To: volz@process.com X-Sender: volz@process.com X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Ted and I have been discussing issues regarding this draft. I believe I understand Ted's objections though I don't feel they are as severe as he does. I do agree with Ted that the best course of action, in the interest of time and progress, that the draft be revised to remove the subnet mask suboption until it can be further refined and reviewed. Some description at least of the issues and potential security and other risks is warranted. And, someone else finally chimed in (thanks Barr), and feels that this is also the prudent course of action. From owner-dhcp-v4@bucknell.edu Wed Feb 2 23:23: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 XAA28060 for ; Wed, 2 Feb 2000 23:23:59 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id XAA06395; Wed, 2 Feb 2000 23:22:56 -0500 (EST) Received: from mail-out2.apple.com (mail-out2.apple.com [17.254.0.51]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id XAA11949 for ; Wed, 2 Feb 2000 23:22:51 -0500 (EST) Received: from mailgate2.apple.com ([17.129.100.225]) by mail-out2.apple.com (8.9.3/8.9.3) with ESMTP id UAA23287 for ; Wed, 2 Feb 2000 20:22:50 -0800 (PST) Received: from scv3.apple.com (scv3.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 2.0.15) with ESMTP id for ; Wed, 02 Feb 2000 20:22:39 -0800 Received: from [17.201.23.37] (chesh1.apple.com [17.201.23.37]) by scv3.apple.com (8.9.3/8.9.3) with SMTP id UAA17331 for ; Wed, 2 Feb 2000 20:22:35 -0800 (PST) Message-Id: <200002030422.UAA17331@scv3.apple.com> Subject: Re: draft-ietf-dhc-csr-00.txt Date: Wed, 2 Feb 2000 20:22:35 -0800 x-sender: cheshire@mail.apple.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Stuart Cheshire Cc: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Reply-To: cheshire@apple.com Sender: owner-dhcp-v4@bucknell.edu To: DHCPv4 discussion list X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN >I fully agree with you. We MUST spell out the expected behavoir. I have >no problem in these routes being ignored if that is the stated behavoir. >I assume you mean that the individual route is ignored, not the entire >list of routes in the option? We should be clear about this as well. Yes. Just the defective route entry itself, not other valid route entries in the packet (which may be contained in the same csr option, or in a separate csr option if the packet contains more than one instance of the csr option). Stuart Cheshire * Web Page * Wizard Without Portfolio, Apple Computer From owner-dhcp-v4@bucknell.edu Thu Feb 3 00:07: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 AAA28929 for ; Thu, 3 Feb 2000 00:07:30 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id AAA15304; Thu, 3 Feb 2000 00:06:35 -0500 (EST) Received: from toccata.fugue.com (toccata.fugue.com [204.152.188.66]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id AAA11521 for ; Thu, 3 Feb 2000 00:06:32 -0500 (EST) Received: from grosse.manhattan.fugue.com (tundruk.manhattan.fugue.com [160.79.19.71]) by toccata.fugue.com (8.9.3/8.6.11) with ESMTP id VAA06662; Wed, 2 Feb 2000 21:00:54 -0800 (PST) Received: from grosse.manhattan.fugue.com (localhost [127.0.0.1]) by grosse.manhattan.fugue.com (8.9.3+3.2W/8.6.11) with ESMTP id AAA02344; Thu, 3 Feb 2000 00:06:29 -0500 (EST) Message-Id: <200002030506.AAA02344@grosse.manhattan.fugue.com> To: DHCPv4 discussion list cc: DHCPv4 discussion list Subject: Re: draft-ietf-dhc-csr-00.txt In-Reply-To: Message from Stuart Cheshire of "Wed, 02 Feb 2000 20:22:35 PST." <200002030422.UAA17331@scv3.apple.com> Date: Thu, 03 Feb 2000 00:06:29 -0500 From: Ted Lemon Reply-To: mellon@isc.org Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN > >I fully agree with you. We MUST spell out the expected behavoir. I have > >no problem in these routes being ignored if that is the stated behavoir. > >I assume you mean that the individual route is ignored, not the entire > >list of routes in the option? We should be clear about this as well. > > Yes. Just the defective route entry itself, not other valid route entries > in the packet (which may be contained in the same csr option, or in a > separate csr option if the packet contains more than one instance of the > csr option). Do youse (New York second person plural) feel that the change I made is sufficiently explicit about this, or should I make it more explicit? _MelloN_ From owner-dhcp-v4@bucknell.edu Thu Feb 3 09:37: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 JAA19136 for ; Thu, 3 Feb 2000 09:37:40 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id JAA30530; Thu, 3 Feb 2000 09:37:10 -0500 (EST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id JAA26835 for ; Thu, 3 Feb 2000 09:36:34 -0500 (EST) Received: from kkinnear-nt (ch2-dhcp133-167.cisco.com [161.44.133.167]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id JAA27119; Thu, 3 Feb 2000 09:36:03 -0500 (EST) Message-Id: <4.2.0.58.20000203092957.017ee850@funnel.cisco.com> X-Sender: kkinnear@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Thu, 03 Feb 2000 09:37:10 -0500 To: DHCPv4 discussion list From: Kim Kinnear Subject: Re: WG Last Call for "DHCP Relay Agent Information Option" I-D Cc: kkinnear@cisco.com In-Reply-To: <009E5141.B9F9CF0F.70@process.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Reply-To: kkinnear@cisco.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN I was away from the office yesterday (working on a different draft, as it happens), and so was unable to jump in on this issue until today. Having now reviewed the recent discussions on the list, I agree rather completely with Bernie's statement below. I understand Ted's objections (I think), though I don't feel they are nearly as severe as he does. That said, in the interests of moving forward the basic relay agent information draft, I don't think we have any alternative but to remove the subnet mask suboption into a separate draft/RFC. Let's get at least the basic relay agent information option finished! Cheers -- Kim At 08:08 PM 2/2/00 -0500, Bernie Volz wrote: >Ted and I have been discussing issues regarding this draft. I believe I >understand Ted's objections though I don't feel they are as severe as he >does. > >I do agree with Ted that the best course of action, in the interest of >time and progress, that the draft be revised to remove the subnet mask >suboption until it can be further refined and reviewed. Some description >at least of the issues and potential security and other risks is >warranted. > >And, someone else finally chimed in (thanks Barr), and feels that this >is also the prudent course of action. > From owner-dhcp-v4@bucknell.edu Fri Feb 4 07:58: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 HAA24501 for ; Fri, 4 Feb 2000 07:58:27 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id HAA20782; Fri, 4 Feb 2000 07:56:36 -0500 (EST) Received: from leo.eg.bucknell.edu (dns.dhcp.org [134.82.56.120]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id HAA00560 for ; Fri, 4 Feb 2000 07:56:20 -0500 (EST) Received: from droms-laptop (host22.bvtc.ptd.net [209.173.2.22]) by leo.eg.bucknell.edu (8.8.8+Sun/8.8.8) with ESMTP id HAA03207 for ; Fri, 4 Feb 2000 07:56:18 -0500 (EST) Message-Id: <4.2.2.20000204075551.00a352e0@mail.bucknell.edu> X-Sender: droms@mail.bucknell.edu X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Fri, 04 Feb 2000 07:56:00 -0500 To: DHCPv4 discussion list From: Ralph Droms Subject: I-D ACTION:draft-ietf-dhc-nextserver-01.txt 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 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Title : DHCP Next Server Option Author(s) : J. Privat, M. Borella Filename : draft-ietf-dhc-nextserver-01.txt Pages : 6 Date : 03-Feb-00 This proposal allows host configuration to be split between two different address servers, potentially under different administration. This ability may be useful to satisfy specific regulatory, operational or business model requirements, as well as to provide support for secondary address servers. This draft proposes a new DHCP option called the DHCP Next Server option. A DHCP server can use this option to redirect clients to a secondary server. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-nextserver-01.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-nextserver-01.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-nextserver-01.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: <20000203131115.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-nextserver-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-nextserver-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000203131115.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-dhcp-v4@bucknell.edu Fri Feb 4 08:48: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 IAA26362 for ; Fri, 4 Feb 2000 08:48:20 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id IAA18368; Fri, 4 Feb 2000 08:46:40 -0500 (EST) Received: from marvin.axion.bt.co.uk (marvin.axion.bt.co.uk [132.146.16.82]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id IAA27810 for ; Fri, 4 Feb 2000 08:46:26 -0500 (EST) From: jerome.privat@bt.com Received: from cbtlipnt01.btlabs.bt.co.uk by marvin (local) with ESMTP; Fri, 4 Feb 2000 13:26:39 +0000 Received: by cbtlipnt01.btlabs.bt.co.uk with Internet Mail Service (5.5.2448.0) id <128YBSD2>; Fri, 4 Feb 2000 13:27:26 -0000 Message-ID: <5104D4DBC598D211B5FE0000F8FE7EB20408733C@mbtlipnt02.btlabs.bt.co.uk> To: DHCPv4 discussion list Subject: RE: I-D ACTION:draft-ietf-dhc-nextserver-01.txt Date: Fri, 4 Feb 2000 13:27:21 -0000 X-Mailer: Internet Mail Service (5.5.2448.0) MIME-version: 1.0 Content-type: text/plain; charset="windows-1252" 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 This new version of the draft takes into account comments sent to the list by Mike Henry: - it extends the option to carry a list of addresses for secondary servers (for robustness); - it enables new secondary server types to be defined later through registration with IANA. Jerome Privat BT -----Original Message----- From: Ralph Droms [mailto:droms@bucknell.edu] Sent: 04 February 2000 12:56 To: DHCPv4 discussion list Subject: I-D ACTION:draft-ietf-dhc-nextserver-01.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 : DHCP Next Server Option Author(s) : J. Privat, M. Borella Filename : draft-ietf-dhc-nextserver-01.txt Pages : 6 Date : 03-Feb-00 This proposal allows host configuration to be split between two different address servers, potentially under different administration. This ability may be useful to satisfy specific regulatory, operational or business model requirements, as well as to provide support for secondary address servers. This draft proposes a new DHCP option called the DHCP Next Server option. A DHCP server can use this option to redirect clients to a secondary server. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-nextserver-01.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-nextserver-01.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-nextserver-01.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: <20000203131115.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-nextserver-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-nextserver-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000203131115.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-dhcp-v4@bucknell.edu Fri Feb 4 18:24: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 SAA12636 for ; Fri, 4 Feb 2000 18:24:40 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id SAA22405; Fri, 4 Feb 2000 18:23:29 -0500 (EST) Received: from leo.eg.bucknell.edu (leo.eg.bucknell.edu [134.82.56.108]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id SAA30538 for ; Fri, 4 Feb 2000 18:22:55 -0500 (EST) Received: from droms-laptop (host22.bvtc.ptd.net [209.173.2.22]) by leo.eg.bucknell.edu (8.8.8+Sun/8.8.8) with ESMTP id SAA06691 for ; Fri, 4 Feb 2000 18:22:54 -0500 (EST) Message-Id: <4.2.2.20000204181854.00a4f780@mail.bucknell.edu> X-Sender: droms@mail.bucknell.edu X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Fri, 04 Feb 2000 18:19:55 -0500 To: DHCPv4 discussion list From: Ralph Droms Subject: Re: WG last call: DHCP for IEEE 1394 (Reminder!!!) In-Reply-To: <4.2.2.20000201073140.00a4c1c0@mail.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 Having received no comments during the DHC WG last call for draft-ietf-ip1394-dhcp-02.txt, I've recommended to the IP1394 WG that the document be submitted for standards track acceptance. - Ralph At 07:32 AM 2/1/00 -0500, Ralph Droms wrote: >(Please note that this last call will end Wednesday, 2/2 [tomorrow]... - RD) > >This is the DHC WG last call for the following document: > > http://www.ietf.org/internet-drafts/draft-ietf-ip1394-dhcp-02.txt > >This DHC WG last call will end 2/2. Please provide comments to the >author, Kenji Fujisawa, and to this mailing list. > >This latest version of the document includes the authors response to >comments from the DHC WG after the 7/99 WG meeting in Oslo. > >The document has passed the IEEE 1394 WG last call. Once the >DHC WG last call completes, this document will be submitted to IESG for >approval to become a Standards Track RFC and be accepted as an official >DHCP Option. > >- Ralph Droms > From owner-dhcp-v4@bucknell.edu Sun Feb 6 17:03: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 RAA13037 for ; Sun, 6 Feb 2000 17:03:45 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id RAA25968; Sun, 6 Feb 2000 17:01:59 -0500 (EST) Received: from monitor.internaut.com (mg-206253202-37.ricochet.net [206.253.202.37]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id RAA04087 for ; Sun, 6 Feb 2000 17:01:06 -0500 (EST) Received: from vaiobean ([204.57.137.66]) by monitor.internaut.com (8.9.2/8.8.8) with SMTP id NAA14817 for ; Sun, 6 Feb 2000 13:53:31 -0800 (PST) Reply-To: From: "Bernard Aboba" To: DHCPv4 discussion list Subject: draft-ietf-dhc-csr-00.txt and compactness Date: Sun, 6 Feb 2000 13:59:48 -0800 Message-ID: <027e01bf70ed$7e62afa0$2d8939cc@ntdev.microsoft.com> 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 CWS, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <200002022259.OAA27665@scv1.apple.com> X-Mimeole: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit I have some comments on the use of DHCP to set client static routes and the need for compactness. In general, the ability to set client static routes is useful functionality. While in most cases the number of client static routes to be set is small, in a significant number of cases the number of routes is large. For example, in my customer visits I have encountered quite a few customers with the need to set dozens of routes. In a several cases, we are talking about well over a hundred routes. While it can probably be argued that such networks have a need for renumbering and improved aggregation, I would observe that the customers in question do not appear in a hurry to renumber, for whatever reason. >From this, I conclude two things: 1. A case can be made that the csr representation should be compact, so as to allow as many routes as possible to be included in a single DHCP packet. For example, including the prefix and number of routes with that prefix, and then the routes themselves (abbreviated so as to only take up the required no. of octets) is a relatively compact representation. For example, to send 3 /24 csrs, one could send the following 24 3 204.57.137 205.47.24 206.12.13 Or a total of 11 octets. To send a 4 /16 csrs, one would send: 16 4 204.57 205.47 206.12 Or a total of 8 octets. 2. There are cases where, no matter how hard we try, we will not be able to fit the required no. of csrs within a single DHCP packet. >From this I conclude that DHCP by itself may not be sufficient in all circumstances. I would note that RSIP (whose control channels runs over TCP) is also supporting csr configuration functionality. Question: Should we be thinking about how to handle the large csr case? Is the answer another protocol, another DHCP option or some combination of both? From owner-dhcp-v4@bucknell.edu Mon Feb 7 00:30: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 AAA17680 for ; Mon, 7 Feb 2000 00:30:28 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id AAA18125; Mon, 7 Feb 2000 00:30:02 -0500 (EST) Received: from toccata.fugue.com (toccata.fugue.com [204.152.188.66]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id AAA14411 for ; Mon, 7 Feb 2000 00:29:45 -0500 (EST) Received: from grosse.manhattan.fugue.com (tundruk.manhattan.fugue.com [160.79.19.71]) by toccata.fugue.com (8.9.3/8.6.11) with ESMTP id VAA11751; Sun, 6 Feb 2000 21:23:57 -0800 (PST) Received: from grosse.manhattan.fugue.com (localhost [127.0.0.1]) by grosse.manhattan.fugue.com (8.9.3+3.2W/8.6.11) with ESMTP id AAA26560; Mon, 7 Feb 2000 00:29:36 -0500 (EST) Message-Id: <200002070529.AAA26560@grosse.manhattan.fugue.com> To: DHCPv4 discussion list cc: DHCPv4 discussion list Subject: Re: draft-ietf-dhc-csr-00.txt and compactness In-Reply-To: Message from "Bernard Aboba" of "Sun, 06 Feb 2000 13:59:48 PST." <027e01bf70ed$7e62afa0$2d8939cc@ntdev.microsoft.com> Date: Mon, 07 Feb 2000 00:29:36 -0500 From: Ted Lemon Reply-To: mellon@isc.org Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Wow. I can see the reasoning behind trying to compress the option, but in a really pathological case you'd still run across the size limit, so I'm not sure how valuable this is. I'd rather not implement that impression scheme, but if you really think it's important I guess I can't argue that it's not. _MelloN_ From owner-dhcp-v4@bucknell.edu Mon Feb 7 00:36: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 AAA17776 for ; Mon, 7 Feb 2000 00:36:16 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id AAA09598; Mon, 7 Feb 2000 00:35:56 -0500 (EST) Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id AAA07858 for ; Mon, 7 Feb 2000 00:35:36 -0500 (EST) Received: from cs.columbia.edu (deccanqueen.cs.columbia.edu [128.59.19.199]) by cs.columbia.edu (8.9.1/8.9.1) with ESMTP id AAA03979; Mon, 7 Feb 2000 00:35:35 -0500 (EST) Message-ID: <389E59C0.AB756E85@cs.columbia.edu> Date: Mon, 07 Feb 2000 00:36:00 -0500 From: Gautam Nair Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.7 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: DHCPv4 discussion list Subject: [Fwd: DHCP options for locating outbound SIP servers] Content-Type: multipart/mixed; boundary="------------FB945CB75D6E253FC8FE3212" Reply-To: gnair@cs.columbia.edu Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN This is a multi-part message in MIME format. --------------FB945CB75D6E253FC8FE3212 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit --------------FB945CB75D6E253FC8FE3212 Content-Type: message/rfc822 Content-Disposition: inline Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by opus.cs.columbia.edu (8.9.1/8.9.1) with ESMTP id LAA22915; Fri, 4 Feb 2000 11:19:59 -0500 (EST) Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by cs.columbia.edu (8.9.1/8.9.1) with ESMTP id LAA04782; Fri, 4 Feb 2000 11:19:58 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id EF41F52B6; Fri, 4 Feb 2000 11:18:03 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 6DE4652C4; Fri, 4 Feb 2000 11:18:02 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from bronx.dnrc.bell-labs.com (bronx [135.180.160.8]) by lists.research.bell-labs.com (Postfix) with ESMTP id D9F0352B6 for ; Fri, 4 Feb 2000 11:17:46 -0500 (EST) Received: from cs.columbia.edu (ume [135.180.240.103]) by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id LAA18959; Fri, 4 Feb 2000 11:17:45 -0500 (EST) Message-ID: <389AFBA9.FE312DEE@cs.columbia.edu> Date: Fri, 04 Feb 2000 11:17:45 -0500 From: Henning Schulzrinne X-Mailer: Mozilla 4.05 [en] (WinNT; U) MIME-Version: 1.0 To: sip@lists.research.bell-labs.com Cc: dhcp-v4@bucknell.edu Subject: DHCP options for locating outbound SIP servers Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Type: text/plain; charset=us-ascii X-Mozilla-Status2: 00000000 Content-Transfer-Encoding: 7bit Gautam Nair and I have submitted an Internet draft for using DHCP to configure SIP clients with the address of outbound SIP servers. Until the draft appears in the I-D directories, it can also be found at http://www.cs.columbia.edu/sip/drafts/draft-nair-sip-dhcp-00.txt (For the DHCP experts: SIP, the Session Initiation Protocol, is used for setting up, modifying and terminating multimedia sessions, including Internet telephone calls. It is an IETF Proposed Standard document in RFC 2543, with information available at http://www.cs.columbia.edu/sip) We have documented a number of approaches in the draft, some of which may well be dropped if deemed to be redundant. A particular concern of ours are low-complexity embedded systems (such as http://www.cs.columbia.edu/~hgs/ephone) that may not support DNS and do not have the computational resources to host an SLP implementation. (Indeed, the outbound SIP server may well handle DNS resolution for the client.) Since SIP domains can be rather large (a whole ISP), we considered it important to provide a load balancing mechanism. Since this operates in a telephony context, reliability is very important, leading us to include the notion of backup servers and the ability to operate even when local DNS service is interrupted. There may well be better mechanisms to address either of these concerns. Feedback and comments are appreciated. Henning --------------FB945CB75D6E253FC8FE3212-- From owner-dhcp-v4@bucknell.edu Mon Feb 7 06:37: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 GAA02154 for ; Mon, 7 Feb 2000 06:37:00 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id GAA09862; Mon, 7 Feb 2000 06:36:28 -0500 (EST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id GAA23151 for ; Mon, 7 Feb 2000 06:36:08 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02046; Mon, 7 Feb 2000 06:36:02 -0500 (EST) Message-Id: <200002071136.GAA02046@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-05.txt Date: Mon, 07 Feb 2000 06:36:02 -0500 Sender: owner-dhcp-v4@bucknell.edu X-Sender: nsyracus@cnri.reston.va.us X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Title : The 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-05.txt Pages : 5 Date : 04-Feb-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 NVT ASCII text object 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-05.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-05.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-05.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: <20000204120800.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-userclass-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-userclass-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000204120800.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-dhcp-v4@bucknell.edu Mon Feb 7 09:52: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 JAA11383 for ; Mon, 7 Feb 2000 09:52:17 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id JAA00120; Mon, 7 Feb 2000 09:51:31 -0500 (EST) Received: from alcor.process.com (alcor.process.com [192.42.95.16]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id JAA17134 for ; Mon, 7 Feb 2000 09:51:10 -0500 (EST) Received: by process.com (MX V5.1-X A2w8g) id 53; Mon, 7 Feb 2000 09:50:36 -0500 Sender: owner-dhcp-v4@bucknell.edu Date: Mon, 7 Feb 2000 09:50:36 -0500 From: Bernie Volz To: DHCPv4 discussion list Message-ID: <009E54D9.3F2B2382.53@process.com> Subject: Re: draft-ietf-dhc-csr-00.txt and compactness Reply-To: volz@process.com X-Sender: volz@process.com X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Well, let me again suggest that one way to save 3 bytes per entry is to use a mask length instead of a bit mask. I still believe that this would be smart to do - I can't see much use for non-contiguous bit masks as I think most software assumes this. - Bernie Date: Mon, 07 Feb 2000 00:29:36 -0500 From: Ted Lemon Wow. I can see the reasoning behind trying to compress the option, but in a really pathological case you'd still run across the size limit, so I'm not sure how valuable this is. I'd rather not implement that impression scheme, but if you really think it's important I guess I can't argue that it's not. _MelloN_ From owner-dhcp-v4@bucknell.edu Mon Feb 7 11:17: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 LAA13894 for ; Mon, 7 Feb 2000 11:17:42 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id LAA05759; Mon, 7 Feb 2000 11:16:59 -0500 (EST) Received: from marvin.axion.bt.co.uk (marvin.axion.bt.co.uk [132.146.16.82]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id LAA09424 for ; Mon, 7 Feb 2000 11:16:38 -0500 (EST) From: jerome.privat@bt.com Received: from cbtlipnt01.btlabs.bt.co.uk by marvin (local) with ESMTP; Mon, 7 Feb 2000 14:36:21 +0000 Received: by cbtlipnt01.btlabs.bt.co.uk with Internet Mail Service (5.5.2448.0) id <1PDGS6NS>; Mon, 7 Feb 2000 14:36:47 -0000 Message-ID: <5104D4DBC598D211B5FE0000F8FE7EB204087341@mbtlipnt02.btlabs.bt.co.uk> To: DHCPv4 discussion list Subject: Re: I-D ACTION:draft-ietf-dhc-userclass-05.txt Date: Mon, 7 Feb 2000 14:36:45 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01BF7178.C2E5E044" 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_01BF7178.C2E5E044 Content-type: text/plain; charset="iso-8859-1" This draft contains modifications to the User Class option discussed at the DC meeting. I have simplified the draft, mainly defining the format of the option as agreed at the meeting. Main changes are: - modify format of the option (opaque field). - add multiple User Class support. - make clear that this option should be configurable by a user. - suppress most of the sections on server and client behavior as they were describing implementation or admin policy choices. I would appreciate any feedback on this new version of the draft. Please also note that the abstract in the annoucement below is incorrect (it mixes the abstract of the present draft with the one in the -04 version). Jerome -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Sent: 07 February 2000 11:36 To: IETF-Announce Cc: dhcp-v4@bucknell.edu Subject: I-D ACTION:draft-ietf-dhc-userclass-05.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-05.txt Pages : 5 Date : 04-Feb-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 NVT ASCII text object 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-05.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-05.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-05.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_01BF7178.C2E5E044 Content-type: message/rfc822 To: Subject: Date: Mon, 7 Feb 2000 14:36:47 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/mixed; boundary="----_=_NextPart_002_01BF7178.C2E5E044" ------_=_NextPart_002_01BF7178.C2E5E044 Content-type: text/plain; charset="us-ascii" ------_=_NextPart_002_01BF7178.C2E5E044 Content-type: application/octet-stream; name="ATT35811" Content-Disposition: attachment; filename="ATT35811" Content-type: message/external-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000204120800.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-userclass-05.txt ------_=_NextPart_002_01BF7178.C2E5E044 Content-type: message/external-body; site="internet-drafts"; dir="draft-ietf-dhc-userclass-05.txt"; mode="ftp.ietf.org"; access-type="anon-ftp" ------_=_NextPart_002_01BF7178.C2E5E044-- ------_=_NextPart_000_01BF7178.C2E5E044-- From owner-dhcp-v4@bucknell.edu Mon Feb 7 12: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 MAA15342 for ; Mon, 7 Feb 2000 12:01:48 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id MAA21307; Mon, 7 Feb 2000 12:01:14 -0500 (EST) Received: from alcor.process.com (alcor.process.com [192.42.95.16]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id MAA28840 for ; Mon, 7 Feb 2000 12:00:11 -0500 (EST) Received: by process.com (MX V5.1-X A2w8g) id 187; Mon, 7 Feb 2000 11:59:34 -0500 Sender: owner-dhcp-v4@bucknell.edu Date: Mon, 7 Feb 2000 11:59:33 -0500 From: Bernie Volz To: DHCPv4 discussion list Message-ID: <009E54EB.4316E456.187@process.com> Subject: RE: draft-nair-sip-dhcp-00.txt Reply-To: volz@process.com X-Sender: volz@process.com X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN I've only taken a brief look at this, but have a question: Is the intent of the suboption 3 (IP address sub-option) that a client randomly picks one address and if that server doesn't respond, it goes to the backup server (suboption 4)? Why not have it try all of the servers in suboption 3 (round-robin fashion, starting with a randomly picked one). That way, you might even be able to drop suboption 4 and simplify configuration a bit? Or, is suboption 4 intended for use in all cases (even when or if suboption 1 (DNS SRV) or suboption 2 (DNS 'A') are specified and used but that server fails to respond or the DNS server isn't responding)? In that case, are the clients not allowed to use suboption 3 anyway? - Bernie Volz Process Software From owner-dhcp-v4@bucknell.edu Mon Feb 7 13:10: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 NAA17870 for ; Mon, 7 Feb 2000 13:10:29 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id NAA12673; Mon, 7 Feb 2000 13:10:01 -0500 (EST) Received: from toccata.fugue.com (toccata.fugue.com [204.152.188.66]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id NAA08695 for ; Mon, 7 Feb 2000 13:09:55 -0500 (EST) Received: from grosse.manhattan.fugue.com (tundruk.manhattan.fugue.com [160.79.19.71]) by toccata.fugue.com (8.9.3/8.6.11) with ESMTP id KAA16536; Mon, 7 Feb 2000 10:04:05 -0800 (PST) Received: from grosse.manhattan.fugue.com (localhost [127.0.0.1]) by grosse.manhattan.fugue.com (8.9.3+3.2W/8.6.11) with ESMTP id NAA06984; Mon, 7 Feb 2000 13:09:44 -0500 (EST) Message-Id: <200002071809.NAA06984@grosse.manhattan.fugue.com> To: DHCPv4 discussion list cc: DHCPv4 discussion list Subject: Re: draft-ietf-dhc-csr-00.txt and compactness In-Reply-To: Message from Bernie Volz of "Mon, 07 Feb 2000 09:50:36 EST." <009E54D9.3F2B2382.53@process.com> Date: Mon, 07 Feb 2000 13:09:44 -0500 From: Ted Lemon Reply-To: mellon@isc.org Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN > Well, let me again suggest that one way to save 3 bytes per entry is to > use a mask length instead of a bit mask. I still believe that this would > be smart to do - I can't see much use for non-contiguous bit masks as > I think most software assumes this. Yeah, based on what Bernard said, I think this is a good plan - the only reason I objected was that I though preserving the capability Just In Case was a good idea. Now that we have a reason to do at least this degree of compression, I agree that it's worth doing. BTW, on this topic, I'd like to add a note to this draft saying that clients SHOULD set the Max Message Size option to their interface MTU if they support IP frag reassembly at boot time. This is a somewhat radical thing to suggest, but I think it might help to deal with the size issue in most cases, and I think that it would actually be very unusual for a client to have to do reassembly for an ethernet-frame-sized UDP packet anyway - maybe Barr can comment on how likely this is, since he has a fairly well-known WAN DHCP configuration, and maybe has some idea of how many of his WAN links have smaller MTUs. _MelloN_ From owner-dhcp-v4@bucknell.edu Mon Feb 7 13:12: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 NAA17907 for ; Mon, 7 Feb 2000 13:12:30 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id NAA15309; Mon, 7 Feb 2000 13:12:01 -0500 (EST) Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id NAA24013 for ; Mon, 7 Feb 2000 13:10:27 -0500 (EST) Received: from cs.columbia.edu (deccanqueen.cs.columbia.edu [128.59.19.199]) by cs.columbia.edu (8.9.1/8.9.1) with ESMTP id NAA17397; Mon, 7 Feb 2000 13:10:25 -0500 (EST) Message-ID: <389F0AAB.DA993AA9@cs.columbia.edu> Date: Mon, 07 Feb 2000 13:10:51 -0500 From: Gautam Nair Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.7 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: DHCPv4 discussion list CC: volz@process.com, Henning Schulzrinne Subject: Re: draft-nair-sip-dhcp-00.txt References: <009E54EB.4316E456.187@process.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Reply-To: gnair@cs.columbia.edu Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit Bernie Volz wrote: > Is the intent of the suboption 3 (IP address sub-option) that a client > randomly picks one address and if that server doesn't respond, it goes > to the backup server (suboption 4)? Why not have it try all of the > servers in suboption 3 (round-robin fashion, starting with a randomly > picked one). You're right. The selection is to be done in round-robin fashion starting with a randomly picked one. > That way, you might even be able to drop suboption 4 and > simplify configuration a bit? > Or, is suboption 4 intended for use in all cases (even when or if > suboption 1 (DNS SRV) or suboption 2 (DNS 'A') are specified and used > but that server fails to respond or the DNS server isn't responding)? Sub-option 4 is intended for use as a last resort option in all cases (sub-options 1, 2 and 3) if the SIP server fails to respond. Sub-option 4 is used after all the SIP servers specified in the sub-options 1,2 and 3 have been tried and have failed. > In > that case, are the clients not allowed to use suboption 3 anyway? > They are allowed to use sub-option 3. Only after an unsuccessful sub-option 3 attempt, does the client try sub-option 4. Sub-option 4 is required in addition to sub-option 3 because there's no easy way to specify the *backup only* server in the random round-robin selection scheme. In case of failure of only the DNS server, sub-option 3 will be used. > - Bernie Volz > Process Software Thank you for your comments and suggestions, Gautam Nair. Columbia University. From owner-dhcp-v4@bucknell.edu Mon Feb 7 13:46: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 NAA18761 for ; Mon, 7 Feb 2000 13:46:45 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id NAA06440; Mon, 7 Feb 2000 13:46:05 -0500 (EST) Received: from alcor.process.com (alcor.process.com [192.42.95.16]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id NAA03517 for ; Mon, 7 Feb 2000 13:45:58 -0500 (EST) Received: by process.com (MX V5.1-X A2w8g) id 5; Mon, 7 Feb 2000 13:44:49 -0500 Sender: owner-dhcp-v4@bucknell.edu Date: Mon, 7 Feb 2000 13:44:49 -0500 From: Bernie Volz To: DHCPv4 discussion list CC: DHCP-V4@bucknell.edu, HGS@cs.columbia.edu Message-ID: <009E54F9.F76969A7.5@process.com> Subject: Re: draft-nair-sip-dhcp-00.txt Reply-To: volz@process.com X-Sender: volz@process.com X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Gautam: I guess I still don't understand what the advantage of singling out this backup server is? Is it somehow special? Is it somehow less equal than the others? If you wanted to communicate some "preference", why not use a format whereby you have a preference value after each IP address in the suboption 3 list. That way, you can give your backup server less preference. The client logic might thus be arrange the addresses in order of preference, for those of equal preference, pick one at random. If that doesn't respond, pick another one of the same preference or if none left, start with next lower preference and so on until the list is exhausted (in which case, restart at the beginning or ???). - Bernie --- Date: Mon, 07 Feb 2000 13:10:51 -0500 From: Gautam Nair Bernie Volz wrote: > Is the intent of the suboption 3 (IP address sub-option) that a client > randomly picks one address and if that server doesn't respond, it goes > to the backup server (suboption 4)? Why not have it try all of the > servers in suboption 3 (round-robin fashion, starting with a randomly > picked one). You're right. The selection is to be done in round-robin fashion starting with a randomly picked one. > That way, you might even be able to drop suboption 4 and > simplify configuration a bit? > Or, is suboption 4 intended for use in all cases (even when or if > suboption 1 (DNS SRV) or suboption 2 (DNS 'A') are specified and used > but that server fails to respond or the DNS server isn't responding)? Sub-option 4 is intended for use as a last resort option in all cases (sub-options 1, 2 and 3) if the SIP server fails to respond. Sub-option 4 is used after all the SIP servers specified in the sub-options 1,2 and 3 have been tried and have failed. > In > that case, are the clients not allowed to use suboption 3 anyway? > They are allowed to use sub-option 3. Only after an unsuccessful sub-option 3 attempt, does the client try sub-option 4. Sub-option 4 is required in addition to sub-option 3 because there's no easy way to specify the *backup only* server in the random round-robin selection scheme. In case of failure of only the DNS server, sub-option 3 will be used. > - Bernie Volz > Process Software Thank you for your comments and suggestions, Gautam Nair. Columbia University. From owner-dhcp-v4@bucknell.edu Mon Feb 7 14:05: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 OAA19193 for ; Mon, 7 Feb 2000 14:05:22 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id OAA09666; Mon, 7 Feb 2000 14:04:55 -0500 (EST) Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id OAA28234 for ; Mon, 7 Feb 2000 14:04:37 -0500 (EST) Received: from cs.columbia.edu (deccanqueen.cs.columbia.edu [128.59.19.199]) by cs.columbia.edu (8.9.1/8.9.1) with ESMTP id OAA26153 for ; Mon, 7 Feb 2000 14:04:37 -0500 (EST) Message-ID: <389F175F.D6ED4D80@cs.columbia.edu> Date: Mon, 07 Feb 2000 14:05:03 -0500 From: Gautam Nair Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.7 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: DHCPv4 discussion list Subject: [Fwd: draft-nair-sip-dhcp-00.txt] Content-Type: multipart/mixed; boundary="------------2A85161D42BAEAC33B67C8E1" Reply-To: gnair@cs.columbia.edu Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN This is a multi-part message in MIME format. --------------2A85161D42BAEAC33B67C8E1 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit --------------2A85161D42BAEAC33B67C8E1 Content-Type: message/rfc822 Content-Disposition: inline Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by opus.cs.columbia.edu (8.9.1/8.9.1) with ESMTP id NAA23090 for ; Mon, 7 Feb 2000 13:55:14 -0500 (EST) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.1/8.9.1) with ESMTP id NAA25012; Mon, 7 Feb 2000 13:55:12 -0500 (EST) Sender: hgs@cs.columbia.edu Message-ID: <389F150D.D9A428F3@cs.columbia.edu> Date: Mon, 07 Feb 2000 13:55:09 -0500 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Bernie Volz CC: gnair@cs.columbia.edu, DHCP-V4@BUCKNELL.EDU Subject: Re: draft-nair-sip-dhcp-00.txt References: <009E54F9.F76969A7.5@process.com> Content-Type: text/plain; charset=us-ascii X-Mozilla-Status2: 00000000 Content-Transfer-Encoding: 7bit Bernie Volz wrote: > > Gautam: > > I guess I still don't understand what the advantage of singling out > this backup server is? Is it somehow special? Is it somehow less > equal than the others? > > If you wanted to communicate some "preference", why not use a format > whereby you have a preference value after each IP address in the > suboption 3 list. That way, you can give your backup server less > preference. The client logic might thus be arrange the addresses in > order of preference, for those of equal preference, pick one at > random. If that doesn't respond, pick another one of the same > preference or if none left, start with next lower preference and > so on until the list is exhausted (in which case, restart at the > beginning or ???). Indeed, it might be simpler to basically replicate the SRV entry (IP address, weight and preference, where weight is for randomization and preference is to distinguish backup from primary servers), with a 16-bit value for each, again to emulate the SRV record. The current solution is somewhat simpler. (In that case, we may as well replicate the protocol identifier as well, to allow selection of UDP vs. TCP...) The reason for backup servers is that there may well be off-site servers that serve a number of organizations (similar to the lower-ranked email servers found today), but that should never be used if the primary server is available. [Gautam, please replicate to dchp-v4, since I can't post there.] -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs --------------2A85161D42BAEAC33B67C8E1-- From owner-dhcp-v4@bucknell.edu Tue Feb 8 06:32: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 GAA13675 for ; Tue, 8 Feb 2000 06:32:29 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id GAA18190; Tue, 8 Feb 2000 06:32:00 -0500 (EST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id GAA03629 for ; Tue, 8 Feb 2000 06:31:27 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13539; Tue, 8 Feb 2000 06:31:26 -0500 (EST) Message-Id: <200002081131.GAA13539@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-05.txt Date: Tue, 08 Feb 2000 06:31:26 -0500 Sender: owner-dhcp-v4@bucknell.edu X-Sender: nsyracus@cnri.reston.va.us X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Title : The 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-05.txt Pages : 5 Date : 07-Feb-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-05.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-05.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-05.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: <20000207125510.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-userclass-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-userclass-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000207125510.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-dhcp-v4@bucknell.edu Tue Feb 8 19:51: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 TAA14194 for ; Tue, 8 Feb 2000 19:51:35 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id TAA02158; Tue, 8 Feb 2000 19:50:58 -0500 (EST) Received: from lukla.Sun.COM (lukla.Sun.COM [192.18.98.31]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id TAA04952 for ; Tue, 8 Feb 2000 19:50:48 -0500 (EST) Received: from sunmail1.Sun.COM ([129.145.1.2]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA11917 for ; Tue, 8 Feb 2000 17:50:47 -0700 (MST) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.84.31]) by sunmail1.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6.1-sunmail1) with ESMTP id QAA08530 for ; Tue, 8 Feb 2000 16:50:47 -0800 (PST) Received: from solarnet205 (solarnet205.Eng.Sun.COM [129.146.86.205]) by jurassic.eng.sun.com (8.9.3+Sun/8.9.3) with SMTP id QAA13423 for ; Tue, 8 Feb 2000 16:50:46 -0800 (PST) Date: Tue, 8 Feb 2000 16:50:39 -0800 (PST) From: "Michael W. Carney" Reply-To: "Michael W. Carney" Subject: Connectathon '00 DHCP reminder... (Fwd) To: DHCPv4 discussion list In-Reply-To: "Your message with ID" 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 Try again... >----------------Begin Forwarded Message----------------< Date: Tue, 8 Feb 2000 13:33:22 -0800 (PST) From: "Mike Carney" Subject: Connectathon '00 DHCP reminder... To: dhcp-v4@bucknell.edu Hi folks, Time is winding down for registration. You have until 2/14 to complete your registration. Please see for more details - you may find that your organization qualifies for a discount. DHCP testing will be done 3/6-3/8 (that's monday-wednesday). I'm in the process of inviting vendors of miscellaneous hardware (printers, firewall boxes, printservers, terminals, etc) to send us samples of their hardware to increase the number of different client implementations we'll have to test. If you know of a device you think would be a good candidate for such testing, please let me know. > Plans for Connectathon 2000 are already under way! The 14th annual > Connectathon event, an interoperability testing event for engineers > only, will be held March 2-9, 2000 in San Jose, California. > Connectathon, sponsored by Sun Microsystems, Inc., hosts nearly 30 > companies annually in an effort to test and debug source code which > utilize the following technologies and protocols: > > NFS versions 2, 3 and 4 > NFS over TCP > WebNFS > Lock Manager > NIS/NIS+/DNS > TI-RPC > Kerberos > Automounter > IPv6 > DHCP > LDAP > Gigabit Ethernet > > Based on demand, in addition we are considering to offer: > > NFS over IPv6 > RPC over IPv6 > Service Location Protocol > IPsec > Mobile IPv4 > > If you are interested in testing any of the above 5 protocols, please > send a note to Cthon@Sun.COM and we'll gauge interest. Or if you have a > > suggestion for another technology, feel free to contact us as well. > > Testing continues 24 hours per day. Technology testing coordinators > will organize testing procedures and test suite material. In > addition, there will be seminars with speakers addressing various > topics. > > The registration deadline is February 14, 2000. An Early Bird > Discount on booth fees is available to those who register and pay by > December 31, 1999. For registration information, please see our web > site at http://www.connectathon.org. > > If you have any questions, please feel free to contact Audrey Van > Belleghem at audrey@vanb.com or (408) 358-9598. > > We look forward to seeing you at the 14th annual Connectathon event! > > Audrey Van Belleghem > Connectathon Manager Mike Carney SNT Internet Engineering Sun Microsystems, Inc. Mailstop UMPK17-202 901 San Antonio Rd Palo Alto, CA 94303 >----------------End Forwarded Message----------------< Mike Carney SNT Internet Engineering Sun Microsystems, Inc. Mailstop UMPK17-202 901 San Antonio Rd Palo Alto, CA 94303 From owner-dhcp-v4@bucknell.edu Tue Feb 8 23:58: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 XAA18530 for ; Tue, 8 Feb 2000 23:58:31 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id XAA01710; Tue, 8 Feb 2000 23:56:25 -0500 (EST) Received: from monitor.internaut.com (mg-206253202-37.ricochet.net [206.253.202.37]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id XAA09657 for ; Tue, 8 Feb 2000 23:56:03 -0500 (EST) Received: from vaiobean ([204.57.137.66]) by monitor.internaut.com (8.9.2/8.8.8) with SMTP id UAA17362; Tue, 8 Feb 2000 20:45:53 -0800 (PST) Reply-To: From: "Bernard Aboba" To: DHCPv4 discussion list Subject: RE: draft-ietf-dhc-csr-00.txt and compactness Date: Tue, 8 Feb 2000 20:52:08 -0800 Message-ID: <033b01bf72b9$7147cb70$2d8939cc@ntdev.microsoft.com> 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 CWS, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <200002071809.NAA06984@grosse.manhattan.fugue.com> X-Mimeole: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit Increasing the Max Message Size option is probably a good idea in this case. With some minimal packing efforts (such as not including zero octets in the source network), you should be able to achieve a density of 3 octets/route. Therefore with a 1500 octet max message size you should be able to handle all but the most extreme cases. BTW, routing protocols such as DVMRP have encountered the route packing problem, and found various ways to compress routes. Code is readily available for implementing these packing methods. For details see: ftp://ftp.isi.edu/internet-drafts/draft-ietf-idmr-dvmrp-v3-09.txt For example, to quote from section 3.4.2 Route Packing: "In order to pack more source networks into a route report, source networks are often represented by less than 4 octets. The number of non-zero bytes in the mask value is used to determine the number of octets used to represent each source network within that particular mask value. For instance if the mask value of 255.255.0.0 is being reported, the source networks would only contain 2 octets each. DVMRP assumes that source networks will never be aggregated into networks whose prefix length is less than 8. Therefore, it does not carry the first octet of the mask in the Route Report since, given this assumption, the first octet will always be 0xFF. This means that the netmask value will always be represented in 3 octets. This method of specifying source network masks is compatible with techniques described in [Rekh93] and [Full93] to group traditional Class C networks into super-nets and to allow different subnets of the same Class A network to be discontinuous. It does not, however, allow grouping class A networks into super-nets since the first octet of the netmask is always assumed to be 255." >From Section 3.4.3 Route Metrics: "As seen in the packet format below, Route Reports do not contain a count of the number of routes reported for each netmask. Instead, a "Last" bit is defined as the high order bit of the octet following the network address. This bit is set to signify when the last route is being reported for a particular mask value. When the "Last" bit is set and the end of the message has not been reached, the next value will be a new netmask to be applied to the subsequent list of routes." -----Original Message----- From: owner-dhcp-v4@bucknell.edu [mailto:owner-dhcp-v4@bucknell.edu]On Behalf Of Ted Lemon Sent: Monday, February 07, 2000 10:10 AM To: DHCPv4 discussion list Cc: DHCPv4 discussion list Subject: Re: draft-ietf-dhc-csr-00.txt and compactness > Well, let me again suggest that one way to save 3 bytes per entry is to > use a mask length instead of a bit mask. I still believe that this would > be smart to do - I can't see much use for non-contiguous bit masks as > I think most software assumes this. Yeah, based on what Bernard said, I think this is a good plan - the only reason I objected was that I though preserving the capability Just In Case was a good idea. Now that we have a reason to do at least this degree of compression, I agree that it's worth doing. BTW, on this topic, I'd like to add a note to this draft saying that clients SHOULD set the Max Message Size option to their interface MTU if they support IP frag reassembly at boot time. This is a somewhat radical thing to suggest, but I think it might help to deal with the size issue in most cases, and I think that it would actually be very unusual for a client to have to do reassembly for an ethernet-frame-sized UDP packet anyway - maybe Barr can comment on how likely this is, since he has a fairly well-known WAN DHCP configuration, and maybe has some idea of how many of his WAN links have smaller MTUs. _MelloN_ From owner-dhcp-v4@bucknell.edu Wed Feb 9 00:21: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 AAA18761 for ; Wed, 9 Feb 2000 00:21:05 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id AAA13070; Wed, 9 Feb 2000 00:11:09 -0500 (EST) Received: from monitor.internaut.com (mg-206253202-37.ricochet.net [206.253.202.37]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id AAA01202 for ; Wed, 9 Feb 2000 00:10:51 -0500 (EST) Received: from vaiobean ([204.57.137.66]) by monitor.internaut.com (8.9.2/8.8.8) with SMTP id VAA17379; Tue, 8 Feb 2000 21:01:09 -0800 (PST) Reply-To: From: "Bernard Aboba" To: DHCPv4 discussion list Cc: "'DHCPv4 discussion list'" Subject: RE: draft-ietf-dhc-csr-00.txt and compactness Date: Tue, 8 Feb 2000 21:07:33 -0800 Message-ID: <033c01bf72bb$93cd4f60$2d8939cc@ntdev.microsoft.com> 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 CWS, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <200002070529.AAA26560@grosse.manhattan.fugue.com> X-Mimeole: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit >Wow. I can see the reasoning behind trying to compress the option, >but in a really pathological case you'd still run across the size >limit, so I'm not sure how valuable this is. By increasing the max message size and doing some minimal efforts at compression, I think you can handle all but the most extreme cases. For example, I have not seen any customers needing this capability that have more than 250 routes. If you can get down to 3 octets/route (equivalent to levels #3-4 described below) you should be able to meet this requirement. Here are some comparisons: 1. Full mask and full route: 8 octets/route 2. prefix and full route: 5 octets/route 3. prefix and non-zero portion of route: 2-5 octets/route (assuming no prefixes larger than /8) 4. prefix, number and list of routes (non-zero portion only): 1-4 octets/route >I'd rather not implement that impression scheme, but if you >really think it's important I guess I can't argue that it's not. It's a question of how far you want to go for what benefit. I would argue that going from #1 to #2 is a clear win for little incremental work. I would also argue that going from #2 to #3 yields substantial benefits for not much extra work. How many extra lines of code are required to check the prefix and only send the non-zero portion of the route? Going from #3 to #4 yields some benefits with more incremental work than the other two steps so here we might decide that the extra effort is not worth the code complexity. Still, this kind of thing has been implemented in routing protocols such as DVMRP so that implementation is by no means intricate. (It just requires sorting the route list by prefix). From owner-dhcp-v4@bucknell.edu Wed Feb 9 12:21: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 MAA11411 for ; Wed, 9 Feb 2000 12:21:03 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id MAA03342; Wed, 9 Feb 2000 12:20:36 -0500 (EST) Received: from e3.ny.us.ibm.com (e3.ny.us.ibm.com [32.97.182.103]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id MAA17149 for ; Wed, 9 Feb 2000 12:20:12 -0500 (EST) From: hoyoung@us.ibm.com Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e3.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id MAA206342 for ; Wed, 9 Feb 2000 12:18:57 -0500 Received: from D51MTA05.pok.ibm.com (d51mta05.pok.ibm.com [9.117.200.33]) by northrelay02.pok.ibm.com (8.8.8m2/NCO v2.06) with SMTP id MAA167968 for ; Wed, 9 Feb 2000 12:20:06 -0500 Received: by D51MTA05.pok.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 85256880.005F35C5 ; Wed, 9 Feb 2000 12:19:56 -0500 X-Lotus-FromDomain: IBMUS To: DHCPv4 discussion list Message-ID: <85256880.005E8AE1.00@D51MTA05.pok.ibm.com> Date: Wed, 9 Feb 2000 11:12:38 -0600 Subject: DHCP operation 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 Sorry to send the note to this list. But I can't get answer from anybody and hope someone in this group will enlighten me. When a DHCP server receives a DISCOVER msg from a client residing on subnet 8.10.120.0, should it search for an address from this subnet directly or should it search three or four of other subnets (such as 8.10.130.0, 8.10.90.0, 8.10.60.0) first before it searches the correct one? The clients reach the server via relay agents. I can't find any information via RFCs. Thanks very much! Hannah Day From owner-dhcp-v4@bucknell.edu Wed Feb 9 12:25: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 MAA11590 for ; Wed, 9 Feb 2000 12:25:24 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id MAA07681; Wed, 9 Feb 2000 12:25:15 -0500 (EST) Received: from toccata.fugue.com (toccata.fugue.com [204.152.188.66]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id MAA06839 for ; Wed, 9 Feb 2000 12:25:00 -0500 (EST) Received: from grosse.manhattan.fugue.com (tundruk.manhattan.fugue.com [160.79.19.71]) by toccata.fugue.com (8.9.3/8.6.11) with ESMTP id JAA28864; Wed, 9 Feb 2000 09:19:04 -0800 (PST) Received: from grosse.manhattan.fugue.com (localhost [127.0.0.1]) by grosse.manhattan.fugue.com (8.9.3+3.2W/8.6.11) with ESMTP id MAA03073; Wed, 9 Feb 2000 12:24:45 -0500 (EST) Message-Id: <200002091724.MAA03073@grosse.manhattan.fugue.com> To: DHCPv4 discussion list cc: DHCPv4 discussion list Subject: Re: DHCP operation In-Reply-To: Message from hoyoung@us.ibm.com of "Wed, 09 Feb 2000 11:12:38 CST." <85256880.005E8AE1.00@D51MTA05.pok.ibm.com> Date: Wed, 09 Feb 2000 12:24:44 -0500 From: Ted Lemon Reply-To: mellon@isc.org Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN > When a DHCP server receives a DISCOVER msg from a client residing on subnet > 8.10.120.0, should it search for an address from this subnet directly or > should it search three or four of other subnets (such as 8.10.130.0, > 8.10.90.0, 8.10.60.0) first before it searches the correct one? The > clients reach the server via relay agents. I can't find any information > via RFCs. What do you mean, "search?" It should reply with an offer that's on the correct subnet, or not reply at all. It does this using the subnet declarations you define in combination with the giaddr from the relay agent. You should read up on subnet declarations and shared-network declarations, get that clear in your mind, and then maybe this will make sense. If not, the DHCP Handbook describes the process in gory detail. _MelloN_ From owner-dhcp-v4@bucknell.edu Wed Feb 9 12:27: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 MAA11713 for ; Wed, 9 Feb 2000 12:27:05 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id MAA28679; Wed, 9 Feb 2000 12:27:00 -0500 (EST) Received: from toccata.fugue.com (toccata.fugue.com [204.152.188.66]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id MAA26884 for ; Wed, 9 Feb 2000 12:26:39 -0500 (EST) Received: from grosse.manhattan.fugue.com (tundruk.manhattan.fugue.com [160.79.19.71]) by toccata.fugue.com (8.9.3/8.6.11) with ESMTP id JAA28873; Wed, 9 Feb 2000 09:20:53 -0800 (PST) Received: from grosse.manhattan.fugue.com (localhost [127.0.0.1]) by grosse.manhattan.fugue.com (8.9.3+3.2W/8.6.11) with ESMTP id MAA03091; Wed, 9 Feb 2000 12:26:34 -0500 (EST) Message-Id: <200002091726.MAA03091@grosse.manhattan.fugue.com> To: DHCPv4 discussion list cc: DHCPv4 discussion list Subject: Re: DHCP operation In-Reply-To: Message from hoyoung@us.ibm.com of "Wed, 09 Feb 2000 11:12:38 CST." <85256880.005E8AE1.00@D51MTA05.pok.ibm.com> Date: Wed, 09 Feb 2000 12:26:34 -0500 From: Ted Lemon Reply-To: mellon@isc.org Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Oops, thought I was reading a different mailing list. The manual pages I was talking about are for the ISC DHCP server (http://www.isc.org). The treatment of this in the DHCP Handbook is definitely more detailed and clear than that in the manual pages, so if you're not using the ISC server anyway, I'd recommend the Handbook. OTOH, I'm one of the authors (Ralph is the other) so I'm admittedly a bit biased. _MelloN_ From owner-dhcp-v4@bucknell.edu Wed Feb 9 12:30: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 MAA11875 for ; Wed, 9 Feb 2000 12:30:54 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id MAA13851; Wed, 9 Feb 2000 12:29:56 -0500 (EST) Received: from sbcsmtp2.ptss.com (sbcsmtp2.ptss.com [204.107.19.24]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id MAA13324 for ; Wed, 9 Feb 2000 12:29:48 -0500 (EST) Received: from mail2.pacbell.com (mail2.pacbell.com [129.245.2.18]) by sbcsmtp2.ptss.com (8.8.8/8.8.8) with ESMTP id JAA18876; Wed, 9 Feb 2000 09:28:11 -0800 (PST) Received: from msgnorth98.ffcrc.pacbell.com .(msgnorth98.ffcrc.pacbell.com [150.234.34.86]) by mail2.PacBell.COM (8.8.5/8.8.5-pb990306) with ESMTP id JAA04500; Wed, 9 Feb 2000 09:28:51 -0800 (PST) Received: by msgnorth98.ffcrc.pacbell.com with Internet Mail Service (5.5.2448.0) id <1RR2WBBV>; Wed, 9 Feb 2000 09:28:28 -0800 Message-ID: <11917F263658D2118AC000805FD4B706E75A59@msgsrv04.srv.PacBell.COM> From: "HIBBS, BARR (SBCSI)" To: DHCPv4 discussion list Subject: RE: DHCP operation Date: Wed, 9 Feb 2000 09:28:28 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain Reply-To: RBHIBBS@msg.pacbell.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN the answer, unfortunately, is "it depends" DHCP servers are supposed to offer clients IP address leases that are appropriate for their use, if all other conditions and criteria are met: in the simplest case, this means from the same subnet as the client's request was received. But lots of other things may happen... If the client is attached to a shared network segment with multiple subnet addresses, the client may be offered any available IP address lease for the shared network segment -- again, subject to local policy and configuration that might restrict the choices available. --Barr > ---------- > From: hoyoung@US.IBM.COM[SMTP:hoyoung@US.IBM.COM] > Sent: Wednesday, February 09, 2000 9:12 AM > To: DHCPv4 discussion list > Subject: DHCP operation > > Sorry to send the note to this list. But I can't get answer from anybody > and hope someone in this group will enlighten me. > > When a DHCP server receives a DISCOVER msg from a client residing on > subnet > 8.10.120.0, should it search for an address from this subnet directly or > should it search three or four of other subnets (such as 8.10.130.0, > 8.10.90.0, 8.10.60.0) first before it searches the correct one? The > clients reach the server via relay agents. I can't find any information > via RFCs. > > Thanks very much! > > Hannah Day > From owner-dhcp-v4@bucknell.edu Wed Feb 9 12:44: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 MAA12518 for ; Wed, 9 Feb 2000 12:44:07 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id MAA01394; Wed, 9 Feb 2000 12:43:57 -0500 (EST) Received: from e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.104]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id MAA17450 for ; Wed, 9 Feb 2000 12:43:43 -0500 (EST) From: hoyoung@us.ibm.com 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 MAA254324; Wed, 9 Feb 2000 12:42:25 -0500 Received: from D51MTA05.pok.ibm.com (d51mta05.pok.ibm.com [9.117.200.33]) by northrelay02.pok.ibm.com (8.8.8m2/NCO v2.06) with SMTP id MAA225388; Wed, 9 Feb 2000 12:43:35 -0500 Received: by D51MTA05.pok.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 85256880.0061599E ; Wed, 9 Feb 2000 12:43:19 -0500 X-Lotus-FromDomain: IBMUS To: DHCPv4 discussion list cc: DHCPv4 discussion list Message-ID: <85256880.0060EEC4.00@D51MTA05.pok.ibm.com> Date: Wed, 9 Feb 2000 11:38:43 -0600 Subject: Re: DHCP operation 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 Please see the following log file. That's what I meant by "search". Is it normal? 02/01 16:48:37 : [00001543] INFO: .............. generate_containerpath: Generating containerpat h for 1-524153203012f3e2be6cbf0101000000 02/01 16:48:37 : [00001543] TRACE: .............. generate_containerpath: Record address is 9.10. 30.240 02/01 16:48:37 : [00001543] TRACE: .............. generate_containerpath: Record clue is 9.10.30. 2 02/01 16:48:37 : [00001543] TRACE: .............. generate_containerpath: generate containerpath flags = 1 1 0 02/01 16:48:37 : [00001543] TRACE: ................ tree_srch_address: tree search: address to fi nd = 9.10.30.2 02/01 16:48:37 : [00001543] INFO: ................ tree_srch_address: tree search: subnet to sea rch = 9.10.71.0 02/01 16:48:37 : [00001543] TRACE: ................ tree_srch_address: tree search: subnet mask t o apply = 255.255.255.0 02/01 16:48:37 : [00001543] TRACE: ................ tree_srch_address: tree search: address to fi nd = 9.10.30.2 02/01 16:48:37 : [00001543] INFO: ................ tree_srch_address: tree search: subnet to sea rch = 9.10.38.0 02/01 16:48:37 : [00001543] TRACE: ................ tree_srch_address: tree search: subnet mask t o apply = 255.255.255.0 02/01 16:48:37 : [00001543] TRACE: ................ tree_srch_address: tree search: address to fi nd = 9.10.30.2 02/01 16:48:37 : [00001543] INFO: ................ tree_srch_address: tree search: subnet to sea rch = 9.10.33.0 02/01 16:48:37 : [00001543] TRACE: ................ tree_srch_address: tree search: subnet mask t o apply = 255.255.255.0 02/01 16:48:37 : [00001543] TRACE: ................ tree_srch_address: tree search: address to fi nd = 9.10.30.2 02/01 16:48:37 : [00001543] INFO: ................ tree_srch_address: tree search: subnet to sea rch = 9.10.11.0 02/01 16:48:37 : [00001543] TRACE: ................ tree_srch_address: tree search: subnet mask t o apply = 255.255.255.0 02/01 16:48:37 : [00001543] TRACE: ................ tree_srch_address: tree search: address to fi nd = 9.10.30.2 02/01 16:48:37 : [00001543] INFO: ................ tree_srch_address: tree search: subnet to sea rch = 9.10.31.0 02/01 16:48:37 : [00001543] TRACE: ................ tree_srch_address: tree search: subnet mask t o apply = 255.255.255.0 02/01 16:48:37 : [00001543] TRACE: ................ tree_srch_address: tree search: address to fi nd = 9.10.30.2 02/01 16:48:37 : [00001543] INFO: ................ tree_srch_address: tree search: subnet to sea rch = 9.10.30.0 02/01 16:48:37 : [00001543] TRACE: ................ tree_srch_address: tree search: subnet mask t o apply = 255.255.255.0 02/01 16:48:37 : [00001543] TRACE: .............. generate_containerpath: Subnet: 9.10.30.0 02/01 16:48:37 : [00001543] TRACE: .............. generate_containerpath: Subnet: 9.10.30.0 02/01 16:48:37 : [00001543] TRACE: .............. generate_containerpath: Subnet: 9.10.30.0 02/01 16:48:37 : [00001543] TRACE: .............. generate_containerpath: Subnet: 9.10.30.0 02/01 16:48:37 : [00001543] INFO: .............. generate_containerpath: Using address 9.10.30.2 40 for 1-524153203012f3e2be6cbf0101000000 Thanks Ted Lemon on 02/09/2000 11:24:44 AM To: Hannah O Day/Rochester/IBM@IBMUS cc: DHCPv4 discussion list Subject: Re: DHCP operation > When a DHCP server receives a DISCOVER msg from a client residing on subnet > 8.10.120.0, should it search for an address from this subnet directly or > should it search three or four of other subnets (such as 8.10.130.0, > 8.10.90.0, 8.10.60.0) first before it searches the correct one? The > clients reach the server via relay agents. I can't find any information > via RFCs. What do you mean, "search?" It should reply with an offer that's on the correct subnet, or not reply at all. It does this using the subnet declarations you define in combination with the giaddr from the relay agent. You should read up on subnet declarations and shared-network declarations, get that clear in your mind, and then maybe this will make sense. If not, the DHCP Handbook describes the process in gory detail. _MelloN_ From owner-dhcp-v4@bucknell.edu Wed Feb 9 13:16: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 NAA14330 for ; Wed, 9 Feb 2000 13:15:59 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id NAA07843; Wed, 9 Feb 2000 13:15:43 -0500 (EST) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id NAA11138 for ; Wed, 9 Feb 2000 13:15:38 -0500 (EST) From: hoyoung@us.ibm.com Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id NAA432734; Wed, 9 Feb 2000 13:14:25 -0500 Received: from D51MTA05.pok.ibm.com (d51mta05.pok.ibm.com [9.117.200.33]) by northrelay02.pok.ibm.com (8.8.8m2/NCO v2.06) with SMTP id NAA158772; Wed, 9 Feb 2000 13:15:34 -0500 Received: by D51MTA05.pok.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 85256880.0064488C ; Wed, 9 Feb 2000 13:15:21 -0500 X-Lotus-FromDomain: IBMUS To: DHCPv4 discussion list cc: DHCPv4 discussion list Message-ID: <85256880.0063EBAA.00@D51MTA05.pok.ibm.com> Date: Wed, 9 Feb 2000 12:11:21 -0600 Subject: RE: DHCP operation 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 Barr, This is not a shared/campus environment All segments have only one subnet. There is no multiple subnets on one router interface. "HIBBS, BARR (SBCSI)" on 02/09/2000 11:28:28 AM Please respond to RBHIBBS@MSG.PACBELL.COM To: DHCPv4 discussion list cc: Subject: RE: DHCP operation the answer, unfortunately, is "it depends" DHCP servers are supposed to offer clients IP address leases that are appropriate for their use, if all other conditions and criteria are met: in the simplest case, this means from the same subnet as the client's request was received. But lots of other things may happen... If the client is attached to a shared network segment with multiple subnet addresses, the client may be offered any available IP address lease for the shared network segment -- again, subject to local policy and configuration that might restrict the choices available. --Barr > ---------- > From: hoyoung@US.IBM.COM[SMTP:hoyoung@US.IBM.COM] > Sent: Wednesday, February 09, 2000 9:12 AM > To: DHCPv4 discussion list > Subject: DHCP operation > > Sorry to send the note to this list. But I can't get answer from anybody > and hope someone in this group will enlighten me. > > When a DHCP server receives a DISCOVER msg from a client residing on > subnet > 8.10.120.0, should it search for an address from this subnet directly or > should it search three or four of other subnets (such as 8.10.130.0, > 8.10.90.0, 8.10.60.0) first before it searches the correct one? The > clients reach the server via relay agents. I can't find any information > via RFCs. > > Thanks very much! > > Hannah Day > From owner-dhcp-v4@bucknell.edu Wed Feb 9 13:48: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 NAA16546 for ; Wed, 9 Feb 2000 13:48:27 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id NAA22598; Wed, 9 Feb 2000 13:48:02 -0500 (EST) Received: from ausmail.austin.ibm.com (ausmail.austin.ibm.com [192.35.232.19]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id NAA12972 for ; Wed, 9 Feb 2000 13:47:09 -0500 (EST) Received: from netmail2.austin.ibm.com (netmail2.austin.ibm.com [9.53.250.97]) by ausmail.austin.ibm.com (8.9.1/8.8.5) with ESMTP id MAA33262 for ; Wed, 9 Feb 2000 12:48:49 -0600 Received: from yeast.austin.ibm.com (yeast.austin.ibm.com [9.53.150.239]) by netmail2.austin.ibm.com (8.8.5/8.8.5) with ESMTP id MAA41924; Wed, 9 Feb 2000 12:47:04 -0600 Received: from austin.ibm.com (yeast.austin.ibm.com [9.53.150.239]) by yeast.austin.ibm.com (AIX4.3/8.9.3/8.7-client1.01) with ESMTP id MAA26092; Wed, 9 Feb 2000 12:47:03 -0600 Sender: owner-dhcp-v4@bucknell.edu Message-ID: <38A1B627.669B90A7@austin.ibm.com> Date: Wed, 09 Feb 2000 12:47:03 -0600 From: David Babbitt X-Mailer: Mozilla 4.7 [en] (X11; U; AIX 4.3) X-Accept-Language: en MIME-Version: 1.0 To: DHCPv4 discussion list CC: DHCPv4 discussion list Subject: Re: DHCP operation References: <85256880.0060EEC4.00@D51MTA05.pok.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Reply-To: dbabbitt@austin.ibm.com X-Sender: dbabbitt@austin.ibm.com X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit The output that you're quoting is when the AIX DHCP server is descending through all of the subnets that it has configured to find the one that matches your relay agent's giaddr. It's extraordinarily verbose when TRACE logging is turned on, as you can see. Continuing what Barr mentioned is that once the subnet is actually matched, many other configuration options may prevent the client from receiving an address OFFER from the server. In AIX, these may not be all that intuitive, so you'll have to consult its documentation or sample files to see. Implementation specific questions are not usually handled on this list, so if you want to take this off-line, feel free to email me directly. Thanks -- David Babbitt AIX TCP/IP Development IBM Austin From owner-dhcp-v4@bucknell.edu Thu Feb 10 12:32: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 MAA05190 for ; Thu, 10 Feb 2000 12:32:52 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id MAA30730; Thu, 10 Feb 2000 12:32:01 -0500 (EST) Received: from stanmsr4.telecom.sna.samsung.com (host8.samsungtelecom.com [209.39.48.8]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id MAA10461 for ; Thu, 10 Feb 2000 12:31:30 -0500 (EST) Received: by stanmsr4.telecom.sna.samsung.com with Internet Mail Service (5.5.2448.0) id ; Thu, 10 Feb 2000 11:35:25 -0600 Message-ID: <41740B0AF075D31196650060971DA17C083094@stanmsr4.telecom.sna.samsung.com> From: Bob Evans To: DHCPv4 discussion list Subject: DHCP Server + Client on same node ? Date: Thu, 10 Feb 2000 11:35:15 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01BF73ED.36E15566" 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 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01BF73ED.36E15566 Content-Type: text/plain; charset="iso-8859-1" Newbie question... In bringing up a subnet, if the first node to boot is the DCHP Server host, can it configure itself, or does a DHCP Server node always need to be statically configured? <> ------_=_NextPart_000_01BF73ED.36E15566 Content-Type: application/octet-stream; name="Robert J Evans.vcf" Content-Disposition: attachment; filename="Robert J Evans.vcf" Content-Transfer-Encoding: quoted-printable BEGIN:VCARD VERSION:2.1 N:Evans;Robert;J.;; FN:Robert J. Evans ORG:Samsung Telecommunications America;Network Systems Lab TITLE:Sr. Staff Engineer NOTE;ENCODING=3DQUOTED-PRINTABLE: Object-Oriented Databases = (Versant)=3D0D=3D0ALDAP,DNS,DHCP,SRB=3D0D=3D0ADistributed = Resources=3D0D=3D0ANaming and Addressing=3D0D=3D0A=3D0D=3D0A TEL;WORK;VOICE:(972) 761-7725 TEL;WORK;FAX:(972) 761-7799 ADR;WORK:;;1130 E. Arapaho Rd.;Richardson;TX;75081;United States of = America LABEL;WORK;ENCODING=3DQUOTED-PRINTABLE:1130 E. Arapaho = Rd.=3D0D=3D0ARichardson, TX 75081=3D0D=3D0AUnited States of America ROLE:Software Engineering EMAIL;PREF;INTERNET:revans@sta.samsung.com REV:20000204T174331Z END:VCARD ------_=_NextPart_000_01BF73ED.36E15566-- From owner-dhcp-v4@bucknell.edu Fri Feb 11 14:06: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 OAA17565 for ; Fri, 11 Feb 2000 14:06:04 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id OAA17509; Fri, 11 Feb 2000 14:04:13 -0500 (EST) Received: from lespaul.process.com (lespaul.process.com [192.42.95.27]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id OAA02435 for ; Fri, 11 Feb 2000 14:02:32 -0500 (EST) Received: by lespaul.process.com with Internet Mail Service (5.5.2650.21) id <1PF4RA42>; Fri, 11 Feb 2000 14:01:36 -0500 Message-ID: <63D30D6E10CFD11190A90000F805FE86023C95CF@lespaul.process.com> From: Steve Gonczi To: DHCPv4 discussion list Subject: Load (re)balancing for renewals. Date: Fri, 11 Feb 2000 14:01: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: Gonczi@process.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Hello, I have been thinking about how renewals happen when the DHC Failover protocol is running. If the primary server goes down several times, potentially all clients will migrate over and start renewing from the backup. Even after normal operations are restored, the clients will keep renewing from the backup. Currently there is no mechanism to migrate some of these renewing clients back to the primary. (apart from shutting down the backup). I posit that ideally, 50% of the clients renewals would be handled by each server during normal operation. What do you all think about using the load balancing protocol to accomplish this? During normal ops, the load balancing hash could be used to selectively ignore renewal attempts. This would cause the ignored clients to broadcast @t2, and as a result, switch over to the other server. sG From owner-dhcp-v4@bucknell.edu Fri Feb 11 14:19: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 OAA17796 for ; Fri, 11 Feb 2000 14:19:18 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id OAA23945; Fri, 11 Feb 2000 14:19:12 -0500 (EST) Received: from toccata.fugue.com (toccata.fugue.com [204.152.188.66]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id OAA01507 for ; Fri, 11 Feb 2000 14:19:03 -0500 (EST) Received: from grosse.manhattan.fugue.com (dhcp-222.rc.vix.com [204.152.187.222]) by toccata.fugue.com (8.9.3/8.6.11) with ESMTP id LAA11255; Fri, 11 Feb 2000 11:13:18 -0800 (PST) Received: from grosse.manhattan.fugue.com (localhost [127.0.0.1]) by grosse.manhattan.fugue.com (8.9.3+3.2W/8.6.11) with ESMTP id LAA01216; Fri, 11 Feb 2000 11:19:01 -0800 (PST) Message-Id: <200002111919.LAA01216@grosse.manhattan.fugue.com> To: DHCPv4 discussion list cc: DHCPv4 discussion list Subject: Re: Load (re)balancing for renewals. In-Reply-To: Message from Steve Gonczi of "Fri, 11 Feb 2000 14:01:35 EST." <63D30D6E10CFD11190A90000F805FE86023C95CF@lespaul.process.com> Date: Fri, 11 Feb 2000 11:19:01 -0800 From: Ted Lemon Reply-To: mellon@isc.org Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Hm. What about sending the other server's IP address back in the server identifier option once it comes back up, if you receive a request for an address for which you're not the primary? We could then use your strategy to account for clients that don't notice the switch. We could also strategically send a short T2 (t1 == t2, for example) to clients to which we are responding because the server that is primary for them is down. _MelloN_ From owner-dhcp-v4@bucknell.edu Fri Feb 11 14:24: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 OAA17857 for ; Fri, 11 Feb 2000 14:24:53 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id OAA01465; Fri, 11 Feb 2000 14:24:46 -0500 (EST) Received: from lespaul.process.com (lespaul.process.com [192.42.95.27]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id OAA04767 for ; Fri, 11 Feb 2000 14:24:38 -0500 (EST) Received: by lespaul.process.com with Internet Mail Service (5.5.2650.21) id <1PF4RAWM>; Fri, 11 Feb 2000 14:23:37 -0500 Message-ID: <63D30D6E10CFD11190A90000F805FE86023C95D0@lespaul.process.com> From: Steve Gonczi To: DHCPv4 discussion list Cc: "'dhcp-v4@bucknell.edu'" Subject: RE: Load (re)balancing for renewals. Date: Fri, 11 Feb 2000 14:23:36 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Reply-To: Gonczi@process.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN If we stay within the framework fo the failover protocol, the address would not change. If I am reading your post correctly, you are forcing the clients to start over (DISCOVER) hence get a new address. My suggestion would not involve NAK-ing any client. We would merely ignore some of them, so that they get to t2 and start broadcasting their renewal request. Because of the 2 failover servers having identical lease databases, at this point they would be able to renew their addresses, ( and get the same address) but from the other server. I should have been clearer on this point. sG -----Original Message----- From: Diana Lane [mailto:dblane@wal-mart.com] Sent: Friday, February 11, 2000 2:14 PM To: 'Gonczi@process.com' Subject: RE: Load (re)balancing for renewals. Steve, For what it's worth, we have been known to deactivate the leases to get Server B to NAK requests from some of the clients so that they switch back to Server A. I like your renewal ignoring idea better, though, because one would not have to remember to go reactivate the leases. The problem with either approach is that some applications do not take it kindly when their IP address suddenly changes out from under them. Diana Lane Sr. Network Engineer IP Research & Development Wal-Mart Stores, Inc. 501/277-3177 - WAL*MART CONFIDENTIAL - From owner-dhcp-v4@bucknell.edu Fri Feb 11 14:25: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 OAA17872 for ; Fri, 11 Feb 2000 14:25:26 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id OAA02836; Fri, 11 Feb 2000 14:25:20 -0500 (EST) Received: from alcor.process.com (alcor.process.com [192.42.95.16]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id OAA28129 for ; Fri, 11 Feb 2000 14:25:02 -0500 (EST) Received: by process.com (MX V5.1-X A2w8g) id 117; Fri, 11 Feb 2000 14:23:42 -0500 Sender: owner-dhcp-v4@bucknell.edu Date: Fri, 11 Feb 2000 14:23:41 -0500 From: Bernie Volz To: DHCPv4 discussion list CC: DHCP-V4@bucknell.edu Message-ID: <009E5824.0F53E029.117@process.com> Subject: Re: Load (re)balancing for renewals. Reply-To: volz@process.com X-Sender: volz@process.com X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN >Hm. What about sending the other server's IP address back in the >server identifier option once it comes back up, if you receive a >request for an address for which you're not the primary? We could >then use your strategy to account for clients that don't notice the >switch. We could also strategically send a short T2 (t1 == t2, for >example) to clients to which we are responding because the server that >is primary for them is down. > > _MelloN_ Yes, I like that far better than Steve's suggestion of waiting until T2's broadcast. Also, doing nothing likely isn't that big a deal. Eventually the clients will get redistributed (of course the secondary server will need to be down at a renewal or the client will have to have the lease expire - such as if it is removed from the network). - Bernie From owner-dhcp-v4@bucknell.edu Fri Feb 11 15:01: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 PAA18595 for ; Fri, 11 Feb 2000 15:01:53 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id PAA08812; Fri, 11 Feb 2000 15:00:39 -0500 (EST) Received: from lespaul.process.com (lespaul.process.com [192.42.95.27]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id OAA25851 for ; Fri, 11 Feb 2000 14:59:54 -0500 (EST) Received: by lespaul.process.com with Internet Mail Service (5.5.2650.21) id <1PF4RAX6>; Fri, 11 Feb 2000 14:40:00 -0500 Message-ID: <63D30D6E10CFD11190A90000F805FE86023C95D2@lespaul.process.com> From: Steve Gonczi To: DHCPv4 discussion list Cc: "'dhcp-v4@bucknell.edu'" Subject: RE: Load (re)balancing for renewals. Date: Fri, 11 Feb 2000 14:39:59 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Reply-To: Gonczi@process.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Yes, I like Ted's suggestion too. I was primarily concerned with pointing out the issue, and my solution was to some degree, improvised. I believe this issue is worth solving. It is clearly possible that clients get spontaneously redistributed but (IMHO) it is not probable. >Yes, I like that far better than Steve's suggestion of waiting until >T2's broadcast. > >Also, doing nothing likely isn't that big a deal. Eventually the >clients will get redistributed (of course the secondary server >will need to be down at a renewal or the client will have to have >the lease expire - such as if it is removed from the network). > >- Bernie From owner-dhcp-v4@bucknell.edu Fri Feb 11 15:50: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 PAA19965 for ; Fri, 11 Feb 2000 15:50:30 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id PAA29783; Fri, 11 Feb 2000 15:48:56 -0500 (EST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id PAA25982 for ; Fri, 11 Feb 2000 15:48:28 -0500 (EST) Received: from kkinnear-nt (ch2-dhcp133-199.cisco.com [161.44.133.199]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id PAA00446; Fri, 11 Feb 2000 15:47:37 -0500 (EST) Message-Id: <4.2.0.58.20000211151649.0181d5f0@funnel.cisco.com> X-Sender: kkinnear@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Fri, 11 Feb 2000 15:48:42 -0500 To: DHCPv4 discussion list From: Kim Kinnear Subject: RE: Load (re)balancing for renewals. Cc: dhcp-v4@bucknell.edu, kkinnear@cisco.com In-Reply-To: <63D30D6E10CFD11190A90000F805FE86023C95D2@lespaul.process.c om> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Reply-To: kkinnear@cisco.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN I feel like this isn't a big deal, and what experience we have in practice seems to bear that out. Though using the server-identifier to "change" the DHCP server is a neat trick if you know the other one is up. I believe that is what Ted was suggesting. (Though not, I think, what Steve thought Ted was suggesting. There is no NAKing involved in this approach.) If we want to solve this "problem", that is the solution that I think we should use. I don't think shortening the renewal interval is necessary or useful in this case partly, I suppose, since I don't think having the secondary renew leases is in general a big problem. I'm thinking too that increasing the load on the secondary (sooner than necessary) is not a good idea. Remember that over time, the renewal times will get shorter and shorter until they equal the MCLT, and then they will be the MCLT until the primary comes up or someone tells the secondary that the primary is down. Cheers -- Kim At 02:39 PM 2/11/00 -0500, Steve Gonczi wrote: >Yes, I like Ted's suggestion too. I was primarily concerned with >pointing out the issue, and my solution was to some degree, improvised. > >I believe this issue is worth solving. It is clearly possible that clients >get spontaneously redistributed but (IMHO) it is not probable. > > >Yes, I like that far better than Steve's suggestion of waiting until > >T2's broadcast. > > > >Also, doing nothing likely isn't that big a deal. Eventually the > >clients will get redistributed (of course the secondary server > >will need to be down at a renewal or the client will have to have > >the lease expire - such as if it is removed from the network). > > > >- Bernie > From owner-dhcp-v4@bucknell.edu Fri Feb 11 16:16: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 QAA21152 for ; Fri, 11 Feb 2000 16:16:52 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id QAA09666; Fri, 11 Feb 2000 16:16:23 -0500 (EST) Received: from alcor.process.com (alcor.process.com [192.42.95.16]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id QAA32231 for ; Fri, 11 Feb 2000 16:16:06 -0500 (EST) Received: by process.com (MX V5.1-X A2w8g) id 112; Fri, 11 Feb 2000 16:15:32 -0500 Sender: owner-dhcp-v4@bucknell.edu Date: Fri, 11 Feb 2000 16:15:31 -0500 From: Bernie Volz To: DHCPv4 discussion list CC: DHCP-V4@bucknell.edu Message-ID: <009E5833.AEA28A22.112@process.com> Subject: RE: Load (re)balancing for renewals. Reply-To: volz@process.com X-Sender: volz@process.com X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Can we get some indication from DHCP Client implementors as to what checking they do on the server-identifier field? Can we really change this or will clients reject the renewal? ---- Kim Kinnear wrote: I feel like this isn't a big deal, and what experience we have in practice seems to bear that out. Though using the server-identifier to "change" the DHCP server is a neat trick if you know the other one is up. I believe that is what Ted was suggesting. (Though not, I think, what Steve thought Ted was suggesting. There is no NAKing involved in this approach.) If we want to solve this "problem", that is the solution that I think we should use. I don't think shortening the renewal interval is necessary or useful in this case partly, I suppose, since I don't think having the secondary renew leases is in general a big problem. I'm thinking too that increasing the load on the secondary (sooner than necessary) is not a good idea. Remember that over time, the renewal times will get shorter and shorter until they equal the MCLT, and then they will be the MCLT until the primary comes up or someone tells the secondary that the primary is down. Cheers -- Kim At 02:39 PM 2/11/00 -0500, Steve Gonczi wrote: >Yes, I like Ted's suggestion too. I was primarily concerned with >pointing out the issue, and my solution was to some degree, improvised. > >I believe this issue is worth solving. It is clearly possible that clients >get spontaneously redistributed but (IMHO) it is not probable. > > >Yes, I like that far better than Steve's suggestion of waiting until > >T2's broadcast. > > > >Also, doing nothing likely isn't that big a deal. Eventually the > >clients will get redistributed (of course the secondary server > >will need to be down at a renewal or the client will have to have > >the lease expire - such as if it is removed from the network). > > > >- Bernie > From owner-dhcp-v4@bucknell.edu Fri Feb 11 16:44: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 QAA22437 for ; Fri, 11 Feb 2000 16:44:04 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id QAA19759; Fri, 11 Feb 2000 16:43:53 -0500 (EST) Received: from toccata.fugue.com (toccata.fugue.com [204.152.188.66]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id QAA04697 for ; Fri, 11 Feb 2000 16:43:40 -0500 (EST) Received: from grosse.manhattan.fugue.com (dhcp-222.rc.vix.com [204.152.187.222]) by toccata.fugue.com (8.9.3/8.6.11) with ESMTP id NAA11737; Fri, 11 Feb 2000 13:37:55 -0800 (PST) Received: from grosse.manhattan.fugue.com (localhost [127.0.0.1]) by grosse.manhattan.fugue.com (8.9.3+3.2W/8.6.11) with ESMTP id NAA01551; Fri, 11 Feb 2000 13:43:37 -0800 (PST) Message-Id: <200002112143.NAA01551@grosse.manhattan.fugue.com> To: DHCPv4 discussion list cc: DHCPv4 discussion list Subject: Re: Load (re)balancing for renewals. In-Reply-To: Message from Kim Kinnear of "Fri, 11 Feb 2000 15:48:42 EST." <4.2.0.58.20000211151649.0181d5f0@funnel.cisco.com> Date: Fri, 11 Feb 2000 13:43:37 -0800 From: Ted Lemon Reply-To: mellon@isc.org Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN > I don't think shortening the renewal interval is necessary or > useful in this case partly, I suppose, since I don't think having > the secondary renew leases is in general a big problem. What I suggested was not to shorten the renewal time, but to make the renewal and rebind time the same - that is, if DHCP server B thinks a client belongs to DHCP server A, but is assigning the client an address because it knows DHCP server A is down, then it sends lease T1 and T2 times that are identical, or just sends a T2 time that's half the lease duration. This will cause the client to broadcast its first renew, which will then be picked up by server A if it's back up by then. _MelloN_ From owner-dhcp-v4@bucknell.edu Tue Feb 15 08:41:38 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 IAA29684 for ; Tue, 15 Feb 2000 08:41:37 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id IAA05590; Tue, 15 Feb 2000 08:40:47 -0500 (EST) Received: from leo.eg.bucknell.edu (leo.eg.bucknell.edu [134.82.56.108]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id IAA01637 for ; Tue, 15 Feb 2000 08:40:19 -0500 (EST) Received: from droms-laptop (lab72-027.bucknell.edu [134.82.72.27]) by leo.eg.bucknell.edu (8.8.8+Sun/8.8.8) with ESMTP id IAA15295 for ; Tue, 15 Feb 2000 08:40:18 -0500 (EST) Message-Id: <4.2.2.20000215083610.00a42930@mail.bucknell.edu> X-Sender: droms@mail.bucknell.edu X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Tue, 15 Feb 2000 08:36:20 -0500 To: DHCPv4 discussion list From: Internet-Drafts@ietf.org (by way of Ralph Droms ) Subject: I-D ACTION:draft-nair-sip-dhcp-01.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Reply-To: Internet-Drafts@ietf.org Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : DHCP Option for SIP Servers Author(s) : G. Nair, H. Schulzrinne Filename : draft-nair-sip-dhcp-01.txt Pages : 8 Date : 14-Feb-00 This document defines a DHCP option that contains one or more pointers to one or more SIP servers . This enables a SIP client to obtain the addresses of the SIP servers during bootup. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-nair-sip-dhcp-01.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-nair-sip-dhcp-01.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-nair-sip-dhcp-01.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. Content-Type: text/plain Content-ID: <20000214115153.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-nair-sip-dhcp-01.txt From owner-dhcp-v4@bucknell.edu Thu Feb 17 14:26: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 OAA22544 for ; Thu, 17 Feb 2000 14:26:17 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id OAA18827; Thu, 17 Feb 2000 14:25:50 -0500 (EST) Received: from ns.mntm.org (ns.mntm.org [209.18.254.130]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id OAA04342 for ; Thu, 17 Feb 2000 14:25:24 -0500 (EST) Received: from mntm.org (swtc6.mntm.org [209.18.254.198]) by ns.mntm.org (8.9.1/8.9.1) with ESMTP id NAA26928 for ; Thu, 17 Feb 2000 13:24:46 -0600 (CST) Message-ID: <38AC4411.D0635C20@mntm.org> Date: Thu, 17 Feb 2000 12:55:13 -0600 From: Rod Wrege Organization: Southwest Telecommunications Cooperative X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: DHCPv4 discussion list Subject: no subnet declaration Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Reply-To: rodwrege@mntm.org Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit I installed dhcp-2.0 from isc.org onto a Calder Linux system with 2.2 kernel. When I execute dhcpd I get the following message: no subnet declaration for eth0 (209.18.254.222) dhcpd: exiting my dhcpd.conf file contains the following: subnet 209.18.254.192 netmask 255.255.255.224 { range 209.18.254.194 209.18.254.206; option broadcast-address 209.18.254.223; option routers 209.18.254.193; } Any suggestions? -- Rod Wrege, Director Southwest Telecommunications Cooperative 507.831.6950 fax: 507.831.6944 rodwrege@mntm.org From owner-dhcp-v4@bucknell.edu Thu Feb 17 17:18:38 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 RAA26154 for ; Thu, 17 Feb 2000 17:18:37 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id RAA13364; Thu, 17 Feb 2000 17:18:19 -0500 (EST) Received: from sbcsmtp2.ptss.com (sbcsmtp2.ptss.com [204.107.19.24]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id RAA14362 for ; Thu, 17 Feb 2000 17:18:05 -0500 (EST) Received: from mail2.pacbell.com (mail2.pacbell.com [129.245.2.18]) by sbcsmtp2.ptss.com (8.8.8/8.8.8) with ESMTP id OAA07552; Thu, 17 Feb 2000 14:16:24 -0800 (PST) Received: from msgnorth98.ffcrc.pacbell.com .(msgnorth98.ffcrc.pacbell.com [150.234.34.86]) by mail2.PacBell.COM (8.8.5/8.8.5-pb990306) with ESMTP id OAA18416; Thu, 17 Feb 2000 14:17:01 -0800 (PST) Received: by msgnorth98.ffcrc.pacbell.com with Internet Mail Service (5.5.2448.0) id <1RR29KPR>; Thu, 17 Feb 2000 14:16:37 -0800 Message-ID: <11917F263658D2118AC000805FD4B706E75A7D@msgsrv04.srv.PacBell.COM> From: "HIBBS, BARR (SBCSI)" To: DHCPv4 discussion list Subject: RE: no subnet declaration Date: Thu, 17 Feb 2000 14:16:28 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain Reply-To: RBHIBBS@msg.pacbell.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN > From: Rod Wrege[SMTP:rodwrege@mntm.org] > Sent: Thursday, February 17, 2000 10:55 AM > > I installed dhcp-2.0 from isc.org onto a Calder Linux system with 2.2 > kernel. When I execute dhcpd I get the following message: > no subnet declaration for eth0 (209.18.254.222) > dhcpd: exiting > > my dhcpd.conf file contains the following: > > subnet 209.18.254.192 netmask 255.255.255.224 { > range 209.18.254.194 209.18.254.206; > option broadcast-address 209.18.254.223; > option routers 209.18.254.193; > } > ...mmmmm.... that's curious! Given a 27-bit subnet mask, addresses 192-223 are valid for the subnet. Your range excludes 192, 193, and 207-223, and your other uses seem appropriate. I see no obvious typos, either. The message normally means that dhcpd.conf does not have a valid subnet declaration that includes the server interface, but that can't be the case here. As an experiment, change the subnet mask to 255.255.255.0 and try to start the server. If the server starts with that declaration, then you've found an interesting bug! I'll also try to recreate the problem to see what I find.... --Barr From owner-dhcp-v4@bucknell.edu Tue Feb 22 11:19: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 LAA13969 for ; Tue, 22 Feb 2000 11:19:13 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id LAA13877; Tue, 22 Feb 2000 11:18:26 -0500 (EST) Received: from george.gims.net (www.30.235.209.in-addr.arpa [209.235.30.98] (may be forged)) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id LAA28291 for ; Tue, 22 Feb 2000 11:18:00 -0500 (EST) Received: from ahallnbook ([38.201.18.97]) by george.gims.net (8.8.8/8.8.8) with SMTP id LAA22571 for ; Tue, 22 Feb 2000 11:17:59 -0500 Message-ID: <000f01bf7d50$b25788c0$2a0ca8c0@secureworks.net> From: "Andrew Hall" To: DHCPv4 discussion list Subject: Is this possible? Date: Tue, 22 Feb 2000 11:20:11 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Reply-To: ahall@secureworks.net Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit Hello dhcp guru's, First my setup: I have a server with two nic cards. One single port Intel nic running dhcp client. The dhcp client is only running on eth0. I have a four port card in the server running dhcp server on pqfe0, pqfe1, pqfe2, and pqfe3. My question is this can I have ports pqfe0-2 responding with one subnet and pqfe3 respond with another? For example ports pqfe0-2 respond with subnet 192.168.10/24 and pqfe3 respond with 10.10.1/24. I have looked at the man pages for dhcpd.conf and dhcp and found nothing covering this. I have attempted to run two copies of the daemon and that fails also. Lastly is there a resource where this is covered? I have been unable to find one. Thankyou in advance for all your assistance. Andrew Hall Secureworks, Inc. From owner-dhcp-v4@bucknell.edu Tue Feb 22 14:21: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 OAA19541 for ; Tue, 22 Feb 2000 14:21:23 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id OAA26136; Tue, 22 Feb 2000 14:20:41 -0500 (EST) Received: from sbcsmtp2.ptss.com (sbcsmtp2.ptss.com [204.107.19.24]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id OAA03113 for ; Tue, 22 Feb 2000 14:20:13 -0500 (EST) Received: from mail2.pacbell.com (mail2.pacbell.com [129.245.2.18]) by sbcsmtp2.ptss.com (8.8.8/8.8.8) with ESMTP id LAA22761; Tue, 22 Feb 2000 11:18:35 -0800 (PST) Received: from msgnorth98.ffcrc.pacbell.com .(msgnorth98.ffcrc.pacbell.com [150.234.34.86]) by mail2.PacBell.COM (8.8.5/8.8.5-pb990306) with ESMTP id LAA24667; Tue, 22 Feb 2000 11:19:18 -0800 (PST) Received: by msgnorth98.ffcrc.pacbell.com with Internet Mail Service (5.5.2448.0) id <1RRJBR09>; Tue, 22 Feb 2000 11:18:53 -0800 Message-ID: <11917F263658D2118AC000805FD4B706E75A95@msgsrv04.srv.PacBell.COM> From: "HIBBS, BARR (SBCSI)" To: DHCPv4 discussion list Subject: RE: Is this possible? Date: Tue, 22 Feb 2000 11:18:51 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain Reply-To: RBHIBBS@msg.pacbell.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN > From: Andrew Hall[SMTP:ahall@secureworks.net] > Sent: Tuesday, February 22, 2000 8:20 AM > > I have a server with two nic cards. One single port Intel nic running > dhcp > client. The dhcp client is only running on eth0. I have a four port card > in the server running dhcp server on pqfe0, pqfe1, pqfe2, and pqfe3. > ...what are you doing here? It generally makes no sense to have the same host be both a client and a server: a server requires a fixed (static) address assignment to preserve continuity in the network topology. > My question is this can I have ports pqfe0-2 responding with one subnet > and > pqfe3 respond with another? For example ports pqfe0-2 respond with subnet > 192.168.10/24 and pqfe3 respond with 10.10.1/24. I have looked at the man > pages for dhcpd.conf and dhcp and found nothing covering this. I have > attempted to run two copies of the daemon and that fails also. > ...if your host supports multiple interfaces and you've properly configured the server, it should "just work." ...the *entire* network topology reachable from the server must be declared. ...pqfe3 must have a 10.10.1.x address and be accessible only from the 10.10.1.0 subnet, that is, no routers or switches on 192.168.10.0 should forward bootp packets to it, and it must be physically separate from 192.168.10.0 as well. ...pqfe0, pqfe1, and pqfe2 must be the inverse of pqfe3: that is, they must have addresses on the 192.168.10.0 subnet, be physically separate from the 10.10.1.0 subnet, and should never receive bootp packets from 10.10.1.0. ...the server will always respond to packets using the interface on which the packet was received, so, with proper configuration it all should "just work." > Lastly is there a resource where this is covered? I have been unable to > find one. > ...probably not in so many words.... ...have you tried configuring the server and had it fail? If so, we need to see the dhcpd.conf file that you are using, the exact messages written to the syslog, and may need more information to help you debug the problem.... --Barr From owner-dhcp-v4@bucknell.edu Tue Feb 22 16:07: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 QAA23185 for ; Tue, 22 Feb 2000 16:07:45 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id QAA21632; Tue, 22 Feb 2000 16:06:49 -0500 (EST) Received: from george.gims.net (www.30.235.209.in-addr.arpa [209.235.30.98] (may be forged)) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id QAA11481 for ; Tue, 22 Feb 2000 16:06:28 -0500 (EST) Received: from cc49958c ([38.201.18.97]) by george.gims.net (8.8.8/8.8.8) with SMTP id QAA24386; Tue, 22 Feb 2000 16:06:07 -0500 Message-ID: <000801bf7d78$f41dbb80$2a0ca8c0@chmbl1.ga.home.com> From: "Andrew Hall" To: DHCPv4 discussion list References: <11917F263658D2118AC000805FD4B706E75A95@msgsrv04.srv.PacBell.COM> Subject: Re: Is this possible? Date: Tue, 22 Feb 2000 16:08:18 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Reply-To: ahall@secureworks.net Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit I want to thank Barr for his assistance. I was able to get it working. What I have found is that since the interface must have an ip in the subnet that the server is responding with that adding different subnets to specific interfaces is as simple as ifconfig-ing the interface and added the subnet in the dhcpd.conf file. Thanks again. Andrew Hall ----- Original Message ----- From: HIBBS, BARR (SBCSI) To: DHCPv4 discussion list ; Sent: Tuesday, February 22, 2000 2:18 PM Subject: RE: Is this possible? > > > From: Andrew Hall[SMTP:ahall@secureworks.net] > > Sent: Tuesday, February 22, 2000 8:20 AM > > > > I have a server with two nic cards. One single port Intel nic running > > dhcp > > client. The dhcp client is only running on eth0. I have a four port card > > in the server running dhcp server on pqfe0, pqfe1, pqfe2, and pqfe3. > > > ...what are you doing here? It generally makes no sense to have the same > host be both a client and a server: a server requires a fixed (static) > address assignment to preserve continuity in the network topology. > > > > My question is this can I have ports pqfe0-2 responding with one subnet > > and > > pqfe3 respond with another? For example ports pqfe0-2 respond with subnet > > 192.168.10/24 and pqfe3 respond with 10.10.1/24. I have looked at the man > > pages for dhcpd.conf and dhcp and found nothing covering this. I have > > attempted to run two copies of the daemon and that fails also. > > > ...if your host supports multiple interfaces and you've properly configured > the server, it should "just work." > > ...the *entire* network topology reachable from the server must be declared. > > ...pqfe3 must have a 10.10.1.x address and be accessible only from the > 10.10.1.0 subnet, that is, no routers or switches on 192.168.10.0 should > forward bootp packets to it, and it must be physically separate from > 192.168.10.0 as well. > > ...pqfe0, pqfe1, and pqfe2 must be the inverse of pqfe3: that is, they must > have addresses on the 192.168.10.0 subnet, be physically separate from the > 10.10.1.0 subnet, and should never receive bootp packets from 10.10.1.0. > > ...the server will always respond to packets using the interface on which > the packet was received, so, with proper configuration it all should "just > work." > > > > Lastly is there a resource where this is covered? I have been unable to > > find one. > > > ...probably not in so many words.... > > ...have you tried configuring the server and had it fail? If so, we need to > see the dhcpd.conf file that you are using, the exact messages written to > the syslog, and may need more information to help you debug the problem.... > > --Barr > From owner-dhcp-v4@bucknell.edu Tue Feb 22 23:32: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 XAA02526 for ; Tue, 22 Feb 2000 23:32:54 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id XAA06961; Tue, 22 Feb 2000 23:25:19 -0500 (EST) Received: from mail-out2.apple.com (mail-out2.apple.com [17.254.0.51]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id XAA10470 for ; Tue, 22 Feb 2000 23:25:03 -0500 (EST) Received: from mailgate2.apple.com (A17-129-100-225.apple.com [17.129.100.225]) by mail-out2.apple.com (8.9.3/8.9.3) with ESMTP id UAA19738 for ; Tue, 22 Feb 2000 20:25:03 -0800 (PST) Received: from scv2.apple.com (scv2.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 2.0.15) with ESMTP id for ; Tue, 22 Feb 2000 20:24:55 -0800 Received: from [17.201.23.37] (chesh1.apple.com [17.201.23.37]) by scv2.apple.com (8.9.3/8.9.3) with SMTP id UAA13945 for ; Tue, 22 Feb 2000 20:24:54 -0800 (PST) Message-Id: <200002230424.UAA13945@scv2.apple.com> Subject: DHCP Domain Name Date: Tue, 22 Feb 2000 20:24:54 -0800 x-sender: cheshire@mail.apple.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Stuart Cheshire To: DHCPv4 discussion list MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Reply-To: cheshire@apple.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN I can't believe how vague the RFCs are some times: >3.17. Domain Name > > This option specifies the domain name that client should use when > resolving hostnames via the Domain Name System. > > The code for this option is 15. Its minimum length is 1. > > Code Len Domain Name > +-----+-----+-----+-----+-----+-----+-- > | 15 | n | d1 | d2 | d3 | d4 | ... > +-----+-----+-----+-----+-----+-----+-- This is obviously supposed to be a fully qualified domain name, since it is specifying the default domain to use for *unqualified* name lookups when the user types something like "telnet bob". Does that mean that it is supposed to be a fully qualified domain name ending in a dot, i.e. "apple.com."? Or, since we know it *must* be a fully qualified domain name, is the final trailing dot superfluous? Am I supposed to assume that the final trailing dot (c) MUST be present (b) MUST NOT be present (c) MAY or MAY NOT be present (but the client MUST treat all domain names as fully qualified whether or not they have a trailing dot)? The server I generally use for testing doesn't give any clue -- it just lets the administrator type in whatever they want and sends that as the Domain Name option (even if it begins with digits or contains illegal characters like spaces). Stuart Cheshire * Web Page * Wizard Without Portfolio, Apple Computer From owner-dhcp-v4@bucknell.edu Wed Feb 23 12:16: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 MAA27309 for ; Wed, 23 Feb 2000 12:16:51 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id MAA32100; Wed, 23 Feb 2000 12:16:20 -0500 (EST) Received: from fs-sd-exch1.coppermountain.com (fs-sd-exch1.coppermountain.com [209.246.224.234]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id MAA24994 for ; Wed, 23 Feb 2000 12:14:51 -0500 (EST) Received: by fs-sd-exch1.coppermountain.com with Internet Mail Service (5.5.2448.0) id ; Wed, 23 Feb 2000 09:14:07 -0800 Message-ID: <47FEF5D2BE22D311AA8600508B108915999F9E@fs-sd-exch1.coppermountain.com> From: Eric Michelsen To: DHCPv4 discussion list Subject: agent-options-08 Date: Wed, 23 Feb 2000 09:14:06 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) 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 Why the prohibition against modifying BOOTP requests (sec 2.1, par 2)? The clients may be old, and may issue BOOTP instead of DHCP. Since the Agent-information is for the benefit of the access device and the DHCP server, why disrupt existing deployments of BOOTP clients, when the agent and server don't care? As an access equipment vendor, I have several scenarios where the access equipment has the knowledge of Circuit ID, etc., but is not acting at a protocol layer that allows it to actually *be* a DHCP relay agent. These applications require that upstream Relay Agents accept requests where the "agent-information" is present, but giaddr = 0. Because servers and agents "know" if they require circuit IDs or not, I don't see any security benefit to requiring *relay agents* to discard such requests (sec 2.1, par 3). A better statement would be that "devices inserting 'agent-information' must remove any pre-existing 'agent-information', to prevent spoofing." The intent of sec 2.1, par 6 is not clear to me: why would the sname or file fields have agent-information options in them, and why shouldn't the access device remove them? The intent of sec 2.1, par 8 is not clear to me: for security, the access device certainly WILL enforce valid agent-information, whether this document requires it or not. But what is the intent here? Along with this, sec 2.2, par 4, DHCP servers may indeed require the agent-options field to be present. Anything else may be a potential security weakness. Sec 2.1.1, for clarity: why would a relay agent receive a relayed request? Doesn't the original relay-agent forward the request by unicast directly to the server? Sec 3.2, I think the "remote-ID" should be clarified, for the case of PVC-like connections to the premise (e.g., DSL), the remote-ID may be an identifier of the physical line (essentially, all the circuit-ID suggestions, plus the additional suggestions given). From the descriptions, it seems like servers interpret remote-ID as the definitive client identification, and circuit-ID may be interesting, but not necessarily definitive. ------------------------------------------- Eric L. Michelsen, Copper Mountain Networks From owner-dhcp-v4@bucknell.edu Wed Feb 23 12:27: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 MAA27709 for ; Wed, 23 Feb 2000 12:27:02 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id MAA08285; Wed, 23 Feb 2000 12:26:55 -0500 (EST) Received: from sbcsmtp2.ptss.com (sbcsmtp2.ptss.com [204.107.19.24]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id MAA10605 for ; Wed, 23 Feb 2000 12:26:32 -0500 (EST) Received: from mail2.pacbell.com (mail2.pacbell.com [129.245.2.18]) by sbcsmtp2.ptss.com (8.8.8/8.8.8) with ESMTP id JAA22670; Wed, 23 Feb 2000 09:25:38 -0800 (PST) Received: from msgnorth98.ffcrc.pacbell.com .(msgnorth98.ffcrc.pacbell.com [150.234.34.86]) by mail2.PacBell.COM (8.8.5/8.8.5-pb990306) with ESMTP id JAA23463; Wed, 23 Feb 2000 09:26:25 -0800 (PST) Received: by msgnorth98.ffcrc.pacbell.com with Internet Mail Service (5.5.2448.0) id <1RRJCTBL>; Wed, 23 Feb 2000 09:25:59 -0800 Message-ID: <11917F263658D2118AC000805FD4B706E75A9B@msgsrv04.srv.PacBell.COM> From: "HIBBS, BARR (SBCSI)" To: DHCPv4 discussion list Subject: RE: DHCP Domain Name Date: Wed, 23 Feb 2000 09:25:53 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain Reply-To: RBHIBBS@msg.pacbell.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN > I can't believe how vague the RFCs are some times: > ...so what else is new....?? > >3.17. Domain Name > > > > This option specifies the domain name that client should use when > > resolving hostnames via the Domain Name System. > > > > The code for this option is 15. Its minimum length is 1. > > > > Code Len Domain Name > > +-----+-----+-----+-----+-----+-----+-- > > | 15 | n | d1 | d2 | d3 | d4 | ... > > +-----+-----+-----+-----+-----+-----+-- > > This is obviously supposed to be a fully qualified domain name, since it > is specifying the default domain to use for *unqualified* name lookups > when the user types something like "telnet bob". > ...oops! option 15 is NOT the "Fully-Qualified Domain Name (FQDN)" because it lacks the hostname portion (carried in option 12).... ...are we having fun yet? > Does that mean that it is supposed to be a fully qualified domain name > ending in a dot, i.e. "apple.com."? > ...no... it should be considered the string to be appended to the hostname portion (option 12), with a period (.) inserted between the two.... > Or, since we know it *must* be a fully qualified domain name, is the > final trailing dot superfluous? > ...a trailing period should NOT be present.... > Am I supposed to assume that the final trailing dot > > (c) MUST be present > (b) MUST NOT be present > (c) MAY or MAY NOT be present (but the client MUST treat all domain names > as fully qualified whether or not they have a trailing dot)? > ...(b)... with the added caveat that option 15 is NOT the FQDN, just the domain name part.... > The server I generally use for testing doesn't give any clue -- it just > lets the administrator type in whatever they want and sends that as the > Domain Name option (even if it begins with digits or contains illegal > characters like spaces). > ...with apologies to Robert Elz and others, Domain Names MAY begin with ANY character except the separator (period) and may contain ANY character (again, the separator cannot be used as an element of the name). However, and this is a BIG gotcha, there are many cases where such Domain names DON'T work with existing implementations of everything from mail service to web browsers.... There is no simple over-arching rule for how to construct domain names that work in all circumstances, so there cannot be a simple rule covering the contents of the options 12 and 15 strings.... --Barr From owner-dhcp-v4@bucknell.edu Wed Feb 23 23:17: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 XAA09996 for ; Wed, 23 Feb 2000 23:17:17 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id XAA30289; Wed, 23 Feb 2000 23:16:28 -0500 (EST) Received: from hotmail.com (f277.law3.hotmail.com [209.185.240.55]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id XAA15672 for ; Wed, 23 Feb 2000 23:16:09 -0500 (EST) Received: (qmail 30482 invoked by uid 0); 24 Feb 2000 04:15:38 -0000 Message-ID: <20000224041538.30481.qmail@hotmail.com> Received: from 216.254.10.21 by www.hotmail.com with HTTP; Wed, 23 Feb 2000 20:15:38 PST X-Originating-IP: [216.254.10.21] From: "Todd Wasielewski" To: DHCPv4 discussion list Subject: DHCP client Date: Wed, 23 Feb 2000 20:15:38 PST Mime-Version: 1.0 Content-Type: text/plain; format=flowed Reply-To: tawasiel@hotmail.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN I've been researching DHCP for three days and still don't have an answer to my question. I have a windows95 machine running microsofts DHCP client. I have an NT server running the DHCP server. My lease is for 3 months. My question is; I turn on my PC and obtain an IP address. I turn off the DHCP server, I still have that DHCP address until the lease expires correct? Now the DHCP server is still off. I shutdown my windows95 PC with the 3 month lease and turn it off. When I turn the PC on should I or should I not have a valid IP address on it for imediate use? I say no because the DHCP server is down and everytime the client starts it needs to talk with a DHCP server. I read tons of MSDN notes and in my office I tested it and it worked like that. But my colleagues in NY mention they can turn off their DHCP server and reboot their workstations and still have an IP address which was intially assigned by DHCP in use. I even read the DHCP RFC's and it was confusing because; .7 When clients should use DHCP A client SHOULD use DHCP to reacquire or verify its IP address and network parameters whenever the local network parameters may have changed; e.g., at system boot time or after a disconnection from the local network, as the local network configuration may change without the client's or user's knowledge. If a client has knowledge of a previous network address and is unable to contact a local DHCP server, the client may continue to use the previous network address until the lease for that address expires. If the lease expires before the client can contact a DHCP server, the client must immediately discontinue use of the previous network address and may inform local users of the problem. and this paragraph; 4.4.6 DHCPRELEASE If the client no longer requires use of its assigned network address (e.g., the client is gracefully shut down), the client sends a DHCPRELEASE message to the server. Note that the correct operation of DHCP does not depend on the transmission of DHCPRELEASE messages. PLEASE HELP ME SEE THE LIGHT!!!!! ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com From owner-dhcp-v4@bucknell.edu Thu Feb 24 18:57:01 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 SAA12856 for ; Thu, 24 Feb 2000 18:56:55 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id SAA03181; Thu, 24 Feb 2000 18:54:41 -0500 (EST) Received: from lespaul.process.com (lespaul.process.com [192.42.95.27]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id SAA11775; Thu, 24 Feb 2000 18:53:24 -0500 (EST) Received: by lespaul.process.com with Internet Mail Service (5.5.2650.21) id ; Thu, 24 Feb 2000 18:52:20 -0500 Message-ID: <63D30D6E10CFD11190A90000F805FE86023C960D@lespaul.process.com> From: Steve Gonczi To: DHCPv4 discussion list Cc: "'robs@join.com'" , "'volz@alcor.process.com'" , "'droms@bucknell.edu'" , "'grabil@lucent.com'" , "'mellon@isc.org'" , "'dhcp-v4@bucknell.edu'" Subject: DHCP Load balancing draft addition Date: Thu, 24 Feb 2000 18:52:19 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Reply-To: Gonczi@process.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Greetings, I have new words (kindly contributed by Ted Lemon) that I would like to add to the DHC load balancing draft. The net effect is to ALLOW a bias (in addition to the hard yes/no) approach. If a server implements this unilaterally, in a worst case scenario we may get a few extra offers under heavy load. I would like to remind you all, the load balancing only affects NEW leases. Please share your thougths! Here is the text: DHCP server implementations may optionally be configurable to handle a case where load balancing is being done but where one DHCP server is not available, and the other is. DHCP server implementations that provide this capability SHOULD have a configuration parameter that states the number of seconds to wait after the client's first request has been sent before responding to a client whose hash would not normally permit the client to be served. A DHCP server providing this capability SHOULD use the value in the secs field of the client request if its value is not zero. Because some clients may not correctly implement the secs field, a DHCP server MAY keep track of the first instance of a client transaction to which it would not normally respond. If the server receives a request from a client that has the same transaction ID as a previously recorded request, and if the secs field in the second packet is zero, the DHCP server MAY use the time in seconds between receipt of the first client request and the receipt of the subsequent client request in place of the secs field in order to determine whether or not to respond. From owner-dhcp-v4@bucknell.edu Thu Feb 24 22:29: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 WAA16559 for ; Thu, 24 Feb 2000 22:29:39 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id WAA16896; Thu, 24 Feb 2000 22:29:14 -0500 (EST) Received: from bosco. (enhntfw3.enh.org [198.173.24.130]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id WAA31486 for ; Thu, 24 Feb 2000 22:29:06 -0500 (EST) Received: from home.com by bosco. (SMI-8.6/SMI-SVR4) id VAA26096; Thu, 24 Feb 2000 21:19:16 -0600 Message-ID: <38B5F6AD.4C928940@home.com> Date: Thu, 24 Feb 2000 21:27:41 -0600 From: Michael Schneider Organization: McKessonHBOC / Evanston Hospital X-Mailer: Mozilla 4.6 [en] (Win98; I) X-Accept-Language: en,en-US,en-GB,es MIME-Version: 1.0 To: DHCPv4 discussion list CC: DHCPv4 discussion list Subject: Re: DHCP client References: <20000224041538.30481.qmail@hotmail.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Reply-To: grimkirk@home.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit Todd - My WINTEL experience in this matter is thus: If: A) Client receives lease (lease period is 90 days), and B) DHCP server dies, and C) DHCP stay dead for more than 90 days. Then: D) At each start up and at every decaying half-life interval, the client will poll the nonexistent DHCP server for a renewal of the lease it has. If the lease expires before the DHCP service is restored, the client should lose its IP address, and continue to periodically broadcast DHCP requests until it receives a response. Anyone feel free to correct me. Todd Wasielewski wrote: > I've been researching DHCP for three days and still don't have an answer to > my question. > > I have a windows95 machine running microsofts DHCP client. I have an NT > server running the DHCP server. My lease is for 3 months. > > My question is; I turn on my PC and obtain an IP address. I turn off the > DHCP server, I still have that DHCP address until the lease expires correct? > Now the DHCP server is still off. I shutdown my windows95 PC with the 3 > month lease and turn it off. When I turn the PC on should I or should I > not have a valid IP address on it for imediate use? I say no because the > DHCP server is down and everytime the client starts it needs to talk with a > DHCP server. -- )|( (o o) ------------------------------ooO-(_)-Ooo------------------------------ Michael Schneider Sr. Network Engineer grimkirk@home.com McKessonHBOC at Evanston Hospital http://wwp.mirabilis.com/1954898 ICQ UIN: 1954898 -------------------------------oo0---0oo------------------------------- From owner-dhcp-v4@bucknell.edu Thu Feb 24 23:45: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 XAA18845 for ; Thu, 24 Feb 2000 23:45:20 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id XAA01948; Thu, 24 Feb 2000 23:44:39 -0500 (EST) Received: from web704.mail.yahoo.com (web704.mail.yahoo.com [128.11.23.24]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id XAA29011 for ; Thu, 24 Feb 2000 23:44:21 -0500 (EST) Received: (qmail 15295 invoked by uid 60001); 25 Feb 2000 04:44:12 -0000 Message-ID: <20000225044412.15294.qmail@web704.mail.yahoo.com> Received: from [63.10.229.23] by web704.mail.yahoo.com; Thu, 24 Feb 2000 20:44:12 PST Date: Thu, 24 Feb 2000 20:44:12 -0800 (PST) From: Cody Smith Subject: Re: DHCP client To: DHCPv4 discussion list MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Reply-To: samiams_knapsack@yahoo.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Mr.Schneider is exactly right in what he said, but there is more. If a DHCP client is leased an IP address for a certain time period that client will keep the DHCP configuration information in its registry. If upon startup the DHCP client does not recieve a reply to its DHCPrequest message which is sent out everytime the computer is restarted, it will still hold the original lease in its registry. When 50% of the lease time expires the DHCP client will request a DHCP lease renewal directly from the originating DHCP server. When it cant find a DCHP server it will keep on sending out DHCPrequest messages directly to the server from where the lease was first obtained, in certain specified intervals which are as follows: 4 DHCPrequest messages in the first 5 minutes of startup, and 1 DHCPrequest message every 5 minutes thereafter. When the 87.5% of the clients lease has expired, and the DHCP client still cannot find the originating DHCP server is will send out a DHCPdiscover message which will basically broadcast to every DHCP server on the subnet if there is more than one DHCP server. Keep in mind while all this is happening the client still holds on to that valid TCP/IP configuration(including a valid IP address) in the registry. So basically your DHCP client computer will have a valid IP address untill the lease expires, but it will not be able to participate in a TCP/IP session. Cody Smith Network Administrator US Army FT. Lewis, WA 98433 ===== The only good is knowledge, and the only evil ignorance. -Socrates __________________________________________________ Do You Yahoo!? Talk to your friends online with Yahoo! Messenger. http://im.yahoo.com From owner-dhcp-v4@bucknell.edu Fri Feb 25 12:21:01 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 MAA15142 for ; Fri, 25 Feb 2000 12:21:01 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id MAA06493; Fri, 25 Feb 2000 12:20:34 -0500 (EST) Received: from ns4.sony.co.jp (ns4.Sony.CO.JP [202.238.80.4]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id MAA02711 for ; Fri, 25 Feb 2000 12:20:17 -0500 (EST) From: fujisawa@sm.sony.co.jp Received: from mail3.sony.co.jp (gatekeeper7.Sony.CO.JP [202.238.80.21]) by ns4.sony.co.jp (02/04/00) with ESMTP id CAA95550; Sat, 26 Feb 2000 02:20:10 +0900 (JST) Received: from smail2.sm.sony.co.jp (smail2.sm.sony.co.jp [43.16.1.128]) by mail3.sony.co.jp (3.7W99051310c) with ESMTP id CAA27376; Sat, 26 Feb 2000 02:20:09 +0900 (JST) Received: from rdmail.sm.sony.co.jp (root@xserver.sm.sony.co.jp [43.16.63.219]) by smail2.sm.sony.co.jp (8.8.8/3.6W) with ESMTP id CAA27583; Sat, 26 Feb 2000 02:18:23 +0900 (JST) Received: from fujiken.sm.sony.co.jp (fujiken.sm.sony.co.jp [43.16.63.177]) by rdmail.sm.sony.co.jp (8.8.8/3.6W-09/08/98) with ESMTP id CAA22149; Sat, 26 Feb 2000 02:18:08 +0900 (JST) Received: from localhost by fujiken.sm.sony.co.jp (8.8.8/6.4J.6/K) id CAA12832; Sat, 26 Feb 2000 02:18:12 +0900 (JST) Message-Id: <200002251718.CAA12832@fujiken.sm.sony.co.jp> To: DHCPv4 discussion list Cc: Thomas Narten , Erik Nordmark Subject: draft-ietf-ip1394-dhcp-03.txt Date: Sat, 26 Feb 2000 02:18:11 +0900 Sender: owner-dhcp-v4@bucknell.edu Reply-To: fujisawa@sm.sony.co.jp X-Sender: fujisawa@sm.sony.co.jp X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Hi all, I submitted a revised draft of 'DHCP for IEEE 1394' according to the comments from Area Directors. It will be available in the I-D directories shortly. Change Notes (02 to 03) * addtion of Security Considerations * addtion of Copyright Notice * one minor technical change EUI-64 client identifier of 1394 client becomes 'SHOULD' option. * several editorial fixes Best Regards, Kenji Fujisawa From owner-dhcp-v4@bucknell.edu Fri Feb 25 12:58: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 MAA15980 for ; Fri, 25 Feb 2000 12:58:27 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id MAA25597; Fri, 25 Feb 2000 12:56:57 -0500 (EST) Received: from lespaul.process.com (lespaul.process.com [192.42.95.27]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id MAA02898; Fri, 25 Feb 2000 12:55:38 -0500 (EST) Received: by lespaul.process.com with Internet Mail Service (5.5.2650.21) id ; Fri, 25 Feb 2000 12:54:33 -0500 Message-ID: <63D30D6E10CFD11190A90000F805FE860248BD21@lespaul.process.com> From: Bernie Volz To: DHCPv4 discussion list Cc: "'robs@join.com'" , "'volz@alcor.process.com'" , "'droms@bucknell.edu'" , "'grabil@lucent.com'" , "'mellon@isc.org'" , "'dhcp-v4@bucknell.edu'" Subject: RE: DHCP Load balancing draft addition Date: Fri, 25 Feb 2000 12:54:32 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Reply-To: Volz@process.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Why is the wording such that it would appear to prohibit a server from using any stored information if the secs field is non-zero? Shouldn't it be allowable to use either the secs field from the packet AND / OR "stored" information about the time since the first request from that client? Why not just simplify the text to say: a) A DHCP Server MAY do this. b) A DHCP Server SHOULD use either the value in the secs AND / OR "stored" information about the time since the first request from that client? A discussion that the secs field may be sufficient because some clients don't set it correctly would be useful (BTW, I have seen some cases where either the packet probe reported or the client set the secs field incorrectly - looked like a byte ordering issue). The advantage to having the server "store" information is that it is potentially more accurate. The disadvantages are the expensive of doing it and the server may not have received all the packets (I think some relay agents are able to do forwarding based on the secs field value as well and hence may not forward to the "backup" server until some time has already elapsed). So the combined method is actually the most desireable. To summarize, I have no problem with the general concept though I would encourage slight revisions to the wording. - Bernie -----Original Message----- From: Steve Gonczi [mailto:Gonczi@process.com] Sent: Thursday, February 24, 2000 6:52 PM To: 'kkinnear@cisco.com' Cc: 'robs@join.com'; 'volz@alcor.process.com'; 'droms@bucknell.edu'; 'grabil@lucent.com'; 'mellon@isc.org'; 'dhcp-v4@bucknell.edu' Subject: DHCP Load balancing draft addition Greetings, I have new words (kindly contributed by Ted Lemon) that I would like to add to the DHC load balancing draft. The net effect is to ALLOW a bias (in addition to the hard yes/no) approach. If a server implements this unilaterally, in a worst case scenario we may get a few extra offers under heavy load. I would like to remind you all, the load balancing only affects NEW leases. Please share your thougths! Here is the text: DHCP server implementations may optionally be configurable to handle a case where load balancing is being done but where one DHCP server is not available, and the other is. DHCP server implementations that provide this capability SHOULD have a configuration parameter that states the number of seconds to wait after the client's first request has been sent before responding to a client whose hash would not normally permit the client to be served. A DHCP server providing this capability SHOULD use the value in the secs field of the client request if its value is not zero. Because some clients may not correctly implement the secs field, a DHCP server MAY keep track of the first instance of a client transaction to which it would not normally respond. If the server receives a request from a client that has the same transaction ID as a previously recorded request, and if the secs field in the second packet is zero, the DHCP server MAY use the time in seconds between receipt of the first client request and the receipt of the subsequent client request in place of the secs field in order to determine whether or not to respond. From owner-dhcp-v4@bucknell.edu Mon Feb 28 18:29: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 SAA23356 for ; Mon, 28 Feb 2000 18:29:45 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id SAA19571; Mon, 28 Feb 2000 18:29:14 -0500 (EST) Received: from mail-out1.apple.com (mail-out1.apple.com [17.254.0.52]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id SAA03910 for ; Mon, 28 Feb 2000 18:28:45 -0500 (EST) Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out1.apple.com (8.9.3/8.9.3) with ESMTP id PAA25363 for ; Mon, 28 Feb 2000 15:28:43 -0800 (PST) Received: from scv1.apple.com (scv1.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.1.5) with ESMTP id for ; Mon, 28 Feb 2000 15:28:16 -0800 Received: from [17.201.23.37] (chesh1.apple.com [17.201.23.37]) by scv1.apple.com (8.9.3/8.9.3) with SMTP id PAA20324 for ; Mon, 28 Feb 2000 15:28:15 -0800 (PST) Message-Id: <200002282328.PAA20324@scv1.apple.com> Subject: RE: DHCP Domain Name Date: Mon, 28 Feb 2000 15:28:16 -0800 x-sender: cheshire@mail.apple.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Stuart Cheshire To: DHCPv4 discussion list Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Reply-To: cheshire@apple.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN >option 15 is NOT the "Fully-Qualified Domain Name (FQDN)" >because it lacks the hostname portion (carried in option 12).... > >it should be considered the string to be appended to the hostname >portion (option 12), with a period (.) inserted between the two.... Sadly, this answer left me more confused than before I asked the question. I'll try again, limiting myself to binary questions this time. 1. If I want to specify one or more search domains that the client should try for unqualified DNS name lookups (i.e. the equivalent of the "search" directive in /etc/resolv.conf) is option 15 the correct option? [YES] / [NO] 2. If yes, is the name fully qualified? (I already know that it is NOT a HOST name -- that's not what I'm asking. It is the name of a domain within which the client should search. Is it the fully qualified name of that domain, or can it be relative to something else?) [Fully qualified] / [Relative] 3. If fully qualified, is the name supposed to end with a dot, like other fully qualified names are supposed to (but rarely do)? [YES] / [NO] Stuart Cheshire * Web Page * Wizard Without Portfolio, Apple Computer From owner-dhcp-v4@bucknell.edu Mon Feb 28 19:08: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 TAA24050 for ; Mon, 28 Feb 2000 19:08:50 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id TAA15542; Mon, 28 Feb 2000 19:08:08 -0500 (EST) Received: from mail-out2.apple.com (mail-out2.apple.com [17.254.0.51]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id TAA02650 for ; Mon, 28 Feb 2000 19:07:48 -0500 (EST) Received: from mailgate2.apple.com (A17-129-100-225.apple.com [17.129.100.225]) by mail-out2.apple.com (8.9.3/8.9.3) with ESMTP id QAA04973 for ; Mon, 28 Feb 2000 16:05:58 -0800 (PST) Received: from scv3.apple.com (scv3.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 2.0.15) with ESMTP id for ; Mon, 28 Feb 2000 16:05:49 -0800 Received: from [17.201.23.37] (chesh1.apple.com [17.201.23.37]) by scv3.apple.com (8.9.3/8.9.3) with SMTP id QAA17085 for ; Mon, 28 Feb 2000 16:05:47 -0800 (PST) Message-Id: <200002290005.QAA17085@scv3.apple.com> Subject: Re: DHCP Domain Name Date: Mon, 28 Feb 2000 16:05:47 -0800 x-sender: cheshire@mail.apple.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Stuart Cheshire To: DHCPv4 discussion list MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Reply-To: cheshire@apple.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN >> 1. If I want to specify one or more search domains that the client >> should try for unqualified DNS name lookups (i.e. the equivalent of >> the "search" directive in /etc/resolv.conf) is option 15 the correct >> option? >> >> [YES] / [NO] > >No. The DHCP protocol currently provides no mechanism for the server >to hand this information to the client. It must be configured directly >on the client. > >Mark Sirota, Technical Lead, Network Systems and Services >University of Pennsylvania, Information Systems and Computing >msirota@isc.upenn.edu, 215/573-7214 >option 15 is the name of the domain of which the host is a member, but >is unrelated to the domain name(s) that should be searched by the host Well, that sucks. One more thing that Mac OS has been doing wrong for all these years. (Why does RFC 2132 say, "This option specifies the domain name that client should use when resolving hostnames..."? It seems like there is a missing "does not" in that sentence.) Stuart Cheshire * Web Page * Wizard Without Portfolio, Apple Computer