From owner-dhcp-v6@bucknell.edu Mon Jan 3 14:59: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 OAA06692 for ; Mon, 3 Jan 2000 14:59:02 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id OAA09273; Mon, 3 Jan 2000 14:53:59 -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 OAA09440 for ; Mon, 3 Jan 2000 14:53:45 -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 MAA18676 for ; Mon, 3 Jan 2000 12:53:40 -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 LAA16623 for ; Mon, 3 Jan 2000 11:53:38 -0800 (PST) Received: from bobo (bobo.Eng.Sun.COM [129.146.86.130]) by jurassic.eng.sun.com (8.9.3+Sun/8.9.3) with SMTP id LAA27835 for ; Mon, 3 Jan 2000 11:53:39 -0800 (PST) Date: Mon, 3 Jan 2000 11:53:39 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: DHCPv6 and multiple servers To: In-Reply-To: "Your message with ID" <386253A0.2B538CB7@iprg.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN > If somebody in the future can manage to devise a platform that can > realistically use multiple DHCP servers for a single network interface, > and the existing protocol does not suffer harm, why do we need to make > any specification about whether or not such a future platform does > such a thing? Why do we need to specify how the client resolves > the answers? Why do we need to explain the client's motivation? In the future I suspect there will be a DHCPv6 server to server protocol for failover and presumably load balancing. If I build a DHCPv6 client which asks multiple servers today using the same identifying information (link local address and relay subnet prefix), wouldn't there be a risk of the client failing when the servers are connected using a server to server protocol? My point is that it isn't trivial to have a future-proof client implementation talking to multiple servers. I don't know what the WG wants to do about this problem. A few possibilities: 1. Declare it out of scope and make that explicit in the document. 2. Specify in the document any known issues when a client on a single interface talks to multiple servers. 3. Work out how things could function in a server-server environment by defining what the client gets back (an error or something else) when it contacts a second server which is synchronized with the first server it talked to. Erik From owner-dhcp-v4@bucknell.edu Mon Jan 3 19:39: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 TAA09493 for ; Mon, 3 Jan 2000 19:39:41 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id TAA04157; Mon, 3 Jan 2000 19:37: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 TAA28137 for ; Mon, 3 Jan 2000 19:37:45 -0500 (EST) Received: by lespaul.process.com with Internet Mail Service (5.5.2650.21) id ; Mon, 3 Jan 2000 19:37:15 -0500 Message-ID: <63D30D6E10CFD11190A90000F805FE86023C94E8@lespaul.process.com> From: Steve Gonczi To: Cc: "'dhcp-v4@bucknell.edu'" Subject: RE: POOLREQ proposal for failover Date: Mon, 3 Jan 2000 19:37:13 -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 Cheers, I have re-read your proposal. I do not seem to be very good at communicating these days... I still believe that maintaining an ownership flag, independent of the lease status is a better way to go. You have proposed to scan the partner server's available leases, and attempt to grab some of those that were recently used by clients that the current server is configured to support. If you maintain 'steady' ownership, this naturally occurs. (The leases that you gave out before, went to clients that you are configured to support. And, they are still yours...;-) Why do you consider this complicated to implement? Your analysis of client not being able to get a lease from server 'A' because 'A' is out of leases, and being out of luck with server 'B' because 'B' is not configured to support this client was excellent. This problem needs to be addressed. I believe the cheapest way to address it is either a) Alter the load balancing draft, so that is prescribes a bias instead of a mandate. (Allow a server to respond even if the hash value sys no, after so many seconds elapsed...perhaps based on the secs field) b) When the above described condition occurs, make one address transfer request. I.e.: The backup server can not give a lease to a client it is supposed to serve, and the primary has a suitable address available. When this specific condition occurs, the backup server could attempt to obtain the address in question via a BNDUPD. sG From owner-dhcp-v4@bucknell.edu Wed Jan 5 10:24:18 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07542 for ; Wed, 5 Jan 2000 10:24:16 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id KAA00703; Wed, 5 Jan 2000 10:22:06 -0500 (EST) Received: from codex.cis.upenn.edu (CODEX.CIS.UPENN.EDU [158.130.6.15]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id KAA30600 for ; Wed, 5 Jan 2000 10:21:49 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by codex.cis.upenn.edu (8.8.5/8.8.5) with SMTP id KAA07413 for ; Wed, 5 Jan 2000 10:21:48 -0500 (EST) Date: Wed, 5 Jan 2000 10:21:48 -0500 (EST) From: "William A. Arbaugh" To: Subject: Continuation option Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: waa@dsl.cis.upenn.edu Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN All, FYI: Angelos and I have re-issued the continuation option given one draft now refers to it (Gupta) and we had one request on the list. I hope to get the new authentication draft out soon so if you still have comments- this is your last chance to have them incorporated in the latest draft. Bill ----------------------------------------------------------------------- Bill Arbaugh email: waa@dsl.cis.upenn.edu web: http://www.cis.upenn.edu/~waa ----------------------------------------------------------------------- From owner-dhcp-v4@bucknell.edu Wed Jan 12 00:26: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 AAA27842 for ; Wed, 12 Jan 2000 00:26:22 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id AAA20289; Wed, 12 Jan 2000 00:24:52 -0500 (EST) Received: from mail.ptd.net (mail1.ha-net.ptd.net [207.44.96.65]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id AAA02957 for ; Wed, 12 Jan 2000 00:24:23 -0500 (EST) Received: (qmail 631 invoked from network); 12 Jan 2000 05:23:58 -0000 Received: from host22.bvtc.ptd.net (HELO portable2) (209.173.2.22) by mail.ptd.net with SMTP; 12 Jan 2000 05:23:58 -0000 Message-Id: <4.2.2.20000112002047.00a778f0@mail.bucknell.edu> X-Sender: droms@mail.bucknell.edu X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Wed, 12 Jan 2000 00:22:30 -0500 To: From: Ralph Droms Subject: I-D ACTION:draft-ietf-dhc-options-cont-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 Continuation Option Code Author(s) : W. Arbaugh, A. Keromytis Filename : draft-ietf-dhc-options-cont-01.txt Pages : 3 Date : 03-Jan-00 The Dynamic Host Configuration Protocol (DHCP) provides a framework for passing configuration information to hosts on a TCP/IP network. Currently options are limited to an information size of 256 bytes because of the one-octet size of the length field. This document defines a new option that permits the continuation of the previous option information. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-options-cont-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-options-cont-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-options-cont-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: <20000103095610.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-options-cont-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-options-cont-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000103095610.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-dhcp-v4@bucknell.edu Wed Jan 12 00:29: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 AAA27854 for ; Wed, 12 Jan 2000 00:29:22 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id AAA11895; Wed, 12 Jan 2000 00:29:13 -0500 (EST) Received: from mail.ptd.net (mail1.ha-net.ptd.net [207.44.96.65]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id AAA22946 for ; Wed, 12 Jan 2000 00:24:24 -0500 (EST) Received: (qmail 726 invoked from network); 12 Jan 2000 05:24:00 -0000 Received: from host22.bvtc.ptd.net (HELO portable2) (209.173.2.22) by mail.ptd.net with SMTP; 12 Jan 2000 05:24:00 -0000 Message-Id: <4.2.2.20000112002050.00a826b0@mail.bucknell.edu> X-Sender: droms@mail.bucknell.edu X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Wed, 12 Jan 2000 00:21:30 -0500 To: From: Ralph Droms Subject: The Name Service Search Option for DHCP to WG last call 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 Carl Smith has submitted a revised version of "The Name Service Search Option for DHCP" (draft-ietf-dhc-nsso-02.txt). As agreed at the most recent DHC WG meeting, this draft is ready for WG last call, prior to submission for acceptance as a "Proposed Standard". If you have any final comments about this draft prior to submission, please respond to dhcp-v4@bucknell.edu before Wedenesday, 1/19/00. - Ralph Droms DHC WG chair From owner-dhcp-v4@bucknell.edu Wed Jan 12 00:29: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 AAA27865 for ; Wed, 12 Jan 2000 00:29:29 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id AAA28476; Wed, 12 Jan 2000 00:29:22 -0500 (EST) Received: from mail.ptd.net (mail1.ha-net.ptd.net [207.44.96.65]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id AAA00430 for ; Wed, 12 Jan 2000 00:24:25 -0500 (EST) Received: (qmail 744 invoked from network); 12 Jan 2000 05:24:00 -0000 Received: from host22.bvtc.ptd.net (HELO portable2) (209.173.2.22) by mail.ptd.net with SMTP; 12 Jan 2000 05:24:00 -0000 Message-Id: <4.2.2.20000112002050.00a86d90@mail.bucknell.edu> X-Sender: droms@mail.bucknell.edu X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Wed, 12 Jan 2000 00:21:26 -0500 To: From: Ralph Droms Subject: I-D ACTION:draft-ietf-dhc-nsso-02.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 Name Service Search Option for DHCP Author(s) : C. Smith Filename : draft-ietf-dhc-nsso-02.txt Pages : 4 Date : 04-Jan-00 This document defines a new DHCP option which is passed from the DHCP Server to the DHCP Client to specify the order in which name services should be consulted when resolving hostnames and other information. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-nsso-02.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-nsso-02.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-nsso-02.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: <20000104103116.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-nsso-02.txt From owner-dhcp-v4@bucknell.edu Wed Jan 12 08:38:52 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15588 for ; Wed, 12 Jan 2000 08:38:52 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id IAA14356; Wed, 12 Jan 2000 08:38:26 -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 IAA23691; Wed, 12 Jan 2000 08:38:13 -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 FAA24931; Wed, 12 Jan 2000 05:32:49 -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 IAA13268; Wed, 12 Jan 2000 08:37:54 -0500 (EST) Message-Id: <200001121337.IAA13268@grosse.manhattan.fugue.com> To: cc: dhcp-v4@bucknell.edu Subject: Re: I-D ACTION:draft-ietf-dhc-nsso-02.txt In-Reply-To: Message from Ralph Droms of "Wed, 12 Jan 2000 00:21:26 EST." <4.2.2.20000112002050.00a86d90@mail.bucknell.edu> Date: Wed, 12 Jan 2000 08:37:54 -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 > In the above example, ns1 & ns2 are 16-bit integers corresponding to > the name service servers option (this allows for evolution without > the need for a separate table translating between these integers and > the name services they represent). For example, the current list, > taken from RFC 2132, includes I just read the draft, and I find the above wording somewhat confusing. What does "corresponding to the name service servers option" mean? I can figure it out from context, but this sentence fragment is confusing. I'd suggest the following paragraph instead: > In the above diagram, ns1 and ns2 are 16-bit integers corresponding to > two DHCP options that specify the IP addresses of two different types > of name server. The current list of name services and their DHCP > option codes, as enumerated in RFC 2132, includes: > > [...] > Other than this nit, the draft looks fine. I'd like to see the wording changed before it goes to PS, and I'm sorry for not bringing this up prior to the latest revision. I hope that it's a small enough change that it can be made without causing too much heartburn. _MelloN_ From owner-dhcp-v4@bucknell.edu Wed Jan 12 08:57: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 IAA16051 for ; Wed, 12 Jan 2000 08:57:54 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id IAA14110; Wed, 12 Jan 2000 08:57:44 -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 IAA21675; Wed, 12 Jan 2000 08:57:29 -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 FAA24969; Wed, 12 Jan 2000 05:52:06 -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 IAA13299; Wed, 12 Jan 2000 08:57:11 -0500 (EST) Message-Id: <200001121357.IAA13299@grosse.manhattan.fugue.com> To: cc: dhcp-v4@bucknell.edu Subject: Re: I-D ACTION:draft-ietf-dhc-options-cont-01.txt In-Reply-To: Message from Ralph Droms of "Wed, 12 Jan 2000 00:22:30 EST." <4.2.2.20000112002047.00a778f0@mail.bucknell.edu> Date: Wed, 12 Jan 2000 08:57:10 -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 would suggest that after the second diagram in the continuation option draft, the following wording be added: The continuation option for an option must appear immediately following that option. If the sname and filename buffers in the DHCP packet are being used in combination with the Overload option, the sname buffer should be considered to immediately follow the main option buffer, and the filename buffer should be considered to immediately follow the sname buffer. It is permissible to use multiple continuation options with lengths shorter than 255 in order to fit a continued option into these buffers. In addition, I'm worried about what happens if a DHCP client uses a continuation option when sending a packet to a DHCP server that doesn't support it, or vice versa. It seems like this could cause trouble. I'm not sure whether the right thing is to specify a negotiation here, or to simply anticipate that options with payloads large enough to require the continuation option should not be implemented at all unless the continuation option is also implemented. I also think this option introduces some serious complexity, and I'm not sure what the benefit is. If we accept that this should only be used for options that require its implementation, then why not just have those options specify that multiple occurrances of the same option should be concatenated? _MelloN_ From owner-dhcp-v4@bucknell.edu Wed Jan 12 10:45:53 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17992 for ; Wed, 12 Jan 2000 10:45:49 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id KAA31697; Wed, 12 Jan 2000 10:44:48 -0500 (EST) Received: from codex.cis.upenn.edu (CODEX.CIS.UPENN.EDU [158.130.6.15]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id KAA07774 for ; Wed, 12 Jan 2000 10:44:44 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by codex.cis.upenn.edu (8.8.5/8.8.5) with SMTP id KAA14872; Wed, 12 Jan 2000 10:44:33 -0500 (EST) Date: Wed, 12 Jan 2000 10:44:33 -0500 (EST) From: "William A. Arbaugh" To: cc: dhcp-v4@bucknell.edu Subject: Re: I-D ACTION:draft-ietf-dhc-options-cont-01.txt In-Reply-To: <200001121357.IAA13299@grosse.manhattan.fugue.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: waa@dsl.cis.upenn.edu Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN On Wed, 12 Jan 2000, Ted Lemon wrote: > ... > ... then why not just > have those options specify that multiple occurrances of the same > option should be concatenated? > This is the behavior that Ted's code uses, and the right approach in my opinion (rather than the continutation option). I'm more than willing to withdraw the option draft in favor of what Ted has proposed. But, we need to do something to support large options if we want to support public key based authentication. Bill From owner-dhcp-v4@bucknell.edu Wed Jan 12 13:54:14 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21875 for ; Wed, 12 Jan 2000 13:54:12 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id NAA17675; Wed, 12 Jan 2000 13:53:28 -0500 (EST) Received: from gidget.incognito.com (GIDGET.INCOGNITO.COM [207.102.214.80]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id NAA26344 for ; Wed, 12 Jan 2000 13:53:04 -0500 (EST) Received: by GIDGET.INCOGNITO.COM with Internet Mail Service (5.5.2650.21) id ; Wed, 12 Jan 2000 10:54:02 -0800 Message-ID: <716D440F8C29D311991100A0C920487423D9FC@GIDGET.INCOGNITO.COM> From: "Kostur, Andre" To: Subject: RE: I-D ACTION:draft-ietf-dhc-options-cont-01.txt Date: Wed, 12 Jan 2000 10:54:01 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Reply-To: Andre@incognito.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN On a somewhat related note, do the order of DHCP options within a DHCP packet matter? As for the topic at hand, I'd voice my support for merely specifying the DHCP option multiple times and concatenate the results to get the final large option. Besides, I somehow recall that one of the NDS options does exactly this. OK, I just looked it up, and.. see RFC 2241, page 3. And, looking at it a little closer, it refers back into the DHCP RFC regarging overlarge options. See RFC 2131, page 24. Are we looking at specifying a new RFC for something that's already covered in the existing RFC? Or am I missing some implementation detail that the new RFC covers? -----Original Message----- From: William A. Arbaugh [mailto:waa@dsl.cis.upenn.edu] Sent: Wednesday, January 12, 2000 07:45 To: dhcp-v4@bucknell.edu Cc: dhcp-v4@bucknell.edu Subject: Re: I-D ACTION:draft-ietf-dhc-options-cont-01.txt On Wed, 12 Jan 2000, Ted Lemon wrote: > ... > ... then why not just > have those options specify that multiple occurrances of the same > option should be concatenated? > This is the behavior that Ted's code uses, and the right approach in my opinion (rather than the continutation option). I'm more than willing to withdraw the option draft in favor of what Ted has proposed. But, we need to do something to support large options if we want to support public key based authentication. Bill From owner-dhcp-v4@bucknell.edu Wed Jan 12 14:05:24 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22090 for ; Wed, 12 Jan 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 OAA01442; Wed, 12 Jan 2000 14:05:07 -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 OAA10901 for ; Wed, 12 Jan 2000 14:04:56 -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 KAA25915; Wed, 12 Jan 2000 10:59:29 -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 OAA14169; Wed, 12 Jan 2000 14:04:33 -0500 (EST) Message-Id: <200001121904.OAA14169@grosse.manhattan.fugue.com> To: cc: dhcp-v4@bucknell.edu Subject: Re: I-D ACTION:draft-ietf-dhc-options-cont-01.txt In-Reply-To: Message from "Kostur, Andre" of "Wed, 12 Jan 2000 10:54:01 PST." <716D440F8C29D311991100A0C920487423D9FC@GIDGET.INCOGNITO.COM> Date: Wed, 12 Jan 2000 14:04:33 -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 > On a somewhat related note, do the order of DHCP options within a DHCP > packet matter? Not according to any standard of which I'm aware. However, if two options are to be concatenated, I suppose it does. > See RFC 2131, page 24. Actually, it's page 23, but I think the wording here is quite clear, and you're right - this obviates the need for a continuation option. I think we should drop this, and it sounds like you and Bill agree. _MelloN_ From owner-dhcp-v4@bucknell.edu Mon Jan 17 06:42: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 GAA29579 for ; Mon, 17 Jan 2000 06:41:59 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id GAA05647; Mon, 17 Jan 2000 06:41:12 -0500 (EST) Received: from mail.ptd.net (mail2.ha-net.ptd.net [207.44.96.66]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id GAA16593 for ; Mon, 17 Jan 2000 06:40:40 -0500 (EST) Received: (qmail 9797 invoked from network); 17 Jan 2000 11:40:19 -0000 Received: from host22.bvtc.ptd.net (HELO portable2) (209.173.2.22) by mail.ptd.net with SMTP; 17 Jan 2000 11:40:19 -0000 Message-Id: <4.2.2.20000115202059.00a58640@mail.bucknell.edu> X-Sender: droms@mail.bucknell.edu X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Sat, 15 Jan 2000 20:22:37 -0500 To: From: Ralph Droms Subject: Re: I-D ACTION:draft-ietf-dhc-options-cont-01.txt Cc: dhcp-v4@bucknell.edu In-Reply-To: <200001121904.OAA14169@grosse.manhattan.fugue.com> References: <716D440F8C29D311991100A0C920487423D9FC@GIDGET.INCOGNITO.COM> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Reply-To: droms@bucknell.edu Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN At 02:04 PM 1/12/00 -0500, Ted Lemon wrote: > > On a somewhat related note, do the order of DHCP options within a DHCP > > packet matter? > >Not according to any standard of which I'm aware. However, if two >options are to be concatenated, I suppose it does. > > > See RFC 2131, page 24. > >Actually, it's page 23, but I think the wording here is quite clear, >and you're right - this obviates the need for a continuation option. >I think we should drop this, and it sounds like you and Bill agree. OK, we'll consider this draft to be no longer operative, and that text allowing multiple occurrences will be added to authentication options that require roe than 255 octets. - Ralph From owner-dhcp-v4@bucknell.edu Tue Jan 18 21:35:03 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08747 for ; Tue, 18 Jan 2000 21:35:02 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id VAA09458; Tue, 18 Jan 2000 21:34:19 -0500 (EST) Received: from mail.ptd.net (mail2.ha-net.ptd.net [207.44.96.66]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id VAA11892 for ; Tue, 18 Jan 2000 21:33:43 -0500 (EST) Received: (qmail 19375 invoked from network); 19 Jan 2000 02:33:23 -0000 Received: from host22.bvtc.ptd.net (HELO droms-laptop) (209.173.2.22) by mail.ptd.net with SMTP; 19 Jan 2000 02:33:23 -0000 Message-Id: <4.2.2.20000118212900.00a5f6c0@mail.bucknell.edu> X-Sender: droms@mail.bucknell.edu X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Tue, 18 Jan 2000 21:30:17 -0500 To: From: "Hattig, Myron" (by way of Ralph Droms ) Subject: WG Last Call on DHCP document Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Reply-To: myron.hattig@intel.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN DHCPv4 WG members - we discussed this document at the IETF meeting in Oslo. Please review the revised document, keeping in mind the input from the DHC WG... - Ralph ===== This is the WG Last Call for the following document. http://www.ietf.org/internet-drafts/draft-ietf-ip1394-dhcp-02.txt This WG Last Call will end Jan 25th. Please provide comments to the author, Kenji Fujisawa, or to this mailing list. This document has already been discussed and reviewed by the DHC WG. This latest version include the authors response to those comments. Once WG Last Call completes. This document will be submitted to IESG for approval to become a Standards Track RFC and be considered an official DHCP Option. Best regards, Myron Hattig WG Co-Chair From owner-dhcp-v4@bucknell.edu Wed Jan 19 09: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 JAA28993 for ; Wed, 19 Jan 2000 09:07:28 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id JAA17726; Wed, 19 Jan 2000 09:06:53 -0500 (EST) Received: from droms-laptop (droms.eg.bucknell.edu [134.82.56.71]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id JAA14923; Wed, 19 Jan 2000 09:06:40 -0500 (EST) Message-Id: <4.2.2.20000119090515.00a85b40@mail.bucknell.edu> X-Sender: droms@mail.bucknell.edu X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Wed, 19 Jan 2000 09:05:44 -0500 To: From: Ralph Droms Subject: Re: The Name Service Search Option for DHCP to WG last call Cc: cheshire@apple.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Reply-To: droms@bucknell.edu Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Mail sent to dhcp-v4@bucknell.edu by cheshire@apple.com: >Carl Smith has submitted a revised version of "The Name Service Search >Option for DHCP" (draft-ietf-dhc-nsso-02.txt). As agreed at the most >recent DHC WG meeting, this draft is ready for WG last call, prior to >submission for acceptance as a "Proposed Standard". If you have any final >comments about this draft prior to submission, please respond to >dhcp-v4@bucknell.edu before Wedenesday, 1/19/00. The draft says: > A name service option code of 0 is used to indicate that the client > should refer to local configuration information. How is this different from merely omitting the Name Service Search Option from the DHCP OFFERs and ACKs? Surely, if there is no Name Service Search Option, then any client will refer to local configuration information anyway, as it does today. If an option code of 0 has identical effect to having no option at all, I propose that sentence be removed. Having two alternative ways of doing the same thing just makes testing more laborious and bugs more likely. Stuart Cheshire * Web Page * Wizard Without Portfolio, Apple Computer From owner-dhcp-v4@bucknell.edu Wed Jan 19 09:10: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 JAA29041 for ; Wed, 19 Jan 2000 09:10:38 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id JAA21442; Wed, 19 Jan 2000 09:09:16 -0500 (EST) Received: from droms-laptop (droms.eg.bucknell.edu [134.82.56.71]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id JAA15148; Wed, 19 Jan 2000 09:06:42 -0500 (EST) Message-Id: <4.2.2.20000119090551.00a517e0@mail.bucknell.edu> X-Sender: droms@mail.bucknell.edu X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Wed, 19 Jan 2000 09:06:27 -0500 To: From: Ralph Droms Subject: Help! Static route option Cc: cheshire@apple.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Reply-To: droms@bucknell.edu Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Mail sent to dhcpv4@bucknell.edu by cheshire@apple.com: A quick question. For the old DHCP Static Route Option (33) that has no mask, what is the effective mask supposed to be? Mac OS Open Transport currently uses a mask of all-ones, apparently in the assumption that a route without a mask must necessarily be a host route. I'm wondering if maybe the intention of the Static Route Option was that the mask should be derived programmatically from the class of the destination address, in the old sense of Class A, Class B, Class C. In other words, a route to destination 36.0.0.0 is assumed to have a /8 mask because it is a Class A address. However, what would you do if the destination were 36.17.23.194? That's a Class A address, but it has ones in the host part, so it can't possibly be a route to net 36/8. RFC 2132 doesn't provide any clarification on this. (I know Static Route Pption is due to be replaced by "Static routes with subnet masks option", but we'd still like to handle the old option in a sane way too.) Stuart Cheshire * Web Page * Wizard Without Portfolio, Apple Computer From owner-dhcp-v4@bucknell.edu Wed Jan 19 09:46: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 JAA29761 for ; Wed, 19 Jan 2000 09:46:40 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id JAA22809; Wed, 19 Jan 2000 09:46:07 -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 JAA29351 for ; Wed, 19 Jan 2000 09:45:59 -0500 (EST) Received: by process.com (MX V5.1-X A2w8g) id 32; Wed, 19 Jan 2000 09:45:21 -0400 Sender: owner-dhcp-v4@bucknell.edu Date: Wed, 19 Jan 2000 09:45:18 -0400 From: Bernie Volz To: Message-ID: <009E45EA.5BDF6CCC.32@process.com> Subject: RE: Help! Static route option Reply-To: volz@process.com X-Sender: volz@process.com X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Since this option goes back to the days of classful networking, it would be assumed that the mask associated with the destination is based on the class of the destination. I could see TWO interpretations of the destination's host part not being zero (based on the class mask): 1. Assume it is a HOST route. In this case, the mask would be 255.255.255.255. 2. Assume it is a NETWORK route. In this case, clear the host part. I believe (1) is the behavoir you are seeing and is probably the better behavoir since it allows both HOST and (classful) NETWORK routes to be communicated. - Bernie Volz Process Software --- Mail sent to dhcpv4@bucknell.edu by cheshire@apple.com: A quick question. For the old DHCP Static Route Option (33) that has no mask, what is the effective mask supposed to be? Mac OS Open Transport currently uses a mask of all-ones, apparently in the assumption that a route without a mask must necessarily be a host route. I'm wondering if maybe the intention of the Static Route Option was that the mask should be derived programmatically from the class of the destination address, in the old sense of Class A, Class B, Class C. In other words, a route to destination 36.0.0.0 is assumed to have a /8 mask because it is a Class A address. However, what would you do if the destination were 36.17.23.194? That's a Class A address, but it has ones in the host part, so it can't possibly be a route to net 36/8. RFC 2132 doesn't provide any clarification on this. (I know Static Route Pption is due to be replaced by "Static routes with subnet masks option", but we'd still like to handle the old option in a sane way too.) Stuart Cheshire * Web Page * Wizard Without Portfolio, Apple Computer From owner-dhcp-v4@bucknell.edu Wed Jan 19 11:25:14 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01437 for ; Wed, 19 Jan 2000 11:25:11 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id LAA26554; Wed, 19 Jan 2000 11:24:06 -0500 (EST) Received: from droms-laptop (droms.eg.bucknell.edu [134.82.56.71]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id LAA22374; Wed, 19 Jan 2000 11:23:38 -0500 (EST) Message-Id: <4.2.2.20000119112145.00a784e0@mail.bucknell.edu> X-Sender: droms@mail.bucknell.edu X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Wed, 19 Jan 2000 11:22:42 -0500 To: From: Ralph Droms Subject: Re: The Name Service Search Option for DHCP to WG last call Cc: Peter.Memishian@East.Sun.COM Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Reply-To: droms@bucknell.edu Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Peter Memishian wrote: > The draft says: > > > A name service option code of 0 is used to indicate that the client > > should refer to local configuration information. > > How is this different from merely omitting the Name Service Search Option > from the DHCP OFFERs and ACKs? Surely, if there is no Name Service Search > Option, then any client will refer to local configuration information > anyway, as it does today. > > If an option code of 0 has identical effect to having no option at all, I > propose that sentence be removed. but it is different, because you may wish to specify a list of name services which are visited in order. for instance, without code 0, how would the server specify that the client should first try dns, then local configuration, then nis? -- meem From owner-dhcp-v4@bucknell.edu Wed Jan 19 15:19:03 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04704 for ; Wed, 19 Jan 2000 15:18:57 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id PAA16946; Wed, 19 Jan 2000 15:15:32 -0500 (EST) Received: from photon.soltec.net (photon.soltec.net [206.148.208.27]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id PAA27563 for ; Wed, 19 Jan 2000 15:14:32 -0500 (EST) Received: from localhost (silent@localhost) by photon.soltec.net (8.8.8/8.8.9) with SMTP id OAA14773 for ; Wed, 19 Jan 2000 14:14:19 -0600 (CST) Date: Wed, 19 Jan 2000 14:14:18 -0600 (CST) From: Brian LaFlamme X-Sender: silent@photon To: Subject: help Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: silent@soltec.net Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN From owner-dhcp-v4@bucknell.edu Wed Jan 19 18:15: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 SAA06434 for ; Wed, 19 Jan 2000 18:15:43 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id SAA23979; Wed, 19 Jan 2000 18:13:23 -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 SAA19753; Wed, 19 Jan 2000 18:13:02 -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 PAA06701; Wed, 19 Jan 2000 15:06:59 -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 SAA15639; Wed, 19 Jan 2000 18:11:32 -0500 (EST) Message-Id: <200001192311.SAA15639@grosse.manhattan.fugue.com> To: cc: dhcp-v4@bucknell.edu, cheshire@apple.com Subject: Re: The Name Service Search Option for DHCP to WG last call In-Reply-To: Message from Ralph Droms of "Wed, 19 Jan 2000 09:05:44 EST." <4.2.2.20000119090515.00a85b40@mail.bucknell.edu> Date: Wed, 19 Jan 2000 18:11:32 -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 > How is this different from merely omitting the Name Service Search Option > from the DHCP OFFERs and ACKs? Surely, if there is no Name Service Search > Option, then any client will refer to local configuration information > anyway, as it does today. You may want to say "local, BIND, yp" or "bind, local, YP". 0 means local in this context. _MelloN_ From owner-dhcp-v4@bucknell.edu Wed Jan 19 18:17: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 SAA06445 for ; Wed, 19 Jan 2000 18:17:09 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id SAA00649; Wed, 19 Jan 2000 18:16:18 -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 SAA24071 for ; Wed, 19 Jan 2000 18:13:59 -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 PAA06706; Wed, 19 Jan 2000 15:08:08 -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 SAA15654; Wed, 19 Jan 2000 18:12:50 -0500 (EST) Message-Id: <200001192312.SAA15654@grosse.manhattan.fugue.com> To: cc: dhcp-v4@bucknell.edu Subject: Re: Help! Static route option In-Reply-To: Message from Bernie Volz of "Wed, 19 Jan 2000 09:45:18 -0400." <009E45EA.5BDF6CCC.32@process.com> Date: Wed, 19 Jan 2000 18:12:50 -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 think it would be a mistake to even implement the static route option at this point. I still owe the WG a classless static route option, which is what I would suggest you implement. *blush* _MelloN_ From owner-dhcp-v4@bucknell.edu Thu Jan 20 08:37:11 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27925 for ; Thu, 20 Jan 2000 08:37:10 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id IAA19807; Thu, 20 Jan 2000 08:36:21 -0500 (EST) Received: from uplink.net (marcie.uplink.net [209.173.80.3]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id IAA21057 for ; Thu, 20 Jan 2000 08:35:49 -0500 (EST) Received: from droms-laptop (pm3mi1-1.uplink.net [209.173.86.2]) by uplink.net (8.9.3/8.9.3) with ESMTP id IAA28412; Thu, 20 Jan 2000 08:35:44 -0500 (EST) Message-Id: <4.2.2.20000120074520.00a77d20@mail.bucknell.edu> X-Sender: droms@mail.bucknell.edu X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Thu, 20 Jan 2000 07:53:32 -0500 To: From: Ralph Droms Subject: RE: Help! Static route option In-Reply-To: <009E45EA.5BDF6CCC.32@process.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Reply-To: droms@bucknell.edu Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Interesting - I had always assumed 2 was right. But the text in RFC2132 doesn't give any hint, and both interpretations of RFC2132 are reasonable. Although this option is to be superceded by an option with explicit masks, we should come to consensus about an interpretation and modify the text in the next rev of RFC2132. - Ralph ===== At 09:45 AM 1/19/00 -0400, Bernie Volz wrote: >Since this option goes back to the days of classful networking, it >would be assumed that the mask associated with the destination is >based on the class of the destination. > >I could see TWO interpretations of the destination's host part not >being zero (based on the class mask): > >1. Assume it is a HOST route. In this case, the mask would be >255.255.255.255. > >2. Assume it is a NETWORK route. In this case, clear the host part. > >I believe (1) is the behavior you are seeing and is probably the >better behavior since it allows both HOST and (classful) NETWORK >routes to be communicated. > >- Bernie Volz > Process Software > From owner-dhcp-v4@bucknell.edu Thu Jan 20 08:39: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 IAA28065 for ; Thu, 20 Jan 2000 08:39:29 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id IAA21226; Thu, 20 Jan 2000 08:39:20 -0500 (EST) Received: from uplink.net (marcie.uplink.net [209.173.80.3]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id IAA17570 for ; Thu, 20 Jan 2000 08:38:48 -0500 (EST) Received: from droms-laptop (pm3mi1-1.uplink.net [209.173.86.2]) by uplink.net (8.9.3/8.9.3) with ESMTP id IAA29633 for ; Thu, 20 Jan 2000 08:38:46 -0500 (EST) Message-Id: <4.2.2.20000120083724.00a28d80@mail.bucknell.edu> X-Sender: droms@mail.bucknell.edu X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Thu, 20 Jan 2000 08:38:15 -0500 To: From: Ralph Droms Subject: I-D ACTION:draft-ietf-dhc-nextserver-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 : DHCP Next Server Option Author(s) : J. Privat, M. Borella Filename : draft-ietf-dhc-nextserver-00.txt Pages : 6 Date : 19-Jan-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-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-nextserver-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-nextserver-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: <20000119140436.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-nextserver-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-nextserver-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000119140436.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-dhcp-v4@bucknell.edu Thu Jan 20 12:12:46 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07693 for ; Thu, 20 Jan 2000 12:12:34 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id MAA32017; Thu, 20 Jan 2000 12:10:45 -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 MAA06695 for ; Thu, 20 Jan 2000 12:10:23 -0500 (EST) From: jerome.privat@bt.com Received: from cbtlipnt01.btlabs.bt.co.uk by marvin (local) with ESMTP; Thu, 20 Jan 2000 16:57:17 +0000 Received: by cbtlipnt01.btlabs.bt.co.uk with Internet Mail Service (5.5.2448.0) id ; Thu, 20 Jan 2000 16:58:09 -0000 Message-ID: <5104D4DBC598D211B5FE0000F8FE7EB2040872EA@mbtlipnt02.btlabs.bt.co.uk> To: Subject: RE: I-D ACTION:draft-ietf-dhc-nextserver-00.txt Date: Thu, 20 Jan 2000 16:58:01 -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 proposed option is pretty straightforward and can be used by a DHCP server to redirect a client to a secondary configuration server. If you have comments on the draft, please send them to the list. Thanks, Jerome Privat, BT -----Original Message----- From: Ralph Droms [mailto:droms@bucknell.edu] Sent: 20 January 2000 13:38 To: dhcp-v4 Subject: I-D ACTION:draft-ietf-dhc-nextserver-00.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-00.txt Pages : 6 Date : 19-Jan-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-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-nextserver-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-nextserver-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: <20000119140436.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-nextserver-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-nextserver-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000119140436.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-dhcp-v4@bucknell.edu Thu Jan 20 12:36: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 MAA08775 for ; Thu, 20 Jan 2000 12:36:44 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id MAA06424; Thu, 20 Jan 2000 12:34:40 -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 MAA07331; Thu, 20 Jan 2000 12:33:50 -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 JAA11884; Thu, 20 Jan 2000 09:27:55 -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 MAA19040; Thu, 20 Jan 2000 12:32:28 -0500 (EST) Message-Id: <200001201732.MAA19040@grosse.manhattan.fugue.com> To: cc: dhcp-v4@bucknell.edu Subject: Re: Help! Static route option In-Reply-To: Message from Ralph Droms of "Thu, 20 Jan 2000 07:53:32 EST." <4.2.2.20000120074520.00a77d20@mail.bucknell.edu> Date: Thu, 20 Jan 2000 12:32:28 -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 > Although this option is to be superceded by an option with explicit > masks, we should come to consensus about an interpretation and > modify the text in the next rev of RFC2132. Is there any reason not to just say it's deprecated? Whichever of the two choices is correct, the option is really not useful - at this juncture, it is sheer coincidence if the "class" subnet mask and the classless subnet mask are the same, and sheer coincidence is a lousy basis for network protocols. :') _MelloN_ From owner-dhcp-v6@bucknell.edu Fri Jan 21 06:07: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 GAA06569 for ; Fri, 21 Jan 2000 06:07:57 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id GAA32606; Fri, 21 Jan 2000 06:03:00 -0500 (EST) Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id GAA02343 for ; Fri, 21 Jan 2000 06:02:48 -0500 (EST) Received: from 157.54.9.100 by mail3.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 21 Jan 2000 03:02:13 -0800 (Pacific Standard Time) Received: by INET-IMC-03 with Internet Mail Service (5.5.2650.21) id ; Fri, 21 Jan 2000 03:02:13 -0800 Message-ID: <4D0A23B3F74DD111ACCD00805F31D8101EDBCBE3@RED-MSG-50> From: Richard Draves To: Subject: DHCPv6 comments Date: Fri, 21 Jan 2000 03:02:10 -0800 X-Mailer: Internet Mail Service (5.5.2650.21) 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 So I finally had time to read draft-ietf-dhc-dhcpv6-14.txt. I don't have access to the list archives at 30,000 feet, so forgive me if these are old issues. I'm going to send separate messages on the extensions draft and responding to Thomas's 12/23 "DHCPv6 address allocation model" email. This protocol is really different from DHCPv4 (from what I've seen of DHCPv4 in packet traces), too bad it doesn't have a different name. Making the relay explicit in the protocol introduces lots of complexity. Here's an idea: The relay should only participate in Solicit/Advertise messages. Once the client discovers server/relay addresses, the client and the server communicate directly with each other. If the client's link-local address is the IP source or destination and the server is off-link (relay address != server address), then a routing header is used to route the packet via the relay. This would simplify the protocol a lot. Among other things, the client and server could potentially use end-to-end IPsec instead of using one-off DHCPv6 security hacks. Some (fatal???) complications with this idea: - Routing header processing when the IP source is link-local. draft-ietf-ipngwg-icmp-v3-00.txt is unclear - should routing header processing generate the "beyond scope of source address" error? - IPsec operation in the server, with off-link link-local client addresses Another issue - servers don't have access to client link-layer addresses. Is the assumption that administrators will be happy to use link-local addresses instead as a good key to identify clients? Will administrators feel that they are losing something here? Misc specific comments (quotations from the draft are indented): 02 DHCP Advertise The DHCP Advertise is an IP unicast message sent by a DHCP Agent in response to a client's DHCP Solicit message. Why not allow for multicast Advertise messages, so when a lot of clients are booting one Advertise can suffice for them all, or least everyone on a link. (See ND Router Advertisements.) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | saved agent-address | | (if present, 16 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I finished reading the dhcpv6 draft and was in the middle of the extensions draft before I realized what "if present" meant. I thought at first that when a field was "not present" it was supposed to be sent as zeroes. I think I got confused because none of the other v6 protocols have optional fields like this in their headers. This could use more explanation. C If set, the client requests that all servers receiving the message deallocate the resources associated with the client. If set, the client SHOULD provide a saved agent-address to locate the clients binding by a server. Shouldn't this be MUST, since the C bit is controlling the presence of the agent-address field? This was also a source of my confusion about "if present". relay MUST NOT be a link-local address. In situations where there are no routers sending Router Advertisements, then a DHCP server MUST be configured on the same link as prospective clients. The DHCPv6 protocol design does not apply to situations where the client is unable to route messages to a server not on the same link. The last sentence does not convey the intended meaning. It is possible to use DHCPv6 when the client is unable to route messages to a server not on the same link, just put the DHCPv6 server on the same link as the client. If a client reboots and does not have a valid IP address, it SHOULD set the `C' bit in the DHCP Solicit message it sends when restarting. By setting the `C' bit in the solicitation, a client requests that all the DHCP servers that receive the solicitation should clean up their client records that match its link-local address. The client link-local address does not uniquely specify the client. If a client sends a DHCP Solicit message after it reboots, the solicitation SHOULD be delayed after reception of the first Router Advertisement [14] message (see section 5.8), by at least some random amount of time between MIN_SOLICIT_DELAY and MAX_SOLICIT_DELAY (see section 8). This delay is intended to help stagger requests to DHCP servers (and avoid link-layer collisions) after a power outage causes many nodes to reboot all at once. Each subsequent DHCP Solicit message that is issued before receiving an advertisement MUST be delayed by twice the amount by which the previous DHCP Solicit message was delayed, plus a small random delay between MIN_SOLICIT_DELAY and MAX_SOLICIT_DELAY seconds. Is there a limit to the number of retransmissions? A limit to the backoff? retransmit according to the rules in Section 8. If (after following those rules) the client has not received a Reply message, it SHOULD start over again by multicasting a new DHCP Solicit message to find a different server. What if the client already knows about other servers from its original solicit? 6.2. Sending DHCP Advertise Messages Upon receiving and verifying the correctness of a DHCP Solicit message, a server constructs a DHCP Advertise message and transmits it on the same link as the solicitation was received from. When the solicitation is received at the All-DHCP-Servers multicast address, the server SHOULD delay the transmission of its advertisement for a random amount of time between SERVER_MIN_ADV_DELAY and SERVER_MAX_ADV_DELAY (see section 8). So this delay is not done when the solicitation is received at the All-DHCP-Agents multicast address??? 7.2. DHCP Request Message Processing When a relay receives a DHCP Request message, it SHOULD check that the IP source address in the IP header is a link-local address, that the link-local address matches the link-local address field in Should the same checks be performed when a relay receives a DHCP Solicit? All of the fields of DHCP Request message transmitted by the relay are copied over unchanged from the DHCP Request received from the client. Only the fields in the IP header will differ from the packet received from the client. All relays MUST send DHCP Request And the UDP checksum will differ. 8. Retransmission and Configuration Variables When a client does not receive a DHCP Reply in response to a pending DHCP Request, the client MUST retransmit the identical DHCP Request, with the same transaction-ID, to the same server again until it can be reasonably sure that the server is unavailable and an alternative can be chosen. The DHCP server assumes that the client has received Unless N bit was set in a Reconfigure that caused the Request. The default settings for the parameters will cause perceptible delay in DHCPv6 address allocation relative to address auto-configuration. Can't they be tuned to make DHCP work faster in the common case? CLIENT_ADV_WAIT Why 2s? An analogous ND value (MAX_RTR_SOLICITATION_DELAY) is 1s. SERVER_MIN_ADV_DELAY / SERVER_MAX_ADV_DELAY Why 100ms / 1s? The analogous range for Router Advertisements is 0 / 500ms. Conflicting descriptions of which multicast addresses are relevant. REPLY_MSG_TIMEOUT / REQUEST_MSG_MIN_RETRANS So it will be ~ 1/2 hour before a client gives up and tries another server when it doesn't get a Reply to a Request??? RECONF_MMSG_MIN_RESP Why is this not zero? RECONF_MULTICAST_REQUEST_WAIT The time a client should wait before retransmitting a Request message in reponse to a retransmitted multicast Reconfigure message. This is a very confusing / incorrect description of this variable. MIN_SOLICIT_DELAY / MAX_SOLICIT_DELAY Why are these values so large compared to the analogous ND values? In general, why is the solicitation algorithm so much more cautious than the ND algorithm? B. Related Protocol Specifications Doesn't mention reference [15]! Thanks, Rich From owner-dhcp-v6@bucknell.edu Fri Jan 21 06:08:34 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06581 for ; Fri, 21 Jan 2000 06:08:34 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id GAA02443; Fri, 21 Jan 2000 06:04:32 -0500 (EST) Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id GAA03884 for ; Fri, 21 Jan 2000 06:02:50 -0500 (EST) Received: from 157.54.9.108 by mail5.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 21 Jan 2000 03:02:16 -0800 (Pacific Standard Time) Received: by INET-IMC-05 with Internet Mail Service (5.5.2650.21) id ; Fri, 21 Jan 2000 03:02:15 -0800 Message-ID: <4D0A23B3F74DD111ACCD00805F31D8101EDBCBE4@RED-MSG-50> From: Richard Draves To: Subject: DHCPv6 extension comments Date: Fri, 21 Jan 2000 03:02:11 -0800 X-Mailer: Internet Mail Service (5.5.2650.21) 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 Comments on draft-ietf-dhc-v6exts-11.txt. Overall, I thought the split between the two documents was rather confusing, the main DHCPv6 spec does not stand on its own because it doesn't say anything about how the extensions are formatted. Future applications will make extensive use of an ever-increasing number and variety of network services. It is expected that client needs for creating connections with these future network services will be satisfied by the Service Location Protocol [27], and not DHCPv6. DHCP is expected to be used for the kinds of configuration that enable clients to become fully functional as self-contained network entities, but not the kinds of configuration that might be required by applications running above the network or transport layer protocol levels. This draft defines a bunch of extensions (NTP, DNS, NIS, ...) that would seem to violate this applicability statement. of extension type 64 (see section 7.1), DHCP entities MUST assume that that the maximum DHCP message size including extensions is 1280 octets. Does this size include any headers (like IP, UDP) before DHCP? 3. IP Address Extension How would one handle IPv4 addresses using DHCPv6? Use v4-mapped address format with the IP Address Extension, or define a new extension? prefix-size If the client address is present (the 'C' bit is set), a nonzero prefix-size is the number of leftmost bits of the client's IPv6 address which make up the routing prefix. Otherwise, if the 'C' bit is not set, prefix-size MUST be zero. Why is there a prefix-size field in the IP Address extension? What do you expect the client to do with this information?? Q If the 'Q' bit is set, the fields included by the client are required, and must be made available by the server or else the extension must be rejected. Can the server set the Q bit? What should happen if it does? I assume the DNS name is present if either the A or P bits are set? Can the client send a non-FQDN and get back a FQDN? Will the server ever send a non-FQDN? In general the A & P bits and their use are unclear. Do you expect the client to know its name and tell the server, or the server to know the client's name and tell the client, or are you allowing for both? What if they disagree? The DNS name can be a host name, which does not contain the '.' ASCII character as a separator between DNS hierarchy components. Any name containing the '.' is treated as a Fully Qualified Domain Name (FQDN). The length of the DNS name may be determined by subtracting, from the Length, the length of those fixed length fields which are present. Why not use the same DNS name representation (label sequence) that DNS uses? By default, the client SHOULD update the AAAA record, and the server SHOULD update the PTR record. The IP Address extension permit What about A6? How can the server "SHOULD update the PTR" by default? Doesn't it need a DNS name in the address extension, meaning the client sets the P bit, meaning the client requested this action so it wasn't performed by default? clients and servers to use a different behavior than the default, and they MAY set the 'Q' and 'A' bits to suit their needs. Should this be 'P' and 'A' bits? 3.2.1. Use with the DHCP Advertise message I'm unclear on the use of address extensions in Advertise messages. Can an address extension in an Advertise give a client an address? Can you provide some scenarios? 4.3. Domain Name Server Extension Shouldn't the two DNS extensions be in the "Application and Services" section? 4.4. Domain Name This extension specifies the default domain name that client should use when resolving hostnames via the Domain Name System. Shouldn't this be called the Domain Name Suffix extension? If there are multiple Domain Name extensions, does the last one apply, the first one, or do they form a search list? (More generally, what happens when the same extension shows up more than once?) 5.3. Network Information Service (NIS and NIS+) extensions This subsection describes DHCPv6 extensions useful for NIS and NIS+ clients. Are NIS and NIS+ IETF standards? If so update the reference. If not, why are these extensions being defined here - if it's relevant to something proprietry, put it in a separate document. 7.2. DHCP Retransmission and Configuration Parameter Extension Are clients expected (or discouraged) to update/store these parameters (particularly the ones that apply to Solicits) in stable storage? 7.3. Platform Specific Information What's the point of encapsulating the platform-specific extensions? Why can't they be given directly to the client without encapsulation? The Encapsulated platform-specific extensions field MUST be encoded as a sequence of type/length/value fields of identical syntax to the form defined for DHCPv6 extensions. Extension 65535 (END), if present, signifies the end of the encapsulated platform extensions, not the end of the platform extensions field. If no extension 65535 is present, then the end of the enclosing platform-specific information field is taken as the end of the encapsulated platform-specific extensions field. What's the point of the 65535/END extension? The end of the outer, encapsulating extension signifies the end of the platform-specific extensions. 7.4. Platform Class Identifier This extension is used by a DHCP client to identify the hardware type and operating system platform it is hosted on. The extension value itself is an opaque value to a DHCP server, and is only used by the DHCP server to "lookup" Platform Specific Extensions associated with clients of a certain platform class. Since the platform is a combination of hardware & operating-system, why isn't this split out into two identifiers? 7.5. Class Identifier How is a client supposed to know it's class identifier? 7.7. Renumber DHCPv6 Server Address What about renumbering the relay address? The Length of the DHCP Relay ICMP Message extension is the length of the ICMP error message received by the relay [9]. What about truncating the error message to make it fit? Thanks, Rich From owner-dhcp-v6@bucknell.edu Fri Jan 21 06:08: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 GAA06592 for ; Fri, 21 Jan 2000 06:08:37 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id GAA04616; Fri, 21 Jan 2000 06:04:39 -0500 (EST) Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id GAA05253 for ; Fri, 21 Jan 2000 06:02:50 -0500 (EST) Received: from 157.54.9.108 by mail5.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 21 Jan 2000 03:02:16 -0800 (Pacific Standard Time) Received: by INET-IMC-05 with Internet Mail Service (5.5.2650.21) id ; Fri, 21 Jan 2000 03:02:15 -0800 Message-ID: <4D0A23B3F74DD111ACCD00805F31D8101EDBCBE5@RED-MSG-50> From: Richard Draves To: Subject: RE: DHCPv6 address allocation model Date: Fri, 21 Jan 2000 03:02:11 -0800 X-Mailer: Internet Mail Service (5.5.2650.21) 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 > From: Thomas Narten [mailto:narten@raleigh.ibm.com] > Sent: Thursday, December 23, 1999 8:15 AM > To: dhcp-v6@bucknell.edu > Subject: DHCPv6 address allocation model > > > Mike Carney - SNT Internet Engineering > writes: > > > We feel we've solved the issues of support for multiple > addresses (of > > different prefixes) and multiple servers. Please read the following > > and let us know if you agree. > > Re: multiple addresses. I posted a note to the dhcpv6 list back in > august (appended below). Does your solution solve all the points > mentioned in it? Indeed, has the solution been explained to the WG > yet? I think Thomas is right, there are major problems here and I do not like the ERE proposal. It's complicated and yet doesn't solve the problems. A link will have a set of prefixes, say one site-local and three global. With the current design, it seems like the DHCP server should generally allocate addresses in groups: if a client sends a request with one IP Address extension, it should get back addresses four addresses in this example. If it sends another request with an IP Address extension, it should get back four more addresses. The client doesn't know how many prefixes are in use on the link, so it can't adjust the number of IP Address extensions that it sends. And the client will need addresses formed from each prefix. Another issue - how does this play with the privacy draft, where clients will want to get two global addresses for each prefix, one anonymous (not in DNS) and one public? Here's a different approach, more like what happens with auto-config: use two kinds of extensions. First an IP Address Prefix extension that gives the client a prefix to use in address formation. (This could be a flavor of the IP Address extension.) This is normally sent in Advertise messages. The server tells the client about multiple prefixes using multiple extensions. Then the client requests addresses using the IP Address extension. In extensions sent in the request, the client can include a prefix of an address (the normal case for getting new addresses, the prefix being learned from the Advertise) or an entire address (the normal case for renewing address leases). So in the example above, the Advertise would contain four IP Address Prefix extensions communicating the site-local prefix and three global prefixes. Then depending on the client's needs it might send in the Request: a) four IP Address extensions, getting an address for each prefix. It can control individually the DNS bits for each address prefix. b) three IP Address extensions, it doesn't want a site-local address. c) seven IP Address extensions, it wants a site-local, three global anonymous, and three global public addresses. d) eight IP Address extensions, it wants to have two sets of addresses, etc, etc. Thanks, Rich From owner-dhcp-v4@bucknell.edu Fri Jan 21 13:58: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 NAA15628 for ; Fri, 21 Jan 2000 13:58:20 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id NAA30464; Fri, 21 Jan 2000 13:57:08 -0500 (EST) Received: from thalia.fm.intel.com (thalia.fm.intel.com [132.233.247.11]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id NAA06912 for ; Fri, 21 Jan 2000 13:56:04 -0500 (EST) Received: from SMTP (fmsmsxvs02-1.fm.intel.com [132.233.42.202]) by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.18 2000/01/07 21:56:55 dmccart Exp $) with SMTP id SAA12447; Fri, 21 Jan 2000 18:56:20 GMT Received: from fmsmsx18.intel.com ([132.233.48.18]) by 132.233.48.202 (Norton AntiVirus for Internet Email Gateways 1.0) ; Fri, 21 Jan 2000 18:55:44 0000 (GMT) Received: by fmsmsx18.fm.intel.com with Internet Mail Service (5.5.2448.0) id ; Fri, 21 Jan 2000 10:55:43 -0800 Message-ID: From: "Henry, Mike" To: Subject: RE: I-D ACTION:draft-ietf-dhc-nextserver-00.txt Date: Fri, 21 Jan 2000 10:55:42 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="windows-1252" Reply-To: mike.henry@intel.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN It seems to me that that the draft has a number of weaknesses. It relies os an explicit IP address, and only one address. That is, there is no provision for more than one secondary config server of a particular type. At a minimum, the ability to provide a list of IP addresses for the client to try would provide some robustness to address the case where the one and only secondary config server is down. Also, there is the question of config server types.... how does one define a third or fourth type beyond DHCP and RSIP-FRAME? Perhaps it would make sense to propose an IANA administered list so vendors with new config server types could simply register the type? Finally, it really seems to me that this is just the sort of thing that SLP (Service Location Protocol) was designed to address. Rather than an ad hoc option to address this particular case, why not discover the secondary config server via SLP? This gets the DHCP admin out of the business of tracking yet another special server type as being of interest to his/her community, and gets the admin out of the business of tracking down and maintaining the server's IP address in this context. Mike H. Intel -----Original Message----- From: jerome.privat@bt.com [mailto:jerome.privat@bt.com] Sent: Thursday, January 20, 2000 8:58 AM To: dhcp-v4@bucknell.edu Subject: RE: I-D ACTION:draft-ietf-dhc-nextserver-00.txt This new proposed option is pretty straightforward and can be used by a DHCP server to redirect a client to a secondary configuration server. If you have comments on the draft, please send them to the list. Thanks, Jerome Privat, BT -----Original Message----- From: Ralph Droms [mailto:droms@bucknell.edu] Sent: 20 January 2000 13:38 To: dhcp-v4 Subject: I-D ACTION:draft-ietf-dhc-nextserver-00.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-00.txt Pages : 6 Date : 19-Jan-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-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-nextserver-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-nextserver-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: <20000119140436.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-nextserver-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-nextserver-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000119140436.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-dhcp-v6@bucknell.edu Fri Jan 21 16:46: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 QAA17737 for ; Fri, 21 Jan 2000 16:45:48 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id QAA27712; Fri, 21 Jan 2000 16:36:21 -0500 (EST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id QAA23481 for ; Fri, 21 Jan 2000 16:36:03 -0500 (EST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.8.8/8.6.10) with ESMTP id NAA23006; Fri, 21 Jan 2000 13:35:19 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.9.3/8.9.3-VIRSCAN) id NAA15803; Fri, 21 Jan 2000 13:35:15 -0800 X-Virus-Scanned: Fri, 21 Jan 2000 13:35:15 -0800 Nokia Silicon Valley AntiVirus Appliance Received: from (charliep.iprg.nokia.com [205.226.2.89]) by darkstar.iprg.nokia.com SMTP/WTS (12.69) xma015564; Fri, 21 Jan 00 13:35:01 -0800 Sender: owner-dhcp-v6@bucknell.edu Message-ID: <3888D105.662A637D@iprg.nokia.com> Date: Fri, 21 Jan 2000 13:35:01 -0800 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 2.2.6-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: CC: dhcp-v6@bucknell.edu, Jim Bound , Mike Carney Subject: Re: DHCPv6 extension comments References: <4D0A23B3F74DD111ACCD00805F31D8101EDBCBE4@RED-MSG-50> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Reply-To: dhcp-v6@bucknell.edu X-Sender: charliep@iprg.nokia.com X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit Hello Richard, Thanks for your note. I'll try to answer some of your points, and I reckon we'll all three have something more to say next week after our next meeting. > Overall, I thought the split between the two documents was rather confusing, > the main DHCPv6 spec does not stand on its own because it doesn't say > anything about how the extensions are formatted. I do not understand why the main specification should say how the extensions are formatted. The main specification handles the protocol control flow. The extensions carry the data. This makes for a very clear division in the specification. Of course, no one wants to have a control sequence without any data, and no one wants to send data without any understanding of how it is to be used. Nevertheless, I think that looking at the specifications this way leads to a very clear document structure. > Future applications will make extensive use of an ever-increasing > number and variety of network services. It is expected that client > needs for creating connections with these future network services > will be satisfied by the Service Location Protocol [27], and not > DHCPv6. DHCP is expected to be used for the kinds of configuration > that enable clients to become fully functional as self-contained > network entities, but not the kinds of configuration that might be > required by applications running above the network or transport layer > protocol levels. > > This draft defines a bunch of extensions (NTP, DNS, NIS, ...) that would > seem to violate this applicability statement. What is the violation? Are you suggesting that DNS should be found by using SLP? We don't intend to invalidate current practices for such well-known operations. > 3. IP Address Extension > > How would one handle IPv4 addresses using DHCPv6? Use v4-mapped address > format with the IP Address Extension, or define a new extension? Are you suggesting that we need a way for a DHCP client to specifically ask for an IPv4 address? If so, then that is a new feature not requested by anyone else up until now. Maybe it would be better to defer this new featue until after we have finally stabilized the current documents. Most people seem to be very anxious to get finished with the current specification without adding new features. We don't deal specifically with allocating anycast addresses either, for example. > prefix-size > If the client address is present (the 'C' bit is set), a > nonzero prefix-size is the number of leftmost bits of the > client's IPv6 address which make up the routing prefix. > Otherwise, if the 'C' bit is not set, prefix-size MUST be > zero. > > Why is there a prefix-size field in the IP Address extension? What do you > expect the client to do with this information?? We don't tell the clients what to do with the information, nor what to do with their IP addresses or any other information. Do you believe that clients should not have this information? > Q If the 'Q' bit is set, the fields included by the client > are required, and must be made available by the server or > else the extension must be rejected. > > Can the server set the Q bit? What should happen if it does? The server should not set the Q bit. I reckon doing so should be prohibited. > I assume the DNS name is present if either the A or P bits are set? Can the > client send a non-FQDN and get back a FQDN? Will the server ever send a > non-FQDN? In general the A & P bits and their use are unclear. We'll probably discuss this more on Monday, but I think that the server would never send back a non-FQDN. Did you know that FQDN does not seem to appear in any RFC? (useless bit of trivia) > Do you expect the client to know its name and tell the server, or the server > to know the client's name and tell the client, or are you allowing for both? > What if they disagree? We do not place any such expectation, but we did want to handle the various cases correctly. There are many places for various network agents to disagree, even in the case of Router Advertisements without DHCP. Can you make a suggestion about how we should handle disagreements in this case? > By default, the client SHOULD update the AAAA record, and the server > SHOULD update the PTR record. The IP Address extension permit > > What about A6? How can the server "SHOULD update the PTR" by default? > Doesn't it need a DNS name in the address extension, meaning the client sets > the P bit, meaning the client requested this action so it wasn't performed > by default? According to your discussion, I think we need to clarify the specification to eliminate future confusion. We didn't take the A6 record update into account, which just goes to show how long it's been since this document was originated. > 3.2.1. Use with the DHCP Advertise message > > I'm unclear on the use of address extensions in Advertise messages. Can an > address extension in an Advertise give a client an address? Can you provide > some scenarios? The newly revised document is supposed to contain some examples, but roughly speaking the idea is for a client to find a server that can supply an IP address that matches what the client wants somehow. I don't have the time just now to build a suitable example to make this clear, but I hope that small bit of intuition will be helpful. > Shouldn't the two DNS extensions be in the "Application and Services" > section? Is DNS an application, or is it a core network requirement? How can I tell the difference? > 4.4. Domain Name > This extension specifies the default domain name that client should > use when resolving hostnames via the Domain Name System. > > Shouldn't this be called the Domain Name Suffix extension? It's O.K. with me! > (More generally, what happens when the same extension shows up more than > once?) What happens today? Can you suggest a reasonable specification for this? > 5.3. Network Information Service (NIS and NIS+) extensions > > This subsection describes DHCPv6 extensions useful for NIS and NIS+ > clients. > > Are NIS and NIS+ IETF standards? If so update the reference. If not, why are > these extensions being defined here - if it's relevant to something > proprietry, put it in a separate document. It's in DHCPv4, and more than one person asked for it. Are you suggesting that we should create some admission criteria for new extensions? If it's in DHCPv4, and people want it, do we still try to find reasons not to include it for DHCPv6? > 7.2. DHCP Retransmission and Configuration Parameter Extension > > Are clients expected (or discouraged) to update/store these parameters > (particularly the ones that apply to Solicits) in stable storage? We didn't make any inducement, nor prohibition. We only included this feature because previous commentators asked for it. If a client asked for a configuration parameter, I guess it ought to remember that it asked. I don't know why someone would go to all the trouble of getting a new parameter just to forget about it. Do you mean to ask about behavior for such parameters over reboots and system crashes? Do you have a preference for what needs to be specified? > 7.3. Platform Specific Information > > What's the point of encapsulating the platform-specific extensions? Why > can't they be given directly to the client without encapsulation? > > The Encapsulated platform-specific extensions field MUST be > encoded as a sequence of type/length/value fields of identical > syntax to the form defined for DHCPv6 extensions. Extension > 65535 (END), if present, signifies the end of the encapsulated > platform extensions, not the end of the platform extensions field. > If no extension 65535 is present, then the end of the enclosing > platform-specific information field is taken as the end of the > encapsulated platform-specific extensions field. > > What's the point of the 65535/END extension? The end of the outer, > encapsulating extension signifies the end of the platform-specific > extensions. I think we just tried to do it like DHCPv4 does it. > 7.4. Platform Class Identifier > This extension is used by a DHCP client to identify the hardware type > and operating system platform it is hosted on. The extension value > itself is an opaque value to a DHCP server, and is only used by the > DHCP server to "lookup" Platform Specific Extensions associated with > clients of a certain platform class. > > Since the platform is a combination of hardware & operating-system, why > isn't this split out into two identifiers? I don't think this split is universally needed, and I do think that for cases when it is needed, you can use the existing extension to provide it. On the other hand, if people generally want to have two extensions, that's totally fine with me. > 7.5. Class Identifier > > How is a client supposed to know it's class identifier? I don't think we have to specify this. > 7.7. Renumber DHCPv6 Server Address > > What about renumbering the relay address? The relay's address is more important to the server than it is to the client. This is something that probably matters whenever a IPv6 server-server protocol gets built. Thanks again for your comments. The parts I left out are the parts I need to think more about, and will have more to say on them next week. Regards, Charlie P. From owner-dhcp-v6@bucknell.edu Fri Jan 21 17:33: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 RAA18207 for ; Fri, 21 Jan 2000 17:33:29 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id RAA15334; Fri, 21 Jan 2000 17:25:14 -0500 (EST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id RAA18191 for ; Fri, 21 Jan 2000 17:24:56 -0500 (EST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.8.8/8.6.10) with ESMTP id OAA28491; Fri, 21 Jan 2000 14:24:23 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.9.3/8.9.3-VIRSCAN) id OAA27168; Fri, 21 Jan 2000 14:24:22 -0800 X-Virus-Scanned: Fri, 21 Jan 2000 14:24:22 -0800 Nokia Silicon Valley AntiVirus Appliance Received: from (charliep.iprg.nokia.com [205.226.2.89]) by darkstar.iprg.nokia.com SMTP/WTS (12.69) xma026951; Fri, 21 Jan 00 14:24:04 -0800 Sender: owner-dhcp-v6@bucknell.edu Message-ID: <3888DC84.DE37E255@iprg.nokia.com> Date: Fri, 21 Jan 2000 14:24:04 -0800 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 2.2.6-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: CC: dhcp-v6@bucknell.edu, Jim Bound , Mike Carney Subject: Re: DHCPv6 address allocation model References: <4D0A23B3F74DD111ACCD00805F31D8101EDBCBE5@RED-MSG-50> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Reply-To: dhcp-v6@bucknell.edu X-Sender: charliep@iprg.nokia.com X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit Hello Richard, > I think Thomas is right, there are major problems here and I do not like the > ERE proposal. It's complicated and yet doesn't solve the problems. It does indeed solve some of the problems. Our goal should be to solve as many problems as we economically can. > A link will have a set of prefixes, say one site-local and three global. > With the current design, it seems like the DHCP server should generally > allocate addresses in groups: if a client sends a request with one IP > Address extension, it should get back addresses four addresses in this > example. If it sends another request with an IP Address extension, it should > get back four more addresses. This is one proposal, but there is no indication about why it's better than another proposal. Following the same logic, perhaps some links might be configured to allocate _two_ addresses per prefix per request, and some other links might be configured to allocate _.3333_ addresses per prefix per request. I don't see what's magic about one, and I don't see how it's related to application requirements. I do see that putting the client in charge of getting resources for its application needs is placing the responsibility where it belongs. > Another issue - how does this play with the privacy draft, where clients > will want to get two global addresses for each prefix, one anonymous (not in > DNS) and one public? That's a really interesting question, and I hope before it's over that an application can get an "anonymous" address just like it can get any other address, and without any ordering restrictions. We are long past the days of serialized batch handling for appliction processing, and it is the application that should decide whether to be anonymous. We surely do not want separate applications to be _forced_ to be associated with each other by using the _same_ anonymous IP address. I hope this is obvious. And, we don't want to force them to be invoked serially. > Here's a different approach, more like what happens with auto-config: use > two kinds of extensions. First an IP Address Prefix extension that gives the > client a prefix to use in address formation. (This could be a flavor of the > IP Address extension.) This is normally sent in Advertise messages. The > server tells the client about multiple prefixes using multiple extensions. > Then the client requests addresses using the IP Address extension. In > extensions sent in the request, the client can include a prefix of an > address (the normal case for getting new addresses, the prefix being learned > from the Advertise) or an entire address (the normal case for renewing > address leases). I don't see the rationale for this! And, it's very late in the process to make this restructuring. As a wannabe mathematician, I enjoy symmetric things like the symmetry in your proposal, but my understanding about how to make life easier for applications doesn't find much harmony with this proposal. Regards, Charlie P. From owner-dhcp-v6@bucknell.edu Fri Jan 21 18:14: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 SAA18667 for ; Fri, 21 Jan 2000 18:14:42 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id SAA25594; Fri, 21 Jan 2000 18:03:31 -0500 (EST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id SAA28060 for ; Fri, 21 Jan 2000 18:03:22 -0500 (EST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.8.8/8.6.10) with ESMTP id PAA02778; Fri, 21 Jan 2000 15:02:51 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.9.3/8.9.3-VIRSCAN) id PAA03251; Fri, 21 Jan 2000 15:02:50 -0800 X-Virus-Scanned: Fri, 21 Jan 2000 15:02:50 -0800 Nokia Silicon Valley AntiVirus Appliance Received: from (charliep.iprg.nokia.com [205.226.2.89]) by darkstar.iprg.nokia.com SMTP/WTS (12.69) xma003115; Fri, 21 Jan 00 15:02:32 -0800 Sender: owner-dhcp-v6@bucknell.edu Message-ID: <3888E588.A7389FEC@iprg.nokia.com> Date: Fri, 21 Jan 2000 15:02:32 -0800 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 2.2.6-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: CC: dhcp-v6@bucknell.edu, Jim Bound , Mike Carney Subject: Re: DHCPv6 comments References: <4D0A23B3F74DD111ACCD00805F31D8101EDBCBE3@RED-MSG-50> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Reply-To: dhcp-v6@bucknell.edu X-Sender: charliep@iprg.nokia.com X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit Hello again Richard, > This protocol is really different from DHCPv4 (from what I've seen of DHCPv4 > in packet traces), too bad it doesn't have a different name. That has to be considered a matter of opinion. Most of the differences arise from things that are different between IPv6 and IPv4 (e.g., link-local addresses, multihomed hosts). > Making the relay explicit in the protocol introduces lots of complexity. Hmmm.... I always thought it made things more definite and (in combination with the use of link-local addresses) a lot easier. As I remember, dealing with 0.0.0.0 as a destination IP address wasn't exactly the world's most elegant design. > Here's an idea: > > The relay should only participate in Solicit/Advertise messages. Once the > client discovers server/relay addresses, the client and the server > communicate directly with each other. If the client's link-local address is > the IP source or destination and the server is off-link (relay address != > server address), then a routing header is used to route the packet via the > relay. > > This would simplify the protocol a lot. Among other things, the client and > server could potentially use end-to-end IPsec instead of using one-off > DHCPv6 security hacks. Y'know, I just hate it when somebody calls my elegant security breakthrough a "hack". Maybe I'm too sensitive about these things. > Some (fatal???) complications with this idea: > - Routing header processing when the IP source is link-local. > draft-ietf-ipngwg-icmp-v3-00.txt is unclear - should routing header > processing generate the "beyond scope of source address" error? > - IPsec operation in the server, with off-link link-local client addresses These complications amount to an objection that is more significant than your issues with the current design. > Another issue - servers don't have access to client link-layer addresses. Is > the assumption that administrators will be happy to use link-local addresses > instead as a good key to identify clients? Will administrators feel that > they are losing something here? I do not understand what's wrong here. How would it help if every server had a network interface to every link, so that it could detect link-local addresses in client packets? I haven't heard any complaints from any administrators! > Misc specific comments (quotations from the draft are indented): > > 02 DHCP Advertise > > The DHCP Advertise is an IP unicast message sent by a DHCP > Agent in response to a client's DHCP Solicit message. > > Why not allow for multicast Advertise messages, so when a lot of clients are > booting one Advertise can suffice for them all, or least everyone on a link. > (See ND Router Advertisements.) I don't have a terrible problem with this, but I also don't want to open that can of worms just now. My mantra is "get it finished, don't look at any additional features". Ask us again in a few weeks when we've finally gone through last call. We've had enough hints from important people to stop making new features. > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | saved agent-address | > | (if present, 16 octets) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > I finished reading the dhcpv6 draft and was in the middle of the extensions > draft before I realized what "if present" meant. I thought at first that > when a field was "not present" it was supposed to be sent as zeroes. I think > I got confused because none of the other v6 protocols have optional fields > like this in their headers. This could use more explanation. I'm sure this can be done. Thanks for pointing out a possible source of confusion. > If a client reboots and does not have a valid IP address, it SHOULD > set the `C' bit in the DHCP Solicit message it sends when restarting. > By setting the `C' bit in the solicitation, a client requests that > all the DHCP servers that receive the solicitation should clean up > their client records that match its link-local address. > > The client link-local address does not uniquely specify the client. This is true. We have discussed this many times. But, it is also true that in many common situations, the link-local address DOES uniquely identify the client, and we wanted to allow for the possibility of using it that way whenever the local administration wished to do so. > retransmit according to the rules in Section 8. If (after following > those rules) the client has not received a Reply message, it SHOULD > start over again by multicasting a new DHCP Solicit message to find a > different server. > > What if the client already knows about other servers from its original > solicit? You are right that a client should be able to use the other servers. I think this language should be changed to make that clear. On the other hand, if the information is very, very old, the client may suffer some additional unwanted latency by using stale information. Should there be a timeout? How long? > 6.2. Sending DHCP Advertise Messages > Upon receiving and verifying the correctness of a DHCP Solicit > message, a server constructs a DHCP Advertise message and transmits > it on the same link as the solicitation was received from. When the > solicitation is received at the All-DHCP-Servers multicast address, > the server SHOULD delay the transmission of its advertisement > for a random amount of time between SERVER_MIN_ADV_DELAY and > SERVER_MAX_ADV_DELAY (see section 8). > > So this delay is not done when the solicitation is received at the > All-DHCP-Agents multicast address??? It only has to be done at one or the other. > 7.2. DHCP Request Message Processing > When a relay receives a DHCP Request message, it SHOULD check that > the IP source address in the IP header is a link-local address, > that the link-local address matches the link-local address field in > > Should the same checks be performed when a relay receives a DHCP Solicit? I'm not certain, but I think the checks are not necessary in this case. > All of the fields of DHCP Request message transmitted by the relay > are copied over unchanged from the DHCP Request received from the > client. Only the fields in the IP header will differ from the > packet received from the client. All relays MUST send DHCP Request > > And the UDP checksum will differ. That is a good point! I think the language in the above paragraph needs to be revised to reflect this point. > 8. Retransmission and Configuration Variables > When a client does not receive a DHCP Reply in response to a pending > DHCP Request, the client MUST retransmit the identical DHCP Request, > with the same transaction-ID, to the same server again until it can > be reasonably sure that the server is unavailable and an alternative > can be chosen. The DHCP server assumes that the client has received > > Unless N bit was set in a Reconfigure that caused the Request. All the stuff about the 'N' bit is going to be stale after the new revision is issued by Mike. > The default settings for the parameters will cause perceptible delay in > DHCPv6 address allocation relative to address auto-configuration. Can't they > be tuned to make DHCP work faster in the common case? I already lost that argument. I agree with you, though. Regarding the other parameter settings, I will leave the discussion to a later date. However, I should note that we haven't had much discussion about them, and probably some of the values should be changed to reflect your observations. > B. Related Protocol Specifications > > Doesn't mention reference [15]! Good point... Regards, Charlie P. From owner-dhcp-v6@bucknell.edu Sun Jan 23 10:45: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 KAA09756 for ; Sun, 23 Jan 2000 10:45:25 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id KAA01766; Sun, 23 Jan 2000 10:40:49 -0500 (EST) Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id KAA30361 for ; Sun, 23 Jan 2000 10:40:44 -0500 (EST) Received: from givry.inria.fr (givry.inria.fr [193.51.193.144]) by concorde.inria.fr (8.8.7/8.8.7) with ESMTP id QAA27796 for ; Sun, 23 Jan 2000 16:40:43 +0100 (MET) Received: from givry.inria.fr (givry.inria.fr [193.51.193.144]) by givry.inria.fr (8.7.6/8.7.3) with ESMTP id QAA31487 for ; Sun, 23 Jan 2000 16:40:42 +0100 (MET) Message-Id: <200001231540.QAA31487@givry.inria.fr> From: Francis Dupont To: Subject: Re: DHCPv6 comments In-reply-to: Your message of Fri, 21 Jan 2000 03:02:10 PST. <4D0A23B3F74DD111ACCD00805F31D8101EDBCBE3@RED-MSG-50> Date: Sun, 23 Jan 2000 16:40:42 +0100 Sender: owner-dhcp-v6@bucknell.edu Reply-To: dhcp-v6@bucknell.edu X-Sender: Francis.Dupont@inria.fr X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN In your previous mail you wrote: So I finally had time to read draft-ietf-dhc-dhcpv6-14.txt. I don't have access to the list archives at 30,000 feet, so forgive me if these are old issues. I'm going to send separate messages on the extensions draft and responding to Thomas's 12/23 "DHCPv6 address allocation model" email. => -14 I-D has many problems which were solved in the mailing list... This protocol is really different from DHCPv4 (from what I've seen of DHCPv4 in packet traces), too bad it doesn't have a different name. => I agree, the main (and unsolved) problem of DHCPv6 is its first four letters (:-). Making the relay explicit in the protocol introduces lots of complexity. => the relay function is needed because a box can start with only a link-local address and no server on the link. A relay is a small piece of code then one can find to have a server with a lot of relays easier than a lot of relays + distributed server management tool. Here's an idea: The relay should only participate in Solicit/Advertise messages. Once the client discovers server/relay addresses, the client and the server communicate directly with each other. If the client's link-local address is the IP source or destination and the server is off-link (relay address != server address), then a routing header is used to route the packet via the relay. => this doesn't work (ie. you can't use a link-local address in a routing header to go outside the link). This would simplify the protocol a lot. Among other things, the client and server could potentially use end-to-end IPsec instead of using one-off DHCPv6 security hacks. => the reason DHCP must have security hacks is simply because IPSec uses destination addresses (the thing you get with DHCP). Some (fatal???) complications with this idea: - Routing header processing when the IP source is link-local. draft-ietf-ipngwg-icmp-v3-00.txt is unclear - should routing header processing generate the "beyond scope of source address" error? => yes or it should drop the packet... - IPsec operation in the server, with off-link link-local client addresses => this is not secure by default because link-local addresses are ambiguous (ie. you can have two off-link clients with the same address on different links). Regards Francis.Dupont@inria.fr PS: I expect the new I-Ds will be available soon? From owner-dhcp-v6@bucknell.edu Sun Jan 23 10:53:15 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09773 for ; Sun, 23 Jan 2000 10:53:15 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id KAA11183; Sun, 23 Jan 2000 10:50:31 -0500 (EST) Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id KAA17611 for ; Sun, 23 Jan 2000 10:50:25 -0500 (EST) Received: from givry.inria.fr (givry.inria.fr [193.51.193.144]) by concorde.inria.fr (8.8.7/8.8.7) with ESMTP id QAA28095 for ; Sun, 23 Jan 2000 16:50:25 +0100 (MET) Received: from givry.inria.fr (givry.inria.fr [193.51.193.144]) by givry.inria.fr (8.7.6/8.7.3) with ESMTP id QAA10947 for ; Sun, 23 Jan 2000 16:50:24 +0100 (MET) Message-Id: <200001231550.QAA10947@givry.inria.fr> From: Francis Dupont To: Subject: Re: DHCPv6 extension comments In-reply-to: Your message of Fri, 21 Jan 2000 03:02:11 PST. <4D0A23B3F74DD111ACCD00805F31D8101EDBCBE4@RED-MSG-50> Date: Sun, 23 Jan 2000 16:50:23 +0100 Sender: owner-dhcp-v6@bucknell.edu Reply-To: dhcp-v6@bucknell.edu X-Sender: Francis.Dupont@inria.fr X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN In your previous mail you wrote: 3. IP Address Extension How would one handle IPv4 addresses using DHCPv6? Use v4-mapped address format with the IP Address Extension, or define a new extension? => DSTM needs this function then Jim should have the answer (:-)! By default, the client SHOULD update the AAAA record, and the server SHOULD update the PTR record. The IP Address extension permit What about A6? => next I-D of course! If there are multiple Domain Name extensions, does the last one apply, the first one, or do they form a search list? => the domain name is the name of the domain where is the client but a way to get a search list is a useful idea. Regards Francis.Dupont@inria.fr From owner-dhcp-v6@bucknell.edu Sun Jan 23 10:59: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 KAA09844 for ; Sun, 23 Jan 2000 10:59:42 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id KAA00807; Sun, 23 Jan 2000 10:58:42 -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 KAA22252 for ; Sun, 23 Jan 2000 10:58:29 -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 HAA29954 for ; Sun, 23 Jan 2000 07:52:37 -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 KAA02759 for ; Sun, 23 Jan 2000 10:56:38 -0500 (EST) Message-Id: <200001231556.KAA02759@grosse.manhattan.fugue.com> To: Subject: Re: DHCPv6 comments In-Reply-To: Message from Francis Dupont of "Sun, 23 Jan 2000 16:40:42 +0100." <200001231540.QAA31487@givry.inria.fr> Date: Sun, 23 Jan 2000 10:56:37 -0500 From: Ted Lemon Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN > => -14 I-D has many problems which were solved in the mailing list... Dare I say it? A problem that has been solved on the mailing list but whose solution is not reflected in the draft has not in fact been solved - it has merely been discussed. _MelloN_ From owner-dhcp-v6@bucknell.edu Sun Jan 23 11:12: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 LAA09964 for ; Sun, 23 Jan 2000 11: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 LAA08347; Sun, 23 Jan 2000 11:11:48 -0500 (EST) Received: from mail.ptd.net (mail2.ha-net.ptd.net [207.44.96.66]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id LAA29411 for ; Sun, 23 Jan 2000 11:11:47 -0500 (EST) Received: (qmail 9175 invoked from network); 23 Jan 2000 16:11:28 -0000 Received: from host22.bvtc.ptd.net (HELO droms-laptop) (209.173.2.22) by mail.ptd.net with SMTP; 23 Jan 2000 16:11:28 -0000 Message-Id: <4.2.2.20000123110607.00a79a80@mail.bucknell.edu> X-Sender: droms@mail.bucknell.edu X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Sun, 23 Jan 2000 11:10:13 -0500 To: From: Ralph Droms Subject: Re: DHCPv6 comments Cc: mellon@ISC.ORG In-Reply-To: <200001231556.KAA02759@grosse.manhattan.fugue.com> References: <200001231540.QAA31487@givry.inria.fr> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN At 10:56 AM 1/23/00 -0500, Ted Lemon wrote: > > => -14 I-D has many problems which were solved in the mailing list... > >Dare I say it? A problem that has been solved on the mailing list >but whose solution is not reflected in the draft has not in fact been >solved - it has merely been discussed. Ted - thanks for making that clarifying (and correct) distinction. I've been in touch with the authors, who expect to post a summary of solutions developed in mailing list conversations. They plan to express the solutions formally in a new draft within a couple of weeks. - Ralph From owner-dhcp-v6@bucknell.edu Sun Jan 23 11:34: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 LAA10248 for ; Sun, 23 Jan 2000 11:34:18 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id LAA12023; Sun, 23 Jan 2000 11:30:45 -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 LAA09987 for ; Sun, 23 Jan 2000 11:30:29 -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 IAA00202 for ; Sun, 23 Jan 2000 08:24:55 -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 LAA02877 for ; Sun, 23 Jan 2000 11:28:54 -0500 (EST) Message-Id: <200001231628.LAA02877@grosse.manhattan.fugue.com> To: Subject: Re: DHCPv6 comments In-Reply-To: Message from Ralph Droms of "Sun, 23 Jan 2000 11:10:13 EST." <4.2.2.20000123110607.00a79a80@mail.bucknell.edu> Date: Sun, 23 Jan 2000 11:28:54 -0500 From: Ted Lemon Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN > Ted - thanks for making that clarifying (and correct) distinction. I've > been in touch with the authors, who expect to post a summary of solutions > developed in mailing list conversations. They plan to express the > solutions formally in a new draft within a couple of weeks. Cool! :') _MelloN_ From owner-dhcp-v6@bucknell.edu Sun Jan 23 21:28:46 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13337 for ; Sun, 23 Jan 2000 21:28:36 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id VAA14506; Sun, 23 Jan 2000 21:16:34 -0500 (EST) Received: from mailext04.compaq.com (mailext04.compaq.com [207.18.199.42]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id VAA28683 for ; Sun, 23 Jan 2000 21:16:21 -0500 (EST) Received: by mailext04.compaq.com (Postfix, from userid 12345) id DF409104BD5; Sun, 23 Jan 2000 20:15:52 -0600 (CST) Received: from mailint02.im.hou.compaq.com (mailint02.compaq.com [207.18.199.35]) by mailext04.compaq.com (Postfix) with ESMTP id DA1DCFB101 for ; Sun, 23 Jan 2000 20:15:52 -0600 (CST) Received: by mailint02.im.hou.compaq.com (Postfix, from userid 12345) id 84DC7BC4CD; Sun, 23 Jan 2000 20:15:45 -0600 (CST) Received: from quarry.zk3.dec.com (quarry.zk3.dec.com [16.140.16.3]) by mailint02.im.hou.compaq.com (Postfix) with ESMTP id 3BF79B2A45 for ; Sun, 23 Jan 2000 20:15:45 -0600 (CST) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id VAA0000014845; Sun, 23 Jan 2000 21:15:51 -0500 (EST) From: Jim Bound Message-Id: <200001240215.VAA0000014845@quarry.zk3.dec.com> To: Subject: Re: DHCPv6 extension comments In-reply-to: Your message of "Sun, 23 Jan 2000 16:50:23 +0100." <200001231550.QAA10947@givry.inria.fr> Date: Sun, 23 Jan 2000 21:15:51 -0500 X-Mts: smtp Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Hi Francis, Charlie is responding to Rich's comments and we will discuss as a team tomorrow (Monday). But........... >DSTM needs this function then Jim should have the answer (:-)! I don't want to throw this into the extensions spec at this point and add a new extension and all the discussion it will take. Also I would l like to use the DSTM req as a means to put forth a new extension for DHCPv6 after we reach PS status. But this is on the agenda for the authors regular meeting tomorrow. As my coauthors of DSTM would like it to be part of the present exts draft too. Do you feel one way or the other? [p.s. You know where I am coming from on this. We will deploy DSTM in the market with or without the IETF, but still working with the IETF at this point and having forward progress but DHCPv6 is more immediate as one of the ngtrans chair (Alain Durand) stated to the DHCv6 WG at Wash D.C., ergo I don't want to do anything that will prevent an expedited DHCPv6 PS status, but maybe it would not to add the DSTM requirement]... thanks /jim From owner-dhcp-v6@bucknell.edu Sun Jan 23 22:49: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 WAA15549 for ; Sun, 23 Jan 2000 22:49:57 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id WAA01188; Sun, 23 Jan 2000 22:44:15 -0500 (EST) Received: from mail.ptd.net (mail2.ha-net.ptd.net [207.44.96.66]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id WAA03360 for ; Sun, 23 Jan 2000 22:44:11 -0500 (EST) Received: (qmail 26320 invoked from network); 24 Jan 2000 03:43:53 -0000 Received: from host22.bvtc.ptd.net (HELO droms-laptop) (209.173.2.22) by mail.ptd.net with SMTP; 24 Jan 2000 03:43:53 -0000 Message-Id: <4.2.2.20000123215956.00a6fc40@mail.bucknell.edu> X-Sender: droms@mail.bucknell.edu X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Sun, 23 Jan 2000 22:39:28 -0500 To: From: Ralph Droms Subject: Re: DHCPv6 extension comments In-Reply-To: <200001231550.QAA10947@givry.inria.fr> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN At 04:50 PM 1/23/00 +0100, Francis Dupont wrote: > In your previous mail you wrote: > > 3. IP Address Extension > > How would one handle IPv4 addresses using DHCPv6? Use v4-mapped address > format with the IP Address Extension, or define a new extension? > >=> DSTM needs this function then Jim should have the answer (:-)! DSTM? Can someone expand that FLA for me? - Ralph From owner-dhcp-v6@bucknell.edu Mon Jan 24 06:25:34 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01243 for ; Mon, 24 Jan 2000 06:25:34 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id GAA11548; Mon, 24 Jan 2000 06:21:19 -0500 (EST) Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id GAA17617 for ; Mon, 24 Jan 2000 06:21:06 -0500 (EST) Received: from givry.inria.fr (givry.inria.fr [193.51.193.144]) by concorde.inria.fr (8.8.7/8.8.7) with ESMTP id MAA15092 for ; Mon, 24 Jan 2000 12:21:03 +0100 (MET) Received: from givry.inria.fr (givry.inria.fr [193.51.193.144]) by givry.inria.fr (8.7.6/8.7.3) with ESMTP id MAA27548 for ; Mon, 24 Jan 2000 12:21:03 +0100 (MET) Message-Id: <200001241121.MAA27548@givry.inria.fr> From: Francis Dupont To: Subject: Re: DHCPv6 extension comments In-reply-to: Your message of Sun, 23 Jan 2000 21:15:51 EST. <200001240215.VAA0000014845@quarry.zk3.dec.com> Date: Mon, 24 Jan 2000 12:21:01 +0100 Sender: owner-dhcp-v6@bucknell.edu Reply-To: dhcp-v6@bucknell.edu X-Sender: Francis.Dupont@inria.fr X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN In your previous mail you wrote: >DSTM needs this function then Jim should have the answer (:-)! Do you feel one way or the other? => I think the *important* thing is to get the new & final I-D for DHCPv6 asap. DSTM details can go into DSTM I-D(s). Thanks Francis.Dupont@enst-bretagne.fr From owner-dhcp-v6@bucknell.edu Mon Jan 24 08:04: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 IAA04356 for ; Mon, 24 Jan 2000 08:04:00 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id IAA10448; Mon, 24 Jan 2000 08:00:05 -0500 (EST) Received: from mailext12.compaq.com (mailext12.compaq.com [207.18.199.188]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id IAA28093 for ; Mon, 24 Jan 2000 08:00:03 -0500 (EST) Received: by mailext12.compaq.com (Postfix, from userid 12345) id D3B0457856; Mon, 24 Jan 2000 07:00:02 -0600 (CST) Received: from mailint02.im.hou.compaq.com (mailint02.compaq.com [207.18.199.35]) by mailext12.compaq.com (Postfix) with ESMTP id D13F354602 for ; Mon, 24 Jan 2000 07:00:02 -0600 (CST) Received: by mailint02.im.hou.compaq.com (Postfix, from userid 12345) id 8ED37BC4C9; Mon, 24 Jan 2000 06:59:55 -0600 (CST) Received: from quarry.zk3.dec.com (quarry.zk3.dec.com [16.140.16.3]) by mailint02.im.hou.compaq.com (Postfix) with ESMTP id 43E32B2A47 for ; Mon, 24 Jan 2000 06:59:55 -0600 (CST) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id HAA0000019569; Mon, 24 Jan 2000 07:59:57 -0500 (EST) From: Jim Bound Message-Id: <200001241259.HAA0000019569@quarry.zk3.dec.com> To: Subject: Re: DHCPv6 extension comments In-reply-to: Your message of "Sun, 23 Jan 2000 22:39:28 EST." <4.2.2.20000123215956.00a6fc40@mail.bucknell.edu> Date: Mon, 24 Jan 2000 07:59:57 -0500 X-Mts: smtp Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Hi Ralph, >>=> DSTM needs this function then Jim should have the answer (:-)! > >DSTM? Can someone expand that FLA for me? See draft-ietf-ngtrans-dstm-01.txt its an ngtrans WG piece of work. Bottom line is this. Customer deploys IPv6 department at their site or in multiple sites. All nodes will be using IPv6 as the core prototocol. IPv4 is only needed when the node temporarily needs to use IPv4 via a Tunnel to speak with say an IPv4 Web Server. The DSTM mechanism has 3 parts. - Interation with DNS to find IPv6 Nodes in this environment - Dynamic Tunneling Interfaces on an implementation - Use of DHCPv6 by an IPv6 node to obtain a temporary IPv4 address via an IPv6 IPv4-Mapped Address or for a co-located DHCPv6/DNS server to dynamically assign an IPv6 node an IPv6 IPv4-Mapped Address. IPv6. This will require a new extension for DHCPv6 to provide an IPv6 IPv4-Mapped address. /jim From owner-dhcp-v6@bucknell.edu Mon Jan 24 08:11:14 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04604 for ; Mon, 24 Jan 2000 08:11:13 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id IAA05845; Mon, 24 Jan 2000 08:08:59 -0500 (EST) Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id IAA17296 for ; Mon, 24 Jan 2000 08:08:53 -0500 (EST) Received: from givry.inria.fr (givry.inria.fr [193.51.193.144]) by concorde.inria.fr (8.8.7/8.8.7) with ESMTP id OAA19910 for ; Mon, 24 Jan 2000 14:08:45 +0100 (MET) Received: from givry.inria.fr (givry.inria.fr [193.51.193.144]) by givry.inria.fr (8.7.6/8.7.3) with ESMTP id OAA15070 for ; Mon, 24 Jan 2000 14:08:44 +0100 (MET) Message-Id: <200001241308.OAA15070@givry.inria.fr> From: Francis Dupont To: Subject: Re: DHCPv6 extension comments In-reply-to: Your message of Sun, 23 Jan 2000 22:39:28 EST. <4.2.2.20000123215956.00a6fc40@mail.bucknell.edu> Date: Mon, 24 Jan 2000 14:08:44 +0100 Sender: owner-dhcp-v6@bucknell.edu Reply-To: dhcp-v6@bucknell.edu X-Sender: Francis.Dupont@inria.fr X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN In your previous mail you wrote: DSTM? Can someone expand that FLA for me? => DSTM is a IPv4->IPv6 transition tool (ie. in the ngtrans WG scope) using DHCPv6 reconfigure message for IPv4 temporary address assignment. It is a merge between AIIH (by Jim Bound) and DTI (by Laurent Toutain, a colleague) with IPv4 over IPv6 tunnels in place of header & address translation. The current position of the ngtrans WG is to not slow down DHCPv6 on its way on the standard path (:-) because of DSTM. Last I-D is draft-ietf-ngtrans-dstm-00.txt . Regards Francis.Dupont@inria.fr From owner-dhcp-v4@bucknell.edu Mon Jan 24 08:54: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 IAA06342 for ; Mon, 24 Jan 2000 08:54:33 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id IAA15183; Mon, 24 Jan 2000 08:53:43 -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 IAA04937 for ; Mon, 24 Jan 2000 08:52:47 -0500 (EST) Received: by fs-sd-exch1.coppermountain.com with Internet Mail Service (5.5.2448.0) id ; Mon, 24 Jan 2000 05:49:53 -0800 Message-ID: <47FEF5D2BE22D311AA8600508B108915999EAF@fs-sd-exch1.coppermountain.com> From: Eric Michelsen To: Subject: RE: Help! Static route option Date: Mon, 24 Jan 2000 05:49:52 -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 I believe this option is currently mandatory for configuring the default route in a host, which is one of the basic critical parameters that any host needs. We use it that way, and require its presence for that purpose. Oddly enough, in the default route case, defined by a destination address of 0.0.0.0, the netmask is meaningless, so I didn't even notice its absence. Note, though, that there are many such examples scattered about the IP standards. RIPv1 has no masks, and yet it is still commonly used. The mask is derived from the IP address class (A, B, or C). Though somewhat confusing, perhaps a reasonable interpretation of the static routes option is this: if the class-ful interpretation of the route has host bits set, it's a host route. Otherwise, it's a network route with the class-ful mask. ------------------------------------------- Eric L. Michelsen, Copper Mountain Networks > -----Original Message----- > From: Ted Lemon [mailto:mellon@isc.org] > Sent: Thursday, January 20, 2000 9:32 > To: dhcp-v4@bucknell.edu > Cc: dhcp-v4@bucknell.edu > Subject: Re: Help! Static route option > > > > > Although this option is to be superceded by an option with explicit > > masks, we should come to consensus about an interpretation and > > modify the text in the next rev of RFC2132. > > Is there any reason not to just say it's deprecated? Whichever of > the two choices is correct, the option is really not useful - at this > juncture, it is sheer coincidence if the "class" subnet mask and the > classless subnet mask are the same, and sheer coincidence is a lousy > basis for network protocols. :') > > _MelloN_ > From owner-dhcp-v4@bucknell.edu Mon Jan 24 09:12: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 JAA06927 for ; Mon, 24 Jan 2000 09:12:09 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id JAA32191; Mon, 24 Jan 2000 09:09:37 -0500 (EST) Received: from mw.3com.com (intergate.usr.com [149.112.20.3]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id JAA26950 for ; Mon, 24 Jan 2000 09:08:49 -0500 (EST) Received: from mwgate02.mw.3com.com by mw.3com.com (8.8.5/3.1.090690-3Com Corporation) id IAA12558; Mon, 24 Jan 2000 08:08:18 -0600 (CST) Received: by mwgate02.mw.3com.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 86256870.004DBE18 ; Mon, 24 Jan 2000 08:09:09 -0600 X-Lotus-FromDomain: 3COM@3COM-MWGATE From: "Mike Borella" To: Message-ID: <86256870.004DBDF3.00@mwgate02.mw.3com.com> Date: Mon, 24 Jan 2000 08:05:49 -0600 Subject: RE: I-D ACTION:draft-ietf-dhc-nextserver-00.txt Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Reply-To: Mike_Borella@mw.3com.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN The first two points are easily addressed. SLP is an option and I believe that some people are currently writing a draft. However, RSIP will be deployed on legacy networks that don't necessarily support SLP. Having an emerging technology rely on another emerging technology is not a robust solution, especially given that DHCP solves the problem in a very elegant fashion. -Mike dhcp-v4@bucknell.edu on 01/21/2000 10:59:21 PM Sent by: dhcp-v4@bucknell.edu To: dhcp-v4@bucknell.edu cc: (Mike Borella/MW/US/3Com) Subject: DHCP-V4 digest 13 DHCP-V4 Digest 13 Topics covered in this issue include: 1) RE: I-D ACTION:draft-ietf-dhc-nextserver-00.txt by "Henry, Mike" Message-ID: From: "Henry, Mike" To: Subject: RE: I-D ACTION:draft-ietf-dhc-nextserver-00.txt Date: Fri, 21 Jan 2000 10:55:42 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1252" It seems to me that that the draft has a number of weaknesses. It relies os an explicit IP address, and only one address. That is, there is no provision for more than one secondary config server of a particular type. At a minimum, the ability to provide a list of IP addresses for the client to try would provide some robustness to address the case where the one and only secondary config server is down. Also, there is the question of config server types.... how does one define a third or fourth type beyond DHCP and RSIP-FRAME? Perhaps it would make sense to propose an IANA administered list so vendors with new config server types could simply register the type? Finally, it really seems to me that this is just the sort of thing that SLP (Service Location Protocol) was designed to address. Rather than an ad hoc option to address this particular case, why not discover the secondary config server via SLP? This gets the DHCP admin out of the business of tracking yet another special server type as being of interest to his/her community, and gets the admin out of the business of tracking down and maintaining the server's IP address in this context. Mike H. Intel -----Original Message----- From: jerome.privat@bt.com [mailto:jerome.privat@bt.com] Sent: Thursday, January 20, 2000 8:58 AM To: dhcp-v4@bucknell.edu Subject: RE: I-D ACTION:draft-ietf-dhc-nextserver-00.txt This new proposed option is pretty straightforward and can be used by a DHCP server to redirect a client to a secondary configuration server. If you have comments on the draft, please send them to the list. Thanks, Jerome Privat, BT -----Original Message----- From: Ralph Droms [mailto:droms@bucknell.edu] Sent: 20 January 2000 13:38 To: dhcp-v4 Subject: I-D ACTION:draft-ietf-dhc-nextserver-00.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-00.txt Pages : 6 Date : 19-Jan-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-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-nextserver-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-nextserver-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: <20000119140436.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-nextserver-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-nextserver-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000119140436.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-dhcp-v4@bucknell.edu Mon Jan 24 09:29:55 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07830 for ; Mon, 24 Jan 2000 09:29:54 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id JAA16506; Mon, 24 Jan 2000 09:29:04 -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 JAA06095 for ; Mon, 24 Jan 2000 09:28:52 -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 GAA06364; Mon, 24 Jan 2000 06:23:13 -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 JAA07048; Mon, 24 Jan 2000 09:27:02 -0500 (EST) Message-Id: <200001241427.JAA07048@grosse.manhattan.fugue.com> To: cc: dhcp-v4@bucknell.edu Subject: Re: Help! Static route option In-Reply-To: Message from Eric Michelsen of "Mon, 24 Jan 2000 05:49:52 PST." <47FEF5D2BE22D311AA8600508B108915999EAF@fs-sd-exch1.coppermountain.com> Date: Mon, 24 Jan 2000 09:27:01 -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 this option is currently mandatory for configuring the default > route in a host Actually, you can use the routers option to configure the default route. That's what, e.g., Windows 95 does. I don't *think* Win95 will even take the default route from the static routes option, although I could be mistaken. > Though somewhat confusing, perhaps a reasonable interpretation of the static > routes option is this: if the class-ful interpretation of the route has host > bits set, it's a host route. Otherwise, it's a network route with the > class-ful mask. The protocol specification doesn't say this, so I think it would be a mistake to assume it. This option is simply not useful anymore, and hasn't been for several years. The right thing to do is deprecate it. _MelloN_ From owner-dhcp-v4@bucknell.edu Mon Jan 24 10:23: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 KAA10475 for ; Mon, 24 Jan 2000 10:23:22 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id KAA16609; Mon, 24 Jan 2000 10:21:25 -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 KAA16370 for ; Mon, 24 Jan 2000 10:20:43 -0500 (EST) Received: by fs-sd-exch1.coppermountain.com with Internet Mail Service (5.5.2448.0) id ; Mon, 24 Jan 2000 07:17:58 -0800 Message-ID: <47FEF5D2BE22D311AA8600508B108915999EB4@fs-sd-exch1.coppermountain.com> From: Eric Michelsen To: Cc: dhcp-v4@bucknell.edu Subject: RE: Help! Static route option Date: Mon, 24 Jan 2000 07:17:57 -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 I'm all for deprecating it when the route-with-mask option is available. Even so, it will take a while before all the DHCP servers support it, so it may still be reasonable to clarify its use until a better option is available. ------------------------------------------- Eric L. Michelsen, Copper Mountain Networks > -----Original Message----- > From: Ted Lemon [mailto:mellon@isc.org] > Sent: Monday, January 24, 2000 6:27 > To: emichelsen@coppermountain.com > Cc: dhcp-v4@bucknell.edu > Subject: Re: Help! Static route option > > > > > I believe this option is currently mandatory for > configuring the default > > route in a host > > Actually, you can use the routers option to configure the default > route. That's what, e.g., Windows 95 does. I don't *think* Win95 > will even take the default route from the static routes option, > although I could be mistaken. > > > Though somewhat confusing, perhaps a reasonable > interpretation of the static > > routes option is this: if the class-ful interpretation of > the route has host > > bits set, it's a host route. Otherwise, it's a network > route with the > > class-ful mask. > > The protocol specification doesn't say this, so I think it would be a > mistake to assume it. This option is simply not useful anymore, and > hasn't been for several years. The right thing to do is deprecate > it. > > _MelloN_ > From owner-dhcp-v4@bucknell.edu Mon Jan 24 10:27: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 KAA10696 for ; Mon, 24 Jan 2000 10:27:53 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id KAA22672; Mon, 24 Jan 2000 10:26:18 -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 KAA09888 for ; Mon, 24 Jan 2000 10:26:06 -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 HAA06585; Mon, 24 Jan 2000 07:20:31 -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 KAA07500; Mon, 24 Jan 2000 10:24:19 -0500 (EST) Message-Id: <200001241524.KAA07500@grosse.manhattan.fugue.com> To: cc: dhcp-v4@bucknell.edu Subject: Re: Help! Static route option In-Reply-To: Message from Eric Michelsen of "Mon, 24 Jan 2000 07:17:57 PST." <47FEF5D2BE22D311AA8600508B108915999EB4@fs-sd-exch1.coppermountain.com> Date: Mon, 24 Jan 2000 10:24:18 -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'm all for deprecating it when the route-with-mask option is available. > Even so, it will take a while before all the DHCP servers support it, so it > may still be reasonable to clarify its use until a better option is > available. Clarifying it doesn't make sense when talking about existing implementations - they are already doing whatever they're going to do, which normally will be to not request the option and to ignore it if it's received. We don't _want_ future implementations, so clarification doesn't help there either. The current option _doesn't work_, so there is simply no point in anybody ever implementing it, clarification or no. I will try to have a draft out today for a classless static routes option, and then we can stop arguing about this. _MelloN_ From owner-dhcp-v4@bucknell.edu Mon Jan 24 10:48:53 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11520 for ; Mon, 24 Jan 2000 10:48:49 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id KAA27855; Mon, 24 Jan 2000 10:48:08 -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 KAA13380 for ; Mon, 24 Jan 2000 10:47:57 -0500 (EST) Received: by process.com (MX V5.1-X A2w8g) id 242; Mon, 24 Jan 2000 10:47:24 -0400 Sender: owner-dhcp-v4@bucknell.edu Date: Mon, 24 Jan 2000 10:47:24 -0400 From: Bernie Volz To: Message-ID: <009E49E0.DC8B5D6F.242@process.com> Subject: Re: Help! Static route option Reply-To: volz@process.com X-Sender: volz@process.com X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN >> I'm all for deprecating it when the route-with-mask option is available. >> Even so, it will take a while before all the DHCP servers support it, so it >> may still be reasonable to clarify its use until a better option is >> available. > >Clarifying it doesn't make sense when talking about existing >implementations - they are already doing whatever they're going to do, >which normally will be to not request the option and to ignore it if >it's received. We don't _want_ future implementations, so >clarification doesn't help there either. > >The current option _doesn't work_, so there is simply no point in >anybody ever implementing it, clarification or no. I will try to >have a draft out today for a classless static routes option, and then >we can stop arguing about this. > > _MelloN_ > While I agree that this option should be depreciated (and am all for a new option with the mask), IF there are clients that use it, it would be nice to hear from these client implementors to understand how they are currently interpreting it such that if someone needed to use it, they could. If most clients ignore it, that would be useful to know as well (since it makes depreciating it easier). So, if any DHCP Client implementors care to comment on how they process this option (or if they don't), please send to the list. - Bernie Volz Process Software From owner-dhcp-v4@bucknell.edu Mon Jan 24 11:02: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 LAA11991 for ; Mon, 24 Jan 2000 11:02:17 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id KAA01745; Mon, 24 Jan 2000 10:59:49 -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 KAA21944 for ; Mon, 24 Jan 2000 10:59:34 -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 HAA06733; Mon, 24 Jan 2000 07:53:26 -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 KAA07619; Mon, 24 Jan 2000 10:57:14 -0500 (EST) Message-Id: <200001241557.KAA07619@grosse.manhattan.fugue.com> To: cc: dhcp-v4@bucknell.edu Subject: Re: Help! Static route option In-Reply-To: Message from Bernie Volz of "Mon, 24 Jan 2000 10:47:24 -0400." <009E49E0.DC8B5D6F.242@process.com> Date: Mon, 24 Jan 2000 10:57:14 -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 > So, if any DHCP Client implementors care to comment on how they process > this option (or if they don't), please send to the list. I actually implemented it, using standard classful routing. I implemented no cleverness at all - it just does exactly what you'd expect in a classful routing environment. :') I'm pretty sure Win95 ignores this option, but I'd be interested in hearing the official word from Microsoft. _MelloN_ From owner-dhcp-v4@bucknell.edu Mon Jan 24 11:41:11 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13570 for ; Mon, 24 Jan 2000 11:41:10 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id LAA18357; Mon, 24 Jan 2000 11:39:15 -0500 (EST) Received: from droms-laptop (droms.eg.bucknell.edu [134.82.56.71]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id LAA04108 for ; Mon, 24 Jan 2000 11:39:03 -0500 (EST) Message-Id: <4.2.2.20000124113732.00a3f380@mail.bucknell.edu> X-Sender: droms@mail.bucknell.edu X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Mon, 24 Jan 2000 11:38:37 -0500 To: From: Ralph Droms Subject: RE: Help! Static route option 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 Message originally sent by Lars Viklund : > From: Bernie Volz [mailto:volz@PROCESS.COM] > Subject: Re: Help! Static route option > So, if any DHCP Client implementors care to comment on how > they process > this option (or if they don't), please send to the list. We ignore it. Also, note that RFC 2132 says that the default route is an illegal destination for a static route. -- Lars Viklund Axis Communications AB SE-223 70 Lund, Sweden From owner-dhcp-v6@bucknell.edu Mon Jan 24 11:41: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 LAA13585 for ; Mon, 24 Jan 2000 11:41:35 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id LAA12471; Mon, 24 Jan 2000 11:26:59 -0500 (EST) Received: from droms-laptop (droms.eg.bucknell.edu [134.82.56.71]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id LAA19836 for ; Mon, 24 Jan 2000 11:26:46 -0500 (EST) Message-Id: <4.2.2.20000124112025.00a77130@mail.bucknell.edu> X-Sender: droms@mail.bucknell.edu X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Mon, 24 Jan 2000 11:21:43 -0500 To: From: Ralph Droms Subject: Re: DHCPv6 extension comments In-Reply-To: <200001241259.HAA0000019569@quarry.zk3.dec.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN At 07:59 AM 1/24/00 -0500, Jim Bound wrote: >Hi Ralph, > > >>=> DSTM needs this function then Jim should have the answer (:-)! > > > >DSTM? Can someone expand that FLA for me? > >See draft-ietf-ngtrans-dstm-01.txt its an ngtrans WG piece of work. Thanks for the clarification, Jim... - Ralph From owner-dhcp-v4@bucknell.edu Mon Jan 24 19:55: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 TAA01263 for ; Mon, 24 Jan 2000 19:55:10 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id TAA23489; Mon, 24 Jan 2000 19:53:13 -0500 (EST) Received: from luna.join.com (ns.join.com [209.125.77.130]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id TAA09615 for ; Mon, 24 Jan 2000 19:52:26 -0500 (EST) Received: from MAUI (133.0012189.lodgenet.net [12.26.70.133] (may be forged)) by luna.join.com (8.8.8/8.8.8) with SMTP id QAA03097 for ; Mon, 24 Jan 2000 16:52:19 -0800 (PST) Received: by MAUI with Microsoft Mail id <01BF668C.3E4BE8C0@MAUI>; Mon, 24 Jan 2000 16:58:31 -0000 Message-ID: <01BF668C.3E4BE8C0@MAUI> From: Rob Stevens To: Subject: RE: Help! Static route option Date: Mon, 24 Jan 2000 16:58:24 -0000 Encoding: 31 TEXT Reply-To: robs@join.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN -----Original Message----- From: Ralph Droms [SMTP:droms@bucknell.edu] Sent: Monday, January 24, 2000 4:39 PM To: dhcp-v4@bucknell.edu Subject: RE: Help! Static route option Message originally sent by Lars Viklund : > From: Bernie Volz [mailto:volz@PROCESS.COM] > Subject: Re: Help! Static route option > So, if any DHCP Client implementors care to comment on how > they process > this option (or if they don't), please send to the list. [] We neither ignore nor use it. The client writes a database which can be interrogated by programs interested in discovering what was returned by DHCP (Typically startup scripts used in booting Unix workstations). Interrogating this option would give you a list of IP address pairs. How those are interpreted is up to whoever is reading them. In general our client does not use directly use options which don't affect the state diagram of the DHCP protocol (so the gateway, IP address, Mask are all things which the client would use). Rob From owner-dhcp-v6@bucknell.edu Wed Jan 26 17:05: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 RAA12377 for ; Wed, 26 Jan 2000 17:05:52 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id QAA21678; Wed, 26 Jan 2000 16:53:28 -0500 (EST) Received: from hygro.adsl.duke.edu (hygro.adsl.duke.edu [152.16.64.159]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id QAA15187 for ; Wed, 26 Jan 2000 16:53:16 -0500 (EST) Received: from hygro.adsl.duke.edu (IDENT:narten@localhost.localdomain [127.0.0.1]) by hygro.adsl.duke.edu (8.9.3/8.9.3) with ESMTP id QAA00879 for ; Wed, 26 Jan 2000 16:53:19 -0500 Message-Id: <200001262153.QAA00879@hygro.adsl.duke.edu> To: Subject: Re: DHCPv6 comments In-Reply-To: Message from Richard Draves of "Fri, 21 Jan 2000 03:02:10 PST." <4D0A23B3F74DD111ACCD00805F31D8101EDBCBE3@RED-MSG-50> Date: Wed, 26 Jan 2000 16:53:18 -0500 From: Thomas Narten 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 Richard Draves writes: > Here's an idea: > The relay should only participate in Solicit/Advertise messages. Once the > client discovers server/relay addresses, the client and the server > communicate directly with each other. If the client's link-local address is > the IP source or destination and the server is off-link (relay address != > server address), then a routing header is used to route the packet via the > relay. For one thing, this would require changing existing (non-DHCP) specs and router implementations. I.e., the current semantics of the routing header don't say anything about what to do if the destination address by itself is insufficient to deterimine which outgoing interface (or more generally which scope) the destination address corresponds to. In the case of DHCP, where the client address is link-local, it isn't clear which outgoing interface to send the packet on. In the case of DHCP relays, the obvious thing to do is send it out on the interface corresponding to the address of the relay agent in the routing header. But this is not something that existing specs say to do or even if it is the right general semantic to have. Also, my recollection of long-ago discussion was that forwarding packets beyond the scope of their source addresses was not something to be encouraged, as this proposal would. The idea of using a general-purpose technique rather than something DHCP-specific is certainly appealing though! Thomas From owner-dhcp-v4@bucknell.edu Thu Jan 27 14:20: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 OAA12466 for ; Thu, 27 Jan 2000 14:20:38 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id OAA23829; Thu, 27 Jan 2000 14:18:32 -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 OAA01128 for ; Thu, 27 Jan 2000 14:17:36 -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 OAA25848 for ; Thu, 27 Jan 2000 14:17:35 -0500 (EST) Message-Id: <4.2.2.20000127141231.00a6c2a0@mail.bucknell.edu> X-Sender: droms@mail.bucknell.edu X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Thu, 27 Jan 2000 14:17:08 -0500 To: From: Ralph Droms Subject: WG last call: DHCP for IEEE 1394 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 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 Fri Jan 28 08:47: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 IAA09949 for ; Fri, 28 Jan 2000 08:47:47 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id IAA27764; Fri, 28 Jan 2000 08:47:14 -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 IAA25152 for ; Fri, 28 Jan 2000 08:46:52 -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 IAA26542 for ; Fri, 28 Jan 2000 08:46:51 -0500 (EST) Message-Id: <4.2.2.20000128084528.00a65160@mail.bucknell.edu> X-Sender: droms@mail.bucknell.edu X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Fri, 28 Jan 2000 08:46:48 -0500 To: From: Ralph Droms Subject: I-D ACTION:draft-ietf-dhc-agent-options-08.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 Relay Agent Information Option Author(s) : M. Patrick Filename : draft-ietf-dhc-agent-options-08.txt Pages : 14 Date : 27-Jan-00 Newer high-speed public Internet access technologies call for a high-speed modem to have a LAN attachment to one or more customer premise hosts. It is advantageous to use the Dynamic Host Configuration Protocol as defined in RFC 2131 [1] to assign customer premise host IP addresses in this environment. However, a number of security and scaling problems arise with such 'public' DHCP use. This document describes a new DHCP option to address these issues. This option extends the set of DHCP options as defined in RFC 2132 [2]. The new option is called the Relay Agent Information option and is inserted by the DHCP relay agent when forwarding client-originated DHCP packets to a DHCP server. Servers recognizing the Relay Agent Information option may use the information to implement IP address or other parameter assignment policies. The DHCP Server echoes the option back verbatim to the relay agent in server-to-client replies, and the relay agent strips the option before forwarding the reply to the client. The 'Relay Agent Information' option is organized as a single DHCP option that contains one or more 'sub-options' that convey information known by the relay agent. The initial sub-options are defined for a relay agent that is co-located in a public circuit access unit. These include a 'circuit ID' for the incoming circuit, a 'remote ID' which provides a trusted identifier for the remote high-speed modem, and the 'subnet mask' of the logical IP subnet from which the relay agent received the client DHCP packet. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-agent-options-08.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dhc-agent-options-08.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dhc-agent-options-08.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000127125852.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-agent-options-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-agent-options-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000127125852.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-dhcp-v4@bucknell.edu Fri Jan 28 09:14: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 JAA11299 for ; Fri, 28 Jan 2000 09:14:02 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id JAA29202; Fri, 28 Jan 2000 09:13:40 -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 JAA01168 for ; Fri, 28 Jan 2000 09:13:37 -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 JAA26567 for ; Fri, 28 Jan 2000 09:13:37 -0500 (EST) Message-Id: <4.2.2.20000128090949.00a68770@mail.bucknell.edu> X-Sender: droms@mail.bucknell.edu X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Fri, 28 Jan 2000 09:12:14 -0500 To: From: Ralph Droms Subject: WG Last Call for "DHCP Relay Agent Information Option" I-D 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 This is the WG last call for "DHCP Relay Agent Information Option", . If you have any comments about this I-D, please respond to this mailing list. The last call discussion will close on Wednesday, 2/9. - Ralph Droms From owner-dhcp-v4@bucknell.edu Fri Jan 28 11:30: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 LAA17847 for ; Fri, 28 Jan 2000 11:30:20 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id LAA11075; Fri, 28 Jan 2000 11:29:25 -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 LAA06054; Fri, 28 Jan 2000 11:29:10 -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 IAA04614; Fri, 28 Jan 2000 08:23:24 -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 LAA14340; Fri, 28 Jan 2000 11:28:56 -0500 (EST) Message-Id: <200001281628.LAA14340@grosse.manhattan.fugue.com> To: cc: dhcp-v4@bucknell.edu Subject: Re: WG Last Call for "DHCP Relay Agent Information Option" I-D In-Reply-To: Message from Ralph Droms of "Fri, 28 Jan 2000 09:12:14 EST." <4.2.2.20000128090949.00a68770@mail.bucknell.edu> Date: Fri, 28 Jan 2000 11:28: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 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 Fri Jan 28 14:53:32 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25225 for ; Fri, 28 Jan 2000 14:53:26 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id OAA27274; Fri, 28 Jan 2000 14:52:21 -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 OAA04314 for ; Fri, 28 Jan 2000 14:51:47 -0500 (EST) Received: by fs-sd-exch1.coppermountain.com with Internet Mail Service (5.5.2448.0) id ; Fri, 28 Jan 2000 11:48:47 -0800 Message-ID: <47FEF5D2BE22D311AA8600508B108915999ECF@fs-sd-exch1.coppermountain.com> From: Eric Michelsen To: Subject: RE: Help! Static route option Date: Fri, 28 Jan 2000 11:48:46 -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 I mispoke about our imlementation using static routes for the default router. That is explicitly forbidden in RFC-2132, and we do the right thing. More below: > -----Original Message----- > From: Ted Lemon [mailto:mellon@isc.org] > Sent: Monday, January 24, 2000 7:24 > To: dhcp-v4@bucknell.edu > Cc: dhcp-v4@bucknell.edu > Subject: Re: Help! Static route option > > > I'm all for deprecating it when the route-with-mask option > is available. > > Even so, it will take a while before all the DHCP servers > support it, so it > > may still be reasonable to clarify its use until a better option is > > available. > > Clarifying it doesn't make sense when talking about existing > implementations - they are already doing whatever they're going to do, > which normally will be to not request the option and to ignore it if > it's received. We don't _want_ future implementations, so > clarification doesn't help there either. The point is that there are existing *servers* which support the existing options. Those servers won't go away overnight. In the meantime, there are *new client* implementations, which may be forced to work with older servers. Therefore, it *does* make sense to define how new clients should interpret the older option. > The current option _doesn't work_, so there is simply no point in > anybody ever implementing it, clarification or no. I will try to > have a draft out today for a classless static routes option, and then > we can stop arguing about this. I disagree that it doesn't work. It works fine in any situation that requires only class-ful routes to be delieverd in DHCP responses. This restriction doesn't limit your whole network, or even the DHCP client, to class-ful routing. It simply means that for the 1 or 2 routes you might plug into your DHCP server, they have to be class-ful. Similarly, RIPv1 works fine, too. There are thousands, if not millions, of RIPv1 implementations working today with standard class-ful routing interpretation of routes-without-masks. Frankly, why would anyone put static routes in their DHCP responses anyway? Isn't that what ICMP Redirects are for? Or is this meant for DHCP clients which are actually routers, and get their routing information from the DHCP server? From owner-dhcp-v4@bucknell.edu Fri Jan 28 14:56: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 OAA25315 for ; Fri, 28 Jan 2000 14:56:25 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id OAA14438; Fri, 28 Jan 2000 14:56:03 -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 OAA15928 for ; Fri, 28 Jan 2000 14:55: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 LAA05605; Fri, 28 Jan 2000 11:50:05 -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 OAA15455; Fri, 28 Jan 2000 14:55:35 -0500 (EST) Message-Id: <200001281955.OAA15455@grosse.manhattan.fugue.com> To: cc: dhcp-v4@bucknell.edu Subject: Re: Help! Static route option In-Reply-To: Message from Eric Michelsen of "Fri, 28 Jan 2000 11:48:46 PST." <47FEF5D2BE22D311AA8600508B108915999ECF@fs-sd-exch1.coppermountain.com> Date: Fri, 28 Jan 2000 14:55:35 -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 mispoke about our imlementation using static routes for the default > router. That is explicitly forbidden in RFC-2132, and we do the right > thing. That's good to hear. > The point is that there are existing *servers* which support the existing > options. Those servers won't go away overnight. In the meantime, there are > *new client* implementations, which may be forced to work with older > servers. Therefore, it *does* make sense to define how new clients should > interpret the older option. Nope. Sorry. The option doesn't work, so existing servers that support it might as well not support it, for all the good it will do for clients. > I disagree that it doesn't work. It works fine in any situation that > requires only class-ful routes to be delieverd in DHCP responses. This > restriction doesn't limit your whole network, or even the DHCP client, to > class-ful routing. It simply means that for the 1 or 2 routes you might > plug into your DHCP server, they have to be class-ful. Right. Unfortunately, class-ful routes are as rare as hen's teeth nowadays. Furthermore, the behaviour of the client when presented with a class-ful route is already well-defined, so no further action needs to be taken. > Frankly, why would anyone put static routes in their DHCP responses anyway? > Isn't that what ICMP Redirects are for? Or is this meant for DHCP clients > which are actually routers, and get their routing information from the DHCP > server? I think it's there for completeness, actually. The netmasked routes option could be useful in some corner cases, but by and large you're right that it would be better to use RIP or OSPF to distribute the routes. ICMP redirects, maybe not - most people disable routing updates via ICMP redirect these days. _MelloN_ From owner-dhcp-v4@bucknell.edu Fri Jan 28 16:45: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 QAA27741 for ; Fri, 28 Jan 2000 16:45:53 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id QAA19500; Fri, 28 Jan 2000 16:45:13 -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 QAA17866 for ; Fri, 28 Jan 2000 16:45:05 -0500 (EST) Received: by fs-sd-exch1.coppermountain.com with Internet Mail Service (5.5.2448.0) id ; Fri, 28 Jan 2000 13:41:59 -0800 Message-ID: <47FEF5D2BE22D311AA8600508B108915999ED1@fs-sd-exch1.coppermountain.com> From: Eric Michelsen To: Subject: RE: Help! Static route option Date: Fri, 28 Jan 2000 13:41:55 -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 ... > > I disagree that it doesn't work. It works fine in any > situation that > > requires only class-ful routes to be delieverd in DHCP > responses. This > > restriction doesn't limit your whole network, or even the > DHCP client, to > > class-ful routing. It simply means that for the 1 or 2 > routes you might > > plug into your DHCP server, they have to be class-ful. > > Right. Unfortunately, class-ful routes are as rare as hen's teeth > nowadays. Furthermore, the behaviour of the client when presented > with a class-ful route is already well-defined, so no further action > needs to be taken. I guess I'm lost. If the behavior of the client is already well defined, then what is the issue being debated right now? Here's the original email that started this thread: > -----Original Message----- > From: Ralph Droms [mailto:droms@bucknell.edu] > Sent: Wednesday, January 19, 2000 6:06 > To: dhcp-v4@bucknell.edu > Cc: cheshire@apple.com > Subject: Help! Static route option > > > Mail sent to dhcpv4@bucknell.edu by cheshire@apple.com: > > A quick question. > > For the old DHCP Static Route Option (33) that has no mask, > what is the > effective mask supposed to be? > > Mac OS Open Transport currently uses a mask of all-ones, apparently in > the assumption that a route without a mask must necessarily be a host > route. > > I'm wondering if maybe the intention of the Static Route > Option was that > the mask should be derived programmatically from the class of the > destination address, in the old sense of Class A, Class B, Class C. In > other words, a route to destination 36.0.0.0 is assumed to > have a /8 mask > because it is a Class A address. However, what would you do if the > destination were 36.17.23.194? That's a Class A address, but > it has ones > in the host part, so it can't possibly be a route to net 36/8. > > RFC 2132 doesn't provide any clarification on this. > > (I know Static Route Pption is due to be replaced by "Static > routes with > subnet masks option", but we'd still like to handle the old > option in a > sane way too.) From owner-dhcp-v4@bucknell.edu Fri Jan 28 17:06:15 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28097 for ; Fri, 28 Jan 2000 17:06:11 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id RAA19553; Fri, 28 Jan 2000 17:05:55 -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 RAA24130 for ; Fri, 28 Jan 2000 17:05:23 -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 NAA06185; Fri, 28 Jan 2000 13:59:22 -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 RAA16184; Fri, 28 Jan 2000 17:04:54 -0500 (EST) Message-Id: <200001282204.RAA16184@grosse.manhattan.fugue.com> To: cc: dhcp-v4@bucknell.edu Subject: Re: Help! Static route option In-Reply-To: Message from Eric Michelsen of "Fri, 28 Jan 2000 13:41:55 PST." <47FEF5D2BE22D311AA8600508B108915999ED1@fs-sd-exch1.coppermountain.com> Date: Fri, 28 Jan 2000 17:04:54 -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 guess I'm lost. If the behavior of the client is already well defined, > then what is the issue being debated right now? Here's the original email > that started this thread: Right, MacOS is doing something that is clearly the wrong thing. But it doesn't matter, because really there _is_ no right thing. There is a cost associated with pushing through new drafts. The default routes option is defined to do a particular thing which is not useful. If we define some new behaviour for it, that doesn't solve anything, because somebody might continue to use the old behaviour. So it's not worth the effort to push through a new draft "clarifying" the old option - it would not do any good. _MelloN_ From owner-dhcp-v4@bucknell.edu Fri Jan 28 18:35: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 SAA29676 for ; Fri, 28 Jan 2000 18:35:38 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id SAA10214; Fri, 28 Jan 2000 18:34:08 -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 SAA21490 for ; Fri, 28 Jan 2000 18:33:47 -0500 (EST) Received: by fs-sd-exch1.coppermountain.com with Internet Mail Service (5.5.2448.0) id ; Fri, 28 Jan 2000 15:30:53 -0800 Message-ID: <47FEF5D2BE22D311AA8600508B108915999ED6@fs-sd-exch1.coppermountain.com> From: Eric Michelsen To: Subject: RE: Help! Static route option Date: Fri, 28 Jan 2000 15:30:45 -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 Well, I respectfully disagree. There is a right thing, and it is clearly for the client to use the class-ful mask, as is done in similar situations such as RIPv1. In fact, that seems so clear to me, that it hardly needs clarification. >From the original request, something that is slightly less clear is: what if the destination includes host-bits in the classfull destination IP address? I think the obvious thing to do is interpret this as a host route. If the class-ful interpretation is inadequate for the job, an installation will have to use another method than DHCP. There is no harm in adding clarity to an option. If you don't like the option, you don't have to use or support it. ------------------------------------------- Eric L. Michelsen, Copper Mountain Networks > -----Original Message----- > From: Ted Lemon [mailto:mellon@isc.org] > Sent: Friday, January 28, 2000 14:05 > To: dhcp-v4@bucknell.edu > Cc: dhcp-v4@bucknell.edu > Subject: Re: Help! Static route option > > > > > I guess I'm lost. If the behavior of the client is already > well defined, > > then what is the issue being debated right now? Here's the > original email > > that started this thread: > > Right, MacOS is doing something that is clearly the wrong thing. > But it doesn't matter, because really there _is_ no right thing. > There is a cost associated with pushing through new drafts. The > default routes option is defined to do a particular thing which is not > useful. If we define some new behaviour for it, that doesn't solve > anything, because somebody might continue to use the old behaviour. > So it's not worth the effort to push through a new draft "clarifying" > the old option - it would not do any good. > > _MelloN_ > From owner-dhcp-v4@bucknell.edu Fri Jan 28 18:47: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 SAA29790 for ; Fri, 28 Jan 2000 18:46:14 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id SAA13198; Fri, 28 Jan 2000 18:44:55 -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 SAA27031 for ; Fri, 28 Jan 2000 18:44:30 -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 PAA06513; Fri, 28 Jan 2000 15:38:51 -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 SAA16457; Fri, 28 Jan 2000 18:44:23 -0500 (EST) Message-Id: <200001282344.SAA16457@grosse.manhattan.fugue.com> To: cc: dhcp-v4@bucknell.edu Subject: Re: Help! Static route option In-Reply-To: Message from Eric Michelsen of "Fri, 28 Jan 2000 15:30:45 PST." <47FEF5D2BE22D311AA8600508B108915999ED6@fs-sd-exch1.coppermountain.com> Date: Fri, 28 Jan 2000 18:44: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 > There is a right thing, and it is clearly > for the client to use the class-ful mask, as is done in similar situations > such as RIPv1. In fact, that seems so clear to me, that it hardly needs > clarification. I agree completely with this, except that the right thing in this case simply isn't very useful. > There is no harm in adding clarity to an option. If you don't like the > option, you don't have to use or support it. I think it would be fine, next time we rev rfc2132, to cross-reference with RFC791 and RFC950 to indicate what network masks to use with this option. I just don't think we should go to any extra effort prior to revising rfc2132, if and when that happens. I think I've been responding in an unhelpful way on this, because I thought you were proposing that we specify *new* behaviour, rather than clarifying the existing, intended behaviour. Sorry about that. :'{ _MelloN_ From owner-dhcp-v4@bucknell.edu Sun Jan 30 08:52: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 IAA08747 for ; Sun, 30 Jan 2000 08:52:23 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id IAA32530; Sun, 30 Jan 2000 08:51:59 -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 IAA02577 for ; Sun, 30 Jan 2000 08:51:26 -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 IAA27756 for ; Sun, 30 Jan 2000 08:51:25 -0500 (EST) Message-Id: <4.2.2.20000130084727.00a78480@mail.bucknell.edu> X-Sender: droms@mail.bucknell.edu X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Sun, 30 Jan 2000 08:48:39 -0500 To: From: Ralph Droms Subject: RE: Help! Static route option 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 Mail sent by Stuart Cheshire, cheshire@apple.com: >While I agree that this option should be depreciated (and am all for a >new option with the mask), IF there are clients that use it, it would be >nice to hear from these client implementors to understand how they are >currently interpreting it such that if someone needed to use it, they >could. I totally agree that the option ought to be deprecated. However, *IF* some DHCP server administrator out there decides to use it, I'd like Mac OS to do something sensible. When customers want to buy our computers and use them in a particular way, it is hard for Apple to take a political stance and obstruct them unless there's a *really* good reason to do that. In that spirit, this is the code I've decided to use: #define ClassMaskOf(X) \ ((((X) & 0x80000000) == 0 ) ? 0xff000000 : \ (((X) & 0xC0000000) == 0x80000000) ? 0xffff0000 : \ (((X) & 0xE0000000) == 0xC0000000) ? 0xffffff00 : 0xffffffff ) mask = ClassMaskOf(rtToAddr); if (rtToAddr & ~mask) mask = ~0; If the destination makes sense as an old-style classful network number, then I use that mask. If it has non-zero bits anywhere in the host part, then I set the mask to all ones to make it a host route. I hope this is the last time I have to look at that code. I will of course add support for routes with masks as soon as it is standardized. Stuart Cheshire * Web Page * Wizard Without Portfolio, Apple Computer