From mailman-admin@ietf.org Sat Feb 1 11:04:05 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09691 for ; Sat, 1 Feb 2003 11:04:05 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h11G89J20908 for ; Sat, 1 Feb 2003 11:08:09 -0500 Date: Sat, 01 Feb 2003 11:08:09 -0500 Message-ID: <20030201160809.8821.59831.Mailman@www1.ietf.org> Subject: ietf.org mailing list memberships reminder From: mailman-owner@www1.ietf.org To: DHC-ARCHIVE@ietf.org X-No-Archive: yes X-Ack: no Sender: mailman-admin@ietf.org Errors-To: mailman-admin@ietf.org X-BeenThere: mailman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, dhcwg-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. *************************************************************************** Note Well All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to * the IETF plenary session, * any IETF working group or portion thereof, * the IESG, or any member thereof on behalf of the IESG, * the IAB or any member thereof on behalf of the IAB, * any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, * the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. *************************************************************************** If you have questions, problems, comments, etc, send them to mailman-owner@www1.ietf.org. Thanks! Passwords for DHC-ARCHIVE@lists.ietf.org: List Password // URL ---- -------- dhcwg@ietf.org aCBd https://www1.ietf.org/mailman/options/dhcwg/dhc-archive%40lists.ietf.org From dhcwg-admin@ietf.org Sun Feb 2 17:27:28 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12910; Sun, 2 Feb 2003 17:27:28 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h12MVSJ26890; Sun, 2 Feb 2003 17:31:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0V8jsJ10862 for ; Fri, 31 Jan 2003 03:45:54 -0500 Received: from exchange5-5.pune.tcs.co.in (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01442 for ; Fri, 31 Jan 2003 03:41:43 -0500 (EST) Received: from punemail.pune.tcs.co.in (PUNEMAIL [172.17.206.4]) by exchange5-5.pune.tcs.co.in with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id D9W7AZ98; Fri, 31 Jan 2003 14:20:15 +0530 To: "dhcwg@ietf.org" X-Mailer: Lotus Notes Release 5.0.6a January 17, 2001 Message-ID: From: "Swapnil Pitale" Date: Fri, 31 Jan 2003 12:10:02 +0530 X-MIMETrack: Serialize by Router on PUNEMAIL/TCSPUNE/TCS(Release 5.0.6a |January 17, 2001) at 01/31/2003 02:12:08 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: [dhcwg] Help needed for setting up a DHCP server and its Client on WIN2K Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Hi All, I want to setup a DHCP server on WIN2K machine.. Please send some URLs or documents for setting up the same along with the client configuration. Thanks and Regards, Swapnil Tata Consultancy Services. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Feb 3 15:48:18 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21130; Mon, 3 Feb 2003 15:48:18 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h13KqkJ24492; Mon, 3 Feb 2003 15:52:46 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h13KpdJ24426 for ; Mon, 3 Feb 2003 15:51:39 -0500 Received: from patan.sun.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21057 for ; Mon, 3 Feb 2003 15:45:59 -0500 (EST) Received: from bebop.France.Sun.COM ([129.157.174.15]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA04300; Mon, 3 Feb 2003 13:49:35 -0700 (MST) Received: from lillen (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h13KnUP01669; Mon, 3 Feb 2003 21:49:31 +0100 (MET) Date: Mon, 3 Feb 2003 21:45:55 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: [dhcwg] Re: PD lifetimes To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= Cc: Erik Nordmark , dhcwg@ietf.org In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , > Yes, *if we want to allow the delegating router to have the ability to > control the downstream valid and preferred lifetimes*. I agree that this "if" is a key question. But what I don't understand is the semantics of any lifetime if we decide that the delegating DHCP server should not be able to control the prefix lifetimes, then what is the purpose of having any lifetime in the prefix delegation option? Wouldn't it be sufficient to just have T1/T2 in that case? > Before going that further, however, I still think it is overkilling > for the delegating router to have the ability to control the > downstream lifetimes. IMO, the requesting router (and the site's > administrator) should be responsible for such parameters, with one > trivial constraint: the site lifetimes must not be smaller than the > lifetimes of each downstream link. Yes, but the counter argument is for home sites that don't have an administrator it might make sense to allow the ISP to be able to suggest or control the lifetimes. Of course, managed sites might be able to override the lifetimes. > 1. the requesting router should also have the additional bits (like > P and V above), > 2. (this may be controversial) the lifetimes in router advertisement > on each downstream link should be the same as the default of RFC > 2461 (i.e. AdvValidLifetime and AdvPreferredLifetime, NOT > decreasing in real time), as long as Renew/Reply exchanges > succeed, and If you add the P and V bits, then wouldn't the decrement behavior be controlled by those bits? I'm assuming that if those bits indicate that the lifetimes should not decrement in real time, then we need to specify what should happen when renew/reply fails. A reasonable approach would be to switch to decrementing in real time at that point in time. > 3. in any case, the valid lifetime of a prefix delegated by PD must > not be smaller than the valid lifetime in router advertisements > on any downstream link. I don't understand this point. Did you inverse it? Are you saying that the RA lifetimes must not exceed the PD lifetimes that the router received? Erik _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Feb 3 15:48:56 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21177; Mon, 3 Feb 2003 15:48:56 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h13Ks3J24543; Mon, 3 Feb 2003 15:54:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h13KrbJ24514 for ; Mon, 3 Feb 2003 15:53:37 -0500 Received: from smtp015.mail.yahoo.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA21123 for ; Mon, 3 Feb 2003 15:47:57 -0500 (EST) Received: from adsl-64-169-91-213.dsl.snfc21.pacbell.net (HELO BarrH63p601) (rbhibbs@pacbell.net@64.169.91.213 with login) by smtp.mail.vip.sc5.yahoo.com with SMTP; 3 Feb 2003 20:51:33 -0000 Reply-To: From: "Barr Hibbs" To: "Dhcwg" Date: Mon, 3 Feb 2003 12:50:36 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: 7bit Subject: [dhcwg] Review of DHCPv4 Implementation Issues Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit One of the work items adopted by the DHC Working Group at IETF-55 in Atlanta was a review of what I'll generically call "implementation issues" faced by implementors of DHCP clients, servers, and relay agents. The purpose of this review is to identify areas of the protocol that were: 1. not well-specified 2. described in a less-than-clear way 3. had dubious value or harmful side-effects 4. conflicted with other RFCs 5. internally inconsistent, that is, conflicted with other sections of the specification 6. "difficult" to implement or test for interoperability 7. not implemented because of external policies 8. "seemed like a good idea" at the time, but are now considered unnecessary, redundant, or wrong I'm calling on all implementors, developers, and designers to offer their observations, comments, wishes, anecdotes, and observations so that we may create a list of problem areas that need resolution before submitting the RFC for consideration as a full Internet Standard. Even typographical errors, grammatical mistakes, and organizational issues are fair game for this purpose. Thanks in advance for your help. --Barr _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Feb 4 00:20:23 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA00672; Tue, 4 Feb 2003 00:20:23 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h145PGJ19343; Tue, 4 Feb 2003 00:25:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h145NaJ19261 for ; Tue, 4 Feb 2003 00:23:36 -0500 Received: from sj-msg-core-3.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA00617 for ; Tue, 4 Feb 2003 00:17:45 -0500 (EST) Received: from cisco.com (mrwint.cisco.com [144.254.98.48]) by sj-msg-core-3.cisco.com (8.12.2/8.12.6) with ESMTP id h145LGB6018447; Mon, 3 Feb 2003 21:21:16 -0800 (PST) Received: (from otroan@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id FAA09826; Tue, 4 Feb 2003 05:21:20 GMT X-Authentication-Warning: mrwint.cisco.com: otroan set sender to ot@cisco.com using -f To: JINMEI Tatuya / =?iso-2022-jp?b?GyRCP0BMQEMjOkgbKEI=?= Cc: Ralph Droms , dhcwg@ietf.org Subject: Re: [dhcwg] questions about prefix-delegation-01 From: Ole Troan Date: Tue, 04 Feb 2003 05:21:20 +0000 In-Reply-To: (JINMEI Tatuya / =?iso-2022-jp?b?GyRCP0BMQEMjOkgbKEIncw==?= message of "Sun, 26 Jan 2003 15:36:48 +0900") Message-ID: <7t5fzr48vu7.fsf@mrwint.cisco.com> User-Agent: Gnus/5.090011 (Oort Gnus v0.11) Emacs/21.2 (sparc-sun-solaris2.8) References: <4.3.2.7.2.20030123155548.00b6c4f8@funnel.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , >>> 3. Section 11 of the PD draft says: >>> >>> In some circumstances the requesting router may need verification >>> that the delegating router still has a valid binding for the >>> requesting router. Examples of times when a requesting router may >>> ask for such verification include: >>> >>> o The requesting router reboots. >>> ... >>> If such verification is needed the requesting router MUST initiate a >>> Renew/Reply message exchange as described in the section "Creation >>> and Transmission of Renew Messages" of the DHCP specification [6]. >>> >>> I don't see why a Renew/Reply exchange is used, instead of a >>> Confirm/Reply exchange. The described situation is very similar to >>> Section 18.1.2 of dhcpv6-28, and I don't see an essential difference >>> to use a Renew/Reply exchange. If there is, the PD draft should be >>> clear on this. > >> Yes, I think a Confirm message could be used in this case. > > Okay, so do you think the PD draft should be updated by replacing the > Renew with Confirm? I personally think it should, because otherwise > it would be unclear why we had Confirm in the base DHCPv6 spec in the > first place. the Confirm message has different semantics. it is used to verify that a prefix is still on-link, something which restricts it usefulness to address assignment. the Reply to a Confirm can come from any server, and there is no requirement that a binding with the server exists. for PD we wanted a message exchange to verify that the delegating router still has a binding with the requesting router, therefore the use of Renew. /ot _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Feb 4 04:12:13 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14253; Tue, 4 Feb 2003 04:12:13 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h149HVJ10914; Tue, 4 Feb 2003 04:17:31 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h149GoJ10871 for ; Tue, 4 Feb 2003 04:16:50 -0500 Received: from palrel10.hp.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14233 for ; Tue, 4 Feb 2003 04:10:56 -0500 (EST) Received: from iconsrv5.india.hp.com (iconsrv5.india.hp.com [15.42.229.13]) by palrel10.hp.com (Postfix) with ESMTP id 283ED1C01BA7 for ; Tue, 4 Feb 2003 01:14:32 -0800 (PST) Received: from india.hp.com (ksenthil@sunaad.india.hp.com [15.42.231.21]) by iconsrv5.india.hp.com (8.9.3/8.9.3 SMKit7.02) with ESMTP id OAA00226 for ; Tue, 4 Feb 2003 14:43:56 +0530 (IST) Message-ID: <3E3F8B23.CF70A9A1@india.hp.com> Date: Tue, 04 Feb 2003 15:13:00 +0530 From: Senthil Kumar B Organization: Hewlett Packard X-Mailer: Mozilla 4.75 [en] (X11; U; HP-UX B.10.20 9000/712) X-Accept-Language: en MIME-Version: 1.0 To: DHCP WG Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [dhcwg] Can a DHCPv4 server REPLY to non-standard port. Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I heard about cases where a DHCP server like ISC DHCP runs on a different port (other than the standard port 67). In that Can I assume the client also run on a selected non-standard port(other than the standard port 68). I just wanted to clarify one thing here. When a DHCP server runs on a non-standard port (may be 1070) and the client is running in (may be 1080, instead of 1071 conventionally), the server should understand the client's port from the client's request packet and reply to the port(1071) accordingly. Will there be any problem if the client runs on a non-standard dynamic port(varies for different dhcpclients)? One of the problem i could see is that, the client (may be customized) can request all the IP addresses and eventually the server will be running out of addresses to assign (Because, any normal user can write up a program and send DHCP messages to acquire all the IP address). Is this scenario violating the standards and if so how to avoid the problem ? Appreciate your help in advance, Thanks, Senthil _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Feb 4 08:38:29 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22184; Tue, 4 Feb 2003 08:38:29 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14DhgJ27889; Tue, 4 Feb 2003 08:43:42 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14DgSJ27852 for ; Tue, 4 Feb 2003 08:42:28 -0500 Received: from e35.co.us.ibm.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22050 for ; Tue, 4 Feb 2003 08:36:29 -0500 (EST) Received: from westrelay04.boulder.ibm.com (westrelay04.boulder.ibm.com [9.17.193.32]) by e35.co.us.ibm.com (8.12.2/8.12.2) with ESMTP id h14De5VE053196; Tue, 4 Feb 2003 08:40:05 -0500 Received: from austin.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay04.boulder.ibm.com (8.12.3/NCO/VER6.5) with ESMTP id h14De4e0075846; Tue, 4 Feb 2003 06:40:04 -0700 Received: from popmail.austin.ibm.com (popmail.austin.ibm.com [9.41.248.164]) by austin.ibm.com (8.12.6/8.12.6) with ESMTP id h14DdwvN038088; Tue, 4 Feb 2003 07:39:58 -0600 Received: from austin.ibm.com (vallab.austin.ibm.com [9.41.86.83]) by popmail.austin.ibm.com (AIX4.3/8.9.3/8.7-client1.01) with ESMTP id HAA25688; Tue, 4 Feb 2003 07:39:57 -0600 Message-ID: <3E3FC2AD.6F75FC1C@austin.ibm.com> Date: Tue, 04 Feb 2003 07:39:57 -0600 From: "Vasu, Vallabhaneni" Organization: IBM X-Mailer: Mozilla 4.79 [en] (X11; U; AIX 5.1) X-Accept-Language: en MIME-Version: 1.0 To: Senthil Kumar B CC: DHCP WG Subject: Re: [dhcwg] Can a DHCPv4 server REPLY to non-standard port. References: <3E3F8B23.CF70A9A1@india.hp.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Senthil Kumar B wrote: > I heard about cases where a DHCP server like ISC DHCP runs on a > different port (other than the standard port 67). In that Can I assume > the client also run on a selected non-standard port(other than the > standard port 68). > > I just wanted to clarify one thing here. When a DHCP server runs on a > non-standard port (may be 1070) and the client is running in (may be > 1080, instead of 1071 conventionally), the server should understand the > client's port from the client's request packet and reply to the > port(1071) accordingly. > > Will there be any problem if the client runs on a non-standard dynamic > port(varies for different dhcpclients)? One of the problem i could see > is that, the client (may be customized) can request all the IP addresses > and eventually the server will be running out of addresses to assign > (Because, any normal user can write up a program and send DHCP messages > to acquire all the IP address). This problem can happen even if the client uses the standard ports. All you need to do is write c code to generate different client id's (MAC or option 61). This issue is being handled in RFC 3118. > > > Is this scenario violating the standards and if so how to avoid the > problem ? > > Appreciate your help in advance, > > Thanks, > Senthil > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Feb 4 09:12:49 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23006; Tue, 4 Feb 2003 09:12:49 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14EIGJ29576; Tue, 4 Feb 2003 09:18:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h147m5J05490 for ; Tue, 4 Feb 2003 02:48:05 -0500 Received: from shuttle.wide.toshiba.co.jp (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA13116 for ; Tue, 4 Feb 2003 02:42:12 -0500 (EST) Received: from localhost ([3ffe:501:4819:2000:200:39ff:fe10:85d7]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id h147jgP73721; Tue, 4 Feb 2003 16:45:43 +0900 (JST) Date: Tue, 04 Feb 2003 16:46:11 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Erik Nordmark Cc: dhcwg@ietf.org Subject: Re: [dhcwg] Re: PD lifetimes In-Reply-To: References: User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.2 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 103 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , >>>>> On Mon, 3 Feb 2003 21:45:55 +0100 (CET), >>>>> Erik Nordmark said: >> Yes, *if we want to allow the delegating router to have the ability to >> control the downstream valid and preferred lifetimes*. > I agree that this "if" is a key question. > But what I don't understand is the semantics of any lifetime > if we decide that the delegating DHCP server should not be able to > control the prefix lifetimes, then what is the purpose of having any > lifetime in the prefix delegation option? Wouldn't it be sufficient to > just have T1/T2 in that case? It is, unless we do not want to control per-prefix lifetime in a single IA_PD. (If we remove the notion of per-prefix lifetime, then we'd clarify the maximum retransmission duration (MRD) of Rebind for IA_PD accordingly). >> Before going that further, however, I still think it is overkilling >> for the delegating router to have the ability to control the >> downstream lifetimes. IMO, the requesting router (and the site's >> administrator) should be responsible for such parameters, with one >> trivial constraint: the site lifetimes must not be smaller than the >> lifetimes of each downstream link. > Yes, but the counter argument is for home sites that don't have > an administrator it might make sense to allow the ISP to be able to suggest > or control the lifetimes. Of course, managed sites might be able to override > the lifetimes. IMO, per-prefix (valid) lifetime (with T1/T2), along with some default rules of conversion, are enough for the ISP to suggest or control lifetime parameters on downstream links. Also, we need to note the difference on the role of valid/preferred lifetimes (in DHCPv6 messages) between the PD case and the address assignment case. In the context of this current thread, the DHCPv6 lifetimes (particularly the preferred one) are just informational parameters for PD. On the other hand, the DHCPv6 lifetimes are essential parameters for address assignment. In fact, there is no value meaning "any" for the lifetimes in DHCPv6 messages from the server to the client. Thus, if we introduce the lifetime parameters as a kind of optional information for ISP to specify the lifetimes, we need to clarify which parameters are essential and which ones are optional. >> 1. the requesting router should also have the additional bits (like >> P and V above), >> 2. (this may be controversial) the lifetimes in router advertisement >> on each downstream link should be the same as the default of RFC >> 2461 (i.e. AdvValidLifetime and AdvPreferredLifetime, NOT >> decreasing in real time), as long as Renew/Reply exchanges >> succeed, and > If you add the P and V bits, then wouldn't the decrement behavior be > controlled by those bits? Yes. I guess I was not clear, but I was talking about the "default" behavior in the bullet 2 above. That is, the P and V bits should be off (not decrementing) by default. > I'm assuming that if those bits indicate that the lifetimes should not > decrement in real time, then we need to specify what should happen when > renew/reply fails. A reasonable approach would be to switch to decrementing > in real time at that point in time. This might make sense, but please let me make it sure. Suppose that we have been delegated a prefix P/48 with valid lifetime: 1000sec V: off preferred lifetime: 500sec P: off T1: 250sec T2: 400sec Then we first advertise (say) P:1/64 on a downstream link, with fixed lifetime values: 1000 and 500 sec, respectively. After 250 sec later, we start renew/rebind exchanges, if the exchange fails (after 400secs since we have been delegated), we need to start decrementing the RA lifetimes. From which values should we start? 1000 and 500 secs just before? 600 and 100 secs, considering the period we have spent? Or others? >> 3. in any case, the valid lifetime of a prefix delegated by PD must >> not be smaller than the valid lifetime in router advertisements >> on any downstream link. > I don't understand this point. Did you inverse it? > Are you saying that the RA lifetimes must not exceed the PD lifetimes > that the router received? Yes, I am (sorry if I was not clear). To be more precise and concrete, suppose that we are delegated a prefix with the valid lifetime VL at time T. Then if we advertise a downstream prefix (in an RA) at time T + n(sec), the valid lifetime in the RA must not be larger than VL - n, unless the delegated prefix is renewed. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Feb 4 09:12:51 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23030; Tue, 4 Feb 2003 09:12:51 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14EIJJ29596; Tue, 4 Feb 2003 09:18:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h149RKJ11237 for ; Tue, 4 Feb 2003 04:27:20 -0500 Received: from shuttle.wide.toshiba.co.jp (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14347 for ; Tue, 4 Feb 2003 04:21:25 -0500 (EST) Received: from localhost ([3ffe:501:4819:2000:200:39ff:fe10:85d7]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id h149OvP74461; Tue, 4 Feb 2003 18:24:57 +0900 (JST) Date: Tue, 04 Feb 2003 18:25:26 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Ralph Droms Cc: dhcwg@ietf.org Subject: Re: [dhcwg] questions about dhcpv6-28 In-Reply-To: <4.3.2.7.2.20030129110537.039df768@funnel.cisco.com> References: <4.3.2.7.2.20030123151949.00b6c3f8@funnel.cisco.com> <4.3.2.7.2.20030129110537.039df768@funnel.cisco.com> User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.2 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 27 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , >>>>> On Wed, 29 Jan 2003 11:23:07 -0500, >>>>> Ralph Droms said: >> Actually, Section 15.6 *seems to* address the case. It says: (snip) >> However, there should be a wording problem. I guess the sentence >> actually intended to be: >> >> Servers MUST discard any received Renew message that fails to meet >> ^^^^^^^^ >> any of the following conditions: > Excellent point; thanks for catching that goof. > While this check is defined in section 15.6, would it be helpful > to add a reference in section 18.1.3 explaining the reason for > that constraint? Hmm, I'm not sure if this case is that special, but the explanation itself would surely be helpful. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Feb 4 09:12:52 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23054; Tue, 4 Feb 2003 09:12:52 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14EILJ29613; Tue, 4 Feb 2003 09:18:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14A2YJ13046 for ; Tue, 4 Feb 2003 05:02:34 -0500 Received: from shuttle.wide.toshiba.co.jp (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14783 for ; Tue, 4 Feb 2003 04:56:37 -0500 (EST) Received: from localhost ([3ffe:501:4819:2000:200:39ff:fe10:85d7]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id h14A09P74787; Tue, 4 Feb 2003 19:00:09 +0900 (JST) Date: Tue, 04 Feb 2003 19:00:38 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Ole Troan Cc: Ralph Droms , dhcwg@ietf.org Subject: Re: [dhcwg] questions about prefix-delegation-01 In-Reply-To: <7t5fzr48vu7.fsf@mrwint.cisco.com> References: <4.3.2.7.2.20030123155548.00b6c4f8@funnel.cisco.com> <7t5fzr48vu7.fsf@mrwint.cisco.com> User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.2 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 50 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , >>>>> On Tue, 04 Feb 2003 05:21:20 +0000, >>>>> Ole Troan said: >>>> I don't see why a Renew/Reply exchange is used, instead of a >>>> Confirm/Reply exchange. The described situation is very similar to >>>> Section 18.1.2 of dhcpv6-28, and I don't see an essential difference >>>> to use a Renew/Reply exchange. If there is, the PD draft should be >>>> clear on this. >> >>> Yes, I think a Confirm message could be used in this case. >> >> Okay, so do you think the PD draft should be updated by replacing the >> Renew with Confirm? I personally think it should, because otherwise >> it would be unclear why we had Confirm in the base DHCPv6 spec in the >> first place. > the Confirm message has different semantics. it is used to verify that > a prefix is still on-link, something which restricts it usefulness to > address assignment. the Reply to a Confirm can come from any server, > and there is no requirement that a binding with the server exists. > for PD we wanted a message exchange to verify that the delegating > router still has a binding with the requesting router, therefore the > use of Renew. Okay, I understand the intention. However, I still think of a case where Confirm is more appropriate. For example, suppose that we have two upstream "cables", each of which connects to a separate ISP. Also suppose that the requesting router has an upstream port. We first plug one cable to the upstream port, and then switch to another cable. This situation corresponds to the following case of the PD draft: o The requesting router is physically disconnected from a wired connection. In this case, the upstream server (a delegating router) should change. If we use a Renew message, the server would ignore it because the server Identifier does not match. As a result, we cannot invalidate the stale prefix until the renew/reply exchanges fail (or, in the worst case, until the lifetime of the prefix expires). On the other hand, if we use a Confirm message, the upstream server would notice that the prefixes do not belong to the ISP, and send a reply with some negative status code. Then the requesting router can restart soliciting delegating router and will be able get a new, valid prefix. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Feb 4 09:12:56 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23079; Tue, 4 Feb 2003 09:12:56 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14EIMJ29629; Tue, 4 Feb 2003 09:18:22 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14AMGJ14256 for ; Tue, 4 Feb 2003 05:22:16 -0500 Received: from shuttle.wide.toshiba.co.jp (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15076 for ; Tue, 4 Feb 2003 05:16:19 -0500 (EST) Received: from localhost ([3ffe:501:4819:2000:200:39ff:fe10:85d7]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id h14AJoP74910; Tue, 4 Feb 2003 19:19:50 +0900 (JST) Date: Tue, 04 Feb 2003 19:20:19 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: "Bernie Volz (EUD)" Cc: dhcwg@ietf.org Subject: Re: [dhcwg] questions about dhcpv6-28 In-Reply-To: References: User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.2 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 52 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , (In the followings, I folded some long lines) >>>>> On Tue, 28 Jan 2003 12:42:33 -0600, >>>>> "Bernie Volz (EUD)" said: >> Ralph pointed out to me the possibility of some "magic" between a >> primary server and a backup server, which allows those servers to be >> synchronized in real time. I'm not sure how this is realistic, >> either, but I'd personally prefer to keep the possibility. > For DHCPv6 there seems to me a better way to handle things like failover? > The two standard mechanisms would be: > 1. Failover like protocol between the two servers > 2. Redundant backend database > But, with the large IPv6 addresses, there is another way which I > think is even better and requires no communication between > "redundant" servers (well, there is the configuration issues but > there is no need or minimal need for ongoing communication). The > idea is as follows: (snip) > I wonder whether the DHC WG might take this on - to specify how > redundant DHCPv6 services could or should be built? I think it will > be easier than the DHCPv4 failover work and may not require any > protocol - just a way of working? But, then perhaps this is simply > left to the server implementers to decide how best to work and > interoperability between several vendors is not required? Thanks for the detailed analysis. I, for one, think the mechanism to provide the redundancy among multiple servers can be out of scope for the dhc wg (at least for now). Going back to the original question, what should the server do when it receives a Rebind containing an IA for which the receiving server does not have a binding? Option 1 (from Ralph): the server should ignore the Rebind unless it has an "explicit" knowledge that the binding has been invalidated. Option 2 (from Bernie): the server should return a Reply with NoBinding anyway, and let the client choose the reaction based on the Server Identifier that provided the IA. As I said before, I prefer Option 1. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Feb 4 10:05:04 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24478; Tue, 4 Feb 2003 10:05:04 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14FAUJ00429; Tue, 4 Feb 2003 10:10:31 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14F7gJ32762 for ; Tue, 4 Feb 2003 10:07:42 -0500 Received: from intermail.se.dataphone.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24435 for ; Tue, 4 Feb 2003 10:01:40 -0500 (EST) Received: from [193.12.201.10] (account budm@weird-solutions.com HELO offset.weird.se) by intermail.se.dataphone.net (CommuniGate Pro SMTP 4.0.5) with ESMTP id 800028; Tue, 04 Feb 2003 16:05:14 +0100 Content-Type: text/plain; charset="iso-8859-1" From: Bud Millwood Reply-To: Bud Millwood Organization: Weird Solutions, Inc. To: "Vasu, Vallabhaneni" , dhcwg@ietf.org Subject: Re: [dhcwg] Can a DHCPv4 server REPLY to non-standard port. Date: Tue, 4 Feb 2003 16:06:27 +0100 User-Agent: KMail/1.4.3 References: <3E3F8B23.CF70A9A1@india.hp.com> <3E3FC2AD.6F75FC1C@austin.ibm.com> In-Reply-To: <3E3FC2AD.6F75FC1C@austin.ibm.com> Cc: Senthil Kumar B MIME-Version: 1.0 Message-Id: <200302041606.27750.budm@weird-solutions.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h14F7gJ32763 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit On Tuesday 04 February 2003 14.39, Vasu, Vallabhaneni wrote: > This problem can happen even if the client uses the standard ports. All you > need to do is write c code to generate different client id's (MAC or option > 61). This issue is being handled in RFC 3118. We respond to the source port the client is using, but allow the administrator to override this at the server. It seemed like a bad idea to respond to a fixed port if no communication had been initiated from that port. The best way to handle spoofing today, to my knowledge, is to use the trusted values found in option 82 for identifying the client. If your server supports resource limiting using option 82, and your relay agents support option 82, you should be fine. Otherwise, some sort of pre-registration works, although that's a bit of a pain to manage. Bud Millwood Weird Solutions, Inc. http://www.weird-solutions.com tel: +46 8 758 3700 fax: +46 8 758 3687 mailto:budm@weird-solutions.com _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Feb 4 11:29:12 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27533; Tue, 4 Feb 2003 11:29:12 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14GYWJ06396; Tue, 4 Feb 2003 11:34:33 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14GXkJ06317 for ; Tue, 4 Feb 2003 11:33:46 -0500 Received: from e31.co.us.ibm.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27419 for ; Tue, 4 Feb 2003 11:27:42 -0500 (EST) Received: from westrelay03.boulder.ibm.com (westrelay03.boulder.ibm.com [9.17.194.24]) by e31.co.us.ibm.com (8.12.2/8.12.2) with ESMTP id h14GVI2Y020382 for ; Tue, 4 Feb 2003 11:31:18 -0500 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.27.12.14]) by westrelay03.boulder.ibm.com (8.12.3/NCO/VER6.5) with ESMTP id h14GUuFD051512 for ; Tue, 4 Feb 2003 09:30:56 -0700 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.11.6/8.11.6) with ESMTP id h14GSfc26441 for ; Tue, 4 Feb 2003 11:28:41 -0500 Message-Id: <200302041628.h14GSfc26441@rotala.raleigh.ibm.com> To: dhcwg@ietf.org Date: Tue, 04 Feb 2003 11:28:40 -0500 From: Thomas Narten Subject: [dhcwg] lease query question Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , I've started my AD review on draft-ietf-dhc-leasequery-04.txt, and have a basic question. From the problem statement, I understood the problem to be fairly narrowly scoped, that is, an ability to rebuild the state that an access concentrator builds from gleaned DHC messages, but loses if it (say) restarts. The abstract/problem statement says: Access concentrators that act as DHCP relay agents need to determine the endpoint locations of IP addresses across public broadband access networks such as cable, DSL, and wireless networks. Because ARP broadcasts are undesirable in public networks, many access concentrator implementations "glean" location information from DHCP messages forwarded by its relay agent function. Unfortunately, the typical access concentrator loses its gleaned information when the access concentrator is rebooted or is replaced. This memo proposes that when gleaned DHCP information is not available, the access concentrator/relay agent obtains the location information directly from the DHCP server(s) using a new, lightweight DHCPLEASEQUERY message. That is, I assumed that what is needed is a mechanism that allows a concentrator to avoid the need to invoke ARP, by querying the DHC server instead. To achieve this, I would have assumed that a simple query-response protocol that would solve the problem as stated. That is, I would have assumed perhaps two queries: - tell me the IP addresses of all devices behind a particular link-layer "MAC", or [note: one might use this to rebuild state about a particular link] - Tell me which of my links (if any) the following IP address resides on. [note: one might use this if one received an packet to forward, and needed to do the equivalent of "ARP" for it] I would expect that the leasequery might say "give me the info", and the server would respond with the same info it would give the client. I.e, the information received is the same as that it would glean from the normal DHC trafic (and in particular, without any new information specific to the leasequery protocol). But the protocol is quite a bit more complex than that. For example, a server can respond with a "sort of" answer, one that indicates I don't have a lease, but I did in the past. Likewise, there is also an R bit for providing further information about the details of a particular lease. I don't fully understand the motivation or need for the additional stuff. There seem to be some unstated assumptions about the nature of the problem being solved. Could someone please clarify what the actual problem is that needs solving here? Thomas _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Feb 4 15:36:28 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03644; Tue, 4 Feb 2003 15:36:28 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14KfQJ22160; Tue, 4 Feb 2003 15:41:26 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14KebJ22115 for ; Tue, 4 Feb 2003 15:40:37 -0500 Received: from toccata.fugue.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03582 for ; Tue, 4 Feb 2003 15:34:29 -0500 (EST) Received: from nominum.com (dsl093-187-100.chi2.dsl.speakeasy.net [66.93.187.100]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id h14KUTP07792; Tue, 4 Feb 2003 14:30:29 -0600 (CST) Date: Tue, 4 Feb 2003 14:37:01 -0600 Subject: Re: [dhcwg] Can a DHCPv4 server REPLY to non-standard port. Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: "Vasu, Vallabhaneni" , dhcwg@ietf.org, Senthil Kumar B To: Bud Millwood From: Ted Lemon In-Reply-To: <200302041606.27750.budm@weird-solutions.com> Message-Id: <6A0683BE-3880-11D7-A2AE-00039367340A@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > We respond to the source port the client is using, but allow the > administrator > to override this at the server. It seemed like a bad idea to respond > to a > fixed port if no communication had been initiated from that port. The RFC is explicit about the port numbers to use when sending messages. If you send to or from other ports, you are not doing DHCP. Which is not to say that what you are doing is wrong for the particular case you're working on, but it isn't what's stated in the protocol specification. You can't count on being able to interoperate successfully with conforming devices if you don't use the port numbers that the standard requires. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Feb 4 17:57:38 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07227; Tue, 4 Feb 2003 17:57:38 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14N31J31512; Tue, 4 Feb 2003 18:03:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14MwSJ31362 for ; Tue, 4 Feb 2003 17:58:28 -0500 Received: from sj-msg-core-3.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07146 for ; Tue, 4 Feb 2003 17:52:16 -0500 (EST) Received: from cisco.com (mrwint.cisco.com [144.254.98.48]) by sj-msg-core-3.cisco.com (8.12.2/8.12.6) with ESMTP id h14MtlB6001484; Tue, 4 Feb 2003 14:55:47 -0800 (PST) Received: (from otroan@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id WAA10768; Tue, 4 Feb 2003 22:55:52 GMT X-Authentication-Warning: mrwint.cisco.com: otroan set sender to ot@cisco.com using -f To: JINMEI Tatuya / =?iso-2022-jp?b?GyRCP0BMQEMjOkgbKEI=?= Cc: Ralph Droms , dhcwg@ietf.org Subject: Re: [dhcwg] questions about prefix-delegation-01 From: Ole Troan Date: Tue, 04 Feb 2003 22:55:52 +0000 In-Reply-To: (JINMEI Tatuya / =?iso-2022-jp?b?GyRCP0BMQEMjOkgbKEIncw==?= message of "Tue, 04 Feb 2003 19:00:38 +0900") Message-ID: <7t5n0lbejuv.fsf@mrwint.cisco.com> User-Agent: Gnus/5.090011 (Oort Gnus v0.11) Emacs/21.2 (sparc-sun-solaris2.8) References: <4.3.2.7.2.20030123155548.00b6c4f8@funnel.cisco.com> <7t5fzr48vu7.fsf@mrwint.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , >>>>> I don't see why a Renew/Reply exchange is used, instead of a >>>>> Confirm/Reply exchange. The described situation is very similar to >>>>> Section 18.1.2 of dhcpv6-28, and I don't see an essential difference >>>>> to use a Renew/Reply exchange. If there is, the PD draft should be >>>>> clear on this. >>> >>>> Yes, I think a Confirm message could be used in this case. >>> >>> Okay, so do you think the PD draft should be updated by replacing the >>> Renew with Confirm? I personally think it should, because otherwise >>> it would be unclear why we had Confirm in the base DHCPv6 spec in the >>> first place. > >> the Confirm message has different semantics. it is used to verify that >> a prefix is still on-link, something which restricts it usefulness to >> address assignment. the Reply to a Confirm can come from any server, >> and there is no requirement that a binding with the server exists. > >> for PD we wanted a message exchange to verify that the delegating >> router still has a binding with the requesting router, therefore the >> use of Renew. > > Okay, I understand the intention. However, I still think of a case > where Confirm is more appropriate. For example, suppose that we have > two upstream "cables", each of which connects to a separate ISP. Also > suppose that the requesting router has an upstream port. We first > plug one cable to the upstream port, and then switch to another > cable. This situation corresponds to the following case of the PD > draft: > > o The requesting router is physically disconnected from a wired > connection. > > In this case, the upstream server (a delegating router) should change. > If we use a Renew message, the server would ignore it because the > server Identifier does not match. As a result, we cannot invalidate > the stale prefix until the renew/reply exchanges fail (or, in the > worst case, until the lifetime of the prefix expires). On the other > hand, if we use a Confirm message, the upstream server would notice > that the prefixes do not belong to the ISP, and send a reply with some > negative status code. Then the requesting router can restart > soliciting delegating router and will be able get a new, valid prefix. Confirm as it is currently specified can only be used for the address options. to make it useful for any type of stateful option it would have to be changed to: - allow confirmation of binding - return status code within each option's IA this is unfortunate but I think it is too late in the game to change it now. one possibility is to create a new message type, e.g "Verify", which has the semantics from Renew (without the ServerId option), retransmission timers from Confirm and where the status code in a Reply would be encapsulated in the IA option. /ot _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Feb 4 18:15:43 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07588; Tue, 4 Feb 2003 18:15:43 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14NLFJ32739; Tue, 4 Feb 2003 18:21:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14NKDJ32697 for ; Tue, 4 Feb 2003 18:20:13 -0500 Received: from sj-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07568 for ; Tue, 4 Feb 2003 18:14:00 -0500 (EST) Received: from cisco.com (mrwint.cisco.com [144.254.98.48]) by sj-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h14NHbSQ017219; Tue, 4 Feb 2003 15:17:37 -0800 (PST) Received: (from otroan@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id XAA11574; Tue, 4 Feb 2003 23:17:36 GMT X-Authentication-Warning: mrwint.cisco.com: otroan set sender to ot@cisco.com using -f To: JINMEI Tatuya / =?iso-2022-jp?b?GyRCP0BMQEMjOkgbKEI=?= Cc: rdroms@cisco.com, dhcwg@ietf.org From: Ole Troan Date: Tue, 04 Feb 2003 23:17:36 +0000 In-Reply-To: (JINMEI Tatuya / =?iso-2022-jp?b?GyRCP0BMQEMjOkgbKEIncw==?= message of "Thu, 23 Jan 2003 19:18:57 +0900") Message-ID: <7t5el6neiun.fsf@mrwint.cisco.com> User-Agent: Gnus/5.090011 (Oort Gnus v0.11) Emacs/21.2 (sparc-sun-solaris2.8) References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [dhcwg] Re: PD lifetimes Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , > I have several comments about lifetimes of prefix delegation (PD). In > this message, I'm talking about > draft-ietf-dhc-dhcpv6-opt-prefix-delegation-01.txt. > > 0. (I once discussed this point privately, but I could not help > raising this again. Please forgive me for this repetition.) > > I cannot understand the reason why the prefix has the notion of > the preferred lifetime, whose role is not clear. The role of the > valid lifetime is very clear; the period that the delegated site can > use the prefix. However, the preferred lifetime only controls a loose > relationship with the preferred lifetime in router advertisements > within the site, and roughly controls the T1/T2 values. > > It would be much simpler to have a single "lifetime" only, which > controls T1 and T2, and loosely affects the RA lifetimes. I believe this was brought up during the DHC meeting in Yokohama. the main argument (coming from Thomas I think) for including the preferred lifetime was to simplify renumbering. it also allows for more granular control if PD is used in other contexts than the one specified in the draft. the draft specifies how a prefix is delegated but has intentionally left unspecified (apart from suggesting some defaults) how it is to be used within the site. the only requirement is that the valid lifetime is adhered to, anything else can be configured in any way the local administrator (if there is one) wants. > In the following comments, however, I'll assume the current valid + > preferred scheme. > > 1. Section 9 says > > In a message sent by a delegating router the preferred and valid > lifetimes should be set to the values specified in section "Router > Configuration Variables" of RFC2461 [3], unless administratively > configured. > > Technically, the wording 'values specified in section "Router > Configuration Variables"' is not clear, because the router > configuration variables of RFC 2461 do not contain the valid and > preferred lifetimes. The intended variables should probably be > AdvValidLifetime and AdvPreferredLifetime, respectively. Even so, > however, I still suspect these are appropriate values. > AdvXXXLifetimes are for each end host (in a site), but the lifetimes > given by PD affect the entire site. In general (and IMO), the latter > should be larger than the former. section 6.2.1 of RFC2461 does indeed include AdvValidLifetime and AdvPreferredLifetime, so I'm not sure what is not clear. > Today, on typical IPv6 links, we see fixed values of the valid and > preferred lifetimes in Router Advertisements, i.e., AdvValidLifetime > and AdvPreferredLifetime. However, according to the default values of > the PD lifetimes and to the specified relationship between the PD > lifetimes and RA lifetimes described in the last paragraph of Section > 11.1, it is highly possible to see smaller RA lifetimes than the > current typical cases. Moreover, if the requesting router simply uses > the PD valid (or preferred) lifetime for the RA valid (or preferred) > lifetime, we'll see the RA lifetime being decremented. > > I believe the default values of PD lifetimes should keep the default > values of RA lifetimes in the typical configuration. Thus, I would > recommend the following values: > > The default value for the PD preferred lifetime is > (5 / 4) * AdvPreferredLifetime. > The default value for the PD valid lifetime can be an arbitrary value, > but should not be smaller than AdvValidLifetime + PD preferred lifetime. > > The rationale of the default is that we won't see "abnormal" RA > lifetimes unless the requesting router fails renew/reply exchanges and > starts rebinding, assuming that "T2" for the prefix is (equal to or > smaller than) the PD preferred lifetime * 0.8. I don't see decrementing lifetimes in RA's as abnormal, nor do I see the benefit of advertising fixed values in RA's. there is nothing prohibiting an requesting router implementation to use fixed values, as long as it behaves correctly when the PD valid lifetime < RA lifetime. > 2. Section 9 also says > > In a message sent by a delegating router to a requesting router, the > requesting router MUST use the value in the valid lifetime field and > MAY use the value in the preferred lifetime field. > > This sentence is not clear to me. Where and how does the requesting > router "use" the lifetimes? This ambiguity also makes the term "MUST" > and "MAY" unclear. Perhaps the sentence intends to specify the > relationship between RA lifetimes and PD lifetimes described in > Section 11.1, but I cannot be sure without any reference. agree, should be clarified. /ot _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Feb 4 19:12:56 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08487; Tue, 4 Feb 2003 19:12:56 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h150IXJ03371; Tue, 4 Feb 2003 19:18:33 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h150HAJ03314 for ; Tue, 4 Feb 2003 19:17:10 -0500 Received: from sj-msg-core-4.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08460 for ; Tue, 4 Feb 2003 19:10:56 -0500 (EST) Received: from cisco.com (mrwint.cisco.com [144.254.98.48]) by sj-msg-core-4.cisco.com (8.12.2/8.12.6) with ESMTP id h150EXap006347; Tue, 4 Feb 2003 16:14:34 -0800 (PST) Received: (from otroan@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id AAA13684; Wed, 5 Feb 2003 00:14:32 GMT X-Authentication-Warning: mrwint.cisco.com: otroan set sender to ot@cisco.com using -f To: aaron.m.smith@motorola.com Cc: Subject: Re: [dhcwg] more prefix-delegation-01 questions From: Ole Troan Date: Wed, 05 Feb 2003 00:14:32 +0000 In-Reply-To: <3E31860C.3D8B145E@motorola.com> ("Aaron M. Smith"'s message of "Fri, 24 Jan 2003 12:29:32 -0600") Message-ID: <7t5wukfd1nb.fsf@mrwint.cisco.com> User-Agent: Gnus/5.090011 (Oort Gnus v0.11) Emacs/21.2 (sparc-sun-solaris2.8) References: <3E31860C.3D8B145E@motorola.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Aaron, thanks for your comments. > In draft-ietf-dhc-dhcpv6-opt-prefix-delegation-01, > the second paragraph of section 5 says > > An IA_PD is different from an IA, in that it does not need to be > associated with exactly one interface. One IA_PD can be associated > with the requesting router, with a set of interfaces or with exactly > one interface. A requesting router must create at least one distinct > IA_PD. It may associate a distinct IA_PD with each of its downstream > network interfaces and use that IA_PD to obtain a prefix for that > interface from the delegating router. > > Then the 3rd to last paragraph in section 11.1 begins > > Upon the receipt of a valid Reply message, the requesting router > assigns a subnet from each of the delegated prefixes to each of the > links to which it is attached, ... > > I think the text in 11.1 is a carryover from before the IA_PD > construct was introduced. Should it be updated to reflect the > IA_PD interface groupings? Perhaps something along the lines of > > Upon the receipt of a valid Reply message, for each IA_PD the > requesting router assigns a subnet from each of the delegated > prefixes to each of the links to which the associated interfaces > are attached, ... agree, that is clearer. > Also, section 5 has "...obtain a prefix for that interface...", > while section 11.1 has "...assigns a subnet from...the...prefixes to... > the links...". Does it ever make sense for the requesting router to > configure an address on its interface(s) using a delegated prefix? > If so, and given that RFC 2462 says routers are not allowed to > auto-configure addresses from prefixes received in advertisements > (even ones they send), then the address configuration would have to be > done explicitly. Does the PD draft need to explain this, or is it > considered obvious, or should routers not do this? a requesting router could indeed configure an address using the delegated prefix. in this case the prefix wouldn't be received in an RA so the restriction in 2462 shouldn't apply. (in any case I think the per interface router/host mode is sometimes a bit blurred, e.g our implementation can auto-configure addresses on an interface while still forwarding on that interface.) cheers, Ole _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Feb 5 02:03:22 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22602; Wed, 5 Feb 2003 02:03:21 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h15791J27464; Wed, 5 Feb 2003 02:09:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1576DJ24962 for ; Wed, 5 Feb 2003 02:06:13 -0500 Received: from sj-msg-core-3.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18142 for ; Wed, 5 Feb 2003 01:59:53 -0500 (EST) Received: from cisco.com (mrwint.cisco.com [144.254.98.48]) by sj-msg-core-3.cisco.com (8.12.2/8.12.6) with ESMTP id h1573MB6006873; Tue, 4 Feb 2003 23:03:22 -0800 (PST) Received: (from otroan@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id HAA22004; Wed, 5 Feb 2003 07:03:27 GMT X-Authentication-Warning: mrwint.cisco.com: otroan set sender to ot@cisco.com using -f To: JINMEI Tatuya / =?iso-2022-jp?b?GyRCP0BMQEMjOkgbKEI=?= Cc: Ralph Droms , dhcwg@ietf.org Subject: Re: [dhcwg] questions about prefix-delegation-01 From: Ole Troan Date: Wed, 05 Feb 2003 07:03:27 +0000 In-Reply-To: (JINMEI Tatuya / =?iso-2022-jp?b?GyRCP0BMQEMjOkgbKEIncw==?= message of "Wed, 05 Feb 2003 15:03:35 +0900") Message-ID: <7t5fzr3cips.fsf@mrwint.cisco.com> User-Agent: Gnus/5.090011 (Oort Gnus v0.11) Emacs/21.2 (sparc-sun-solaris2.8) References: <4.3.2.7.2.20030123155548.00b6c4f8@funnel.cisco.com> <7t5fzr48vu7.fsf@mrwint.cisco.com> <7t5n0lbejuv.fsf@mrwint.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , >>>>>> On Tue, 04 Feb 2003 22:55:52 +0000, >>>>>> Ole Troan said: > >> Confirm as it is currently specified can only be used for the address >> options. to make it useful for any type of stateful option it >> would have to be changed to: > >> - allow confirmation of binding >> - return status code within each option's IA > >> this is unfortunate but I think it is too late in the game to >> change it now. > > I agree that the ideal approach would be to make the base DHCPv6 spec > generic and that such an attempt is unfortunately too late. > >> one possibility is to create a new message type, e.g "Verify", which >> has the semantics from Renew (without the ServerId option), >> retransmission timers from Confirm and where the status code in a >> Reply would be encapsulated in the IA option. > > This would be a possibility. However, I also think we can still > "overload" the Confirm message so that it can be used for the PD (or > other stateful resources) case. > > I don't want to introduce too-much generalization into the PD spec and > to delay the standardization. But I do not want to see an easygoing > compromise either, because this is a good (and perhaps the last) > chance to make the PD spec complete. So, I'd like to hear from > others, if anyone else has an opinion on this. Confirm allows other servers than the one with the binding to reply, if they have the required information, i.e if the prefix is onlink or not. I think it is much less likely in the PD case that other servers than the one with the binding will have the knowledge to determine if the prefix is correct or not. if you accept this point, then the scenario you outlined earlier can easily be solved. when Renew is used as Confirm, Renew should use Confirm's retransmission timers. the message exchange will stop after 10 seconds, and the requesting router will go back to soliciting for delegating routers. cheers, Ole _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Feb 5 06:14:11 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17627; Wed, 5 Feb 2003 06:14:11 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h15BJwJ15421; Wed, 5 Feb 2003 06:19:59 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1565tJ20121 for ; Wed, 5 Feb 2003 01:05:55 -0500 Received: from shuttle.wide.toshiba.co.jp (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17002 for ; Wed, 5 Feb 2003 00:59:34 -0500 (EST) Received: from localhost ([3ffe:501:100f:1048:3853:6878:e4bc:cbd6]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id h15634P86397; Wed, 5 Feb 2003 15:03:05 +0900 (JST) Date: Wed, 05 Feb 2003 15:03:35 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Ole Troan Cc: Ralph Droms , dhcwg@ietf.org Subject: Re: [dhcwg] questions about prefix-delegation-01 In-Reply-To: <7t5n0lbejuv.fsf@mrwint.cisco.com> References: <4.3.2.7.2.20030123155548.00b6c4f8@funnel.cisco.com> <7t5fzr48vu7.fsf@mrwint.cisco.com> <7t5n0lbejuv.fsf@mrwint.cisco.com> User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.2 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 35 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , >>>>> On Tue, 04 Feb 2003 22:55:52 +0000, >>>>> Ole Troan said: > Confirm as it is currently specified can only be used for the address > options. to make it useful for any type of stateful option it > would have to be changed to: > - allow confirmation of binding > - return status code within each option's IA > this is unfortunate but I think it is too late in the game to > change it now. I agree that the ideal approach would be to make the base DHCPv6 spec generic and that such an attempt is unfortunately too late. > one possibility is to create a new message type, e.g "Verify", which > has the semantics from Renew (without the ServerId option), > retransmission timers from Confirm and where the status code in a > Reply would be encapsulated in the IA option. This would be a possibility. However, I also think we can still "overload" the Confirm message so that it can be used for the PD (or other stateful resources) case. I don't want to introduce too-much generalization into the PD spec and to delay the standardization. But I do not want to see an easygoing compromise either, because this is a good (and perhaps the last) chance to make the PD spec complete. So, I'd like to hear from others, if anyone else has an opinion on this. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Feb 5 06:14:29 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17667; Wed, 5 Feb 2003 06:14:29 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h15BKMJ15492; Wed, 5 Feb 2003 06:20:22 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1592cJ07861 for ; Wed, 5 Feb 2003 04:02:38 -0500 Received: from shuttle.wide.toshiba.co.jp (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14735 for ; Wed, 5 Feb 2003 03:56:14 -0500 (EST) Received: from localhost ([3ffe:501:100f:1048:3853:6878:e4bc:cbd6]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id h158xbP87991; Wed, 5 Feb 2003 17:59:37 +0900 (JST) Date: Wed, 05 Feb 2003 18:00:07 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Ole Troan Cc: rdroms@cisco.com, dhcwg@ietf.org Subject: Re: [dhcwg] Re: PD lifetimes In-Reply-To: <7t5el6neiun.fsf@mrwint.cisco.com> References: <7t5el6neiun.fsf@mrwint.cisco.com> User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.2 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 115 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , >>>>> On Tue, 04 Feb 2003 23:17:36 +0000, >>>>> Ole Troan said: >> 0. (I once discussed this point privately, but I could not help >> raising this again. Please forgive me for this repetition.) (snip) >> It would be much simpler to have a single "lifetime" only, which >> controls T1 and T2, and loosely affects the RA lifetimes. > I believe this was brought up during the DHC meeting in Yokohama. the > main argument (coming from Thomas I think) for including the preferred > lifetime was to simplify renumbering. it also allows for more granular > control if PD is used in other contexts than the one specified in the > draft. Okay, according to the discussion in this thread, it seems that I'm in the minority on this. So, I'm okay to keep the preferred lifetime in the PD specification. > the draft specifies how a prefix is delegated but has intentionally > left unspecified (apart from suggesting some defaults) how it is to be > used within the site. the only requirement is that the valid lifetime > is adhered to, anything else can be configured in any way the local > administrator (if there is one) wants. As I said in a separate message, this approach treats the preferred lifetime as (a kind of) optional information, while the preferred lifetime takes an essential role in address assignment. In the PD spec, the valid and preferred lifetimes are sometimes essential and sometimes informational, which make me confused: - the PD valid lifetime specifies the "lease duration" of the site prefix. (this is essential) - the PD valid lifetime also specifies the upper bound of the RA valid lifetime. (this is a bit strong, but still informational) - the PD preferred lifetime controls the (recommended) default values of T1 and T2. (this is essential) - the PD preferred lifetime specifies a suggestion of the RA preferred lifetime. (this is informational) Thus, it would most make sense to me if the essential and informational parts are clearly separated. For example, - we have three parameters for a prefix; lease duration, valid lifetime, and preferred lifetime. we also have T1 and T2 for an IA_PD. - the lease duration is an essential information, which specifies the "lifetime of the site prefix" and must be specified in Reply messages. It also controls the default value of T1 and T2. - the valid and preferred lifetimes are informational, which may or may not be (concretely) specified in Reply messages. If specified, those values mean the suggested values of the RA lifetimes. - there are of course some trivial relationship between the parameters. For instance, the valid and preferred lifetimes must not be larger than the lease duration. (we may need additional bits for the valid and preferred lifetimes as Erik suggested, but I omitted the additional bits here for simplicity.) Doesn't this make much sense? >> In the following comments, however, I'll assume the current valid + >> preferred scheme. >> >> 1. Section 9 says >> >> In a message sent by a delegating router the preferred and valid >> lifetimes should be set to the values specified in section "Router >> Configuration Variables" of RFC2461 [3], unless administratively >> configured. >> >> Technically, the wording 'values specified in section "Router >> Configuration Variables"' is not clear, because the router >> configuration variables of RFC 2461 do not contain the valid and >> preferred lifetimes. The intended variables should probably be >> AdvValidLifetime and AdvPreferredLifetime, respectively. Even so, >> however, I still suspect these are appropriate values. >> AdvXXXLifetimes are for each end host (in a site), but the lifetimes >> given by PD affect the entire site. In general (and IMO), the latter >> should be larger than the former. > section 6.2.1 of RFC2461 does indeed include AdvValidLifetime and > AdvPreferredLifetime, so I'm not sure what is not clear. My point is that the text should be like this: In a message sent by a delegating router the preferred and valid lifetimes should be set to AdvValidLifetime and AdvPreferredLifetime, respectively, as specified in section "Router Configuration Variables" of RFC2461 [3], unless administratively configured. (though I'd like larger default value as I said below.) >> I believe the default values of PD lifetimes should keep the default >> values of RA lifetimes in the typical configuration. Thus, I would >> recommend the following values: (snip) > I don't see decrementing lifetimes in RA's as abnormal, nor do I see > the benefit of advertising fixed values in RA's. there is nothing > prohibiting an requesting router implementation to use fixed values, > as long as it behaves correctly when the PD valid lifetime < RA > lifetime. Regarding this point, please refer to the succeeding discussion in this thread. However, if we clarified the essential and informational parameters (see above), this part might not be an issue. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Feb 5 06:14:33 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17695; Wed, 5 Feb 2003 06:14:33 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h15BKPJ15508; Wed, 5 Feb 2003 06:20:25 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h159TYJ09193 for ; Wed, 5 Feb 2003 04:29:34 -0500 Received: from shuttle.wide.toshiba.co.jp (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA15104 for ; Wed, 5 Feb 2003 04:23:09 -0500 (EST) Received: from localhost ([3ffe:501:100f:1048:3853:6878:e4bc:cbd6]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id h159QZP88307; Wed, 5 Feb 2003 18:26:36 +0900 (JST) Date: Wed, 05 Feb 2003 18:27:04 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Ole Troan Cc: Ralph Droms , dhcwg@ietf.org Subject: Re: [dhcwg] questions about prefix-delegation-01 In-Reply-To: <7t5fzr3cips.fsf@mrwint.cisco.com> References: <4.3.2.7.2.20030123155548.00b6c4f8@funnel.cisco.com> <7t5fzr48vu7.fsf@mrwint.cisco.com> <7t5n0lbejuv.fsf@mrwint.cisco.com> <7t5fzr3cips.fsf@mrwint.cisco.com> User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.2 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 38 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , >>>>> On Wed, 05 Feb 2003 07:03:27 +0000, >>>>> Ole Troan said: >> This would be a possibility. However, I also think we can still >> "overload" the Confirm message so that it can be used for the PD (or >> other stateful resources) case. >> >> I don't want to introduce too-much generalization into the PD spec and >> to delay the standardization. But I do not want to see an easygoing >> compromise either, because this is a good (and perhaps the last) >> chance to make the PD spec complete. So, I'd like to hear from >> others, if anyone else has an opinion on this. > Confirm allows other servers than the one with the binding to reply, > if they have the required information, i.e if the prefix is onlink or > not. I think it is much less likely in the PD case that other servers > than the one with the binding will have the knowledge to determine if > the prefix is correct or not. if you accept this point, then the > scenario you outlined earlier can easily be solved. when Renew is used > as Confirm, Renew should use Confirm's retransmission timers. the > message exchange will stop after 10 seconds, and the requesting router > will go back to soliciting for delegating routers. As I said in the previous message, I think it is possible that the other servers have the (particularly negative) knowledge of the prefix validity. Also, using different parameters for Renew requires a special treatment for PD on the base DHCPv6 specification, so I don't see an advantage of this approach comparing to "overloaded" Confirm. However, either approach would cover the typical case, so I don't stick to the idea of overloaded Confirm. I'll hear from others, and will follow the consensus. (If there is no other opinion, I'll follow the author's decision). JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Feb 5 08:58:02 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25223; Wed, 5 Feb 2003 08:58:02 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h15E3gJ26422; Wed, 5 Feb 2003 09:03:42 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h15E2pJ26386 for ; Wed, 5 Feb 2003 09:02:51 -0500 Received: from nwkea-mail-2.sun.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25187 for ; Wed, 5 Feb 2003 08:56:22 -0500 (EST) Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA17691; Wed, 5 Feb 2003 05:59:57 -0800 (PST) Received: from lillen (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h15DxpP21327; Wed, 5 Feb 2003 14:59:52 +0100 (MET) Date: Wed, 5 Feb 2003 14:56:15 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: [dhcwg] Re: PD lifetimes To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= Cc: Erik Nordmark , dhcwg@ietf.org In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , > IMO, per-prefix (valid) lifetime (with T1/T2), along with some default > rules of conversion, are enough for the ISP to suggest or control > lifetime parameters on downstream links. If you only have the valid lifetime (plus T1 and T2) then it isn't possible for the ISP to drive the renumbering since the ISP can't deprecate a prefix - the site would have to do the deprecation by twiddling something in the router. Thus AFACT if you want to allow the site to delegate renumbering to the ISP using PD you need (optional) valid and preferred lifetimes per prefix. > Also, we need to note the difference on the role of valid/preferred > lifetimes (in DHCPv6 messages) between the PD case and the address > assignment case. In the context of this current thread, the DHCPv6 > lifetimes (particularly the preferred one) are just informational > parameters for PD. On the other hand, the DHCPv6 lifetimes are > essential parameters for address assignment. In fact, there is no > value meaning "any" for the lifetimes in DHCPv6 messages from the > server to the client. Maybe I'm misunderstanding but I don't see that much difference between DHCP address assignment and prefix assignment. If the DHCP server provides a lifetime for the allocation then after that lifetime expires (assuming no successful renew) the address/prefix might no longer work. This still allows the DHCP client to use a shorter lifetime for the address/prefix than the server stated, but, for both address and prefix assignment, using a longer lifetime than the server provided is risky. > > If you add the P and V bits, then wouldn't the decrement behavior be > > controlled by those bits? > > Yes. I guess I was not clear, but I was talking about the "default" > behavior in the bullet 2 above. That is, the P and V bits should be > off (not decrementing) by default. Agreed. > > I'm assuming that if those bits indicate that the lifetimes should not > > decrement in real time, then we need to specify what should happen when > > renew/reply fails. A reasonable approach would be to switch to decrementing > > in real time at that point in time. > > This might make sense, but please let me make it sure. Suppose that > we have been delegated a prefix P/48 with > valid lifetime: 1000sec > V: off > preferred lifetime: 500sec > P: off > T1: 250sec > T2: 400sec > > Then we first advertise (say) P:1/64 on a downstream link, with fixed > lifetime values: 1000 and 500 sec, respectively. After 250 sec later, > we start renew/rebind exchanges, if the exchange fails (after 400secs > since we have been delegated), we need to start decrementing the RA > lifetimes. From which values should we start? 1000 and 500 secs just > before? 600 and 100 secs, considering the period we have spent? Or > others? Good question. The 2 hour rule for stateless addrconf means that decrementing the valid lifetime faster than real time below the 2 hour limit will be ignored by the hosts. Thus I think starting at 1000 and 500 secs makes sense plus documenting that the server should be configured taking T2 into account when determining the max time the prefix will be used. Thus in this example the server thought it was ok for the prefix to be used for 1000+400 secs after it handed it out. Alternatively, the DHCP client should always decrement the lifetimes in real time i.e. the RAs will contain decrementing prefix lifetimes until the renew when the lifetimes would jump back up again. > Yes, I am (sorry if I was not clear). To be more precise and > concrete, suppose that we are delegated a prefix with the valid > lifetime VL at time T. Then if we advertise a downstream prefix (in > an RA) at time T + n(sec), the valid lifetime in the RA must not be > larger than VL - n, unless the delegated prefix is renewed. That fits what I called "alternatively" above, and in that case you don't need the P and V bits. That might be the simplest approach. But you still need a preferred lifetime in PD (with the same deprecating lifetime) in order to enable the case when ISP takes care of renumbering. Erik _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Feb 5 09:19:51 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26181; Wed, 5 Feb 2003 09:19:51 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h15EPYJ28087; Wed, 5 Feb 2003 09:25:34 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h15EOlJ28016 for ; Wed, 5 Feb 2003 09:24:47 -0500 Received: from rtp-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26136 for ; Wed, 5 Feb 2003 09:18:18 -0500 (EST) Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h15EMmWY027043 for ; Wed, 5 Feb 2003 09:22:48 -0500 (EST) Received: from rdroms-w2k.cisco.com (rtp-vpn2-280.cisco.com [10.82.241.24]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id JAA09864 for ; Wed, 5 Feb 2003 09:21:54 -0500 (EST) Message-Id: <4.3.2.7.2.20030205091930.03e4af08@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 05 Feb 2003 09:20:15 -0500 To: dhcwg@ietf.org From: Ralph Droms Subject: Re: [dhcwg] questions about dhcpv6-28 In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , At 03:32 PM 1/26/2003 +0900, JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= wrote: > >>>>> On Thu, 23 Jan 2003 16:22:07 +0900, > >>>>> JINMEI Tatuya said: > > >> 1. Section 18.1.8 says: > > >> When the client receives a NoBinding status in an IA from the server > >> in response to a Renew message or a Rebind message, the client sends > >> a Request to reestablish an IA with the server. > > >> does this imply that the client must remove the IA before sending the > >> request? (I guess the answer is YES, but I'm asking this to be sure.) > >BV> No. As long as the address has a valid lifetime left, the client >BV> should be able to use that address. NoBinding just means that the >BV> server has no record of that binding (perhaps it is a new server >BV> or a server that losts its stable storage). While this situation >BV> is not desireable, it is possible and should work out OK. > > > I see. Then I have a related question. Does the client continue or > > stop sending Renew or Rebind in this case? > >I may have been asking too many things at one time, but I did not get >an answer to this. Could anyone clarify this? The client sends a request with the IA. The server will record the IA and return it to the client with assigned addresses. - Ralph > JINMEI, Tatuya > Communication Platform Lab. > Corporate R&D Center, Toshiba Corp. > jinmei@isl.rdc.toshiba.co.jp >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Feb 5 09:25:16 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26373; Wed, 5 Feb 2003 09:25:16 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h15EV6J28369; Wed, 5 Feb 2003 09:31:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h15EUsJ28341 for ; Wed, 5 Feb 2003 09:30:54 -0500 Received: from rtp-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26361 for ; Wed, 5 Feb 2003 09:24:23 -0500 (EST) Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h15ESrJw027858 for ; Wed, 5 Feb 2003 09:28:54 -0500 (EST) Received: from rdroms-w2k.cisco.com (rtp-vpn2-280.cisco.com [10.82.241.24]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id JAA10165 for ; Wed, 5 Feb 2003 09:28:00 -0500 (EST) Message-Id: <4.3.2.7.2.20030205092337.03deaf10@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 05 Feb 2003 09:25:44 -0500 To: dhcwg@ietf.org From: Ralph Droms Subject: Re: [dhcwg] questions about dhcpv6-28 In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , I agree that we should consider the issue of an inter-server protocol to be out of scope for now. We have experience in designing DHCPv4 so that the client-server protocol is independent of the server-server protocol. I would prefer option 1 - the server ignores a Rebind message for which it has no explicit information. - Ralph At 07:20 PM 2/4/2003 +0900, JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= wrote: >(In the followings, I folded some long lines) > > >>>>> On Tue, 28 Jan 2003 12:42:33 -0600, > >>>>> "Bernie Volz (EUD)" said: > > >> Ralph pointed out to me the possibility of some "magic" between a > >> primary server and a backup server, which allows those servers to be > >> synchronized in real time. I'm not sure how this is realistic, > >> either, but I'd personally prefer to keep the possibility. > > > For DHCPv6 there seems to me a better way to handle things like failover? > > > The two standard mechanisms would be: > > 1. Failover like protocol between the two servers > > 2. Redundant backend database > > > But, with the large IPv6 addresses, there is another way which I > > think is even better and requires no communication between > > "redundant" servers (well, there is the configuration issues but > > there is no need or minimal need for ongoing communication). The > > idea is as follows: > >(snip) > > > I wonder whether the DHC WG might take this on - to specify how > > redundant DHCPv6 services could or should be built? I think it will > > be easier than the DHCPv4 failover work and may not require any > > protocol - just a way of working? But, then perhaps this is simply > > left to the server implementers to decide how best to work and > > interoperability between several vendors is not required? > >Thanks for the detailed analysis. I, for one, think the mechanism to >provide the redundancy among multiple servers can be out of scope for >the dhc wg (at least for now). > >Going back to the original question, what should the server do when it >receives a Rebind containing an IA for which the receiving server does >not have a binding? > >Option 1 (from Ralph): the server should ignore the Rebind unless it >has an "explicit" knowledge that the binding has been invalidated. > >Option 2 (from Bernie): the server should return a Reply with >NoBinding anyway, and let the client choose the reaction based on the >Server Identifier that provided the IA. > >As I said before, I prefer Option 1. > > JINMEI, Tatuya > Communication Platform Lab. > Corporate R&D Center, Toshiba Corp. > jinmei@isl.rdc.toshiba.co.jp >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Feb 5 10:06:46 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27600; Wed, 5 Feb 2003 10:06:46 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h15FCVJ31416; Wed, 5 Feb 2003 10:12:32 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h15FBOJ31377 for ; Wed, 5 Feb 2003 10:11:24 -0500 Received: from rtp-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27538 for ; Wed, 5 Feb 2003 10:04:53 -0500 (EST) Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h15F9N7a004450 for ; Wed, 5 Feb 2003 10:09:24 -0500 (EST) Received: from rdroms-w2k.cisco.com (ch2-dhcp150-75.cisco.com [161.44.150.75]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id KAA13093 for ; Wed, 5 Feb 2003 10:08:30 -0500 (EST) Message-Id: <4.3.2.7.2.20030205100744.00b7d470@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 05 Feb 2003 10:08:28 -0500 To: dhcwg@ietf.org From: Ralph Droms Subject: Re: [dhcwg] questions about dhcpv6-28 In-Reply-To: References: <4.3.2.7.2.20030205091930.03e4af08@funnel.cisco.com> <4.3.2.7.2.20030205091930.03e4af08@funnel.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Whoops, sorry for the misunderstanding. No, the server doesn't send the Renew/Rebind - only the Request. - Ralph At 12:05 AM 2/6/2003 +0900, JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= wrote: > >>>>> On Wed, 05 Feb 2003 09:20:15 -0500, > >>>>> Ralph Droms said: > >BV> No. As long as the address has a valid lifetime left, the client >BV> should be able to use that address. NoBinding just means that the >BV> server has no record of that binding (perhaps it is a new server >BV> or a server that losts its stable storage). While this situation >BV> is not desireable, it is possible and should work out OK. > >> > >> > I see. Then I have a related question. Does the client continue or > >> > stop sending Renew or Rebind in this case? > >> > >> I may have been asking too many things at one time, but I did not get > >> an answer to this. Could anyone clarify this? > > > The client sends a request with the IA. The server will record the IA and > > return it to the client with assigned addresses. > >I know, but my question is if the client should continue to send >Renew/Rebind *as well as sending a Request*. > > JINMEI, Tatuya > Communication Platform Lab. > Corporate R&D Center, Toshiba Corp. > jinmei@isl.rdc.toshiba.co.jp _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Feb 5 10:06:50 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27624; Wed, 5 Feb 2003 10:06:50 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h15FCkJ31439; Wed, 5 Feb 2003 10:12:46 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h15F8WJ31180 for ; Wed, 5 Feb 2003 10:08:32 -0500 Received: from shuttle.wide.toshiba.co.jp (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27472 for ; Wed, 5 Feb 2003 10:02:01 -0500 (EST) Received: from localhost ([3ffe:501:100f:f::6]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id h15F5RP91250; Thu, 6 Feb 2003 00:05:28 +0900 (JST) Date: Thu, 06 Feb 2003 00:05:21 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Ralph Droms Cc: dhcwg@ietf.org Subject: Re: [dhcwg] questions about dhcpv6-28 In-Reply-To: <4.3.2.7.2.20030205091930.03e4af08@funnel.cisco.com> References: <4.3.2.7.2.20030205091930.03e4af08@funnel.cisco.com> User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.2 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 25 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , >>>>> On Wed, 05 Feb 2003 09:20:15 -0500, >>>>> Ralph Droms said: BV> No. As long as the address has a valid lifetime left, the client BV> should be able to use that address. NoBinding just means that the BV> server has no record of that binding (perhaps it is a new server BV> or a server that losts its stable storage). While this situation BV> is not desireable, it is possible and should work out OK. >> >> > I see. Then I have a related question. Does the client continue or >> > stop sending Renew or Rebind in this case? >> >> I may have been asking too many things at one time, but I did not get >> an answer to this. Could anyone clarify this? > The client sends a request with the IA. The server will record the IA and > return it to the client with assigned addresses. I know, but my question is if the client should continue to send Renew/Rebind *as well as sending a Request*. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Feb 5 10:14:13 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27948; Wed, 5 Feb 2003 10:14:13 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h15FK7J31893; Wed, 5 Feb 2003 10:20:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h15FJ0J31773 for ; Wed, 5 Feb 2003 10:19:00 -0500 Received: from rtp-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27875 for ; Wed, 5 Feb 2003 10:12:25 -0500 (EST) Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h15FGrCb005731 for ; Wed, 5 Feb 2003 10:16:53 -0500 (EST) Received: from rdroms-w2k.cisco.com (ch2-dhcp150-75.cisco.com [161.44.150.75]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id KAA13658 for ; Wed, 5 Feb 2003 10:15:59 -0500 (EST) Message-Id: <4.3.2.7.2.20030205101046.03de8280@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 05 Feb 2003 10:15:56 -0500 To: dhcwg@ietf.org From: Ralph Droms Subject: Re: [dhcwg] questions about prefix-delegation-01 In-Reply-To: References: <7t5fzr3cips.fsf@mrwint.cisco.com> <4.3.2.7.2.20030123155548.00b6c4f8@funnel.cisco.com> <7t5fzr48vu7.fsf@mrwint.cisco.com> <7t5n0lbejuv.fsf@mrwint.cisco.com> <7t5fzr3cips.fsf@mrwint.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Suppose the RR were to send a Rebind (instead of Renew) in the case that the RR may have moved to a new link? The upstream DR would process the Rebind and be able to respond immediately with zero lifetimes in the IA_PD, indicating that the prefixes in the IA_PD are no longer valid. - Ralph At 06:27 PM 2/5/2003 +0900, JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= wrote: > >>>>> On Wed, 05 Feb 2003 07:03:27 +0000, > >>>>> Ole Troan said: > > >> This would be a possibility. However, I also think we can still > >> "overload" the Confirm message so that it can be used for the PD (or > >> other stateful resources) case. > >> > >> I don't want to introduce too-much generalization into the PD spec and > >> to delay the standardization. But I do not want to see an easygoing > >> compromise either, because this is a good (and perhaps the last) > >> chance to make the PD spec complete. So, I'd like to hear from > >> others, if anyone else has an opinion on this. > > > Confirm allows other servers than the one with the binding to reply, > > if they have the required information, i.e if the prefix is onlink or > > not. I think it is much less likely in the PD case that other servers > > than the one with the binding will have the knowledge to determine if > > the prefix is correct or not. if you accept this point, then the > > scenario you outlined earlier can easily be solved. when Renew is used > > as Confirm, Renew should use Confirm's retransmission timers. the > > message exchange will stop after 10 seconds, and the requesting router > > will go back to soliciting for delegating routers. > >As I said in the previous message, I think it is possible that the >other servers have the (particularly negative) knowledge of the prefix >validity. Also, using different parameters for Renew requires a >special treatment for PD on the base DHCPv6 specification, so I don't >see an advantage of this approach comparing to "overloaded" Confirm. > >However, either approach would cover the typical case, so I don't >stick to the idea of overloaded Confirm. I'll hear from others, and >will follow the consensus. (If there is no other opinion, I'll follow >the author's decision). > > JINMEI, Tatuya > Communication Platform Lab. > Corporate R&D Center, Toshiba Corp. > jinmei@isl.rdc.toshiba.co.jp _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Feb 5 11:53:52 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01360; Wed, 5 Feb 2003 11:53:52 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h15GxcJ05776; Wed, 5 Feb 2003 11:59:38 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h15GtMJ05490 for ; Wed, 5 Feb 2003 11:55:22 -0500 Received: from shuttle.wide.toshiba.co.jp (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01185 for ; Wed, 5 Feb 2003 11:48:48 -0500 (EST) Received: from localhost ([3ffe:501:100f:f::6]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id h15GpnP92050; Thu, 6 Feb 2003 01:51:52 +0900 (JST) Date: Thu, 06 Feb 2003 01:51:36 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Ralph Droms Cc: dhcwg@ietf.org Subject: Re: [dhcwg] questions about dhcpv6-28 In-Reply-To: <4.3.2.7.2.20030205100744.00b7d470@funnel.cisco.com> References: <4.3.2.7.2.20030205091930.03e4af08@funnel.cisco.com> <4.3.2.7.2.20030205100744.00b7d470@funnel.cisco.com> User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.2 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 29 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , >>>>> On Wed, 05 Feb 2003 10:08:28 -0500, >>>>> Ralph Droms said: > Whoops, sorry for the misunderstanding. No, the server doesn't send the > Renew/Rebind - only the Request. Okay, that makes sense. Perhaps this is too trivial for others, but it would be helpful if the text is clearer: When the client receives a NoBinding status in an IA from the server in response to a Renew message or a Rebind message, the client stops sending Renew or Rebind messages but sends a Request to reestablish an IA with the server. (Section 18.1.8.) I have one more question on this scenario. In this case, the client would send a Request with an IA containing the currently available addresses. For the server, this is just a hint to (re)establish the IA. So, the server may assign a different address for the IA, and send a Reply with the (different) address. What should the client do about the old address? If the client continues to use the old one, it means the client uses an address that is not in the server's binding (though the old address may be invalidated at the next Renew/Reply exchange or when the lifetime expires). Is this situation okay? JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Feb 5 13:20:46 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05331; Wed, 5 Feb 2003 13:20:46 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h15IQUJ12350; Wed, 5 Feb 2003 13:26:31 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h15IMfJ12231 for ; Wed, 5 Feb 2003 13:22:41 -0500 Received: from imr1.ericy.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05144 for ; Wed, 5 Feb 2003 13:16:05 -0500 (EST) Received: from mr5.exu.ericsson.se (mr5u3.ericy.com [208.237.135.124]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id h15IJhd25095; Wed, 5 Feb 2003 12:19:43 -0600 (CST) Received: from eamrcnt761.exu.ericsson.se (eamrcnt761.exu.ericsson.se [138.85.133.39]) by mr5.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id h15IJhe16271; Wed, 5 Feb 2003 12:19:43 -0600 (CST) Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2656.59) id ; Wed, 5 Feb 2003 12:19:42 -0600 Message-ID: From: "Bernie Volz (EUD)" To: "'JINMEI Tatuya / ????'" , Ralph Droms Cc: dhcwg@ietf.org Subject: RE: [dhcwg] questions about dhcpv6-28 Date: Wed, 5 Feb 2003 12:18:09 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2CD42.EFDDDB28" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2CD42.EFDDDB28 Content-Type: text/plain; charset="ISO-2022-JP" I feel that the client can continue to use the old addresses until the lifetimes expire. - Bernie -----Original Message----- From: jinmei@isl.rdc.toshiba.co.jp [mailto:jinmei@isl.rdc.toshiba.co.jp] Sent: Wednesday, February 05, 2003 11:52 AM To: Ralph Droms Cc: dhcwg@ietf.org Subject: Re: [dhcwg] questions about dhcpv6-28 >>>>> On Wed, 05 Feb 2003 10:08:28 -0500, >>>>> Ralph Droms said: > Whoops, sorry for the misunderstanding. No, the server doesn't send the > Renew/Rebind - only the Request. Okay, that makes sense. Perhaps this is too trivial for others, but it would be helpful if the text is clearer: When the client receives a NoBinding status in an IA from the server in response to a Renew message or a Rebind message, the client stops sending Renew or Rebind messages but sends a Request to reestablish an IA with the server. (Section 18.1.8.) I have one more question on this scenario. In this case, the client would send a Request with an IA containing the currently available addresses. For the server, this is just a hint to (re)establish the IA. So, the server may assign a different address for the IA, and send a Reply with the (different) address. What should the client do about the old address? If the client continues to use the old one, it means the client uses an address that is not in the server's binding (though the old address may be invalidated at the next Renew/Reply exchange or when the lifetime expires). Is this situation okay? JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg ------_=_NextPart_001_01C2CD42.EFDDDB28 Content-Type: text/html; charset="ISO-2022-JP" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] questions about dhcpv6-28

I feel that the client can continue to use the old = addresses until the
lifetimes expire.

- Bernie

-----Original Message-----
From: jinmei@isl.rdc.toshiba.co.jp [mailto:jinmei@isl.rdc.toshi= ba.co.jp]
Sent: Wednesday, February 05, 2003 11:52 AM
To: Ralph Droms
Cc: dhcwg@ietf.org
Subject: Re: [dhcwg] questions about = dhcpv6-28


>>>>> On Wed, 05 Feb 2003 10:08:28 = -0500,
>>>>> Ralph Droms = <rdroms@cisco.com> said:

> Whoops, sorry for the misunderstanding.  = No, the server doesn't send the
> Renew/Rebind - only the Request.

Okay, that makes sense.  Perhaps this is too = trivial for others, but
it would be helpful if the text is clearer:

   When the client receives a NoBinding = status in an IA from the server
   in response to a Renew message or a = Rebind message, the client
   stops sending Renew or Rebind messages = but sends a Request to
   reestablish an IA with the = server.
(Section 18.1.8.)

I have one more question on this scenario.  In = this case, the client
would send a Request with an IA containing the = currently available
addresses.  For the server, this is just a hint = to (re)establish the
IA.  So, the server may assign a different = address for the IA, and
send a Reply with the (different) address.  = What should the client do
about the old address?  If the client continues = to use the old one, it
means the client uses an address that is not in the = server's binding
(though the old address may be invalidated at the = next Renew/Reply
exchange or when the lifetime expires).  Is = this situation okay?

        =         =         =         =         JINMEI, = Tatuya
        =         =         =         =         Communication = Platform Lab.
        =         =         =         =         Corporate = R&D Center, Toshiba Corp.
        =         =         =         =         jinmei@isl.rdc.toshiba.co.jp
_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg

------_=_NextPart_001_01C2CD42.EFDDDB28-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Feb 5 13:39:38 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06030; Wed, 5 Feb 2003 13:39:38 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h15IjUJ13591; Wed, 5 Feb 2003 13:45:30 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h15IikJ13551 for ; Wed, 5 Feb 2003 13:44:46 -0500 Received: from imr2.ericy.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05978 for ; Wed, 5 Feb 2003 13:38:09 -0500 (EST) Received: from mr5.exu.ericsson.se (mr5att.ericy.com [138.85.224.141]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id h15Ifnb27748; Wed, 5 Feb 2003 12:41:49 -0600 (CST) Received: from eamrcnt760.exu.ericsson.se (eamrcnt760.exu.ericsson.se [138.85.133.38]) by mr5.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id h15Ifmq25981; Wed, 5 Feb 2003 12:41:48 -0600 (CST) Received: by eamrcnt760.exu.ericsson.se with Internet Mail Service (5.5.2656.59) id ; Wed, 5 Feb 2003 12:41:48 -0600 Message-ID: From: "Bernie Volz (EUD)" To: "'Ralph Droms'" , dhcwg@ietf.org Subject: RE: [dhcwg] questions about dhcpv6-28 Date: Wed, 5 Feb 2003 12:40:13 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2CD46.04F2C3FE" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2CD46.04F2C3FE Content-Type: text/plain; charset="ISO-8859-1" I think we need to think this through a bit more ... If the other servers don't respond, at which point does the client do something differently than continue to Rebind. From 18.1.4, we have: MRD Remaining time until valid lifetimes of all addresses have expired It clearly stops when the valid lifetimes of all addresses expire, however at that point it no longer has any addresses (whereas it could long ago have obtained new addresses from another server and Reply's from other servers with NoBinding would tell the client that other servers exist). Also, for the Rebind case, there is no Server Identifier. So, if the server that originally had the binding crashed and losts its stable storage and comes back on line after the T2 time has started, how does that server even know to respond? It would not since it has no memory. (If the server restarts before T2, it would properly respond to the Renew with NoBinding and all would be well.) In a failover configuration and assuming concepts from the DHCPv4 failover protocol, the lazy update to the peer may also never have occurred. This is why I believe option 2 (having the client make the determination) is much better. The client has the memory of which server gave it the binding. I agree that this has failings in a failover type arrangement [though there are other potential tricks that could be played in this configuration - such as the remaining server responding as if it were the first server, ie, with that server's server identifier that could be played]. Also, if the client receives NO responses to the Rebind, it can conclude there are no other servers so even going to Solicit would do it no good. Yet, if the client does receive NoBindings, perhaps we should allow it (once the PREFERRED LIFETIMES expire), to try a Request or Solicit instead of contining to Rebind? So, we could have the client handle it this way: - If the server that assigned the binding responds with NoBinding, do a Request (or Solicit). - If there are no Replies to the Rebind, continue to Rebind until the valid lifetimes expire. - If there are Replies with NoBinding, the client can make a decision as to whether to Solicit or Request based on the remaining PREFERRED lifetimes. - Bernie -----Original Message----- From: Ralph Droms [mailto:rdroms@cisco.com] Sent: Wednesday, February 05, 2003 9:26 AM To: dhcwg@ietf.org Subject: Re: [dhcwg] questions about dhcpv6-28 I agree that we should consider the issue of an inter-server protocol to be out of scope for now. We have experience in designing DHCPv4 so that the client-server protocol is independent of the server-server protocol. I would prefer option 1 - the server ignores a Rebind message for which it has no explicit information. - Ralph At 07:20 PM 2/4/2003 +0900, JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= wrote: >(In the followings, I folded some long lines) > > >>>>> On Tue, 28 Jan 2003 12:42:33 -0600, > >>>>> "Bernie Volz (EUD)" said: > > >> Ralph pointed out to me the possibility of some "magic" between a > >> primary server and a backup server, which allows those servers to be > >> synchronized in real time. I'm not sure how this is realistic, > >> either, but I'd personally prefer to keep the possibility. > > > For DHCPv6 there seems to me a better way to handle things like failover? > > > The two standard mechanisms would be: > > 1. Failover like protocol between the two servers > > 2. Redundant backend database > > > But, with the large IPv6 addresses, there is another way which I > > think is even better and requires no communication between > > "redundant" servers (well, there is the configuration issues but > > there is no need or minimal need for ongoing communication). The > > idea is as follows: > >(snip) > > > I wonder whether the DHC WG might take this on - to specify how > > redundant DHCPv6 services could or should be built? I think it will > > be easier than the DHCPv4 failover work and may not require any > > protocol - just a way of working? But, then perhaps this is simply > > left to the server implementers to decide how best to work and > > interoperability between several vendors is not required? > >Thanks for the detailed analysis. I, for one, think the mechanism to >provide the redundancy among multiple servers can be out of scope for >the dhc wg (at least for now). > >Going back to the original question, what should the server do when it >receives a Rebind containing an IA for which the receiving server does >not have a binding? > >Option 1 (from Ralph): the server should ignore the Rebind unless it >has an "explicit" knowledge that the binding has been invalidated. > >Option 2 (from Bernie): the server should return a Reply with >NoBinding anyway, and let the client choose the reaction based on the >Server Identifier that provided the IA. > >As I said before, I prefer Option 1. > > JINMEI, Tatuya > Communication Platform Lab. > Corporate R&D Center, Toshiba Corp. > jinmei@isl.rdc.toshiba.co.jp >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg ------_=_NextPart_001_01C2CD46.04F2C3FE Content-Type: text/html; charset="ISO-8859-1" RE: [dhcwg] questions about dhcpv6-28

I think we need to think this through a bit more ...

If the other servers don't respond, at which point does the client do something
differently than continue to Rebind. From 18.1.4, we have:

      MRD   Remaining time until valid lifetimes of all addresses have
            expired

It clearly stops when the valid lifetimes of all addresses expire, however at that
point it no longer has any addresses (whereas it could long ago have obtained new
addresses from another server and Reply's from other servers with NoBinding would
tell the client that other servers exist).

Also, for the Rebind case, there is no Server Identifier. So, if the server that
originally had the binding crashed and losts its stable storage and comes back on
line after the T2 time has started, how does that server even know to respond? It
would not since it has no memory. (If the server restarts before T2, it would
properly respond to the Renew with NoBinding and all would be well.) In a failover
configuration and assuming concepts from the DHCPv4 failover protocol, the lazy
update to the peer may also never have occurred.


This is why I believe option 2 (having the client make the determination) is much
better. The client has the memory of which server gave it the binding. I agree
that this has failings in a failover type arrangement [though there are other
potential tricks that could be played in this configuration - such as the
remaining server responding as if it were the first server, ie, with that server's
server identifier that could be played].

Also, if the client receives NO responses to the Rebind, it can conclude there are
no other servers so even going to Solicit would do it no good. Yet, if the client
does receive NoBindings, perhaps we should allow it (once the PREFERRED LIFETIMES
expire), to try a Request or Solicit instead of contining to Rebind?

So, we could have the client handle it this way:
- If the server that assigned the binding responds with NoBinding, do a Request
(or Solicit).
- If there are no Replies to the Rebind, continue to Rebind until the valid
lifetimes expire.
- If there are Replies with NoBinding, the client can make a decision as to
whether to Solicit or Request based on the remaining PREFERRED lifetimes.

- Bernie

-----Original Message-----
From: Ralph Droms [mailto:rdroms@cisco.com]
Sent: Wednesday, February 05, 2003 9:26 AM
To: dhcwg@ietf.org
Subject: Re: [dhcwg] questions about dhcpv6-28


I agree that we should consider the issue of an inter-server protocol to be
out of scope for now.  We have experience in designing DHCPv4 so that the
client-server protocol is independent of the server-server protocol.

I would prefer option 1 - the server ignores a Rebind message for which it
has no explicit information.

- Ralph

At 07:20 PM 2/4/2003 +0900, JINMEI Tatuya /
=?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= wrote:
>(In the followings, I folded some long lines)
>
> >>>>> On Tue, 28 Jan 2003 12:42:33 -0600,
> >>>>> "Bernie Volz (EUD)" <Bernie.Volz@am1.ericsson.se> said:
>
> >> Ralph pointed out to me the possibility of some "magic" between a
> >> primary server and a backup server, which allows those servers to be
> >> synchronized in real time.  I'm not sure how this is realistic,
> >> either, but I'd personally prefer to keep the possibility.
>
> > For DHCPv6 there seems to me a better way to handle things like failover?
>
> > The two standard mechanisms would be:
> > 1. Failover like protocol between the two servers
> > 2. Redundant backend database
>
> > But, with the large IPv6 addresses, there is another way which I
> > think is even better and requires no communication between
> > "redundant" servers (well, there is the configuration issues but
> > there is no need or minimal need for ongoing communication). The
> > idea is as follows:
>
>(snip)
>
> > I wonder whether the DHC WG might take this on - to specify how
> > redundant DHCPv6 services could or should be built? I think it will
> > be easier than the DHCPv4 failover work and may not require any
> > protocol - just a way of working? But, then perhaps this is simply
> > left to the server implementers to decide how best to work and
> > interoperability between several vendors is not required?
>
>Thanks for the detailed analysis.  I, for one, think the mechanism to
>provide the redundancy among multiple servers can be out of scope for
>the dhc wg (at least for now).
>
>Going back to the original question, what should the server do when it
>receives a Rebind containing an IA for which the receiving server does
>not have a binding?
>
>Option 1 (from Ralph): the server should ignore the Rebind unless it
>has an "explicit" knowledge that the binding has been invalidated.
>
>Option 2 (from Bernie): the server should return a Reply with
>NoBinding anyway, and let the client choose the reaction based on the
>Server Identifier that provided the IA.
>
>As I said before, I prefer Option 1.
>
>                                         JINMEI, Tatuya
>                                         Communication Platform Lab.
>                                         Corporate R&D Center, Toshiba Corp.
>                                         jinmei@isl.rdc.toshiba.co.jp
>_______________________________________________
>dhcwg mailing list
>dhcwg@ietf.org
>https://www1.ietf.org/mailman/listinfo/dhcwg

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg

------_=_NextPart_001_01C2CD46.04F2C3FE-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Feb 5 13:56:52 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06550; Wed, 5 Feb 2003 13:56:51 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h15J2mJ14417; Wed, 5 Feb 2003 14:02:48 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h15HP9J08173 for ; Wed, 5 Feb 2003 12:25:09 -0500 Received: from shuttle.wide.toshiba.co.jp (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02396 for ; Wed, 5 Feb 2003 12:18:34 -0500 (EST) Received: from localhost ([3ffe:501:100f:f::6]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id h15HM2P92250; Thu, 6 Feb 2003 02:22:02 +0900 (JST) Date: Thu, 06 Feb 2003 02:21:54 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Erik Nordmark Cc: dhcwg@ietf.org Subject: Re: [dhcwg] Re: PD lifetimes In-Reply-To: References: User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.2 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: multipart/mixed; boundary="Multipart_Thu_Feb__6_02:21:54_2003-1" X-Dispatcher: imput version 20000228(IM140) Lines: 251 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --Multipart_Thu_Feb__6_02:21:54_2003-1 Content-Type: text/plain; charset=US-ASCII >>>>> On Wed, 5 Feb 2003 14:56:15 +0100 (CET), >>>>> Erik Nordmark said: >> IMO, per-prefix (valid) lifetime (with T1/T2), along with some default >> rules of conversion, are enough for the ISP to suggest or control >> lifetime parameters on downstream links. > If you only have the valid lifetime (plus T1 and T2) then it isn't > possible for the ISP to drive the renumbering since the ISP can't deprecate > a prefix - the site would have to do the deprecation by twiddling something > in the router. > Thus AFACT if you want to allow the site to delegate renumbering to the ISP > using PD you need (optional) valid and preferred lifetimes per prefix. As I replied to Ole, I'm now okay to have the preferred lifetime in the PD specification. So let's concentrate on other points: >> Also, we need to note the difference on the role of valid/preferred >> lifetimes (in DHCPv6 messages) between the PD case and the address >> assignment case. In the context of this current thread, the DHCPv6 >> lifetimes (particularly the preferred one) are just informational >> parameters for PD. On the other hand, the DHCPv6 lifetimes are >> essential parameters for address assignment. In fact, there is no >> value meaning "any" for the lifetimes in DHCPv6 messages from the >> server to the client. > Maybe I'm misunderstanding but I don't see that much difference between > DHCP address assignment and prefix assignment. If the DHCP server provides > a lifetime for the allocation then after that lifetime expires (assuming > no successful renew) the address/prefix might no longer work. > This still allows the DHCP client to use a shorter lifetime for the > address/prefix than the server stated, but, for both address and prefix > assignment, using a longer lifetime than the server provided is risky. Absolutely. I did not say that the client (requesting router) should be able to use longer RA lifetimes than the server (delegating router) provided. Perhaps my point is clearer in a related message in response to Ole (attached below). >> > If you add the P and V bits, then wouldn't the decrement behavior be >> > controlled by those bits? >> >> Yes. I guess I was not clear, but I was talking about the "default" >> behavior in the bullet 2 above. That is, the P and V bits should be >> off (not decrementing) by default. > Agreed. >> > I'm assuming that if those bits indicate that the lifetimes should not >> > decrement in real time, then we need to specify what should happen when >> > renew/reply fails. A reasonable approach would be to switch to decrementing >> > in real time at that point in time. >> >> This might make sense, but please let me make it sure. Suppose that >> we have been delegated a prefix P/48 with >> valid lifetime: 1000sec >> V: off >> preferred lifetime: 500sec >> P: off >> T1: 250sec >> T2: 400sec >> >> Then we first advertise (say) P:1/64 on a downstream link, with fixed >> lifetime values: 1000 and 500 sec, respectively. After 250 sec later, >> we start renew/rebind exchanges, if the exchange fails (after 400secs >> since we have been delegated), we need to start decrementing the RA >> lifetimes. From which values should we start? 1000 and 500 secs just >> before? 600 and 100 secs, considering the period we have spent? Or >> others? > Good question. > The 2 hour rule for stateless addrconf means that decrementing the valid > lifetime faster than real time below the 2 hour limit will be ignored > by the hosts. > Thus I think starting at 1000 and 500 secs makes sense plus documenting > that the server should be configured taking T2 into account when determining > the max time the prefix will be used. > Thus in this example the server thought it was ok for the prefix to be > used for 1000+400 secs after it handed it out. But doesn't this change the semantics of the Valid lifetime? Are you saying the real "lease duration" should be valid lifetime plus T2 (if so, what if T2 is 0, which specifies the client to choose the value)? > Alternatively, the DHCP client should always decrement the lifetimes in > real time i.e. the RAs will contain decrementing prefix lifetimes > until the renew when the lifetimes would jump back up again. >> Yes, I am (sorry if I was not clear). To be more precise and >> concrete, suppose that we are delegated a prefix with the valid >> lifetime VL at time T. Then if we advertise a downstream prefix (in >> an RA) at time T + n(sec), the valid lifetime in the RA must not be >> larger than VL - n, unless the delegated prefix is renewed. > That fits what I called "alternatively" above, and in that case you don't > need the P and V bits. The restriction above is not that strict. The client can use a fixed RA valid lifetime which is much smaller than the PD valid lifetime. This is because I prefer a larger default value for the PD valid lifetime. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp --Multipart_Thu_Feb__6_02:21:54_2003-1 Content-Type: message/rfc822 Date: Wed, 05 Feb 2003 18:00:07 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Ole Troan Cc: rdroms@cisco.com, dhcwg@ietf.org Subject: Re: [dhcwg] Re: PD lifetimes In-Reply-To: <7t5el6neiun.fsf@mrwint.cisco.com> References: <7t5el6neiun.fsf@mrwint.cisco.com> User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.2 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII >>>>> On Tue, 04 Feb 2003 23:17:36 +0000, >>>>> Ole Troan said: >> 0. (I once discussed this point privately, but I could not help >> raising this again. Please forgive me for this repetition.) (snip) >> It would be much simpler to have a single "lifetime" only, which >> controls T1 and T2, and loosely affects the RA lifetimes. > I believe this was brought up during the DHC meeting in Yokohama. the > main argument (coming from Thomas I think) for including the preferred > lifetime was to simplify renumbering. it also allows for more granular > control if PD is used in other contexts than the one specified in the > draft. Okay, according to the discussion in this thread, it seems that I'm in the minority on this. So, I'm okay to keep the preferred lifetime in the PD specification. > the draft specifies how a prefix is delegated but has intentionally > left unspecified (apart from suggesting some defaults) how it is to be > used within the site. the only requirement is that the valid lifetime > is adhered to, anything else can be configured in any way the local > administrator (if there is one) wants. As I said in a separate message, this approach treats the preferred lifetime as (a kind of) optional information, while the preferred lifetime takes an essential role in address assignment. In the PD spec, the valid and preferred lifetimes are sometimes essential and sometimes informational, which make me confused: - the PD valid lifetime specifies the "lease duration" of the site prefix. (this is essential) - the PD valid lifetime also specifies the upper bound of the RA valid lifetime. (this is a bit strong, but still informational) - the PD preferred lifetime controls the (recommended) default values of T1 and T2. (this is essential) - the PD preferred lifetime specifies a suggestion of the RA preferred lifetime. (this is informational) Thus, it would most make sense to me if the essential and informational parts are clearly separated. For example, - we have three parameters for a prefix; lease duration, valid lifetime, and preferred lifetime. we also have T1 and T2 for an IA_PD. - the lease duration is an essential information, which specifies the "lifetime of the site prefix" and must be specified in Reply messages. It also controls the default value of T1 and T2. - the valid and preferred lifetimes are informational, which may or may not be (concretely) specified in Reply messages. If specified, those values mean the suggested values of the RA lifetimes. - there are of course some trivial relationship between the parameters. For instance, the valid and preferred lifetimes must not be larger than the lease duration. (we may need additional bits for the valid and preferred lifetimes as Erik suggested, but I omitted the additional bits here for simplicity.) Doesn't this make much sense? >> In the following comments, however, I'll assume the current valid + >> preferred scheme. >> >> 1. Section 9 says >> >> In a message sent by a delegating router the preferred and valid >> lifetimes should be set to the values specified in section "Router >> Configuration Variables" of RFC2461 [3], unless administratively >> configured. >> >> Technically, the wording 'values specified in section "Router >> Configuration Variables"' is not clear, because the router >> configuration variables of RFC 2461 do not contain the valid and >> preferred lifetimes. The intended variables should probably be >> AdvValidLifetime and AdvPreferredLifetime, respectively. Even so, >> however, I still suspect these are appropriate values. >> AdvXXXLifetimes are for each end host (in a site), but the lifetimes >> given by PD affect the entire site. In general (and IMO), the latter >> should be larger than the former. > section 6.2.1 of RFC2461 does indeed include AdvValidLifetime and > AdvPreferredLifetime, so I'm not sure what is not clear. My point is that the text should be like this: In a message sent by a delegating router the preferred and valid lifetimes should be set to AdvValidLifetime and AdvPreferredLifetime, respectively, as specified in section "Router Configuration Variables" of RFC2461 [3], unless administratively configured. (though I'd like larger default value as I said below.) >> I believe the default values of PD lifetimes should keep the default >> values of RA lifetimes in the typical configuration. Thus, I would >> recommend the following values: (snip) > I don't see decrementing lifetimes in RA's as abnormal, nor do I see > the benefit of advertising fixed values in RA's. there is nothing > prohibiting an requesting router implementation to use fixed values, > as long as it behaves correctly when the PD valid lifetime < RA > lifetime. Regarding this point, please refer to the succeeding discussion in this thread. However, if we clarified the essential and informational parameters (see above), this part might not be an issue. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp --Multipart_Thu_Feb__6_02:21:54_2003-1-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Feb 5 13:56:56 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06574; Wed, 5 Feb 2003 13:56:56 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h15J2wJ14439; Wed, 5 Feb 2003 14:02:58 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h15Ha1J08824 for ; Wed, 5 Feb 2003 12:36:01 -0500 Received: from shuttle.wide.toshiba.co.jp (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02764 for ; Wed, 5 Feb 2003 12:29:26 -0500 (EST) Received: from localhost ([3ffe:501:100f:f::6]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id h15HWtP92344; Thu, 6 Feb 2003 02:32:55 +0900 (JST) Date: Thu, 06 Feb 2003 02:32:50 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Ralph Droms Cc: dhcwg@ietf.org Subject: Re: [dhcwg] questions about prefix-delegation-01 In-Reply-To: <4.3.2.7.2.20030205101046.03de8280@funnel.cisco.com> References: <7t5fzr3cips.fsf@mrwint.cisco.com> <4.3.2.7.2.20030123155548.00b6c4f8@funnel.cisco.com> <7t5fzr48vu7.fsf@mrwint.cisco.com> <7t5n0lbejuv.fsf@mrwint.cisco.com> <4.3.2.7.2.20030205101046.03de8280@funnel.cisco.com> User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.2 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 38 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , >>>>> On Wed, 05 Feb 2003 10:15:56 -0500, >>>>> Ralph Droms said: > Suppose the RR were to send a Rebind (instead of Renew) in the case that > the RR may have moved to a new link? The upstream DR would process the > Rebind and be able to respond immediately with zero lifetimes in the IA_PD, > indicating that the prefixes in the IA_PD are no longer valid. Hmm, I guess you're applying the following part of the base DHCPv6 spec: If the server finds that any of the addresses are no longer appropriate to the link to which the client is attached, the server returns the address to the client with lifetimes of 0. (Section 18.2.4) However, the section also has the following sentence (before this part): If the server cannot find a client entry for the IA the server returns the IA containing no addresses with a Status Code option set to NoBinding in the Reply message. Additionally, according to a recent discussion, we're now agreeing that the upstream server should ignore the Rebind in such a case. So, I don't think we cannot directly apply the case, and this leads me to a same conclusion as Renew: I don't see an advantage to use Rebind against Confirm. However, again, I don't stick to Confirm. I'll follow the final consensus (or the author's decision if there is no particular opinion) as long as the specification is clear and can handle the situation I raised. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Feb 5 16:16:35 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11045; Wed, 5 Feb 2003 16:16:35 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h15LMWJ23979; Wed, 5 Feb 2003 16:22:32 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h15LKtJ23928 for ; Wed, 5 Feb 2003 16:20:55 -0500 Received: from rtp-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11002 for ; Wed, 5 Feb 2003 16:14:17 -0500 (EST) Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h15LIlUo000602; Wed, 5 Feb 2003 16:18:47 -0500 (EST) Received: from rdroms-w2k.cisco.com (ch2-dhcp150-75.cisco.com [161.44.150.75]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id QAA12487; Wed, 5 Feb 2003 16:17:53 -0500 (EST) Message-Id: <4.3.2.7.2.20030205160932.051c5948@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 05 Feb 2003 16:17:49 -0500 To: dhcwg@ietf.org, ipng@sunroof.eng.sun.com, namedroppers@ops.ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [dhcwg] WG last call on draft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This message announces a WG last call on "DNS Configuration options for DHCPv6" . The last call will conclude on Friday, 2/21. Note that this is a parallel WG last call in the dhc, ipv6 and dnsext WGs. draft-ietf-dhc-dhcpv6 opt-dnsconfig-02.txt describes two options for DHCPv6: the Domain Name Server option and the Domain Search List option. This document is being considered for Proposed Standard as an extension to the base DHCPv6 specification, and is available as http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt - Ralph Droms _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Feb 6 09:31:43 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19191; Thu, 6 Feb 2003 09:31:43 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h16Ebpp04047; Thu, 6 Feb 2003 09:37:51 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h16EZ9p03279 for ; Thu, 6 Feb 2003 09:35:09 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18840; Thu, 6 Feb 2003 09:28:08 -0500 (EST) Message-Id: <200302061428.JAA18840@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: dhcwg@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Thu, 06 Feb 2003 09:28:08 -0500 Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-pktc-kerb-tckt-00.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Title : Kerberos Ticket Control Sub-option for the CableLabs Client Configuration Option Author(s) : P. Duffy Filename : draft-ietf-dhc-pktc-kerb-tckt-00.txt Pages : 6 Date : 2003-2-5 This document defines a new sub-option for the CableLabs Client Configuration (CCC) Option. This new sub-option will be used to direct CableLabs Client Devices (CCDs) to invalidate locally persisted Kerberos tickets. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-pktc-kerb-tckt-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-pktc-kerb-tckt-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-pktc-kerb-tckt-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: <2003-2-5135955.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-pktc-kerb-tckt-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-pktc-kerb-tckt-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-2-5135955.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Feb 6 13:00:22 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28297; Thu, 6 Feb 2003 13:00:22 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h16I6op19526; Thu, 6 Feb 2003 13:06:50 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h16HWwp17401 for ; Thu, 6 Feb 2003 12:32:58 -0500 Received: from shuttle.wide.toshiba.co.jp (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26897 for ; Thu, 6 Feb 2003 12:25:54 -0500 (EST) Received: from localhost ([3ffe:501:100f:f::6]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id h16HTOP05176; Fri, 7 Feb 2003 02:29:24 +0900 (JST) Date: Fri, 07 Feb 2003 02:27:51 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: "Bernie Volz (EUD)" Cc: dhcwg@ietf.org Subject: Re: [dhcwg] questions about dhcpv6-28 In-Reply-To: References: User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.2 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 22 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , >>>>> On Wed, 5 Feb 2003 12:18:09 -0600 , >>>>> "Bernie Volz (EUD)" said: > I feel that the client can continue to use the old addresses until the > lifetimes expire. Okay, thanks. > I have one more question on this scenario. In this case, the client > would send a Request with an IA containing the currently available > addresses. For the server, this is just a hint to (re)establish the > IA. So, the server may assign a different address for the IA, and > send a Reply with the (different) address. What should the client do > about the old address? If the client continues to use the old one, it > means the client uses an address that is not in the server's binding > (though the old address may be invalidated at the next Renew/Reply > exchange or when the lifetime expires). Is this situation okay? JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Feb 6 13:00:34 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28325; Thu, 6 Feb 2003 13:00:33 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h16I6Xp19491; Thu, 6 Feb 2003 13:06:34 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h16945p13534 for ; Thu, 6 Feb 2003 04:04:05 -0500 Received: from netcore.fi (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09034 for ; Thu, 6 Feb 2003 03:57:12 -0500 (EST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h1690df18991; Thu, 6 Feb 2003 11:00:39 +0200 Date: Thu, 6 Feb 2003 11:00:38 +0200 (EET) From: Pekka Savola To: Ralph Droms cc: dhcwg@ietf.org, , In-Reply-To: <4.3.2.7.2.20030205160932.051c5948@funnel.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [dhcwg] Re: WG last call on draft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , On Wed, 5 Feb 2003, Ralph Droms wrote: > DHCPv6" . The last call will > conclude on Friday, 2/21. > > Note that this is a parallel WG last call in the dhc, ipv6 and dnsext WGs. > > draft-ietf-dhc-dhcpv6 opt-dnsconfig-02.txt describes two options for > DHCPv6: the Domain Name Server option and the Domain Search List option. > This document is being considered for Proposed Standard as an extension > to the base DHCPv6 specification, and is available as > http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt A few comments; I haven't looked too deep into DHCPv6 to be able to comment on those parts, but there are some definite need for revisal in the doc..: 2. Requirements The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, [...] ==> I'd put these under Introduction or Terminology sections, no use having a separate section with a questionable title. option-length: Length of the 'options' field in octets; must be a multiple of 16 ==> 'options' field has not been defined. Is it the whole option or just the length of DNS-server address options (I assume so)? If the former, there must be 32 bits of zero padding. Is it ok that the options aren't 64-bit aligned? The list of domain names in the 'searchstring' MUST be encoded as specified in section "Representation and use of domain names" of the DHCPv6 specification [4]. ==> I didn't bother to check, but I guess this document also defines how to pad the names to get some desired level of alignment? 6. Appearance of these options The Domain Name Server option MUST appear only in the following messages: Solicit, Advertise, Request, Confirm, Renew, Rebind, Information-Request, Reply. The Domain Search List option MUST appear only in the following messages: Solicit, Advertise, Request, Confirm, Renew, Rebind, Information-Request, Reply. ==> I would reword these differently, like: The Domain Name Server option MUST NOT appear in other than the following messages: .... ==> is it ok to server to give only one of these options but not the other? References ==> split the references [4] Bound, J., Carney, M., Perkins, C., Lemon, T., Volz, B. and R. Droms (ed.), "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", draft-ietf-dhc-dhcpv6-23 (work in progress), February 2002. ==> update this draft version Author's Address Ralph Droms (ed.) ==> the author is an editor, but the draft does not have acknowledgements or contributors section. Just remove Editor if nobody else contributed to the document. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Feb 6 13:54:59 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00174; Thu, 6 Feb 2003 13:54:59 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h16J1Kp23098; Thu, 6 Feb 2003 14:01:20 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h16J10p23070 for ; Thu, 6 Feb 2003 14:01:00 -0500 Received: from pheriche.sun.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00165 for ; Thu, 6 Feb 2003 13:53:54 -0500 (EST) Received: from bebop.France.Sun.COM ([129.157.174.15]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA19717; Thu, 6 Feb 2003 11:57:33 -0700 (MST) Received: from lillen (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h16IvTP10218; Thu, 6 Feb 2003 19:57:29 +0100 (MET) Date: Thu, 6 Feb 2003 19:53:48 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: [dhcwg] Re: PD lifetimes To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= Cc: Erik Nordmark , dhcwg@ietf.org In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , > The restriction above is not that strict. The client can use a fixed > RA valid lifetime which is much smaller than the PD valid lifetime. > This is because I prefer a larger default value for the PD valid > lifetime. Ah - sorry for not understanding that the first time around. That makes sense. Means we don't need P and V flags, right? And the document could say that if the PD lifetimes exceed the RFC 2461 defaults the router should use those defaults, otherwise it should use the PD lifetimes and decrement them in real time. Erik _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Feb 7 03:00:35 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00844; Fri, 7 Feb 2003 03:00:35 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h17874p15073; Fri, 7 Feb 2003 03:07:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1785Bp14890 for ; Fri, 7 Feb 2003 03:05:11 -0500 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA00751 for ; Fri, 7 Feb 2003 02:57:48 -0500 (EST) Received: from esealnt612.al.sw.ericsson.se (esealnt612.al.sw.ericsson.se [153.88.254.71]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h1781QAv024812 for ; Fri, 7 Feb 2003 09:01:27 +0100 (MET) Received: from esealnt135.al.sw.ericsson.se ([153.88.251.92]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id DW0DT93P; Fri, 7 Feb 2003 09:01:26 +0100 Received: by esealnt135.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Fri, 7 Feb 2003 09:01:26 +0100 Message-ID: <1254192C94D3D411B8060008C7E6AEEBF9DF19@esealnt408> X-Sybari-Trust: e5ba1cec 9ffcebbb 7a95d2f4 00000138 From: =?iso-8859-1?Q?Tony_Lindstr=F6m_=28EAB=29?= To: "'dhcwg@ietf.org'" Date: Fri, 7 Feb 2003 08:58:33 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [dhcwg] Comments to draft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , In chapter 6. Appearance of these options 'The Domain Name Server option MUST appear only in the following messages: Solicit, Advertise, Request, Confirm, Renew, Rebind, Information-Request, Reply.' Confirm message should be removed becaue it is not valid anymore. This is even valid for 'Domain Search List' option. In References number 4, The draft should be update with the RFC number when you know it (for "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)"). // Tony _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Feb 7 13:50:05 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17897; Fri, 7 Feb 2003 13:50:04 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h17Iv0p22167; Fri, 7 Feb 2003 13:57:00 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h17ItMp22100 for ; Fri, 7 Feb 2003 13:55:22 -0500 Received: from rtp-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17854 for ; Fri, 7 Feb 2003 13:47:47 -0500 (EST) Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h17Iq88o023764; Fri, 7 Feb 2003 13:52:09 -0500 (EST) Received: from rdroms-w2k.cisco.com (ch2-dhcp150-75.cisco.com [161.44.150.75]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id NAA23161; Fri, 7 Feb 2003 13:51:09 -0500 (EST) Message-Id: <4.3.2.7.2.20030207134618.03eb6930@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 07 Feb 2003 13:51:06 -0500 To: dhcwg@ietf.org, ips@ece.cmu.edu From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [dhcwg] WG last call on Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This message announces a WG last call on "DHCP Options for Internet Storage Name Service" . The last call will conclude on Friday, 2/21. Note that this is a parallel WG last call in the dhc and ips WGs. draft-ietf-dhc-isnsoption-04.txt defines a new DHCP option for discovery of the location and role of iSNS Protocol servers in iSCSI and iFCP devices. The draft is available at http://www.ietf.org/internet-drafts/draft-ietf-dhc-isnsoption-04.txt - Ralph Droms _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Feb 10 11:22:25 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14252; Mon, 10 Feb 2003 11:22:25 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1AGUhp25704; Mon, 10 Feb 2003 11:30:43 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1AGSUp25589 for ; Mon, 10 Feb 2003 11:28:30 -0500 Received: from rtp-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14154 for ; Mon, 10 Feb 2003 11:19:30 -0500 (EST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h1AGNANh009669; Mon, 10 Feb 2003 11:23:11 -0500 (EST) Received: from rdroms-w2k.cisco.com (ch2-dhcp150-75.cisco.com [161.44.150.75]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id LAA02979; Mon, 10 Feb 2003 11:23:10 -0500 (EST) Message-Id: <4.3.2.7.2.20030210111614.00bb13d0@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 10 Feb 2003 11:23:07 -0500 To: dhcwg@ietf.org, , From: Ralph Droms Subject: Re: [dhcwg] Re: WG last call on draft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt In-Reply-To: References: <4.3.2.7.2.20030205160932.051c5948@funnel.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Pekka, Thanks for the review and feedback; my comments are in line... And - for other members of the dhc, dnsext and ipv6 WGS: please respond to this last call notice with comments or an explicit ack to indicate you accept the draft as published. Thanks... - Ralph At 11:00 AM 2/6/2003 +0200, Pekka Savola wrote: >On Wed, 5 Feb 2003, Ralph Droms wrote: > > DHCPv6" . The last call will > > conclude on Friday, 2/21. > > > > Note that this is a parallel WG last call in the dhc, ipv6 and dnsext WGs. > > > > draft-ietf-dhc-dhcpv6 opt-dnsconfig-02.txt describes two options for > > DHCPv6: the Domain Name Server option and the Domain Search List option. > > This document is being considered for Proposed Standard as an extension > > to the base DHCPv6 specification, and is available as > > > http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt > >A few comments; I haven't looked too deep into DHCPv6 to be able to >comment on those parts, but there are some definite need for revisal in >the doc..: > >2. Requirements > > The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, > [...] > >==> I'd put these under Introduction or Terminology sections, no use >having a separate section with a questionable title. > > option-length: Length of the 'options' field in octets; must be a > multiple of 16 Should read "Length of the list of DNS servers in octets; ..." >==> 'options' field has not been defined. Is it the whole option or just >the length of DNS-server address options (I assume so)? If the former, >there must be 32 bits of zero padding. Is it ok that the options aren't >64-bit aligned? It's OK that options are not 64-bit aligned; I don't think the padding is necessary. > The list of domain names in the 'searchstring' MUST be encoded as > specified in section "Representation and use of domain names" of the > DHCPv6 specification [4]. > >==> I didn't bother to check, but I guess this document also defines how >to pad the names to get some desired level of alignment? DHCPv6 doesn't require alignment of the contents of options. >6. Appearance of these options > > The Domain Name Server option MUST appear only in the following > messages: Solicit, Advertise, Request, Confirm, Renew, Rebind, > Information-Request, Reply. > > The Domain Search List option MUST appear only in the following > messages: Solicit, Advertise, Request, Confirm, Renew, Rebind, > Information-Request, Reply. > > >==> I would reword these differently, like: > > The Domain Name Server option MUST NOT appear in other than the following >messages: .... OK. >==> is it ok to server to give only one of these options but not the >other? Yes. >References > >==> split the references OK. > [4] Bound, J., Carney, M., Perkins, C., Lemon, T., Volz, B. and R. > Droms (ed.), "Dynamic Host Configuration Protocol for IPv6 > (DHCPv6)", draft-ietf-dhc-dhcpv6-23 (work in progress), February > 2002. > >==> update this draft version OK. >Author's Address > > Ralph Droms (ed.) > >==> the author is an editor, but the draft does not have acknowledgements >or contributors section. Just remove Editor if nobody else contributed to >the document. Thanks for noticing the oversight. I'll add an acknowledgments seciton. >-- >Pekka Savola "You each name yourselves king, yet the >Netcore Oy kingdom bleeds." >Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Feb 10 12:21:59 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16573; Mon, 10 Feb 2003 12:21:59 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1AHUKp29764; Mon, 10 Feb 2003 12:30:20 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1AHTwp29739 for ; Mon, 10 Feb 2003 12:29:58 -0500 Received: from rtp-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16525 for ; Mon, 10 Feb 2003 12:20:57 -0500 (EST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h1AHOcNh015648; Mon, 10 Feb 2003 12:24:38 -0500 (EST) Received: from rdroms-w2k.cisco.com (ch2-dhcp150-75.cisco.com [161.44.150.75]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id MAA08035; Mon, 10 Feb 2003 12:24:37 -0500 (EST) Message-Id: <4.3.2.7.2.20030210122210.00b665a0@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 10 Feb 2003 12:24:34 -0500 To: "'dhcwg@ietf.org'" , namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com From: Ralph Droms Subject: Re: [dhcwg] Comments to draft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt In-Reply-To: <1254192C94D3D411B8060008C7E6AEEBF9DF19@esealnt408> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Tony, Thanks for the feedback...I've responded in line. - Ralph At 08:58 AM 2/7/2003 +0100, EAB wrote: >In chapter 6. Appearance of these options > >'The Domain Name Server option MUST appear only in the following messages: >Solicit, Advertise, Request, Confirm, Renew, Rebind, Information-Request, >Reply.' > >Confirm message should be removed becaue it is not valid anymore. > >This is even valid for 'Domain Search List' option. Yes. >In References number 4, > >The draft should be update with the RFC number when you know it (for >"Dynamic Host Configuration Protocol for IPv6 (DHCPv6)"). OK. >// Tony >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Feb 10 13:44:08 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20293; Mon, 10 Feb 2003 13:44:08 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1AIqSp02971; Mon, 10 Feb 2003 13:52:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1AIpap02939 for ; Mon, 10 Feb 2003 13:51:36 -0500 Received: from imr1.ericy.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20211 for ; Mon, 10 Feb 2003 13:42:32 -0500 (EST) Received: from mr5.exu.ericsson.se (mr5u3.ericy.com [208.237.135.124]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id h1AIjUd06705; Mon, 10 Feb 2003 12:45:30 -0600 (CST) Received: from eamrcnt760.exu.ericsson.se (eamrcnt760.exu.ericsson.se [138.85.133.38]) by mr5.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id h1AIjUx03167; Mon, 10 Feb 2003 12:45:30 -0600 (CST) Received: by eamrcnt760.exu.ericsson.se with Internet Mail Service (5.5.2656.59) id ; Mon, 10 Feb 2003 12:45:29 -0600 Message-ID: From: "Bernie Volz (EUD)" To: "'Ralph Droms'" , dhcwg@ietf.org, ipng@sunroof.eng.sun.com, namedroppers@ops.ietf.org Subject: RE: [dhcwg] Re: WG last call on draft-ietf-dhc-dhcpv6-opt-dnsconf ig-02.txt Date: Mon, 10 Feb 2003 12:43:54 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2D134.5C6074C8" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2D134.5C6074C8 Content-Type: text/plain; charset="ISO-8859-1" Ralph: All of the previous comments should be incorporated. But, in addition: Section 4 and 5 state that a "Server sends ... option to the DHCP client". However, the list of messages in which these options may appear includes client generated messages (Solicit, Request, Renew, Rebind, Information-Request). I believe that client generated messages can request these option codes in an ORO option, but should they include these options? There may be little harm in allowing them? Though it is difficult to see how they could appear in a Solicit even in that case. In section 7, for: Because the Domain Search List option may be used to spoof DNS name resolution in a way that cannot be detected by DNS security mechanisms like DNSSEC [5], DHCP clients and servers MUST use authenticated DHCP when a Domain Search List option is included in a DHCP message. Might it be better to instead state that a client MUST NOT install the Domain Search List unless the message was authenticated? This is cleaner as to what it requires a client and server to do. It is difficult for a client to know in advance whether a server will supply the option? The same might be true of the Domain Name Server option?? Otherwise, the draft looks fine and I would like to see it advanced. - Bernie Volz -----Original Message----- From: Ralph Droms [mailto:rdroms@cisco.com] Sent: Monday, February 10, 2003 11:23 AM To: dhcwg@ietf.org; ipng@sunroof.eng.sun.com; namedroppers@ops.ietf.org Subject: Re: [dhcwg] Re: WG last call on draft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt Pekka, Thanks for the review and feedback; my comments are in line... And - for other members of the dhc, dnsext and ipv6 WGS: please respond to this last call notice with comments or an explicit ack to indicate you accept the draft as published. Thanks... - Ralph ------_=_NextPart_001_01C2D134.5C6074C8 Content-Type: text/html; charset="ISO-8859-1" RE: [dhcwg] Re: WG last call on draft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt

Ralph:

All of the previous comments should be incorporated. But, in addition:

Section 4 and 5 state that a "Server sends ... option to the DHCP client".
However, the list of messages in which these options may appear includes
client generated messages (Solicit, Request, Renew, Rebind,
Information-Request).

I believe that client generated messages can request these option codes
in an ORO option, but should they include these options? There may be
little harm in allowing them? Though it is difficult to see how they
could appear in a Solicit even in that case.

In section 7, for:

   Because the Domain Search List option may be used to spoof DNS name
   resolution in a way that cannot be detected by DNS security
   mechanisms like DNSSEC [5], DHCP clients and servers MUST use
   authenticated DHCP when a Domain Search List option is included in a
   DHCP message.

Might it be better to instead state that a client MUST NOT install the Domain
Search List unless the message was authenticated? This is cleaner as to what
it requires a client and server to do. It is difficult for a client to know
in advance whether a server will supply the option?

The same might be true of the Domain Name Server option??

Otherwise, the draft looks fine and I would like to see it advanced.

- Bernie Volz

-----Original Message-----
From: Ralph Droms [mailto:rdroms@cisco.com]
Sent: Monday, February 10, 2003 11:23 AM
To: dhcwg@ietf.org; ipng@sunroof.eng.sun.com; namedroppers@ops.ietf.org
Subject: Re: [dhcwg] Re: WG last call on
draft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt


Pekka,

Thanks for the review and feedback; my comments are in line...

And - for other members of the dhc, dnsext and ipv6 WGS: please
respond to this last call notice with comments or an explicit
ack to indicate you accept the draft as published.  Thanks...

- Ralph

------_=_NextPart_001_01C2D134.5C6074C8-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Feb 10 14:37:48 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22063; Mon, 10 Feb 2003 14:37:47 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1AJkDp06535; Mon, 10 Feb 2003 14:46:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1AJcsp06108 for ; Mon, 10 Feb 2003 14:38:54 -0500 Received: from momotombo.TechFak.Uni-Bielefeld.DE (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21719 for ; Mon, 10 Feb 2003 14:29:51 -0500 (EST) Received: from grimsvotn.TechFak.Uni-Bielefeld.DE (grimsvotn.TechFak.Uni-Bielefeld.DE [129.70.137.40]) by momotombo.TechFak.Uni-Bielefeld.DE (8.11.6+Sun/8.11.6/TechFak/pk+ro20010720) with ESMTP id h1AJRdU09073; Mon, 10 Feb 2003 20:27:39 +0100 (MET) Received: from localhost (pk@localhost) by grimsvotn.TechFak.Uni-Bielefeld.DE (8.11.6+Sun/8.9.1) with SMTP id h1AJRdu16843; Mon, 10 Feb 2003 20:27:39 +0100 (MET) Message-Id: <200302101927.h1AJRdu16843@grimsvotn.TechFak.Uni-Bielefeld.DE> X-Authentication-Warning: grimsvotn.TechFak.Uni-Bielefeld.DE: pk owned process doing -bs X-Authentication-Warning: grimsvotn.TechFak.Uni-Bielefeld.DE: pk@localhost didn't use HELO protocol To: Ralph Droms Cc: dhcwg@ietf.org, ipng@sunroof.eng.sun.com, namedroppers@ops.ietf.org In-reply-to: Your message of "Wed, 05 Feb 2003 16:17:49 EST." <4.3.2.7.2.20030205160932.051c5948@funnel.cisco.com> X-Organization: Uni Bielefeld, Technische Fakultaet X-Phone: +49 521 106 2902 Date: Mon, 10 Feb 2003 20:27:39 +0100 From: Peter Koch Subject: [dhcwg] Re: WG last call on draft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , > draft-ietf-dhc-dhcpv6 opt-dnsconfig-02.txt describes two options for > DHCPv6: the Domain Name Server option and the Domain Search List > This document uses terminology specific to IPv6 and DHCPv6 as defined > in section "Terminology" of the DHCP specification. Might want to add an explicit normative reference here? > 4. Domain Name Server option > > The Domain Name Server option provides a list of one or more IP > addresses of DNS servers to which a client's DNS resolver MAY send From a purist's point of view I'm tempted to say that you're not really looking for a DNS server here but instead for a (list of) recursive resolvers. > DNS-server: IP address of DNS server I did not follow the DHCPv6 effort too close, so I must admit not knowing the usual "culture", but wouldn't it be better to say IPv6 address here? > A server sends a Domain Search List option to the DHCP client to > specify the domain search list the client is to use when resolving > hostnames with DNS. This option does not apply to other name > resolution mechanisms. The draft does not say for which kind of domain names the client is expected to process the list, i.e. one-label names only, n-label names (how to communicate the 'n', aka 'ndots', then?) or whether this is left to the application(s). > Because the Domain Search List option may be used to spoof DNS name > resolution in a way that cannot be detected by DNS security > mechanisms like DNSSEC [5], DHCP clients and servers MUST use Apart from the sad fact that DNSSEC isn't yet deployed I don't see why it wouldn't be able to detect spoofing. If, however, you want to say that using domain names in the search list you don't control is a dangerous thing, that could be emphazised by a reference to RFC 1535. > authenticated DHCP when a Domain Search List option is included in a > DHCP message. Why is this a MUST while there's a SHOULD only for the server option? -Peter _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Feb 10 18:30:20 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00293; Mon, 10 Feb 2003 18:30:20 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1ANcfp22359; Mon, 10 Feb 2003 18:38:41 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1ANbUp22320 for ; Mon, 10 Feb 2003 18:37:30 -0500 Received: from rtp-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00264 for ; Mon, 10 Feb 2003 18:28:21 -0500 (EST) Received: from goblet.cisco.com (IDENT:mirapoint@goblet.cisco.com [161.44.168.80]) by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h1ANVxNh007787; Mon, 10 Feb 2003 18:32:00 -0500 (EST) Received: from KKINNEAR-W2K.cisco.com (che-vpn-cluster-2-84.cisco.com [10.86.242.84]) by goblet.cisco.com (Mirapoint) with ESMTP id ACP10580; Mon, 10 Feb 2003 18:31:56 -0500 (EST) Message-Id: <4.3.2.7.2.20030210170642.025d8f08@goblet.cisco.com> X-Sender: kkinnear@goblet.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 10 Feb 2003 18:31:56 -0500 To: Thomas Narten , dhcwg@ietf.org From: Kim Kinnear Subject: Re: [dhcwg] lease query question Cc: kkinnear@cisco.com, rdroms@cisco.com, "Woundy, Richard" In-Reply-To: <200302041628.h14GSfc26441@rotala.raleigh.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , At 11:28 AM 2/4/2003, Thomas Narten wrote: >I've started my AD review on draft-ietf-dhc-leasequery-04.txt, and >have a basic question. From the problem statement, I understood the >problem to be fairly narrowly scoped, that is, an ability to rebuild >the state that an access concentrator builds from gleaned DHC >messages, but loses if it (say) restarts. The abstract/problem >statement says: > > Access concentrators that act as DHCP relay agents need to determine > the endpoint locations of IP addresses across public broadband access > networks such as cable, DSL, and wireless networks. Because ARP > broadcasts are undesirable in public networks, many access > concentrator implementations "glean" location information from DHCP > messages forwarded by its relay agent function. Unfortunately, the > typical access concentrator loses its gleaned information when the > access concentrator is rebooted or is replaced. This memo proposes > that when gleaned DHCP information is not available, the access > concentrator/relay agent obtains the location information directly > from the DHCP server(s) using a new, lightweight DHCPLEASEQUERY > message. We have evolved the leasequery capability and draft quite a bit without, perhaps, similarly evolving the abstract/problem statement. This is due, no doubt, to the fact that it has taken quite a while to get this draft completed. Having said that (which is true), I don't see significant deviation from at least my conceptualization of the current problem the leasequery protocol/draft solves. There are implementations of this capability in the field today, and the actual draft is informed by not only our intellectual exercises in protocol design but by actual implementations and actual users of those implementations with real requirements. If you think there is dramatic mis-match between the problem statement with the actual protocol, we can certainly revise the problem statement to whatever degree you deem necessary. >That is, I assumed that what is needed is a mechanism that allows a >concentrator to avoid the need to invoke ARP, by querying the DHC >server instead. To achieve this, I would have assumed that a simple >query-response protocol that would solve the problem as stated. That >is, I would have assumed perhaps two queries: > > - tell me the IP addresses of all devices behind a particular > link-layer "MAC", or [note: one might use this to rebuild state > about a particular link] > > - Tell me which of my links (if any) the following IP address resides > on. [note: one might use this if one received an packet to forward, > and needed to do the equivalent of "ARP" for it] > >I would expect that the leasequery might say "give me the info", and >the server would respond with the same info it would give the >client. I.e, the information received is the same as that it would >glean from the normal DHC trafic (and in particular, without any new >information specific to the leasequery protocol). Largely, this is what it does. >But the protocol is quite a bit more complex than that. For example, a >server can respond with a "sort of" answer, one that indicates I don't >have a lease, but I did in the past. Likewise, there is also an R bit >for providing further information about the details of a particular >lease. To a first approximation, the server is trying to supply information that is similar to that it would supply to the DHCP client. However, the client of a leasequery is not precisely identical to the DHCP client that is requesting a lease. So, for instance, if a "real" DHCP client was talking to the DHCP server, it would give the client a lease (as opposed to telling the client that it had a lease at some point in the past). However, the client for a leasequery request isn't looking for a lease -- it is looking for information *about* a lease. Allowing a server to return information that indicates that a lease existed for a client at sometime in the past may well be useful to a device which is trying to rebuild its state, since this is information that it normally would have available if it had not lost its state. The R bit is designed to allow a device which uses DHCP gleaning to also operate correctly in the event that some IP addresses are "hard coded" or "hand configured". In this case, if the DHCP server is supplied with a reservation for the hand configured IP<->MAC relationship, then if the DHCP client asks for an IP address, it will get the proper one. More importantly, the leasequery client doesn't have to be configured with the hand-configured IP address, since it can determine which IP addresses are "allowable" from the results of a leasequery. This is indeed a capability that the leasequery protocol allows that isn't possible in a straightforward way without it. You could argue that it is a convenience, I suppose, and that it is beyond the mission statement of the original protocol. It is one of the capabilities that has been requested by actual users of devices that utilize the leasequery protocol, since those devices are much less useful if you have to hand configure them with this information. Some major customers have argued that this sort of capability fits squarely into the leasequery approach, and we agree with them. But you are right -- this is a capability that is somewhat beyond what was possible without the leasequery protocol. >I don't fully understand the motivation or need for the additional >stuff. There seem to be some unstated assumptions about the nature of >the problem being solved. Could someone please clarify what the actual >problem is that needs solving here? I guess that I don't understand exactly which stuff you consider extraneous, other than the two points which I already addressed above. One of those capabilities I don't consider extraneous, and the other I see only as a logical extension to the basic capability, so I can't reason from those to the other things that you find "additional". Were I to state the problem that leasequery is trying to solve without reference to the original problem statement (as something of an exercise), I would say: Router-type devices which want to enforce some level of access control over which IP addresses are allowed on their links need to maintain information concerning IP<->MAC/client-id mappings using DHCP gleaning, and these devices don't typically have stable storage sufficient to keep this information over reloads. The leasequery request allows them to efficiently rebuild this information as necessary. Moreover, for these devices to be as useful in as many environments as possible, some information not available from DHCP gleaning can also be determined by using the leasequery capability. But that explanation is only a slight extension from what we already have in the draft (and that you quoted above). I'll be glad to pursue this if you wish. I can either add some variant of the last sentence above to the mission statement in the draft. Alternatively we can discuss other items that you consider beyond the scope of the leasequery protocol. In order to do that effectively, I'm going to have to have additional information as to which other capabilities you consider "additional". I don't expect any difficulty explaining why they 'fit' into the mission statement of the protocol, or to expanding the mission statement to cover them, for what that is worth. I don't think that it is any more complex than it needs to be to solve the task at hand, though I'll admit the task is becoming something of a second generation task as opposed to a first generation task. Cheers -- Kim >Thomas >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Feb 11 04:18:02 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24424; Tue, 11 Feb 2003 04:18:02 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1B9Qfp31881; Tue, 11 Feb 2003 04:26:41 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1B9Plp31849 for ; Tue, 11 Feb 2003 04:25:47 -0500 Received: from ratree.psu.ac.th (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24400 for ; Tue, 11 Feb 2003 04:16:25 -0500 (EST) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h1B9Ixn11951; Tue, 11 Feb 2003 16:19:00 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h1B9IOb19962; Tue, 11 Feb 2003 16:18:25 +0700 (ICT) From: Robert Elz To: Ralph Droms cc: dhcwg@ietf.org, ipng@sunroof.eng.sun.com, namedroppers@ops.ietf.org Subject: Re: [dhcwg] Re: WG last call on draft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt In-Reply-To: <4.3.2.7.2.20030210111614.00bb13d0@funnel.cisco.com> References: <4.3.2.7.2.20030210111614.00bb13d0@funnel.cisco.com> <4.3.2.7.2.20030205160932.051c5948@funnel.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 11 Feb 2003 16:18:24 +0700 Message-ID: <19960.1044955104@munnari.OZ.AU> Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Date: Mon, 10 Feb 2003 11:23:07 -0500 From: Ralph Droms Message-ID: <4.3.2.7.2.20030210111614.00bb13d0@funnel.cisco.com> | And - for other members of the dhc, dnsext and ipv6 WGS: please | respond to this last call notice with comments or an explicit | ack to indicate you accept the draft as published. Thanks... With the various changes (mostly fairly minor) that have been suggested, it looks Ok to me. kre _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Feb 11 06:13:44 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27401; Tue, 11 Feb 2003 06:13:44 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1BBMTp05963; Tue, 11 Feb 2003 06:22:30 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1B59bp07684 for ; Tue, 11 Feb 2003 00:09:37 -0500 Received: from shuttle.wide.toshiba.co.jp (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA08715 for ; Tue, 11 Feb 2003 00:00:21 -0500 (EST) Received: from localhost ([3ffe:501:4819:2000:200:39ff:fe10:85d7]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id h1B53vP54529; Tue, 11 Feb 2003 14:03:57 +0900 (JST) Date: Tue, 11 Feb 2003 14:03:58 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Ralph Droms Cc: dhcwg@ietf.org, , Subject: Re: [dhcwg] Re: WG last call on draft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt In-Reply-To: <4.3.2.7.2.20030210111614.00bb13d0@funnel.cisco.com> References: <4.3.2.7.2.20030205160932.051c5948@funnel.cisco.com> <4.3.2.7.2.20030210111614.00bb13d0@funnel.cisco.com> User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.2 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 15 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , >>>>> On Mon, 10 Feb 2003 11:23:07 -0500, >>>>> Ralph Droms said: > And - for other members of the dhc, dnsext and ipv6 WGS: please > respond to this last call notice with comments or an explicit > ack to indicate you accept the draft as published. Thanks... I'm okay to publish the draft. I've reviewed it, and implemented the Domain Name Server option. The specification is useful and important, and (at least regarding the part I implemented) working well. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Feb 11 06:45:23 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28502; Tue, 11 Feb 2003 06:45:23 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1BBs8p07756; Tue, 11 Feb 2003 06:54:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1BBrOp07725 for ; Tue, 11 Feb 2003 06:53:24 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28197; Tue, 11 Feb 2003 06:44:01 -0500 (EST) Message-Id: <200302111144.GAA28197@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: dhcwg@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 11 Feb 2003 06:44:01 -0500 Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-dhcpv6-opt-prefix-delegation-02.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Title : IPv6 Prefix Options for DHCPv6 Author(s) : O. Troan, R. Droms Filename : draft-ietf-dhc-dhcpv6-opt-prefix-delegation-02.txt Pages : 18 Date : 2003-2-10 The Prefix Delegation options provide a mechanism for automated delegation of IPv6 prefixes using DHCP. This mechanism is intended for delegating long-lived prefix from a delegating router to a requesting router, across an administrative boundary, where the delegating router does not require knowledge about the topology of the links in the network to which the prefixes will be assigned. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-opt-prefix-delegation-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dhc-dhcpv6-opt-prefix-delegation-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-dhcpv6-opt-prefix-delegation-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. --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: <2003-2-10132628.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-dhcpv6-opt-prefix-delegation-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-dhcpv6-opt-prefix-delegation-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-2-10132628.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Feb 11 07:10:47 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00070; Tue, 11 Feb 2003 07:10:47 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1BCJTp09659; Tue, 11 Feb 2003 07:19:29 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1BCHip09375 for ; Tue, 11 Feb 2003 07:17:44 -0500 Received: from palrel12.hp.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29991 for ; Tue, 11 Feb 2003 07:08:20 -0500 (EST) Received: from iconsrv5.india.hp.com (iconsrv5.india.hp.com [15.42.229.13]) by palrel12.hp.com (Postfix) with ESMTP id 00E8B1C01586 for ; Tue, 11 Feb 2003 04:12:02 -0800 (PST) Received: from india.hp.com (nt23074.india.hp.com [15.42.230.74]) by iconsrv5.india.hp.com (8.9.3/8.9.3 SMKit7.02) with ESMTP id RAA16303 for ; Tue, 11 Feb 2003 17:41:26 +0530 (IST) Message-ID: <3E48E971.4020100@india.hp.com> Date: Tue, 11 Feb 2003 17:45:45 +0530 From: B Naveen User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020830 X-Accept-Language: en-us, en MIME-Version: 1.0 To: dhcwg@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [dhcwg] should the client id be unique across subnets? Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit RFC 2132 says," the client identifier value is expected to be unique for all clients in an administrative domain " (section 9.14). Also under the same section, we have "for correct identification of clients, each client's client-identifier MUST be unique among the client-identifiers used on the subnet to which the client is attached". Say a client is plugged to subnet A. After a while, this machine is moved to subnet B. At this time, it is desirable for the dhcp server to release the previous IP address, and grant a new IP address to the machine in the new subnet. The identification of the client is through the client-identifier. Therefore, if the client-identifier is unique among all the dhcp clients, then we can implement this feature. But unfortunately, if there are 2 clients with the same client identifier but different subnet, then there may be a problem with the above mentioned feature. I am not very clear on this part of client-identifier. Can anybody throw some light on this issue? Thanks and Regards, Naveen. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Feb 11 08:09:32 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03462; Tue, 11 Feb 2003 08:09:32 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1BDINp13668; Tue, 11 Feb 2003 08:18:23 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1BDHwp13622 for ; Tue, 11 Feb 2003 08:17:58 -0500 Received: from ratree.psu.ac.th (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03434 for ; Tue, 11 Feb 2003 08:08:31 -0500 (EST) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h1BDBtn09605; Tue, 11 Feb 2003 20:11:58 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h1BDBmb21311; Tue, 11 Feb 2003 20:11:51 +0700 (ICT) From: Robert Elz To: B Naveen cc: dhcwg@ietf.org Subject: Re: [dhcwg] should the client id be unique across subnets? In-Reply-To: <3E48E971.4020100@india.hp.com> References: <3E48E971.4020100@india.hp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 11 Feb 2003 20:11:48 +0700 Message-ID: <21309.1044969108@munnari.OZ.AU> Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Date: Tue, 11 Feb 2003 17:45:45 +0530 From: B Naveen Message-ID: <3E48E971.4020100@india.hp.com> | Say a client is plugged to subnet A. After a while, this machine | is moved to subnet B. At this time, it is desirable for the dhcp | server to release the previous IP address, No, it shouldn't do that (until the lease expires anyway). | and grant a new IP address to the machine in the new subnet. Obviously... If the client then moves back to subnet A, while its lease on that subnet is still valid (and assuming it wasn't released) then the client can (after attempting to communicate with the DHCP server, and perhaps failing) simply use the old lease. If the server has released it, just because the client turned up somewhere else (and worse, reassigned it to someone else) that fails. Lease times MUST be respected by servers (excepting only when they receive a release request). I think this makes the rest of your question moot. That is, it simply doesn't matter whether client ids are supposed to be unique everywhere, or only unique on the net (about the only place where it might matter would be if the client wanted to release an old address after it has moved to a new subnet). kre _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Feb 11 08:50:29 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04795; Tue, 11 Feb 2003 08:50:28 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1BDxHp16158; Tue, 11 Feb 2003 08:59:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1BDwIp16117 for ; Tue, 11 Feb 2003 08:58:18 -0500 Received: from e31.co.us.ibm.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04739 for ; Tue, 11 Feb 2003 08:48:51 -0500 (EST) Received: from westrelay04.boulder.ibm.com (westrelay04.boulder.ibm.com [9.17.193.32]) by e31.co.us.ibm.com (8.12.7/8.12.2) with ESMTP id h1BDqYCA061552; Tue, 11 Feb 2003 08:52:34 -0500 Received: from austin.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay04.boulder.ibm.com (8.12.3/NCO/VER6.5) with ESMTP id h1BDqXrH157786; Tue, 11 Feb 2003 06:52:33 -0700 Received: from popmail.austin.ibm.com (popmail.austin.ibm.com [9.41.248.164]) by austin.ibm.com (8.12.6/8.12.6) with ESMTP id h1BDqW5t040822; Tue, 11 Feb 2003 07:52:32 -0600 Received: from austin.ibm.com (vallab.austin.ibm.com [9.41.86.83]) by popmail.austin.ibm.com (AIX4.3/8.9.3/8.7-client1.01) with ESMTP id HAA03622; Tue, 11 Feb 2003 07:52:32 -0600 Message-ID: <3E49001F.AC59F984@austin.ibm.com> Date: Tue, 11 Feb 2003 07:52:31 -0600 From: "Vasu, Vallabhaneni" Organization: IBM X-Mailer: Mozilla 4.79 [en] (X11; U; AIX 5.1) X-Accept-Language: en MIME-Version: 1.0 To: B Naveen CC: dhcwg@ietf.org Subject: Re: [dhcwg] should the client id be unique across subnets? References: <3E48E971.4020100@india.hp.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit B Naveen wrote: > RFC 2132 says," the client identifier value is expected > to be unique for all clients in an administrative domain " > (section 9.14). > > Also under the same section, we have "for correct > identification of clients, each client's client-identifier MUST be > unique among the client-identifiers used on the subnet to which > the client is attached". > > Say a client is plugged to subnet A. After a while, this machine > is moved to subnet B. At this time, it is desirable for the dhcp > server to release the previous IP address, and grant a new IP > address to the machine in the new subnet. The identification of > the client is through the client-identifier. Therefore, if the > client-identifier is unique among all the dhcp clients, then we > can implement this feature. > > But unfortunately, if there are 2 clients with the same client > identifier but different subnet, then there may be a problem > with the above mentioned feature. Yup you are right about this. I have seen the dhcp servers they look for the client identifier to be unique for the administrative domain of the dhcp server and I think this is the correct behaviour. I think clients should generate their client identifier as they defined in IPv6 dhcp RFC. > > > I am not very clear on this part of client-identifier. Can > anybody throw some light on this issue? > > Thanks and Regards, > Naveen. > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Feb 11 10:24:45 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08233; Tue, 11 Feb 2003 10:24:44 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1BFXSp22088; Tue, 11 Feb 2003 10:33:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1BFWsp22064 for ; Tue, 11 Feb 2003 10:32:54 -0500 Received: from rtp-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08199 for ; Tue, 11 Feb 2003 10:23:27 -0500 (EST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h1BFR7Nh002492; Tue, 11 Feb 2003 10:27:08 -0500 (EST) Received: from rdroms-w2k.cisco.com (ch2-dhcp150-75.cisco.com [161.44.150.75]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id KAA21726; Tue, 11 Feb 2003 10:27:07 -0500 (EST) Message-Id: <4.3.2.7.2.20030211102344.03d88c40@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 11 Feb 2003 10:27:05 -0500 To: dhcwg@ietf.org, ipng@sunroof.eng.sun.com From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [dhcwg] WG last call on draft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This message announces a WG last call on "IPv6 Prefix Options for DHCPv6" . The last call will conclude on Friday, 2/28. Note that this is a parallel WG last call in the dhc, and ipv6 WGs. draft-ietf-dhc-dhcpv6-opt-prefix-delegation-02.txt describes new DHCPv6 options and a mechanism through which a "delegating router" (e.g., an ISP aggregation device) can assign and delegate one or more prefixes to a "requesting router" (e.g., CPE). This draft is available as http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-opt-prefix-delegation-02.txt - Ralph Droms _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Feb 11 10:35:23 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08528; Tue, 11 Feb 2003 10:35:22 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1BFiGp23203; Tue, 11 Feb 2003 10:44:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1BFhip23165 for ; Tue, 11 Feb 2003 10:43:44 -0500 Received: from rtp-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08475 for ; Tue, 11 Feb 2003 10:34:17 -0500 (EST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h1BFbwNh003200; Tue, 11 Feb 2003 10:37:58 -0500 (EST) Received: from rdroms-w2k.cisco.com (ch2-dhcp150-75.cisco.com [161.44.150.75]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id KAA23101; Tue, 11 Feb 2003 10:37:57 -0500 (EST) Message-Id: <4.3.2.7.2.20030211103734.03d92e18@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 11 Feb 2003 10:37:56 -0500 To: dhcwg@ietf.org, ipng@sunroof.eng.sun.com From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [dhcwg] WG last call on draft-ietf-dhc-dhcpv6-opt-prefix-delegation-02.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , (resent with correct Subject:) This message announces a WG last call on "IPv6 Prefix Options for DHCPv6" . The last call will conclude on Friday, 2/28. Note that this is a parallel WG last call in the dhc, and ipv6 WGs. draft-ietf-dhc-dhcpv6-opt-prefix-delegation-02.txt describes new DHCPv6 options and a mechanism through which a "delegating router" (e.g., an ISP aggregation device) can assign and delegate one or more prefixes to a "requesting router" (e.g., CPE). This draft is available as http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-opt-prefix-delegation-02.txt - Ralph Droms _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Feb 11 11:13:25 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09551; Tue, 11 Feb 2003 11:13:25 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1BGMKp25358; Tue, 11 Feb 2003 11:22:20 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1BGLbp25329 for ; Tue, 11 Feb 2003 11:21:37 -0500 Received: from chimera.incognito.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09524 for ; Tue, 11 Feb 2003 11:12:08 -0500 (EST) Received: from homerdmz.incognito.com ([207.102.214.106] helo=homer.incognito.com.) by chimera.incognito.com with smtp (Exim 3.35 #1 (Debian)) id 18id4Z-0007ax-00 for ; Tue, 11 Feb 2003 08:15:51 -0800 Received: by homer.incognito.com. with Internet Mail Service (5.5.2653.19) id <13JRG88N>; Tue, 11 Feb 2003 08:21:53 -0800 Message-ID: <4FB49E60CFBA724E88867317DAA3D198E1DEC4@homer.incognito.com.> From: "Cosmo, Patrick" To: dhcwg@ietf.org Date: Tue, 11 Feb 2003 08:21:52 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2D1E9.AFEF0EA0" Subject: [dhcwg] Assigning Option Codes Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2D1E9.AFEF0EA0 Content-Type: text/plain; charset="iso-8859-1" The IANA appears to have a list of options numbers that are assigned to options that are still in the IETF draft process, or in some cases, appear merely to have been "requested" (I don't even see an IETF draft for some of these), see http://www.iana.org/assignments/bootp-dhcp-extensions/. Are these numbers actually assigned to options that have not become RFCs? Or are they in some sort of "in-between" state where they are being set aside for an option for the day when it does become an RFC? Or is it merely a list of requests for numbers, but does not reflect actual assignment in any way? Any comments/insight? Patrick ------_=_NextPart_001_01C2D1E9.AFEF0EA0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Assigning Option Codes

The IANA appears to have a list of options numbers = that are assigned to options that are still in the IETF draft process, = or in some cases, appear merely to have been "requested" (I = don't even see an IETF draft for some of these), see http://www.iana.org/assignments/bootp-dhcp-extensions/= .

Are these numbers actually assigned to options that = have not become RFCs? Or are they in some sort of = "in-between" state where they are being set aside for an = option for the day when it does become an RFC? Or is it merely a list = of requests for numbers, but does not reflect actual assignment in any = way?

Any comments/insight?

Patrick

------_=_NextPart_001_01C2D1E9.AFEF0EA0-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Feb 11 11:25:14 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10107; Tue, 11 Feb 2003 11:25:14 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1BGY1p25857; Tue, 11 Feb 2003 11:34:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1BGWhp25788 for ; Tue, 11 Feb 2003 11:32:43 -0500 Received: from rtp-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10045 for ; Tue, 11 Feb 2003 11:23:14 -0500 (EST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h1BGQuJR015595 for ; Tue, 11 Feb 2003 11:26:56 -0500 (EST) Received: from rdroms-w2k.cisco.com (ch2-dhcp150-75.cisco.com [161.44.150.75]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id LAA28910 for ; Tue, 11 Feb 2003 11:26:55 -0500 (EST) Message-Id: <4.3.2.7.2.20030211112437.03dcfde8@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 11 Feb 2003 11:26:52 -0500 To: dhcwg@ietf.org From: Ralph Droms Subject: Re: [dhcwg] Assigning Option Codes In-Reply-To: <4FB49E60CFBA724E88867317DAA3D198E1DEC4@homer.incognito.com .> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Patrick, Those option codes that do not have an associated RFC (or RFC-to-be) were assigned before RFC2939 changed the way in which option codes are assigned. The dhc WG is working to recover those never-used option codes so they can be returned to the pool of available codes. - Ralph At 08:21 AM 2/11/2003 -0800, Cosmo, Patrick wrote: >The IANA appears to have a list of options numbers that are assigned to >options that are still in the IETF draft process, or in some cases, appear >merely to have been "requested" (I don't even see an IETF draft for some >of these), see >http://www.iana.org/assignments/bootp-dhcp-extensions/. > > >Are these numbers actually assigned to options that have not become RFCs? >Or are they in some sort of "in-between" state where they are being set >aside for an option for the day when it does become an RFC? Or is it >merely a list of requests for numbers, but does not reflect actual >assignment in any way? > >Any comments/insight? > >Patrick _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Feb 11 12:53:15 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13088; Tue, 11 Feb 2003 12:53:15 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1BI1Wp32068; Tue, 11 Feb 2003 13:01:32 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1BI0dp31997 for ; Tue, 11 Feb 2003 13:00:39 -0500 Received: from e34.co.us.ibm.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13032 for ; Tue, 11 Feb 2003 12:51:08 -0500 (EST) Received: from westrelay01.boulder.ibm.com (westrelay01.boulder.ibm.com [9.17.194.22]) by e34.co.us.ibm.com (8.12.7/8.12.2) with ESMTP id h1BHrsBf062836; Tue, 11 Feb 2003 12:53:55 -0500 Received: from cichlid.adsl.duke.edu (sig-9-65-198-184.mts.ibm.com [9.65.198.184]) by westrelay01.boulder.ibm.com (8.12.3/NCO/VER6.5) with ESMTP id h1BHrU9Z152302; Tue, 11 Feb 2003 10:53:31 -0700 Received: from cichlid.adsl.duke.edu (narten@localhost) by cichlid.adsl.duke.edu (8.11.6/8.9.3) with ESMTP id h1BHpMQ02918; Tue, 11 Feb 2003 12:51:22 -0500 Message-Id: <200302111751.h1BHpMQ02918@cichlid.adsl.duke.edu> To: Kim Kinnear cc: dhcwg@ietf.org, rdroms@cisco.com, "Woundy, Richard" Subject: Re: [dhcwg] lease query question In-Reply-To: Message from kkinnear@cisco.com of "Mon, 10 Feb 2003 18:31:56 EST." <4.3.2.7.2.20030210170642.025d8f08@goblet.cisco.com> Date: Tue, 11 Feb 2003 12:51:22 -0500 From: Thomas Narten Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Hi Kim. > Having said that (which is true), I don't see significant > deviation from at least my conceptualization of the > current problem the leasequery protocol/draft solves. I guess I do. I could imagine solving the simple problem by having just a pair of messages (request and reply), with the reply saying "yes there is a lease" or "no there is not" and not having the R bit at all. Thus, I'd like to understand whether and why the more complex solution is really necessary. Ideally, this would follow from the problem statement. > There are implementations of this capability in the field > today, and the actual draft is informed by not only our > intellectual exercises in protocol design but by actual > implementations and actual users of those implementations > with real requirements. If you think there is dramatic > mis-match between the problem statement with the actual > protocol, we can certainly revise the problem statement > to whatever degree you deem necessary. Well, one can always revise a problem statement to make sure that a proposed solution follows from it. But that isn't generally the way to get good protocols. What I would rather understand is the actual problem, independent of the solution. If it happens that the solution is a reasonable one given the problem statement, that would be great. But if there are simpler solutions, they should be considered too. So far, you've provided a very high-level, general problem description. From it, I don't see the need for some of the proposed protocol features. I really do want to understand if the proposed solution is the best one for the actual problem. > So, for instance, if a "real" DHCP client was talking to > the DHCP server, it would give the client a lease (as > opposed to telling the client that it had a lease at some > point in the past). However, the client for a leasequery > request isn't looking for a lease -- it is looking for > information *about* a lease. Allowing a server to return > information that indicates that a lease existed for a > client at sometime in the past may well be useful to a > device which is trying to rebuild its state, since this > is information that it normally would have available if > it had not lost its state. The above is not obvious to me. Why should the relay agent care if an address used to be in use on a particular link in the past? I would think that the relay agent shouldn't be creating ARP state based on that because: - in fact that address might be in use by a different node elsewhere on a different link now (and the server responding might not know that because its not coordinating properly with the other server). - if the lease is no longer valid, presumably the device using that address shouldn't be using that address anymore (after all, it didn't renew the lease). So why should the relay agent forward packets for that address to the site where a device used to be in the past? > The R bit is designed to allow a device which uses DHCP > gleaning to also operate correctly in the event that some > IP addresses are "hard coded" or "hand configured". In > this case, if the DHCP server is supplied with a > reservation for the hand configured IP<->MAC > relationship, then if the DHCP client asks for an IP > address, it will get the proper one. Makes complete sense for normal DHC usage. > More importantly, > the leasequery client doesn't have to be configured with > the hand-configured IP address, since it can determine > which IP addresses are "allowable" from the results of a > leasequery. This is indeed a capability that the > leasequery protocol allows that isn't possible in a > straightforward way without it. The above I don't follow, for the reason I mentioned above. Seems to me, the relay agent shouldn't be populating it's ARP cache *unless* there is a valid lease. Thus, knowing that an address is reserved, but not currently in use, doesn't seem to be info the relay agent really needs. Am I missing some other important detail here? Thomas _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Feb 11 16:37:40 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19139; Tue, 11 Feb 2003 16:37:40 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1BLhGp14307; Tue, 11 Feb 2003 16:43:18 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1BLfxp14280 for ; Tue, 11 Feb 2003 16:41:59 -0500 Received: from chimera.incognito.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19065 for ; Tue, 11 Feb 2003 16:32:22 -0500 (EST) Received: from homerdmz.incognito.com ([207.102.214.106] helo=homer.incognito.com.) by chimera.incognito.com with smtp (Exim 3.35 #1 (Debian)) id 18ii44-0002zk-00; Tue, 11 Feb 2003 13:35:40 -0800 Received: by homer.incognito.com. with Internet Mail Service (5.5.2653.19) id <13JRG942>; Tue, 11 Feb 2003 13:41:38 -0800 Message-ID: <4FB49E60CFBA724E88867317DAA3D198E1DED2@homer.incognito.com.> From: "Cosmo, Patrick" To: "'Thomas Narten'" , Kim Kinnear Cc: dhcwg@ietf.org, rdroms@cisco.com, "Woundy, Richard" Subject: RE: [dhcwg] lease query question Date: Tue, 11 Feb 2003 13:41:38 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2D216.5B620860" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2D216.5B620860 Content-Type: text/plain; charset="iso-8859-1" >Thus, knowing that an address is reserved, but >not currently in use, doesn't seem to be info the >relay agent really needs. Am I missing some other >important detail here? Here's one example: some relay agents provide an "Host Authentication" feature where they only fwd data from an device using an IP address that the device "really does own". This is an attempt to prevent IP spoofing. The relay agent determines who "owns" an IP address (who was actually leased the address) by gleaning the DHCP messages that pass through it, or through DHCP lease query. In the case where a device is manually configured with an IP and is not performing DHCP, the DHCP service may be configured with a "static address" for the device to indicate that the device really does "own" that IP address. The relay agent can determine and recognize this fact through the use of DHCP lease query. There may be other current examples, or future uses not yet considered. It's all about flexibility I think. -----Original Message----- From: Thomas Narten [mailto:narten@us.ibm.com] Sent: Tuesday, February 11, 2003 12:51 PM To: Kim Kinnear Cc: dhcwg@ietf.org; rdroms@cisco.com; Woundy, Richard Subject: Re: [dhcwg] lease query question Hi Kim. > Having said that (which is true), I don't see significant > deviation from at least my conceptualization of the > current problem the leasequery protocol/draft solves. I guess I do. I could imagine solving the simple problem by having just a pair of messages (request and reply), with the reply saying "yes there is a lease" or "no there is not" and not having the R bit at all. Thus, I'd like to understand whether and why the more complex solution is really necessary. Ideally, this would follow from the problem statement. > There are implementations of this capability in the field > today, and the actual draft is informed by not only our > intellectual exercises in protocol design but by actual > implementations and actual users of those implementations > with real requirements. If you think there is dramatic > mis-match between the problem statement with the actual > protocol, we can certainly revise the problem statement > to whatever degree you deem necessary. Well, one can always revise a problem statement to make sure that a proposed solution follows from it. But that isn't generally the way to get good protocols. What I would rather understand is the actual problem, independent of the solution. If it happens that the solution is a reasonable one given the problem statement, that would be great. But if there are simpler solutions, they should be considered too. So far, you've provided a very high-level, general problem description. From it, I don't see the need for some of the proposed protocol features. I really do want to understand if the proposed solution is the best one for the actual problem. > So, for instance, if a "real" DHCP client was talking to > the DHCP server, it would give the client a lease (as > opposed to telling the client that it had a lease at some > point in the past). However, the client for a leasequery > request isn't looking for a lease -- it is looking for > information *about* a lease. Allowing a server to return > information that indicates that a lease existed for a > client at sometime in the past may well be useful to a > device which is trying to rebuild its state, since this > is information that it normally would have available if > it had not lost its state. The above is not obvious to me. Why should the relay agent care if an address used to be in use on a particular link in the past? I would think that the relay agent shouldn't be creating ARP state based on that because: - in fact that address might be in use by a different node elsewhere on a different link now (and the server responding might not know that because its not coordinating properly with the other server). - if the lease is no longer valid, presumably the device using that address shouldn't be using that address anymore (after all, it didn't renew the lease). So why should the relay agent forward packets for that address to the site where a device used to be in the past? > The R bit is designed to allow a device which uses DHCP > gleaning to also operate correctly in the event that some > IP addresses are "hard coded" or "hand configured". In > this case, if the DHCP server is supplied with a > reservation for the hand configured IP<->MAC > relationship, then if the DHCP client asks for an IP > address, it will get the proper one. Makes complete sense for normal DHC usage. > More importantly, > the leasequery client doesn't have to be configured with > the hand-configured IP address, since it can determine > which IP addresses are "allowable" from the results of a > leasequery. This is indeed a capability that the > leasequery protocol allows that isn't possible in a > straightforward way without it. The above I don't follow, for the reason I mentioned above. Seems to me, the relay agent shouldn't be populating it's ARP cache *unless* there is a valid lease. Thus, knowing that an address is reserved, but not currently in use, doesn't seem to be info the relay agent really needs. Am I missing some other important detail here? Thomas _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg ------_=_NextPart_001_01C2D216.5B620860 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] lease query question

>Thus, knowing that an address is reserved, = but
>not currently in use, doesn't seem to be info = the
>relay agent really needs. Am I missing some = other
>important detail here?

Here's one example:

some relay agents provide an "Host = Authentication" feature where they only fwd data from an device = using an IP address that the device "really does own". This = is an attempt to prevent IP spoofing. The relay agent determines who = "owns" an IP address (who was actually leased the address) by = gleaning the DHCP messages that pass through it, or through DHCP lease = query. In the case where a device is manually configured with an IP and = is not performing DHCP, the DHCP service may be configured with a = "static address" for the device to indicate that the device = really does "own" that IP address. The relay agent can = determine and recognize this fact through the use of DHCP lease = query.

There may be other current examples, or future uses = not yet considered. It's all about flexibility I think.


-----Original Message-----
From: Thomas Narten [mailto:narten@us.ibm.com]
Sent: Tuesday, February 11, 2003 12:51 PM
To: Kim Kinnear
Cc: dhcwg@ietf.org; rdroms@cisco.com; Woundy, = Richard
Subject: Re: [dhcwg] lease query question


Hi Kim.

>         = Having said that (which is true), I don't see significant
>         = deviation from at least my conceptualization of the
>         = current problem the leasequery protocol/draft solves.

I guess I do. I could imagine solving the simple = problem by having
just a pair of messages (request and reply), with = the reply saying
"yes there is a lease" or "no there = is not" and not having the R bit
at all. Thus, I'd like to understand whether and why = the more complex
solution is really necessary. Ideally, this would = follow from the
problem statement.

>         = There are implementations of this capability in the field
>         = today, and the actual draft is informed by not only our
>         = intellectual exercises in protocol design but by actual
>         = implementations and actual users of those implementations
>         = with real requirements.  If you think there is dramatic
>         = mis-match between the problem statement with the actual
>         = protocol, we can certainly revise the problem statement
>         = to whatever degree you deem necessary.

Well, one can always revise a problem statement to = make sure that a
proposed solution follows from it. But that isn't = generally the way to
get good protocols. What I would rather understand = is the actual
problem, independent of the solution. If it happens = that the solution
is a reasonable one given the problem statement, = that would be
great. But if there are simpler solutions, they = should be considered
too.

So far, you've provided a very high-level, general = problem
description. From it, I don't see the need for some = of the proposed
protocol features.  I really do want to = understand if the proposed
solution is the best one for the actual = problem.

>         = So, for instance, if a "real" DHCP client was talking = to
>         = the DHCP server, it would give the client a lease (as
>         = opposed to telling the client that it had a lease at some
>         = point in the past).  However, the client for a leasequery
>         = request isn't looking for a lease -- it is looking for
>         = information *about* a lease.  Allowing a server to return
>         = information that indicates that a lease existed for a
>         = client at sometime in the past may well be useful to a
>         = device which is trying to rebuild its state, since this
>         = is information that it normally would have available if
>         = it had not lost its state.

The above is not obvious to me. Why should the relay = agent care if an
address used to be in use on a particular link in = the past? I would
think that the relay agent shouldn't be creating ARP = state based on
that because:

 - in fact that address might be in use by a = different node elsewhere
   on a different link now (and the server = responding might not know
   that because its not coordinating = properly with the other server).

 - if the lease is no longer valid, presumably = the device using that
   address shouldn't be using that address = anymore (after all, it
   didn't renew the lease). So why should = the relay agent forward
   packets for that address to the site = where a device used to be in
   the past?

>         = The R bit is designed to allow a device which uses DHCP
>         = gleaning to also operate correctly in the event that some
>         = IP addresses are "hard coded" or "hand = configured".  In
>         = this case, if the DHCP server is supplied with a
>         = reservation for the hand configured IP<->MAC
>         = relationship, then if the DHCP client asks for an IP
>         = address, it will get the proper one.

Makes complete sense for normal DHC usage.

>         More = importantly,
>         = the leasequery client doesn't have to be configured with
>         = the hand-configured IP address, since it can determine
>         = which IP addresses are "allowable" from the results of = a
>         = leasequery.  This is indeed a capability that the
>         = leasequery protocol allows that isn't possible in a
>         = straightforward way without it.

The above I don't follow, for the reason I mentioned = above. Seems to
me, the relay agent shouldn't be populating it's ARP = cache *unless*
there is a valid lease. Thus, knowing that an = address is reserved, but
not currently in use, doesn't seem to be info the = relay agent really
needs. Am I missing some other important detail = here?

Thomas
_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg

------_=_NextPart_001_01C2D216.5B620860-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Feb 11 22:01:39 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26329; Tue, 11 Feb 2003 22:01:38 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1C3AYp01163; Tue, 11 Feb 2003 22:10:34 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1C39wp01128 for ; Tue, 11 Feb 2003 22:09:58 -0500 Received: from e33.co.us.ibm.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26311 for ; Tue, 11 Feb 2003 22:00:17 -0500 (EST) Received: from westrelay01.boulder.ibm.com (westrelay01.boulder.ibm.com [9.17.194.22]) by e33.co.us.ibm.com (8.12.7/8.12.2) with ESMTP id h1C33qGj068614; Tue, 11 Feb 2003 22:03:52 -0500 Received: from cichlid.adsl.duke.edu (sig-9-65-205-168.mts.ibm.com [9.65.205.168]) by westrelay01.boulder.ibm.com (8.12.3/NCO/VER6.5) with ESMTP id h1C32Z9Z155008; Tue, 11 Feb 2003 20:02:35 -0700 Received: from cichlid.adsl.duke.edu (narten@localhost) by cichlid.adsl.duke.edu (8.11.6/8.9.3) with ESMTP id h1C30ML02918; Tue, 11 Feb 2003 22:00:22 -0500 Message-Id: <200302120300.h1C30ML02918@cichlid.adsl.duke.edu> To: "Cosmo, Patrick" cc: Kim Kinnear , dhcwg@ietf.org, rdroms@cisco.com, "Woundy, Richard" Subject: Re: [dhcwg] lease query question In-Reply-To: Message from Patrick@incognito.com of "Tue, 11 Feb 2003 13:41:38 PST." <4FB49E60CFBA724E88867317DAA3D198E1DED2@homer.incognito.com.> Date: Tue, 11 Feb 2003 22:00:22 -0500 From: Thomas Narten Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , "Cosmo, Patrick" writes: > >Thus, knowing that an address is reserved, but > >not currently in use, doesn't seem to be info the > >relay agent really needs. Am I missing some other > >important detail here? > Here's one example: > some relay agents provide an "Host Authentication" feature where they only > fwd data from an device using an IP address that the device "really does > own". This is an attempt to prevent IP spoofing. The relay agent determines > who "owns" an IP address (who was actually leased the address) by gleaning > the DHCP messages that pass through it, or through DHCP lease query. I understand and agree with everything so far. > In the case where a device is manually configured with an IP and is > not performing DHCP, the DHCP service may be configured with a > "static address" for the device to indicate that the device really > does "own" that IP address. The relay agent can determine and > recognize this fact through the use of DHCP lease query. So, the client isn't using DHC, but we're going to configure the DHC server about that client anyway and the relay agent is going to use leasequery to get info from the DHC server about those addresses, even though DHC (as in the RFC 2131) isn't even being used for these addresses? Is this indeed part of the problem statement? I'll note also that the above problem can't be solved by DHC gleaning, since the client isn't using DHC. So, the above isn't just about restoring gleaned information after losing state. But having said that, couldn't the DHC server just respond with "I have a lease" for the hardcoded configuration information, even if it (in some sense) doesn't? What the relay agent presumably cares about is whether an address is in use on a certain link. It doesn't really care _how_ the DHC server knows about those addresses. Right? Thomas _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Feb 12 10:46:30 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06804; Wed, 12 Feb 2003 10:46:30 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1CFtmp25574; Wed, 12 Feb 2003 10:55:48 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1CFsep25514 for ; Wed, 12 Feb 2003 10:54:40 -0500 Received: from rtp-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06776 for ; Wed, 12 Feb 2003 10:44:43 -0500 (EST) Received: from goblet.cisco.com (IDENT:mirapoint@goblet.cisco.com [161.44.168.80]) by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h1CFmNNh028269; Wed, 12 Feb 2003 10:48:23 -0500 (EST) Received: from KKINNEAR-W2K.cisco.com (ch2-dhcp150-41.cisco.com [161.44.150.41]) by goblet.cisco.com (Mirapoint) with ESMTP id ACP42116; Wed, 12 Feb 2003 10:48:22 -0500 (EST) Message-Id: <4.3.2.7.2.20030212102523.0238be88@goblet.cisco.com> X-Sender: kkinnear@goblet.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 12 Feb 2003 10:48:21 -0500 To: Thomas Narten , "Cosmo, Patrick" From: Kim Kinnear Subject: Re: [dhcwg] lease query question Cc: Kim Kinnear , dhcwg@ietf.org, rdroms@cisco.com, "Woundy, Richard" In-Reply-To: <200302120300.h1C30ML02918@cichlid.adsl.duke.edu> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Thomas, Patrick did an excellent job of explaining the motivation behind this particular part of the problem statement in the leasequery draft (from the second point on page 2): 2. The access concentrator can perform IP source address verifica- tion of datagrams received from the access network. The verif- ication may be based on the datagram source hardware address, the incoming access network port, the incoming virtual circuit, and/or the transmitting modem. I have some additional comments, indented, below. At 10:00 PM 2/11/2003, Thomas Narten wrote: >"Cosmo, Patrick" writes: > >> >Thus, knowing that an address is reserved, but >> >not currently in use, doesn't seem to be info the >> >relay agent really needs. Am I missing some other >> >important detail here? > >> Here's one example: > >> some relay agents provide an "Host Authentication" feature where they only >> fwd data from an device using an IP address that the device "really does >> own". This is an attempt to prevent IP spoofing. The relay agent determines >> who "owns" an IP address (who was actually leased the address) by gleaning >> the DHCP messages that pass through it, or through DHCP lease query. > >I understand and agree with everything so far. > >> In the case where a device is manually configured with an IP and is >> not performing DHCP, the DHCP service may be configured with a >> "static address" for the device to indicate that the device really >> does "own" that IP address. The relay agent can determine and >> recognize this fact through the use of DHCP lease query. > >So, the client isn't using DHC, but we're going to configure the DHC >server about that client anyway and the relay agent is going to use >leasequery to get info from the DHC server about those addresses, >even though DHC (as in the RFC 2131) isn't even being used for these >addresses? Yes, since the utility of this "host authentication" feature or "source address verification" feature (call it what you will) has been found to be less broadly applicable in practice than it was in theory. It is certainly useful, but it would be more useful if it worked on networks which were not configured solely using DHCP enabled clients. Thus, practical experience has shown that the solution we originally architected and deployed would be even more useful if we added some small things to the leasequery capability. That was the source of my comment about this becoming a second generation capability -- it has truly evolved over time. >Is this indeed part of the problem statement? Yes, it is now. >I'll note also that the above problem can't be solved by DHC gleaning, >since the client isn't using DHC. So, the above isn't just about >restoring gleaned information after losing state. You are correct. >But having said that, couldn't the DHC server just respond with "I >have a lease" for the hardcoded configuration information, even if it >(in some sense) doesn't? Yes, and this is what it does. > What the relay agent presumably cares about >is whether an address is in use on a certain link. It doesn't really >care _how_ the DHC server knows about those addresses. Right? It may well be that an access concentrator will use the reservation to decide that it will allow this IP address to work from any port, but then remember that port and not allow it from any other port. This is because there may not be option-82 information configured for that reservation. In this case, the fact that it is a reservation may well be key to the access concentrator's ability to allow the IP address to be used. On the other hand, we don't know for sure that someone won't create an access concentrator that might want to prohibit leasequery information for any *but* real DHCP clients, we decided to put this bit of information into the leasequery capability. Indeed, there may well be other decisions an access concentrator might with to make based on this information that I haven't even imagined at this time. I believe that our job is to create capabilities that serve a well defined need in a clear and easily implemented (to be interoperable) manner. I *also* happen to believe that if we do our jobs right, people will use these capabilities in ways that we have not yet imagined to do things that are innovative and useful for end-users. Thus, I believe that in a capability such as leasequery where the primary goal is to return information to an access concentrator, we would be missing the point if we failed to deliver something as simple and possibly basic as the source of the rest of the information. It isn't as though we had to invent a new message exchange or anything -- that would have been overkill. However, since we have the information it seems foolish to withhold it on some philosophical grounds given we are talking about one bit, and we can certainly imagine ways in which it might well be useful. Kim >Thomas _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Feb 12 15:12:36 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14439; Wed, 12 Feb 2003 15:12:36 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1CKLup18127; Wed, 12 Feb 2003 15:21:56 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1CKK8p18041 for ; Wed, 12 Feb 2003 15:20:08 -0500 Received: from sj-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14403 for ; Wed, 12 Feb 2003 15:10:04 -0500 (EST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by sj-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h1CKDmSR003839 for ; Wed, 12 Feb 2003 12:13:49 -0800 (PST) Date: Wed, 12 Feb 2003 15:13:48 -0500 (EST) From: Ralph Droms To: dhcwg@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [dhcwg] WG last call on draft-ietf-dhc-dhcpv6-loadb-02.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This message announces a WG last call on "Load Balancing for DHCPv6" . The last call will conclude on Friday, 2/28. draft-ietf-dhc-dhcpv6-loadb-02.txt specifies a load balancing algorithm for use with DHCPv6, which enables multiple cooperating DHCPv6 servers to decide which one should service a client without exchanging any information beyond initial configuration. This draft is available as http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-loadb-02.txt - Ralph Droms _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Feb 12 15:22:55 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14692; Wed, 12 Feb 2003 15:22:55 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1CKWDp18429; Wed, 12 Feb 2003 15:32:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1CKVNp18386 for ; Wed, 12 Feb 2003 15:31:23 -0500 Received: from sj-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14624 for ; Wed, 12 Feb 2003 15:21:19 -0500 (EST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by sj-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h1CKP2SR011205 for ; Wed, 12 Feb 2003 12:25:03 -0800 (PST) Date: Wed, 12 Feb 2003 15:25:02 -0500 (EST) From: Ralph Droms To: dhcwg@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [dhcwg] WG last call on draft-ietf-dhc-dhcpv6-opt-nisconfig-01.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This message announces a WG last call on "NIS Configuration Options for DHCPv6" . The last call will conclude on Friday, 2/28. draft-ietf-dhc-dhcpv6-opt-nisconfig-01.txt specifies four DHCPv6 options for configuration information related to Network Information Service (NIS). This draft is available as http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-opt-nisconfig-01.txt - Ralph Droms _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Feb 12 15:34:52 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14972; Wed, 12 Feb 2003 15:34:52 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1CKiMp19580; Wed, 12 Feb 2003 15:44:22 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1CKhdp19538 for ; Wed, 12 Feb 2003 15:43:39 -0500 Received: from sj-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14941 for ; Wed, 12 Feb 2003 15:33:35 -0500 (EST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by sj-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h1CKbJSR019812 for ; Wed, 12 Feb 2003 12:37:19 -0800 (PST) Date: Wed, 12 Feb 2003 15:37:19 -0500 (EST) From: Ralph Droms To: dhcwg@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [dhcwg] WG last call on draft-ietf-dhc-dhcpv6-opt-timeconfig-01.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This message announces a WG last call on "Time Configuration Options for DHCPv6" . The last call will conclude on Friday, 2/28. draft-ietf-dhc-dhcpv6-opt-timeconfig-01.txt specifies describes the DHCPv6 options for time related configuration information: NTP Servers and IEEE 1003.1 POSIX Timezone specifier. This draft is available as http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-opt-timeconfig-01.txt - Ralph Droms _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Feb 12 15:57:28 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15500; Wed, 12 Feb 2003 15:57:28 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1CL6Wp20439; Wed, 12 Feb 2003 16:06:32 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1CL5fp20414 for ; Wed, 12 Feb 2003 16:05:41 -0500 Received: from rtp-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15468 for ; Wed, 12 Feb 2003 15:55:36 -0500 (EST) Received: from goblet.cisco.com (IDENT:mirapoint@goblet.cisco.com [161.44.168.80]) by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h1CKxHNh017621; Wed, 12 Feb 2003 15:59:17 -0500 (EST) Received: from KKINNEAR-W2K.cisco.com (ch2-dhcp150-41.cisco.com [161.44.150.41]) by goblet.cisco.com (Mirapoint) with ESMTP id ACP50136; Wed, 12 Feb 2003 15:59:16 -0500 (EST) Message-Id: <4.3.2.7.2.20030212154448.023430c0@goblet.cisco.com> X-Sender: kkinnear@goblet.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 12 Feb 2003 15:59:15 -0500 To: dhcwg@ietf.org From: Kim Kinnear Cc: kkinnear@cisco.com, rdroms@cisco.com, mjs@cisco.com, scanner@nominum.com, Bernie.Volz@am1.ericsson.se Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [dhcwg] Failover Atlanta IETF discussion notes Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , During the last IETF in Atlanta, a discussion was held with several folks about problems in the DHCP failover protocol and its description. In attendance were: Scanner Luce scanner@nominum.com Bernie Volz Bernie.Volz@am1.ericsson.se Mark Stapp mjs@cisco.com Kim Kinnear kkinnear@cisco.com We primarily discussed issues encountered by Scanner during his implementation of the failover protocol, and first raised at a meeting with several people during the Summer 2002 IETF. Thanks to Bernie Volz for comments and additions to an earlier version of these notes. Some of his additions I've simply placed into the text, but I've left one comment explicit since we may want to discuss it further. The action plan for failover at this point is: a. Circulate these notes to the DHCP list. b. Accept comments. c. Update the failover draft by the end of February. d. Consider whether we need another WG last call based on these changes. Here is step a.... Notes from offline discussion at Atlanta IETF: ---------------------------------------------- While the discussion ranged over several topics, the action items boiled down to the following: 1. Connection establishment changes: a. There MUST be one endpoint failover relationship (i.e., between two servers). b. There SHOULD be one relationship per partner, but this is not a requirement. We determined there was little value in having the same two servers be involved in two relationships (in general). So, having one server be primary for some pools and secondary for others where the partner has opposite roles is really not necessary and makes little sense. Especially now that load balancing exists and the primary and secondary are almost equal (the primary just breaks ties). c. There SHOULD be only one port in use for failover traffic. d. The TCP connection from the secondary server to the primary server is dropped by the secondary server or is dropped by the primary server in the event that both servers end up connecting at the same time. We need a strategy to handle the case where two connections are done at the same time (primary -> secondary; secondary -> primary). The role is simply that the connection that the primary initiated is the one that is kept. So, the primary drops the connection it ACCEPTed from the secondary and the secondary drops the connection on which it CONNECTed to the primary. 2. Remove paragraph 4 from Section 7.1.3 (from the BNDUPD conflict section). This paragraph turns out to add as opposed to remove confusion. 3. Consider adding pseudo-code for the MCLT logic (which Scanner has offered to contribute, since he felt this would be helpful.) I'll include anything I get in this regard. 4. Review sequence diagrams for accuracy. 5. The failover partners can run in two different modes -- time sync mode, or time skew mode. In time sync mode, still send the time, and the receiving server can be itself be in one of two modes -- time correction mode (to handle time drift) or time rejection mode (which will reject packets with a time that is "too wrong") in them. Bernie added: One point is that whichever mode one is in, one must allow some small drift in time when doing time based comparisons. For example, lease expirations may easily be off by 1 second just because of the time that elapsed between when a packet was sent and received (a very small fraction of time must elapse for this to potentially happen). I think that was more the issue that we need to make clear - time checks need to be somewhat soft rather than absolute? But I agree that servers may chose to require the time to be "in sync" or can chose to do time corrections. Note that we have found problems in not accommodating time skew; if the servers require the time to be in sync and continue running (but refuse to communicate) bad things sometimes happen (especially if the servers assume partner-down state). This can happen because step 6 in section 9.3.2 allows two actions. We may want to consider exactly what it means for the partner to be "down"; for example if the partner is up but a connection can not be established because the time-skew it out of range, then it may be better to have one server wait (typically the one that was down the longest?). 6. The client-last-transaction-time should not be remembered if the packet is dropped due to the server being in the wrong failover state to respond to DHCP client packets. This was implicit in the previous versions of the draft, but not clearly stated. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Feb 13 18:56:11 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21267; Thu, 13 Feb 2003 18:56:11 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1DNxOp30945; Thu, 13 Feb 2003 18:59:24 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1DNvSp30894 for ; Thu, 13 Feb 2003 18:57:28 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21141; Thu, 13 Feb 2003 18:53:35 -0500 (EST) Message-Id: <200302132353.SAA21141@ietf.org> To: IETF-Announce: ; Cc: RFC Editor , Internet Architecture Board , dhcwg@ietf.org From: The IESG Date: Thu, 13 Feb 2003 18:53:35 -0500 Subject: [dhcwg] Protocol Action: Subnet Selection sub-option for the Relay Agent Information Option to Proposed Standard Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , The IESG has approved the Internet-Draft 'Subnet Selection sub-option for the Relay Agent Information Option' as a Proposed Standard. This document is the product of the Dynamic Host Configuration Working Group. The IESG contact persons are Erik Nordmark and Thomas Narten. Technical Summary In "Dynamic Host Configuration Protocol" (RFC2131), the giaddr field specifies a single address that indicates both the subnet on which a DHCP client resides as well as the IP address through which the DHCP response is to be relayed back to the client. The Subnet Selection Option (RFC 3011) allows a client (when acting as a DHCP proxy) to override the default function of the giaddr so that a different address can be provided to indicate the subnet from which to allocate an IP address on (the giaddr field still indicates the IP (relay) address through which the DHCP server responds to the client). Analgous situations exist where the relay agent needs to specify a subnet on which a DHCP client resides that is different from the address in the giaddr field. The DHCP Relay Agent Subnet-Selection sub-option specified in this document provides a mechanism to do this. Working Group Summary There was support for this document in the WG, and no issues were raised during Last Call. Protocol Quality This document has been reviewed for the IESG by Thomas Narten. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Feb 14 06:46:11 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17152; Fri, 14 Feb 2003 06:46:11 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1EBnap18674; Fri, 14 Feb 2003 06:49:36 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1EBl5p18552 for ; Fri, 14 Feb 2003 06:47:05 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16648; Fri, 14 Feb 2003 06:42:58 -0500 (EST) Message-Id: <200302141142.GAA16648@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: dhcwg@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Fri, 14 Feb 2003 06:42:58 -0500 Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-server-override-00.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Title : DHCP Server-ID Override Suboption Author(s) : R. Johnson et al. Filename : draft-ietf-dhc-server-override-00.txt Pages : 4 Date : 2003-2-13 This memo defines a new suboption of the DHCP relay information option [6] which allows the DHCP relay to specify a new value for the Server-ID option, which is inserted by the DHCP Server. In some cases it is convenient for the DHCP relay to act as the actual DHCP server such that DHCP RENEWAL requests will come to the relay instead of going to the server directly. This gives the relay the opportunity to include the Relay Agent option with appropriate suboptions even on RENEWAL messages. This new relay agent suboption allows the relay to tell the DHCP server what value to use in the Server-ID option [3]. If this suboption is not present, the server should build the Server-ID option in the normal fashion. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-server-override-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-server-override-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-server-override-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: <2003-2-13152609.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-server-override-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-server-override-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-2-13152609.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Feb 14 12:02:31 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27280; Fri, 14 Feb 2003 12:02:31 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1EH67p07362; Fri, 14 Feb 2003 12:06:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1EH1vp06950 for ; Fri, 14 Feb 2003 12:01:57 -0500 Received: from chimera.incognito.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27061 for ; Fri, 14 Feb 2003 11:57:26 -0500 (EST) Received: from homerdmz.incognito.com ([207.102.214.106] helo=homer.incognito.com.) by chimera.incognito.com with smtp (Exim 3.35 #1 (Debian)) id 18jjD2-0001vQ-00 for ; Fri, 14 Feb 2003 09:01:08 -0800 Received: by homer.incognito.com. with Internet Mail Service (5.5.2653.19) id <13JRHCW6>; Fri, 14 Feb 2003 09:07:12 -0800 Message-ID: <4FB49E60CFBA724E88867317DAA3D198A67A2E@homer.incognito.com.> From: "Kostur, Andre" To: dhcwg@ietf.org Subject: RE: [dhcwg] I-D ACTION:draft-ietf-dhc-server-override-00.txt Date: Fri, 14 Feb 2003 09:07:10 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2D44B.82DF8E80" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2D44B.82DF8E80 Content-Type: text/plain; charset="iso-8859-1" A few observations: 1) This introduces a new point of failure in a DHCP infrastructure. If this particular relay goes down, then devices which currently hold a lease cannot renew, where under standard DHCP, they would be able to. 2) It also seems kinda odd that the DHCP Server should only sometimes pay attention to this sub-option: DHCP Servers SHOULD use this value as the value to insert into the Server-ID option ONLY when the protocol is in the SELECTING and REQUESTING and REBINDING states. If this suboption appears in a DHCP request which is part of a lease RENEWAL, it SHOULD be ignored. What's the justification of the server ignoring the value for RENEWALs? This would mean that a client Renewing their lease (T1 expiries) will get a response from a DHCP sever that it didn't unicast a Request to. Details: SvrIP = DHCP Server IP RelayIP = Relay IP - Client broadcasts a Discover - Relay receives Discover, does the normal relay duties, and adds Opt82 with the RelayIP as the override - Server processes Discover and sends back an Offer with a SeverID of RelayIP (according to this draft). - Relay receives Offer, does the normal relay duties, and broadcasts back to the client. - Client receives the Offer, and records RelayIP as the server which is servicing this client. - Client broadcasts a Request, with ServerID of RelayIP - Relay receives the Request, does the normal relay duties, and adds Opt82 with the RelayIP as the override - Server receives the Request. Since the ServerID is not the DHCP Server's IP, the Request is ignored! Actually there's another problem... the DHCP Server will ignore the Request! But let's continue, assuming that this is accepted somehow by the server: - Server sends back an Ack with a ServerID of RelayIP - Time passes until T1 - Client unicasts a Request to RelayIP - Relay receives Request, does the normal relay duties, and adds Opt82 with the RelayIP as the override - Server receives the Request, and Acks with a ServerID of SvrIP (according to this draft, the RENEWAL should ignore the override) - Relay receives the ACK, does the normal relay duties, unicasts it back to the client - The Client receives an ACK from what appears to be a completely different DHCP Server! 2 things may happen at this point. The first is that the client might decide to discard the answer since it didn't come from the DHCP Server that it sent the request to, or the client may change which DHCP Server it's going to try talking to since it now has an answer from the actual server. Assuming the second case happens, when the client tries to renew the next time, it will try to unicast directly to the DHCP server, and will bypass the relay altogether, defeating the purpose of this draft! On a side (but somewhat related) note, I think I've found a discrepancy between RFC 2131 and RFC 2132 with respect to the Server ID option. In RFC 2131, Section 4.3.1, Page 29, Table 3: This table indicates that a server MUST include the Server ID option in Offers, Acks, and Nacks. In RFC 2132, Section 9.7, Page 27: The description of the Server ID option states that "This option is used in DHCPOFFER and DHCPREQUEST messages, and may optionally be included in the DHCPACK and DHCPNAK messages." RFC 2131 states it MUST be included, and 2132 says "may optionally" be included... ------_=_NextPart_001_01C2D44B.82DF8E80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] I-D = ACTION:draft-ietf-dhc-server-override-00.txt

A few observations:

1) This introduces a new point of failure in a DHCP = infrastructure.  If this particular relay goes down, then devices = which currently hold a lease cannot renew, where under standard DHCP, = they would be able to.

2) It also seems kinda odd that the DHCP Server = should only sometimes pay attention to this sub-option:

   DHCP Servers SHOULD use this value as = the value to insert into the
   Server-ID option ONLY when the protocol = is in the SELECTING and
   REQUESTING and REBINDING states.  = If this suboption appears in a DHCP
   request which is part of a lease = RENEWAL, it SHOULD be ignored.

What's the justification of the server ignoring the = value for RENEWALs?  This would mean that a client Renewing their = lease (T1 expiries) will get a response from a DHCP sever that it = didn't unicast a Request to.  Details:

SvrIP =3D DHCP Server IP
RelayIP =3D Relay IP


- Client broadcasts a Discover
- Relay receives Discover, does the normal relay = duties, and adds Opt82 with the RelayIP as the override
- Server processes Discover and sends back an Offer = with a SeverID of RelayIP (according to this draft).
- Relay receives Offer, does the normal relay = duties, and broadcasts back to the client.
- Client receives the Offer, and records RelayIP as = the server which is servicing this client.
- Client broadcasts a Request, with ServerID of = RelayIP
- Relay receives the Request, does the normal relay = duties, and adds Opt82 with the RelayIP as the override
- Server receives the Request.  Since the = ServerID is not the DHCP Server's IP, the Request is ignored!

Actually there's another problem... the DHCP Server = will ignore the Request!  But let's continue, assuming that this = is accepted somehow by the server:

- Server sends back an Ack with a ServerID of = RelayIP
- Time passes until T1
- Client unicasts a Request to RelayIP
- Relay receives Request, does the normal relay = duties, and adds Opt82 with the RelayIP as the override
- Server receives the Request, and Acks with a = ServerID of SvrIP (according to this draft, the RENEWAL should ignore = the override)

- Relay receives the ACK, does the normal relay = duties, unicasts it back to the client
- The Client receives an ACK from what appears to be = a completely different DHCP Server!

2 things may happen at this point.  The first is = that the client might decide to discard the answer since it didn't come = from the DHCP Server that it sent the request to, or the client may = change which DHCP Server it's going to try talking to since it now has = an answer from the actual server.  Assuming the second case = happens, when the client tries to renew the next time, it will try to = unicast directly to the DHCP server, and will bypass the relay = altogether, defeating the purpose of this draft!



On a side (but somewhat related) note, I think I've = found a discrepancy between RFC 2131 and RFC 2132 with respect to the = Server ID option.

In RFC 2131, Section 4.3.1, Page 29, Table 3:  = This table indicates that a server MUST include the Server ID option in = Offers, Acks, and Nacks.

In RFC 2132, Section 9.7, Page 27: The description of = the Server ID option states that "This option is used in DHCPOFFER = and DHCPREQUEST messages, and may optionally be included in the DHCPACK = and DHCPNAK messages."

RFC 2131 states it MUST be included, and 2132 says = "may optionally" be included...

------_=_NextPart_001_01C2D44B.82DF8E80-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Feb 14 13:06:30 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29228; Fri, 14 Feb 2003 13:06:30 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1EI9wp12666; Fri, 14 Feb 2003 13:09:59 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1EI8Cp12620 for ; Fri, 14 Feb 2003 13:08:12 -0500 Received: from toccata.fugue.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29166 for ; Fri, 14 Feb 2003 13:03:57 -0500 (EST) Received: from nominum.com (24-148-0-210.na.21stcentury.net [24.148.0.210]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id h1EI65P28643; Fri, 14 Feb 2003 12:06:05 -0600 (CST) Date: Fri, 14 Feb 2003 12:07:39 -0600 Subject: Re: [dhcwg] I-D ACTION:draft-ietf-dhc-server-override-00.txt Content-Type: text/plain; charset=ISO-8859-1; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: dhcwg@ietf.org To: "Kostur, Andre" From: Ted Lemon In-Reply-To: <4FB49E60CFBA724E88867317DAA3D198A67A2E@homer.incognito.com.> Message-Id: <347AA628-4047-11D7-AC5A-00039317663C@nominum.com> X-Mailer: Apple Mail (2.551) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h1EI8Cp12621 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit > 1) This introduces a new point of failure in a DHCP infrastructure.  > If this particular relay goes down, then devices which currently hold > a lease cannot renew, where under standard DHCP, they would be able > to. Not true. They can still renew in the REBINDING state - just not in the RENEWING state. Your observation about the wording of when the DHCP server should pay attention to this option makes sense, though - I wonder where that came from. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Feb 14 13:08:24 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29329; Fri, 14 Feb 2003 13:08:24 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1EIC1p12818; Fri, 14 Feb 2003 13:12:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1EIB6p12756 for ; Fri, 14 Feb 2003 13:11:06 -0500 Received: from chimera.incognito.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29258 for ; Fri, 14 Feb 2003 13:06:51 -0500 (EST) Received: from homerdmz.incognito.com ([207.102.214.106] helo=homer.incognito.com.) by chimera.incognito.com with smtp (Exim 3.35 #1 (Debian)) id 18jkIF-0002IE-00; Fri, 14 Feb 2003 10:10:35 -0800 Received: by homer.incognito.com. with Internet Mail Service (5.5.2653.19) id <13JRHC5K>; Fri, 14 Feb 2003 10:16:43 -0800 Message-ID: <4FB49E60CFBA724E88867317DAA3D198A67A30@homer.incognito.com.> From: "Kostur, Andre" To: "'Ted Lemon'" , "Kostur, Andre" Cc: dhcwg@ietf.org Subject: RE: [dhcwg] I-D ACTION:draft-ietf-dhc-server-override-00.txt Date: Fri, 14 Feb 2003 10:16:41 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2D455.38F23020" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2D455.38F23020 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable If the device is in the REBINDING state, then the client is = broadcasting it's REQUEST. Since the Relay is down, the DHCP Server still won't = receive the Request, there's nothing to relay the broadcast to the server.... > -----Original Message----- > From: Ted Lemon [mailto:Ted.Lemon@nominum.com] > Sent: Friday, February 14, 2003 10:08 AM > To: Kostur, Andre > Cc: dhcwg@ietf.org > Subject: Re: [dhcwg] I-D ACTION:draft-ietf-dhc-server-override-00.txt >=20 >=20 > > 1) This introduces a new point of failure in a DHCP=20 > infrastructure.=A0=20 > > If this particular relay goes down, then devices which=20 > currently hold=20 > > a lease cannot renew, where under standard DHCP, they would=20 > be able > to. >=20 > Not true. They can still renew in the REBINDING state - just not in = > the RENEWING state. >=20 > Your observation about the wording of when the DHCP server should pay = > attention to this option makes sense, though - I wonder where=20 > that came=20 > from. >=20 ------_=_NextPart_001_01C2D455.38F23020 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] I-D = ACTION:draft-ietf-dhc-server-override-00.txt

If the device is in the REBINDING state, then the = client is broadcasting it's REQUEST.  Since the Relay is down, the = DHCP Server still won't receive the Request, there's nothing to relay = the broadcast to the server....

> -----Original Message-----
> From: Ted Lemon [mailto:Ted.Lemon@nominum.com]<= /FONT>
> Sent: Friday, February 14, 2003 10:08 AM
> To: Kostur, Andre
> Cc: dhcwg@ietf.org
> Subject: Re: [dhcwg] I-D = ACTION:draft-ietf-dhc-server-override-00.txt
>
>
> > 1) This introduces a new point of failure = in a DHCP
> infrastructure.=A0
> > If this particular relay goes down, then = devices which
> currently hold
> > a lease cannot renew, where under standard = DHCP, they would
> be able > to.
>
> Not true.   They can still renew in = the REBINDING state - just not in
> the RENEWING state.
>
> Your observation about the wording of when the = DHCP server should pay
> attention to this option makes sense, though - = I wonder where
> that came
> from.
>

------_=_NextPart_001_01C2D455.38F23020-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Feb 14 13:57:02 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00978; Fri, 14 Feb 2003 13:57:01 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1EJ0Tp15861; Fri, 14 Feb 2003 14:00:29 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1EIxjp15754 for ; Fri, 14 Feb 2003 13:59:45 -0500 Received: from toccata.fugue.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00916 for ; Fri, 14 Feb 2003 13:55:29 -0500 (EST) Received: from nominum.com (24-148-0-210.na.21stcentury.net [24.148.0.210]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id h1EIvcP29105; Fri, 14 Feb 2003 12:57:38 -0600 (CST) Date: Fri, 14 Feb 2003 12:59:12 -0600 Subject: Re: [dhcwg] I-D ACTION:draft-ietf-dhc-server-override-00.txt Content-Type: text/plain; charset=ISO-8859-1; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: dhcwg@ietf.org To: "Kostur, Andre" From: Ted Lemon In-Reply-To: <4FB49E60CFBA724E88867317DAA3D198A67A30@homer.incognito.com.> Message-Id: <6825222D-404E-11D7-AC5A-00039317663C@nominum.com> X-Mailer: Apple Mail (2.551) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h1EIxjp15755 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit > If the device is in the REBINDING state, then the client is > broadcasting it's REQUEST.  Since the Relay is down, the DHCP Server > still won't receive the Request, there's nothing to relay the > broadcast to the server.... If you don't have a redundant network setup, you don't have a redundant network setup. This is the same whether you are using the server override option or not. It's true that a site that has a redundant router configuration but no redundant relay agent configuration would be able to continue supporting renewals for existing clients through a relay agent outage, this isn't a very realistic scenario, and I don't think it's a valid criticism of the draft. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Feb 14 13:59:33 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01144; Fri, 14 Feb 2003 13:59:32 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1EJ35p16039; Fri, 14 Feb 2003 14:03:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1EJ2qp16009 for ; Fri, 14 Feb 2003 14:02:52 -0500 Received: from sj-msg-core-3.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01092 for ; Fri, 14 Feb 2003 13:58:36 -0500 (EST) Received: from jschnizl-w2k.cisco.com (sjc-vpn1-184.cisco.com [10.21.96.184]) by sj-msg-core-3.cisco.com (8.12.2/8.12.6) with ESMTP id h1EJ27B9015967; Fri, 14 Feb 2003 11:02:11 -0800 (PST) Message-Id: <4.3.2.7.2.20030214135721.0472c4d0@wells.cisco.com> X-Sender: jschnizl@wells.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 14 Feb 2003 14:02:15 -0500 To: "Kostur, Andre" From: John Schnizlein Subject: RE: [dhcwg] I-D ACTION:draft-ietf-dhc-server-override-00.txt Cc: dhcwg@ietf.org In-Reply-To: <4FB49E60CFBA724E88867317DAA3D198A67A30@homer.incognito.com .> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , At 01:16 PM 2/14/2003, Kostur, Andre wrote: >If the device is in the REBINDING state, then the client is >broadcasting it's REQUEST. Since the Relay is down, the DHCP >Server still won't receive the Request, there's nothing to >relay the broadcast to the server.... > >>> 1) This introduces a new point of failure in a DHCP infrastructure. Maybe I am missing something, but this seems not to be a new point of potential failure because the relay is usually the router nearest the DHCP client. If it goes down, no traffic of any kind reaches anywhere off the local subnet. John _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Feb 14 14:31:09 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02149; Fri, 14 Feb 2003 14:31:09 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1EJYkp18299; Fri, 14 Feb 2003 14:34:46 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1EJXJp18175 for ; Fri, 14 Feb 2003 14:33:19 -0500 Received: from chimera.incognito.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02012 for ; Fri, 14 Feb 2003 14:29:02 -0500 (EST) Received: from homerdmz.incognito.com ([207.102.214.106] helo=homer.incognito.com.) by chimera.incognito.com with smtp (Exim 3.35 #1 (Debian)) id 18jlWP-0002nC-00; Fri, 14 Feb 2003 11:29:17 -0800 Received: by homer.incognito.com. with Internet Mail Service (5.5.2653.19) id <13JRHC0H>; Fri, 14 Feb 2003 11:35:25 -0800 Message-ID: <4FB49E60CFBA724E88867317DAA3D198A67A33@homer.incognito.com.> From: "Kostur, Andre" To: "'John Schnizlein'" , "Kostur, Andre" Cc: dhcwg@ietf.org Subject: RE: [dhcwg] I-D ACTION:draft-ietf-dhc-server-override-00.txt Date: Fri, 14 Feb 2003 11:35:24 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2D460.385CA5E0" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2D460.385CA5E0 Content-Type: text/plain; charset="iso-8859-1" > >If the device is in the REBINDING state, then the client is > >broadcasting it's REQUEST. Since the Relay is down, the DHCP > >Server still won't receive the Request, there's nothing to > >relay the broadcast to the server.... > > > >>> 1) This introduces a new point of failure in a DHCP > infrastructure. > > Maybe I am missing something, but this seems not to be a new > point of potential failure because the relay is usually the > router nearest the DHCP client. If it goes down, no traffic > of any kind reaches anywhere off the local subnet. Granted, but it's not required that the Relay must exist on the Router between two networks. ------_=_NextPart_001_01C2D460.385CA5E0 Content-Type: text/html; charset="iso-8859-1" RE: [dhcwg] I-D ACTION:draft-ietf-dhc-server-override-00.txt

> >If the device is in the REBINDING state, then the client is
> >broadcasting it's REQUEST.  Since the Relay is down, the DHCP
> >Server still won't receive the Request, there's nothing to
> >relay the broadcast to the server....
> >
> >>> 1) This introduces a new point of failure in a DHCP
> infrastructure. 
>
> Maybe I am missing something, but this seems not to be a new
> point of potential failure because the relay is usually the
> router nearest the DHCP client. If it goes down, no traffic
> of any kind reaches anywhere off the local subnet.

Granted, but it's not required that the Relay must exist on the
Router between two networks.

------_=_NextPart_001_01C2D460.385CA5E0-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Feb 14 14:42:44 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02546; Fri, 14 Feb 2003 14:42:44 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1EJkOp19636; Fri, 14 Feb 2003 14:46:24 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1EJjDp19613 for ; Fri, 14 Feb 2003 14:45:13 -0500 Received: from chimera.incognito.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02481 for ; Fri, 14 Feb 2003 14:40:55 -0500 (EST) Received: from homerdmz.incognito.com ([207.102.214.106] helo=homer.incognito.com.) by chimera.incognito.com with smtp (Exim 3.35 #1 (Debian)) id 18jllI-0002vi-00; Fri, 14 Feb 2003 11:44:40 -0800 Received: by homer.incognito.com. with Internet Mail Service (5.5.2653.19) id <13JRHDA0>; Fri, 14 Feb 2003 11:50:49 -0800 Message-ID: <4FB49E60CFBA724E88867317DAA3D198A67A34@homer.incognito.com.> From: "Kostur, Andre" To: "'Ted Lemon'" , "Kostur, Andre" Cc: dhcwg@ietf.org Subject: RE: [dhcwg] I-D ACTION:draft-ietf-dhc-server-override-00.txt Date: Fri, 14 Feb 2003 11:50:49 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2D462.5F6F5310" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2D462.5F6F5310 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > > 1) This introduces a new point of failure in a DHCP=20 > infrastructure.=A0=20 > > If this particular relay goes down, then devices which=20 > currently hold=20 > > a lease cannot renew, where under standard DHCP, they would=20 > be able > to. >=20 > Not true. They can still renew in the REBINDING state - just not in = > the RENEWING state. >=20 > Your observation about the wording of when the DHCP server should pay = > attention to this option makes sense, though - I wonder where=20 > that came=20 > from. Assuming that the Draft is modified to have the DHCP server always pay attention to the sub-option, what about the initial DHCPREQUEST (the = one sent in response to an Offer) arriving at the DHCP server with a = ServerID that isn't the DHCP Server's IP? Wouldn't that mean to the server that = it should _not_ pay attention to this packet since it is intended for a different DHCP server?=20 ------_=_NextPart_001_01C2D462.5F6F5310 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] I-D = ACTION:draft-ietf-dhc-server-override-00.txt

> > 1) This introduces a new point of failure = in a DHCP
> infrastructure.=A0
> > If this particular relay goes down, then = devices which
> currently hold
> > a lease cannot renew, where under standard = DHCP, they would
> be able > to.
>
> Not true.   They can still renew in = the REBINDING state - just not in
> the RENEWING state.
>
> Your observation about the wording of when the = DHCP server should pay
> attention to this option makes sense, though - = I wonder where
> that came
> from.

Assuming that the Draft is modified to have the DHCP = server always pay
attention to the sub-option, what about the initial = DHCPREQUEST (the one
sent in response to an Offer) arriving at the DHCP = server with a ServerID
that isn't the DHCP Server's IP?  Wouldn't that = mean to the server that it
should _not_ pay attention to this packet since it = is intended for a
different DHCP server?

------_=_NextPart_001_01C2D462.5F6F5310-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Feb 14 14:45:07 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02676; Fri, 14 Feb 2003 14:45:07 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1EJmqp19792; Fri, 14 Feb 2003 14:48:52 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1EJlqp19698 for ; Fri, 14 Feb 2003 14:47:52 -0500 Received: from chimera.incognito.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02616 for ; Fri, 14 Feb 2003 14:43:34 -0500 (EST) Received: from homerdmz.incognito.com ([207.102.214.106] helo=homer.incognito.com.) by chimera.incognito.com with smtp (Exim 3.35 #1 (Debian)) id 18jlnr-0002wj-00; Fri, 14 Feb 2003 11:47:19 -0800 Received: by homer.incognito.com. with Internet Mail Service (5.5.2653.19) id <13JRHDB1>; Fri, 14 Feb 2003 11:53:28 -0800 Message-ID: <4FB49E60CFBA724E88867317DAA3D198A67A35@homer.incognito.com.> From: "Kostur, Andre" To: "'Ted Lemon'" , "Kostur, Andre" Cc: dhcwg@ietf.org Subject: RE: [dhcwg] I-D ACTION:draft-ietf-dhc-server-override-00.txt Date: Fri, 14 Feb 2003 11:53:27 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2D462.BDD7B870" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2D462.BDD7B870 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > > If the device is in the REBINDING state, then the client is=20 > > broadcasting it's REQUEST.=A0 Since the Relay is down, the=20 > DHCP Server=20 > > still won't receive the Request, there's nothing to relay the=20 > > broadcast to the server.... >=20 > If you don't have a redundant network setup, you don't have a=20 > redundant=20 > network setup. This is the same whether you are using the server=20 > override option or not. It's true that a site that has a redundant=20 > router configuration but no redundant relay agent configuration would = > be able to continue supporting renewals for existing clients=20 > through a=20 > relay agent outage, this isn't a very realistic scenario, and I don't = > think it's a valid criticism of the draft. OK, assuming that one has multiple relays on the network, then devices at T2 will still be able to renew their leases (and new devices will be able to acquire new leases). In the redundant cases, does this imply that the redundant relays need to pass whatever information it acquires from the DHCP clients to each other through some other proprietary mechanism? After the first set of broadcasts used to establish a lease (which both relays will hear), a DHCP client then only uses unicast packets to talk to one of the relays. The second relay will no longer hear from the client. So = after the initial lease time expires, the second relay will "forget" about = that lease. (It may even drop the lease once it sees the DHCPREQUEST pass through that has a ServerID with a different IP than itself, although = the redundant relay could be configured to recognize the ServerID of it's "partner" relay to prevent this.) ------_=_NextPart_001_01C2D462.BDD7B870 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] I-D = ACTION:draft-ietf-dhc-server-override-00.txt

> > If the device is in the REBINDING state, = then the client is
> > broadcasting it's REQUEST.=A0 Since the = Relay is down, the
> DHCP Server
> > still won't receive the Request, there's = nothing to relay the
> > broadcast to the server....
>
> If you don't have a redundant network setup, = you don't have a
> redundant
> network setup.   This is the same = whether you are using the server
> override option or not.   It's true = that a site that has a redundant
> router configuration but no redundant relay = agent configuration would
> be able to continue supporting renewals for = existing clients
> through a
> relay agent outage, this isn't a very realistic = scenario, and I don't
> think it's a valid criticism of the = draft.

OK, assuming that one has multiple relays on the = network, then devices
at T2 will still be able to renew their leases (and = new devices will
be able to acquire new leases).

In the redundant cases, does this imply that the = redundant relays need
to pass whatever information it acquires from the = DHCP clients to each
other through some other proprietary = mechanism?  After the first set of
broadcasts used to establish a lease (which both = relays will hear),
a DHCP client then only uses unicast packets to talk = to one of the
relays.  The second relay will no longer hear = from the client.  So after
the initial lease time expires, the second relay = will "forget" about that
lease.  (It may even drop the lease once it = sees the DHCPREQUEST pass
through that has a ServerID with a different IP than = itself, although the
redundant relay could be configured to recognize the = ServerID of it's
"partner" relay to prevent this.)

------_=_NextPart_001_01C2D462.BDD7B870-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Feb 14 14:56:52 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02955; Fri, 14 Feb 2003 14:56:52 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1EK0Pp20128; Fri, 14 Feb 2003 15:00:25 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1EJx8p20059 for ; Fri, 14 Feb 2003 14:59:08 -0500 Received: from toccata.fugue.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02897 for ; Fri, 14 Feb 2003 14:54:50 -0500 (EST) Received: from nominum.com (24-148-0-210.na.21stcentury.net [24.148.0.210]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id h1EJuxP00666; Fri, 14 Feb 2003 13:56:59 -0600 (CST) Date: Fri, 14 Feb 2003 13:58:34 -0600 Subject: Re: [dhcwg] I-D ACTION:draft-ietf-dhc-server-override-00.txt Content-Type: text/plain; charset=ISO-8859-1; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: dhcwg@ietf.org To: "Kostur, Andre" From: Ted Lemon In-Reply-To: <4FB49E60CFBA724E88867317DAA3D198A67A34@homer.incognito.com.> Message-Id: X-Mailer: Apple Mail (2.551) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h1EJx8p20060 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit > Assuming that the Draft is modified to have the DHCP server always pay > attention to the sub-option, what about the initial DHCPREQUEST (the > one > sent in response to an Offer) arriving at the DHCP server with a > ServerID > that isn't the DHCP Server's IP?  Wouldn't that mean to the server > that it > should _not_ pay attention to this packet since it is intended for a > different DHCP server? Yes, that needs to be addressed. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Feb 14 15:23:35 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03659; Fri, 14 Feb 2003 15:23:35 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1EKRAp22116; Fri, 14 Feb 2003 15:27:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1EKQNp22101 for ; Fri, 14 Feb 2003 15:26:23 -0500 Received: from toccata.fugue.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03639 for ; Fri, 14 Feb 2003 15:22:04 -0500 (EST) Received: from nominum.com (24-148-0-210.na.21stcentury.net [24.148.0.210]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id h1EKOBP01003; Fri, 14 Feb 2003 14:24:12 -0600 (CST) Date: Fri, 14 Feb 2003 14:25:46 -0600 Subject: Re: [dhcwg] I-D ACTION:draft-ietf-dhc-server-override-00.txt Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: dhcwg@ietf.org To: "Kostur, Andre" From: Ted Lemon In-Reply-To: <4FB49E60CFBA724E88867317DAA3D198A67A35@homer.incognito.com.> Message-Id: <7FE5C2AA-405A-11D7-AC5A-00039317663C@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > In the redundant cases, does this imply that the redundant relays need > to pass whatever information it acquires from the DHCP clients to each > other through some other proprietary mechanism? The point of this option is to ensure that the relays see every message from the client and therefore have an opportunity to insert a relay agent information option into each such message. I don't know why it would be necessary for the relay agent to remember anything at all about the client, nor do I see any need for a proprietary or standard inter-relay-agent protocol. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Feb 14 15:30:25 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03911; Fri, 14 Feb 2003 15:30:25 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1EKY8p22503; Fri, 14 Feb 2003 15:34:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1EKXXp22434 for ; Fri, 14 Feb 2003 15:33:33 -0500 Received: from chimera.incognito.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03871 for ; Fri, 14 Feb 2003 15:29:14 -0500 (EST) Received: from homerdmz.incognito.com ([207.102.214.106] helo=homer.incognito.com.) by chimera.incognito.com with smtp (Exim 3.35 #1 (Debian)) id 18jmW2-0003Kc-00; Fri, 14 Feb 2003 12:32:58 -0800 Received: by homer.incognito.com. with Internet Mail Service (5.5.2653.19) id <13JRHD17>; Fri, 14 Feb 2003 12:39:06 -0800 Message-ID: <4FB49E60CFBA724E88867317DAA3D198A67A36@homer.incognito.com.> From: "Kostur, Andre" To: "'Ted Lemon'" , "Kostur, Andre" Cc: dhcwg@ietf.org Subject: RE: [dhcwg] I-D ACTION:draft-ietf-dhc-server-override-00.txt Date: Fri, 14 Feb 2003 12:39:06 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2D469.1E418460" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2D469.1E418460 Content-Type: text/plain; charset="iso-8859-1" > > In the redundant cases, does this imply that the redundant > relays need > > to pass whatever information it acquires from the DHCP > clients to each > > other through some other proprietary mechanism? > > The point of this option is to ensure that the relays see > every message > from the client and therefore have an opportunity to insert a relay > agent information option into each such message. I don't > know why it > would be necessary for the relay agent to remember anything at all > about the client, nor do I see any need for a proprietary or standard > inter-relay-agent protocol. Does this change RFC 3046? Consequently, servers SHOULD be prepared to handle relay agent options in unicast messages, but MUST NOT expect them to always be there. Given that wording, the DHCP server is required to behave "correctly", even if the incoming Request doesn't have option 82 in it, why do we need an option to force it's existance? ------_=_NextPart_001_01C2D469.1E418460 Content-Type: text/html; charset="iso-8859-1" RE: [dhcwg] I-D ACTION:draft-ietf-dhc-server-override-00.txt

> > In the redundant cases, does this imply that the redundant
> relays need
> > to pass whatever information it acquires from the DHCP
> clients to each
> > other through some other proprietary mechanism?
>
> The point of this option is to ensure that the relays see
> every message
> from the client and therefore have an opportunity to insert a relay
> agent information option into each such message.   I don't
> know why it
> would be necessary for the relay agent to remember anything at all
> about the client, nor do I see any need for a proprietary or standard
> inter-relay-agent protocol.

Does this change RFC 3046? 

   Consequently, servers SHOULD be prepared to handle relay agent
   options in unicast messages, but MUST NOT expect them to always be
   there.

Given that wording, the DHCP server is required to behave "correctly",
even if the incoming Request doesn't have option 82 in it, why do we
need an option to force it's existance?

------_=_NextPart_001_01C2D469.1E418460-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Feb 14 16:07:06 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05001; Fri, 14 Feb 2003 16:07:06 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1ELAdp25421; Fri, 14 Feb 2003 16:10:39 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1EL9Xp25363 for ; Fri, 14 Feb 2003 16:09:33 -0500 Received: from toccata.fugue.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04969 for ; Fri, 14 Feb 2003 16:05:14 -0500 (EST) Received: from nominum.com (24-148-0-210.na.21stcentury.net [24.148.0.210]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id h1EL7MP01452; Fri, 14 Feb 2003 15:07:23 -0600 (CST) Date: Fri, 14 Feb 2003 15:08:57 -0600 Subject: Re: [dhcwg] I-D ACTION:draft-ietf-dhc-server-override-00.txt Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: dhcwg@ietf.org To: "Kostur, Andre" From: Ted Lemon In-Reply-To: <4FB49E60CFBA724E88867317DAA3D198A67A36@homer.incognito.com.> Message-Id: <885B5F1B-4060-11D7-AC5A-00039317663C@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > Given that wording, the DHCP server is required to behave "correctly", > even if the incoming Request doesn't have option 82 in it, why do we > need an option to force it's existance? Because it turns out that it's a more reliable way of accomplishing the goals of option 82. Sure, the DHCP server can cache the option 82 from the most recent broadcast message from the client, but it's less likely to be using stale information, and less likely to be spoofed, if the server doesn't have to cache this information, but instead gets a fresh copy of it each time it gets a message from the client. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sat Feb 15 02:40:24 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27661; Sat, 15 Feb 2003 02:40:24 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1F7iCp07323; Sat, 15 Feb 2003 02:44:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1F7gGp07283 for ; Sat, 15 Feb 2003 02:42:16 -0500 Received: from rediffmail.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA27637 for ; Sat, 15 Feb 2003 02:37:44 -0500 (EST) Received: (qmail 22242 invoked by uid 510); 15 Feb 2003 07:46:16 -0000 Date: 15 Feb 2003 07:46:16 -0000 Message-ID: <20030215074616.22241.qmail@webmail29.rediffmail.com> Received: from unknown (61.11.78.54) by rediffmail.com via HTTP; 15 feb 2003 07:46:16 -0000 MIME-Version: 1.0 From: "Chandra Murali" Reply-To: "Chandra Murali" To: dhcwg@ietf.org Content-type: text/plain; format=flowed Content-Disposition: inline Subject: [dhcwg] How to configure after getting message from server Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , hi friends, i'm devoloping dhcp client protocol in Solaris 5.7 platform. i need to know how to configure the client machine after getting dhcpoffer message from DHCP server. i mean i need to know how to change my system IP address that was received from server. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sat Feb 15 04:22:36 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29178; Sat, 15 Feb 2003 04:22:36 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1F9QVp12009; Sat, 15 Feb 2003 04:26:31 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1F9Pcp11975 for ; Sat, 15 Feb 2003 04:25:38 -0500 Received: from ratree.psu.ac.th (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29167 for ; Sat, 15 Feb 2003 04:21:02 -0500 (EST) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h1F9Ohq20955; Sat, 15 Feb 2003 16:24:43 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h1F9OYb14626; Sat, 15 Feb 2003 16:24:37 +0700 (ICT) From: Robert Elz To: Ted Lemon cc: "Kostur, Andre" , dhcwg@ietf.org Subject: Re: [dhcwg] I-D ACTION:draft-ietf-dhc-server-override-00.txt In-Reply-To: <7FE5C2AA-405A-11D7-AC5A-00039317663C@nominum.com> References: <7FE5C2AA-405A-11D7-AC5A-00039317663C@nominum.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 15 Feb 2003 16:24:34 +0700 Message-ID: <14624.1045301074@munnari.OZ.AU> Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Date: Fri, 14 Feb 2003 14:25:46 -0600 From: Ted Lemon Message-ID: <7FE5C2AA-405A-11D7-AC5A-00039317663C@nominum.com> | The point of this option is to ensure that the relays see every message | from the client and therefore have an opportunity to insert a relay | agent information option into each such message. I agree. However, why is the server getting involved in this? If the relay wants its clients to see a DHCP SERVER option containing its IP address, why wouldn't it just alter the reply back from the server to the client (which goes back through the relay agent) ? There should be no problem with later unicast renewals direct from client to server, as the relay agent *is* the server as far as the client is concerned. kre _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sat Feb 15 12:33:20 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05219; Sat, 15 Feb 2003 12:33:20 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1FHbRp04648; Sat, 15 Feb 2003 12:37:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1FHa1p03879 for ; Sat, 15 Feb 2003 12:36:01 -0500 Received: from toccata.fugue.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05199 for ; Sat, 15 Feb 2003 12:31:16 -0500 (EST) Received: from nominum.com (dsl093-187-232.chi2.dsl.speakeasy.net [66.93.187.232]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id h1FHXHP09948; Sat, 15 Feb 2003 11:33:17 -0600 (CST) Date: Sat, 15 Feb 2003 11:35:02 -0600 Subject: Re: [dhcwg] I-D ACTION:draft-ietf-dhc-server-override-00.txt Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: dhcwg@ietf.org, "Kostur, Andre" To: Robert Elz From: Ted Lemon In-Reply-To: <14624.1045301074@munnari.OZ.AU> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > However, why is the server getting involved in this? If the relay > wants > its clients to see a DHCP SERVER option containing its IP address, why > wouldn't it just alter the reply back from the server to the client > (which goes back through the relay agent) ? Because this would violate the DHCP authentication RFC - if you hack the middle of the packet, it breaks the security checksum. If you make changes to the relay agent information option, as a relay agent, that's okay, because the DHCP client and server don't include that option when checking signatures. This may seem academic right now, since nobody is using the DHCP authentication RFC, but I think that will change in the future, and the authors of this draft have rightly chosen not to create a new RFC that's in conflict with the old one. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sun Feb 16 01:15:37 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA12621; Sun, 16 Feb 2003 01:15:37 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1G6Jup05590; Sun, 16 Feb 2003 01:19:56 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1G6IZp05571 for ; Sun, 16 Feb 2003 01:18:36 -0500 Received: from ratree.psu.ac.th (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA12599 for ; Sun, 16 Feb 2003 01:13:34 -0500 (EST) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h1G6H9q01427; Sun, 16 Feb 2003 13:17:09 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h1G6GuK02284; Sun, 16 Feb 2003 13:16:59 +0700 (ICT) From: Robert Elz To: Ted Lemon cc: dhcwg@ietf.org, "Kostur, Andre" Subject: Re: [dhcwg] I-D ACTION:draft-ietf-dhc-server-override-00.txt In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 16 Feb 2003 13:16:56 +0700 Message-ID: <2282.1045376216@munnari.OZ.AU> Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Date: Sat, 15 Feb 2003 11:35:02 -0600 From: Ted Lemon Message-ID: | Because this would violate the DHCP authentication RFC OK, that makes sense. kre _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sun Feb 16 11:45:11 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27427; Sun, 16 Feb 2003 11:45:11 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1GGnbp15685; Sun, 16 Feb 2003 11:49:38 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1GGlXp15642 for ; Sun, 16 Feb 2003 11:47:33 -0500 Received: from rtp-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27418 for ; Sun, 16 Feb 2003 11:42:20 -0500 (EST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h1GGk5JR017950 for ; Sun, 16 Feb 2003 11:46:05 -0500 (EST) Received: from rdroms-w2k.cisco.com (sjc-vpn2-458.cisco.com [10.21.113.202]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id LAA19718 for ; Sun, 16 Feb 2003 11:46:04 -0500 (EST) Message-Id: <4.3.2.7.2.20030216113245.00bb4278@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sun, 16 Feb 2003 11:45:59 -0500 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [dhcwg] Final draft of revised DHC WG charter Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Included below is a final draft of the revised DHC WG charter. This changes to this draft are primarily editorial to for improved clarity and readability. Please review and comment on this draft charter by Wed, 2/19. The IESG will review the charter on 2/20. Thanks... - Ralph Dynamic Host Configuration (dhc) -------------------------------- Charter Last Modified: 2003--2-16 Current Status: Active Working Group Chair(s): R. Droms Internet Area Director(s): Thomas Narten E. Nordmark Internet Area Advisor: Thomas Narten Mailing Lists: General Discussion:dhcwg@ietf.org To Subscribe: http://www1.ietf.org/mailman/listinfo/dhcwg Archive: http://www1.ietf.org/mailman/listinfo/dhcwg Description of Working Group The dhc working group (DHC WG) has developed DHCP for automated allocation, configuration and management of IP addresses and TCP/IP protocol stack parameters. DHCP is currently a "Draft Standard". The base protocol is document in RFC2131 and RFC2132. Additional options are documented in subsequent RFCs. The DHC WG is responsible for reviewing (and sometimes developing) DHCP options or other extensions (for both IPv4 and IPv6). The DHC WG is expected to review all proposed extensions to DHCP to ensure that they are consistent with the DHCP specification and other option formats, that they do not duplicate existing mechanisms, etc. The DHC WG will not (generally) be responsible for evaluating the semantic content of proposed options. The DHC WG will not adopt new proposals for extensions to DHCP as working group documents without first coordinating with other relevant working groups and determining who has the responsibility for reviewing the semantic content of an option. The DHC WG has the following main objectives: * The DHC WG will address security in DHCP o Develop and document security requirements for DHCP. RFC 3118 defines current security mechanisms for DHCPv4. Unfortunately, RFC 3118 has neither been implemented nor deployed to date. Specific issues to be considered include: - Improved key management and scalability - Security for messages passed between relay agents and servers - Threats of DoS attacks through FORCERENEW - The increased usage of DHC on unsecure (e.g., wireless) and public LANs - The need for clients to be able to authenticate servers, without simultaneusly requiring client authentication by the server. o Develop and document a roadmap of any new documents or protocols needed to meet the security requirements for DHCP * Write an analysis of the DHCP specification, including RFC2131, RFC2132 and other RFCs defining additional options, which identifies ambiguities, contradictory specifications and other obstacles to development of interoperable implementations. Recommend a process for resolving identified problems and incorporating the resolutions into the DHCP specification. * Complete or abandon work on DHCPv6 options that are currently work in progress: IPv6 Prefix Options for DHCPv6 DNS Configuration options for DHCPv6 Load Balancing for DHCPv6 NIS Configuration Options for DHCPv6 Time Configuration Options for DHCPv6 Client Preferred Prefix option for DHCPv6 A Guide to Implementing Stateless DHCPv6 Service DSTM Options for DHCPv6 DSTM Ports Option for DHCPv6 * Complete or abandon work on DHCP extensions and options that are currently work in progress: Failover protocol The DHCP Client FQDN Option Resolution of DNS Name Conflicts Among DHCP Clients DHCP Server MIB Considerations for the use of the Host Name option DHCP Lease Query DHCP Options for Internet Storage Name Service Dynamic Host Configuration Protocol (DHCP) Server MIB DHCP Option for Mobile IP Mobility Agents DHCP VPN Information Option KDC Server Address Sub-option The Authentication Suboption for the DHCP Relay Agent Option Link Selection sub-option for the Relay Agent Information Option VPN Identifier sub-option for the Relay Agent Information Option RADIUS Attributes Sub-option for the DHCP Relay Agent Information Option DHCP Subscriber ID Suboption for the DHCP Relay Agent Option _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Feb 17 11:40:00 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25429; Mon, 17 Feb 2003 11:40:00 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1HGiwp05843; Mon, 17 Feb 2003 11:44:58 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1HGhcp05794 for ; Mon, 17 Feb 2003 11:43:38 -0500 Received: from imr2.ericy.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25417 for ; Mon, 17 Feb 2003 11:37:55 -0500 (EST) Received: from mr5.exu.ericsson.se (mr5att.ericy.com [138.85.224.141]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id h1HGfhb11717; Mon, 17 Feb 2003 10:41:43 -0600 (CST) Received: from eamrcnt760.exu.ericsson.se (eamrcnt760.exu.ericsson.se [138.85.133.38]) by mr5.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id h1HGfg819407; Mon, 17 Feb 2003 10:41:42 -0600 (CST) Received: by eamrcnt760.exu.ericsson.se with Internet Mail Service (5.5.2656.59) id ; Mon, 17 Feb 2003 10:41:42 -0600 Message-ID: From: "Bernie Volz (EUD)" To: "'Ralph Droms'" , dhcwg@ietf.org Subject: RE: [dhcwg] Final draft of revised DHC WG charter Date: Mon, 17 Feb 2003 10:40:04 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2D6A2.B2EC8A0C" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2D6A2.B2EC8A0C Content-Type: text/plain; charset="ISO-8859-1" Ralph: This looks fine. My one comment would be that it would be great if we can put in something about DHCPv6 in the first paragraph of the description, such as: The dhc working group (DHC WG) has developed DHCP for automated allocation, configuration and management of IP addresses and TCP/IP protocol stack parameters. DHCP is currently a "Draft Standard". The base protocol is document in RFC2131 and RFC2132 for DHCPv4 and RFCxxxx for DHCPv6. Additional options are documented in subsequent RFCs. Perhaps by the time this charter is approved and published, we'll know the RFC number (or perhaps the IESG can request this from IANA before updating the official WG description). However, this isn't a big issue and I don't want to delay the update any further just because of this!! Will you also publish the updated milestones? - Bernie -----Original Message----- From: Ralph Droms [mailto:rdroms@cisco.com] Sent: Sunday, February 16, 2003 11:46 AM To: dhcwg@ietf.org Subject: [dhcwg] Final draft of revised DHC WG charter Included below is a final draft of the revised DHC WG charter. This changes to this draft are primarily editorial to for improved clarity and readability. Please review and comment on this draft charter by Wed, 2/19. The IESG will review the charter on 2/20. Thanks... - Ralph Dynamic Host Configuration (dhc) -------------------------------- Charter Last Modified: 2003--2-16 Current Status: Active Working Group Chair(s): R. Droms Internet Area Director(s): Thomas Narten E. Nordmark Internet Area Advisor: Thomas Narten Mailing Lists: General Discussion:dhcwg@ietf.org To Subscribe: http://www1.ietf.org/mailman/listinfo/dhcwg Archive: http://www1.ietf.org/mailman/listinfo/dhcwg Description of Working Group The dhc working group (DHC WG) has developed DHCP for automated allocation, configuration and management of IP addresses and TCP/IP protocol stack parameters. DHCP is currently a "Draft Standard". The base protocol is document in RFC2131 and RFC2132. Additional options are documented in subsequent RFCs. The DHC WG is responsible for reviewing (and sometimes developing) DHCP options or other extensions (for both IPv4 and IPv6). The DHC WG is expected to review all proposed extensions to DHCP to ensure that they are consistent with the DHCP specification and other option formats, that they do not duplicate existing mechanisms, etc. The DHC WG will not (generally) be responsible for evaluating the semantic content of proposed options. The DHC WG will not adopt new proposals for extensions to DHCP as working group documents without first coordinating with other relevant working groups and determining who has the responsibility for reviewing the semantic content of an option. The DHC WG has the following main objectives: * The DHC WG will address security in DHCP o Develop and document security requirements for DHCP. RFC 3118 defines current security mechanisms for DHCPv4. Unfortunately, RFC 3118 has neither been implemented nor deployed to date. Specific issues to be considered include: - Improved key management and scalability - Security for messages passed between relay agents and servers - Threats of DoS attacks through FORCERENEW - The increased usage of DHC on unsecure (e.g., wireless) and public LANs - The need for clients to be able to authenticate servers, without simultaneusly requiring client authentication by the server. o Develop and document a roadmap of any new documents or protocols needed to meet the security requirements for DHCP * Write an analysis of the DHCP specification, including RFC2131, RFC2132 and other RFCs defining additional options, which identifies ambiguities, contradictory specifications and other obstacles to development of interoperable implementations. Recommend a process for resolving identified problems and incorporating the resolutions into the DHCP specification. * Complete or abandon work on DHCPv6 options that are currently work in progress: IPv6 Prefix Options for DHCPv6 DNS Configuration options for DHCPv6 Load Balancing for DHCPv6 NIS Configuration Options for DHCPv6 Time Configuration Options for DHCPv6 Client Preferred Prefix option for DHCPv6 A Guide to Implementing Stateless DHCPv6 Service DSTM Options for DHCPv6 DSTM Ports Option for DHCPv6 * Complete or abandon work on DHCP extensions and options that are currently work in progress: Failover protocol The DHCP Client FQDN Option Resolution of DNS Name Conflicts Among DHCP Clients DHCP Server MIB Considerations for the use of the Host Name option DHCP Lease Query DHCP Options for Internet Storage Name Service Dynamic Host Configuration Protocol (DHCP) Server MIB DHCP Option for Mobile IP Mobility Agents DHCP VPN Information Option KDC Server Address Sub-option The Authentication Suboption for the DHCP Relay Agent Option Link Selection sub-option for the Relay Agent Information Option VPN Identifier sub-option for the Relay Agent Information Option RADIUS Attributes Sub-option for the DHCP Relay Agent Information Option DHCP Subscriber ID Suboption for the DHCP Relay Agent Option _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg ------_=_NextPart_001_01C2D6A2.B2EC8A0C Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] Final draft of revised DHC WG charter

Ralph:

This looks fine.

My one comment would be that it would be great if we = can put in something
about DHCPv6 in the first paragraph of the = description, such as:

   The dhc working group (DHC WG) has = developed DHCP for automated
   allocation, configuration and = management of IP addresses and TCP/IP
   protocol stack parameters. DHCP is = currently a "Draft Standard".  The
   base protocol is document in RFC2131 = and RFC2132 for DHCPv4 and
   RFCxxxx for DHCPv6.  Additional = options are documented in subsequent
   RFCs.

Perhaps by the time this charter is approved and = published, we'll know
the RFC number (or perhaps the IESG can request this = from IANA before
updating the official WG description).

However, this isn't a big issue and I don't want to = delay the update any
further just because of this!!

Will you also publish the updated milestones?

- Bernie

-----Original Message-----
From: Ralph Droms [mailto:rdroms@cisco.com]
Sent: Sunday, February 16, 2003 11:46 AM
To: dhcwg@ietf.org
Subject: [dhcwg] Final draft of revised DHC WG = charter


Included below is a final draft of the revised DHC WG = charter.  This
changes to this draft are primarily editorial to for = improved clarity and
readability.  Please review and comment on this = draft charter by Wed,
2/19.  The IESG will review the charter on = 2/20.  Thanks...

- Ralph



Dynamic Host Configuration (dhc)
--------------------------------

  Charter
  Last Modified: 2003--2-16

  Current Status: Active Working Group

  Chair(s):
      R. Droms  = <rdroms@cisco.com>

  Internet Area Director(s):
      Thomas Narten  = <narten@us.ibm.com>
      E. Nordmark  = <erik.nordmark@sun.com>

  Internet Area Advisor:
      Thomas Narten  = <narten@us.ibm.com>

  Mailing Lists:
      General = Discussion:dhcwg@ietf.org
      To = Subscribe:      http://www1.ietf.org/mailman/listinfo/dhcwg=
      = Archive:           http://www1.ietf.org/mailman/listinfo/dhcwg=


Description of Working Group


The dhc working group (DHC WG) has developed DHCP for = automated
allocation, configuration and management of IP = addresses and TCP/IP
protocol stack parameters. DHCP is currently a = "Draft Standard".  The
base protocol is document in RFC2131 and = RFC2132.  Additional options
are documented in subsequent RFCs.

The DHC WG is responsible for reviewing (and = sometimes developing)
DHCP options or other extensions (for both IPv4 and = IPv6). The DHC WG
is expected to review all proposed extensions to = DHCP to ensure that
they are consistent with the DHCP specification and = other option
formats, that they do not duplicate existing = mechanisms, etc.  The DHC
WG will not (generally) be responsible for = evaluating the semantic
content of proposed options. The DHC WG will not = adopt new proposals
for extensions to DHCP as working group documents = without first
coordinating with other relevant working groups and = determining who
has the responsibility for reviewing the semantic = content of an
option.

The DHC WG has the following main objectives:

* The DHC WG will address security in DHCP

   o Develop and document security = requirements for DHCP.  RFC 3118
     defines current security = mechanisms for DHCPv4.  Unfortunately,
     RFC 3118 has neither been = implemented nor deployed to date.
     Specific issues to be = considered include:

     - Improved key management = and scalability
     - Security for messages = passed between relay agents and servers
     - Threats of DoS attacks = through FORCERENEW
     - The increased usage of = DHC on unsecure (e.g., wireless) and
       public = LANs
     - The need for clients to = be able to authenticate servers, without
       simultaneusly = requiring client authentication by the server.

   o Develop and document a roadmap of any = new documents or protocols
     needed to meet the security = requirements for DHCP

* Write an analysis of the DHCP specification, = including RFC2131,
   RFC2132 and other RFCs defining = additional options, which identifies
   ambiguities, contradictory = specifications and other obstacles to
   development of interoperable = implementations.  Recommend a process
   for resolving identified problems and = incorporating the resolutions
   into the DHCP specification.

* Complete or abandon work on DHCPv6 options that are = currently work
   in progress:

     IPv6 Prefix Options for = DHCPv6
       <draft-troan-= dhcpv6-opt-prefix-delegation-01.txt>
     DNS Configuration options = for DHCPv6
       = <draft-ietf-dhc-dhcpv6-opt-dnsconfig-01.txt>
     Load Balancing for = DHCPv6
       = <draft-ietf-dhc-dhcpv6-loadb-02.txt>
     NIS Configuration Options = for DHCPv6
       = <draft-ietf-dhc-dhcpv6-opt-nisconfig-01.txt>
     Time Configuration Options = for DHCPv6
       = <draft-ietf-dhc-dhcpv6-opt-timeconfig-01.txt>
     Client Preferred Prefix = option for DHCPv6
       = <draft-ietf-dhc-dhcpv6-opt-cliprefprefix-00.txt>
     A Guide to Implementing = Stateless DHCPv6 Service
       = <draft-droms-dhcpv6-stateless-guide-00.txt>
     DSTM Options for = DHCPv6
       = <draft-ietf-dhc-dhcpv6-opt-dstm-01.txt>
     DSTM Ports Option for = DHCPv6
       = <draft-ietf-dhc-dhcpv6-opt-dstm-ports-01.txt>

* Complete or abandon work on DHCP extensions and = options that are
   currently work in progress:

     Failover protocol
       = <draft-ietf-dhc-failover-11.txt>
     The DHCP Client FQDN = Option
       = <draft-ietf-dhc-fqdn-option-04.txt>
     Resolution of DNS Name = Conflicts Among DHCP Clients
       = <draft-ietf-dhc-ddns-resolution-04.txt>
     DHCP Server MIB
       = <draft-ietf-dhc-server-mib-07.txt>
     Considerations for the use = of the Host Name option
       = <draft-ietf-dhc-host-option-considerations-01.txt>
     DHCP Lease Query
       = <draft-ietf-dhc-leasequery-04.txt>
     DHCP Options for Internet = Storage Name Service
       = <draft-ietf-dhc-isnsoption-03.txt>
     Dynamic Host Configuration = Protocol (DHCP) Server MIB
       = <draft-ietf-dhc-server-mib-07.txt>
     DHCP Option for Mobile IP = Mobility Agents
       = <draft-ietf-dhc-mipadvert-opt-00.txt>
     DHCP VPN Information = Option
       = <draft-ietf-dhc-vpn-option-02.txt>
     KDC Server Address = Sub-option
       = <draft-ietf-dhc-suboptions-kdc-serveraddress-00.txt>
     The Authentication = Suboption for the DHCP Relay Agent Option
       = <draft-ietf-dhc-auth-suboption-00.txt>
     Link Selection sub-option = for the Relay Agent Information Option
       = <draft-ietf-dhc-agent-subnet-selection-03.txt>
     VPN Identifier sub-option = for the Relay Agent Information Option
       = <draft-ietf-dhc-agent-vpn-id-02.txt>
     RADIUS Attributes = Sub-option for the DHCP Relay Agent Information Option
       = <draft-ietf-dhc-agentopt-radius-02.txt>
     DHCP Subscriber ID = Suboption for the DHCP Relay Agent Option
       = <draft-ietf-dhc-subscriber-id-00.txt>


_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg

------_=_NextPart_001_01C2D6A2.B2EC8A0C-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Feb 17 11:53:26 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25708; Mon, 17 Feb 2003 11:53:26 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1HGwVp06303; Mon, 17 Feb 2003 11:58:31 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1HGrZp06165 for ; Mon, 17 Feb 2003 11:53:35 -0500 Received: from rtp-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25560 for ; Mon, 17 Feb 2003 11:47:53 -0500 (EST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h1HGpdNh003497 for ; Mon, 17 Feb 2003 11:51:39 -0500 (EST) Received: from rdroms-w2k.cisco.com (rtp-vpn1-755.cisco.com [10.82.226.243]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id LAA06106 for ; Mon, 17 Feb 2003 11:51:38 -0500 (EST) Message-Id: <4.3.2.7.2.20030217114913.0393fe58@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 17 Feb 2003 11:51:33 -0500 To: dhcwg@ietf.org From: Ralph Droms Subject: RE: [dhcwg] Final draft of revised DHC WG charter In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Bernie - I agree about specific mention of DHCPv6 as you suggest. Regarding the milestones ... I don't have milestones from most Internet-Draft authors, yet. Rather than hold up the charter, I suggest we publish it as is and add the milestones as we get commitments from the authors. - Ralph At 10:40 AM 2/17/2003 -0600, Bernie Volz (EUD) wrote: >Ralph: > >This looks fine. > >My one comment would be that it would be great if we can put in something >about DHCPv6 in the first paragraph of the description, such as: > > The dhc working group (DHC WG) has developed DHCP for automated > allocation, configuration and management of IP addresses and TCP/IP > protocol stack parameters. DHCP is currently a "Draft Standard". The > base protocol is document in RFC2131 and RFC2132 for DHCPv4 and > RFCxxxx for DHCPv6. Additional options are documented in subsequent > RFCs. > >Perhaps by the time this charter is approved and published, we'll know >the RFC number (or perhaps the IESG can request this from IANA before >updating the official WG description). > >However, this isn't a big issue and I don't want to delay the update any >further just because of this!! > >Will you also publish the updated milestones? > >- Bernie > >-----Original Message----- >From: Ralph Droms [mailto:rdroms@cisco.com] >Sent: Sunday, February 16, 2003 11:46 AM >To: dhcwg@ietf.org >Subject: [dhcwg] Final draft of revised DHC WG charter > >Included below is a final draft of the revised DHC WG charter. This >changes to this draft are primarily editorial to for improved clarity and >readability. Please review and comment on this draft charter by Wed, >2/19. The IESG will review the charter on 2/20. Thanks... > >- Ralph > > >Dynamic Host Configuration (dhc) >-------------------------------- > > Charter > Last Modified: 2003--2-16 > > Current Status: Active Working Group > > Chair(s): > R. Droms > > Internet Area Director(s): > Thomas Narten > E. Nordmark > > Internet Area Advisor: > Thomas Narten > > Mailing Lists: > General Discussion:dhcwg@ietf.org > To > Subscribe: > http://www1.ietf.org/mailman/listinfo/dhcwg > > Archive: > http://www1.ietf.org/mailman/listinfo/dhcwg > > >Description of Working Group > >The dhc working group (DHC WG) has developed DHCP for automated >allocation, configuration and management of IP addresses and TCP/IP >protocol stack parameters. DHCP is currently a "Draft Standard". The >base protocol is document in RFC2131 and RFC2132. Additional options >are documented in subsequent RFCs. > >The DHC WG is responsible for reviewing (and sometimes developing) >DHCP options or other extensions (for both IPv4 and IPv6). The DHC WG >is expected to review all proposed extensions to DHCP to ensure that >they are consistent with the DHCP specification and other option >formats, that they do not duplicate existing mechanisms, etc. The DHC >WG will not (generally) be responsible for evaluating the semantic >content of proposed options. The DHC WG will not adopt new proposals >for extensions to DHCP as working group documents without first >coordinating with other relevant working groups and determining who >has the responsibility for reviewing the semantic content of an >option. > >The DHC WG has the following main objectives: > >* The DHC WG will address security in DHCP > > o Develop and document security requirements for DHCP. RFC 3118 > defines current security mechanisms for DHCPv4. Unfortunately, > RFC 3118 has neither been implemented nor deployed to date. > Specific issues to be considered include: > > - Improved key management and scalability > - Security for messages passed between relay agents and servers > - Threats of DoS attacks through FORCERENEW > - The increased usage of DHC on unsecure (e.g., wireless) and > public LANs > - The need for clients to be able to authenticate servers, without > simultaneusly requiring client authentication by the server. > > o Develop and document a roadmap of any new documents or protocols > needed to meet the security requirements for DHCP > >* Write an analysis of the DHCP specification, including RFC2131, > RFC2132 and other RFCs defining additional options, which identifies > ambiguities, contradictory specifications and other obstacles to > development of interoperable implementations. Recommend a process > for resolving identified problems and incorporating the resolutions > into the DHCP specification. > >* Complete or abandon work on DHCPv6 options that are currently work > in progress: > > IPv6 Prefix Options for DHCPv6 > > DNS Configuration options for DHCPv6 > > Load Balancing for DHCPv6 > > NIS Configuration Options for DHCPv6 > > Time Configuration Options for DHCPv6 > > Client Preferred Prefix option for DHCPv6 > > A Guide to Implementing Stateless DHCPv6 Service > > DSTM Options for DHCPv6 > > DSTM Ports Option for DHCPv6 > > >* Complete or abandon work on DHCP extensions and options that are > currently work in progress: > > Failover protocol > > The DHCP Client FQDN Option > > Resolution of DNS Name Conflicts Among DHCP Clients > > DHCP Server MIB > > Considerations for the use of the Host Name option > > DHCP Lease Query > > DHCP Options for Internet Storage Name Service > > Dynamic Host Configuration Protocol (DHCP) Server MIB > > DHCP Option for Mobile IP Mobility Agents > > DHCP VPN Information Option > > KDC Server Address Sub-option > > The Authentication Suboption for the DHCP Relay Agent Option > > Link Selection sub-option for the Relay Agent Information Option > > VPN Identifier sub-option for the Relay Agent Information Option > > RADIUS Attributes Sub-option for the DHCP Relay Agent Information > Option > > DHCP Subscriber ID Suboption for the DHCP Relay Agent Option > > >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www1.ietf.org/mailman/listinfo/dhcwg > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Feb 17 15:59:48 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01298; Mon, 17 Feb 2003 15:59:47 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1HL4fp22524; Mon, 17 Feb 2003 16:04:41 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1HL3kp22504 for ; Mon, 17 Feb 2003 16:03:46 -0500 Received: from imr1.ericy.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01279 for ; Mon, 17 Feb 2003 15:57:58 -0500 (EST) Received: from mr5.exu.ericsson.se (mr5u3.ericy.com [208.237.135.124]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id h1HL1kd23835; Mon, 17 Feb 2003 15:01:46 -0600 (CST) Received: from eamrcnt761.exu.ericsson.se (eamrcnt761.exu.ericsson.se [138.85.133.39]) by mr5.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id h1HL1k119770; Mon, 17 Feb 2003 15:01:46 -0600 (CST) Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2656.59) id ; Mon, 17 Feb 2003 15:01:45 -0600 Message-ID: From: "Bernie Volz (EUD)" To: "'Ralph Droms'" , dhcwg@ietf.org Subject: RE: [dhcwg] WG last call on draft-ietf-dhc-dhcpv6-opt-nisconfig-0 1.txt Date: Mon, 17 Feb 2003 14:59:54 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2D6C6.AFA694D6" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2D6C6.AFA694D6 Content-Type: text/plain; charset="iso-8859-1" I fully support the approval of this document for publication. However, I would recommend we review the following section: 8. Appearance of these option The NIS servers, NIS+ servers, NIS domain name and NIS+ domain name options MUST appear only in the following messages: Solicit, Advertise, Request, Confirm, Renew, Rebind, Information-Request, Reply. Based on earlier text, these options are for the server to convey information to clients and therefore perhaps text as follows is more appropriate: The NIS servers, NIS+ servers, NIS domain name and NIS+ domain name options MUST appear only in the Advertise and Reply messages. The option numbers for these options may appear in the Option Request Option [2] in Solicit, Request, Renew, Rebind, Information-Request, and Reconfigure messages. Or, we want a client to send these options in Request, Renew, Rebind to a server as well? In any case, there is little need for this option itself in Solicit and Confirm (based on the original text). And, some mention of use of the ORO option (at least in Reconfigure) may be appropriate? - Bernie -----Original Message----- From: Ralph Droms [mailto:rdroms@cisco.com] Sent: Wednesday, February 12, 2003 3:25 PM To: dhcwg@ietf.org Subject: [dhcwg] WG last call on draft-ietf-dhc-dhcpv6-opt-nisconfig-01.txt This message announces a WG last call on "NIS Configuration Options for DHCPv6" . The last call will conclude on Friday, 2/28. draft-ietf-dhc-dhcpv6-opt-nisconfig-01.txt specifies four DHCPv6 options for configuration information related to Network Information Service (NIS). This draft is available as http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-opt-nisconfig-01.txt - Ralph Droms _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg ------_=_NextPart_001_01C2D6C6.AFA694D6 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] WG last call on = draft-ietf-dhc-dhcpv6-opt-nisconfig-01.txt

I fully support the approval of this document for = publication.

However, I would recommend we review the following = section:

8. Appearance of these option

   The NIS servers, NIS+ servers, NIS = domain name and NIS+ domain name
   options MUST appear only in the = following messages: Solicit,
   Advertise, Request, Confirm, Renew, = Rebind, Information-Request,
   Reply.

Based on earlier text, these options are for the = server to convey information
to clients and therefore perhaps text as follows is = more appropriate:

   The NIS servers, NIS+ servers, NIS = domain name and NIS+ domain name
   options MUST appear only in the = Advertise and Reply messages. The
   option numbers for these options may = appear in the Option Request
   Option [2] in Solicit, Request, Renew, = Rebind, Information-Request,
   and Reconfigure messages.

Or, we want a client to send these options in = Request, Renew, Rebind to
a server as well?

In any case, there is little need for this option = itself in Solicit and
Confirm (based on the original text). And, some = mention of use of the
ORO option (at least in Reconfigure) may be = appropriate?

- Bernie

-----Original Message-----
From: Ralph Droms [mailto:rdroms@cisco.com]
Sent: Wednesday, February 12, 2003 3:25 PM
To: dhcwg@ietf.org
Subject: [dhcwg] WG last call on
draft-ietf-dhc-dhcpv6-opt-nisconfig-01.txt


This message announces a WG last call on "NIS = Configuration Options
for DHCPv6" = <draft-ietf-dhc-dhcpv6-opt-nisconfig-01.txt>.  The last = call
will conclude on Friday, 2/28.

draft-ietf-dhc-dhcpv6-opt-nisconfig-01.txt specifies = four DHCPv6 options
for configuration information related to Network = Information Service
(NIS).  This draft is available as
http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhc= pv6-opt-nisconfig-01.txt

- Ralph Droms


_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg

------_=_NextPart_001_01C2D6C6.AFA694D6-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Feb 17 16:08:53 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01495; Mon, 17 Feb 2003 16:08:53 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1HLE4p23551; Mon, 17 Feb 2003 16:14:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1HLDmp23533 for ; Mon, 17 Feb 2003 16:13:48 -0500 Received: from imr2.ericy.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01481 for ; Mon, 17 Feb 2003 16:08:01 -0500 (EST) Received: from mr5.exu.ericsson.se (mr5att.ericy.com [138.85.224.141]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id h1HLBmb23690; Mon, 17 Feb 2003 15:11:48 -0600 (CST) Received: from eamrcnt761.exu.ericsson.se (eamrcnt761.exu.ericsson.se [138.85.133.39]) by mr5.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id h1HLBmO23324; Mon, 17 Feb 2003 15:11:48 -0600 (CST) Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2656.59) id ; Mon, 17 Feb 2003 15:11:48 -0600 Message-ID: From: "Bernie Volz (EUD)" To: "'Ralph Droms'" , dhcwg@ietf.org Subject: RE: [dhcwg] WG last call on draft-ietf-dhc-dhcpv6-opt-timeconfig- 01.txt Date: Mon, 17 Feb 2003 15:10:02 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2D6C8.EF7A6798" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2D6C8.EF7A6798 Content-Type: text/plain; charset="iso-8859-1" I fully support publication of this document. There are a few minor items that could be addressed: For: Time Time has the same format as Offset, except that no leading ``-'' or ``+'' is permitted. The default is 02:00:00. should the description indicate that time is the time of the daylight savings time change? For: 6. Appearance of these option The NTP servers and IEEE 1003.1 POSIX Timezone options MUST appear only in the following messages: Solicit, Advertise, Request, Confirm, Renew, Rebind, Information-Request, Reply. I have the same issue as I did for http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-opt-nisconfig-01.txt. Please see my comments for that last call; these essentially apply to this document as well. Oh, (missed this in the nisconfig option as well), but the reference to the base DHCPv6 specification will need to be updated - hopefully to the RFC but at least to -28. - Bernie Volz -----Original Message----- From: Ralph Droms [mailto:rdroms@cisco.com] Sent: Wednesday, February 12, 2003 3:37 PM To: dhcwg@ietf.org Subject: [dhcwg] WG last call on draft-ietf-dhc-dhcpv6-opt-timeconfig-01.txt This message announces a WG last call on "Time Configuration Options for DHCPv6" . The last call will conclude on Friday, 2/28. draft-ietf-dhc-dhcpv6-opt-timeconfig-01.txt specifies describes the DHCPv6 options for time related configuration information: NTP Servers and IEEE 1003.1 POSIX Timezone specifier. This draft is available as http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-opt-timeconfig-01.txt - Ralph Droms _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg ------_=_NextPart_001_01C2D6C8.EF7A6798 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] WG last call on = draft-ietf-dhc-dhcpv6-opt-timeconfig-01.txt

I fully support publication of this document.

There are a few minor items that could be = addressed:

For:
      = Time     Time has the same format as Offset, except = that no
          &nb= sp;    leading ``-'' or ``+'' is permitted.  The = default is
          &nb= sp;    02:00:00.
should the description indicate that time is the = time of the daylight savings
time change?

For:

6. Appearance of these option

   The NTP servers and IEEE 1003.1 POSIX = Timezone options MUST appear
   only in the following messages: = Solicit, Advertise, Request,
   Confirm, Renew, Rebind, = Information-Request, Reply.

I have the same issue as I did for
http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhc= pv6-opt-nisconfig-01.txt.
Please see my comments for that last call; these = essentially apply to this
document as well.

Oh, (missed this in the nisconfig option as well), = but the reference to the
base DHCPv6 specification will need to be updated - = hopefully to the RFC but
at least to -28.

- Bernie Volz

-----Original Message-----
From: Ralph Droms [mailto:rdroms@cisco.com]
Sent: Wednesday, February 12, 2003 3:37 PM
To: dhcwg@ietf.org
Subject: [dhcwg] WG last call on
draft-ietf-dhc-dhcpv6-opt-timeconfig-01.txt


This message announces a WG last call on "Time = Configuration Options for
DHCPv6" = <draft-ietf-dhc-dhcpv6-opt-timeconfig-01.txt>. The last call = will
conclude on Friday, 2/28.

draft-ietf-dhc-dhcpv6-opt-timeconfig-01.txt specifies = describes the
DHCPv6 options for time related configuration = information: NTP Servers
and IEEE 1003.1 POSIX Timezone specifier.  This = draft is available as
http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhc= pv6-opt-timeconfig-01.txt

- Ralph Droms

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg

------_=_NextPart_001_01C2D6C8.EF7A6798-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Feb 18 07:35:29 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26588; Tue, 18 Feb 2003 07:35:29 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1ICemp23566; Tue, 18 Feb 2003 07:40:48 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1ICdKp23486 for ; Tue, 18 Feb 2003 07:39:20 -0500 Received: from palrel10.hp.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26524 for ; Tue, 18 Feb 2003 07:33:14 -0500 (EST) Received: from iconsrv5.india.hp.com (iconsrv5.india.hp.com [15.42.229.13]) by palrel10.hp.com (Postfix) with ESMTP id C33D71C01889; Tue, 18 Feb 2003 04:37:00 -0800 (PST) Received: from nt23056 (vijayak@nt23056.india.hp.com [15.42.230.56]) by iconsrv5.india.hp.com (8.9.3/8.9.3 SMKit7.02) with SMTP id SAA19463; Tue, 18 Feb 2003 18:06:23 +0530 (IST) Reply-To: From: "Vijayabhaskar A K" To: "'Bernie Volz (EUD)'" , "'Ralph Droms'" , Subject: RE: [dhcwg] WG last call on draft-ietf-dhc-dhcpv6-opt-nisconfig-01.txt Date: Tue, 18 Feb 2003 18:05:50 +0530 Message-ID: <002801c2d74a$4584ad70$38e62a0f@nt23056> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Importance: Normal Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Bernie, Thanks for your comments.... See my reply inline, prefixed by VJ. ~Vijay -----Original Message----- From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org]On Behalf Of Bernie Volz (EUD) Sent: Tuesday, February 18, 2003 2:30 AM To: 'Ralph Droms'; dhcwg@ietf.org Subject: RE: [dhcwg] WG last call on draft-ietf-dhc-dhcpv6-opt-nisconfig-01.txt I fully support the approval of this document for publication. However, I would recommend we review the following section: 8. Appearance of these option The NIS servers, NIS+ servers, NIS domain name and NIS+ domain name options MUST appear only in the following messages: Solicit, Advertise, Request, Confirm, Renew, Rebind, Information-Request, Reply. VJ> Basically, sending these options in messages originating from the VJ> client is for asking the server to provide these information. VJ> Its the alternative way of sending ORO with the option number for these options. VJ> We may want to make a decision here that these options can occur VJ> ONLY in messages originating from server and the client can VJ> indicate the server that it want any of these options by sending ONLY VJ> ORO option, because, client sending these options is of VJ> no interest in the server side, since, its not going to make VJ> any major decision based on the content of this option. VJ> But, it SHOULD be made consistent with ALL service addresses/parameters options. Based on earlier text, these options are for the server to convey information to clients and therefore perhaps text as follows is more appropriate: The NIS servers, NIS+ servers, NIS domain name and NIS+ domain name options MUST appear only in the Advertise and Reply messages. The option numbers for these options may appear in the Option Request Option [2] in Solicit, Request, Renew, Rebind, Information-Request, and Reconfigure messages. VJ> I will add. Or, we want a client to send these options in Request, Renew, Rebind to a server as well? In any case, there is little need for this option itself in Solicit and Confirm (based on the original text). And, some mention of use of the ORO option (at least in Reconfigure) may be appropriate? VJ> OK. I will add. - Bernie -----Original Message----- From: Ralph Droms [mailto:rdroms@cisco.com] Sent: Wednesday, February 12, 2003 3:25 PM To: dhcwg@ietf.org Subject: [dhcwg] WG last call on draft-ietf-dhc-dhcpv6-opt-nisconfig-01.txt This message announces a WG last call on "NIS Configuration Options for DHCPv6" . The last call will conclude on Friday, 2/28. draft-ietf-dhc-dhcpv6-opt-nisconfig-01.txt specifies four DHCPv6 options for configuration information related to Network Information Service (NIS). This draft is available as http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-opt-nisconfig-01.t xt - Ralph Droms _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Feb 18 09:47:06 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29068; Tue, 18 Feb 2003 09:47:06 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1IEqdp32265; Tue, 18 Feb 2003 09:52:39 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1IEpZp32227 for ; Tue, 18 Feb 2003 09:51:35 -0500 Received: from palrel10.hp.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29049 for ; Tue, 18 Feb 2003 09:45:26 -0500 (EST) Received: from iconsrv5.india.hp.com (iconsrv5.india.hp.com [15.42.229.13]) by palrel10.hp.com (Postfix) with ESMTP id D39591C01D5F; Tue, 18 Feb 2003 06:49:13 -0800 (PST) Received: from nt23056 (nt23056.india.hp.com [15.42.230.56]) by iconsrv5.india.hp.com (8.9.3/8.9.3 SMKit7.02) with SMTP id UAA28257; Tue, 18 Feb 2003 20:18:37 +0530 (IST) Reply-To: From: "Vijayabhaskar A K" To: "'Bernie Volz (EUD)'" , "'Ralph Droms'" , Subject: RE: [dhcwg] WG last call on draft-ietf-dhc-dhcpv6-opt-timeconfig-01.txt Date: Tue, 18 Feb 2003 20:18:04 +0530 Message-ID: <003001c2d75c$be92ccd0$38e62a0f@nt23056> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Importance: Normal Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Bernie, See my reply inline prefixed by VJ. ~Vijay -----Original Message----- From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org]On Behalf Of Bernie Volz (EUD) Sent: Tuesday, February 18, 2003 2:40 AM To: 'Ralph Droms'; dhcwg@ietf.org Subject: RE: [dhcwg] WG last call on draft-ietf-dhc-dhcpv6-opt-timeconfig-01.txt I fully support publication of this document. There are a few minor items that could be addressed: For: Time Time has the same format as Offset, except that no leading ``-'' or ``+'' is permitted. The default is 02:00:00. should the description indicate that time is the time of the daylight savings time change? VJ> "Start" and "End" are the fields which suggest when to move to daylight VJ> savings and when to come back respectively. "Time" is just a representation VJ> of hh:mm:ss. For: 6. Appearance of these option The NTP servers and IEEE 1003.1 POSIX Timezone options MUST appear only in the following messages: Solicit, Advertise, Request, Confirm, Renew, Rebind, Information-Request, Reply. I have the same issue as I did for http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-opt-nisconfig-01.t xt. Please see my comments for that last call; these essentially apply to this document as well. VJ> OK. I will update. Oh, (missed this in the nisconfig option as well), but the reference to the base DHCPv6 specification will need to be updated - hopefully to the RFC but at least to -28. VJ> Thanks for the comments. I will update it. BTW, do you know the RFC number VJ> assigned for DHCPv6? - Bernie Volz -----Original Message----- From: Ralph Droms [mailto:rdroms@cisco.com] Sent: Wednesday, February 12, 2003 3:37 PM To: dhcwg@ietf.org Subject: [dhcwg] WG last call on draft-ietf-dhc-dhcpv6-opt-timeconfig-01.txt This message announces a WG last call on "Time Configuration Options for DHCPv6" . The last call will conclude on Friday, 2/28. draft-ietf-dhc-dhcpv6-opt-timeconfig-01.txt specifies describes the DHCPv6 options for time related configuration information: NTP Servers and IEEE 1003.1 POSIX Timezone specifier. This draft is available as http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-opt-timeconfig-01. txt - Ralph Droms _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Feb 18 10:23:47 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29879; Tue, 18 Feb 2003 10:23:47 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1IFTLp02315; Tue, 18 Feb 2003 10:29:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1IFSbp02259 for ; Tue, 18 Feb 2003 10:28:37 -0500 Received: from imr1.ericy.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29853 for ; Tue, 18 Feb 2003 10:22:26 -0500 (EST) Received: from mr5.exu.ericsson.se (mr5u3.ericy.com [208.237.135.124]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id h1IFQFd18189; Tue, 18 Feb 2003 09:26:15 -0600 (CST) Received: from eamrcnt761.exu.ericsson.se (eamrcnt761.exu.ericsson.se [138.85.133.39]) by mr5.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id h1IFQEg02062; Tue, 18 Feb 2003 09:26:15 -0600 (CST) Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2656.59) id ; Tue, 18 Feb 2003 09:26:14 -0600 Message-ID: From: "Bernie Volz (EUD)" To: "'vijayak@india.hp.com'" , "'Ralph Droms'" , dhcwg@ietf.org Subject: RE: [dhcwg] WG last call on draft-ietf-dhc-dhcpv6-opt-nisconfig-0 1.txt Date: Tue, 18 Feb 2003 09:24:32 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2D761.A0C0F056" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2D761.A0C0F056 Content-Type: text/plain; charset="iso-8859-1" Personally, I would like to see clients NOT send options to the server but instead just send an ORO option. I see little value in sending the NIS server info to the server - it just increases the packet size and work a server must do to ignore these. ORO is the mechanism to request that a server send an option; not sending the option to the server. For DHCPv4, is there any server that checks options sent by the client to make sure that what it send is valid? What would a server do if it isn't valid - just send the correct value? So, it seems to me ORO is the way to go. Now, of course there are options that must be sent by the client, such as IA options since they carry information from the client to the server (such as the IAID). I don't think we need to PROHIBIT a client from sending the option; but we should not encourage it. A server that receives "unknown" options should just ignore them. - Bernie -----Original Message----- From: Vijayabhaskar A K [mailto:vijayak@india.hp.com] Sent: Tuesday, February 18, 2003 7:36 AM To: 'Bernie Volz (EUD)'; 'Ralph Droms'; dhcwg@ietf.org Subject: RE: [dhcwg] WG last call on draft-ietf-dhc-dhcpv6-opt-nisconfig-01.txt Bernie, Thanks for your comments.... See my reply inline, prefixed by VJ. ~Vijay -----Original Message----- From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org]On Behalf Of Bernie Volz (EUD) Sent: Tuesday, February 18, 2003 2:30 AM To: 'Ralph Droms'; dhcwg@ietf.org Subject: RE: [dhcwg] WG last call on draft-ietf-dhc-dhcpv6-opt-nisconfig-01.txt I fully support the approval of this document for publication. However, I would recommend we review the following section: 8. Appearance of these option The NIS servers, NIS+ servers, NIS domain name and NIS+ domain name options MUST appear only in the following messages: Solicit, Advertise, Request, Confirm, Renew, Rebind, Information-Request, Reply. VJ> Basically, sending these options in messages originating from the VJ> client is for asking the server to provide these information. VJ> Its the alternative way of sending ORO with the option number for these options. VJ> We may want to make a decision here that these options can occur VJ> ONLY in messages originating from server and the client can VJ> indicate the server that it want any of these options by sending ONLY VJ> ORO option, because, client sending these options is of VJ> no interest in the server side, since, its not going to make VJ> any major decision based on the content of this option. VJ> But, it SHOULD be made consistent with ALL service addresses/parameters options. Based on earlier text, these options are for the server to convey information to clients and therefore perhaps text as follows is more appropriate: The NIS servers, NIS+ servers, NIS domain name and NIS+ domain name options MUST appear only in the Advertise and Reply messages. The option numbers for these options may appear in the Option Request Option [2] in Solicit, Request, Renew, Rebind, Information-Request, and Reconfigure messages. VJ> I will add. Or, we want a client to send these options in Request, Renew, Rebind to a server as well? In any case, there is little need for this option itself in Solicit and Confirm (based on the original text). And, some mention of use of the ORO option (at least in Reconfigure) may be appropriate? VJ> OK. I will add. - Bernie -----Original Message----- From: Ralph Droms [mailto:rdroms@cisco.com] Sent: Wednesday, February 12, 2003 3:25 PM To: dhcwg@ietf.org Subject: [dhcwg] WG last call on draft-ietf-dhc-dhcpv6-opt-nisconfig-01.txt This message announces a WG last call on "NIS Configuration Options for DHCPv6" . The last call will conclude on Friday, 2/28. draft-ietf-dhc-dhcpv6-opt-nisconfig-01.txt specifies four DHCPv6 options for configuration information related to Network Information Service (NIS). This draft is available as http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-opt-nisconfig-01.t xt - Ralph Droms _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg ------_=_NextPart_001_01C2D761.A0C0F056 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] WG last call on = draft-ietf-dhc-dhcpv6-opt-nisconfig-01.txt

Personally, I would like to see clients NOT send = options to the
server but instead just send an ORO option. I see = little value in
sending the NIS server info to the server - it just = increases the
packet size and work a server must do to ignore = these. ORO is the
mechanism to request that a server send an option; = not sending the
option to the server.

For DHCPv4, is there any server that checks options = sent by the
client to make sure that what it send is valid? What = would a server
do if it isn't valid - just send the correct value? = So, it seems to
me ORO is the way to go. Now, of course there are = options that must
be sent by the client, such as IA options since they = carry information
from the client to the server (such as the = IAID).

I don't think we need to PROHIBIT a client from = sending the option;
but we should not encourage it. A server that = receives "unknown"
options should just ignore them.

- Bernie

-----Original Message-----
From: Vijayabhaskar A K [mailto:vijayak@india.hp.com]
Sent: Tuesday, February 18, 2003 7:36 AM
To: 'Bernie Volz (EUD)'; 'Ralph Droms'; = dhcwg@ietf.org
Subject: RE: [dhcwg] WG last call on
draft-ietf-dhc-dhcpv6-opt-nisconfig-01.txt


Bernie,
Thanks for your comments....
See my reply inline, prefixed by VJ.
~Vijay

-----Original Message-----
From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org]On = Behalf Of Bernie
Volz (EUD)
Sent: Tuesday, February 18, 2003 2:30 AM
To: 'Ralph Droms'; dhcwg@ietf.org
Subject: RE: [dhcwg] WG last call on
draft-ietf-dhc-dhcpv6-opt-nisconfig-01.txt


I fully support the approval of this document for = publication.
However, I would recommend we review the following = section:
8. Appearance of these option
   The NIS servers, NIS+ servers, NIS = domain name and NIS+ domain name
   options MUST appear only in the = following messages: Solicit,
   Advertise, Request, Confirm, Renew, = Rebind, Information-Request,
   Reply.

VJ> Basically, sending these options in messages = originating from the
VJ> client is for asking the server to provide = these information.
VJ> Its the alternative way of sending ORO with = the option number for these
options.
VJ> We may want to make a decision here that = these options can occur
VJ> ONLY in messages originating from server and = the client can
VJ> indicate the server that it want any of these = options by sending ONLY
VJ> ORO option, because, client sending these = options is of
VJ> no interest in the server side, since, its = not going to make
VJ> any major decision based on the content of = this option.
VJ> But, it SHOULD be made consistent with ALL = service addresses/parameters
options.

Based on earlier text, these options are for the = server to convey
information
to clients and therefore perhaps text as follows is = more appropriate:
   The NIS servers, NIS+ servers, NIS = domain name and NIS+ domain name
   options MUST appear only in the = Advertise and Reply messages. The
   option numbers for these options may = appear in the Option Request
   Option [2] in Solicit, Request, Renew, = Rebind, Information-Request,
   and Reconfigure messages.

VJ> I will add.

Or, we want a client to send these options in = Request, Renew, Rebind to
a server as well?

In any case, there is little need for this option = itself in Solicit and
Confirm (based on the original text). And, some = mention of use of the
ORO option (at least in Reconfigure) may be = appropriate?

VJ> OK. I will add.

- Bernie
-----Original Message-----
From: Ralph Droms [mailto:rdroms@cisco.com]
Sent: Wednesday, February 12, 2003 3:25 PM
To: dhcwg@ietf.org
Subject: [dhcwg] WG last call on
draft-ietf-dhc-dhcpv6-opt-nisconfig-01.txt


This message announces a WG last call on "NIS = Configuration Options
for DHCPv6" = <draft-ietf-dhc-dhcpv6-opt-nisconfig-01.txt>.  The last = call
will conclude on Friday, 2/28.
draft-ietf-dhc-dhcpv6-opt-nisconfig-01.txt specifies = four DHCPv6 options
for configuration information related to Network = Information Service
(NIS).  This draft is available as
http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhc= pv6-opt-nisconfig-01.t
xt
- Ralph Droms


_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg

------_=_NextPart_001_01C2D761.A0C0F056-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Feb 19 06:43:42 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19408; Wed, 19 Feb 2003 06:43:42 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1JBkHp00817; Wed, 19 Feb 2003 06:46:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1JBgcp00682 for ; Wed, 19 Feb 2003 06:42:38 -0500 Received: from ratree.psu.ac.th (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19236 for ; Wed, 19 Feb 2003 06:36:03 -0500 (EST) Received: from delta.cs.mu.OZ.AU ([172.30.0.189]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h1JBdid02923 for ; Wed, 19 Feb 2003 18:39:44 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h1JBZBK05987 for ; Wed, 19 Feb 2003 18:35:12 +0700 (ICT) From: Robert Elz To: dhcwg@ietf.org Subject: Re: [dhcwg] WG last call on draft-ietf-dhc-dhcpv6-opt-timeconfig-01.txt In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 19 Feb 2003 18:35:11 +0700 Message-ID: <5985.1045654511@munnari.OZ.AU> Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , There are a few issues in this doc that should be attended to. I suspect that most of them are really issues with the posix timezone format, but it should still be possible to clear things up in this doc so it is complete on its own (where possible, keeping it compatible with posix is, I suppose, a good idea). The NTP part is fine - though the security considerations should probably also note that time accuracy can be crucial to some security algorithms (being able to manipulate time can allow expired certificates to gain a new life, etc...) and so systems with any particular security requirements should take special care. That is, the "time critical applications" might be security applications, which makes this of special concern. Should it actually say SNTP instead of NTP, since that's the RFC that is referenced? It would be nice if the timezone option could also carry an ado type timezone specifier (as used by almost all systems that actually care about dealing with time zone representation). That's the name of one of the defined timezone specifications for the world, which conveys MUCH more information than a posix timezone string can possibly convey. I suspect that all that's needed to make this work is to make the (first) Offset optional. That is, if there's no offset, then the name is treated as an index into the timezone database (if it exists) - on most systems, this means as a file name (relative to some system dependent directory) and all the other data are obtained from there. Systems which can't use this form should just be sent a standard posix string, of course. The description of the offset after Dst doesn't indicate whether that offset is an offset from UTC or from local standard time. The text ... If no Offset follows Dst, then Dst is assumed to be one hour ahead of standard time suggests that it is an offset from standard time (or can certainly be read that way), but the example that includes EST5EDT4 suggests that it is an offset from UTC (which I believe is correct). This should be made clear. The format "Mm.n.d" is allowed to allow (simplistic) rules for daylight saving to be encoded (simplistic as there's no way to say "second last Sunday" and various other possibilities - but that's a posix limitation I expect). But ... Mm.n.d The ``d''th day, (0 <= d <= 6) of week doesn't give a clue as to which digits correspond to which days. That is, is the first (0th) dat of the week Sunday, Monday, or some other day? This should be clarified. For the example (eastern US, a pretty boring timezone to have chosen - except for the issues of just what it includes, which isn't relevant here, the meaning of the string should explained in more detail. That is, the 116th day is some particular date - say which one (then people can see how the calculation happened). Same for the 298th day. The "at 2am" should be explicit (here as well as elsewhere where it is stated) that this means "local clock time" (ie: DST starts at 02:00 standard time, and ends at 02:00 daylight saving time). kre _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Feb 19 10:28:10 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28815; Wed, 19 Feb 2003 10:28:10 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1JFXjp19135; Wed, 19 Feb 2003 10:33:45 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1JFWBp19025 for ; Wed, 19 Feb 2003 10:32:11 -0500 Received: from atlrel6.hp.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28658 for ; Wed, 19 Feb 2003 10:25:30 -0500 (EST) Received: from iconsrv5.india.hp.com (iconsrv5.india.hp.com [15.42.229.13]) by atlrel6.hp.com (Postfix) with ESMTP id 14DF61C0009F; Wed, 19 Feb 2003 10:29:19 -0500 (EST) Received: from nt23056 (vijayak@nt23056.india.hp.com [15.42.230.56]) by iconsrv5.india.hp.com (8.9.3/8.9.3 SMKit7.02) with SMTP id UAA22639; Wed, 19 Feb 2003 20:58:42 +0530 (IST) Reply-To: From: "Vijayabhaskar A K" To: "'Robert Elz'" , Subject: RE: [dhcwg] WG last call on draft-ietf-dhc-dhcpv6-opt-timeconfig-01.txt Date: Wed, 19 Feb 2003 20:58:07 +0530 Message-ID: <002401c2d82b$81652cc0$38e62a0f@nt23056> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <5985.1045654511@munnari.OZ.AU> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Importance: Normal Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Robert, Thanks for your thorough review. See my reply inline... ~Vijay > -----Original Message----- > From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org]On Behalf Of > Robert Elz > Sent: Wednesday, February 19, 2003 5:05 PM > To: dhcwg@ietf.org > Subject: Re: [dhcwg] WG last call on > draft-ietf-dhc-dhcpv6-opt-timeconfig-01.txt > > > There are a few issues in this doc that should be attended to. > I suspect that most of them are really issues with the posix > timezone format, but it should still be possible to clear things > up in this doc so it is complete on its own (where possible, keeping > it compatible with posix is, I suppose, a good idea). > > The NTP part is fine - though the security considerations > should probably > also note that time accuracy can be crucial to some security > algorithms > (being able to manipulate time can allow expired certificates > to gain a > new life, etc...) and so systems with any particular security > requirements > should take special care. That is, the "time critical > applications" might > be security applications, which makes this of special concern. Agreed. I will add note on "time critical security applications". > > Should it actually say SNTP instead of NTP, since that's the > RFC that is > referenced? As NTP is the generic term referencing both NTP and SNTP, i have made it as NTP. > > > It would be nice if the timezone option could also carry an ado type > timezone specifier (as used by almost all systems that actually care > about dealing with time zone representation). That's the > name of one of > the defined timezone specifications for the world, which conveys MUCH > more information than a posix timezone string can possibly convey. > > I suspect that all that's needed to make this work is to make the > (first) Offset optional. That is, if there's no offset, then the > name is treated as an index into the timezone database (if it exists) > - on most systems, this means as a file name (relative to some system > dependent directory) and all the other data are obtained from there. > > Systems which can't use this form should just be sent a standard posix > string, of course. Please note that this information is sent by the server to the clients. DHCPv6 server will serve a network with varieties of systems. If it sends Time zone as you specified above, then the systems which can't use it in this form may be in trouble. That's why the time zone representation in kept sync with IEEE specification. > > > The description of the offset after Dst doesn't indicate whether that > offset is an offset from UTC or from local standard time. The Offset is always relative to UTC. Offset Indicates the value one must add to local time to arrive at UTC, of the form: [+|-]hh[:mm[:ss]]. > > The text ... > > If no Offset follows Dst, then > Dst is assumed to be one hour ahead of standard time > > suggests that it is an offset from standard time (or can certainly > be read that way), Yes. You are correct. Its offset from standard time, as it clearly says. > but the example that includes > > EST5EDT4 > > suggests that it is an offset from UTC (which I believe is correct). > This should be made clear. The example is also correct, since "offset" is specified, its relative to UTC. > > > The format "Mm.n.d" is allowed to allow (simplistic) rules > for daylight > saving to be encoded (simplistic as there's no way to say > "second last Sunday" > and various other possibilities - but that's a posix > limitation I expect). > > But ... > > Mm.n.d The ``d''th day, (0 <= d <= 6) of week > > doesn't give a clue as to which digits correspond to which > days. That > is, is the first (0th) dat of the week Sunday, Monday, or > some other day? > This should be clarified. Agreed. I add a note on this. Day 0 is Sunday. > > > For the example (eastern US, a pretty boring time zone to have > chosen - except > for the issues of just what it includes, which isn't relevant > here, the meaning > of the string should explained in more detail. > > That is, the 116th day is some particular date - say which > one (then people > can see how the calculation happened). Same for the 298th > day. The "at 2am" > should be explicit (here as well as elsewhere where it is > stated) that this > means "local clock time" (ie: DST starts at 02:00 standard > time, and ends > at 02:00 daylight saving time). Agreed. I will add that. EST5EDT4,116/02:00:00,298/02:00:00 This says that: The standard time zone is in 5 hours lag to UTC. The DST is 4 hours lag to UTC. Day light savings starts at April 26 02:00 AM and ends at October 25 02:00 AM Thanks once again for your comments > > kre > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Feb 19 10:42:16 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29273; Wed, 19 Feb 2003 10:42:16 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1JFm4p20507; Wed, 19 Feb 2003 10:48:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1JFhQp20411 for ; Wed, 19 Feb 2003 10:43:26 -0500 Received: from palrel12.hp.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29070 for ; Wed, 19 Feb 2003 10:36:44 -0500 (EST) Received: from iconsrv5.india.hp.com (iconsrv5.india.hp.com [15.42.229.13]) by palrel12.hp.com (Postfix) with ESMTP id 216441C01483; Wed, 19 Feb 2003 07:40:30 -0800 (PST) Received: from nt23056 (nt23056.india.hp.com [15.42.230.56]) by iconsrv5.india.hp.com (8.9.3/8.9.3 SMKit7.02) with SMTP id VAA23241; Wed, 19 Feb 2003 21:09:49 +0530 (IST) Reply-To: From: "Vijayabhaskar A K" To: "'Bernie Volz (EUD)'" , "'Ralph Droms'" , Subject: RE: [dhcwg] WG last call on draft-ietf-dhc-dhcpv6-opt-nisconfig-01.txt Date: Wed, 19 Feb 2003 21:09:14 +0530 Message-ID: <002501c2d82d$0ec2ca90$38e62a0f@nt23056> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0026_01C2D85B.287B0690" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Importance: Normal Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_0026_01C2D85B.287B0690 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit RE: [dhcwg] WG last call on draft-ietf-dhc-dhcpv6-opt-nisconfig-01.txtBernie, I agree that client sending this option is no useful to server, we can stick to ORO. In the case if we decide not to prohibit client sending these options, if the client sends these options, (i) do the server need to reply back with the correct values of these options? (or) (ii) make the server reply only if the option number is filled in ORO option, thus just ignoring the client sending these options. I beleive, (i) is better. If we decide (ii) then there is no meaning in not prohibiting client to send these options. Though, there is no harm in prohibiting the clients to send these options, because, it can anyway get the values using ORO. ~Vijay -----Original Message----- From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org]On Behalf Of Bernie Volz (EUD) Sent: Tuesday, February 18, 2003 8:55 PM To: 'vijayak@india.hp.com'; 'Ralph Droms'; dhcwg@ietf.org Subject: RE: [dhcwg] WG last call on draft-ietf-dhc-dhcpv6-opt-nisconfig-01.txt Personally, I would like to see clients NOT send options to the server but instead just send an ORO option. I see little value in sending the NIS server info to the server - it just increases the packet size and work a server must do to ignore these. ORO is the mechanism to request that a server send an option; not sending the option to the server. For DHCPv4, is there any server that checks options sent by the client to make sure that what it send is valid? What would a server do if it isn't valid - just send the correct value? So, it seems to me ORO is the way to go. Now, of course there are options that must be sent by the client, such as IA options since they carry information from the client to the server (such as the IAID). I don't think we need to PROHIBIT a client from sending the option; but we should not encourage it. A server that receives "unknown" options should just ignore them. - Bernie -----Original Message----- From: Vijayabhaskar A K [mailto:vijayak@india.hp.com] Sent: Tuesday, February 18, 2003 7:36 AM To: 'Bernie Volz (EUD)'; 'Ralph Droms'; dhcwg@ietf.org Subject: RE: [dhcwg] WG last call on draft-ietf-dhc-dhcpv6-opt-nisconfig-01.txt Bernie, Thanks for your comments.... See my reply inline, prefixed by VJ. ~Vijay -----Original Message----- From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org]On Behalf Of Bernie Volz (EUD) Sent: Tuesday, February 18, 2003 2:30 AM To: 'Ralph Droms'; dhcwg@ietf.org Subject: RE: [dhcwg] WG last call on draft-ietf-dhc-dhcpv6-opt-nisconfig-01.txt I fully support the approval of this document for publication. However, I would recommend we review the following section: 8. Appearance of these option The NIS servers, NIS+ servers, NIS domain name and NIS+ domain name options MUST appear only in the following messages: Solicit, Advertise, Request, Confirm, Renew, Rebind, Information-Request, Reply. VJ> Basically, sending these options in messages originating from the VJ> client is for asking the server to provide these information. VJ> Its the alternative way of sending ORO with the option number for these options. VJ> We may want to make a decision here that these options can occur VJ> ONLY in messages originating from server and the client can VJ> indicate the server that it want any of these options by sending ONLY VJ> ORO option, because, client sending these options is of VJ> no interest in the server side, since, its not going to make VJ> any major decision based on the content of this option. VJ> But, it SHOULD be made consistent with ALL service addresses/parameters options. Based on earlier text, these options are for the server to convey information to clients and therefore perhaps text as follows is more appropriate: The NIS servers, NIS+ servers, NIS domain name and NIS+ domain name options MUST appear only in the Advertise and Reply messages. The option numbers for these options may appear in the Option Request Option [2] in Solicit, Request, Renew, Rebind, Information-Request, and Reconfigure messages. VJ> I will add. Or, we want a client to send these options in Request, Renew, Rebind to a server as well? In any case, there is little need for this option itself in Solicit and Confirm (based on the original text). And, some mention of use of the ORO option (at least in Reconfigure) may be appropriate? VJ> OK. I will add. - Bernie -----Original Message----- From: Ralph Droms [mailto:rdroms@cisco.com] Sent: Wednesday, February 12, 2003 3:25 PM To: dhcwg@ietf.org Subject: [dhcwg] WG last call on draft-ietf-dhc-dhcpv6-opt-nisconfig-01.txt This message announces a WG last call on "NIS Configuration Options for DHCPv6" . The last call will conclude on Friday, 2/28. draft-ietf-dhc-dhcpv6-opt-nisconfig-01.txt specifies four DHCPv6 options for configuration information related to Network Information Service (NIS). This draft is available as http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-opt-nisconfig-01.t xt - Ralph Droms _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg ------=_NextPart_000_0026_01C2D85B.287B0690 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] WG last call on = draft-ietf-dhc-dhcpv6-opt-nisconfig-01.txt
Bernie,
I=20 agree that client sending this option is no useful to=20 server,
we can=20 stick to ORO. In the case if we decide not to
prohibit client sending these=20 options,
if the=20 client sends these options,
(i) do=20 the server need
to=20 reply back with the correct values of these options?
(or)
(ii)=20 make the server reply only if the option number is
filled=20 in ORO option, thus just ignoring the client sending
these=20 options.
I=20 beleive, (i) is better.
If we=20 decide (ii) then there is no meaning in not prohibiting =
client=20 to send these options. Though, there is no harm
in=20 prohibiting the clients to send these options, because, =
it can=20 anyway get the values using ORO.
~Vijay
-----Original Message-----
From: = dhcwg-admin@ietf.org=20 [mailto:dhcwg-admin@ietf.org]On Behalf Of Bernie Volz=20 (EUD)
Sent: Tuesday, February 18, 2003 8:55 PM
To: = 'vijayak@india.hp.com'; 'Ralph Droms'; = dhcwg@ietf.org
Subject: RE:=20 [dhcwg] WG last call on=20 draft-ietf-dhc-dhcpv6-opt-nisconfig-01.txt

Personally, I would like to see clients NOT send = options to=20 the
server but instead just send an ORO = option. I see=20 little value in
sending the NIS server info = to the=20 server - it just increases the
packet size = and work a=20 server must do to ignore these. ORO is the
mechanism=20 to request that a server send an option; not sending the =
option to the server.

For DHCPv4, is there any server that checks options = sent by=20 the
client to make sure that what it send is = valid?=20 What would a server
do if it isn't valid - = just send=20 the correct value? So, it seems to
me ORO is = the way=20 to go. Now, of course there are options that must
be=20 sent by the client, such as IA options since they carry = information=20
from the client to the server (such as the = IAID).

I don't think we need to PROHIBIT a client from = sending the=20 option;
but we should not encourage it. A = server that=20 receives "unknown"
options should just = ignore=20 them.

- Bernie

-----Original Message-----
From:=20 Vijayabhaskar A K [mailto:vijayak@india.hp.com]=20
Sent: Tuesday, February 18, 2003 7:36 AM =
To: 'Bernie Volz (EUD)'; 'Ralph Droms'; dhcwg@ietf.org =
Subject: RE: [dhcwg] WG last call on
draft-ietf-dhc-dhcpv6-opt-nisconfig-01.txt


Bernie,
Thanks for your=20 comments....
See my reply inline, prefixed = by=20 VJ.
~Vijay

-----Original Message-----
From:=20 dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org]On = Behalf=20 Of Bernie
Volz (EUD)
Sent:=20 Tuesday, February 18, 2003 2:30 AM
To: = 'Ralph Droms';=20 dhcwg@ietf.org
Subject: RE: [dhcwg] WG last = call=20 on
draft-ietf-dhc-dhcpv6-opt-nisconfig-01.txt=20


I fully support the approval of this document for=20 publication.
However, I would recommend we = review the=20 following section:
8. Appearance of these=20 option
   The NIS servers, NIS+ = servers, NIS=20 domain name and NIS+ domain name
   options=20 MUST appear only in the following messages: Solicit,
   Advertise, Request, Confirm, Renew, Rebind,=20 Information-Request,
   = Reply.

VJ> Basically, sending these options in messages=20 originating from the
VJ> client is for = asking the=20 server to provide these information.
VJ> = Its the=20 alternative way of sending ORO with the option number for these =
options.
VJ> We may = want to make a=20 decision here that these options can occur
VJ> ONLY=20 in messages originating from server and the client can =
VJ> indicate the server that it want any of these options = by sending=20 ONLY
VJ> ORO option, because, client = sending these=20 options is of
VJ> no interest in the = server side,=20 since, its not going to make
VJ> any = major decision=20 based on the content of this option.
VJ> = But, it=20 SHOULD be made consistent with ALL service addresses/parameters =
options.

Based on earlier text, these options are for the = server to=20 convey
information
to clients=20 and therefore perhaps text as follows is more appropriate: =
   The NIS servers, NIS+ servers, NIS domain name = and NIS+=20 domain name
   options MUST appear = only in=20 the Advertise and Reply messages. The
  =20 option numbers for these options may appear in the Option = Request=20
   Option [2] in Solicit, Request, Renew, = Rebind,=20 Information-Request,
   and = Reconfigure=20 messages.

VJ> I will add.

Or, we want a client to send these options in = Request, Renew,=20 Rebind to
a server as well?

In any case, there is little need for this option = itself in=20 Solicit and
Confirm (based on the original = text). And,=20 some mention of use of the
ORO option (at = least in=20 Reconfigure) may be appropriate?

VJ> OK. I will add.

- Bernie
-----Original=20 Message-----
From: Ralph Droms [mailto:rdroms@cisco.com] =
Sent: Wednesday, February 12, 2003 3:25 PM
To:=20 dhcwg@ietf.org
Subject: [dhcwg] WG last call = on=20
draft-ietf-dhc-dhcpv6-opt-nisconfig-01.txt =


This message announces a WG last call on "NIS = Configuration=20 Options
for DHCPv6"=20 <draft-ietf-dhc-dhcpv6-opt-nisconfig-01.txt>.  The last = call=20
will conclude on Friday, 2/28.
draft-ietf-dhc-dhcpv6-opt-nisconfig-01.txt specifies four = DHCPv6=20 options
for configuration information = related to=20 Network Information Service
(NIS).  = This draft is=20 available as
http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-op= t-nisconfig-01.t=20
xt
- Ralph Droms =


_______________________________________________=20
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.o= rg/mailman/listinfo/dhcwg=20

------=_NextPart_000_0026_01C2D85B.287B0690-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Feb 19 12:08:38 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01685; Wed, 19 Feb 2003 12:08:37 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1JHDCp27391; Wed, 19 Feb 2003 12:13:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1JH4jp26082 for ; Wed, 19 Feb 2003 12:04:45 -0500 Received: from imr2.ericy.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01396 for ; Wed, 19 Feb 2003 11:58:01 -0500 (EST) Received: from mr5.exu.ericsson.se (mr5att.ericy.com [138.85.224.141]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id h1JH1pb06971; Wed, 19 Feb 2003 11:01:51 -0600 (CST) Received: from eamrcnt761.exu.ericsson.se (eamrcnt761.exu.ericsson.se [138.85.133.39]) by mr5.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id h1JH1oi17161; Wed, 19 Feb 2003 11:01:50 -0600 (CST) Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2656.59) id ; Wed, 19 Feb 2003 11:01:50 -0600 Message-ID: From: "Bernie Volz (EUD)" To: "'vijayak@india.hp.com'" , "'Ralph Droms'" , dhcwg@ietf.org Subject: RE: [dhcwg] WG last call on draft-ietf-dhc-dhcpv6-opt-nisconfig-0 1.txt Date: Wed, 19 Feb 2003 11:00:11 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2D838.021A55E6" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2D838.021A55E6 Content-Type: text/plain; charset="iso-8859-1" I would prefer (ii). A server should not be required to also go through a packet to see what options the client sent to send the "correct" information. The ORO mechanism is the way for a client to request certain options and it should be the only mechanism. It simplifies implementations. If a client sends an option (such as NIS server info), the server should just ignore it. If that option is in the ORO, the server should send back the configured information to the client. NOTE: The above applies only to those options which are essentially server to client configuration options. - Bernie -----Original Message----- From: Vijayabhaskar A K [mailto:vijayak@india.hp.com] Sent: Wednesday, February 19, 2003 10:39 AM To: 'Bernie Volz (EUD)'; 'Ralph Droms'; dhcwg@ietf.org Subject: RE: [dhcwg] WG last call on draft-ietf-dhc-dhcpv6-opt-nisconfig-01.txt Bernie, I agree that client sending this option is no useful to server, we can stick to ORO. In the case if we decide not to prohibit client sending these options, if the client sends these options, (i) do the server need to reply back with the correct values of these options? (or) (ii) make the server reply only if the option number is filled in ORO option, thus just ignoring the client sending these options. I beleive, (i) is better. If we decide (ii) then there is no meaning in not prohibiting client to send these options. Though, there is no harm in prohibiting the clients to send these options, because, it can anyway get the values using ORO. ~Vijay -----Original Message----- From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org]On Behalf Of Bernie Volz (EUD) Sent: Tuesday, February 18, 2003 8:55 PM To: 'vijayak@india.hp.com'; 'Ralph Droms'; dhcwg@ietf.org Subject: RE: [dhcwg] WG last call on draft-ietf-dhc-dhcpv6-opt-nisconfig-01.txt Personally, I would like to see clients NOT send options to the server but instead just send an ORO option. I see little value in sending the NIS server info to the server - it just increases the packet size and work a server must do to ignore these. ORO is the mechanism to request that a server send an option; not sending the option to the server. For DHCPv4, is there any server that checks options sent by the client to make sure that what it send is valid? What would a server do if it isn't valid - just send the correct value? So, it seems to me ORO is the way to go. Now, of course there are options that must be sent by the client, such as IA options since they carry information from the client to the server (such as the IAID). I don't think we need to PROHIBIT a client from sending the option; but we should not encourage it. A server that receives "unknown" options should just ignore them. - Bernie -----Original Message----- From: Vijayabhaskar A K [ mailto:vijayak@india.hp.com ] Sent: Tuesday, February 18, 2003 7:36 AM To: 'Bernie Volz (EUD)'; 'Ralph Droms'; dhcwg@ietf.org Subject: RE: [dhcwg] WG last call on draft-ietf-dhc-dhcpv6-opt-nisconfig-01.txt Bernie, Thanks for your comments.... See my reply inline, prefixed by VJ. ~Vijay -----Original Message----- From: dhcwg-admin@ietf.org [ mailto:dhcwg-admin@ietf.org ]On Behalf Of Bernie Volz (EUD) Sent: Tuesday, February 18, 2003 2:30 AM To: 'Ralph Droms'; dhcwg@ietf.org Subject: RE: [dhcwg] WG last call on draft-ietf-dhc-dhcpv6-opt-nisconfig-01.txt I fully support the approval of this document for publication. However, I would recommend we review the following section: 8. Appearance of these option The NIS servers, NIS+ servers, NIS domain name and NIS+ domain name options MUST appear only in the following messages: Solicit, Advertise, Request, Confirm, Renew, Rebind, Information-Request, Reply. VJ> Basically, sending these options in messages originating from the VJ> client is for asking the server to provide these information. VJ> Its the alternative way of sending ORO with the option number for these options. VJ> We may want to make a decision here that these options can occur VJ> ONLY in messages originating from server and the client can VJ> indicate the server that it want any of these options by sending ONLY VJ> ORO option, because, client sending these options is of VJ> no interest in the server side, since, its not going to make VJ> any major decision based on the content of this option. VJ> But, it SHOULD be made consistent with ALL service addresses/parameters options. Based on earlier text, these options are for the server to convey information to clients and therefore perhaps text as follows is more appropriate: The NIS servers, NIS+ servers, NIS domain name and NIS+ domain name options MUST appear only in the Advertise and Reply messages. The option numbers for these options may appear in the Option Request Option [2] in Solicit, Request, Renew, Rebind, Information-Request, and Reconfigure messages. VJ> I will add. Or, we want a client to send these options in Request, Renew, Rebind to a server as well? In any case, there is little need for this option itself in Solicit and Confirm (based on the original text). And, some mention of use of the ORO option (at least in Reconfigure) may be appropriate? VJ> OK. I will add. - Bernie -----Original Message----- From: Ralph Droms [ mailto:rdroms@cisco.com ] Sent: Wednesday, February 12, 2003 3:25 PM To: dhcwg@ietf.org Subject: [dhcwg] WG last call on draft-ietf-dhc-dhcpv6-opt-nisconfig-01.txt This message announces a WG last call on "NIS Configuration Options for DHCPv6" . The last call will conclude on Friday, 2/28. draft-ietf-dhc-dhcpv6-opt-nisconfig-01.txt specifies four DHCPv6 options for configuration information related to Network Information Service (NIS). This draft is available as http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-opt-nisconfig-01.t xt - Ralph Droms _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg ------_=_NextPart_001_01C2D838.021A55E6 Content-Type: text/html; charset="iso-8859-1" RE: [dhcwg] WG last call on draft-ietf-dhc-dhcpv6-opt-nisconfig-01.txt
I would prefer (ii). A server should not be required to also go through a packet to see what options the
client sent to send the "correct" information.
 
The ORO mechanism is the way for a client to request certain options and it should be the only
mechanism. It simplifies implementations.
 
If a client sends an option (such as NIS server info), the server should just ignore it. If that option is
in the ORO, the server should send back the configured information to the client.
 
NOTE: The above applies only to those options which are essentially server to client configuration
options.
 
- Bernie
-----Original Message-----
From: Vijayabhaskar A K [mailto:vijayak@india.hp.com]
Sent: Wednesday, February 19, 2003 10:39 AM
To: 'Bernie Volz (EUD)'; 'Ralph Droms'; dhcwg@ietf.org
Subject: RE: [dhcwg] WG last call on draft-ietf-dhc-dhcpv6-opt-nisconfig-01.txt

Bernie,
I agree that client sending this option is no useful to server,
we can stick to ORO. In the case if we decide not to
prohibit client sending these options,
if the client sends these options,
(i) do the server need
to reply back with the correct values of these options?
(or)
(ii) make the server reply only if the option number is
filled in ORO option, thus just ignoring the client sending
these options.
I beleive, (i) is better.
If we decide (ii) then there is no meaning in not prohibiting
client to send these options. Though, there is no harm
in prohibiting the clients to send these options, because,
it can anyway get the values using ORO.
~Vijay
-----Original Message-----
From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org]On Behalf Of Bernie Volz (EUD)
Sent: Tuesday, February 18, 2003 8:55 PM
To: 'vijayak@india.hp.com'; 'Ralph Droms'; dhcwg@ietf.org
Subject: RE: [dhcwg] WG last call on draft-ietf-dhc-dhcpv6-opt-nisconfig-01.txt

Personally, I would like to see clients NOT send options to the
server but instead just send an ORO option. I see little value in
sending the NIS server info to the server - it just increases the
packet size and work a server must do to ignore these. ORO is the
mechanism to request that a server send an option; not sending the
option to the server.

For DHCPv4, is there any server that checks options sent by the
client to make sure that what it send is valid? What would a server
do if it isn't valid - just send the correct value? So, it seems to
me ORO is the way to go. Now, of course there are options that must
be sent by the client, such as IA options since they carry information
from the client to the server (such as the IAID).

I don't think we need to PROHIBIT a client from sending the option;
but we should not encourage it. A server that receives "unknown"
options should just ignore them.

- Bernie

-----Original Message-----
From: Vijayabhaskar A K [mailto:vijayak@india.hp.com]
Sent: Tuesday, February 18, 2003 7:36 AM
To: 'Bernie Volz (EUD)'; 'Ralph Droms'; dhcwg@ietf.org
Subject: RE: [dhcwg] WG last call on
draft-ietf-dhc-dhcpv6-opt-nisconfig-01.txt


Bernie,
Thanks for your comments....
See my reply inline, prefixed by VJ.
~Vijay

-----Original Message-----
From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org]On Behalf Of Bernie
Volz (EUD)
Sent: Tuesday, February 18, 2003 2:30 AM
To: 'Ralph Droms'; dhcwg@ietf.org
Subject: RE: [dhcwg] WG last call on
draft-ietf-dhc-dhcpv6-opt-nisconfig-01.txt


I fully support the approval of this document for publication.
However, I would recommend we review the following section:
8. Appearance of these option
   The NIS servers, NIS+ servers, NIS domain name and NIS+ domain name
   options MUST appear only in the following messages: Solicit,
   Advertise, Request, Confirm, Renew, Rebind, Information-Request,
   Reply.

VJ> Basically, sending these options in messages originating from the
VJ> client is for asking the server to provide these information.
VJ> Its the alternative way of sending ORO with the option number for these
options.
VJ> We may want to make a decision here that these options can occur
VJ> ONLY in messages originating from server and the client can
VJ> indicate the server that it want any of these options by sending ONLY
VJ> ORO option, because, client sending these options is of
VJ> no interest in the server side, since, its not going to make
VJ> any major decision based on the content of this option.
VJ> But, it SHOULD be made consistent with ALL service addresses/parameters
options.

Based on earlier text, these options are for the server to convey
information
to clients and therefore perhaps text as follows is more appropriate:
   The NIS servers, NIS+ servers, NIS domain name and NIS+ domain name
   options MUST appear only in the Advertise and Reply messages. The
   option numbers for these options may appear in the Option Request
   Option [2] in Solicit, Request, Renew, Rebind, Information-Request,
   and Reconfigure messages.

VJ> I will add.

Or, we want a client to send these options in Request, Renew, Rebind to
a server as well?

In any case, there is little need for this option itself in Solicit and
Confirm (based on the original text). And, some mention of use of the
ORO option (at least in Reconfigure) may be appropriate?

VJ> OK. I will add.

- Bernie
-----Original Message-----
From: Ralph Droms [mailto:rdroms@cisco.com]
Sent: Wednesday, February 12, 2003 3:25 PM
To: dhcwg@ietf.org
Subject: [dhcwg] WG last call on
draft-ietf-dhc-dhcpv6-opt-nisconfig-01.txt


This message announces a WG last call on "NIS Configuration Options
for DHCPv6" <draft-ietf-dhc-dhcpv6-opt-nisconfig-01.txt>.  The last call
will conclude on Friday, 2/28.
draft-ietf-dhc-dhcpv6-opt-nisconfig-01.txt specifies four DHCPv6 options
for configuration information related to Network Information Service
(NIS).  This draft is available as
http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-opt-nisconfig-01.t
xt
- Ralph Droms


_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg

------_=_NextPart_001_01C2D838.021A55E6-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Feb 19 12:49:53 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02975; Wed, 19 Feb 2003 12:49:53 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1JHtgp30173; Wed, 19 Feb 2003 12:55:42 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1JHsGp30096 for ; Wed, 19 Feb 2003 12:54:16 -0500 Received: from rtp-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02914 for ; Wed, 19 Feb 2003 12:47:32 -0500 (EST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h1JHpIJR017532 for ; Wed, 19 Feb 2003 12:51:19 -0500 (EST) Received: from rdroms-w2k.cisco.com (dhcp-161-44-149-251.cisco.com [161.44.149.251]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id MAA08929 for ; Wed, 19 Feb 2003 12:51:18 -0500 (EST) Message-Id: <4.3.2.7.2.20030219122513.03d54ee8@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 19 Feb 2003 12:51:17 -0500 To: dhcwg@ietf.org From: Ralph Droms Subject: Re: [dhcwg] lease query question In-Reply-To: <4.3.2.7.2.20030210170642.025d8f08@goblet.cisco.com> References: <200302041628.h14GSfc26441@rotala.raleigh.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Kim, Based on the discussion and current draft of the spec, it looks to me like the protocol has evolved beyond simply reporting lease information into a mechanism for populating an access concentrator with device identity and location information. It's more than a mere formality to ensure that the problem statement and design motivation match the protocol itself - those readers who have not been part of the evolution need to be able match up the problem statement and the protocol spec to effectively evaluate the correctness and applicability of the protocol. For example, I think the following problem statement more accurately reflects the current protocol and the problem that is causing its evolution: Router-type devices which want to enforce some level of access control over which IP addresses are allowed on their links need to maintain information concerning IP<->MAC/client-id mappings. One way in which these devices can obtain information about IP<->MAC/client-id bindings is through "DHCP gleaning", in which the device extracts useful information from DHCP messages exchanged between hosts and DHCP servers. However, these devices don't typically have stable storage sufficient to keep this information over reloads. There may be additional information that is useful to the device that cannot be obtained through DHCP gleaning. The leasequery request message described in this document allows a device to obtain information about IP<->MAC/client-id bindings from a DHCP server. This information may include currently active bindings, bindings involving previously assigned addresses for which the lease on the address has expired and static bindings for devices that are otherwise configured and not using DHCP for address assignment. - Ralph At 06:31 PM 2/10/2003 -0500, Kim Kinnear wrote: >At 11:28 AM 2/4/2003, Thomas Narten wrote: > >I've started my AD review on draft-ietf-dhc-leasequery-04.txt, and > >have a basic question. From the problem statement, I understood the > >problem to be fairly narrowly scoped, that is, an ability to rebuild > >the state that an access concentrator builds from gleaned DHC > >messages, but loses if it (say) restarts. The abstract/problem > >statement says: > > > > Access concentrators that act as DHCP relay agents need to determine > > the endpoint locations of IP addresses across public broadband access > > networks such as cable, DSL, and wireless networks. Because ARP > > broadcasts are undesirable in public networks, many access > > concentrator implementations "glean" location information from DHCP > > messages forwarded by its relay agent function. Unfortunately, the > > typical access concentrator loses its gleaned information when the > > access concentrator is rebooted or is replaced. This memo proposes > > that when gleaned DHCP information is not available, the access > > concentrator/relay agent obtains the location information directly > > from the DHCP server(s) using a new, lightweight DHCPLEASEQUERY > > message. > > We have evolved the leasequery capability and draft quite > a bit without, perhaps, similarly evolving the > abstract/problem statement. This is due, no doubt, to > the fact that it has taken quite a while to get this > draft completed. > > Having said that (which is true), I don't see significant > deviation from at least my conceptualization of the > current problem the leasequery protocol/draft solves. > > There are implementations of this capability in the field > today, and the actual draft is informed by not only our > intellectual exercises in protocol design but by actual > implementations and actual users of those implementations > with real requirements. If you think there is dramatic > mis-match between the problem statement with the actual > protocol, we can certainly revise the problem statement > to whatever degree you deem necessary. > > > >That is, I assumed that what is needed is a mechanism that allows a > >concentrator to avoid the need to invoke ARP, by querying the DHC > >server instead. To achieve this, I would have assumed that a simple > >query-response protocol that would solve the problem as stated. That > >is, I would have assumed perhaps two queries: > > > > - tell me the IP addresses of all devices behind a particular > > link-layer "MAC", or [note: one might use this to rebuild state > > about a particular link] > > > > - Tell me which of my links (if any) the following IP address resides > > on. [note: one might use this if one received an packet to forward, > > and needed to do the equivalent of "ARP" for it] > > > >I would expect that the leasequery might say "give me the info", and > >the server would respond with the same info it would give the > >client. I.e, the information received is the same as that it would > >glean from the normal DHC trafic (and in particular, without any new > >information specific to the leasequery protocol). > > Largely, this is what it does. > > > >But the protocol is quite a bit more complex than that. For example, a > >server can respond with a "sort of" answer, one that indicates I don't > >have a lease, but I did in the past. Likewise, there is also an R bit > >for providing further information about the details of a particular > >lease. > > To a first approximation, the server is trying to supply > information that is similar to that it would supply to > the DHCP client. However, the client of a leasequery is > not precisely identical to the DHCP client that is > requesting a lease. > > So, for instance, if a "real" DHCP client was talking to > the DHCP server, it would give the client a lease (as > opposed to telling the client that it had a lease at some > point in the past). However, the client for a leasequery > request isn't looking for a lease -- it is looking for > information *about* a lease. Allowing a server to return > information that indicates that a lease existed for a > client at sometime in the past may well be useful to a > device which is trying to rebuild its state, since this > is information that it normally would have available if > it had not lost its state. > > The R bit is designed to allow a device which uses DHCP > gleaning to also operate correctly in the event that some > IP addresses are "hard coded" or "hand configured". In > this case, if the DHCP server is supplied with a > reservation for the hand configured IP<->MAC > relationship, then if the DHCP client asks for an IP > address, it will get the proper one. More importantly, > the leasequery client doesn't have to be configured with > the hand-configured IP address, since it can determine > which IP addresses are "allowable" from the results of a > leasequery. This is indeed a capability that the > leasequery protocol allows that isn't possible in a > straightforward way without it. > > You could argue that it is a convenience, I suppose, and > that it is beyond the mission statement of the original > protocol. It is one of the capabilities that has been > requested by actual users of devices that utilize the > leasequery protocol, since those devices are much less > useful if you have to hand configure them with this > information. Some major customers have argued that this > sort of capability fits squarely into the leasequery > approach, and we agree with them. > > But you are right -- this is a capability that is > somewhat beyond what was possible without the leasequery > protocol. > > > >I don't fully understand the motivation or need for the additional > >stuff. There seem to be some unstated assumptions about the nature of > >the problem being solved. Could someone please clarify what the actual > >problem is that needs solving here? > > > I guess that I don't understand exactly which stuff you > consider extraneous, other than the two points which I > already addressed above. One of those capabilities I > don't consider extraneous, and the other I see only as a > logical extension to the basic capability, so I can't > reason from those to the other things that you find > "additional". > > Were I to state the problem that leasequery is trying to > solve without reference to the original problem statement > (as something of an exercise), I would say: > > Router-type devices which want to enforce some level of > access control over which IP addresses are allowed on > their links need to maintain information concerning > IP<->MAC/client-id mappings using DHCP gleaning, and > these devices don't typically have stable storage > sufficient to keep this information over reloads. The > leasequery request allows them to efficiently rebuild > this information as necessary. Moreover, for these > devices to be as useful in as many environments as > possible, some information not available from DHCP > gleaning can also be determined by using the leasequery > capability. > > But that explanation is only a slight extension from what > we already have in the draft (and that you quoted above). > > I'll be glad to pursue this if you wish. I can either > add some variant of the last sentence above to the > mission statement in the draft. > > Alternatively we can discuss other items that you > consider beyond the scope of the leasequery protocol. In > order to do that effectively, I'm going to have to have > additional information as to which other capabilities you > consider "additional". > > I don't expect any difficulty explaining why they 'fit' > into the mission statement of the protocol, or to > expanding the mission statement to cover them, for what > that is worth. I don't think that it is any more complex > than it needs to be to solve the task at hand, though > I'll admit the task is becoming something of a second > generation task as opposed to a first generation task. > > Cheers -- Kim > > > >Thomas > >_______________________________________________ > >dhcwg mailing list > >dhcwg@ietf.org > >https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Feb 19 17:15:53 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10940; Wed, 19 Feb 2003 17:15:52 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1JMLUp15070; Wed, 19 Feb 2003 17:21:30 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1JMKVp15013 for ; Wed, 19 Feb 2003 17:20:31 -0500 Received: from imr2.ericy.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10919 for ; Wed, 19 Feb 2003 17:13:41 -0500 (EST) Received: from mr5.exu.ericsson.se (mr5att.ericy.com [138.85.224.141]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id h1JMHVb28864; Wed, 19 Feb 2003 16:17:31 -0600 (CST) Received: from eamrcnt760.exu.ericsson.se (eamrcnt760.exu.ericsson.se [138.85.133.38]) by mr5.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id h1JMHVu29083; Wed, 19 Feb 2003 16:17:31 -0600 (CST) Received: by eamrcnt760.exu.ericsson.se with Internet Mail Service (5.5.2656.59) id ; Wed, 19 Feb 2003 16:17:30 -0600 Message-ID: From: "Bernie Volz (EUD)" To: "'vijayak@india.hp.com'" , "'Ralph Droms'" , dhcwg@ietf.org Subject: RE: [dhcwg] WG last call on draft-ietf-dhc-dhcpv6-opt-nisconfig-0 1.txt Date: Wed, 19 Feb 2003 16:15:52 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2D864.771DBEC4" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2D864.771DBEC4 Content-Type: text/plain; charset="ISO-8859-1" Vijay: The -28 draft says in 17.2.2. Creation and Transmission of Advertise Messages: The server includes options the server will return to the client in a subsequent Reply message. The information in these options may be used by the client in the selection of a server if the client receives more than one Advertise message. If the client has included an Option Request option in the Solicit message, the server includes options in the Advertise message containing configuration parameters for all of the options identified in the Option Request option that the server has been configured to return to the client. The server MAY return additional options to the client if it has been configured to do so. The server SHOULD limit the options returned to the client so that the DHCP message header and options do not cause fragmentation. And, also in 18.2. Server Behavior: In most Reply messages, the server includes options containing configuration information for the client. The server SHOULD limit the options returned to the client so that the DHCP message header and options do not cause fragmentation. If the client included an Option Request option in its message, the server includes options in the Reply message containing configuration parameters for all of the options identified in the Option Request option that the server has been configured to return to the client. The server MAY return additional options to the client if it has been configured to do so. In neither case is your (i) implied. The text says include the ORO options first and then send any other options specified by the server's configuration. I don't see a need to clarify this further in -28, but perhaps you (or others) do? - Bernie -----Original Message----- From: Bernie Volz (EUD) [mailto:Bernie.Volz@am1.ericsson.se] Sent: Wednesday, February 19, 2003 12:00 PM To: 'vijayak@india.hp.com'; 'Ralph Droms'; dhcwg@ietf.org Subject: RE: [dhcwg] WG last call on draft-ietf-dhc-dhcpv6-opt-nisconfig-0 1.txt I would prefer (ii). A server should not be required to also go through a packet to see what options the client sent to send the "correct" information. The ORO mechanism is the way for a client to request certain options and it should be the only mechanism. It simplifies implementations. If a client sends an option (such as NIS server info), the server should just ignore it. If that option is in the ORO, the server should send back the configured information to the client. NOTE: The above applies only to those options which are essentially server to client configuration options. - Bernie -----Original Message----- From: Vijayabhaskar A K [mailto:vijayak@india.hp.com] Sent: Wednesday, February 19, 2003 10:39 AM To: 'Bernie Volz (EUD)'; 'Ralph Droms'; dhcwg@ietf.org Subject: RE: [dhcwg] WG last call on draft-ietf-dhc-dhcpv6-opt-nisconfig-01.txt Bernie, I agree that client sending this option is no useful to server, we can stick to ORO. In the case if we decide not to prohibit client sending these options, if the client sends these options, (i) do the server need to reply back with the correct values of these options? (or) (ii) make the server reply only if the option number is filled in ORO option, thus just ignoring the client sending these options. I beleive, (i) is better. If we decide (ii) then there is no meaning in not prohibiting client to send these options. Though, there is no harm in prohibiting the clients to send these options, because, it can anyway get the values using ORO. ~Vijay -----Original Message----- From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org]On Behalf Of Bernie Volz (EUD) Sent: Tuesday, February 18, 2003 8:55 PM To: 'vijayak@india.hp.com'; 'Ralph Droms'; dhcwg@ietf.org Subject: RE: [dhcwg] WG last call on draft-ietf-dhc-dhcpv6-opt-nisconfig-01.txt Personally, I would like to see clients NOT send options to the server but instead just send an ORO option. I see little value in sending the NIS server info to the server - it just increases the packet size and work a server must do to ignore these. ORO is the mechanism to request that a server send an option; not sending the option to the server. For DHCPv4, is there any server that checks options sent by the client to make sure that what it send is valid? What would a server do if it isn't valid - just send the correct value? So, it seems to me ORO is the way to go. Now, of course there are options that must be sent by the client, such as IA options since they carry information from the client to the server (such as the IAID). I don't think we need to PROHIBIT a client from sending the option; but we should not encourage it. A server that receives "unknown" options should just ignore them. - Bernie -----Original Message----- From: Vijayabhaskar A K [mailto:vijayak@india.hp.com] Sent: Tuesday, February 18, 2003 7:36 AM To: 'Bernie Volz (EUD)'; 'Ralph Droms'; dhcwg@ietf.org Subject: RE: [dhcwg] WG last call on draft-ietf-dhc-dhcpv6-opt-nisconfig-01.txt Bernie, Thanks for your comments.... See my reply inline, prefixed by VJ. ~Vijay -----Original Message----- From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org]On Behalf Of Bernie Volz (EUD) Sent: Tuesday, February 18, 2003 2:30 AM To: 'Ralph Droms'; dhcwg@ietf.org Subject: RE: [dhcwg] WG last call on draft-ietf-dhc-dhcpv6-opt-nisconfig-01.txt I fully support the approval of this document for publication. However, I would recommend we review the following section: 8. Appearance of these option The NIS servers, NIS+ servers, NIS domain name and NIS+ domain name options MUST appear only in the following messages: Solicit, Advertise, Request, Confirm, Renew, Rebind, Information-Request, Reply. VJ> Basically, sending these options in messages originating from the VJ> client is for asking the server to provide these information. VJ> Its the alternative way of sending ORO with the option number for these options. VJ> We may want to make a decision here that these options can occur VJ> ONLY in messages originating from server and the client can VJ> indicate the server that it want any of these options by sending ONLY VJ> ORO option, because, client sending these options is of VJ> no interest in the server side, since, its not going to make VJ> any major decision based on the content of this option. VJ> But, it SHOULD be made consistent with ALL service addresses/parameters options. Based on earlier text, these options are for the server to convey information to clients and therefore perhaps text as follows is more appropriate: The NIS servers, NIS+ servers, NIS domain name and NIS+ domain name options MUST appear only in the Advertise and Reply messages. The option numbers for these options may appear in the Option Request Option [2] in Solicit, Request, Renew, Rebind, Information-Request, and Reconfigure messages. VJ> I will add. Or, we want a client to send these options in Request, Renew, Rebind to a server as well? In any case, there is little need for this option itself in Solicit and Confirm (based on the original text). And, some mention of use of the ORO option (at least in Reconfigure) may be appropriate? VJ> OK. I will add. - Bernie -----Original Message----- From: Ralph Droms [mailto:rdroms@cisco.com] Sent: Wednesday, February 12, 2003 3:25 PM To: dhcwg@ietf.org Subject: [dhcwg] WG last call on draft-ietf-dhc-dhcpv6-opt-nisconfig-01.txt This message announces a WG last call on "NIS Configuration Options for DHCPv6" . The last call will conclude on Friday, 2/28. draft-ietf-dhc-dhcpv6-opt-nisconfig-01.txt specifies four DHCPv6 options for configuration information related to Network Information Service (NIS). This draft is available as http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-opt-nisconfig-01.t xt - Ralph Droms _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg ------_=_NextPart_001_01C2D864.771DBEC4 Content-Type: text/html; charset="ISO-8859-1" RE: [dhcwg] WG last call on draft-ietf-dhc-dhcpv6-opt-nisconfig-0 1.txt

Vijay:

The -28 draft says in 17.2.2. Creation and Transmission of Advertise Messages:

   The server includes options the server will return to the client in
   a subsequent Reply message.  The information in these options may
   be used by the client in the selection of a server if the client
   receives more than one Advertise message.  If the client has included
   an Option Request option in the Solicit message, the server includes
   options in the Advertise message containing configuration parameters
   for all of the options identified in the Option Request option
   that the server has been configured to return to the client.  The
   server MAY return additional options to the client if it has been
   configured to do so.  The server SHOULD limit the options returned to
   the client so that the DHCP message header and options do not cause
   fragmentation.

And, also in 18.2. Server Behavior:

   In most Reply messages, the server includes options containing
   configuration information for the client.  The server SHOULD limit
   the options returned to the client so that the DHCP message header
   and options do not cause fragmentation.  If the client included an
   Option Request option in its message, the server includes options
   in the Reply message containing configuration parameters for all of
   the options identified in the Option Request option that the server
   has been configured to return to the client.  The server MAY return
   additional options to the client if it has been configured to do so.

In neither case is your (i) implied. The text says include the ORO options
first and then send any other options specified by the server's configuration.

I don't see a need to clarify this further in -28, but perhaps you (or
others) do?

- Bernie

-----Original Message-----
From: Bernie Volz (EUD) [mailto:Bernie.Volz@am1.ericsson.se]
Sent: Wednesday, February 19, 2003 12:00 PM
To: 'vijayak@india.hp.com'; 'Ralph Droms'; dhcwg@ietf.org
Subject: RE: [dhcwg] WG last call on draft-ietf-dhc-dhcpv6-opt-nisconfig-0 1.txt


I would prefer (ii). A server should not be required to also go through a packet to see what options the
client sent to send the "correct" information.

The ORO mechanism is the way for a client to request certain options and it should be the only
mechanism. It simplifies implementations.

If a client sends an option (such as NIS server info), the server should just ignore it. If that option is
in the ORO, the server should send back the configured information to the client.

NOTE: The above applies only to those options which are essentially server to client configuration
options.

- Bernie
-----Original Message-----
From: Vijayabhaskar A K [mailto:vijayak@india.hp.com]
Sent: Wednesday, February 19, 2003 10:39 AM
To: 'Bernie Volz (EUD)'; 'Ralph Droms'; dhcwg@ietf.org
Subject: RE: [dhcwg] WG last call on draft-ietf-dhc-dhcpv6-opt-nisconfig-01.txt


Bernie,
I agree that client sending this option is no useful to server,
we can stick to ORO. In the case if we decide not to
prohibit client sending these options,
if the client sends these options,
(i) do the server need
to reply back with the correct values of these options?
(or)
(ii) make the server reply only if the option number is
filled in ORO option, thus just ignoring the client sending
these options.
I beleive, (i) is better.
If we decide (ii) then there is no meaning in not prohibiting
client to send these options. Though, there is no harm
in prohibiting the clients to send these options, because,
it can anyway get the values using ORO.
~Vijay
-----Original Message-----
From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org]On Behalf Of Bernie Volz (EUD)
Sent: Tuesday, February 18, 2003 8:55 PM
To: 'vijayak@india.hp.com'; 'Ralph Droms'; dhcwg@ietf.org
Subject: RE: [dhcwg] WG last call on draft-ietf-dhc-dhcpv6-opt-nisconfig-01.txt


Personally, I would like to see clients NOT send options to the
server but instead just send an ORO option. I see little value in
sending the NIS server info to the server - it just increases the
packet size and work a server must do to ignore these. ORO is the
mechanism to request that a server send an option; not sending the
option to the server.
For DHCPv4, is there any server that checks options sent by the
client to make sure that what it send is valid? What would a server
do if it isn't valid - just send the correct value? So, it seems to
me ORO is the way to go. Now, of course there are options that must
be sent by the client, such as IA options since they carry information
from the client to the server (such as the IAID).
I don't think we need to PROHIBIT a client from sending the option;
but we should not encourage it. A server that receives "unknown"
options should just ignore them.
- Bernie
-----Original Message-----
From: Vijayabhaskar A K [mailto:vijayak@india.hp.com]
Sent: Tuesday, February 18, 2003 7:36 AM
To: 'Bernie Volz (EUD)'; 'Ralph Droms'; dhcwg@ietf.org
Subject: RE: [dhcwg] WG last call on
draft-ietf-dhc-dhcpv6-opt-nisconfig-01.txt


Bernie,
Thanks for your comments....
See my reply inline, prefixed by VJ.
~Vijay
-----Original Message-----
From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org]On Behalf Of Bernie
Volz (EUD)
Sent: Tuesday, February 18, 2003 2:30 AM
To: 'Ralph Droms'; dhcwg@ietf.org
Subject: RE: [dhcwg] WG last call on
draft-ietf-dhc-dhcpv6-opt-nisconfig-01.txt


I fully support the approval of this document for publication.
However, I would recommend we review the following section:
8. Appearance of these option
   The NIS servers, NIS+ servers, NIS domain name and NIS+ domain name
   options MUST appear only in the following messages: Solicit,
   Advertise, Request, Confirm, Renew, Rebind, Information-Request,
   Reply.
VJ> Basically, sending these options in messages originating from the
VJ> client is for asking the server to provide these information.
VJ> Its the alternative way of sending ORO with the option number for these
options.
VJ> We may want to make a decision here that these options can occur
VJ> ONLY in messages originating from server and the client can
VJ> indicate the server that it want any of these options by sending ONLY
VJ> ORO option, because, client sending these options is of
VJ> no interest in the server side, since, its not going to make
VJ> any major decision based on the content of this option.
VJ> But, it SHOULD be made consistent with ALL service addresses/parameters
options.
Based on earlier text, these options are for the server to convey
information
to clients and therefore perhaps text as follows is more appropriate:
   The NIS servers, NIS+ servers, NIS domain name and NIS+ domain name
   options MUST appear only in the Advertise and Reply messages. The
   option numbers for these options may appear in the Option Request
   Option [2] in Solicit, Request, Renew, Rebind, Information-Request,
   and Reconfigure messages.
VJ> I will add.
Or, we want a client to send these options in Request, Renew, Rebind to
a server as well?
In any case, there is little need for this option itself in Solicit and
Confirm (based on the original text). And, some mention of use of the
ORO option (at least in Reconfigure) may be appropriate?
VJ> OK. I will add.
- Bernie
-----Original Message-----
From: Ralph Droms [mailto:rdroms@cisco.com]
Sent: Wednesday, February 12, 2003 3:25 PM
To: dhcwg@ietf.org
Subject: [dhcwg] WG last call on
draft-ietf-dhc-dhcpv6-opt-nisconfig-01.txt


This message announces a WG last call on "NIS Configuration Options
for DHCPv6" <draft-ietf-dhc-dhcpv6-opt-nisconfig-01.txt>.  The last call
will conclude on Friday, 2/28.
draft-ietf-dhc-dhcpv6-opt-nisconfig-01.txt specifies four DHCPv6 options
for configuration information related to Network Information Service
(NIS).  This draft is available as
http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-opt-nisconfig-01.t
xt
- Ralph Droms


_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg

------_=_NextPart_001_01C2D864.771DBEC4-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Feb 20 07:15:47 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08504; Thu, 20 Feb 2003 07:15:47 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KCM9p07420; Thu, 20 Feb 2003 07:22:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KCKcp07377 for ; Thu, 20 Feb 2003 07:20:38 -0500 Received: from palrel11.hp.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08483 for ; Thu, 20 Feb 2003 07:13:33 -0500 (EST) Received: from iconsrv5.india.hp.com (iconsrv5.india.hp.com [15.42.229.13]) by palrel11.hp.com (Postfix) with ESMTP id C31021C014C1; Thu, 20 Feb 2003 04:17:20 -0800 (PST) Received: from nt23056 (nt23056.india.hp.com [15.42.230.56]) by iconsrv5.india.hp.com (8.9.3/8.9.3 SMKit7.02) with SMTP id RAA05489; Thu, 20 Feb 2003 17:46:43 +0530 (IST) Reply-To: From: "Vijayabhaskar A K" To: "'Bernie Volz (EUD)'" , "'Ralph Droms'" , Subject: RE: [dhcwg] WG last call on draft-ietf-dhc-dhcpv6-opt-nisconfig-01.txt Date: Thu, 20 Feb 2003 17:46:07 +0530 Message-ID: <001a01c2d8d9$d90cc1f0$38e62a0f@nt23056> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Importance: Normal Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Sure, the server doesn't need to parse the value in these options, rather it can note down the option number, skip the option without processing it and in the reply, it sends back the "correct" information for that option. I dont think that there is any harm in allowing this. ~Vijay -----Original Message----- From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org]On Behalf Of Bernie Volz (EUD) Sent: Wednesday, February 19, 2003 10:30 PM To: 'vijayak@india.hp.com'; 'Ralph Droms'; dhcwg@ietf.org Subject: RE: [dhcwg] WG last call on draft-ietf-dhc-dhcpv6-opt-nisconfig-01.txt I would prefer (ii). A server should not be required to also go through a packet to see what options the client sent to send the "correct" information. The ORO mechanism is the way for a client to request certain options and it should be the only mechanism. It simplifies implementations. If a client sends an option (such as NIS server info), the server should just ignore it. If that option is in the ORO, the server should send back the configured information to the client. NOTE: The above applies only to those options which are essentially server to client configuration options. - Bernie -----Original Message----- From: Vijayabhaskar A K [mailto:vijayak@india.hp.com] Sent: Wednesday, February 19, 2003 10:39 AM To: 'Bernie Volz (EUD)'; 'Ralph Droms'; dhcwg@ietf.org Subject: RE: [dhcwg] WG last call on draft-ietf-dhc-dhcpv6-opt-nisconfig-01.txt Bernie, I agree that client sending this option is no useful to server, we can stick to ORO. In the case if we decide not to prohibit client sending these options, if the client sends these options, (i) do the server need to reply back with the correct values of these options? (or) (ii) make the server reply only if the option number is filled in ORO option, thus just ignoring the client sending these options. I beleive, (i) is better. If we decide (ii) then there is no meaning in not prohibiting client to send these options. Though, there is no harm in prohibiting the clients to send these options, because, it can anyway get the values using ORO. ~Vijay -----Original Message----- From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org]On Behalf Of Bernie Volz (EUD) Sent: Tuesday, February 18, 2003 8:55 PM To: 'vijayak@india.hp.com'; 'Ralph Droms'; dhcwg@ietf.org Subject: RE: [dhcwg] WG last call on draft-ietf-dhc-dhcpv6-opt-nisconfig-01.txt Personally, I would like to see clients NOT send options to the server but instead just send an ORO option. I see little value in sending the NIS server info to the server - it just increases the packet size and work a server must do to ignore these. ORO is the mechanism to request that a server send an option; not sending the option to the server. For DHCPv4, is there any server that checks options sent by the client to make sure that what it send is valid? What would a server do if it isn't valid - just send the correct value? So, it seems to me ORO is the way to go. Now, of course there are options that must be sent by the client, such as IA options since they carry information from the client to the server (such as the IAID). I don't think we need to PROHIBIT a client from sending the option; but we should not encourage it. A server that receives "unknown" options should just ignore them. - Bernie -----Original Message----- From: Vijayabhaskar A K [mailto:vijayak@india.hp.com] Sent: Tuesday, February 18, 2003 7:36 AM To: 'Bernie Volz (EUD)'; 'Ralph Droms'; dhcwg@ietf.org Subject: RE: [dhcwg] WG last call on draft-ietf-dhc-dhcpv6-opt-nisconfig-01.txt Bernie, Thanks for your comments.... See my reply inline, prefixed by VJ. ~Vijay -----Original Message----- From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org]On Behalf Of Bernie Volz (EUD) Sent: Tuesday, February 18, 2003 2:30 AM To: 'Ralph Droms'; dhcwg@ietf.org Subject: RE: [dhcwg] WG last call on draft-ietf-dhc-dhcpv6-opt-nisconfig-01.txt I fully support the approval of this document for publication. However, I would recommend we review the following section: 8. Appearance of these option The NIS servers, NIS+ servers, NIS domain name and NIS+ domain name options MUST appear only in the following messages: Solicit, Advertise, Request, Confirm, Renew, Rebind, Information-Request, Reply. VJ> Basically, sending these options in messages originating from the VJ> client is for asking the server to provide these information. VJ> Its the alternative way of sending ORO with the option number for these options. VJ> We may want to make a decision here that these options can occur VJ> ONLY in messages originating from server and the client can VJ> indicate the server that it want any of these options by sending ONLY VJ> ORO option, because, client sending these options is of VJ> no interest in the server side, since, its not going to make VJ> any major decision based on the content of this option. VJ> But, it SHOULD be made consistent with ALL service addresses/parameters options. Based on earlier text, these options are for the server to convey information to clients and therefore perhaps text as follows is more appropriate: The NIS servers, NIS+ servers, NIS domain name and NIS+ domain name options MUST appear only in the Advertise and Reply messages. The option numbers for these options may appear in the Option Request Option [2] in Solicit, Request, Renew, Rebind, Information-Request, and Reconfigure messages. VJ> I will add. Or, we want a client to send these options in Request, Renew, Rebind to a server as well? In any case, there is little need for this option itself in Solicit and Confirm (based on the original text). And, some mention of use of the ORO option (at least in Reconfigure) may be appropriate? VJ> OK. I will add. - Bernie -----Original Message----- From: Ralph Droms [mailto:rdroms@cisco.com] Sent: Wednesday, February 12, 2003 3:25 PM To: dhcwg@ietf.org Subject: [dhcwg] WG last call on draft-ietf-dhc-dhcpv6-opt-nisconfig-01.txt This message announces a WG last call on "NIS Configuration Options for DHCPv6" . The last call will conclude on Friday, 2/28. draft-ietf-dhc-dhcpv6-opt-nisconfig-01.txt specifies four DHCPv6 options for configuration information related to Network Information Service (NIS). This draft is available as http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-opt-nisconfig-01.t xt - Ralph Droms _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Feb 20 07:29:56 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08758; Thu, 20 Feb 2003 07:29:56 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KCaMp07864; Thu, 20 Feb 2003 07:36:22 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KCZSp07777 for ; Thu, 20 Feb 2003 07:35:28 -0500 Received: from atlrel9.hp.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08737 for ; Thu, 20 Feb 2003 07:28:24 -0500 (EST) Received: from iconsrv5.india.hp.com (iconsrv5.india.hp.com [15.42.229.13]) by atlrel9.hp.com (Postfix) with ESMTP id 23BC81C00B80; Thu, 20 Feb 2003 07:32:11 -0500 (EST) Received: from nt23056 (nt23056.india.hp.com [15.42.230.56]) by iconsrv5.india.hp.com (8.9.3/8.9.3 SMKit7.02) with SMTP id SAA06465; Thu, 20 Feb 2003 18:01:34 +0530 (IST) Reply-To: From: "Vijayabhaskar A K" To: "'Bernie Volz (EUD)'" , "'Ralph Droms'" , Subject: RE: [dhcwg] WG last call on draft-ietf-dhc-dhcpv6-opt-nisconfig-0 1.txt Date: Thu, 20 Feb 2003 18:00:58 +0530 Message-ID: <001b01c2d8db$ebf16b20$38e62a0f@nt23056> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Importance: Normal Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Bernie, I agree that it doesn't imply that. But this will make the server to ignore an option, for which it has a valid information and supports it. It doesn't make sense. If we are going to ignore the option in server side, then whats the point to "allowing" (Note: i didn't mean "encouraging") the client to send this option to the server? Its just going to eatup some bytes of packet. We have to make decision on either of the following two i) prohibit the clients to send these options and ignore these options in the server (to cope up with non RFC conformant clients) ii) allow client to send these options and let server reply with the correct values, as if these option numbers were present in ORO option that client has sent It doesn't make sense on keeping combination of the both, with server allowing the clients to send these options and ignoring it. ~Vijay -----Original Message----- From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org]On Behalf Of Bernie Volz (EUD) Sent: Thursday, February 20, 2003 3:46 AM To: 'vijayak@india.hp.com'; 'Ralph Droms'; dhcwg@ietf.org Subject: RE: [dhcwg] WG last call on draft-ietf-dhc-dhcpv6-opt-nisconfig-0 1.txt Vijay: The -28 draft says in 17.2.2. Creation and Transmission of Advertise Messages: The server includes options the server will return to the client in a subsequent Reply message. The information in these options may be used by the client in the selection of a server if the client receives more than one Advertise message. If the client has included an Option Request option in the Solicit message, the server includes options in the Advertise message containing configuration parameters for all of the options identified in the Option Request option that the server has been configured to return to the client. The server MAY return additional options to the client if it has been configured to do so. The server SHOULD limit the options returned to the client so that the DHCP message header and options do not cause fragmentation. And, also in 18.2. Server Behavior: In most Reply messages, the server includes options containing configuration information for the client. The server SHOULD limit the options returned to the client so that the DHCP message header and options do not cause fragmentation. If the client included an Option Request option in its message, the server includes options in the Reply message containing configuration parameters for all of the options identified in the Option Request option that the server has been configured to return to the client. The server MAY return additional options to the client if it has been configured to do so. In neither case is your (i) implied. The text says include the ORO options first and then send any other options specified by the server's configuration. I don't see a need to clarify this further in -28, but perhaps you (or others) do? - Bernie -----Original Message----- From: Bernie Volz (EUD) [mailto:Bernie.Volz@am1.ericsson.se] Sent: Wednesday, February 19, 2003 12:00 PM To: 'vijayak@india.hp.com'; 'Ralph Droms'; dhcwg@ietf.org Subject: RE: [dhcwg] WG last call on draft-ietf-dhc-dhcpv6-opt-nisconfig-0 1.txt I would prefer (ii). A server should not be required to also go through a packet to see what options the client sent to send the "correct" information. The ORO mechanism is the way for a client to request certain options and it should be the only mechanism. It simplifies implementations. If a client sends an option (such as NIS server info), the server should just ignore it. If that option is in the ORO, the server should send back the configured information to the client. NOTE: The above applies only to those options which are essentially server to client configuration options. - Bernie -----Original Message----- From: Vijayabhaskar A K [mailto:vijayak@india.hp.com] Sent: Wednesday, February 19, 2003 10:39 AM To: 'Bernie Volz (EUD)'; 'Ralph Droms'; dhcwg@ietf.org Subject: RE: [dhcwg] WG last call on draft-ietf-dhc-dhcpv6-opt-nisconfig-01.txt Bernie, I agree that client sending this option is no useful to server, we can stick to ORO. In the case if we decide not to prohibit client sending these options, if the client sends these options, (i) do the server need to reply back with the correct values of these options? (or) (ii) make the server reply only if the option number is filled in ORO option, thus just ignoring the client sending these options. I beleive, (i) is better. If we decide (ii) then there is no meaning in not prohibiting client to send these options. Though, there is no harm in prohibiting the clients to send these options, because, it can anyway get the values using ORO. ~Vijay -----Original Message----- From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org]On Behalf Of Bernie Volz (EUD) Sent: Tuesday, February 18, 2003 8:55 PM To: 'vijayak@india.hp.com'; 'Ralph Droms'; dhcwg@ietf.org Subject: RE: [dhcwg] WG last call on draft-ietf-dhc-dhcpv6-opt-nisconfig-01.txt Personally, I would like to see clients NOT send options to the server but instead just send an ORO option. I see little value in sending the NIS server info to the server - it just increases the packet size and work a server must do to ignore these. ORO is the mechanism to request that a server send an option; not sending the option to the server. For DHCPv4, is there any server that checks options sent by the client to make sure that what it send is valid? What would a server do if it isn't valid - just send the correct value? So, it seems to me ORO is the way to go. Now, of course there are options that must be sent by the client, such as IA options since they carry information from the client to the server (such as the IAID). I don't think we need to PROHIBIT a client from sending the option; but we should not encourage it. A server that receives "unknown" options should just ignore them. - Bernie -----Original Message----- From: Vijayabhaskar A K [mailto:vijayak@india.hp.com] Sent: Tuesday, February 18, 2003 7:36 AM To: 'Bernie Volz (EUD)'; 'Ralph Droms'; dhcwg@ietf.org Subject: RE: [dhcwg] WG last call on draft-ietf-dhc-dhcpv6-opt-nisconfig-01.txt Bernie, Thanks for your comments.... See my reply inline, prefixed by VJ. ~Vijay -----Original Message----- From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org]On Behalf Of Bernie Volz (EUD) Sent: Tuesday, February 18, 2003 2:30 AM To: 'Ralph Droms'; dhcwg@ietf.org Subject: RE: [dhcwg] WG last call on draft-ietf-dhc-dhcpv6-opt-nisconfig-01.txt I fully support the approval of this document for publication. However, I would recommend we review the following section: 8. Appearance of these option The NIS servers, NIS+ servers, NIS domain name and NIS+ domain name options MUST appear only in the following messages: Solicit, Advertise, Request, Confirm, Renew, Rebind, Information-Request, Reply. VJ> Basically, sending these options in messages originating from the VJ> client is for asking the server to provide these information. VJ> Its the alternative way of sending ORO with the option number for these options. VJ> We may want to make a decision here that these options can occur VJ> ONLY in messages originating from server and the client can VJ> indicate the server that it want any of these options by sending ONLY VJ> ORO option, because, client sending these options is of VJ> no interest in the server side, since, its not going to make VJ> any major decision based on the content of this option. VJ> But, it SHOULD be made consistent with ALL service addresses/parameters options. Based on earlier text, these options are for the server to convey information to clients and therefore perhaps text as follows is more appropriate: The NIS servers, NIS+ servers, NIS domain name and NIS+ domain name options MUST appear only in the Advertise and Reply messages. The option numbers for these options may appear in the Option Request Option [2] in Solicit, Request, Renew, Rebind, Information-Request, and Reconfigure messages. VJ> I will add. Or, we want a client to send these options in Request, Renew, Rebind to a server as well? In any case, there is little need for this option itself in Solicit and Confirm (based on the original text). And, some mention of use of the ORO option (at least in Reconfigure) may be appropriate? VJ> OK. I will add. - Bernie -----Original Message----- From: Ralph Droms [mailto:rdroms@cisco.com] Sent: Wednesday, February 12, 2003 3:25 PM To: dhcwg@ietf.org Subject: [dhcwg] WG last call on draft-ietf-dhc-dhcpv6-opt-nisconfig-01.txt This message announces a WG last call on "NIS Configuration Options for DHCPv6" . The last call will conclude on Friday, 2/28. draft-ietf-dhc-dhcpv6-opt-nisconfig-01.txt specifies four DHCPv6 options for configuration information related to Network Information Service (NIS). This draft is available as http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-opt-nisconfig-01.t xt - Ralph Droms _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Feb 20 07:36:44 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09138; Thu, 20 Feb 2003 07:36:44 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KCh6p08850; Thu, 20 Feb 2003 07:43:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KCglp08829 for ; Thu, 20 Feb 2003 07:42:47 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08935; Thu, 20 Feb 2003 07:35:44 -0500 (EST) Message-Id: <200302201235.HAA08935@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: dhcwg@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Thu, 20 Feb 2003 07:35:44 -0500 Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-unused-optioncodes-00.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Title : Unused DHCP Option Codes Author(s) : R. Droms Filename : draft-ietf-dhc-unused-optioncodes-00.txt Pages : 8 Date : 2003-2-19 Prior to the publication of RFC2939 (which was updated by RFC2489), several option codes were assigned to proposed DHCP options that were subsequently never used. This document lists those unused option codes and will be used to confirm that these option codes can be reused for other DHCP options in the future. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-unused-optioncodes-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-unused-optioncodes-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-unused-optioncodes-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: <2003-2-19141857.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-unused-optioncodes-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-unused-optioncodes-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-2-19141857.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Feb 20 10:20:12 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17311; Thu, 20 Feb 2003 10:20:12 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KFQXp20273; Thu, 20 Feb 2003 10:26:33 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KFPqp20170 for ; Thu, 20 Feb 2003 10:25:52 -0500 Received: from imr1.ericy.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17195 for ; Thu, 20 Feb 2003 10:18:41 -0500 (EST) Received: from mr5.exu.ericsson.se (mr5u3.ericy.com [208.237.135.124]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id h1KFMVd28262; Thu, 20 Feb 2003 09:22:31 -0600 (CST) Received: from eamrcnt760.exu.ericsson.se (eamrcnt760.exu.ericsson.se [138.85.133.38]) by mr5.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id h1KFMQX10243; Thu, 20 Feb 2003 09:22:26 -0600 (CST) Received: by eamrcnt760.exu.ericsson.se with Internet Mail Service (5.5.2656.59) id ; Thu, 20 Feb 2003 09:22:25 -0600 Message-ID: From: "Bernie Volz (EUD)" To: "'vijayak@india.hp.com'" , "'Ralph Droms'" , dhcwg@ietf.org Subject: RE: [dhcwg] WG last call on draft-ietf-dhc-dhcpv6-opt-nisconfig-0 1.txt Date: Thu, 20 Feb 2003 09:20:46 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2D8F3.A3EBE5D6" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2D8F3.A3EBE5D6 Content-Type: text/plain; charset="ISO-8859-1" Vijay: The question really is what do we REQUIRE a server to do. I think there is NO reason to require a server to do anything with these options. The server MAY do something (such as sending back the correct value for this options), but that is not the required behavior. The required behavior is for the server to send a) those options specified in the ORO and b) those options that it has configuration information for (subject to packet size limitations). I do *NOT* want to add a c) (or move b to c and add a b) of any options that were included by the client. [And also have to consider what PRIORITY these options have with respect to the ORO ones and the configured ones.] Why complicate the picture when this is completely unnecessary. If your clients (and your server) want to this, there is nothing prohibiting your client from sending the options and your server processing them in some non-standard way. However, don't expect this to interoperate with other servers or clients - those other servers will ignore those options and those other clients won't send them. For your clients to interoperate properly, you have to follow the rules which would require you to send an ORO listing the options you want the server to send. The client can also include those options in any messages it sends to the server (but again, most servers will ignore them). If your clients fail to include any options they want in the ORO, then the other servers may still send those options but that is because those options were configured at the server, provided the packet size has not been exceeded. - Bernie -----Original Message----- From: Vijayabhaskar A K [mailto:vijayak@india.hp.com] Sent: Thursday, February 20, 2003 7:31 AM To: 'Bernie Volz (EUD)'; 'Ralph Droms'; dhcwg@ietf.org Subject: RE: [dhcwg] WG last call on draft-ietf-dhc-dhcpv6-opt-nisconfig-0 1.txt Bernie, I agree that it doesn't imply that. But this will make the server to ignore an option, for which it has a valid information and supports it. It doesn't make sense. If we are going to ignore the option in server side, then whats the point to "allowing" (Note: i didn't mean "encouraging") the client to send this option to the server? Its just going to eatup some bytes of packet. We have to make decision on either of the following two i) prohibit the clients to send these options and ignore these options in the server (to cope up with non RFC conformant clients) ii) allow client to send these options and let server reply with the correct values, as if these option numbers were present in ORO option that client has sent It doesn't make sense on keeping combination of the both, with server allowing the clients to send these options and ignoring it. ~Vijay -----Original Message----- From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org]On Behalf Of Bernie Volz (EUD) Sent: Thursday, February 20, 2003 3:46 AM To: 'vijayak@india.hp.com'; 'Ralph Droms'; dhcwg@ietf.org Subject: RE: [dhcwg] WG last call on draft-ietf-dhc-dhcpv6-opt-nisconfig-0 1.txt Vijay: The -28 draft says in 17.2.2. Creation and Transmission of Advertise Messages: The server includes options the server will return to the client in a subsequent Reply message. The information in these options may be used by the client in the selection of a server if the client receives more than one Advertise message. If the client has included an Option Request option in the Solicit message, the server includes options in the Advertise message containing configuration parameters for all of the options identified in the Option Request option that the server has been configured to return to the client. The server MAY return additional options to the client if it has been configured to do so. The server SHOULD limit the options returned to the client so that the DHCP message header and options do not cause fragmentation. And, also in 18.2. Server Behavior: In most Reply messages, the server includes options containing configuration information for the client. The server SHOULD limit the options returned to the client so that the DHCP message header and options do not cause fragmentation. If the client included an Option Request option in its message, the server includes options in the Reply message containing configuration parameters for all of the options identified in the Option Request option that the server has been configured to return to the client. The server MAY return additional options to the client if it has been configured to do so. In neither case is your (i) implied. The text says include the ORO options first and then send any other options specified by the server's configuration. I don't see a need to clarify this further in -28, but perhaps you (or others) do? - Bernie -----Original Message----- From: Bernie Volz (EUD) [mailto:Bernie.Volz@am1.ericsson.se] Sent: Wednesday, February 19, 2003 12:00 PM To: 'vijayak@india.hp.com'; 'Ralph Droms'; dhcwg@ietf.org Subject: RE: [dhcwg] WG last call on draft-ietf-dhc-dhcpv6-opt-nisconfig-0 1.txt I would prefer (ii). A server should not be required to also go through a packet to see what options the client sent to send the "correct" information. The ORO mechanism is the way for a client to request certain options and it should be the only mechanism. It simplifies implementations. If a client sends an option (such as NIS server info), the server should just ignore it. If that option is in the ORO, the server should send back the configured information to the client. NOTE: The above applies only to those options which are essentially server to client configuration options. - Bernie -----Original Message----- From: Vijayabhaskar A K [mailto:vijayak@india.hp.com] Sent: Wednesday, February 19, 2003 10:39 AM To: 'Bernie Volz (EUD)'; 'Ralph Droms'; dhcwg@ietf.org Subject: RE: [dhcwg] WG last call on draft-ietf-dhc-dhcpv6-opt-nisconfig-01.txt Bernie, I agree that client sending this option is no useful to server, we can stick to ORO. In the case if we decide not to prohibit client sending these options, if the client sends these options, (i) do the server need to reply back with the correct values of these options? (or) (ii) make the server reply only if the option number is filled in ORO option, thus just ignoring the client sending these options. I beleive, (i) is better. If we decide (ii) then there is no meaning in not prohibiting client to send these options. Though, there is no harm in prohibiting the clients to send these options, because, it can anyway get the values using ORO. ~Vijay -----Original Message----- From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org]On Behalf Of Bernie Volz (EUD) Sent: Tuesday, February 18, 2003 8:55 PM To: 'vijayak@india.hp.com'; 'Ralph Droms'; dhcwg@ietf.org Subject: RE: [dhcwg] WG last call on draft-ietf-dhc-dhcpv6-opt-nisconfig-01.txt Personally, I would like to see clients NOT send options to the server but instead just send an ORO option. I see little value in sending the NIS server info to the server - it just increases the packet size and work a server must do to ignore these. ORO is the mechanism to request that a server send an option; not sending the option to the server. For DHCPv4, is there any server that checks options sent by the client to make sure that what it send is valid? What would a server do if it isn't valid - just send the correct value? So, it seems to me ORO is the way to go. Now, of course there are options that must be sent by the client, such as IA options since they carry information from the client to the server (such as the IAID). I don't think we need to PROHIBIT a client from sending the option; but we should not encourage it. A server that receives "unknown" options should just ignore them. - Bernie -----Original Message----- From: Vijayabhaskar A K [mailto:vijayak@india.hp.com] Sent: Tuesday, February 18, 2003 7:36 AM To: 'Bernie Volz (EUD)'; 'Ralph Droms'; dhcwg@ietf.org Subject: RE: [dhcwg] WG last call on draft-ietf-dhc-dhcpv6-opt-nisconfig-01.txt Bernie, Thanks for your comments.... See my reply inline, prefixed by VJ. ~Vijay -----Original Message----- From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org]On Behalf Of Bernie Volz (EUD) Sent: Tuesday, February 18, 2003 2:30 AM To: 'Ralph Droms'; dhcwg@ietf.org Subject: RE: [dhcwg] WG last call on draft-ietf-dhc-dhcpv6-opt-nisconfig-01.txt I fully support the approval of this document for publication. However, I would recommend we review the following section: 8. Appearance of these option The NIS servers, NIS+ servers, NIS domain name and NIS+ domain name options MUST appear only in the following messages: Solicit, Advertise, Request, Confirm, Renew, Rebind, Information-Request, Reply. VJ> Basically, sending these options in messages originating from the VJ> client is for asking the server to provide these information. VJ> Its the alternative way of sending ORO with the option number for these options. VJ> We may want to make a decision here that these options can occur VJ> ONLY in messages originating from server and the client can VJ> indicate the server that it want any of these options by sending ONLY VJ> ORO option, because, client sending these options is of VJ> no interest in the server side, since, its not going to make VJ> any major decision based on the content of this option. VJ> But, it SHOULD be made consistent with ALL service addresses/parameters options. Based on earlier text, these options are for the server to convey information to clients and therefore perhaps text as follows is more appropriate: The NIS servers, NIS+ servers, NIS domain name and NIS+ domain name options MUST appear only in the Advertise and Reply messages. The option numbers for these options may appear in the Option Request Option [2] in Solicit, Request, Renew, Rebind, Information-Request, and Reconfigure messages. VJ> I will add. Or, we want a client to send these options in Request, Renew, Rebind to a server as well? In any case, there is little need for this option itself in Solicit and Confirm (based on the original text). And, some mention of use of the ORO option (at least in Reconfigure) may be appropriate? VJ> OK. I will add. - Bernie -----Original Message----- From: Ralph Droms [mailto:rdroms@cisco.com] Sent: Wednesday, February 12, 2003 3:25 PM To: dhcwg@ietf.org Subject: [dhcwg] WG last call on draft-ietf-dhc-dhcpv6-opt-nisconfig-01.txt This message announces a WG last call on "NIS Configuration Options for DHCPv6" . The last call will conclude on Friday, 2/28. draft-ietf-dhc-dhcpv6-opt-nisconfig-01.txt specifies four DHCPv6 options for configuration information related to Network Information Service (NIS). This draft is available as http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-opt-nisconfig-01.t xt - Ralph Droms _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg ------_=_NextPart_001_01C2D8F3.A3EBE5D6 Content-Type: text/html; charset="ISO-8859-1" RE: [dhcwg] WG last call on draft-ietf-dhc-dhcpv6-opt-nisconfig-0 1.txt

Vijay:

The question really is what do we REQUIRE a server to do. I think there is
NO reason to require a server to do anything with these options. The server
MAY do something (such as sending back the correct value for this options),
but that is not the required behavior.

The required behavior is for the server to send a) those options specified
in the ORO and b) those options that it has configuration information for
(subject to packet size limitations).

I do *NOT* want to add a c) (or move b to c and add a b) of any options
that were included by the client. [And also have to consider what PRIORITY
these options have with respect to the ORO ones and the configured ones.]

Why complicate the picture when this is completely unnecessary.

If your clients (and your server) want to this, there is nothing prohibiting
your client from sending the options and your server processing them in some
non-standard way. However, don't expect this to interoperate with other
servers or clients - those other servers will ignore those options and those
other clients won't send them.

For your clients to interoperate properly, you have to follow the rules
which would require you to send an ORO listing the options you want the
server to send. The client can also include those options in any messages
it sends to the server (but again, most servers will ignore them).

If your clients fail to include any options they want in the ORO, then the
other servers may still send those options but that is because those
options were configured at the server, provided the packet size has not been
exceeded.

- Bernie

-----Original Message-----
From: Vijayabhaskar A K [mailto:vijayak@india.hp.com]
Sent: Thursday, February 20, 2003 7:31 AM
To: 'Bernie Volz (EUD)'; 'Ralph Droms'; dhcwg@ietf.org
Subject: RE: [dhcwg] WG last call on
draft-ietf-dhc-dhcpv6-opt-nisconfig-0 1.txt


Bernie,
I agree that it doesn't imply that.
But this will make the server to ignore an option, for which it
has a valid information and supports it. It doesn't make sense.
If we are going to ignore the option in server side, then
whats the point to "allowing" (Note: i didn't mean "encouraging")
the client to send this option to the server? Its just
going to eatup some bytes of packet.
We have to make decision on either of the following two
i) prohibit the clients to send these options and ignore these
options in the server (to cope up with non RFC conformant clients)
ii) allow client to send these options and let server reply
with the correct values, as if these option numbers were
present in ORO option that client has sent
It doesn't make sense on keeping combination of the both, with
server allowing the clients to send these options and ignoring
it.
~Vijay

-----Original Message-----
From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org]On Behalf Of Bernie
Volz (EUD)
Sent: Thursday, February 20, 2003 3:46 AM
To: 'vijayak@india.hp.com'; 'Ralph Droms'; dhcwg@ietf.org
Subject: RE: [dhcwg] WG last call on draft-ietf-dhc-dhcpv6-opt-nisconfig-0
1.txt


Vijay:
The -28 draft says in 17.2.2. Creation and Transmission of Advertise
Messages:
   The server includes options the server will return to the client in
   a subsequent Reply message.  The information in these options may
   be used by the client in the selection of a server if the client
   receives more than one Advertise message.  If the client has included
   an Option Request option in the Solicit message, the server includes
   options in the Advertise message containing configuration parameters
   for all of the options identified in the Option Request option
   that the server has been configured to return to the client.  The
   server MAY return additional options to the client if it has been
   configured to do so.  The server SHOULD limit the options returned to
   the client so that the DHCP message header and options do not cause
   fragmentation.
And, also in 18.2. Server Behavior:
   In most Reply messages, the server includes options containing
   configuration information for the client.  The server SHOULD limit
   the options returned to the client so that the DHCP message header
   and options do not cause fragmentation.  If the client included an
   Option Request option in its message, the server includes options
   in the Reply message containing configuration parameters for all of
   the options identified in the Option Request option that the server
   has been configured to return to the client.  The server MAY return
   additional options to the client if it has been configured to do so.
In neither case is your (i) implied. The text says include the ORO options
first and then send any other options specified by the server's
configuration.
I don't see a need to clarify this further in -28, but perhaps you (or
others) do?
- Bernie
-----Original Message-----
From: Bernie Volz (EUD) [mailto:Bernie.Volz@am1.ericsson.se]
Sent: Wednesday, February 19, 2003 12:00 PM
To: 'vijayak@india.hp.com'; 'Ralph Droms'; dhcwg@ietf.org
Subject: RE: [dhcwg] WG last call on draft-ietf-dhc-dhcpv6-opt-nisconfig-0
1.txt


I would prefer (ii). A server should not be required to also go through a
packet to see what options the
client sent to send the "correct" information.
The ORO mechanism is the way for a client to request certain options and it
should be the only
mechanism. It simplifies implementations.
If a client sends an option (such as NIS server info), the server should
just ignore it. If that option is
in the ORO, the server should send back the configured information to the
client.
NOTE: The above applies only to those options which are essentially server
to client configuration
options.
- Bernie
-----Original Message-----
From: Vijayabhaskar A K [mailto:vijayak@india.hp.com]
Sent: Wednesday, February 19, 2003 10:39 AM
To: 'Bernie Volz (EUD)'; 'Ralph Droms'; dhcwg@ietf.org
Subject: RE: [dhcwg] WG last call on
draft-ietf-dhc-dhcpv6-opt-nisconfig-01.txt


Bernie,
I agree that client sending this option is no useful to server,
we can stick to ORO. In the case if we decide not to
prohibit client sending these options,
if the client sends these options,
(i) do the server need
to reply back with the correct values of these options?
(or)
(ii) make the server reply only if the option number is
filled in ORO option, thus just ignoring the client sending
these options.
I beleive, (i) is better.
If we decide (ii) then there is no meaning in not prohibiting
client to send these options. Though, there is no harm
in prohibiting the clients to send these options, because,
it can anyway get the values using ORO.
~Vijay
-----Original Message-----
From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org]On Behalf Of Bernie
Volz (EUD)
Sent: Tuesday, February 18, 2003 8:55 PM
To: 'vijayak@india.hp.com'; 'Ralph Droms'; dhcwg@ietf.org
Subject: RE: [dhcwg] WG last call on
draft-ietf-dhc-dhcpv6-opt-nisconfig-01.txt


Personally, I would like to see clients NOT send options to the
server but instead just send an ORO option. I see little value in
sending the NIS server info to the server - it just increases the
packet size and work a server must do to ignore these. ORO is the
mechanism to request that a server send an option; not sending the
option to the server.
For DHCPv4, is there any server that checks options sent by the
client to make sure that what it send is valid? What would a server
do if it isn't valid - just send the correct value? So, it seems to
me ORO is the way to go. Now, of course there are options that must
be sent by the client, such as IA options since they carry information
from the client to the server (such as the IAID).
I don't think we need to PROHIBIT a client from sending the option;
but we should not encourage it. A server that receives "unknown"
options should just ignore them.
- Bernie
-----Original Message-----
From: Vijayabhaskar A K [mailto:vijayak@india.hp.com]
Sent: Tuesday, February 18, 2003 7:36 AM
To: 'Bernie Volz (EUD)'; 'Ralph Droms'; dhcwg@ietf.org
Subject: RE: [dhcwg] WG last call on
draft-ietf-dhc-dhcpv6-opt-nisconfig-01.txt


Bernie,
Thanks for your comments....
See my reply inline, prefixed by VJ.
~Vijay
-----Original Message-----
From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org]On Behalf Of Bernie
Volz (EUD)
Sent: Tuesday, February 18, 2003 2:30 AM
To: 'Ralph Droms'; dhcwg@ietf.org
Subject: RE: [dhcwg] WG last call on
draft-ietf-dhc-dhcpv6-opt-nisconfig-01.txt


I fully support the approval of this document for publication.
However, I would recommend we review the following section:
8. Appearance of these option
   The NIS servers, NIS+ servers, NIS domain name and NIS+ domain name
   options MUST appear only in the following messages: Solicit,
   Advertise, Request, Confirm, Renew, Rebind, Information-Request,
   Reply.
VJ> Basically, sending these options in messages originating from the
VJ> client is for asking the server to provide these information.
VJ> Its the alternative way of sending ORO with the option number for these
options.
VJ> We may want to make a decision here that these options can occur
VJ> ONLY in messages originating from server and the client can
VJ> indicate the server that it want any of these options by sending ONLY
VJ> ORO option, because, client sending these options is of
VJ> no interest in the server side, since, its not going to make
VJ> any major decision based on the content of this option.
VJ> But, it SHOULD be made consistent with ALL service addresses/parameters
options.
Based on earlier text, these options are for the server to convey
information
to clients and therefore perhaps text as follows is more appropriate:
   The NIS servers, NIS+ servers, NIS domain name and NIS+ domain name
   options MUST appear only in the Advertise and Reply messages. The
   option numbers for these options may appear in the Option Request
   Option [2] in Solicit, Request, Renew, Rebind, Information-Request,
   and Reconfigure messages.
VJ> I will add.
Or, we want a client to send these options in Request, Renew, Rebind to
a server as well?
In any case, there is little need for this option itself in Solicit and
Confirm (based on the original text). And, some mention of use of the
ORO option (at least in Reconfigure) may be appropriate?
VJ> OK. I will add.
- Bernie
-----Original Message-----
From: Ralph Droms [mailto:rdroms@cisco.com]
Sent: Wednesday, February 12, 2003 3:25 PM
To: dhcwg@ietf.org
Subject: [dhcwg] WG last call on
draft-ietf-dhc-dhcpv6-opt-nisconfig-01.txt


This message announces a WG last call on "NIS Configuration Options
for DHCPv6" <draft-ietf-dhc-dhcpv6-opt-nisconfig-01.txt>.  The last call
will conclude on Friday, 2/28.
draft-ietf-dhc-dhcpv6-opt-nisconfig-01.txt specifies four DHCPv6 options
for configuration information related to Network Information Service
(NIS).  This draft is available as
http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-opt-nisconfig-01.t
xt
- Ralph Droms


_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg

------_=_NextPart_001_01C2D8F3.A3EBE5D6-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Feb 20 10:22:32 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17454; Thu, 20 Feb 2003 10:22:32 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KFT3p20490; Thu, 20 Feb 2003 10:29:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KFSwp20453 for ; Thu, 20 Feb 2003 10:28:58 -0500 Received: from imr2.ericy.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17419 for ; Thu, 20 Feb 2003 10:21:47 -0500 (EST) Received: from mr5.exu.ericsson.se (mr5att.ericy.com [138.85.224.141]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id h1KFPbb03086; Thu, 20 Feb 2003 09:25:37 -0600 (CST) Received: from eamrcnt760.exu.ericsson.se (eamrcnt760.exu.ericsson.se [138.85.133.38]) by mr5.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id h1KFPbX11461; Thu, 20 Feb 2003 09:25:37 -0600 (CST) Received: by eamrcnt760.exu.ericsson.se with Internet Mail Service (5.5.2656.59) id ; Thu, 20 Feb 2003 09:25:36 -0600 Message-ID: From: "Bernie Volz (EUD)" To: "'vijayak@india.hp.com'" , "'Ralph Droms'" , "'dhcwg@ietf.org'" Subject: RE: [dhcwg] WG last call on draft-ietf-dhc-dhcpv6-opt-nisconfig-0 1.txt Date: Thu, 20 Feb 2003 09:23:58 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2D8F3.E6DB0A84" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2D8F3.E6DB0A84 Content-Type: text/plain; charset="ISO-8859-1" Oh, one more comment: >It doesn't make sense on keeping combination of the both, with >server allowing the clients to send these options and ignoring >it. A server must always be set up to ignore unknown or unexpected options. So, if a client does send an NIS+ server option, a server would ignore it. While it may know the option, the server does not expect these options in messages from clients and therefore SHOULD ignore it. I also agree that it makes little sense of a client to send the option and hence would highly recommend a client not do so (ie, SHOULD NOT). But we have no idea of what new options will be defined and what their semantics may be. Therefore, a server that receives an unknown or unexpected option MUST ignore it. - Bernie -----Original Message----- From: Bernie Volz (EUD) Sent: Thursday, February 20, 2003 10:21 AM To: 'vijayak@india.hp.com'; 'Ralph Droms'; dhcwg@ietf.org Subject: RE: [dhcwg] WG last call on draft-ietf-dhc-dhcpv6-opt-nisconfig-0 1.txt Vijay: The question really is what do we REQUIRE a server to do. I think there is NO reason to require a server to do anything with these options. The server MAY do something (such as sending back the correct value for this options), but that is not the required behavior. The required behavior is for the server to send a) those options specified in the ORO and b) those options that it has configuration information for (subject to packet size limitations). I do *NOT* want to add a c) (or move b to c and add a b) of any options that were included by the client. [And also have to consider what PRIORITY these options have with respect to the ORO ones and the configured ones.] Why complicate the picture when this is completely unnecessary. If your clients (and your server) want to this, there is nothing prohibiting your client from sending the options and your server processing them in some non-standard way. However, don't expect this to interoperate with other servers or clients - those other servers will ignore those options and those other clients won't send them. For your clients to interoperate properly, you have to follow the rules which would require you to send an ORO listing the options you want the server to send. The client can also include those options in any messages it sends to the server (but again, most servers will ignore them). If your clients fail to include any options they want in the ORO, then the other servers may still send those options but that is because those options were configured at the server, provided the packet size has not been exceeded. - Bernie -----Original Message----- From: Vijayabhaskar A K [mailto:vijayak@india.hp.com] Sent: Thursday, February 20, 2003 7:31 AM To: 'Bernie Volz (EUD)'; 'Ralph Droms'; dhcwg@ietf.org Subject: RE: [dhcwg] WG last call on draft-ietf-dhc-dhcpv6-opt-nisconfig-0 1.txt Bernie, I agree that it doesn't imply that. But this will make the server to ignore an option, for which it has a valid information and supports it. It doesn't make sense. If we are going to ignore the option in server side, then whats the point to "allowing" (Note: i didn't mean "encouraging") the client to send this option to the server? Its just going to eatup some bytes of packet. We have to make decision on either of the following two i) prohibit the clients to send these options and ignore these options in the server (to cope up with non RFC conformant clients) ii) allow client to send these options and let server reply with the correct values, as if these option numbers were present in ORO option that client has sent It doesn't make sense on keeping combination of the both, with server allowing the clients to send these options and ignoring it. ~Vijay -----Original Message----- From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org]On Behalf Of Bernie Volz (EUD) Sent: Thursday, February 20, 2003 3:46 AM To: 'vijayak@india.hp.com'; 'Ralph Droms'; dhcwg@ietf.org Subject: RE: [dhcwg] WG last call on draft-ietf-dhc-dhcpv6-opt-nisconfig-0 1.txt Vijay: The -28 draft says in 17.2.2. Creation and Transmission of Advertise Messages: The server includes options the server will return to the client in a subsequent Reply message. The information in these options may be used by the client in the selection of a server if the client receives more than one Advertise message. If the client has included an Option Request option in the Solicit message, the server includes options in the Advertise message containing configuration parameters for all of the options identified in the Option Request option that the server has been configured to return to the client. The server MAY return additional options to the client if it has been configured to do so. The server SHOULD limit the options returned to the client so that the DHCP message header and options do not cause fragmentation. And, also in 18.2. Server Behavior: In most Reply messages, the server includes options containing configuration information for the client. The server SHOULD limit the options returned to the client so that the DHCP message header and options do not cause fragmentation. If the client included an Option Request option in its message, the server includes options in the Reply message containing configuration parameters for all of the options identified in the Option Request option that the server has been configured to return to the client. The server MAY return additional options to the client if it has been configured to do so. In neither case is your (i) implied. The text says include the ORO options first and then send any other options specified by the server's configuration. I don't see a need to clarify this further in -28, but perhaps you (or others) do? - Bernie -----Original Message----- From: Bernie Volz (EUD) [mailto:Bernie.Volz@am1.ericsson.se] Sent: Wednesday, February 19, 2003 12:00 PM To: 'vijayak@india.hp.com'; 'Ralph Droms'; dhcwg@ietf.org Subject: RE: [dhcwg] WG last call on draft-ietf-dhc-dhcpv6-opt-nisconfig-0 1.txt I would prefer (ii). A server should not be required to also go through a packet to see what options the client sent to send the "correct" information. The ORO mechanism is the way for a client to request certain options and it should be the only mechanism. It simplifies implementations. If a client sends an option (such as NIS server info), the server should just ignore it. If that option is in the ORO, the server should send back the configured information to the client. NOTE: The above applies only to those options which are essentially server to client configuration options. - Bernie -----Original Message----- From: Vijayabhaskar A K [mailto:vijayak@india.hp.com] Sent: Wednesday, February 19, 2003 10:39 AM To: 'Bernie Volz (EUD)'; 'Ralph Droms'; dhcwg@ietf.org Subject: RE: [dhcwg] WG last call on draft-ietf-dhc-dhcpv6-opt-nisconfig-01.txt Bernie, I agree that client sending this option is no useful to server, we can stick to ORO. In the case if we decide not to prohibit client sending these options, if the client sends these options, (i) do the server need to reply back with the correct values of these options? (or) (ii) make the server reply only if the option number is filled in ORO option, thus just ignoring the client sending these options. I beleive, (i) is better. If we decide (ii) then there is no meaning in not prohibiting client to send these options. Though, there is no harm in prohibiting the clients to send these options, because, it can anyway get the values using ORO. ~Vijay -----Original Message----- From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org]On Behalf Of Bernie Volz (EUD) Sent: Tuesday, February 18, 2003 8:55 PM To: 'vijayak@india.hp.com'; 'Ralph Droms'; dhcwg@ietf.org Subject: RE: [dhcwg] WG last call on draft-ietf-dhc-dhcpv6-opt-nisconfig-01.txt Personally, I would like to see clients NOT send options to the server but instead just send an ORO option. I see little value in sending the NIS server info to the server - it just increases the packet size and work a server must do to ignore these. ORO is the mechanism to request that a server send an option; not sending the option to the server. For DHCPv4, is there any server that checks options sent by the client to make sure that what it send is valid? What would a server do if it isn't valid - just send the correct value? So, it seems to me ORO is the way to go. Now, of course there are options that must be sent by the client, such as IA options since they carry information from the client to the server (such as the IAID). I don't think we need to PROHIBIT a client from sending the option; but we should not encourage it. A server that receives "unknown" options should just ignore them. - Bernie -----Original Message----- From: Vijayabhaskar A K [mailto:vijayak@india.hp.com] Sent: Tuesday, February 18, 2003 7:36 AM To: 'Bernie Volz (EUD)'; 'Ralph Droms'; dhcwg@ietf.org Subject: RE: [dhcwg] WG last call on draft-ietf-dhc-dhcpv6-opt-nisconfig-01.txt Bernie, Thanks for your comments.... See my reply inline, prefixed by VJ. ~Vijay -----Original Message----- From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org]On Behalf Of Bernie Volz (EUD) Sent: Tuesday, February 18, 2003 2:30 AM To: 'Ralph Droms'; dhcwg@ietf.org Subject: RE: [dhcwg] WG last call on draft-ietf-dhc-dhcpv6-opt-nisconfig-01.txt I fully support the approval of this document for publication. However, I would recommend we review the following section: 8. Appearance of these option The NIS servers, NIS+ servers, NIS domain name and NIS+ domain name options MUST appear only in the following messages: Solicit, Advertise, Request, Confirm, Renew, Rebind, Information-Request, Reply. VJ> Basically, sending these options in messages originating from the VJ> client is for asking the server to provide these information. VJ> Its the alternative way of sending ORO with the option number for these options. VJ> We may want to make a decision here that these options can occur VJ> ONLY in messages originating from server and the client can VJ> indicate the server that it want any of these options by sending ONLY VJ> ORO option, because, client sending these options is of VJ> no interest in the server side, since, its not going to make VJ> any major decision based on the content of this option. VJ> But, it SHOULD be made consistent with ALL service addresses/parameters options. Based on earlier text, these options are for the server to convey information to clients and therefore perhaps text as follows is more appropriate: The NIS servers, NIS+ servers, NIS domain name and NIS+ domain name options MUST appear only in the Advertise and Reply messages. The option numbers for these options may appear in the Option Request Option [2] in Solicit, Request, Renew, Rebind, Information-Request, and Reconfigure messages. VJ> I will add. Or, we want a client to send these options in Request, Renew, Rebind to a server as well? In any case, there is little need for this option itself in Solicit and Confirm (based on the original text). And, some mention of use of the ORO option (at least in Reconfigure) may be appropriate? VJ> OK. I will add. - Bernie -----Original Message----- From: Ralph Droms [mailto:rdroms@cisco.com] Sent: Wednesday, February 12, 2003 3:25 PM To: dhcwg@ietf.org Subject: [dhcwg] WG last call on draft-ietf-dhc-dhcpv6-opt-nisconfig-01.txt This message announces a WG last call on "NIS Configuration Options for DHCPv6" . The last call will conclude on Friday, 2/28. draft-ietf-dhc-dhcpv6-opt-nisconfig-01.txt specifies four DHCPv6 options for configuration information related to Network Information Service (NIS). This draft is available as http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-opt-nisconfig-01.t xt - Ralph Droms _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg ------_=_NextPart_001_01C2D8F3.E6DB0A84 Content-Type: text/html; charset="ISO-8859-1" RE: [dhcwg] WG last call on draft-ietf-dhc-dhcpv6-opt-nisconfig-0 1.txt

Oh, one more comment:

>It doesn't make sense on keeping combination of the both, with
>server allowing the clients to send these options and ignoring
>it.

A server must always be set up to ignore unknown or unexpected options.
So, if a client does send an NIS+ server option, a server would ignore
it. While it may know the option, the server does not expect these
options in messages from clients and therefore SHOULD ignore it.

I also agree that it makes little sense of a client to send the option
and hence would highly recommend a client not do so (ie, SHOULD NOT).
But we have no idea of what new options will be defined and what their
semantics may be. Therefore, a server that receives an unknown or
unexpected option MUST ignore it.

- Bernie

-----Original Message-----
From: Bernie Volz (EUD)
Sent: Thursday, February 20, 2003 10:21 AM
To: 'vijayak@india.hp.com'; 'Ralph Droms'; dhcwg@ietf.org
Subject: RE: [dhcwg] WG last call on
draft-ietf-dhc-dhcpv6-opt-nisconfig-0 1.txt


Vijay:

The question really is what do we REQUIRE a server to do. I think there is
NO reason to require a server to do anything with these options. The server
MAY do something (such as sending back the correct value for this options),
but that is not the required behavior.

The required behavior is for the server to send a) those options specified
in the ORO and b) those options that it has configuration information for
(subject to packet size limitations).

I do *NOT* want to add a c) (or move b to c and add a b) of any options
that were included by the client. [And also have to consider what PRIORITY
these options have with respect to the ORO ones and the configured ones.]

Why complicate the picture when this is completely unnecessary.

If your clients (and your server) want to this, there is nothing prohibiting
your client from sending the options and your server processing them in some
non-standard way. However, don't expect this to interoperate with other
servers or clients - those other servers will ignore those options and those
other clients won't send them.

For your clients to interoperate properly, you have to follow the rules
which would require you to send an ORO listing the options you want the
server to send. The client can also include those options in any messages
it sends to the server (but again, most servers will ignore them).

If your clients fail to include any options they want in the ORO, then the
other servers may still send those options but that is because those
options were configured at the server, provided the packet size has not been
exceeded.

- Bernie

-----Original Message-----
From: Vijayabhaskar A K [mailto:vijayak@india.hp.com]
Sent: Thursday, February 20, 2003 7:31 AM
To: 'Bernie Volz (EUD)'; 'Ralph Droms'; dhcwg@ietf.org
Subject: RE: [dhcwg] WG last call on
draft-ietf-dhc-dhcpv6-opt-nisconfig-0 1.txt


Bernie,
I agree that it doesn't imply that.
But this will make the server to ignore an option, for which it
has a valid information and supports it. It doesn't make sense.
If we are going to ignore the option in server side, then
whats the point to "allowing" (Note: i didn't mean "encouraging")
the client to send this option to the server? Its just
going to eatup some bytes of packet.
We have to make decision on either of the following two
i) prohibit the clients to send these options and ignore these
options in the server (to cope up with non RFC conformant clients)
ii) allow client to send these options and let server reply
with the correct values, as if these option numbers were
present in ORO option that client has sent
It doesn't make sense on keeping combination of the both, with
server allowing the clients to send these options and ignoring
it.
~Vijay

-----Original Message-----
From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org]On Behalf Of Bernie
Volz (EUD)
Sent: Thursday, February 20, 2003 3:46 AM
To: 'vijayak@india.hp.com'; 'Ralph Droms'; dhcwg@ietf.org
Subject: RE: [dhcwg] WG last call on draft-ietf-dhc-dhcpv6-opt-nisconfig-0
1.txt


Vijay:
The -28 draft says in 17.2.2. Creation and Transmission of Advertise
Messages:
   The server includes options the server will return to the client in
   a subsequent Reply message.  The information in these options may
   be used by the client in the selection of a server if the client
   receives more than one Advertise message.  If the client has included
   an Option Request option in the Solicit message, the server includes
   options in the Advertise message containing configuration parameters
   for all of the options identified in the Option Request option
   that the server has been configured to return to the client.  The
   server MAY return additional options to the client if it has been
   configured to do so.  The server SHOULD limit the options returned to
   the client so that the DHCP message header and options do not cause
   fragmentation.
And, also in 18.2. Server Behavior:
   In most Reply messages, the server includes options containing
   configuration information for the client.  The server SHOULD limit
   the options returned to the client so that the DHCP message header
   and options do not cause fragmentation.  If the client included an
   Option Request option in its message, the server includes options
   in the Reply message containing configuration parameters for all of
   the options identified in the Option Request option that the server
   has been configured to return to the client.  The server MAY return
   additional options to the client if it has been configured to do so.
In neither case is your (i) implied. The text says include the ORO options
first and then send any other options specified by the server's
configuration.
I don't see a need to clarify this further in -28, but perhaps you (or
others) do?
- Bernie
-----Original Message-----
From: Bernie Volz (EUD) [mailto:Bernie.Volz@am1.ericsson.se]
Sent: Wednesday, February 19, 2003 12:00 PM
To: 'vijayak@india.hp.com'; 'Ralph Droms'; dhcwg@ietf.org
Subject: RE: [dhcwg] WG last call on draft-ietf-dhc-dhcpv6-opt-nisconfig-0
1.txt


I would prefer (ii). A server should not be required to also go through a
packet to see what options the
client sent to send the "correct" information.
The ORO mechanism is the way for a client to request certain options and it
should be the only
mechanism. It simplifies implementations.
If a client sends an option (such as NIS server info), the server should
just ignore it. If that option is
in the ORO, the server should send back the configured information to the
client.
NOTE: The above applies only to those options which are essentially server
to client configuration
options.
- Bernie
-----Original Message-----
From: Vijayabhaskar A K [mailto:vijayak@india.hp.com]
Sent: Wednesday, February 19, 2003 10:39 AM
To: 'Bernie Volz (EUD)'; 'Ralph Droms'; dhcwg@ietf.org
Subject: RE: [dhcwg] WG last call on
draft-ietf-dhc-dhcpv6-opt-nisconfig-01.txt


Bernie,
I agree that client sending this option is no useful to server,
we can stick to ORO. In the case if we decide not to
prohibit client sending these options,
if the client sends these options,
(i) do the server need
to reply back with the correct values of these options?
(or)
(ii) make the server reply only if the option number is
filled in ORO option, thus just ignoring the client sending
these options.
I beleive, (i) is better.
If we decide (ii) then there is no meaning in not prohibiting
client to send these options. Though, there is no harm
in prohibiting the clients to send these options, because,
it can anyway get the values using ORO.
~Vijay
-----Original Message-----
From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org]On Behalf Of Bernie
Volz (EUD)
Sent: Tuesday, February 18, 2003 8:55 PM
To: 'vijayak@india.hp.com'; 'Ralph Droms'; dhcwg@ietf.org
Subject: RE: [dhcwg] WG last call on
draft-ietf-dhc-dhcpv6-opt-nisconfig-01.txt


Personally, I would like to see clients NOT send options to the
server but instead just send an ORO option. I see little value in
sending the NIS server info to the server - it just increases the
packet size and work a server must do to ignore these. ORO is the
mechanism to request that a server send an option; not sending the
option to the server.
For DHCPv4, is there any server that checks options sent by the
client to make sure that what it send is valid? What would a server
do if it isn't valid - just send the correct value? So, it seems to
me ORO is the way to go. Now, of course there are options that must
be sent by the client, such as IA options since they carry information
from the client to the server (such as the IAID).
I don't think we need to PROHIBIT a client from sending the option;
but we should not encourage it. A server that receives "unknown"
options should just ignore them.
- Bernie
-----Original Message-----
From: Vijayabhaskar A K [mailto:vijayak@india.hp.com]
Sent: Tuesday, February 18, 2003 7:36 AM
To: 'Bernie Volz (EUD)'; 'Ralph Droms'; dhcwg@ietf.org
Subject: RE: [dhcwg] WG last call on
draft-ietf-dhc-dhcpv6-opt-nisconfig-01.txt


Bernie,
Thanks for your comments....
See my reply inline, prefixed by VJ.
~Vijay
-----Original Message-----
From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org]On Behalf Of Bernie
Volz (EUD)
Sent: Tuesday, February 18, 2003 2:30 AM
To: 'Ralph Droms'; dhcwg@ietf.org
Subject: RE: [dhcwg] WG last call on
draft-ietf-dhc-dhcpv6-opt-nisconfig-01.txt


I fully support the approval of this document for publication.
However, I would recommend we review the following section:
8. Appearance of these option
   The NIS servers, NIS+ servers, NIS domain name and NIS+ domain name
   options MUST appear only in the following messages: Solicit,
   Advertise, Request, Confirm, Renew, Rebind, Information-Request,
   Reply.
VJ> Basically, sending these options in messages originating from the
VJ> client is for asking the server to provide these information.
VJ> Its the alternative way of sending ORO with the option number for these
options.
VJ> We may want to make a decision here that these options can occur
VJ> ONLY in messages originating from server and the client can
VJ> indicate the server that it want any of these options by sending ONLY
VJ> ORO option, because, client sending these options is of
VJ> no interest in the server side, since, its not going to make
VJ> any major decision based on the content of this option.
VJ> But, it SHOULD be made consistent with ALL service addresses/parameters
options.
Based on earlier text, these options are for the server to convey
information
to clients and therefore perhaps text as follows is more appropriate:
   The NIS servers, NIS+ servers, NIS domain name and NIS+ domain name
   options MUST appear only in the Advertise and Reply messages. The
   option numbers for these options may appear in the Option Request
   Option [2] in Solicit, Request, Renew, Rebind, Information-Request,
   and Reconfigure messages.
VJ> I will add.
Or, we want a client to send these options in Request, Renew, Rebind to
a server as well?
In any case, there is little need for this option itself in Solicit and
Confirm (based on the original text). And, some mention of use of the
ORO option (at least in Reconfigure) may be appropriate?
VJ> OK. I will add.
- Bernie
-----Original Message-----
From: Ralph Droms [mailto:rdroms@cisco.com]
Sent: Wednesday, February 12, 2003 3:25 PM
To: dhcwg@ietf.org
Subject: [dhcwg] WG last call on
draft-ietf-dhc-dhcpv6-opt-nisconfig-01.txt


This message announces a WG last call on "NIS Configuration Options
for DHCPv6" <draft-ietf-dhc-dhcpv6-opt-nisconfig-01.txt>.  The last call
will conclude on Friday, 2/28.
draft-ietf-dhc-dhcpv6-opt-nisconfig-01.txt specifies four DHCPv6 options
for configuration information related to Network Information Service
(NIS).  This draft is available as
http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-opt-nisconfig-01.t
xt
- Ralph Droms


_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg

------_=_NextPart_001_01C2D8F3.E6DB0A84-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Feb 20 10:24:33 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17570; Thu, 20 Feb 2003 10:24:33 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KFV3p20655; Thu, 20 Feb 2003 10:31:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KFUvp20612 for ; Thu, 20 Feb 2003 10:30:57 -0500 Received: from sj-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17525 for ; Thu, 20 Feb 2003 10:23:48 -0500 (EST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by sj-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h1KFRcSR029612 for ; Thu, 20 Feb 2003 07:27:38 -0800 (PST) Date: Thu, 20 Feb 2003 10:27:38 -0500 (EST) From: Ralph Droms To: dhcwg@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [dhcwg] WG last call on draft-ietf-dhc-pktc-kerb-tckt-00.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This message announces a WG last call on "Kerberos Ticket Control Sub-option for the CableLabs Client Configuration Option" . The last call will conclude on Friday, 2/28. draft-ietf-dhc-pktc-kerb-tckt-00.txt describes a new sub-option of the CableLabs Client Configuration (CCC) DHCP option, which instructs a CableLabs client device to invalidate cached Kerberos tickets. This document is being considered for Proposed Standard as an extension to the CCC option, and is available as http://www.ietf.org/internet-drafts/draft-ietf-dhc-pktc-kerb-tckt-00.txt - Ralph Droms _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Feb 20 11:08:02 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19367; Thu, 20 Feb 2003 11:08:02 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KGEEp24562; Thu, 20 Feb 2003 11:14:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KGC1p24443 for ; Thu, 20 Feb 2003 11:12:01 -0500 Received: from toccata.fugue.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19246 for ; Thu, 20 Feb 2003 11:04:51 -0500 (EST) Received: from nominum.com (az-ben-pm3-2-15.ppp.theriver.com [206.25.50.15]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id h1KG65N10652; Thu, 20 Feb 2003 10:06:05 -0600 (CST) Date: Thu, 20 Feb 2003 09:08:38 -0700 Subject: Re: [dhcwg] WG last call on draft-ietf-dhc-dhcpv6-opt-nisconfig-01.txt Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: dhcwg@ietf.org To: vijayak@india.hp.com From: Ted Lemon In-Reply-To: <001a01c2d8d9$d90cc1f0$38e62a0f@nt23056> Message-Id: <92432C20-44ED-11D7-A12D-00039317663C@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > Sure, the server doesn't need to parse the value in these options, > rather it can note down the option number, skip the option > without processing it and in the reply, it sends back the > "correct" information for that option. I dont think that there is > any harm in allowing this. I agree with you that it's not too hard for the server to go through the options the client sent and make a list from that. The problem is that you're creating additional implementation work and getting no additional benefit in exchange for that work, so it doesn't matter how easy it is. Are you familiar with the phrase, "pecked to death by ducks?" The idea is that each individual peck isn't particularly painful, but when you're pecked enough times, it kills you. If a client might request the NISconfig option by sending it, then the server has to look to see if the client did this, and has to tweak its list of options to send accordingly. Whereas if the ORO is the only way to request an option, then the server doesn't have to do this additional work. So no duck peck. So as Bernie has said, the right way to do this is to _only_ use the ORO to request options. > We have to make decision on either of the following two > i) prohibit the clients to send these options and ignore these > options in the server (to cope up with non RFC conformant clients) This one is okay by me. > ii) allow client to send these options and let server reply > with the correct values, as if these option numbers were > present in ORO option that client has sent This one is not. > It doesn't make sense on keeping combination of the both, with > server allowing the clients to send these options and ignoring > it. The only reason it would make sense to allow the client to send the option would be if there were some meaning to the client sending it - e.g., if it made sense for the client to tell the server what NIS server it wanted, or something like that. Since the draft doesn't specify anything like that (and I don't think it should - again, it would add needless complexity) - it's probably fine to just forbid the client from sending the option. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Feb 20 12:14:17 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21712; Thu, 20 Feb 2003 12:14:16 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KHKdp30784; Thu, 20 Feb 2003 12:20:39 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KHJ1p30675 for ; Thu, 20 Feb 2003 12:19:01 -0500 Received: from rtp-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21669 for ; Thu, 20 Feb 2003 12:11:50 -0500 (EST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h1KHFdJR002725 for ; Thu, 20 Feb 2003 12:15:40 -0500 (EST) Received: from rdroms-w2k.cisco.com (rtp-vpn2-275.cisco.com [10.82.241.19]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id MAA05193 for ; Thu, 20 Feb 2003 12:15:39 -0500 (EST) Message-Id: <4.3.2.7.2.20030220121102.03bbeb68@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 20 Feb 2003 12:15:37 -0500 To: dhcwg@ietf.org From: Ralph Droms Subject: Re: [dhcwg] WG last call on draft-ietf-dhc-dhcpv6-opt-nisconfig-01.txt In-Reply-To: <92432C20-44ED-11D7-A12D-00039317663C@nominum.com> References: <001a01c2d8d9$d90cc1f0$38e62a0f@nt23056> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , I think we already have definitive text in the DHCPv6 base spec, section 17.1.1: The client SHOULD include an Option Request option (see section 22.7) to indicate the options the client is interested in receiving. The client MAY additionally include instances of those options that are identified in the Option Request option with data values as hints to the server about parameter values the client would like to have returned. The phrase "additionally include instances of those options that are identified in the Option Request option" specifically prohibits the inclusion of an option if that option is not identified in the Option Request option... - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Feb 20 12:21:25 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21972; Thu, 20 Feb 2003 12:21:25 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KHS4p31168; Thu, 20 Feb 2003 12:28:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KHRXp31108 for ; Thu, 20 Feb 2003 12:27:33 -0500 Received: from imr2.ericy.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21949 for ; Thu, 20 Feb 2003 12:20:22 -0500 (EST) Received: from mr5.exu.ericsson.se (mr5att.ericy.com [138.85.224.141]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id h1KHODb27797; Thu, 20 Feb 2003 11:24:13 -0600 (CST) Received: from eamrcnt761.exu.ericsson.se (eamrcnt761.exu.ericsson.se [138.85.133.39]) by mr5.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id h1KHOCf02104; Thu, 20 Feb 2003 11:24:13 -0600 (CST) Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2656.59) id ; Thu, 20 Feb 2003 11:24:12 -0600 Message-ID: From: "Bernie Volz (EUD)" To: "'Ralph Droms'" , dhcwg@ietf.org Subject: RE: [dhcwg] WG last call on draft-ietf-dhc-dhcpv6-opt-nisconfig-0 1.txt Date: Thu, 20 Feb 2003 11:22:32 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2D904.69E0993E" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2D904.69E0993E Content-Type: text/plain; charset="iso-8859-1" Thanks Ralph for finding this ... I think that addresses both mine and Vijay's issues. If the client wants the server to send the option, the client must include that option number in the ORO. But, it MAY send a value along which the server may (but need not) use to determine what to respond with. - Bernie -----Original Message----- From: Ralph Droms [mailto:rdroms@cisco.com] Sent: Thursday, February 20, 2003 12:16 PM To: dhcwg@ietf.org Subject: Re: [dhcwg] WG last call on draft-ietf-dhc-dhcpv6-opt-nisconfig-01.txt I think we already have definitive text in the DHCPv6 base spec, section 17.1.1: The client SHOULD include an Option Request option (see section 22.7) to indicate the options the client is interested in receiving. The client MAY additionally include instances of those options that are identified in the Option Request option with data values as hints to the server about parameter values the client would like to have returned. The phrase "additionally include instances of those options that are identified in the Option Request option" specifically prohibits the inclusion of an option if that option is not identified in the Option Request option... - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg ------_=_NextPart_001_01C2D904.69E0993E Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] WG last call on = draft-ietf-dhc-dhcpv6-opt-nisconfig-01.txt

Thanks Ralph for finding this ... I think that = addresses both mine and
Vijay's issues.

If the client wants the server to send the option, = the client must
include that option number in the ORO. But, it MAY = send a value along
which the server may (but need not) use to determine = what to respond
with.

- Bernie

-----Original Message-----
From: Ralph Droms [mailto:rdroms@cisco.com]
Sent: Thursday, February 20, 2003 12:16 PM
To: dhcwg@ietf.org
Subject: Re: [dhcwg] WG last call on
draft-ietf-dhc-dhcpv6-opt-nisconfig-01.txt


I think we already have definitive text in the DHCPv6 = base spec, section
17.1.1:

    The client SHOULD include an = Option Request option (see section 22.7)
    to indicate the options the = client is interested in receiving.  The
    client MAY additionally include = instances of those options that are
    identified in the Option Request = option with data values as hints
    to the server about parameter = values the client would like to have
    returned.

The phrase "additionally include instances of = those options that are
identified in the Option Request option" = specifically prohibits the
inclusion of an option if that option is not = identified in the Option
Request option...

- Ralph

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg

------_=_NextPart_001_01C2D904.69E0993E-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Feb 20 13:00:40 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23170; Thu, 20 Feb 2003 13:00:40 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KI7Ap01684; Thu, 20 Feb 2003 13:07:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KHd2p32398 for ; Thu, 20 Feb 2003 12:39:02 -0500 Received: from shuttle.wide.toshiba.co.jp (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22276 for ; Thu, 20 Feb 2003 12:31:50 -0500 (EST) Received: from localhost (unknown [3ffe:501:100f:f::6]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id E717615215; Fri, 21 Feb 2003 02:35:40 +0900 (JST) Date: Fri, 21 Feb 2003 02:35:41 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Ralph Droms Cc: dhcwg@ietf.org Subject: Re: [dhcwg] WG last call on draft-ietf-dhc-dhcpv6-opt-nisconfig-01.txt In-Reply-To: <4.3.2.7.2.20030220121102.03bbeb68@funnel.cisco.com> References: <001a01c2d8d9$d90cc1f0$38e62a0f@nt23056> <92432C20-44ED-11D7-A12D-00039317663C@nominum.com> <4.3.2.7.2.20030220121102.03bbeb68@funnel.cisco.com> User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.2 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 43 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , >>>>> On Thu, 20 Feb 2003 12:15:37 -0500, >>>>> Ralph Droms said: > I think we already have definitive text in the DHCPv6 base spec, section > 17.1.1: > The client SHOULD include an Option Request option (see section 22.7) > to indicate the options the client is interested in receiving. The > client MAY additionally include instances of those options that are > identified in the Option Request option with data values as hints > to the server about parameter values the client would like to have > returned. > The phrase "additionally include instances of those options that are > identified in the Option Request option" specifically prohibits the > inclusion of an option if that option is not identified in the Option > Request option... Hmm, does this also apply to IA or IA_PD options? Section 17.1.1 explicitly says an IA option is included in Solicit (if the client wants an address for the IA): The client includes IA options for any IAs to which it wants the server to assign addresses. The prefix delegation draft even has a stronger sentence: The requesting router creates an IA_PD and assigns it an IAID. The requesting router MUST include the IA_PD option in the Solicit message. (Section 10.1 of draft-ietf-dhc-dhcpv6-opt-prefix-delegation-02.txt) Is the client also required to include an option request option specifying an IA or IA_PD option? FYI: Our implementation does not include an Option request option for IA_PD option, but I've never seen any interoperability issue with regards to this behavior. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Feb 20 13:03:44 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23327; Thu, 20 Feb 2003 13:03:43 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KIA9p02411; Thu, 20 Feb 2003 13:10:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KI9rp02355 for ; Thu, 20 Feb 2003 13:09:53 -0500 Received: from imr1.ericy.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23292 for ; Thu, 20 Feb 2003 13:02:40 -0500 (EST) Received: from mr5.exu.ericsson.se (mr5u3.ericy.com [208.237.135.124]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id h1KI6Vd22869; Thu, 20 Feb 2003 12:06:31 -0600 (CST) Received: from eamrcnt760.exu.ericsson.se (eamrcnt760.exu.ericsson.se [138.85.133.38]) by mr5.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id h1KI6VY19509; Thu, 20 Feb 2003 12:06:31 -0600 (CST) Received: by eamrcnt760.exu.ericsson.se with Internet Mail Service (5.5.2656.59) id ; Thu, 20 Feb 2003 12:06:31 -0600 Message-ID: From: "Bernie Volz (EUD)" To: "'JINMEI Tatuya / ????'" , Ralph Droms Cc: dhcwg@ietf.org Subject: RE: [dhcwg] WG last call on draft-ietf-dhc-dhcpv6-opt-nisconfig- 01.txt Date: Thu, 20 Feb 2003 12:04:53 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2D90A.912E78FC" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2D90A.912E78FC Content-Type: text/plain; charset="ISO-2022-JP" No, you don't need to include these in an ORO. For options where it is explicitly stated these are used for client to server communication (and also server to client), there is no need to include them in the ORO. This includes IA_NA, IA_TA, and IA_PD. -----Original Message----- From: jinmei@isl.rdc.toshiba.co.jp [mailto:jinmei@isl.rdc.toshiba.co.jp] Sent: Thursday, February 20, 2003 12:36 PM To: Ralph Droms Cc: dhcwg@ietf.org Subject: Re: [dhcwg] WG last call on draft-ietf-dhc-dhcpv6-opt-nisconfig-01.txt >>>>> On Thu, 20 Feb 2003 12:15:37 -0500, >>>>> Ralph Droms said: > I think we already have definitive text in the DHCPv6 base spec, section > 17.1.1: > The client SHOULD include an Option Request option (see section 22.7) > to indicate the options the client is interested in receiving. The > client MAY additionally include instances of those options that are > identified in the Option Request option with data values as hints > to the server about parameter values the client would like to have > returned. > The phrase "additionally include instances of those options that are > identified in the Option Request option" specifically prohibits the > inclusion of an option if that option is not identified in the Option > Request option... Hmm, does this also apply to IA or IA_PD options? Section 17.1.1 explicitly says an IA option is included in Solicit (if the client wants an address for the IA): The client includes IA options for any IAs to which it wants the server to assign addresses. The prefix delegation draft even has a stronger sentence: The requesting router creates an IA_PD and assigns it an IAID. The requesting router MUST include the IA_PD option in the Solicit message. (Section 10.1 of draft-ietf-dhc-dhcpv6-opt-prefix-delegation-02.txt) Is the client also required to include an option request option specifying an IA or IA_PD option? FYI: Our implementation does not include an Option request option for IA_PD option, but I've never seen any interoperability issue with regards to this behavior. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg ------_=_NextPart_001_01C2D90A.912E78FC Content-Type: text/html; charset="ISO-2022-JP" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] WG last call on = draft-ietf-dhc-dhcpv6-opt-nisconfig-01.txt

No, you don't need to include these in an ORO.

For options where it is explicitly stated these are = used for client to
server communication (and also server to client), = there is no need to
include them in the ORO. This includes IA_NA, IA_TA, = and IA_PD.

-----Original Message-----
From: jinmei@isl.rdc.toshiba.co.jp [mailto:jinmei@isl.rdc.toshi= ba.co.jp]
Sent: Thursday, February 20, 2003 12:36 PM
To: Ralph Droms
Cc: dhcwg@ietf.org
Subject: Re: [dhcwg] WG last call on
draft-ietf-dhc-dhcpv6-opt-nisconfig-01.txt


>>>>> On Thu, 20 Feb 2003 12:15:37 = -0500,
>>>>> Ralph Droms = <rdroms@cisco.com> said:

> I think we already have definitive text in the = DHCPv6 base spec, section
> 17.1.1:

>     The client SHOULD = include an Option Request option (see section 22.7)
>     to indicate the options = the client is interested in receiving.  The
>     client MAY additionally = include instances of those options that are
>     identified in the = Option Request option with data values as hints
>     to the server about = parameter values the client would like to have
>     returned.

> The phrase "additionally include instances = of those options that are
> identified in the Option Request option" = specifically prohibits the
> inclusion of an option if that option is not = identified in the Option
> Request option...

Hmm, does this also apply to IA or IA_PD = options?  Section 17.1.1
explicitly says an IA option is included in Solicit = (if the client
wants an address for the IA):

   The client includes IA options for any = IAs to which
   it wants the server to assign = addresses.

The prefix delegation draft even has a stronger = sentence:

   The requesting router creates an IA_PD = and assigns it an IAID.  The
   requesting router MUST include the = IA_PD option in the Solicit
   message.
(Section 10.1 of = draft-ietf-dhc-dhcpv6-opt-prefix-delegation-02.txt)

Is the client also required to include an option = request option
specifying an IA or IA_PD option?

FYI: Our implementation does not include an Option = request option for
IA_PD option, but I've never seen any = interoperability issue with
regards to this behavior.

        =         =         =         =         JINMEI, = Tatuya
        =         =         =         =         Communication = Platform Lab.
        =         =         =         =         Corporate = R&D Center, Toshiba Corp.
        =         =         =         =         jinmei@isl.rdc.toshiba.co.jp
_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg

------_=_NextPart_001_01C2D90A.912E78FC-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Feb 20 13:21:50 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24093; Thu, 20 Feb 2003 13:21:50 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KISMp03447; Thu, 20 Feb 2003 13:28:22 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KIRCp03391 for ; Thu, 20 Feb 2003 13:27:12 -0500 Received: from rtp-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24037 for ; Thu, 20 Feb 2003 13:20:01 -0500 (EST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h1KINdNh029389; Thu, 20 Feb 2003 13:23:44 -0500 (EST) Received: from rdroms-w2k.cisco.com (rtp-vpn2-275.cisco.com [10.82.241.19]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id NAA10567; Thu, 20 Feb 2003 13:23:38 -0500 (EST) Message-Id: <4.3.2.7.2.20030220132022.00ba7a08@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 20 Feb 2003 13:23:33 -0500 To: dhcwg@ietf.org, ips@ece.cmu.edu From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [dhcwg] WG last call on (Reminder!) Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Reminder and note: there has been not response to this WG last call. Please review draft-ietf-dhc-isnsoption-04.txt and reply with comments. If you recommend the document for advancement without revision, please respond with a quick acknowledgment. No response will be interpreted as a lack of support for advancing the document. ----- This message announces a WG last call on "DHCP Options for Internet Storage Name Service" . The last call will conclude on Friday, 2/21. Note that this is a parallel WG last call in the dhc and ips WGs. draft-ietf-dhc-isnsoption-04.txt defines a new DHCP option for discovery of the location and role of iSNS Protocol servers in iSCSI and iFCP devices. The draft is available at http://www.ietf.org/internet-drafts/draft-ietf-dhc-isnsoption-04.txt - Ralph Droms _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Feb 20 13:37:24 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24659; Thu, 20 Feb 2003 13:37:24 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KIhAp04975; Thu, 20 Feb 2003 13:43:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KIgAp04886 for ; Thu, 20 Feb 2003 13:42:10 -0500 Received: from imr2.ericy.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24577 for ; Thu, 20 Feb 2003 13:34:57 -0500 (EST) Received: from mr5.exu.ericsson.se (mr5att.ericy.com [138.85.224.141]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id h1KIclb01864; Thu, 20 Feb 2003 12:38:47 -0600 (CST) Received: from eamrcnt761.exu.ericsson.se (eamrcnt761.exu.ericsson.se [138.85.133.39]) by mr5.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id h1KIckv03323; Thu, 20 Feb 2003 12:38:46 -0600 (CST) Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2656.59) id ; Thu, 20 Feb 2003 12:38:46 -0600 Message-ID: From: "Bernie Volz (EUD)" To: "'rdroms@cisco.com'" Cc: dhcwg@ietf.org Subject: RE: [dhcwg] I-D ACTION:draft-ietf-dhc-unused-optioncodes-00.txt Date: Thu, 20 Feb 2003 12:37:00 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2D90F.0DE97C1C" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2D90F.0DE97C1C Content-Type: text/plain; charset="iso-8859-1" Ralph: This draft looks great. One minor issue. In Abstract you write: Prior to the publication of RFC2939 (which was updated by RFC2489), Shouldn't it have been: Prior to the publication of RFC2489 (which was updated by RFC2939), Also, shouldn't the abstract or the Introduction clearly state why this I-D is being published ... such as: This I-D documents those options that the DHC WG believes are not in use at present and will ask IANA to return to the available option pool for eventual reassignment per RFC2939 (or its predecessors). Comments are solicited if DHCP client or server implementations exist that use and require these options. Also, does it make sense to consider asking IANA to reserve say option 127 for possible use as an extension option should there ever be a need rather than releasing it for general reassignment? I'm not clear why two option numbers were originally selected, so perhaps two should be reserved? My reasoning is that even with the RFC 2939 procedures, it does require someone (the DHC WG?) to monitor the options usage and make sure that a timely I-D (and RFC) are produced to assure the last option is never assigned (or at least properly assigned to permit extensions). As we have no idea how long the DHC WG will be around, it may be prudent to reserve an option now? - Bernie -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Sent: Thursday, February 20, 2003 7:36 AM Cc: dhcwg@ietf.org Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-unused-optioncodes-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 : Unused DHCP Option Codes Author(s) : R. Droms Filename : draft-ietf-dhc-unused-optioncodes-00.txt Pages : 8 Date : 2003-2-19 Prior to the publication of RFC2939 (which was updated by RFC2489), several option codes were assigned to proposed DHCP options that were subsequently never used. This document lists those unused option codes and will be used to confirm that these option codes can be reused for other DHCP options in the future. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-unused-optioncodes-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-unused-optioncodes-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-unused-optioncodes-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_001_01C2D90F.0DE97C1C Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] I-D = ACTION:draft-ietf-dhc-unused-optioncodes-00.txt

Ralph:

This draft looks great.

One minor issue. In Abstract you write:

   Prior to the publication of RFC2939 = (which was updated by RFC2489),

Shouldn't it have been:
   Prior to the publication of RFC2489 = (which was updated by RFC2939),


Also, shouldn't the abstract or the Introduction = clearly state why this
I-D is being published ... such as:

   This I-D documents those options that = the DHC WG believes are not
   in use at present and will ask IANA to = return to the available option
   pool for eventual reassignment per = RFC2939 (or its predecessors).
   Comments are solicited if DHCP client = or server implementations exist
   that use and require these = options.


Also, does it make sense to consider asking IANA to = reserve say option
127 for possible use as an extension option should = there ever be a need
rather than releasing it for general reassignment? = I'm not clear why two
option numbers were originally selected, so perhaps = two should be
reserved?

My reasoning is that even with the RFC 2939 = procedures, it does require
someone (the DHC WG?) to monitor the options usage = and make sure that
a timely I-D (and RFC) are produced to assure the = last option is never
assigned (or at least properly assigned to permit = extensions). As we
have no idea how long the DHC WG will be around, it = may be prudent to
reserve an option now?

- Bernie

-----Original Message-----
From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org= ]
Sent: Thursday, February 20, 2003 7:36 AM
Cc: dhcwg@ietf.org
Subject: [dhcwg] I-D = ACTION:draft-ietf-dhc-unused-optioncodes-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           : = Unused DHCP Option Codes
        Author(s)       : R. = Droms
        Filename        : = draft-ietf-dhc-unused-optioncodes-00.txt
        Pages           : = 8
        Date    =         : 2003-2-19
       =20
Prior to the publication of RFC2939 (which was = updated by RFC2489),
several option codes were assigned to proposed DHCP = options that were
subsequently never used.  This document lists = those unused option
codes and will be used to confirm that these option = codes can be
reused for other DHCP options in the future.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-dhc-unu= sed-optioncodes-00.txt

To remove yourself from the IETF Announcement list, = send a message to
ietf-announce-request with the word unsubscribe in = the body of the message.

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-unused-optioncodes-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-unused-optioncodes-00.txt".
       =20
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.
        =        =20
        =        =20
Below is the data which will enable a MIME compliant = mail reader
implementation to automatically retrieve the ASCII = version of the
Internet-Draft.

------_=_NextPart_001_01C2D90F.0DE97C1C-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Feb 20 13:46:36 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24998; Thu, 20 Feb 2003 13:46:36 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KIr7p05461; Thu, 20 Feb 2003 13:53:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KIqsp05430 for ; Thu, 20 Feb 2003 13:52:54 -0500 Received: from rtp-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24990 for ; Thu, 20 Feb 2003 13:45:43 -0500 (EST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h1KInVNh001012 for ; Thu, 20 Feb 2003 13:49:31 -0500 (EST) Received: from rdroms-w2k.cisco.com (rtp-vpn2-275.cisco.com [10.82.241.19]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id NAA12998 for ; Thu, 20 Feb 2003 13:49:30 -0500 (EST) Message-Id: <4.3.2.7.2.20030220134341.03e75378@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 20 Feb 2003 13:49:23 -0500 To: dhcwg@ietf.org From: Ralph Droms Subject: RE: [dhcwg] I-D ACTION:draft-ietf-dhc-unused-optioncodes-00.txt In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Bernie - thanks for the feedback. Comments in line... - Ralph At 12:37 PM 2/20/2003 -0600, Bernie Volz (EUD) wrote: >Ralph: > >This draft looks great. > >One minor issue. In Abstract you write: > > Prior to the publication of RFC2939 (which was updated by RFC2489), > >Shouldn't it have been: > Prior to the publication of RFC2489 (which was updated by RFC2939), Of course - good catch. > > >Also, shouldn't the abstract or the Introduction clearly state why this >I-D is being published ... such as: > > This I-D documents those options that the DHC WG believes are not > in use at present and will ask IANA to return to the available option > pool for eventual reassignment per RFC2939 (or its predecessors). > Comments are solicited if DHCP client or server implementations exist > that use and require these options. What I had in mind is: * make an IETF-wide announcement about the draft (following up on the automatic publication announcement), specifically asking for input such as you suggest * accept input and updating the draft as appropriate * turn the draft into an Informational RFC directing IANA to mark the unused options as "available" I suppose it wouldn't hurt to also add the text you suggest at the front of the current I-D. >Also, does it make sense to consider asking IANA to reserve say option >127 for possible use as an extension option should there ever be a need >rather than releasing it for general reassignment? I'm not clear why two >option numbers were originally selected, so perhaps two should be >reserved? > >My reasoning is that even with the RFC 2939 procedures, it does require >someone (the DHC WG?) to monitor the options usage and make sure that >a timely I-D (and RFC) are produced to assure the last option is never >assigned (or at least properly assigned to permit extensions). As we >have no idea how long the DHC WG will be around, it may be prudent to >reserve an option now? Well, I thought that was a good idea, too, when I proposed it some years ago. At the time, the WG rejected the plan as a bad idea... > > >- Bernie > >-----Original Message----- >From: Internet-Drafts@ietf.org >[mailto:Internet-Drafts@ietf.org] >Sent: Thursday, February 20, 2003 7:36 AM >Cc: dhcwg@ietf.org >Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-unused-optioncodes-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 : Unused DHCP Option Codes > Author(s) : R. Droms > Filename : draft-ietf-dhc-unused-optioncodes-00.txt > Pages : 8 > Date : 2003-2-19 > >Prior to the publication of RFC2939 (which was updated by RFC2489), >several option codes were assigned to proposed DHCP options that were >subsequently never used. This document lists those unused option >codes and will be used to confirm that these option codes can be >reused for other DHCP options in the future. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-dhc-unused-optioncodes-00.txt > > >To remove yourself from the IETF Announcement list, send a message to >ietf-announce-request with the word unsubscribe in the body of the message. > >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-unused-optioncodes-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-unused-optioncodes-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. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Feb 20 13:54:32 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25219; Thu, 20 Feb 2003 13:54:32 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KJ16p05838; Thu, 20 Feb 2003 14:01:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KJ0Qp05796 for ; Thu, 20 Feb 2003 14:00:26 -0500 Received: from rtp-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25201 for ; Thu, 20 Feb 2003 13:53:15 -0500 (EST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h1KIv2JR009522; Thu, 20 Feb 2003 13:57:03 -0500 (EST) Received: from rdroms-w2k.cisco.com (rtp-vpn2-275.cisco.com [10.82.241.19]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id NAA13590; Thu, 20 Feb 2003 13:57:00 -0500 (EST) Message-Id: <4.3.2.7.2.20030220135524.03e6d548@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 20 Feb 2003 13:56:59 -0500 To: dhcwg@ietf.org, ipng@sunroof.eng.sun.com, namedroppers@ops.ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [dhcwg] WG last call on draft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Reminder and note: there have been a few responses to this WG last call, but no explicit positive recommendations for advancement. Please review draft-ietf-dhc-dhcpv6 opt-dnsconfig-02.txt and reply with comments. If you recommend the document for advancement without revision, please respond with a quick acknowledgment. No response will be interpreted as a lack of support for advancing the document. ----- This message announces a WG last call on "DNS Configuration options for DHCPv6" . The last call will conclude on Friday, 2/21. Note that this is a parallel WG last call in the dhc, ipv6 and dnsext WGs. draft-ietf-dhc-dhcpv6 opt-dnsconfig-02.txt describes two options for DHCPv6: the Domain Name Server option and the Domain Search List option. This document is being considered for Proposed Standard as an extension to the base DHCPv6 specification, and is available as http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt - Ralph Droms _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Feb 20 14:04:37 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25654; Thu, 20 Feb 2003 14:04:37 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KJBBp07076; Thu, 20 Feb 2003 14:11:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KJAdp07038 for ; Thu, 20 Feb 2003 14:10:39 -0500 Received: from ariel.nishansystems.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25621 for ; Thu, 20 Feb 2003 14:03:27 -0500 (EST) Received: by ariel.nishansystems.com with Internet Mail Service (5.5.2653.19) id ; Thu, 20 Feb 2003 11:07:11 -0800 Message-ID: From: Charles Monia To: "'Ralph Droms'" , dhcwg@ietf.org, ips@ece.cmu.edu Subject: RE: [dhcwg] WG last call on (R eminder!) Date: Thu, 20 Feb 2003 11:07:10 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Hi: With co-author's hat on, I believe the spec is ready to go forward. Charles > -----Original Message----- > From: Ralph Droms [mailto:rdroms@cisco.com] > Sent: Thursday, February 20, 2003 10:24 AM > To: dhcwg@ietf.org; ips@ece.cmu.edu > Subject: [dhcwg] WG last call on > (Reminder!) > > > Reminder and note: there has been not response to this WG last > call. Please review draft-ietf-dhc-isnsoption-04.txt and reply with > comments. If you recommend the document for advancement > without revision, > please respond with a quick acknowledgment. No response will be > interpreted as a lack of support for advancing the document. > > ----- > > This message announces a WG last call on "DHCP Options for > Internet Storage > Name Service" . The last call will > conclude on Friday, 2/21. > > Note that this is a parallel WG last call in the dhc and ips WGs. > > draft-ietf-dhc-isnsoption-04.txt defines a new DHCP option > for discovery of > the location and role of iSNS Protocol servers in iSCSI and iFCP > devices. The draft is available at > http://www.ietf.org/internet-drafts/draft-ietf-dhc-isnsoption-04.txt > > - Ralph Droms > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Feb 20 14:44:03 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27074; Thu, 20 Feb 2003 14:44:03 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KJoep10101; Thu, 20 Feb 2003 14:50:40 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KJhpp09620 for ; Thu, 20 Feb 2003 14:43:51 -0500 Received: from patan.sun.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26839 for ; Thu, 20 Feb 2003 14:36:38 -0500 (EST) Received: from esunmail ([129.147.58.198]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA08135 for ; Thu, 20 Feb 2003 12:40:28 -0700 (MST) Received: from xpa-fe2 ([129.147.58.198]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.08 (built Dec 6 2002)) with ESMTP id <0HAM00MBGHBF5O@edgemail1.Central.Sun.COM> for dhcwg@ietf.org; Thu, 20 Feb 2003 12:40:28 -0700 (MST) Received: from sun.com ([129.146.10.23]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.08 (built Dec 6 2002)) with ESMTPSA id <0HAM007HQHBECA@mail.sun.net> for dhcwg@ietf.org; Thu, 20 Feb 2003 12:40:27 -0700 (MST) Date: Thu, 20 Feb 2003 11:40:26 -0800 From: Alain Durand To: Ralph Droms Cc: dhcwg@ietf.org, ipng@sunroof.eng.sun.com, namedroppers@ops.ietf.org Message-id: <3E552F2A.2090302@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.0.1) Gecko/20020920 Netscape/7.0 References: <4.3.2.7.2.20030220135524.03e6d548@funnel.cisco.com> Content-Transfer-Encoding: 7BIT Subject: [dhcwg] Re: WG last call on draft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT From a quick look at the draft: 4. Domain Name Server option The Domain Name Server option provides a list of one or more IP addresses of DNS servers to which a client's DNS resolver MAY send DNS queries [2]. The DNS servers are listed in the order of preference for use by the client resolver. The format of the Domain Name Server option is: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OPTION_DNS_SERVERS | option-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | DNS-server (IP address) | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | DNS-server (IP address) | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Are the IP addresses of the DNS servers IPv4 ones or IPv6 ones? How would the DHCP client knows? From the width of the boxes, one could think it it is v4 addresses, but from the height (4 lines!), one could think it is actually v6 addresses. My points are: - the spec is unclear if those addresses are v4 or v6 - it may makes sense to actually mix both type in an announcement, for example say: try this v6 address, if it does not work, try this v4 one. Then each DNS server entry should have both the actual address and its family. - Alain. Ralph Droms wrote: > Reminder and note: there have been a few responses to this WG last > call, but no explicit positive recommendations for advancement. > Please review draft-ietf-dhc-dhcpv6 opt-dnsconfig-02.txt and reply > with comments. If you recommend the document for advancement without > revision, please respond with a quick acknowledgment. No response > will be interpreted as a lack of support for advancing the document. > > ----- > > This message announces a WG last call on "DNS Configuration options > for DHCPv6" . The last > call will conclude on Friday, 2/21. > > Note that this is a parallel WG last call in the dhc, ipv6 and dnsext > WGs. > > draft-ietf-dhc-dhcpv6 opt-dnsconfig-02.txt describes two options for > DHCPv6: the Domain Name Server option and the Domain Search List > option. This document is being considered for Proposed Standard as an > extension to the base DHCPv6 specification, and is available as > http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt > > > - Ralph Droms > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Feb 20 14:52:24 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27330; Thu, 20 Feb 2003 14:52:24 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KJx3p10448; Thu, 20 Feb 2003 14:59:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KJwep10428 for ; Thu, 20 Feb 2003 14:58:40 -0500 Received: from rtp-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27308 for ; Thu, 20 Feb 2003 14:51:26 -0500 (EST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h1KJtEJR013584; Thu, 20 Feb 2003 14:55:15 -0500 (EST) Received: from rdroms-w2k.cisco.com (rtp-vpn2-275.cisco.com [10.82.241.19]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA18996; Thu, 20 Feb 2003 14:55:13 -0500 (EST) Message-Id: <4.3.2.7.2.20030220143854.03e69358@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 20 Feb 2003 14:55:11 -0500 To: dhcwg@ietf.org, ipng@sunroof.eng.sun.com, namedroppers@ops.ietf.org From: Ralph Droms In-Reply-To: <200302101927.h1AJRdu16843@grimsvotn.TechFak.Uni-Bielefeld. DE> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [dhcwg] Re: WG last call on draft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Thanks for your feedback, Peter; my comments in line... - Ralph At 08:27 PM 2/10/2003 +0100, Peter Koch wrote: > > draft-ietf-dhc-dhcpv6 opt-dnsconfig-02.txt describes two options for > > DHCPv6: the Domain Name Server option and the Domain Search List > > > This document uses terminology specific to IPv6 and DHCPv6 as defined > > in section "Terminology" of the DHCP specification. > >Might want to add an explicit normative reference here? OK. > > 4. Domain Name Server option > > > > The Domain Name Server option provides a list of one or more IP > > addresses of DNS servers to which a client's DNS resolver MAY send > > >From a purist's point of view I'm tempted to say that you're not really > looking >for a DNS server here but instead for a (list of) recursive resolvers. Should this sentence read (I'm not a DNS purist!): The Domain Name Server option provides a list of one or more IP addresses of DNS recursive resolvers to which a client's DNS resolver MAY send DNS queries [2]. > > DNS-server: IP address of DNS server (change to "DNS recursive resolver"?) >I did not follow the DHCPv6 effort too close, so I must admit not knowing >the usual "culture", but wouldn't it be better to say IPv6 address here? Yes; also see follow up by Alain Durand. > > A server sends a Domain Search List option to the DHCP client to > > specify the domain search list the client is to use when resolving > > hostnames with DNS. This option does not apply to other name > > resolution mechanisms. > >The draft does not say for which kind of domain names the client is expected >to process the list, i.e. one-label names only, n-label names (how to >communicate the 'n', aka 'ndots', then?) or whether this is left to the >application(s). > > > Because the Domain Search List option may be used to spoof DNS name > > resolution in a way that cannot be detected by DNS security > > mechanisms like DNSSEC [5], DHCP clients and servers MUST use > >Apart from the sad fact that DNSSEC isn't yet deployed I don't see why it >wouldn't be able to detect spoofing. If, however, you want to say that >using domain names in the search list you don't control is a dangerous >thing, that could be emphazised by a reference to RFC 1535. The idea here (note that I'm not a DNSSEC expert, either) is that a search list that the host doesn't control might still pass DNSSEC authentication while yielding unexpected results. I would be happy to hear that DNSSEC can prevent the problem and would be willing to follow your suggestion and replace the reference to DNSSEC with a more general reference to untrusted search lists. > > authenticated DHCP when a Domain Search List option is included in a > > DHCP message. > >Why is this a MUST while there's a SHOULD only for the server option? They probably both should have the same level of requirement; I would think SHOULD would be sufficient for both. >-Peter > >-- >to unsubscribe send a message to namedroppers-request@ops.ietf.org with >the word 'unsubscribe' in a single line as the message text body. >archive: _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Feb 20 15:01:37 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27634; Thu, 20 Feb 2003 15:01:37 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KK8Bp11538; Thu, 20 Feb 2003 15:08:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KK7Fp11140 for ; Thu, 20 Feb 2003 15:07:15 -0500 Received: from rtp-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27601 for ; Thu, 20 Feb 2003 15:00:01 -0500 (EST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h1KK3oJR014151; Thu, 20 Feb 2003 15:03:50 -0500 (EST) Received: from rdroms-w2k.cisco.com (rtp-vpn2-275.cisco.com [10.82.241.19]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id PAA19859; Thu, 20 Feb 2003 15:03:49 -0500 (EST) Message-Id: <4.3.2.7.2.20030220150155.03e6d448@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 20 Feb 2003 15:03:44 -0500 To: dhcwg@ietf.org, ipng@sunroof.eng.sun.com, namedroppers@ops.ietf.org From: Ralph Droms Subject: Re: [dhcwg] Re: WG last call on draft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt In-Reply-To: <3E552F2A.2090302@sun.com> References: <4.3.2.7.2.20030220135524.03e6d548@funnel.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Alain, If it's unclear, then we should edit the document to explicitly identify the addresses as IPv6 addresses. This option is intended to return IPv6 configuration information. IPv4 addresses for DNS resolvers should be provided through DHCPv4... - Ralph At 11:40 AM 2/20/2003 -0800, Alain Durand wrote: > From a quick look at the draft: > >4. Domain Name Server option > > The Domain Name Server option provides a list of one or more IP > addresses of DNS servers to which a client's DNS resolver MAY send > DNS queries [2]. The DNS servers are listed in the order of > preference for use by the client resolver. > > The format of the Domain Name Server option is: > > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | OPTION_DNS_SERVERS | option-len | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > | DNS-server (IP address) | > | | > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > | DNS-server (IP address) | > | | > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | ... | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > >Are the IP addresses of the DNS servers IPv4 ones or IPv6 ones? >How would the DHCP client knows? > From the width of the boxes, one could think it it is v4 addresses, >but from the height (4 lines!), one could think it is actually v6 addresses. > >My points are: >- the spec is unclear if those addresses are v4 or v6 >- it may makes sense to actually mix both type in an announcement, > for example say: try this v6 address, if it does not work, try this v4 one. > Then each DNS server entry should have both the actual address and its > family. > > - Alain. > > >Ralph Droms wrote: > >>Reminder and note: there have been a few responses to this WG last call, >>but no explicit positive recommendations for advancement. >>Please review draft-ietf-dhc-dhcpv6 opt-dnsconfig-02.txt and reply with >>comments. If you recommend the document for advancement without >>revision, please respond with a quick acknowledgment. No response will >>be interpreted as a lack of support for advancing the document. >> >>----- >> >>This message announces a WG last call on "DNS Configuration options for >>DHCPv6" . The last call will >>conclude on Friday, 2/21. >> >>Note that this is a parallel WG last call in the dhc, ipv6 and dnsext WGs. >> >>draft-ietf-dhc-dhcpv6 opt-dnsconfig-02.txt describes two options for >>DHCPv6: the Domain Name Server option and the Domain Search List >>option. This document is being considered for Proposed Standard as an >>extension to the base DHCPv6 specification, and is available as >>http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt >> >>- Ralph Droms >> >>-------------------------------------------------------------------- >>IETF IPng Working Group Mailing List >>IPng Home Page: http://playground.sun.com/ipng >>FTP archive: ftp://playground.sun.com/pub/ipng >>Direct all administrative requests to majordomo@sunroof.eng.sun.com >>-------------------------------------------------------------------- > > > >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Feb 20 15:14:55 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28007; Thu, 20 Feb 2003 15:14:55 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KKLLp12152; Thu, 20 Feb 2003 15:21:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KKKrp12070 for ; Thu, 20 Feb 2003 15:20:53 -0500 Received: from toccata.fugue.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27983 for ; Thu, 20 Feb 2003 15:13:40 -0500 (EST) Received: from nominum.com (az-ben-pm3-2-15.ppp.theriver.com [206.25.50.15]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id h1KKEoN12781; Thu, 20 Feb 2003 14:14:50 -0600 (CST) Date: Thu, 20 Feb 2003 13:17:26 -0700 Subject: Re: [dhcwg] WG last call on draft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: dhcwg@ietf.org, ipng@sunroof.eng.sun.com, namedroppers@ops.ietf.org To: Ralph Droms From: Ted Lemon In-Reply-To: <4.3.2.7.2.20030220135524.03e6d548@funnel.cisco.com> Message-Id: <5448A21C-4510-11D7-A12D-00039317663C@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I thought I had said that I thought it should go ahead, but maybe not explicitly. I would like to see this draft advance. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Feb 20 15:39:43 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28903; Thu, 20 Feb 2003 15:39:43 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KKkKp14273; Thu, 20 Feb 2003 15:46:20 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KKjwp14203 for ; Thu, 20 Feb 2003 15:45:58 -0500 Received: from imr1.ericy.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28845 for ; Thu, 20 Feb 2003 15:38:42 -0500 (EST) Received: from mr5.exu.ericsson.se (mr5u3.ericy.com [208.237.135.124]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id h1KKgWd11195; Thu, 20 Feb 2003 14:42:32 -0600 (CST) Received: from eamrcnt761.exu.ericsson.se (eamrcnt761.exu.ericsson.se [138.85.133.39]) by mr5.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id h1KKgV026013; Thu, 20 Feb 2003 14:42:31 -0600 (CST) Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2656.59) id ; Thu, 20 Feb 2003 14:42:31 -0600 Message-ID: From: "Bernie Volz (EUD)" To: "'Ralph Droms'" , dhcwg@ietf.org Subject: RE: [dhcwg] I-D ACTION:draft-ietf-dhc-unused-optioncodes-00.txt Date: Thu, 20 Feb 2003 14:40:45 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2D91F.E2E642F0" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2D91F.E2E642F0 Content-Type: text/plain; charset="iso-8859-1" >Well, I thought that was a good idea, too, when I proposed it >some years ago. At the time, the WG rejected the plan as >a bad idea... As we didn't have the concat draft, perhaps that was why the WG thought it was a bad idea? Or was there some other reason(s)? Is this perhaps a work item that the WG should take on (in many ways I think there may never be a need so perhaps this is nothing to worry about) ... or is there some other action we can request of IANA to prevent assignment of the last [few] option[s] just in case? Should this be an agenda item for the SF IETF DHC WG? (Note that I'm not yet certain I'll be there, so if you want you can add the topic under my name but someone else may have to handle it.) - Bernie -----Original Message----- From: Ralph Droms [mailto:rdroms@cisco.com] Sent: Thursday, February 20, 2003 1:49 PM To: dhcwg@ietf.org Subject: RE: [dhcwg] I-D ACTION:draft-ietf-dhc-unused-optioncodes-00.txt Bernie - thanks for the feedback. Comments in line... - Ralph At 12:37 PM 2/20/2003 -0600, Bernie Volz (EUD) wrote: >Ralph: > >This draft looks great. > >One minor issue. In Abstract you write: > > Prior to the publication of RFC2939 (which was updated by RFC2489), > >Shouldn't it have been: > Prior to the publication of RFC2489 (which was updated by RFC2939), Of course - good catch. > > >Also, shouldn't the abstract or the Introduction clearly state why this >I-D is being published ... such as: > > This I-D documents those options that the DHC WG believes are not > in use at present and will ask IANA to return to the available option > pool for eventual reassignment per RFC2939 (or its predecessors). > Comments are solicited if DHCP client or server implementations exist > that use and require these options. What I had in mind is: * make an IETF-wide announcement about the draft (following up on the automatic publication announcement), specifically asking for input such as you suggest * accept input and updating the draft as appropriate * turn the draft into an Informational RFC directing IANA to mark the unused options as "available" I suppose it wouldn't hurt to also add the text you suggest at the front of the current I-D. >Also, does it make sense to consider asking IANA to reserve say option >127 for possible use as an extension option should there ever be a need >rather than releasing it for general reassignment? I'm not clear why two >option numbers were originally selected, so perhaps two should be >reserved? > >My reasoning is that even with the RFC 2939 procedures, it does require >someone (the DHC WG?) to monitor the options usage and make sure that >a timely I-D (and RFC) are produced to assure the last option is never >assigned (or at least properly assigned to permit extensions). As we >have no idea how long the DHC WG will be around, it may be prudent to >reserve an option now? Well, I thought that was a good idea, too, when I proposed it some years ago. At the time, the WG rejected the plan as a bad idea... > > >- Bernie > >-----Original Message----- >From: Internet-Drafts@ietf.org >[mailto:Internet-Drafts@ietf.org] >Sent: Thursday, February 20, 2003 7:36 AM >Cc: dhcwg@ietf.org >Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-unused-optioncodes-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 : Unused DHCP Option Codes > Author(s) : R. Droms > Filename : draft-ietf-dhc-unused-optioncodes-00.txt > Pages : 8 > Date : 2003-2-19 > >Prior to the publication of RFC2939 (which was updated by RFC2489), >several option codes were assigned to proposed DHCP options that were >subsequently never used. This document lists those unused option >codes and will be used to confirm that these option codes can be >reused for other DHCP options in the future. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-dhc-unused-optioncodes-00.txt > > >To remove yourself from the IETF Announcement list, send a message to >ietf-announce-request with the word unsubscribe in the body of the message. > >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-unused-optioncodes-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-unused-optioncodes-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. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg ------_=_NextPart_001_01C2D91F.E2E642F0 Content-Type: text/html; charset="iso-8859-1" RE: [dhcwg] I-D ACTION:draft-ietf-dhc-unused-optioncodes-00.txt

>Well, I thought that was a good idea, too, when I proposed it
>some years ago.  At the time, the WG rejected the plan as
>a bad idea...

As we didn't have the concat draft, perhaps that was why the WG thought
it was a bad idea? Or was there some other reason(s)?

Is this perhaps a work item that the WG should take on (in many ways I
think there may never be a need so perhaps this is nothing to worry
about) ... or is there some other action we can request of IANA to prevent
assignment of the last [few] option[s] just in case?

Should this be an agenda item for the SF IETF DHC WG? (Note that I'm not
yet certain I'll be there, so if you want you can add the topic under my name
but someone else may have to handle it.)

- Bernie

-----Original Message-----
From: Ralph Droms [mailto:rdroms@cisco.com]
Sent: Thursday, February 20, 2003 1:49 PM
To: dhcwg@ietf.org
Subject: RE: [dhcwg] I-D ACTION:draft-ietf-dhc-unused-optioncodes-00.txt


Bernie - thanks for the feedback.  Comments in line...

- Ralph

At 12:37 PM 2/20/2003 -0600, Bernie Volz (EUD) wrote:

>Ralph:
>
>This draft looks great.
>
>One minor issue. In Abstract you write:
>
>    Prior to the publication of RFC2939 (which was updated by RFC2489),
>
>Shouldn't it have been:
>    Prior to the publication of RFC2489 (which was updated by RFC2939),

Of course - good catch.

>
>
>Also, shouldn't the abstract or the Introduction clearly state why this
>I-D is being published ... such as:
>
>    This I-D documents those options that the DHC WG believes are not
>    in use at present and will ask IANA to return to the available option
>    pool for eventual reassignment per RFC2939 (or its predecessors).
>    Comments are solicited if DHCP client or server implementations exist
>    that use and require these options.

What I had in mind is:

* make an IETF-wide announcement about the draft (following
   up on the automatic publication announcement), specifically
   asking for input such as you suggest
* accept input and updating the draft as appropriate
* turn the draft into an Informational RFC directing IANA
   to mark the unused options as "available"

I suppose it wouldn't hurt to also add the text you suggest
at the front of the current I-D.


>Also, does it make sense to consider asking IANA to reserve say option
>127 for possible use as an extension option should there ever be a need
>rather than releasing it for general reassignment? I'm not clear why two
>option numbers were originally selected, so perhaps two should be
>reserved?
>
>My reasoning is that even with the RFC 2939 procedures, it does require
>someone (the DHC WG?) to monitor the options usage and make sure that
>a timely I-D (and RFC) are produced to assure the last option is never
>assigned (or at least properly assigned to permit extensions). As we
>have no idea how long the DHC WG will be around, it may be prudent to
>reserve an option now?

Well, I thought that was a good idea, too, when I proposed it
some years ago.  At the time, the WG rejected the plan as
a bad idea...

>
>
>- Bernie
>
>-----Original Message-----
>From: Internet-Drafts@ietf.org
>[<mailto:Internet-Drafts@ietf.org>mailto:Internet-Drafts@ietf.org]
>Sent: Thursday, February 20, 2003 7:36 AM
>Cc: dhcwg@ietf.org
>Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-unused-optioncodes-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           : Unused DHCP Option Codes
>         Author(s)       : R. Droms
>         Filename        : draft-ietf-dhc-unused-optioncodes-00.txt
>         Pages           : 8
>         Date            : 2003-2-19
>
>Prior to the publication of RFC2939 (which was updated by RFC2489),
>several option codes were assigned to proposed DHCP options that were
>subsequently never used.  This document lists those unused option
>codes and will be used to confirm that these option codes can be
>reused for other DHCP options in the future.
>
>A URL for this Internet-Draft is:
><http://www.ietf.org/internet-drafts/draft-ietf-dhc-unused-optioncodes-00.txt>http://www.ietf.org/internet-drafts/draft-ietf-dhc-unused-optioncodes-00.txt

>
>
>To remove yourself from the IETF Announcement list, send a message to
>ietf-announce-request with the word unsubscribe in the body of the message.
>
>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-unused-optioncodes-00.txt".
>
>A list of Internet-Drafts directories can be found in
><http://www.ietf.org/shadow.html>http://www.ietf.org/shadow.html
>or
><ftp://ftp.ietf.org/ietf/1shadow-sites.txt>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-unused-optioncodes-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.

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg

------_=_NextPart_001_01C2D91F.E2E642F0-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Feb 20 16:30:16 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00297; Thu, 20 Feb 2003 16:30:16 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KLaJp17279; Thu, 20 Feb 2003 16:36:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KLZ9p17241 for ; Thu, 20 Feb 2003 16:35:09 -0500 Received: from scaup.mail.pas.earthlink.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00150 for ; Thu, 20 Feb 2003 16:27:54 -0500 (EST) Received: from h-66-167-186-165.hstqtx02.covad.net ([66.167.186.165] helo=earthlink.net) by scaup.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 18lyIC-0000l5-00 for dhcwg@ietf.org; Thu, 20 Feb 2003 13:31:44 -0800 Message-ID: <3E556530.4080102@earthlink.net> Date: Thu, 20 Feb 2003 15:30:56 -0800 From: "J.A. Ribelles" User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en,es-ES MIME-Version: 1.0 To: dhcwg@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [dhcwg] (no subject) Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit take off the mailing list _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Feb 20 17:42:35 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02476; Thu, 20 Feb 2003 17:42:35 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KMmVp23175; Thu, 20 Feb 2003 17:48:31 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KMgpp22932 for ; Thu, 20 Feb 2003 17:42:51 -0500 Received: from mxic2.corp.emc.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02260 for ; Thu, 20 Feb 2003 17:35:34 -0500 (EST) From: Black_David@emc.com Received: by mxic2.corp.emc.com with Internet Mail Service (5.5.2653.19) id <1PRHRSL1>; Thu, 20 Feb 2003 17:39:24 -0500 Message-ID: <277DD60FB639D511AC0400B0D068B71E0564C8FE@corpmx14.us.dg.com> To: rdroms@cisco.com, dhcwg@ietf.org, ips@ece.cmu.edu Date: Thu, 20 Feb 2003 17:37:05 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [dhcwg] RE: WG last call on (Reminder! ) Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Ralph, I reviewed the -03 version of this draft, and the -04 version incorporated revisions in response to my comments. I believe this DHCP option is needed and so this draft should be advanced. Thanks, --David ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- > -----Original Message----- > From: Ralph Droms [mailto:rdroms@cisco.com] > Sent: Thursday, February 20, 2003 1:24 PM > To: dhcwg@ietf.org; ips@ece.cmu.edu > Subject: WG last call on > (Reminder!) > > > Reminder and note: there has been not response to this WG last > call. Please review draft-ietf-dhc-isnsoption-04.txt and reply with > comments. If you recommend the document for advancement > without revision, > please respond with a quick acknowledgment. No response will be > interpreted as a lack of support for advancing the document. > > ----- > > This message announces a WG last call on "DHCP Options for > Internet Storage > Name Service" . The last call will > conclude on Friday, 2/21. > > Note that this is a parallel WG last call in the dhc and ips WGs. > > draft-ietf-dhc-isnsoption-04.txt defines a new DHCP option > for discovery of > the location and role of iSNS Protocol servers in iSCSI and iFCP > devices. The draft is available at > http://www.ietf.org/internet-drafts/draft-ietf-dhc-isnsoption-04.txt > > - Ralph Droms > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Feb 20 19:14:51 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04431; Thu, 20 Feb 2003 19:14:51 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1L0LRp28822; Thu, 20 Feb 2003 19:21:27 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1L0EEp28362 for ; Thu, 20 Feb 2003 19:14:14 -0500 Received: from patan.sun.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04155 for ; Thu, 20 Feb 2003 19:06:54 -0500 (EST) Received: from esunmail ([129.147.58.198]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA29659 for ; Thu, 20 Feb 2003 17:10:46 -0700 (MST) Received: from xpa-fe1 ([129.147.58.198]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.08 (built Dec 6 2002)) with ESMTP id <0HAM00MX8TS19W@edgemail1.Central.Sun.COM> for dhcwg@ietf.org; Thu, 20 Feb 2003 17:09:38 -0700 (MST) Received: from sun.com ([66.93.78.11]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.08 (built Dec 6 2002)) with ESMTPSA id <0HAM0062DTS0W0@mail.sun.net> for dhcwg@ietf.org; Thu, 20 Feb 2003 17:09:37 -0700 (MST) Date: Thu, 20 Feb 2003 16:10:44 -0800 From: Alain Durand Subject: Re: [dhcwg] Re: WG last call on draft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt In-reply-to: <4.3.2.7.2.20030220150155.03e6d448@funnel.cisco.com> To: Ralph Droms Cc: dhcwg@ietf.org, ipng@sunroof.eng.sun.com, namedroppers@ops.ietf.org Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.551) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT Content-Transfer-Encoding: 7BIT Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT On Thursday, February 20, 2003, at 12:03 PM, Ralph Droms wrote: > Alain, > > If it's unclear, then we should edit the document to explicitly > identify the addresses as IPv6 addresses. > > This option is intended to return IPv6 configuration information. > IPv4 addresses for DNS resolvers should be provided through DHCPv4... ??? Why so? This would be the equivalent to say: "If queried using IPv6, DNS will return AAAA and if queried using IPv4, it will return A". Now, let's say that this is the case for DHCP, what should a node that act both as a DHCPv4 and DHCPv6 client do when it will be returned two lists of recursive DNS serves, one IPv4 via DHCPv4 and one IPv6 via DHCPv6. Which one should take priority? - Alain. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Feb 21 06:19:53 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26052; Fri, 21 Feb 2003 06:19:53 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1LBQkp14244; Fri, 21 Feb 2003 06:26:46 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1L6Tkp16919 for ; Fri, 21 Feb 2003 01:29:46 -0500 Received: from netcore.fi (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA10548 for ; Fri, 21 Feb 2003 01:22:18 -0500 (EST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h1L6Pvm20135; Fri, 21 Feb 2003 08:25:57 +0200 Date: Fri, 21 Feb 2003 08:25:57 +0200 (EET) From: Pekka Savola To: Alain Durand cc: Ralph Droms , , , Subject: Re: [dhcwg] Re: WG last call on draft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , On Thu, 20 Feb 2003, Alain Durand wrote: > On Thursday, February 20, 2003, at 12:03 PM, Ralph Droms wrote: > > If it's unclear, then we should edit the document to explicitly > > identify the addresses as IPv6 addresses. > > > > This option is intended to return IPv6 configuration information. > > IPv4 addresses for DNS resolvers should be provided through DHCPv4... I symphatize with this -- there are some uses to have DHCPv6 return IPv4 addresses too -- but the result would just make the dnsconfig option more complex for little benefit. Let's face it: if you deploy DHCPv6, you really should have long since deployed IPv6-enabled nameservers too. So, I think clarifying the scope to do only IPv6 seems like the best option by far. > Now, let's say that this is the case for DHCP, what should a node that > act both as a DHCPv4 and DHCPv6 client do when it will be returned two > lists of recursive DNS serves, one IPv4 via DHCPv4 and one IPv6 via > DHCPv6. Which one should take priority? Implementation decision, but I guess typically the results of the latest query take precedence. I don't see a problem here, myself. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Feb 21 06:19:55 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26076; Fri, 21 Feb 2003 06:19:55 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1LBQrp14264; Fri, 21 Feb 2003 06:26:53 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1L6Top16923 for ; Fri, 21 Feb 2003 01:29:50 -0500 Received: from sccrmhc03.attbi.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA10551 for ; Fri, 21 Feb 2003 01:22:23 -0500 (EST) Received: from mobilebill (12-211-30-155.client.attbi.com[12.211.30.155]) by sccrmhc03.attbi.com (sccrmhc03) with SMTP id <2003022106261400300sore4e>; Fri, 21 Feb 2003 06:26:15 +0000 From: "bill" To: "'Ralph Droms'" , , Date: Thu, 20 Feb 2003 22:25:51 -0800 Message-ID: <000501c2d972$155d2440$6701a8c0@mobilebill> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal In-Reply-To: <4.3.2.7.2.20030220132022.00ba7a08@funnel.cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: 7bit Subject: [dhcwg] RE: WG last call on (Reminder!) Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I have looked this over... Having not seen any problems I haven't responded... Bill -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu] On Behalf Of Ralph Droms Sent: Thursday, February 20, 2003 10:24 AM To: dhcwg@ietf.org; ips@ece.cmu.edu Subject: WG last call on (Reminder!) Reminder and note: there has been not response to this WG last call. Please review draft-ietf-dhc-isnsoption-04.txt and reply with comments. If you recommend the document for advancement without revision, please respond with a quick acknowledgment. No response will be interpreted as a lack of support for advancing the document. ----- This message announces a WG last call on "DHCP Options for Internet Storage Name Service" . The last call will conclude on Friday, 2/21. Note that this is a parallel WG last call in the dhc and ips WGs. draft-ietf-dhc-isnsoption-04.txt defines a new DHCP option for discovery of the location and role of iSNS Protocol servers in iSCSI and iFCP devices. The draft is available at http://www.ietf.org/internet-drafts/draft-ietf-dhc-isnsoption-04.txt - Ralph Droms _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Feb 21 06:19:56 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26093; Fri, 21 Feb 2003 06:19:56 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1LBQsp14280; Fri, 21 Feb 2003 06:26:54 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1L6g2p18107 for ; Fri, 21 Feb 2003 01:42:02 -0500 Received: from patan.sun.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA10746 for ; Fri, 21 Feb 2003 01:34:34 -0500 (EST) Received: from esunmail ([129.147.58.120]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA27453 for ; Thu, 20 Feb 2003 23:38:25 -0700 (MST) Received: from xpa-fe1 (esunmail [129.147.58.120]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.08 (built Dec 6 2002)) with ESMTP id <0HAN004RGBS0K5@edgemail1.Central.Sun.COM> for dhcwg@ietf.org; Thu, 20 Feb 2003 23:38:24 -0700 (MST) Received: from sun.com ([66.93.78.11]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.08 (built Dec 6 2002)) with ESMTPSA id <0HAN006WTBRYVU@mail.sun.net> for dhcwg@ietf.org; Thu, 20 Feb 2003 23:38:24 -0700 (MST) Date: Thu, 20 Feb 2003 22:39:29 -0800 From: Alain Durand Subject: Re: [dhcwg] Re: WG last call on draft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt In-reply-to: To: Pekka Savola Cc: Ralph Droms , dhcwg@ietf.org, ipng@sunroof.eng.sun.com, namedroppers@ops.ietf.org Message-id: <3A56AD0A-4567-11D7-A383-00039376A6AA@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.551) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT Content-Transfer-Encoding: 7BIT Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT On Thursday, February 20, 2003, at 10:25 PM, Pekka Savola wrote: > On Thu, 20 Feb 2003, Alain Durand wrote: >> On Thursday, February 20, 2003, at 12:03 PM, Ralph Droms wrote: >>> If it's unclear, then we should edit the document to explicitly >>> identify the addresses as IPv6 addresses. >>> >>> This option is intended to return IPv6 configuration information. >>> IPv4 addresses for DNS resolvers should be provided through DHCPv4... > > I symphatize with this -- there are some uses to have DHCPv6 return > IPv4 > addresses too -- but the result would just make the dnsconfig option > more > complex for little benefit. Let's face it: if you deploy DHCPv6, you > really should have long since deployed IPv6-enabled nameservers too. > > So, I think clarifying the scope to do only IPv6 seems like the best > option by far. Some may scream at this idea, but couldn't we pass an IPv4-mapped address in there? The DHCPv6 client could recognize this special format to mean this is actually a v4 address? > >> Now, let's say that this is the case for DHCP, what should a node that >> act both as a DHCPv4 and DHCPv6 client do when it will be returned two >> lists of recursive DNS serves, one IPv4 via DHCPv4 and one IPv6 via >> DHCPv6. Which one should take priority? > > Implementation decision, but I guess typically the results of the > latest query take precedence. I don't see a problem here, myself. Unpredictable behavior. Difficult to debug. - Alain. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Feb 21 06:19:58 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26124; Fri, 21 Feb 2003 06:19:58 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1LBQtp14296; Fri, 21 Feb 2003 06:26:55 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1L6x3p18616 for ; Fri, 21 Feb 2003 01:59:03 -0500 Received: from netcore.fi (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA11073 for ; Fri, 21 Feb 2003 01:51:36 -0500 (EST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h1L6tDw20364; Fri, 21 Feb 2003 08:55:13 +0200 Date: Fri, 21 Feb 2003 08:55:13 +0200 (EET) From: Pekka Savola To: Alain Durand cc: Ralph Droms , , , Subject: Re: [dhcwg] Re: WG last call on draft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt In-Reply-To: <3A56AD0A-4567-11D7-A383-00039376A6AA@sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , On Thu, 20 Feb 2003, Alain Durand wrote: > On Thursday, February 20, 2003, at 10:25 PM, Pekka Savola wrote: > > > On Thu, 20 Feb 2003, Alain Durand wrote: > >> On Thursday, February 20, 2003, at 12:03 PM, Ralph Droms wrote: > >>> If it's unclear, then we should edit the document to explicitly > >>> identify the addresses as IPv6 addresses. > >>> > >>> This option is intended to return IPv6 configuration information. > >>> IPv4 addresses for DNS resolvers should be provided through DHCPv4... > > > > I symphatize with this -- there are some uses to have DHCPv6 return > > IPv4 > > addresses too -- but the result would just make the dnsconfig option > > more > > complex for little benefit. Let's face it: if you deploy DHCPv6, you > > really should have long since deployed IPv6-enabled nameservers too. > > > > So, I think clarifying the scope to do only IPv6 seems like the best > > option by far. > > Some may scream at this idea, but couldn't we pass an IPv4-mapped address > in there? The DHCPv6 client could recognize this special format > to mean this is actually a v4 address? That is certainly an idea, but I don't like passing around mapped addresses if it can be avoided. Anything which requires special code in DHCPv6 seems like a bad idea. Of course, if the mapped address is pushed in your /etc/resolv.conf and your resolver understands that.... -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Feb 21 06:19:59 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26145; Fri, 21 Feb 2003 06:19:59 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1LBQup14316; Fri, 21 Feb 2003 06:26:56 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1L9BNp06141 for ; Fri, 21 Feb 2003 04:11:23 -0500 Received: from p-mail2 (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA23787 for ; Fri, 21 Feb 2003 04:03:53 -0500 (EST) Received: from parsmtp2.rd.francetelecom.com ([10.193.117.129]) by 192.144.74.32 with InterScan Messaging Security Suite; Fri, 21 Feb 2003 10:12:03 +0100 Received: from lanmhs50.rd.francetelecom.fr ([10.193.21.52]) by parsmtp2.rd.francetelecom.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 21 Feb 2003 10:07:14 +0100 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Subject: RE: [dhcwg] Re: WG last call ondraft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt Date: Fri, 21 Feb 2003 10:07:13 +0100 Message-ID: Thread-Topic: [dhcwg] Re: WG last call ondraft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt Thread-Index: AcLZdJ2qzsJy1hb2SAuoytmUjyAg6AAEmgEg From: "BELOEIL Luc FTRD/DMI/CAE" To: "Alain Durand" , "Pekka Savola" Cc: "Ralph Droms" , , , X-OriginalArrivalTime: 21 Feb 2003 09:07:14.0493 (UTC) FILETIME=[A01E86D0:01C2D988] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h1L9BNp06142 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi all, > De : Alain Durand [mailto:Alain.Durand@Sun.COM] > > On Thursday, February 20, 2003, at 10:25 PM, Pekka Savola wrote: > > > On Thu, 20 Feb 2003, Alain Durand wrote: > >> On Thursday, February 20, 2003, at 12:03 PM, Ralph Droms wrote: > >>> If it's unclear, then we should edit the document to explicitly > >>> identify the addresses as IPv6 addresses. > >>> > >>> This option is intended to return IPv6 configuration information. > >>> IPv4 addresses for DNS resolvers should be provided > through DHCPv4... > > > > I symphatize with this -- there are some uses to have DHCPv6 return > > IPv4 > > addresses too -- but the result would just make the > dnsconfig option > > more > > complex for little benefit. Let's face it: if you deploy > DHCPv6, you > > really should have long since deployed IPv6-enabled nameservers too. > > > > So, I think clarifying the scope to do only IPv6 seems like the best > > option by far. > > > Some may scream at this idea, but couldn't we pass an IPv4-mapped > address > in there? The DHCPv6 client could recognize this special format > to mean this is actually a v4 address? > I feel ill at ease with such a solution. How your DHCPv6 client, running a node, is aware that there is an IPv4 stack enable on that same node ? If it is not, v4-mapped addresses could be harmfull, couldn't they ? > > > > >> Now, let's say that this is the case for DHCP, what should > a node that > >> act both as a DHCPv4 and DHCPv6 client do when it will be > returned two > >> lists of recursive DNS serves, one IPv4 via DHCPv4 and one IPv6 via > >> DHCPv6. Which one should take priority? > > > > Implementation decision, but I guess typically the results of the > > latest query take precedence. I don't see a problem here, myself. > > Unpredictable behavior. Difficult to debug. > > - Alain. > Good remark! I understand the point/issue if IPv6 provider is not the same as IPv4 one. By that way the node may not have the same global vision of the Domain Name System! _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Feb 21 06:20:00 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26160; Fri, 21 Feb 2003 06:20:00 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1LBQwp14333; Fri, 21 Feb 2003 06:26:58 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1L9Xrp06882 for ; Fri, 21 Feb 2003 04:33:53 -0500 Received: from netcore.fi (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24120 for ; Fri, 21 Feb 2003 04:26:23 -0500 (EST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h1L9Tso21144; Fri, 21 Feb 2003 11:29:54 +0200 Date: Fri, 21 Feb 2003 11:29:54 +0200 (EET) From: Pekka Savola To: BELOEIL Luc FTRD/DMI/CAE cc: Alain Durand , Ralph Droms , , , Subject: RE: [dhcwg] Re: WG last call ondraft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , On Fri, 21 Feb 2003, BELOEIL Luc FTRD/DMI/CAE wrote: > > > Implementation decision, but I guess typically the results of the > > > latest query take precedence. I don't see a problem here, myself. > > > > Unpredictable behavior. Difficult to debug. > > > > - Alain. > > Good remark! I understand the point/issue if IPv6 provider is not the > same as IPv4 one. By that way the node may not have the same global > vision of the Domain Name System! I'm having a difficulty seeing the point. A similar situation happens if the user has manually configured a few nameservers in /etc/resolv.conf and then runs either DHCPv4 / DHCPv6. Is it IETF's business to specify whether or not (and if so, how) the entries should be overwritten, prepended/appended, etc. ? Is this done now with DHCPv4? I'm not so sure, but something like "DNS servers configured through this option should take precedence if some existed beforehand" would be acceptable to me Note *no* RFC2119 upper-case keywords. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Feb 21 07:42:51 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27857; Fri, 21 Feb 2003 07:42:51 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1LCnmp20079; Fri, 21 Feb 2003 07:49:48 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1LCMap18483 for ; Fri, 21 Feb 2003 07:22:36 -0500 Received: from shuttle.wide.toshiba.co.jp (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27516 for ; Fri, 21 Feb 2003 07:15:01 -0500 (EST) Received: from localhost (unknown [3ffe:501:100f:1048:39e3:8874:aae1:94ec]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 7D6C715210; Fri, 21 Feb 2003 21:18:51 +0900 (JST) Date: Fri, 21 Feb 2003 21:19:00 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Ralph Droms Cc: dhcwg@ietf.org, ipng@sunroof.eng.sun.com, namedroppers@ops.ietf.org In-Reply-To: <4.3.2.7.2.20030220135524.03e6d548@funnel.cisco.com> References: <4.3.2.7.2.20030220135524.03e6d548@funnel.cisco.com> User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.2 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 20 Subject: [dhcwg] Re: WG last call on draft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , >>>>> On Thu, 20 Feb 2003 13:56:59 -0500, >>>>> Ralph Droms said: > Reminder and note: there have been a few responses to this WG last call, > but no explicit positive recommendations for advancement. Please review > draft-ietf-dhc-dhcpv6 opt-dnsconfig-02.txt and reply with comments. If you > recommend the document for advancement without revision, please respond > with a quick acknowledgment. No response will be interpreted as a lack of > support for advancing the document. Just as a note: I believe I presented a positive recommendation for advancement. (But it would better to revise the document once to address issues raised during the last call period.) JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Feb 21 07:54:11 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28156; Fri, 21 Feb 2003 07:54:11 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1LD19p20654; Fri, 21 Feb 2003 08:01:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1LD07p20578 for ; Fri, 21 Feb 2003 08:00:07 -0500 Received: from rtp-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28127 for ; Fri, 21 Feb 2003 07:52:31 -0500 (EST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h1LCuKNh003586; Fri, 21 Feb 2003 07:56:21 -0500 (EST) Received: from rdroms-w2k.cisco.com (dhcp-161-44-149-251.cisco.com [161.44.149.251]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id HAA13252; Fri, 21 Feb 2003 07:56:20 -0500 (EST) Message-Id: <4.3.2.7.2.20030221074927.03e89ed8@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 21 Feb 2003 07:56:20 -0500 To: dhcwg@ietf.org, ipng@sunroof.eng.sun.com, namedroppers@ops.ietf.org From: Ralph Droms Subject: Re: [dhcwg] Re: WG last call on draft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt In-Reply-To: <3A56AD0A-4567-11D7-A383-00039376A6AA@sun.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Regarding unpredictable, difficult to debug behavior (see end of quoted text)... Shouldn't the host receive the same answer to a DNS query, regardless of the resolver to which the query is sent? If so, the order in which resolvers are used by the host shouldn't matter. What is done today in the deployed IPv6 world in a host that has both an IPv6 stack and an IPv4 stack, and a manually configured list of DNS resolvers? Is it allowed to mix together IPv6 and IPv4 addresses for resolvers? Is that configuration actually used? Does the host have two lists: one for IPv6 and one for IPv4? Suppose the host only has an IPv6 stack but both IPv6 and IPv4 addresses in its list of DNS resolvers? I'm hoping we can get some real-world deployment experience injected into the conversation... - Ralph At 10:39 PM 2/20/2003 -0800, Alain Durand wrote: >On Thursday, February 20, 2003, at 10:25 PM, Pekka Savola wrote: > >>On Thu, 20 Feb 2003, Alain Durand wrote: >>>On Thursday, February 20, 2003, at 12:03 PM, Ralph Droms wrote: >>>>If it's unclear, then we should edit the document to explicitly >>>>identify the addresses as IPv6 addresses. >>>> >>>>This option is intended to return IPv6 configuration information. >>>>IPv4 addresses for DNS resolvers should be provided through DHCPv4... >> >>I symphatize with this -- there are some uses to have DHCPv6 return IPv4 >>addresses too -- but the result would just make the dnsconfig option more >>complex for little benefit. Let's face it: if you deploy DHCPv6, you >>really should have long since deployed IPv6-enabled nameservers too. >> >>So, I think clarifying the scope to do only IPv6 seems like the best >>option by far. > > >Some may scream at this idea, but couldn't we pass an IPv4-mapped address >in there? The DHCPv6 client could recognize this special format >to mean this is actually a v4 address? > > >> >>>Now, let's say that this is the case for DHCP, what should a node that >>>act both as a DHCPv4 and DHCPv6 client do when it will be returned two >>>lists of recursive DNS serves, one IPv4 via DHCPv4 and one IPv6 via >>>DHCPv6. Which one should take priority? >> >>Implementation decision, but I guess typically the results of the >>latest query take precedence. I don't see a problem here, myself. > >Unpredictable behavior. Difficult to debug. > > - Alain. > > >-- >to unsubscribe send a message to namedroppers-request@ops.ietf.org with >the word 'unsubscribe' in a single line as the message text body. >archive: _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Feb 21 08:54:26 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29441; Fri, 21 Feb 2003 08:54:26 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1LE1Lp24165; Fri, 21 Feb 2003 09:01:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1LE0Yp24107 for ; Fri, 21 Feb 2003 09:00:34 -0500 Received: from ratree.psu.ac.th (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29426 for ; Fri, 21 Feb 2003 08:52:58 -0500 (EST) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h1LDuSd14961; Fri, 21 Feb 2003 20:56:28 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h1LDuCo24076; Fri, 21 Feb 2003 20:56:12 +0700 (ICT) From: Robert Elz To: Ralph Droms cc: dhcwg@ietf.org, ipng@sunroof.eng.sun.com, namedroppers@ops.ietf.org Subject: Re: [dhcwg] Re: WG last call on draft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt In-Reply-To: <4.3.2.7.2.20030221074927.03e89ed8@funnel.cisco.com> References: <4.3.2.7.2.20030221074927.03e89ed8@funnel.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 21 Feb 2003 20:56:12 +0700 Message-ID: <24074.1045835772@munnari.OZ.AU> Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Date: Fri, 21 Feb 2003 07:56:20 -0500 From: Ralph Droms Message-ID: <4.3.2.7.2.20030221074927.03e89ed8@funnel.cisco.com> | Shouldn't the host receive the same answer to a DNS query, regardless of | the resolver to which the query is sent? If so, the order in which | resolvers are used by the host shouldn't matter. It shouldn't matter to the answer (but those who insist on shoving 2faced DNS implementations down everyone's throats can cause problems). It can matter to the workability - often the first resolver listed is the one that should be used, the others are there for backup purposes only, and won't necessarily respond as quickly (they may have smaller cache capacity, slower net links, slower CPU, ...). All this is fine as a backup when the primary resolver happens to be broken, but you wouldn't want to be using it just because you happened to pick the wrong address from a list. | What is done today in the deployed IPv6 world in a host that has both an | IPv6 stack and an IPv4 stack, and a manually configured list of DNS | resolvers? Just about everyone uses IPv4 alone for their resolvers. | Is it allowed to mix together IPv6 and IPv4 addresses for resolvers? Allowed, yes, of course, nothing disallows it. | Is that configuration actually used? Probably not at the minute. | Does the host have two lists: one for IPv6 and one for IPv4? This would make no sense. The host (or application in most cases) has one resolver (stub). When called, all that exists is a domain name, there's no particular v4 or v6 preference. The resolver stub needs to contact its back end resolver to resolve the address, whether v4 or v6 is used for this will depend entirely upon what addresses have been configured for the back end resolver (cache). It certainly isn't influenced by the nature of the query, or by what use is intended for the results of the query. | Suppose the host only has an IPv6 stack but both IPv6 and IPv4 addresses in | its list of DNS resolvers? The v4 address would be useless, just like any other (patently) bogus address that is configured. Ignoring that one would be easy. | I'm hoping we can get some real-world deployment experience injected into | the conversation... Since just about no-one is using v6 in their stub resolvers (just a few who will no doubt now speak up...) this might be difficult. On the issue - I think having just v6 addresses in the DHCPv6 option is fine. How the host actually mixes addresses it gets from DHCPv6 and DHCPv4, and other mechanisms is an interesting problem to which we don't yet have any real answers. This is an area where we probably should just say nothing, and wait to see how implementations actually react. But rather than mixing v6 & v4 addresses in one response (as you imply, v6 addresses are no use to a node with only v4, and v4 addresses no use to a node with only v6) it might be better to explicitly add a "priority of this DNS cache" field along with each address. This allows the implicit "this one is better than that one" based upon ordering to be done away with. What's more, if we were to pick a middling well known priority that would implicitly be applied to addresses in a v4 response it also allows v6 to be placed before, or after, v4 addresses in nodes that support both (or even some before, and some after). It doesn't allow v4 addresses to be ranked other than by their implicit ordering, nor for v6 addresses to be inserted in the middle of the v4 list, but we can't have everything (and I doubt anyone wants to go changing the v4 DNS cache list option now). kre _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Feb 21 09:15:27 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00773; Fri, 21 Feb 2003 09:15:27 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1LEMPp25796; Fri, 21 Feb 2003 09:22:25 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1LDPBp22201 for ; Fri, 21 Feb 2003 08:25:11 -0500 Received: from p-mail1.rd.francetelecom.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA28624 for ; Fri, 21 Feb 2003 08:17:36 -0500 (EST) Received: from parsmtp1.rd.francetelecom.com ([10.193.117.128]) by p-mail1 with InterScan Messaging Security Suite; Fri, 21 Feb 2003 14:21:06 +0100 Received: from lanmhs50.rd.francetelecom.fr ([10.193.21.52]) by parsmtp1.rd.francetelecom.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 21 Feb 2003 14:20:47 +0100 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Subject: RE: [dhcwg] Re: WG last call ondraft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt Date: Fri, 21 Feb 2003 14:20:45 +0100 Message-ID: Thread-Topic: [dhcwg] Re: WG last call ondraft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt Thread-Index: AcLZi8vN/f23m7QVS5ycrelM9us50wAGvQmw From: "BELOEIL Luc FTRD/DMI/CAE" To: "Pekka Savola" Cc: "Alain Durand" , "Ralph Droms" , , , X-OriginalArrivalTime: 21 Feb 2003 13:20:47.0203 (UTC) FILETIME=[0B99DB30:01C2D9AC] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h1LDPBp22202 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit > De : Pekka Savola [mailto:pekkas@netcore.fi] > > > On Fri, 21 Feb 2003, BELOEIL Luc FTRD/DMI/CAE wrote: > > > > Implementation decision, but I guess typically the > results of the > > > > latest query take precedence. I don't see a problem > here, myself. > > > > > > Unpredictable behavior. Difficult to debug. > > > > > > - Alain. > > > > Good remark! I understand the point/issue if IPv6 provider > is not the > > same as IPv4 one. By that way the node may not have the same global > > vision of the Domain Name System! > > I'm having a difficulty seeing the point. A similar > situation happens if > the user has manually configured a few nameservers in > /etc/resolv.conf and > then runs either DHCPv4 / DHCPv6. > Yes > Is it IETF's business to specify whether or not (and if so, how) the > entries should be overwritten, prepended/appended, etc. ? I'm really not sure. > Is this done > now with DHCPv4? > No idea. > I'm not so sure, but something like "DNS servers configured > through this > option should take precedence if some existed beforehand" would be > acceptable to me Note *no* RFC2119 upper-case keywords. > IMO, the "split vision of DNS" remark is useful for service architectures but may not be taken into account in some protocol specifications. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Feb 21 12:34:08 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08005; Fri, 21 Feb 2003 12:34:08 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1LHfCp07814; Fri, 21 Feb 2003 12:41:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1LHdcp07722 for ; Fri, 21 Feb 2003 12:39:38 -0500 Received: from rtp-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07950 for ; Fri, 21 Feb 2003 12:31:57 -0500 (EST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h1LHZlJR004346 for ; Fri, 21 Feb 2003 12:35:47 -0500 (EST) Received: from rdroms-w2k.cisco.com (dhcp-161-44-149-251.cisco.com [161.44.149.251]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id MAA03847 for ; Fri, 21 Feb 2003 12:35:46 -0500 (EST) Message-Id: <4.3.2.7.2.20030221123343.03e74180@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 21 Feb 2003 12:35:45 -0500 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [dhcwg] Request for agenda items, dhc WG meeting in SF Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , If you have an agenda item for the dhc WG meeting in SF, please send me a request including the topic, relevant drafts and estimated time. Here is the latest draft agenda: DHC WG agenda - IETF 56 (Last revised 2/21/03 12:00) ------------------------------ Administrivia; agenda bashing; WG progress report Ralph Droms 5 minutes Review of new charter; request for milestones Ralph Droms 10 minutes RFC 3118 review team report Bernie Volz 10 minutes Option code recovery Ralph Droms 5 minutes Option code extensions Bernie Volz 10 minutes Authentication of relay agent options John Schnizlein 10 minutes Review of DHCP RFCs Barr Hibbs 10 minutes ---------- Total 60 minutes _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Feb 21 12:47:10 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08696; Fri, 21 Feb 2003 12:47:10 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1LHsFp08390; Fri, 21 Feb 2003 12:54:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1LHr5p08294 for ; Fri, 21 Feb 2003 12:53:05 -0500 Received: from toccata.fugue.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08579 for ; Fri, 21 Feb 2003 12:45:24 -0500 (EST) Received: from nominum.com (a21.pm3-67.theriver.com [206.25.48.213]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id h1LHk3N26412; Fri, 21 Feb 2003 11:46:03 -0600 (CST) Date: Fri, 21 Feb 2003 10:48:44 -0700 Subject: Re: [dhcwg] Re: WG last call on draft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: Ralph Droms , dhcwg@ietf.org, ipng@sunroof.eng.sun.com, namedroppers@ops.ietf.org To: Robert Elz From: Ted Lemon In-Reply-To: <24074.1045835772@munnari.OZ.AU> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I'm not sure why you would have a deployed DHCPv6 server and not deploy a DNS resolver that listens to requests on an IPv6 socket. Can anybody give a rationale for this? Has anybody done this? Was it a problem? In principle, there is nothing that would prevent you from configuring your DHCPv6 server to return an encapsulated IPv4 address, but as various people have said, this might produce a not-useful result. I think that the idea of having a DNS resolver priority list is a reasonable answer to the problem of "what do we do if we have both IPv4 and IPv6 addresses for resolvers," but I also think that it's a complicated answer, and I do not believe that the problem it solves is a compelling one. It adds significant special-case code to the DHCP client, and I don't think it produces a useful benefit. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Feb 21 15:38:32 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13896; Fri, 21 Feb 2003 15:38:32 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1LKjbp19600; Fri, 21 Feb 2003 15:45:37 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1LJBKp13462 for ; Fri, 21 Feb 2003 14:11:20 -0500 Received: from zcars04f.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11299 for ; Fri, 21 Feb 2003 14:03:37 -0500 (EST) Received: from zbl6c012.us.nortel.com (zbl6c012.corpeast.baynetworks.com [132.245.205.62]) by zcars04f.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h1LJ58r28340; Fri, 21 Feb 2003 14:05:08 -0500 (EST) Received: from zbl6c002.us.nortel.com (zbl6c002.corpeast.baynetworks.com [132.245.205.52]) by zbl6c012.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id F1NM9MKG; Fri, 21 Feb 2003 14:05:07 -0500 Received: from TRAVOS-2.nortelnetworks.com (travos-2.us.nortel.com [47.16.72.102]) by zbl6c002.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 1DCCHKKS; Fri, 21 Feb 2003 14:05:07 -0500 Message-Id: <5.1.1.6.2.20030221135140.028787d0@zbl6c002.corpeast.baynetworks.com> X-Sender: travos@zbl6c002.corpeast.baynetworks.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Fri, 21 Feb 2003 14:04:54 -0500 To: Ralph Droms , dhcwg@ietf.org, ips@ece.cmu.edu From: Franco Travostino In-Reply-To: <4.3.2.7.2.20030220132022.00ba7a08@funnel.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [dhcwg] Re: WG last call on (Reminder!) Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , I support the draft. An observation regarding IPv4 vs IPv6. Other DHCP documents make it clear that they are talking about IPv4 use (e.g., rfc 3361, ""Dynamic Host Configuration Protocol (DHCP-for-IPv4) Option for Session Initiation Protocol (SIP) Servers""). If there is an agreed-upon style for defining applicability, it should be used here as well. -franco At 01:23 PM 2/20/2003, Ralph Droms wrote: >Reminder and note: there has been not response to this WG last >call. Please review draft-ietf-dhc-isnsoption-04.txt and reply with >comments. If you recommend the document for advancement without revision, >please respond with a quick acknowledgment. No response will be >interpreted as a lack of support for advancing the document. > >----- > >This message announces a WG last call on "DHCP Options for Internet >Storage Name Service" . The last call >will conclude on Friday, 2/21. > >Note that this is a parallel WG last call in the dhc and ips WGs. > >draft-ietf-dhc-isnsoption-04.txt defines a new DHCP option for discovery >of the location and role of iSNS Protocol servers in iSCSI and iFCP >devices. The draft is available at >http://www.ietf.org/internet-drafts/draft-ietf-dhc-isnsoption-04.txt > >- Ralph Droms _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Feb 21 15:38:48 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13921; Fri, 21 Feb 2003 15:38:48 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1LKjxp19630; Fri, 21 Feb 2003 15:45:59 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1LKIRp17966 for ; Fri, 21 Feb 2003 15:18:27 -0500 Received: from patan.sun.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13200 for ; Fri, 21 Feb 2003 15:10:44 -0500 (EST) Received: from esunmail ([129.147.58.120]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA17824 for ; Fri, 21 Feb 2003 13:14:34 -0700 (MST) Received: from xpa-fe2 ([129.147.58.198]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.08 (built Dec 6 2002)) with ESMTP id <0HAO005BQDK9EK@edgemail1.Central.Sun.COM> for dhcwg@ietf.org; Fri, 21 Feb 2003 13:14:34 -0700 (MST) Received: from sun.com ([66.93.78.11]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.08 (built Dec 6 2002)) with ESMTPSA id <0HAO00K1ADK8UH@mail.sun.net> for dhcwg@ietf.org; Fri, 21 Feb 2003 13:14:33 -0700 (MST) Date: Fri, 21 Feb 2003 12:15:41 -0800 From: Alain Durand Subject: Re: [dhcwg] Re: WG last call on draft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt In-reply-to: <4.3.2.7.2.20030221074927.03e89ed8@funnel.cisco.com> To: Ralph Droms Cc: dhcwg@ietf.org, ipng@sunroof.eng.sun.com, namedroppers@ops.ietf.org Message-id: <3FCBEDD2-45D9-11D7-9278-00039376A6AA@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.551) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT Content-Transfer-Encoding: 7BIT Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT On Friday, February 21, 2003, at 04:56 AM, Ralph Droms wrote: > Regarding unpredictable, difficult to debug behavior (see end of > quoted text)... > > Shouldn't the host receive the same answer to a DNS query, regardless > of the resolver to which the query is sent? If so, the order in which > resolvers are used by the host shouldn't matter. There might be performance/security issues. > > What is done today in the deployed IPv6 world in a host that has both > an IPv6 stack and an IPv4 stack, and a manually configured list of DNS > resolvers? Is it allowed to mix together IPv6 and IPv4 addresses for > resolvers? Yes, in /etc/resolv.conf > Is that configuration actually used? Yes > Does the host have two lists: one for IPv6 and one for IPv4? No, one list which include either v4 or v6 addreses > > Suppose the host only has an IPv6 stack but both IPv6 and IPv4 > addresses in its list of DNS resolvers? then obviously it should ignore the v4 one, the same way a v4-only host should ignore AAAA records. > I'm hoping we can get some real-world deployment experience injected > into the conversation... > > - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Feb 21 16:48:27 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15922; Fri, 21 Feb 2003 16:48:27 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1LLtYp23540; Fri, 21 Feb 2003 16:55:34 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1LLAkp21396 for ; Fri, 21 Feb 2003 16:10:46 -0500 Received: from luminous.mit.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14822 for ; Fri, 21 Feb 2003 16:03:01 -0500 (EST) Received: by luminous.mit.edu (Postfix, from userid 1000) id 711D6767C6; Fri, 21 Feb 2003 16:06:48 -0500 (EST) To: dhcwg@ietf.org mail-copies-to: hartmans@mit.edu From: Sam Hartman Date: Fri, 21 Feb 2003 16:06:48 -0500 Message-ID: <87heaxpclz.fsf@luminous.mit.edu> Lines: 84 User-Agent: Gnus/5.090006 (Oort Gnus v0.06) Emacs/21.1 (i386-debian-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [dhcwg] Comments on draft-ietf-dhc-pktc-kerb-tckt-00.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Hi. I'm not subscribed to the list, so please copy me on responses. I'm sending these comments because a review of the option from a Kerberos viewpoint was requested. First, I do not believe this document is an appropriate work item of the IETF for the following reasons. I do not think it likely there will ever be multiple implementations of the standard, so I do not think it likely that the the standard will meet criteria for advancement. The standard seems focused on a specific deployment situation and in fact on a specific category of tightly specified devices and has insufficient generic applicability to devices outside that specific environment to be an Internet standard. I understand these devices are being deployed on the open Internet. However it is not necessary for the IETF to specify all protocols that are used over the Internet. I realize this concern applies equally to the base packetcable configuration option and as such will probably be discarded. The second reason this document seems poorly scoped for the IETF is that while based on Kerberos, the authentication technology discussed is not in fact Kerberos. The Packetcable group needed a standard and could not wait for the Kerberos working group to conclude and publish a document. As such they adopted a draft that is incompatible both with RFC 1510 and with current drafts within the Kerberos working group. Fields are added to protocol messages in a manner that does cause implementations of RFC 1510 to reject the messages and will interfere with future expansion of the protocol. The mandatory to use encryption systems for Packetcable Kerberos are not even specified in the IETF drafts or published RFCs. The Kerberos working group has decided not to standardize the encryption systems that Packetcable uses in part because the encryption systems that are being standardized are significantly stronger. It may be possible to implement a system that supports both Packetcable Kerberos and IETF Kerberos--I know one vendor who is trying to do that. However it seems that the IETF should not spend time standardizing a DHCP sub option for controlling an authentication system outside of the scope of the IETF for use in a limited environment. If the IETF decides that this work is within our scope, a note needs to be added to the draft clarifying the Kerberos compatibility issue. A pointer to the Packetcable Kerberos specification should be added along with a note that this specification is incompatible with current RFC 1510 implementations and with ongoing working in the IETF. The rationale for this draft claims that it will be used among other reasons to cancel subscriber service. The presence of a Kerberos ticket should not be used to imply authorization to use a service; this is incompatible both with RFC 1510 and with current Kerberos drafts. Even if the authorization data field is used to convey authorization along with authentication, service tickets with should not be issued with lifetimes longer than are acceptable. I.E. you should only issue a ticket with a lifetime as long as you are willing to have authorization cached. I believe that this problem should be fixed by removing the text proposing that using this option is appropriate to notify a device that service has been canceled and adding a requirement that the security of the deployment MUST NOT depend on this option being honored. The option if it exists should serve to invalidate caches to deal with operational problems such as emergency rekeying of services or testing, and the only effect of failing to honor this option should be a temporary loss of service. The format of this option is insufficiently extensible. Many of the sixteen code points for available services have already been used and experiences shows new Kerberos services tend to be deployed over time. Why would you want to selectively invalidate some but not all tickets? If this option exists, it seems like providing a mechanism to completely invalidate the cache should be sufficient. Finally security considerations need to discuss the disadvantages of storing persistent Kerberos tickets. Other deployments of Kerberos are moving away from doing this and instead storing tickets in volatile memory. It would be excellent if the write up of this issue in the security considerations section gave numbers to justify the need for persistent tickets, although requiring this would be excessive. --Sam _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sat Feb 22 07:09:34 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09453; Sat, 22 Feb 2003 07:09:34 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1MCGvp12084; Sat, 22 Feb 2003 07:16:57 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1M1hTp04785 for ; Fri, 21 Feb 2003 20:43:29 -0500 Received: from thrintun.hactrn.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20728 for ; Fri, 21 Feb 2003 20:35:38 -0500 (EST) Received: from thrintun.hactrn.net (localhost [::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 1D82D18EC; Fri, 21 Feb 2003 20:39:30 -0500 (EST) Date: Fri, 21 Feb 2003 20:39:30 -0500 From: Rob Austein To: Ralph Droms Cc: dhcwg@ietf.org, ipng@sunroof.eng.sun.com, namedroppers@ops.ietf.org In-Reply-To: <4.3.2.7.2.20030220143854.03e69358@funnel.cisco.com> User-Agent: Wanderlust/2.8.1 (Something) Emacs/20.7 Mule/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.14.4 - "Hosorogi") Content-Type: text/plain; charset=US-ASCII Message-Id: <20030222013930.1D82D18EC@thrintun.hactrn.net> Subject: [dhcwg] Re: WG last call on draft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , In response to the main question: I've read the draft, the option looks looks reasonable to me (subject to the discussion that has already taken place during this last call, I'm not disagreeing with any of that), and I think it'd be useful for this draft to advance. The rest of this message is on one specific point: At Thu, 20 Feb 2003 14:55:11 -0500, Ralph Droms wrote: > At 08:27 PM 2/10/2003 +0100, Peter Koch wrote: > > >Apart from the sad fact that DNSSEC isn't yet deployed I don't see why it > >wouldn't be able to detect spoofing. If, however, you want to say that > >using domain names in the search list you don't control is a dangerous > >thing, that could be emphazised by a reference to RFC 1535. > > The idea here (note that I'm not a DNSSEC expert, either) is that > a search list that the host doesn't control might still pass DNSSEC > authentication while yielding unexpected results. > > I would be happy to hear that DNSSEC can prevent the problem and would > be willing to follow your suggestion and replace the reference to > DNSSEC with a more general reference to untrusted search lists. DNSSEC could let you figure out whether the data you got back was signed by an entity which you trust. The difficulty with search paths, is that you're also trusting the search path to tell you what question you should be asking. So DNSSEC could let you figure out whether the random question that your search path just told you to ask was answered with data signed by an entity which you trust, but it's not going to help you figure out whether that was the right question. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sat Feb 22 07:15:15 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09523; Sat, 22 Feb 2003 07:15:14 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1MCMfp12254; Sat, 22 Feb 2003 07:22:41 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1MAqBp07883 for ; Sat, 22 Feb 2003 05:52:11 -0500 Received: from devil.pp.htv.fi (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08559 for ; Sat, 22 Feb 2003 05:44:09 -0500 (EST) Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) with ESMTP id h1MAmXaj027089; Sat, 22 Feb 2003 12:48:34 +0200 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) id h1MAmSxt027087; Sat, 22 Feb 2003 12:48:28 +0200 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: [dhcwg] Re: WG last call on draft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt From: Mika Liljeberg To: Pekka Savola Cc: Alain Durand , Ralph Droms , dhcwg@ietf.org, ipng@sunroof.eng.sun.com, namedroppers@ops.ietf.org In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1045910906.26677.29.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 22 Feb 2003 12:48:27 +0200 Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Fri, 2003-02-21 at 08:25, Pekka Savola wrote: > On Thu, 20 Feb 2003, Alain Durand wrote: > > On Thursday, February 20, 2003, at 12:03 PM, Ralph Droms wrote: > > > If it's unclear, then we should edit the document to explicitly > > > identify the addresses as IPv6 addresses. > > > > > > This option is intended to return IPv6 configuration information. > > > IPv4 addresses for DNS resolvers should be provided through DHCPv4... > > I symphatize with this -- there are some uses to have DHCPv6 return IPv4 > addresses too -- but the result would just make the dnsconfig option more > complex for little benefit. Let's face it: if you deploy DHCPv6, you > really should have long since deployed IPv6-enabled nameservers too. > > So, I think clarifying the scope to do only IPv6 seems like the best > option by far. Is that necessary? IPv4 addresses can be returned in IPv4 Mapped format if necessary. Just add some text explaining this. With our hybrid IPv4/IPv6 stack implementation this would work out of the box. MikaL _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sat Feb 22 07:21:01 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09641; Sat, 22 Feb 2003 07:21:01 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1MCSSp12423; Sat, 22 Feb 2003 07:28:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1MB6Zp08271 for ; Sat, 22 Feb 2003 06:06:35 -0500 Received: from devil.pp.htv.fi (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08676 for ; Sat, 22 Feb 2003 05:58:33 -0500 (EST) Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) with ESMTP id h1MB31aj027243; Sat, 22 Feb 2003 13:03:01 +0200 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) id h1MB30t3027242; Sat, 22 Feb 2003 13:03:00 +0200 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: RE: [dhcwg] Re: WG last call ondraft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt From: Mika Liljeberg To: BELOEIL Luc FTRD/DMI/CAE Cc: Alain Durand , Pekka Savola , Ralph Droms , dhcwg@ietf.org, ipng@sunroof.eng.sun.com, namedroppers@ops.ietf.org In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1045911780.27180.5.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 22 Feb 2003 13:03:00 +0200 Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Fri, 2003-02-21 at 11:07, BELOEIL Luc FTRD/DMI/CAE wrote: > > Some may scream at this idea, but couldn't we pass an IPv4-mapped > > address > > in there? The DHCPv6 client could recognize this special format > > to mean this is actually a v4 address? I think this is a good idea. > I feel ill at ease with such a solution. How your DHCPv6 client, running > a node, is aware that there is an IPv4 stack enable on that same node ? > If it is not, v4-mapped addresses could be harmfull, couldn't they ? Not really. Why would a network administrator advertise IPv4 DNS servers on a network with IPv6 only nodes? Even if there are some IPv6 only nodes on the network, the host resolver on those nodes will simply try to use the IPv4-mapped address and fail, and move on the the next one as it would do with any malfunctioning DNS server. I don't think the DHCP client has to care whether IPv4 is enabled on the node (although it could attempt to check that). All it has to do is configure the DNS addresses and let the host resolver take it from there. MikaL _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sat Feb 22 07:27:13 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09726; Sat, 22 Feb 2003 07:27:12 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1MCYcp12567; Sat, 22 Feb 2003 07:34:38 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1MBICp09251 for ; Sat, 22 Feb 2003 06:18:12 -0500 Received: from netcore.fi (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08839 for ; Sat, 22 Feb 2003 06:10:10 -0500 (EST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h1MBDmP29761; Sat, 22 Feb 2003 13:13:48 +0200 Date: Sat, 22 Feb 2003 13:13:48 +0200 (EET) From: Pekka Savola To: Mika Liljeberg cc: Alain Durand , Ralph Droms , , , Subject: Re: [dhcwg] Re: WG last call on draft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt In-Reply-To: <1045910906.26677.29.camel@devil> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , On 22 Feb 2003, Mika Liljeberg wrote: > On Fri, 2003-02-21 at 08:25, Pekka Savola wrote: > > On Thu, 20 Feb 2003, Alain Durand wrote: > > > On Thursday, February 20, 2003, at 12:03 PM, Ralph Droms wrote: > > > > If it's unclear, then we should edit the document to explicitly > > > > identify the addresses as IPv6 addresses. > > > > > > > > This option is intended to return IPv6 configuration information. > > > > IPv4 addresses for DNS resolvers should be provided through DHCPv4... > > > > I symphatize with this -- there are some uses to have DHCPv6 return IPv4 > > addresses too -- but the result would just make the dnsconfig option more > > complex for little benefit. Let's face it: if you deploy DHCPv6, you > > really should have long since deployed IPv6-enabled nameservers too. > > > > So, I think clarifying the scope to do only IPv6 seems like the best > > option by far. > > Is that necessary? IPv4 addresses can be returned in IPv4 Mapped format > if necessary. Just add some text explaining this. With our hybrid > IPv4/IPv6 stack implementation this would work out of the box. IMO, we should just say "IPv6 addresses" (the critical thing here is the size of the address -- no checks are done to validate them!), and nothing about mapped addresses. If some want to push mapped addresses in there, that's fine by me -- if your DNS resolver supports mapped addresses in /etc/resolv.conf (or equivalent). No special code/text, is my opinion! -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sat Feb 22 07:32:54 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09862; Sat, 22 Feb 2003 07:32:54 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1MCeKp13473; Sat, 22 Feb 2003 07:40:20 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1MBLMp09350 for ; Sat, 22 Feb 2003 06:21:22 -0500 Received: from devil.pp.htv.fi (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08884 for ; Sat, 22 Feb 2003 06:13:20 -0500 (EST) Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) with ESMTP id h1MBHlaj027296; Sat, 22 Feb 2003 13:17:48 +0200 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) id h1MBHiY2027295; Sat, 22 Feb 2003 13:17:44 +0200 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: [dhcwg] Re: WG last call on draft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt From: Mika Liljeberg To: Pekka Savola Cc: Alain Durand , Ralph Droms , dhcwg@ietf.org, ipng@sunroof.eng.sun.com, namedroppers@ops.ietf.org In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1045912663.27180.12.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 22 Feb 2003 13:17:44 +0200 Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Sat, 2003-02-22 at 13:13, Pekka Savola wrote: > IMO, we should just say "IPv6 addresses" (the critical thing here is the > size of the address -- no checks are done to validate them!), and nothing > about mapped addresses. > > If some want to push mapped addresses in there, that's fine by me -- if > your DNS resolver supports mapped addresses in /etc/resolv.conf (or > equivalent). > > No special code/text, is my opinion! That's good. I agree. MikaL _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sat Feb 22 07:38:32 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09939; Sat, 22 Feb 2003 07:38:32 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1MCjxp13625; Sat, 22 Feb 2003 07:45:59 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1MBQmp09501 for ; Sat, 22 Feb 2003 06:26:48 -0500 Received: from devil.pp.htv.fi (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08943 for ; Sat, 22 Feb 2003 06:18:45 -0500 (EST) Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) with ESMTP id h1MBNEaj027331; Sat, 22 Feb 2003 13:23:14 +0200 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) id h1MBNDPc027330; Sat, 22 Feb 2003 13:23:13 +0200 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f From: Mika Liljeberg To: Ralph Droms Cc: dhcwg@ietf.org, ipng@sunroof.eng.sun.com, namedroppers@ops.ietf.org In-Reply-To: <4.3.2.7.2.20030220135524.03e6d548@funnel.cisco.com> References: <4.3.2.7.2.20030220135524.03e6d548@funnel.cisco.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1045912992.27180.14.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 22 Feb 2003 13:23:12 +0200 Content-Transfer-Encoding: 7bit Subject: [dhcwg] Re: WG last call on draft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Thu, 2003-02-20 at 20:56, Ralph Droms wrote: > Reminder and note: there have been a few responses to this WG last call, > but no explicit positive recommendations for advancement. Please review > draft-ietf-dhc-dhcpv6 opt-dnsconfig-02.txt and reply with comments. If you > recommend the document for advancement without revision, please respond > with a quick acknowledgment. No response will be interpreted as a lack of > support for advancing the document. I would like to see this specification move forward. MikaL _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sat Feb 22 07:44:29 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10038; Sat, 22 Feb 2003 07:44:29 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1MCprp13819; Sat, 22 Feb 2003 07:51:53 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1MCR2p12392 for ; Sat, 22 Feb 2003 07:27:02 -0500 Received: from rtp-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09624 for ; Sat, 22 Feb 2003 07:18:58 -0500 (EST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h1MCMnJR000414 for ; Sat, 22 Feb 2003 07:22:49 -0500 (EST) Received: from rdroms-w2k.cisco.com (rtp-vpn2-504.cisco.com [10.82.241.248]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id HAA01087 for ; Sat, 22 Feb 2003 07:22:48 -0500 (EST) Message-Id: <4.3.2.7.2.20030222072136.03d75f78@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sat, 22 Feb 2003 07:22:46 -0500 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [dhcwg] Revised dhc WG charter Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , The revised dhc WG charter has been accepted and is posted on the dhc WG page at http://www.ietf.org/html.charters/dhc-charter.html - Ralph Droms _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sat Feb 22 07:57:44 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10198; Sat, 22 Feb 2003 07:57:44 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1MD5Bp14238; Sat, 22 Feb 2003 08:05:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1MCwWp14072 for ; Sat, 22 Feb 2003 07:58:32 -0500 Received: from boreas.isi.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10116 for ; Sat, 22 Feb 2003 07:50:28 -0500 (EST) Received: (from bmanning@localhost) by boreas.isi.edu (8.11.6/8.11.2) id h1MCs1I04267; Sat, 22 Feb 2003 04:54:01 -0800 (PST) From: Bill Manning Message-Id: <200302221254.h1MCs1I04267@boreas.isi.edu> Subject: Re: [dhcwg] Re: WG last call on draft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt In-Reply-To: <1045912663.27180.12.camel@devil> from Mika Liljeberg at "Feb 22, 3 01:17:44 pm" To: mika.liljeberg@welho.com (Mika Liljeberg) Date: Sat, 22 Feb 2003 04:54:00 -0800 (PST) Cc: pekkas@netcore.fi, Alain.Durand@Sun.COM, rdroms@cisco.com, dhcwg@ietf.org, ipng@sunroof.eng.sun.com, namedroppers@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL39 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit regarding the use of mapped addresses: draft-cmetz-v6ops-v4mapped-api-harmful-00.txt might be a useful ID to review before committing this draft to the stds process. --bill Opinions expressed may not even be mine by the time you read them, and certainly don't reflect those of any other entity (legal or otherwise). _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sat Feb 22 08:32:51 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10635; Sat, 22 Feb 2003 08:32:50 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1MDeLp16663; Sat, 22 Feb 2003 08:40:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1MDTBp15658 for ; Sat, 22 Feb 2003 08:29:11 -0500 Received: from devil.pp.htv.fi (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10521 for ; Sat, 22 Feb 2003 08:21:05 -0500 (EST) Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) with ESMTP id h1MDPXaj027791; Sat, 22 Feb 2003 15:25:34 +0200 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) id h1MDPVQX027788; Sat, 22 Feb 2003 15:25:31 +0200 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: IPv4-mapped API [Re: [dhcwg] Re: WG last call on draft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt] From: Mika Liljeberg To: Bill Manning Cc: pekkas@netcore.fi, Alain.Durand@Sun.COM, rdroms@cisco.com, dhcwg@ietf.org, ipng@sunroof.eng.sun.com, namedroppers@ops.ietf.org In-Reply-To: <200302221254.h1MCs1I04267@boreas.isi.edu> References: <200302221254.h1MCs1I04267@boreas.isi.edu> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1045920330.27180.45.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 22 Feb 2003 15:25:31 +0200 Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit [Topic changed. If you respond to this, please drop unrelated mailing lists.] On Sat, 2003-02-22 at 14:54, Bill Manning wrote: > regarding the use of mapped addresses: > > draft-cmetz-v6ops-v4mapped-api-harmful-00.txt > > might be a useful ID to review before committing this draft to the > stds process. These issues are completely unrelated. The API issues are real but they are not something that can or should be considered in a protocol specification. [Sorry for the off-topicness of the following] I'm not too happy about RFC2553 myself in this respect, and I strongly support the "Alternative solution" (fully specify IPv4-mapped behaviour) in the above mentioned draft. I can attest from implementation experience that it is possible to create a hybrid IPv4/IPv6 stack implementation that uses around 80-90% shared code between IPv4 and IPv6. All IPv4 addresses are handled in IPv4-mapped format internally inside the stack. Our sockets API is (mostly) version agnostic. Most applications are not even aware which IP version they are using. The OS is not a unix derivative and did not have the legacy baggage of the BSD style sockets API. The API that was already defined for IPv4 yielded very easily to support IPv6. MikaL _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sat Feb 22 18:14:19 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17124; Sat, 22 Feb 2003 18:14:19 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1MNKhp12477; Sat, 22 Feb 2003 18:20:44 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1ML1ip04879 for ; Sat, 22 Feb 2003 16:01:44 -0500 Received: from netcore.fi (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15390 for ; Sat, 22 Feb 2003 15:53:30 -0500 (EST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h1MKvBU32692; Sat, 22 Feb 2003 22:57:11 +0200 Date: Sat, 22 Feb 2003 22:57:10 +0200 (EET) From: Pekka Savola To: Ralph Droms cc: dhcwg@ietf.org, In-Reply-To: <4.3.2.7.2.20030211103734.03d92e18@funnel.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [dhcwg] Re: WG last call on draft-ietf-dhc-dhcpv6-opt-prefix-delegation-02.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , On Tue, 11 Feb 2003, Ralph Droms wrote: > draft-ietf-dhc-dhcpv6-opt-prefix-delegation-02.txt describes new DHCPv6 > options and a mechanism through which a "delegating router" (e.g., an ISP > aggregation device) can assign and delegate one or more prefixes to a > "requesting router" (e.g., CPE). This draft is available as > http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-opt-prefix-delegation-02.txt A few comments. Bigger issues -- I'm sorry for bringing them up so late (relatively), but I haven't really thought/read about the big picture, before. 1) I fail to see why to add T1 and T2 in IA_PD. They seem to be mostly redundant -- the requesting router should just take the minimum of lifetimes of the prefixes, calculate it in the same fashion, that's it. Of course, there is an assumption (which doesn't seem to be properly addressed!) that the requesting router is free to refresh the delegation when it feels right, even every hour, day, month etc. without regard to the lifetimes -- indeed, I think *NO* implementation would just wait until the last minute to refresh them. Is there something I'm missing? 2) Multiple IA_PD looks unnecessarily complex. Are there any valid reasons why it wouldn't be just enough to have only one IA_PD per requesting router? (The option to and subsequent complexity of) generating one for each interface seems like a completely unnecessary feature to me -- it's the router which should be doing prefix delegation to it's downstream interfaces! The only feature I can quickly think of which could profit from this is kind of "shared routers" where the connected interfaces are separate administrative entities with differently configured properties at the ISP. This seems questionable to me, a case for manual configuration or "advanced prefix delegation" to me. So, I think the possibility to do prefix delegation in more complex ways than really necessary should be seriously considered. Keep it Simple, Stupid would be a good rule. 3) One item that may also need some consideration is the option to let the requesting router give its preference to some values (prefix length, lifetimes, IAprefix-options contents (maybe?), the prefixes). I'm not sure of the usefulness of these, really. In the real world, I think ISP's set them, either to some values communicated off-band, or otherwise. The complexity required (policy, policy,...) when the delegating router must decide whether it can agree to the requested values seems like a big hit. I'm not really sure whether it's worth it, even though it may offer some flexibility for some corner cases. The only commonly used one I could think of would be whether the customer wants _single_ /64 (for the only one subnet!) or whole /48 -- seems like a heavy baggage for that. 4) As one who hasn't really read DHCPv6 specification, the spec was confusing as it introduced options and code values, and reused ones from DHCPv6 quite liberally (more of this below in detailed comments). I would have hoped for a bit clearer picture of elements associated with DHCP prefix delegation. 5) as above, there doesn't seem to be clear structure to the document when specifying the DHCPv6 PD-specific options (and different DHCPv6 options altogether) [sections 8-9, mostly]: this makes it rather difficult to follow the which options include which options, what options may be embedded in which, etc. This may partially be due to the fact I'm not so familiar with DHCPv6, but some kind of "hierarchy" or "big picture" was missing. ==> in consequence I think there are at least two items, 1-3 which need some thought (if they haven't already been brought up and discussed), and at least 4-5 which would clarify the specification which are IMO very important in conveying the right message. As for more detailed comments...: Identity Association for Prefix Delegation (IA_PD) A collection of prefixes assigned to the requesting router. Each IA_PD has an associated IAID. ==> first use of "IAID", so spell it out, or even put is as an item in the terminology, as it keeps cropping up all the time. 4. Model and Applicability ==> the middle/latter part of this paragraph could be reorganized/reworded a bit to say that the model described there is indeed just an example; perhaps break off starting at page 5 as a separate sub-section? The delegating router chooses prefix(es) for delegation, and returns the prefix(es) to the requesting router. ==> the use of "returns the prefix(es)" seems slightly ambiguous -- could one read that and get a picture that the delegator gives back the same prefixes requested? Did I misunderstand, or did you mean along the lines of "responds with prefixes delegated to the requesing router" ? Figure 1 illustrates a network architecture in which prefix delegation would be used. ==> s/would/could/ ? The IAID uniquely identifies the IA_PD and must be chosen to be unique among the IA_PD IDs on the requesting router. ==> s/IDs/IAIDs/ ? option-code: OPTION_IA_PD (TBD) option-length: 12 + length of IA_PD-options field. ==> is it necessary to say how the option-code is stored/transported (signed/unsigned) ? I guess this is clear enough? ==> length of IA_PD-options field in which units? Octets, seems likely? ==> same issues in sect 9 T1 The time at which the requesting router contacts T2 The time at which the requesting router contacts ==> s/contacts/should contact/ or even "is instructed to contact" IA_PD-options Options associated with this IA_PD. The IA_PD-options field encapsulates those options that are specific to this IA_PD. For example, all of the IA_PD Prefix Options carrying the prefixes associated with this IA_PD are in the IA_PD-options field. ==> one should refer to the next section and explain that currently, only IA_PD Prefix option is defined? (I'd structure section 9 maybe differently: like "IA_PD options" as the main section title, and the current one as a subsection, but some other clarification would also be ok). In a message sent by a delegating router to a requesting router, the requesting router MUST use the values in the T1 and T2 fields for the T1 and T2 parameters. ==> the first part of the sentence is awkward, did you mean something like "In case the message sent by the delegating router included non-zero T1 or T2, the parameters MUST be used" ? The status of any operations involving this IA_PD Prefix option is indicated in a Status Code option in the IAprefix-options field. ==> Status Code options haven't been explained. The requesting router MUST ignore any Advertise message that includes a Status Code option containing the value NoPrefixAvail, ==> where is the defintion of NoPrefixAvail or other codes? message for the user, a Server Identifier option with the delegating router's DUID and a Client Identifier option with the requesting router's DUID. ==> DUID used for the first time (inherited from DHCPv6 spec I think), spell it out? ==> all in all, I think one should have a better picture which kinds of options from DHCPv6 spec which aren't mentioned in the draft are ok (or if some aren't applicable) -- or at least refer to those in the previous sections. Each prefix has valid and preferred lifetimes whose duration is ==> s/duration is/durations are/ When a requesting router subnets a delegated prefix, it must assign additional bits to the prefix to generate unique, longer prefixes. For example, if the requesting router in Figure 1 were delegated 3FFE:FFFF:0::/48, it might generate 3FFE:FFFF:0:1::/64 and 3FFE:FFFF:0:2::/64 for assignment to the two links in the subscriber network. ==> I'm not sure if the first sentence is entirely accurate. One could use prefix delegation to get multiple /64's directly from your ISP, then extra bits wouldn't be needed at all. When a delegating router receives a Request message from a requesting router that contains an IA_PD option, and the delegating router is authorised to delegate prefix(es) to the requesting router, the delegating router selects the prefix(es) to be delegated to the requesting router. The mechanism through which the delegating router selects prefix(es) for delegation is not specified in this document. Section 10.2 gives examples of ways in which a delegating router might select the prefix(es) to be delegated to a requesting router. A delegating router examines the prefix(es) identified in IA_PD Prefix options (in an IA_PD option) in Renew and Rebind messages and responds according to the current status of the prefix(es). [...] ==> These paragraph deal with a different message types and situations, etc., so separating them more clearly in the text would be useful (start using a similar sentence or whatever). ==> same goes in the next paragraph 14. Security Considerations ==> personally I'm rather worried about the requestor being able to give "guidance" to the delegator what on what it wants. Unreliable input could lead to bad results in an implementation which hasn't been done carefully (requesting link/site-local prefixes which don't exist, effect of bogus prefixlengths etc.etc.). [more of this was above] -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sat Feb 22 21:59:24 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20001; Sat, 22 Feb 2003 21:59:24 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1N376p25351; Sat, 22 Feb 2003 22:07:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1N32Mp25059 for ; Sat, 22 Feb 2003 22:02:22 -0500 Received: from imr2.ericy.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19929 for ; Sat, 22 Feb 2003 21:54:01 -0500 (EST) Received: from mr5.exu.ericsson.se (mr5att.ericy.com [138.85.224.141]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id h1N2vkb18037; Sat, 22 Feb 2003 20:57:46 -0600 (CST) Received: from eamrcnt760.exu.ericsson.se (eamrcnt760.exu.ericsson.se [138.85.133.38]) by mr5.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id h1N2vkp12309; Sat, 22 Feb 2003 20:57:46 -0600 (CST) Received: by eamrcnt760.exu.ericsson.se with Internet Mail Service (5.5.2656.59) id ; Sat, 22 Feb 2003 20:57:45 -0600 Message-ID: From: "Bernie Volz (EUD)" To: "'Franco Travostino'" , Ralph Droms , dhcwg@ietf.org, ips@ece.cmu.edu Subject: RE: [dhcwg] Re: WG last call on (Reminder!) Date: Sat, 22 Feb 2003 20:56:06 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2DAE7.1BE6095A" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2DAE7.1BE6095A Content-Type: text/plain; charset="ISO-8859-1" Yes, this is a good point and something we should make clear in all future options drafts. Minor changes to the Abstract and Introduction should fix this. Abstract This document describes the DHCP option to allow iSNS clients using DHCP[ for IPv4] to automatically discover the location of the iSNS server. iSNS ... 1. Introduction The Dynamic Host Configuration Protocol [for IPv4 | [DHCP]] provides a framework for passing configuration information to hosts. However, anyone attempting to implement this for DHCPv6 or studying this carefully would notice: - No reference to the DHCPv6 specification (there is to the DHCPv4 spec) - Option numbers and lengths are only 8 bits (not the 16 of DHCPv6) I support this draft (even without the above changes). - Bernie -----Original Message----- From: Franco Travostino [mailto:travos@nortelnetworks.com] Sent: Friday, February 21, 2003 2:05 PM To: Ralph Droms; dhcwg@ietf.org; ips@ece.cmu.edu Subject: [dhcwg] Re: WG last call on (Reminder!) I support the draft. An observation regarding IPv4 vs IPv6. Other DHCP documents make it clear that they are talking about IPv4 use (e.g., rfc 3361, ""Dynamic Host Configuration Protocol (DHCP-for-IPv4) Option for Session Initiation Protocol (SIP) Servers""). If there is an agreed-upon style for defining applicability, it should be used here as well. -franco At 01:23 PM 2/20/2003, Ralph Droms wrote: >Reminder and note: there has been not response to this WG last >call. Please review draft-ietf-dhc-isnsoption-04.txt and reply with >comments. If you recommend the document for advancement without revision, >please respond with a quick acknowledgment. No response will be >interpreted as a lack of support for advancing the document. > >----- > >This message announces a WG last call on "DHCP Options for Internet >Storage Name Service" . The last call >will conclude on Friday, 2/21. > >Note that this is a parallel WG last call in the dhc and ips WGs. > >draft-ietf-dhc-isnsoption-04.txt defines a new DHCP option for discovery >of the location and role of iSNS Protocol servers in iSCSI and iFCP >devices. The draft is available at >http://www.ietf.org/internet-drafts/draft-ietf-dhc-isnsoption-04.txt > >- Ralph Droms _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg ------_=_NextPart_001_01C2DAE7.1BE6095A Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] Re: WG last call on = <draft-ietf-dhc-isnsoption-04.txt> (Reminder!)

Yes, this is a good point and something we should = make clear in all
future options drafts. Minor changes to the Abstract = and Introduction
should fix this.

     Abstract

        This = document describes the DHCP option to allow iSNS clients using
        DHCP[ for = IPv4] to automatically discover the location of the iSNS server. = iSNS
        = ...

     = 1.       Introduction

        The = Dynamic Host Configuration Protocol [for IPv4 | [DHCP]] provides a = framework for
        passing = configuration information to hosts.
 
However, anyone attempting to implement this for = DHCPv6 or studying this
carefully would notice:
- No reference to the DHCPv6 specification (there is = to the DHCPv4 spec)
- Option numbers and lengths are only 8 bits (not = the 16 of DHCPv6)

I support this draft (even without the above = changes).

- Bernie

-----Original Message-----
From: Franco Travostino [mailto:travos@nortelnetworks.c= om]
Sent: Friday, February 21, 2003 2:05 PM
To: Ralph Droms; dhcwg@ietf.org; = ips@ece.cmu.edu
Subject: [dhcwg] Re: WG last call on = <draft-ietf-dhc-isnsoption-04.txt>
(Reminder!)



I support the draft.

An observation regarding IPv4 vs IPv6. Other DHCP = documents make it clear
that they are talking about IPv4 use (e.g., rfc = 3361, ""Dynamic Host
Configuration Protocol (DHCP-for-IPv4) Option for = Session Initiation
Protocol (SIP) Servers""). If there is an = agreed-upon style for defining
applicability, it should be used here as = well.

-franco



At 01:23 PM 2/20/2003, Ralph Droms wrote:
>Reminder and note: there has been not response = to this WG last
>call.  Please review = draft-ietf-dhc-isnsoption-04.txt and reply with
>comments.  If you recommend the document = for advancement without revision,
>please respond with a quick = acknowledgment.  No response will be
>interpreted as a lack of support for advancing = the document.
>
>-----
>
>This message announces a WG last call on = "DHCP Options for Internet
>Storage Name Service" = <draft-ietf-dhc-isnsoption-04.txt>.  The last call
>will conclude on Friday, 2/21.
>
>Note that this is a parallel WG last call in the = dhc and ips WGs.
>
>draft-ietf-dhc-isnsoption-04.txt defines a new = DHCP option for discovery
>of the location and role of iSNS Protocol = servers in iSCSI and iFCP
>devices.  The draft is available at
>http://www.ietf.org/internet-drafts/draft-ietf-dhc-isn= soption-04.txt
>
>- Ralph Droms

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg

------_=_NextPart_001_01C2DAE7.1BE6095A-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sun Feb 23 11:07:52 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09271; Sun, 23 Feb 2003 11:07:52 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1NGFnp11124; Sun, 23 Feb 2003 11:15:49 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1NGEOp11094 for ; Sun, 23 Feb 2003 11:14:24 -0500 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09245 for ; Sun, 23 Feb 2003 11:05:47 -0500 (EST) From: juha.wiljakka@nokia.com Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h1NGChm12324 for ; Sun, 23 Feb 2003 18:12:43 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Sun, 23 Feb 2003 18:09:38 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Sun, 23 Feb 2003 18:09:38 +0200 Received: from esebe005.NOE.Nokia.com ([172.21.138.45]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Sun, 23 Feb 2003 18:09:37 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Sun, 23 Feb 2003 18:09:37 +0200 Message-ID: <245DBCAEEC4F074CB77B3F984FF9834F0193C272@esebe005.ntc.nokia.com> Thread-Topic: WG last call on draft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt Thread-Index: AcLaZZynvrulm453S7+HDXpNQWfSyQA66Q7Q To: Cc: , , X-OriginalArrivalTime: 23 Feb 2003 16:09:37.0984 (UTC) FILETIME=[F6D7DC00:01C2DB55] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h1NGEOp11095 Subject: [dhcwg] RE: WG last call on draft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi all! Even though I find standardizing "stateless DNS discovery" in the IPv6 wg very important, I find this DHCPv6 option useful. So I also support moving it forward. Juha Wiljakka _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sun Feb 23 12:59:25 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10468; Sun, 23 Feb 2003 12:59:25 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1NI7Tp16422; Sun, 23 Feb 2003 13:07:29 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1NI6kp15664 for ; Sun, 23 Feb 2003 13:06:46 -0500 Received: from atlrel6.hp.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10456 for ; Sun, 23 Feb 2003 12:58:05 -0500 (EST) Received: from iconsrv5.india.hp.com (iconsrv5.india.hp.com [15.42.229.13]) by atlrel6.hp.com (Postfix) with ESMTP id D44221C00D9B; Sun, 23 Feb 2003 13:01:55 -0500 (EST) Received: from nt23056 (nt23056.india.hp.com [15.42.230.56]) by iconsrv5.india.hp.com (8.9.3/8.9.3 SMKit7.02) with SMTP id XAA24919; Sun, 23 Feb 2003 23:31:18 +0530 (IST) Reply-To: From: "Vijayabhaskar A K" To: "'Pekka Savola'" , "'Ralph Droms'" Cc: , Subject: RE: [dhcwg] Re: WG last call on draft-ietf-dhc-dhcpv6-opt-prefix-delegation-02.txt Date: Sun, 23 Feb 2003 23:30:36 +0530 Message-ID: <000601c2db65$78a62750$38e62a0f@nt23056> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Importance: Normal Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Pekka See my reply inline. ~Vijay > -----Original Message----- > From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org]On Behalf Of > Pekka Savola > Sent: Sunday, February 23, 2003 2:27 AM > To: Ralph Droms > Cc: dhcwg@ietf.org; ipng@sunroof.eng.sun.com > Subject: [dhcwg] Re: WG last call on > draft-ietf-dhc-dhcpv6-opt-prefix-delegation-02.txt > > > On Tue, 11 Feb 2003, Ralph Droms wrote: > > draft-ietf-dhc-dhcpv6-opt-prefix-delegation-02.txt > describes new DHCPv6 > > options and a mechanism through which a "delegating router" > (e.g., an ISP > > aggregation device) can assign and delegate one or more > prefixes to a > > "requesting router" (e.g., CPE). This draft is available as > > > http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-opt- > prefix-delegation-02.txt > > A few comments. > > Bigger issues -- I'm sorry for bringing them up so late > (relatively), but > I haven't really thought/read about the big picture, before. > > 1) I fail to see why to add T1 and T2 in IA_PD. They seem to be > mostly redundant -- the requesting router should just take > the minimum of > lifetimes of the prefixes, calculate it in the same fashion, > that's it. > Of course, there is an assumption (which doesn't seem to be properly > addressed!) that the requesting router is free to refresh the > delegation > when it feels right, even every hour, day, month etc. without > regard to > the lifetimes -- indeed, I think *NO* implementation would > just wait until > the last minute to refresh them. > > Is there something I'm missing? Normally, T1 will be assigned with a value which is 0.5 times the shortest preferred lifetime of the prefixes in the IA_PD. This means you have enough time till the expiration of lifetimes of the prefixes. > > 2) Multiple IA_PD looks unnecessarily complex. Are there any valid > reasons why it wouldn't be just enough to have only one IA_PD per > requesting router? (The option to and subsequent complexity of) > generating one for each interface seems like a completely unnecessary > feature to me -- it's the router which should be doing prefix > delegation > to it's downstream interfaces! Seperate IA_PDs for every downstream interface is not mandatory. Look at the following text: One IA_PD can be associated with the requesting router, with a set of interfaces or with exactly one interface. A requesting router must create at least one distinct IA_PD. It may associate a distinct IA_PD with each of its downstream network interfaces and use that IA_PD to obtain a prefix for that interface from the delegating router. Its requesting routers' wish to have single or multiple IA_PDs. > > The only feature I can quickly think of which could profit > from this is > kind of "shared routers" where the connected interfaces are separate > administrative entities with differently configured > properties at the ISP. Exactly. That's the case. When the downstreaming interfaces are served my multiple ISPs, you need multiple IA_PDs. > This seems questionable to me, a case for manual configuration or > "advanced prefix delegation" to me. > > So, I think the possibility to do prefix delegation in more > complex ways > than really necessary should be seriously considered. Keep it Simple, > Stupid would be a good rule. Generate IA_PDs such that every ISP is associtated with a single IA_PD. I think, this is the simplest method possible. > > 3) One item that may also need some consideration is the > option to let the > requesting router give its preference to some values (prefix length, > lifetimes, IAprefix-options contents (maybe?), the prefixes). I'm not > sure of the usefulness of these, really. In the real world, > I think ISP's > set them, either to some values communicated off-band, or > otherwise. The > complexity required (policy, policy,...) when the delegating > router must > decide whether it can agree to the requested values seems > like a big hit. > I'm not really sure whether it's worth it, even though it may > offer some > flexibility for some corner cases. The only commonly used one I could > think of would be whether the customer wants _single_ /64 > (for the only > one subnet!) or whole /48 -- seems like a heavy baggage for that. Yes. I too agree with you. If there is no pre-configured information for the requesting router in the delegating router, it wont be able to to know whether the requesting routers needs /48 or /64 bit prefix. Probably, the solution would be, in the request message, the requesting routers can specify prefix length it prefers. But, the server MUST process that and delegate prefixes accordingly, else it should send back NoPrefixAvail. > > 4) As one who hasn't really read DHCPv6 specification, the spec was > confusing as it introduced options and code values, and > reused ones from > DHCPv6 quite liberally (more of this below in detailed > comments). I would > have hoped for a bit clearer picture of elements associated with DHCP > prefix delegation. > > 5) as above, there doesn't seem to be clear structure to the > document when > specifying the DHCPv6 PD-specific options (and different > DHCPv6 options > altogether) [sections 8-9, mostly]: this makes it rather difficult to > follow the which options include which options, what options may be > embedded in which, etc. This may partially be due to the > fact I'm not so > familiar with DHCPv6, but some kind of "hierarchy" or "big > picture" was > missing. > > ==> in consequence I think there are at least two items, 1-3 > which need > some thought (if they haven't already been brought up and > discussed), and > at least 4-5 which would clarify the specification which are IMO very > important in conveying the right message. > > As for more detailed comments...: > > Identity Association for Prefix Delegation (IA_PD) A collection of > prefixes assigned to the requesting > router. Each > IA_PD has an associated IAID. > > ==> first use of "IAID", so spell it out, or even put is as > an item in the > terminology, as it keeps cropping up all the time. > > 4. Model and Applicability > > ==> the middle/latter part of this paragraph could be > reorganized/reworded > a bit to say that the model described there is indeed just an > example; > perhaps break off starting at page 5 as a separate sub-section? > > The delegating router chooses prefix(es) > for delegation, and returns the prefix(es) to the > requesting router. > > ==> the use of "returns the prefix(es)" seems slightly > ambiguous -- could > one read that and get a picture that the delegator gives back > the same > prefixes requested? Did I misunderstand, or did you mean > along the lines > of "responds with prefixes delegated to the requesing router" ? > > Figure 1 illustrates a network architecture in which prefix > delegation would be used. > > ==> s/would/could/ ? > > The IAID uniquely identifies the IA_PD and must be chosen to be > unique among the IA_PD IDs on the requesting router. > > ==> s/IDs/IAIDs/ ? > > option-code: OPTION_IA_PD (TBD) > > option-length: 12 + length of IA_PD-options field. > > ==> is it necessary to say how the option-code is stored/transported > (signed/unsigned) ? I guess this is clear enough? > > ==> length of IA_PD-options field in which units? Octets, > seems likely? > > ==> same issues in sect 9 > > T1 The time at which the requesting router contacts > T2 The time at which the requesting router contacts > > ==> s/contacts/should contact/ or even "is instructed to contact" > > IA_PD-options Options associated with this IA_PD. > > The IA_PD-options field encapsulates those options that > are specific > to this IA_PD. For example, all of the IA_PD Prefix > Options carrying > the prefixes associated with this IA_PD are in the IA_PD-options > field. > > ==> one should refer to the next section and explain that > currently, only > IA_PD Prefix option is defined? (I'd structure section 9 maybe > differently: like "IA_PD options" as the main section title, and the > current one as a subsection, but some other clarification > would also be > ok). > > In a message sent > by a delegating router to a requesting router, the > requesting router > MUST use the values in the T1 and T2 fields for the T1 and T2 > parameters. > > ==> the first part of the sentence is awkward, did you mean > something like > "In case the message sent by the delegating router included > non-zero T1 or > T2, the parameters MUST be used" ? > > The status of any operations involving this IA_PD Prefix > option is > indicated in a Status Code option in the IAprefix-options field. > > ==> Status Code options haven't been explained. > > The requesting router MUST ignore any Advertise message > that includes > a Status Code option containing the value NoPrefixAvail, > > ==> where is the defintion of NoPrefixAvail or other codes? > > message for the user, a Server Identifier option with the > delegating > router's DUID and a Client Identifier option with the requesting > router's DUID. > > ==> DUID used for the first time (inherited from DHCPv6 spec > I think), > spell it out? > > ==> all in all, I think one should have a better picture > which kinds of > options from DHCPv6 spec which aren't mentioned in the draft > are ok (or if > some aren't applicable) -- or at least refer to those in the previous > sections. > > Each prefix has valid and preferred lifetimes whose duration is > > ==> s/duration is/durations are/ > > When a requesting router subnets a delegated prefix, it must assign > additional bits to the prefix to generate unique, longer prefixes. > For example, if the requesting router in Figure 1 were delegated > 3FFE:FFFF:0::/48, it might generate 3FFE:FFFF:0:1::/64 and > 3FFE:FFFF:0:2::/64 for assignment to the two links in the > subscriber > network. > > ==> I'm not sure if the first sentence is entirely accurate. > One could > use prefix delegation to get multiple /64's directly from > your ISP, then > extra bits wouldn't be needed at all. Instead of getting multiple /64 prefixes, if the requesting router belonged to a site with huge number of links, then it can obtain /48 prefix and distribute it among the links. > > When a delegating router receives a Request message from a > requesting > router that contains an IA_PD option, and the delegating router is > authorised to delegate prefix(es) to the requesting router, the > delegating router selects the prefix(es) to be delegated to the > requesting router. The mechanism through which the > delegating router > selects prefix(es) for delegation is not specified in this > document. > Section 10.2 gives examples of ways in which a delegating router > might select the prefix(es) to be delegated to a requesting router. > > A delegating router examines the prefix(es) identified in IA_PD > Prefix options (in an IA_PD option) in Renew and Rebind > messages and > responds according to the current status of the prefix(es). [...] > > ==> These paragraph deal with a different message types and > situations, > etc., so separating them more clearly in the text would be > useful (start > using a similar sentence or whatever). > > ==> same goes in the next paragraph > > 14. Security Considerations > > ==> personally I'm rather worried about the requestor being > able to give > "guidance" to the delegator what on what it wants. > Unreliable input could > lead to bad results in an implementation which hasn't been > done carefully > (requesting link/site-local prefixes which don't exist, > effect of bogus > prefixlengths etc.etc.). [more of this was above] > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > > > > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sun Feb 23 15:51:52 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12425; Sun, 23 Feb 2003 15:51:52 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1NKxqp23573; Sun, 23 Feb 2003 15:59:52 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1NIcnp17877 for ; Sun, 23 Feb 2003 13:38:49 -0500 Received: from netcore.fi (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10898 for ; Sun, 23 Feb 2003 13:30:08 -0500 (EST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h1NIPjG13443; Sun, 23 Feb 2003 20:25:45 +0200 Date: Sun, 23 Feb 2003 20:25:45 +0200 (EET) From: Pekka Savola To: Vijayabhaskar A K cc: "'Ralph Droms'" , , Subject: RE: [dhcwg] Re: WG last call on draft-ietf-dhc-dhcpv6-opt-prefix-delegation-02.txt In-Reply-To: <000601c2db65$78a62750$38e62a0f@nt23056> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Some comments inline. On Sun, 23 Feb 2003, Vijayabhaskar A K wrote: > > 1) I fail to see why to add T1 and T2 in IA_PD. They seem to be > > mostly redundant -- the requesting router should just take the minimum > > of lifetimes of the prefixes, calculate it in the same fashion, that's > > it. Of course, there is an assumption (which doesn't seem to be > > properly addressed!) that the requesting router is free to refresh the > > delegation when it feels right, even every hour, day, month etc. > > without regard to the lifetimes -- indeed, I think *NO* implementation > > would just wait until the last minute to refresh them. > > > > Is there something I'm missing? > > Normally, T1 will be assigned with a value which is 0.5 times the > shortest preferred lifetime of the prefixes in the IA_PD. This > means you have enough time till the expiration of lifetimes of the > prefixes. That doesn't answer the real question. That is, the requesting router is in charge of all the prefixes until they expire. The robust requesting router implementation will perform some sane refreshing of these bindings way before they expire, even periodically. Thus, I fail to see any reason why these values would have to be communicated from the delegator. > > 2) Multiple IA_PD looks unnecessarily complex. Are there any valid > > reasons why it wouldn't be just enough to have only one IA_PD per > > requesting router? (The option to and subsequent complexity of) > > generating one for each interface seems like a completely unnecessary > > feature to me -- it's the router which should be doing prefix > > delegation > > to it's downstream interfaces! > > Seperate IA_PDs for every downstream interface is not mandatory. > Look at the following text: > > One IA_PD can be associated > with the requesting router, with a set of interfaces or with exactly > one interface. A requesting router must create at least one distinct > IA_PD. It may associate a distinct IA_PD with each of its downstream > network interfaces and use that IA_PD to obtain a prefix for that > interface from the delegating router. > > Its requesting routers' wish to have single or multiple IA_PDs. I know it is not mandatory: but it seems (mostly) unnecessary to me, which was the real point. > > The only feature I can quickly think of which could profit > > from this is > > kind of "shared routers" where the connected interfaces are separate > > administrative entities with differently configured > > properties at the ISP. > > Exactly. That's the case. > When the downstreaming interfaces are served my multiple ISPs, > you need multiple IA_PDs. Prefix delegation by DHCP is not meant to be all-purpose-zero-configuration tool for routers, I think. This seems conflicting -- a fringe case which should not came up. Better would be just require that the requesting router will get a delegation from all the ISP's for itself, and subnet accordingly. If the following does not apply, it seems to me that there must be routers connected to the downstreaming interfaces -- which in turn could perform prefix delegation directly from the ISP, the first router acting as a relay. Doesn't seem to be need for this.. > > This seems questionable to me, a case for manual configuration or > > "advanced prefix delegation" to me. > > > > So, I think the possibility to do prefix delegation in more > > complex ways > > than really necessary should be seriously considered. Keep it Simple, > > Stupid would be a good rule. > > Generate IA_PDs such that every ISP is associtated with a single > IA_PD. I think, this is the simplest method possible. Seems wrong to me: An IA_PD is a construct through which a delegating router and a requesting router can identify, group and manage a set of related IPv6 prefixes. and: Identity Association for Prefix Delegation (IA_PD) A collection of prefixes assigned to the requesting router. Each IA_PD has an associated IAID. ==> the model appears to be, to me, that the requesting router makes an association with *one* delegating router. In that case, multiple IA_PD's for multiple seem unnecessary. If this is not the case, the applicability section needs to be worked out a bit more. Also, then I can't help wondering what multiple prefixes are for. Why would anyone (except for bogus /64 for every downstream link -delegating requests) want multiple prefixes? (note: site-local is not applicable, different admin domains.) Regardless of that, I'm not sure how the requesting router would discover more of these delegating routers -- how would they be connected? Which kind of infrastructure would typically be between requesting router and multiple delegating routers? > > 3) One item that may also need some consideration is the option to let > > the requesting router give its preference to some values (prefix > > length, lifetimes, IAprefix-options contents (maybe?), the prefixes). > > I'm not sure of the usefulness of these, really. In the real world, I > > think ISP's set them, either to some values communicated off-band, or > > otherwise. The complexity required (policy, policy,...) when the > > delegating router must decide whether it can agree to the requested > > values seems like a big hit. I'm not really sure whether it's worth > > it, even though it may offer some flexibility for some corner cases. > > The only commonly used one I could think of would be whether the > > customer wants _single_ /64 (for the only one subnet!) or whole /48 -- > > seems like a heavy baggage for that. > > Yes. I too agree with you. If there is no pre-configured information > for the requesting router in the delegating router, it wont > be able to to know whether the requesting routers needs /48 or > /64 bit prefix. > > Probably, the solution would be, in the request message, the requesting > routers can specify prefix length it prefers. But, the server MUST > process that and delegate prefixes accordingly, else it should > send back NoPrefixAvail. I agree that for certain requested values, the outcome would get very confusing for the requesting router if the delegating router could not fullfill these requirements. But the point was different: I think the whole "preference for X" model seems mostly unnecessary. > > One could use prefix delegation to get multiple /64's directly from > > your ISP, then extra bits wouldn't be needed at all. > > Instead of getting multiple /64 prefixes, if the requesting router > belonged to a site with huge number of links, then it can obtain /48 > prefix and distribute it among the links. I totally agree with that (that's the sensible thing to do!), but the first sentence was not accurate, as you don't split /64 prefixes *IF* you'd do it nonetheless. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Feb 24 08:00:46 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12908; Mon, 24 Feb 2003 08:00:46 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1OD94p23943; Mon, 24 Feb 2003 08:09:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1OD7Ep23506 for ; Mon, 24 Feb 2003 08:07:14 -0500 Received: from rtp-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12770 for ; Mon, 24 Feb 2003 07:58:12 -0500 (EST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h1OD24Nh008112 for ; Mon, 24 Feb 2003 08:02:04 -0500 (EST) Received: from rdroms-w2k.cisco.com (rtp-vpn1-204.cisco.com [10.82.224.204]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id IAA02943 for ; Mon, 24 Feb 2003 08:02:03 -0500 (EST) Message-Id: <4.3.2.7.2.20030220134034.03e69258@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 24 Feb 2003 08:00:00 -0500 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [dhcwg] WG last call on draft-ietf-dhc-dhcpv6-loadb-02.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Reminder and note: there has been not response to this WG last call. Please review draft-ietf-dhc-dhcpv6-loadb-02.txt and reply with comments. If you recommend the document for advancement without revision, please respond with a quick acknowledgment. No response will be interpreted as a lack of support for advancing the document. ----- This message announces a WG last call on "Load Balancing for DHCPv6" . The last call will conclude on Friday, 2/28. draft-ietf-dhc-dhcpv6-loadb-02.txt specifies a load balancing algorithm for use with DHCPv6, which enables multiple cooperating DHCPv6 servers to decide which one should service a client without exchanging any information beyond initial configuration. This draft is available as http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-loadb-02.txt - Ralph Droms _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Feb 24 08:01:03 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12956; Mon, 24 Feb 2003 08:01:03 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1OD9Tp23960; Mon, 24 Feb 2003 08:09:29 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1OD7Fp23550 for ; Mon, 24 Feb 2003 08:07:15 -0500 Received: from rtp-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12773 for ; Mon, 24 Feb 2003 07:58:13 -0500 (EST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h1OD25Nh008115; Mon, 24 Feb 2003 08:02:05 -0500 (EST) Received: from rdroms-w2k.cisco.com (rtp-vpn1-204.cisco.com [10.82.224.204]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id IAA02946; Mon, 24 Feb 2003 08:02:04 -0500 (EST) Message-Id: <4.3.2.7.2.20030220132513.00ba9a40@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 24 Feb 2003 08:00:00 -0500 To: dhcwg@ietf.org, ipng@sunroof.eng.sun.com From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [dhcwg] WG last call on draft-ietf-dhc-dhcpv6-opt-prefix-delegation-02.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Reminder and note: there has been not response to this WG last call. Please review draft-ietf-dhc-dhcpv6-opt-prefix-delegation-02.txt and reply with comments. If you recommend the document for advancement without revision, please respond with a quick acknowledgment. No response will be interpreted as a lack of support for advancing the document. ----- This message announces a WG last call on "IPv6 Prefix Options for DHCPv6" . The last call will conclude on Friday, 2/28. Note that this is a parallel WG last call in the dhc and ipv6 WGs. draft-ietf-dhc-dhcpv6-opt-prefix-delegation-02.txt describes new DHCPv6 options and a mechanism through which a "delegating router" (e.g., an ISP aggregation device) can assign and delegate one or more prefixes to a "requesting router" (e.g., CPE). This draft is available as http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-opt-prefix-delegation-02.txt - Ralph Droms _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Feb 24 08:48:43 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14445; Mon, 24 Feb 2003 08:48:43 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1ODvDp26256; Mon, 24 Feb 2003 08:57:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1ODuEp26196 for ; Mon, 24 Feb 2003 08:56:14 -0500 Received: from rtp-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14363 for ; Mon, 24 Feb 2003 08:47:10 -0500 (EST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h1ODp2JR011295; Mon, 24 Feb 2003 08:51:02 -0500 (EST) Received: from rdroms-w2k.cisco.com (dhcp-161-44-149-251.cisco.com [161.44.149.251]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id IAA04960; Mon, 24 Feb 2003 08:51:02 -0500 (EST) Message-Id: <4.3.2.7.2.20030224084930.03f2a828@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 24 Feb 2003 08:51:01 -0500 To: dhcwg@ietf.org, ipng@sunroof.eng.sun.com From: Ralph Droms In-Reply-To: <4.3.2.7.2.20030220132513.00ba9a40@funnel.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [dhcwg] Re: WG last call on draft-ietf-dhc-dhcpv6-opt-prefix-delegation-02.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Please ignore the first sentence of this reminder - it was queued for transmission before the round of discussion that began at the end of last week... - Ralph At 08:00 AM 2/24/2003 -0500, Ralph Droms wrote: >Reminder and note: there has been not response to this WG last >call. Please review draft-ietf-dhc-dhcpv6-opt-prefix-delegation-02.txt >and reply with comments. If you recommend the document for advancement >without revision, please respond with a quick acknowledgment. No response >will be interpreted as a lack of support for advancing the document. > >----- > >This message announces a WG last call on "IPv6 Prefix Options for DHCPv6" >. The last call will >conclude on Friday, 2/28. > >Note that this is a parallel WG last call in the dhc and ipv6 WGs. > >draft-ietf-dhc-dhcpv6-opt-prefix-delegation-02.txt describes new DHCPv6 >options and a mechanism through which a "delegating router" (e.g., an ISP >aggregation device) can assign and delegate one or more prefixes to a >"requesting router" (e.g., CPE). This draft is available as >http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-opt-prefix-delegation-02.txt > >- Ralph Droms >-------------------------------------------------------------------- >IETF IPng Working Group Mailing List >IPng Home Page: http://playground.sun.com/ipng >FTP archive: ftp://playground.sun.com/pub/ipng >Direct all administrative requests to majordomo@sunroof.eng.sun.com >-------------------------------------------------------------------- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Feb 24 12:41:00 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20088; Mon, 24 Feb 2003 12:41:00 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1OHnWp09796; Mon, 24 Feb 2003 12:49:32 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1OHmPp09755 for ; Mon, 24 Feb 2003 12:48:25 -0500 Received: from rtp-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20030 for ; Mon, 24 Feb 2003 12:39:17 -0500 (EST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h1OHh8Nh024277; Mon, 24 Feb 2003 12:43:09 -0500 (EST) Received: from rdroms-w2k.cisco.com (dhcp-161-44-149-251.cisco.com [161.44.149.251]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id MAA23894; Mon, 24 Feb 2003 12:43:08 -0500 (EST) Message-Id: <4.3.2.7.2.20030224123058.03f484a8@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 24 Feb 2003 12:43:06 -0500 To: dhcwg@ietf.org, ipng@sunroof.eng.sun.com, namedroppers@ops.ietf.org From: Ralph Droms Subject: Re: [dhcwg] Re: WG last call on draft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt In-Reply-To: <1045912992.27180.14.camel@devil> References: <4.3.2.7.2.20030220135524.03e6d548@funnel.cisco.com> <4.3.2.7.2.20030220135524.03e6d548@funnel.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Summary of discussion during WG last call on draft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt Pekka Savola, Tony Lindstrom, Bernie Volz and Peter Koch all responded with editorial suggestions. These suggestions have been incorporated into the draft and will appear in next published rev. Peter Koch and Rob Austein commented on the "Security Considerations"; specifically, whether DNSSEC can prevent problems caused by a search list supplied as part of an attack by a DHCP server. Based on Rob's argument (and assuming I understood Rob correctly) that DNSSEC can guarantee that a host can trust the replies it receives, but DNSSEC can't guarantee that the host has asked the right question based on its search list, I'm inclined to leave the text in question unchanged. Alain Durand raised the issue of supplying both IPv4 and IPv6 addresses for DNS resolvers in the DNS server option. I judged the rough consensus in the responses to be that restricting the DNS server option to return only IPv6 addresses is acceptable. - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Feb 24 12:41:30 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20144; Mon, 24 Feb 2003 12:41:30 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1OHo1p09846; Mon, 24 Feb 2003 12:50:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1OHjOp09575 for ; Mon, 24 Feb 2003 12:45:24 -0500 Received: from shuttle.wide.toshiba.co.jp (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19908 for ; Mon, 24 Feb 2003 12:36:16 -0500 (EST) Received: from localhost (unknown [3ffe:501:100f:f::6]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id C846C15210; Tue, 25 Feb 2003 02:40:16 +0900 (JST) Date: Tue, 25 Feb 2003 02:40:10 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Ralph Droms Cc: dhcwg@ietf.org, ipng@sunroof.eng.sun.com In-Reply-To: <4.3.2.7.2.20030224084930.03f2a828@funnel.cisco.com> References: <4.3.2.7.2.20030220132513.00ba9a40@funnel.cisco.com> <4.3.2.7.2.20030224084930.03f2a828@funnel.cisco.com> User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.2 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 21 Subject: [dhcwg] Re: WG last call on draft-ietf-dhc-dhcpv6-opt-prefix-delegation-02.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , >>>>> On Mon, 24 Feb 2003 08:51:01 -0500, >>>>> Ralph Droms said: > Please ignore the first sentence of this reminder - it was queued for > transmission before the round of discussion that began at the end of last > week... >> Reminder and note: there has been not response to this WG last >> call. Please review draft-ietf-dhc-dhcpv6-opt-prefix-delegation-02.txt >> and reply with comments. If you recommend the document for advancement >> without revision, please respond with a quick acknowledgment. No response >> will be interpreted as a lack of support for advancing the document. I basically support the idea of the draft, but I have several issues to be discussed before advancing it. I'll re-read the latest revision and send a list of issues in a few days. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Feb 24 13:26:38 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21677; Mon, 24 Feb 2003 13:26:38 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1OIZCp12689; Mon, 24 Feb 2003 13:35:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1OIYip12650 for ; Mon, 24 Feb 2003 13:34:44 -0500 Received: from palrel10.hp.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21642 for ; Mon, 24 Feb 2003 13:25:34 -0500 (EST) Received: from iconsrv5.india.hp.com (iconsrv5.india.hp.com [15.42.229.13]) by palrel10.hp.com (Postfix) with ESMTP id DB9E61C0152D; Mon, 24 Feb 2003 10:29:25 -0800 (PST) Received: from nt23056 (nt23056.india.hp.com [15.42.230.56]) by iconsrv5.india.hp.com (8.9.3/8.9.3 SMKit7.02) with SMTP id XAA17328; Mon, 24 Feb 2003 23:58:49 +0530 (IST) Reply-To: From: "Vijayabhaskar A K" To: "'Pekka Savola'" Cc: "'Ralph Droms'" , , Subject: RE: [dhcwg] Re: WG last call on draft-ietf-dhc-dhcpv6-opt-prefix-delegation-02.txt Date: Mon, 24 Feb 2003 23:58:06 +0530 Message-ID: <001901c2dc32$7a55e400$38e62a0f@nt23056> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Importance: Normal Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit My comments inline.... ~ Vijay > -----Original Message----- > From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org]On Behalf Of > Pekka Savola > Sent: Sunday, February 23, 2003 11:56 PM > To: Vijayabhaskar A K > Cc: 'Ralph Droms'; dhcwg@ietf.org; ipng@sunroof.eng.sun.com > Subject: RE: [dhcwg] Re: WG last call on > draft-ietf-dhc-dhcpv6-opt-prefix-delegation-02.txt > > > Some comments inline. > > On Sun, 23 Feb 2003, Vijayabhaskar A K wrote: > > > 1) I fail to see why to add T1 and T2 in IA_PD. They seem to be > > > mostly redundant -- the requesting router should just > take the minimum > > > of lifetimes of the prefixes, calculate it in the same > fashion, that's > > > it. Of course, there is an assumption (which doesn't seem to be > > > properly addressed!) that the requesting router is free > to refresh the > > > delegation when it feels right, even every hour, day, month etc. > > > without regard to the lifetimes -- indeed, I think *NO* > implementation > > > would just wait until the last minute to refresh them. > > > > > > Is there something I'm missing? > > > > Normally, T1 will be assigned with a value which is 0.5 times the > > shortest preferred lifetime of the prefixes in the IA_PD. This > > means you have enough time till the expiration of lifetimes of the > > prefixes. > > That doesn't answer the real question. > > That is, the requesting router is in charge of all the > prefixes until they > expire. The robust requesting router implementation will > perform some > sane refreshing of these bindings way before they expire, even > periodically. > > Thus, I fail to see any reason why these values would have to be > communicated from the delegator. Yes, I agree that the it can refresh the bindings at any periodic intervals it want. But, what if the delegating router is dead and not responding at all? Hence, dhcpv6 provides you with two values: T1 -> This is the time at which the requesting router starts contacting the delegating router for the renewal of the lease... T2 -> If till the expiration of T2 it didn't get the response from the delegating router, it can contact any available dhcpv6 server to refresh its bindings. Ofcourse, the requesting router can generate these values itself. With DHCPv6 server sending T1 and T2 values, the requesting router dont need to recalculate the values again and again.. Trust the DHCPv6 server, the values provided by it makes the requesting router to refresh its bindings well before the expiry.. > > > > 2) Multiple IA_PD looks unnecessarily complex. Are there > any valid > > > reasons why it wouldn't be just enough to have only one IA_PD per > > > requesting router? (The option to and subsequent complexity of) > > > generating one for each interface seems like a completely > unnecessary > > > feature to me -- it's the router which should be doing prefix > > > delegation > > > to it's downstream interfaces! > > > > Seperate IA_PDs for every downstream interface is not mandatory. > > Look at the following text: > > > > One IA_PD can be associated > > with the requesting router, with a set of interfaces or > with exactly > > one interface. A requesting router must create at least > one distinct > > IA_PD. It may associate a distinct IA_PD with each of > its downstream > > network interfaces and use that IA_PD to obtain a prefix for that > > interface from the delegating router. > > > > Its requesting routers' wish to have single or multiple IA_PDs. > > I know it is not mandatory: but it seems (mostly) unnecessary > to me, which > was the real point. > > > > The only feature I can quickly think of which could profit > > > from this is > > > kind of "shared routers" where the connected interfaces > are separate > > > administrative entities with differently configured > > > properties at the ISP. > > > > Exactly. That's the case. > > When the downstreaming interfaces are served my multiple ISPs, > > you need multiple IA_PDs. > > Prefix delegation by DHCP is not meant to be > all-purpose-zero-configuration tool for routers, I think. > > This seems conflicting -- a fringe case which should not came up. > > Better would be just require that the requesting router will get a > delegation from all the ISP's for itself, and subnet accordingly. > > If the following does not apply, it seems to me that there > must be routers > connected to the downstreaming interfaces -- which in turn > could perform > prefix delegation directly from the ISP, the first router acting as a > relay. > > Doesn't seem to be need for this.. Need not be. Simple case is Home networks, they dont afford to have individual routers for every ISPs. They may need multiple ISPs for high availablity or some other reason. In this case, there will be only one border router with mutiple appliances/nodes in the downstreaming interfaces, which may span in one or more links. In this case, it needs to unique IA_PD for every ISP. > > > > This seems questionable to me, a case for manual configuration or > > > "advanced prefix delegation" to me. > > > > > > So, I think the possibility to do prefix delegation in more > > > complex ways > > > than really necessary should be seriously considered. > Keep it Simple, > > > Stupid would be a good rule. > > > > Generate IA_PDs such that every ISP is associtated with a single > > IA_PD. I think, this is the simplest method possible. > > Seems wrong to me: > > An IA_PD is a construct through which a delegating router and a > requesting router can identify, group and manage a set of related > IPv6 prefixes. > > and: > > Identity Association for Prefix Delegation (IA_PD) A > collection of > prefixes assigned to the requesting > router. Each > IA_PD has an associated IAID. > > ==> the model appears to be, to me, that the requesting > router makes an > association with *one* delegating router. In that case, > multiple IA_PD's > for multiple seem unnecessary. > > If this is not the case, the applicability section needs to > be worked out > a bit more. > > Also, then I can't help wondering what multiple prefixes are for. Why > would anyone (except for bogus /64 for every downstream link > -delegating > requests) want multiple prefixes? (note: site-local is not > applicable, > different admin domains.) May be for high availabilty, it may get prefixes from multiple ISPs. > > Regardless of that, I'm not sure how the requesting router > would discover > more of these delegating routers -- how would they be > connected? Which > kind of infrastructure would typically be between requesting > router and > multiple delegating routers? I beleive there will be unique dialup connection with each ISPs. > > > > 3) One item that may also need some consideration is the > option to let > > > the requesting router give its preference to some values (prefix > > > length, lifetimes, IAprefix-options contents (maybe?), > the prefixes). > > > I'm not sure of the usefulness of these, really. In the > real world, I > > > think ISP's set them, either to some values communicated > off-band, or > > > otherwise. The complexity required (policy, policy,...) when the > > > delegating router must decide whether it can agree to the > requested > > > values seems like a big hit. I'm not really sure whether > it's worth > > > it, even though it may offer some flexibility for some > corner cases. > > > The only commonly used one I could think of would be whether the > > > customer wants _single_ /64 (for the only one subnet!) or > whole /48 -- > > > seems like a heavy baggage for that. > > > > Yes. I too agree with you. If there is no pre-configured information > > for the requesting router in the delegating router, it wont > > be able to to know whether the requesting routers needs /48 or > > /64 bit prefix. > > > > Probably, the solution would be, in the request message, > the requesting > > routers can specify prefix length it prefers. But, the server MUST > > process that and delegate prefixes accordingly, else it should > > send back NoPrefixAvail. > > I agree that for certain requested values, the outcome would get very > confusing for the requesting router if the delegating router > could not > fullfill these requirements. > > But the point was different: I think the whole "preference > for X" model > seems mostly unnecessary. > > > One could use prefix delegation to get multiple /64's > directly from > > > your ISP, then extra bits wouldn't be needed at all. > > > > Instead of getting multiple /64 prefixes, if the requesting router > > belonged to a site with huge number of links, then it can obtain /48 > > prefix and distribute it among the links. > > I totally agree with that (that's the sensible thing to do!), but the > first sentence was not accurate, as you don't split /64 prefixes *IF* > you'd do it nonetheless. > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Feb 24 14:20:53 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23291; Mon, 24 Feb 2003 14:20:53 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1OJTOp16750; Mon, 24 Feb 2003 14:29:24 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1OJHip15871 for ; Mon, 24 Feb 2003 14:17:44 -0500 Received: from noxmail.sandelman.ottawa.on.ca (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22893 for ; Mon, 24 Feb 2003 14:08:34 -0500 (EST) Received: from sandelman.ottawa.on.ca (marajade.sandelman.ottawa.on.ca [192.139.46.20]) by noxmail.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id h1OJCLv26703 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK); Mon, 24 Feb 2003 14:12:27 -0500 (EST) Received: from marajade.sandelman.ottawa.on.ca (marajade [127.0.0.1]) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian -4) with ESMTP id h1OJCJFp016385 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Mon, 24 Feb 2003 14:12:21 -0500 Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by marajade.sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian -4) with ESMTP id h1OJCIPV016363; Mon, 24 Feb 2003 14:12:19 -0500 Message-Id: <200302241912.h1OJCIPV016363@marajade.sandelman.ottawa.on.ca> To: dhcwg@ietf.org, Ted Lemon Subject: Re: [dhcwg] Re: WG last call on draft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt In-reply-to: Your message of "Fri, 21 Feb 2003 10:48:44 MST." Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Mon, 24 Feb 2003 14:12:17 -0500 From: Michael Richardson Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Ted" == Ted Lemon writes: Ted> I'm not sure why you would have a deployed DHCPv6 server and not Ted> deploy a DNS resolver that listens to requests on an IPv6 socket. Ted> Can anybody give a rationale for this? Has anybody done this? Was Ted> it a problem? 1) IPv6 DNS server machine died - not mission critical, won't be fixed immediately. 2) IPv6 router that gets you there died. 3) some new bug in bind9 means that it dies for IPv6 transport, but not for IPv4. All of these would result in me telling clients to try IPv4 first. Often, seeminly unreasonable configurations are the result of trying to patch around a problem elsewhere. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Finger me for keys iQCVAwUBPlpukIqHRg3pndX9AQETpQQAwiES3iMU/f/8RKIlx/QC1okUZhhOEjmi 6IKX5R9OYSdOreEfwYGTHiyVMsqiGK5ZiD0tW82QHmwPuhPO8mJj+Y4WDeatn47D w3ZAf6PsUYpEbehlXw4/e24SGYB9+y9ZnWa6CZq9easeqRT/wnMmDwoT6JgWOUrg YMYyrh3xmUs= =jLdv -----END PGP SIGNATURE----- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Feb 24 14:31:37 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23718; Mon, 24 Feb 2003 14:31:37 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1OJeBp18094; Mon, 24 Feb 2003 14:40:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1OJdop18021 for ; Mon, 24 Feb 2003 14:39:50 -0500 Received: from rtp-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23676 for ; Mon, 24 Feb 2003 14:30:39 -0500 (EST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h1OJYVJR005563; Mon, 24 Feb 2003 14:34:31 -0500 (EST) Received: from rdroms-w2k.cisco.com (dhcp-161-44-149-251.cisco.com [161.44.149.251]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA05165; Mon, 24 Feb 2003 14:34:30 -0500 (EST) Message-Id: <4.3.2.7.2.20030224140504.03f26948@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 24 Feb 2003 14:34:29 -0500 To: dhcwg@ietf.org, From: Ralph Droms Subject: Re: [dhcwg] Re: WG last call on draft-ietf-dhc-dhcpv6-opt-prefix-delegation-02.txt In-Reply-To: References: <4.3.2.7.2.20030211103734.03d92e18@funnel.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Pekka, Thanks for your review and feedback on draft-ietf-dhc-dhcpv6-opt-prefix-delegation-02 My comments are in line... - Ralph At 10:57 PM 2/22/2003 +0200, Pekka Savola wrote: >On Tue, 11 Feb 2003, Ralph Droms wrote: > > draft-ietf-dhc-dhcpv6-opt-prefix-delegation-02.txt describes new DHCPv6 > > options and a mechanism through which a "delegating router" (e.g., an ISP > > aggregation device) can assign and delegate one or more prefixes to a > > "requesting router" (e.g., CPE). This draft is available as > > > http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-opt-prefix-delegation-02.txt > >A few comments. > >Bigger issues -- I'm sorry for bringing them up so late (relatively), but >I haven't really thought/read about the big picture, before. > >1) I fail to see why to add T1 and T2 in IA_PD. They seem to be >mostly redundant -- the requesting router should just take the minimum of >lifetimes of the prefixes, calculate it in the same fashion, that's it. >Of course, there is an assumption (which doesn't seem to be properly >addressed!) that the requesting router is free to refresh the delegation >when it feels right, even every hour, day, month etc. without regard to >the lifetimes -- indeed, I think *NO* implementation would just wait until >the last minute to refresh them. > >Is there something I'm missing? The spec allows for flexibility in deployment scenarios by allowing the ISP (through the delegating router) to control the behavior of the requesting router, or by leaving the behavior under the control of the requesting router by setting T1 and T2 to 0 (see section 8 of the draft). >2) Multiple IA_PD looks unnecessarily complex. Are there any valid >reasons why it wouldn't be just enough to have only one IA_PD per >requesting router? (The option to and subsequent complexity of) >generating one for each interface seems like a completely unnecessary >feature to me -- it's the router which should be doing prefix delegation >to it's downstream interfaces! > >The only feature I can quickly think of which could profit from this is >kind of "shared routers" where the connected interfaces are separate >administrative entities with differently configured properties at the ISP. >This seems questionable to me, a case for manual configuration or >"advanced prefix delegation" to me. > >So, I think the possibility to do prefix delegation in more complex ways >than really necessary should be seriously considered. Keep it Simple, >Stupid would be a good rule. There is no requirement that the delegating router supply more than one IA_PD to the requesting router, and limiting the delegation to only one IA_PD seems overly restrictive. For example, a delegating router might send one IA_PD for each ISP used by a customer site. It is not the intention of the draft that the requesting router receive one IA_PD for each of its downstream interfaces. If that is your understanding of the draft, then we need to clarify the text. In section 11.1, the draft specifies that the requesting router assigns subnets from the delegated prefixes to each of its downstream interfaces. >3) One item that may also need some consideration is the option to let the >requesting router give its preference to some values (prefix length, >lifetimes, IAprefix-options contents (maybe?), the prefixes). I'm not >sure of the usefulness of these, really. In the real world, I think ISP's >set them, either to some values communicated off-band, or otherwise. The >complexity required (policy, policy,...) when the delegating router must >decide whether it can agree to the requested values seems like a big hit. >I'm not really sure whether it's worth it, even though it may offer some >flexibility for some corner cases. The only commonly used one I could >think of would be whether the customer wants _single_ /64 (for the only >one subnet!) or whole /48 -- seems like a heavy baggage for that. The cost of allowing the requesting router to express its preferences isn't all that great - a simple delegating router can simply ignore the requesting router's preferences... >4) As one who hasn't really read DHCPv6 specification, the spec was >confusing as it introduced options and code values, and reused ones from >DHCPv6 quite liberally (more of this below in detailed comments). I would >have hoped for a bit clearer picture of elements associated with DHCP >prefix delegation. Well, this option (and the spec) really isn't useful without DHCP, so I don't think it's unreasonable to expect a fair amount of familiarity with DHCPv6 on the part of the reader. However, we can edit the draft to include some additional definitions and concepts from DHCPv6 for clarity. >5) as above, there doesn't seem to be clear structure to the document when >specifying the DHCPv6 PD-specific options (and different DHCPv6 options >altogether) [sections 8-9, mostly]: this makes it rather difficult to >follow the which options include which options, what options may be >embedded in which, etc. This may partially be due to the fact I'm not so >familiar with DHCPv6, but some kind of "hierarchy" or "big picture" was >missing. We can take a look at those sections and try to edit them for clarity, and we'll make some changes based on the more detailed comments you made below... >==> in consequence I think there are at least two items, 1-3 which need >some thought (if they haven't already been brought up and discussed), and >at least 4-5 which would clarify the specification which are IMO very >important in conveying the right message. > >As for more detailed comments...: > > Identity Association for Prefix Delegation (IA_PD) A collection of > prefixes assigned to the requesting router. Each > IA_PD has an associated IAID. > >==> first use of "IAID", so spell it out, or even put is as an item in the >terminology, as it keeps cropping up all the time. OK. >4. Model and Applicability > >==> the middle/latter part of this paragraph could be reorganized/reworded >a bit to say that the model described there is indeed just an example; >perhaps break off starting at page 5 as a separate sub-section? I suppose we could break section 4 into a couple of subsections, to clarify what text is describing the example scenario and what text is describing the use of the prefix delegation option more generally. >The delegating router chooses prefix(es) > for delegation, and returns the prefix(es) to the requesting router. > >==> the use of "returns the prefix(es)" seems slightly ambiguous -- could >one read that and get a picture that the delegator gives back the same >prefixes requested? Did I misunderstand, or did you mean along the lines >of "responds with prefixes delegated to the requesing router" ? "responds with prefixes[...]" is the correct clarification; we can make that change. > Figure 1 illustrates a network architecture in which prefix > delegation would be used. > >==> s/would/could/ ? OK. > The IAID uniquely identifies the IA_PD and must be chosen to be > unique among the IA_PD IDs on the requesting router. > >==> s/IDs/IAIDs/ ? Yes. > option-code: OPTION_IA_PD (TBD) > > option-length: 12 + length of IA_PD-options field. > >==> is it necessary to say how the option-code is stored/transported >(signed/unsigned) ? I guess this is clear enough? The format of the option code is (should be?) specified in the DHCPv6 spec. >==> length of IA_PD-options field in which units? Octets, seems likely? OK. >==> same issues in sect 9 > > T1 The time at which the requesting router contacts > T2 The time at which the requesting router contacts > >==> s/contacts/should contact/ or even "is instructed to contact" OK > IA_PD-options Options associated with this IA_PD. > > The IA_PD-options field encapsulates those options that are specific > to this IA_PD. For example, all of the IA_PD Prefix Options carrying > the prefixes associated with this IA_PD are in the IA_PD-options > field. > >==> one should refer to the next section and explain that currently, only >IA_PD Prefix option is defined? (I'd structure section 9 maybe >differently: like "IA_PD options" as the main section title, and the >current one as a subsection, but some other clarification would also be >ok). OK. > In a message sent > by a delegating router to a requesting router, the requesting router > MUST use the values in the T1 and T2 fields for the T1 and T2 > parameters. > >==> the first part of the sentence is awkward, did you mean something like >"In case the message sent by the delegating router included non-zero T1 or >T2, the parameters MUST be used" ? OK. > The status of any operations involving this IA_PD Prefix option is > indicated in a Status Code option in the IAprefix-options field. > >==> Status Code options haven't been explained. We can add an entry in the terminology section with a pointer to the DHCPv6 spec. > The requesting router MUST ignore any Advertise message that includes > a Status Code option containing the value NoPrefixAvail, > >==> where is the defintion of NoPrefixAvail or other codes? Needs a pointer to the DHCPv6 spec? > message for the user, a Server Identifier option with the delegating > router's DUID and a Client Identifier option with the requesting > router's DUID. > >==> DUID used for the first time (inherited from DHCPv6 spec I think), >spell it out? Needs a pointer to the DHCPv6 spec? >==> all in all, I think one should have a better picture which kinds of >options from DHCPv6 spec which aren't mentioned in the draft are ok (or if >some aren't applicable) -- or at least refer to those in the previous >sections. > > Each prefix has valid and preferred lifetimes whose duration is > >==> s/duration is/durations are/ OK. > When a requesting router subnets a delegated prefix, it must assign > additional bits to the prefix to generate unique, longer prefixes. > For example, if the requesting router in Figure 1 were delegated > 3FFE:FFFF:0::/48, it might generate 3FFE:FFFF:0:1::/64 and > 3FFE:FFFF:0:2::/64 for assignment to the two links in the subscriber > network. > >==> I'm not sure if the first sentence is entirely accurate. One could >use prefix delegation to get multiple /64's directly from your ISP, then >extra bits wouldn't be needed at all. But that wouldn't be "subnetting", I don't think - just reassignment? > When a delegating router receives a Request message from a requesting > router that contains an IA_PD option, and the delegating router is > authorised to delegate prefix(es) to the requesting router, the > delegating router selects the prefix(es) to be delegated to the > requesting router. The mechanism through which the delegating router > selects prefix(es) for delegation is not specified in this document. > Section 10.2 gives examples of ways in which a delegating router > might select the prefix(es) to be delegated to a requesting router. > > A delegating router examines the prefix(es) identified in IA_PD > Prefix options (in an IA_PD option) in Renew and Rebind messages and > responds according to the current status of the prefix(es). [...] > >==> These paragraph deal with a different message types and situations, >etc., so separating them more clearly in the text would be useful (start >using a similar sentence or whatever) > >==> same goes in the next paragraph OK. >14. Security Considerations > >==> personally I'm rather worried about the requestor being able to give >"guidance" to the delegator what on what it wants. Unreliable input could >lead to bad results in an implementation which hasn't been done carefully >(requesting link/site-local prefixes which don't exist, effect of bogus >prefixlengths etc.etc.). [more of this was above] Paranoid delegating routers can simply ignore the guidance... >-- >Pekka Savola "You each name yourselves king, yet the >Netcore Oy kingdom bleeds." >Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Feb 24 14:32:25 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23752; Mon, 24 Feb 2003 14:32:25 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1OJf2p18143; Mon, 24 Feb 2003 14:41:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1OJeTp18108 for ; Mon, 24 Feb 2003 14:40:29 -0500 Received: from imr1.ericy.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23716 for ; Mon, 24 Feb 2003 14:31:18 -0500 (EST) Received: from mr5.exu.ericsson.se (mr5u3.ericy.com [208.237.135.124]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id h1OJZ7d15014; Mon, 24 Feb 2003 13:35:08 -0600 (CST) Received: from eamrcnt761.exu.ericsson.se (eamrcnt761.exu.ericsson.se [138.85.133.39]) by mr5.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id h1OJZ7Z11540; Mon, 24 Feb 2003 13:35:08 -0600 (CST) Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2656.59) id ; Mon, 24 Feb 2003 13:35:07 -0600 Message-ID: From: "Bernie Volz (EUD)" To: "'Ralph Droms'" , dhcwg@ietf.org, ipng@sunroof.eng.sun.com, namedroppers@ops.ietf.org Subject: RE: [dhcwg] Re: WG last call on draft-ietf-dhc-dhcpv6-opt-dnsconf ig-02.txt Date: Mon, 24 Feb 2003 13:33:27 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2DC3B.9AC3CE60" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2DC3B.9AC3CE60 Content-Type: text/plain; charset="iso-8859-1" Isn't it possible for the DHCPv6 server to return IPv4 addresses as per RFC 2373, section 2.5.4 (IPv6 Addresses with Embedded IPv4 Addresses), in particular: A second type of IPv6 address which holds an embedded IPv4 address is also defined. This address is used to represent the addresses of IPv4-only nodes (those that *do not* support IPv6) as IPv6 addresses. This type of address is termed an "IPv4-mapped IPv6 address" and has the format: | 80 bits | 16 | 32 bits | +--------------------------------------+--------------------------+ |0000..............................0000|FFFF| IPv4 address | +--------------------------------------+----+---------------------+ - Bernie -----Original Message----- From: Ralph Droms [mailto:rdroms@cisco.com] Sent: Monday, February 24, 2003 12:43 PM To: dhcwg@ietf.org; ipng@sunroof.eng.sun.com; namedroppers@ops.ietf.org Subject: Re: [dhcwg] Re: WG last call on draft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt Summary of discussion during WG last call on draft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt Pekka Savola, Tony Lindstrom, Bernie Volz and Peter Koch all responded with editorial suggestions. These suggestions have been incorporated into the draft and will appear in next published rev. Peter Koch and Rob Austein commented on the "Security Considerations"; specifically, whether DNSSEC can prevent problems caused by a search list supplied as part of an attack by a DHCP server. Based on Rob's argument (and assuming I understood Rob correctly) that DNSSEC can guarantee that a host can trust the replies it receives, but DNSSEC can't guarantee that the host has asked the right question based on its search list, I'm inclined to leave the text in question unchanged. Alain Durand raised the issue of supplying both IPv4 and IPv6 addresses for DNS resolvers in the DNS server option. I judged the rough consensus in the responses to be that restricting the DNS server option to return only IPv6 addresses is acceptable. - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg ------_=_NextPart_001_01C2DC3B.9AC3CE60 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] Re: WG last call on = draft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt

Isn't it possible for the DHCPv6 server to return = IPv4 addresses as per
RFC 2373, section 2.5.4 (IPv6 Addresses with = Embedded IPv4 Addresses),
in particular:

   A second type of IPv6 address which = holds an embedded IPv4 address is
   also defined.  This address is = used to represent the addresses of
   IPv4-only nodes (those that *do not* = support IPv6) as IPv6 addresses.
   This type of address is termed an = "IPv4-mapped IPv6 address" and has
   the format:

   = |            = ;    80 = bits           &n= bsp;   | 16 |      32 = bits        |
   = +--------------------------------------+--------------------------+
   = |0000..............................0000|FFFF|    IPv4 = address     |
   = +--------------------------------------+----+---------------------+

- Bernie

-----Original Message-----
From: Ralph Droms [mailto:rdroms@cisco.com]
Sent: Monday, February 24, 2003 12:43 PM
To: dhcwg@ietf.org; ipng@sunroof.eng.sun.com; = namedroppers@ops.ietf.org
Subject: Re: [dhcwg] Re: WG last call on
draft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt


Summary of discussion during WG last call on
draft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt

Pekka Savola, Tony Lindstrom, Bernie Volz and Peter = Koch all responded with
editorial suggestions.  These suggestions have = been incorporated into the
draft and will appear in next published rev.

Peter Koch and Rob Austein commented on the = "Security Considerations";
specifically, whether DNSSEC can prevent problems = caused by a search list
supplied as part of an attack by a DHCP = server.  Based on Rob's argument
(and assuming I understood Rob correctly) that = DNSSEC can guarantee that a
host can trust the replies it receives, but DNSSEC = can't guarantee that the
host has asked the right question based on its = search list, I'm inclined to
leave the text in question unchanged.

Alain Durand raised the issue of supplying both IPv4 = and IPv6 addresses for
DNS resolvers in the DNS server option.  I = judged the rough consensus in
the responses to be that restricting the DNS server = option to return only
IPv6 addresses is acceptable.

- Ralph


_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg

------_=_NextPart_001_01C2DC3B.9AC3CE60-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Feb 24 15:12:47 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25053; Mon, 24 Feb 2003 15:12:46 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1OKLDp20582; Mon, 24 Feb 2003 15:21:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1OK5lp19082 for ; Mon, 24 Feb 2003 15:05:47 -0500 Received: from raeburn.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24392 for ; Mon, 24 Feb 2003 14:56:35 -0500 (EST) Received: from kal-el.raeburn.org (mail@kal-el.raeburn.org [18.101.0.230]) by raeburn.org (8.11.3/8.11.3) with ESMTP id h1OK0Sh08639; Mon, 24 Feb 2003 15:00:28 -0500 (EST) Received: from raeburn by kal-el.raeburn.org with local (Exim 3.35 #1 (Debian)) id 18nOm3-0003vE-00; Mon, 24 Feb 2003 15:00:27 -0500 From: Ken Raeburn To: dhcwg@ietf.org References: <87heaxpclz.fsf@luminous.mit.edu> Date: Mon, 24 Feb 2003 15:00:27 -0500 In-Reply-To: <87heaxpclz.fsf@luminous.mit.edu> (Sam Hartman's message of "Fri, 21 Feb 2003 16:06:48 -0500") Message-ID: Lines: 91 User-Agent: Gnus/5.090006 (Oort Gnus v0.06) Emacs/21.1.50 (i686-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [dhcwg] Re: Comments on draft-ietf-dhc-pktc-kerb-tckt-00.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Sam Hartman writes: > Hi. I'm not subscribed to the list, so please copy me on responses. > I'm sending these comments because a review of the option from a > Kerberos viewpoint was requested. Same here.... > The rationale for this draft claims that it will be used among other > reasons to cancel subscriber service. The presence of a Kerberos > ticket should not be used to imply authorization to use a service; > this is incompatible both with RFC 1510 and with current Kerberos > drafts. Even if the authorization data field is used to convey > authorization along with authentication, service tickets with should > not be issued with lifetimes longer than are acceptable. I.E. you > should only issue a ticket with a lifetime as long as you are willing > to have authorization cached. Agreed. The security model should not rely on the CCD behaving itself nicely. Even if you want long-lived tickets, presumably to reduce the frequency with which public-key PKINIT operations need to be done, and if you want them to carry authorization data, you could use renewable tickets or server-based hot-lists to close out a customer's access fairly quickly. Renewable tickets require repeated communication with the KDC to get new valid tickets with later expiration times, but they don't require the same public-key operations, and thus should be cheaper in CPU time. > The option if it exists should serve to invalidate caches to > deal with operational problems such as emergency rekeying of services > or testing, These do seem like valid reasons. > and the only effect of failing to honor this option should > be a temporary loss of service. If the issue is that the old service key has been exposed, failing to honor this option could result in transmitting arbitrary data "securely" to an intruder, or in a way that an intruder may be able to read it. I don't think there's much that can be done about that; it's comparable to choosing not to check a certificate revocation list. > The format of this option is insufficiently extensible. Many of the > sixteen code points for available services have already been used and > experiences shows new Kerberos services tend to be deployed over time. > Why would you want to selectively invalidate some but not all tickets? > If this option exists, it seems like providing a mechanism to > completely invalidate the cache should be sufficient. Completely invalidating the cache means starting over with public key ops, and reauthenticating to unaffected services that may be in active use at the time. There may be some benefit to invalidating only certain tickets, in cases like emergency rekeying of a single compromised service. I won't speak to the extensibility issue, not knowing much about the Packet Cable context. > Finally security considerations need to discuss the disadvantages of > storing persistent Kerberos tickets. Other deployments of Kerberos > are moving away from doing this and instead storing tickets in > volatile memory. It would be excellent if the write up of this issue > in the security considerations section gave numbers to justify the > need for persistent tickets, although requiring this would be > excessive. Keeping Kerberos tickets for the long term is probably not a great idea, though since the CCD is presumably storing a public key pair anyways, the usual reasons concerning limited exposure after a compromise of the device don't apply as much. The difficulty of revocation is a more interesting issue. However, since I'd expect the CCD is likely to reconnect and reauthenticate to the system on power-up, avoidance of a huge server load spike after a power outage by retaining tickets for a while would be a good thing, especially with PKINIT. (As would randomized delays, if the retained tickets are found to have already expired at power-up time.) Oh, and an editorial issue: "Persist" is not a transitive verb in any English-language dictionary I've checked; it doesn't take an object. "The CCD persists Kerberos tickets" is just wrong. "Persist" is what the tickets do; it's not done to them. Perhaps "retain" or "store" should be used, maybe specifically mentioning persistent storage? ("Persistent", instead of "persisted", is fine as an adjective.) Ken _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Feb 24 16:31:02 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27172; Mon, 24 Feb 2003 16:31:02 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1OLdap26459; Mon, 24 Feb 2003 16:39:36 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1OLcLp26351 for ; Mon, 24 Feb 2003 16:38:21 -0500 Received: from sj-msg-core-3.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27134 for ; Mon, 24 Feb 2003 16:29:08 -0500 (EST) Received: from jschnizl-w2k.cisco.com (rtp-vpn2-224.cisco.com [10.82.240.224]) by sj-msg-core-3.cisco.com (8.12.2/8.12.6) with ESMTP id h1OLWnB7018432 for ; Mon, 24 Feb 2003 13:32:49 -0800 (PST) Message-Id: <4.3.2.7.2.20030224161059.045e2d00@wells.cisco.com> X-Sender: jschnizl@wells.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 24 Feb 2003 16:16:07 -0500 To: dhcwg@ietf.org From: John Schnizlein Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [dhcwg] Methods of protecting DHCP relay-agent information options Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This is the summary I promised in Atlanta. Two methods to protect the contents of the relay-agent information option (RAIO) have been proposed: (1) encapsulating the DHCP message in IPsec (RA-IPsec) [draft-droms-dhcp-relay-agent-ipsec-00.txt] and (2) including a message authentication sub-option (AuthSO) [draft-ietf-dhc-auth-suboption-01.txt] similar to the authentication option for protecting options between clients and servers [RFC 3118]. Which method is suitable depends on different circumstances. Both methods employ keyed message authentication codes, and require distribution of key material. Both methods must also support the separate insertion of RAIO by a "trusted" device closer to the client and GIADDR by a subsequent relay agent, specified in section 2.1 of RFC 3046. AuthSO accommodates this separation the same way that RFC 3118 does, by excluding mutable fields from the integrity computation. Because RA-IPsec necessarily covers the entire message, it must establish IPsec security associations (SA) between each pair of relay agents in the path as well as the SA between the last relay agent and the DHC server. In circumstances where the deployment of DHCP involves this separation of relay-agent function, the RA-IPsec method would entail more configuration of these SAs than the equivalent key management for AuthSO. In circumstances where the "trusted" device requires protection for RAIO, and does not already have the machinery for IPsec Encapsulating Security Payload the AuthSO method might entail less implementation than RA-IPsec. Where IPsec is already in all relay agents, the IPsec method would avoid implementing AuthSO. IPsec is based on existing protocols and technology, and can leverage key distribution mechanisms and other future improvements. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Feb 24 17:29:10 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28736; Mon, 24 Feb 2003 17:29:10 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1OMbdp30694; Mon, 24 Feb 2003 17:37:39 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1OMaGp29912 for ; Mon, 24 Feb 2003 17:36:16 -0500 Received: from toccata.fugue.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28706 for ; Mon, 24 Feb 2003 17:27:01 -0500 (EST) Received: from nominum.com (az-ben-pm3-2-13.ppp.theriver.com [206.25.50.13]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id h1OMRYN17837; Mon, 24 Feb 2003 16:27:35 -0600 (CST) Date: Mon, 24 Feb 2003 15:30:56 -0700 Subject: Re: [dhcwg] Re: WG last call on draft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: dhcwg@ietf.org To: Michael Richardson From: Ted Lemon In-Reply-To: <200302241912.h1OJCIPV016363@marajade.sandelman.ottawa.on.ca> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > Often, seeminly unreasonable configurations are the result of trying > to patch around a problem elsewhere. I.e., they're not something with which a standards body need necessarily concern itself. ;') To be less provocative, my point is that if we are using DHCPv6, we probably are expecting that the IPv6 infrastructure we are using works. If not, why are we trying to use it? If it's broken, isn't the right answer to fix it? I'm not saying you shouldn't kludge around problems like this when you're trying to get other work done, but when I kludge around an infrastructure problem, what I normally do is some kind of ugly hack that I wouldn't want to see in a standard anyway. Since Ralph has already declared rough consensus on this point, I think there's no point in discussing it further anyway. :'} _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Feb 24 18:27:16 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00039; Mon, 24 Feb 2003 18:27:16 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1ONZsp01176; Mon, 24 Feb 2003 18:35:54 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1ONYNp01099 for ; Mon, 24 Feb 2003 18:34:23 -0500 Received: from peacock.tci.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29981 for ; Mon, 24 Feb 2003 18:25:08 -0500 (EST) Received: from mms02-RelayB.tci.com (mms02-relayb.broadband.att.com [147.191.89.213]) by peacock.tci.com (8.12.2/8.12.2) with ESMTP id h1ONSXJD028494; Mon, 24 Feb 2003 16:28:33 -0700 (MST) Received: from 147.191.89.201 by mms02-relaya.tci.com with ESMTP ( Tumbleweed MMS SMTP Relay (MMS v5.5.0)); Mon, 24 Feb 2003 16:28:24 -0600 Received: by entexchimc02.broadband.att.com with Internet Mail Service ( 5.5.2653.19) id ; Mon, 24 Feb 2003 16:27:56 -0700 Message-ID: <6732623D2548D61193C90002A5C88DCC0566371C@entmaexch02.broadband.att.com> From: "Woundy, Richard" To: "'John Schnizlein'" cc: dhcwg@ietf.org Subject: RE: [dhcwg] Methods of protecting DHCP relay-agent information op tions Date: Mon, 24 Feb 2003 16:28:16 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-WSS-ID: 12447512132962-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit John, There might be one other minor consideration, that I stumbled across after the Atlanta meeting. If DHCP Lease Query messages are implemented by the relay agent, then IPSec encapsulation might be used to protect those messages. I cannot say that DHCP Lease Query is any more or less important than other protocols on the relay agent. But at least it is a protocol under consideration by *this* WG. ;^) -- Rich -----Original Message----- From: John Schnizlein [mailto:jschnizl@cisco.com] Sent: Monday, February 24, 2003 4:16 PM To: dhcwg@ietf.org Subject: [dhcwg] Methods of protecting DHCP relay-agent information options This is the summary I promised in Atlanta. Two methods to protect the contents of the relay-agent information option (RAIO) have been proposed: (1) encapsulating the DHCP message in IPsec (RA-IPsec) [draft-droms-dhcp-relay-agent-ipsec-00.txt] and (2) including a message authentication sub-option (AuthSO) [draft-ietf-dhc-auth-suboption-01.txt] similar to the authentication option for protecting options between clients and servers [RFC 3118]. Which method is suitable depends on different circumstances. Both methods employ keyed message authentication codes, and require distribution of key material. Both methods must also support the separate insertion of RAIO by a "trusted" device closer to the client and GIADDR by a subsequent relay agent, specified in section 2.1 of RFC 3046. AuthSO accommodates this separation the same way that RFC 3118 does, by excluding mutable fields from the integrity computation. Because RA-IPsec necessarily covers the entire message, it must establish IPsec security associations (SA) between each pair of relay agents in the path as well as the SA between the last relay agent and the DHC server. In circumstances where the deployment of DHCP involves this separation of relay-agent function, the RA-IPsec method would entail more configuration of these SAs than the equivalent key management for AuthSO. In circumstances where the "trusted" device requires protection for RAIO, and does not already have the machinery for IPsec Encapsulating Security Payload the AuthSO method might entail less implementation than RA-IPsec. Where IPsec is already in all relay agents, the IPsec method would avoid implementing AuthSO. IPsec is based on existing protocols and technology, and can leverage key distribution mechanisms and other future improvements. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Feb 25 05:59:00 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23028; Tue, 25 Feb 2003 05:59:00 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1PB7vp18330; Tue, 25 Feb 2003 06:07:57 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1P6sjp23989 for ; Tue, 25 Feb 2003 01:54:45 -0500 Received: from netcore.fi (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08334 for ; Tue, 25 Feb 2003 01:45:20 -0500 (EST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h1P6n0W25598; Tue, 25 Feb 2003 08:49:00 +0200 Date: Tue, 25 Feb 2003 08:49:00 +0200 (EET) From: Pekka Savola To: Ralph Droms cc: dhcwg@ietf.org, Subject: Re: [dhcwg] Re: WG last call on draft-ietf-dhc-dhcpv6-opt-prefix-delegation-02.txt In-Reply-To: <4.3.2.7.2.20030224140504.03f26948@funnel.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Similar discussion has already been had, so I'll try to keep it at the minimum. On Mon, 24 Feb 2003, Ralph Droms wrote: > At 10:57 PM 2/22/2003 +0200, Pekka Savola wrote: > >On Tue, 11 Feb 2003, Ralph Droms wrote: > > > draft-ietf-dhc-dhcpv6-opt-prefix-delegation-02.txt describes new DHCPv6 > > > options and a mechanism through which a "delegating router" (e.g., an ISP > > > aggregation device) can assign and delegate one or more prefixes to a > > > "requesting router" (e.g., CPE). This draft is available as > > > > > http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-opt-prefix-delegation-02.txt > > > >A few comments. > > > >Bigger issues -- I'm sorry for bringing them up so late (relatively), but > >I haven't really thought/read about the big picture, before. > > > >1) I fail to see why to add T1 and T2 in IA_PD. They seem to be > >mostly redundant -- the requesting router should just take the minimum of > >lifetimes of the prefixes, calculate it in the same fashion, that's it. > >Of course, there is an assumption (which doesn't seem to be properly > >addressed!) that the requesting router is free to refresh the delegation > >when it feels right, even every hour, day, month etc. without regard to > >the lifetimes -- indeed, I think *NO* implementation would just wait until > >the last minute to refresh them. > > > >Is there something I'm missing? > > The spec allows for flexibility in deployment scenarios by > allowing the ISP (through the delegating router) to control > the behavior of the requesting router, or by leaving the > behavior under the control of the requesting router > by setting T1 and T2 to 0 (see section 8 of the draft). Yes, I noticed they can be zero -- all I'm questioning is the usability of this flexibility. I fail to see why such flexibility is useful. The requesting router can be as flexible as it wants -- and refresh bindings when it deems it necessary even without guidance. > >2) Multiple IA_PD looks unnecessarily complex. Are there any valid > >reasons why it wouldn't be just enough to have only one IA_PD per > >requesting router? (The option to and subsequent complexity of) > >generating one for each interface seems like a completely unnecessary > >feature to me -- it's the router which should be doing prefix delegation > >to it's downstream interfaces! > > > >The only feature I can quickly think of which could profit from this is > >kind of "shared routers" where the connected interfaces are separate > >administrative entities with differently configured properties at the ISP. > >This seems questionable to me, a case for manual configuration or > >"advanced prefix delegation" to me. > > > >So, I think the possibility to do prefix delegation in more complex ways > >than really necessary should be seriously considered. Keep it Simple, > >Stupid would be a good rule. > > There is no requirement that the delegating router supply more than > one IA_PD to the requesting router, and limiting the delegation to > only one IA_PD seems overly restrictive. For example, a delegating > router might send one IA_PD for each ISP used by a customer site. I don't see it overly restrictive myself: as an operator and end-user, if someone connects to two ISP's, it's (almost, at least) always done either from two separate routers (no use doing it from one, really), or in a serial fashion (terminate one, establish the other -- like dialup). > It is not the intention of the draft that the requesting router > receive one IA_PD for each of its downstream interfaces. If that > is your understanding of the draft, then we need to clarify > the text. In section 11.1, the draft specifies that the > requesting router assigns subnets from the delegated prefixes > to each of its downstream interfaces. I understood well that the particular behaviour is only optional, but the problem seems to be that the "main behaviour" is described quickly (indeed, it's rather simple) and then the spec goes on at great length describing the fringe cases. This makes an unwary reader think the fringe cases are actually more than just fringe cases. At least, there should be some clearer separation between the two and possibly some guidance when (for example) not to use special mechanisms. > >3) One item that may also need some consideration is the option to let the > >requesting router give its preference to some values (prefix length, > >lifetimes, IAprefix-options contents (maybe?), the prefixes). I'm not > >sure of the usefulness of these, really. In the real world, I think ISP's > >set them, either to some values communicated off-band, or otherwise. The > >complexity required (policy, policy,...) when the delegating router must > >decide whether it can agree to the requested values seems like a big hit. > >I'm not really sure whether it's worth it, even though it may offer some > >flexibility for some corner cases. The only commonly used one I could > >think of would be whether the customer wants _single_ /64 (for the only > >one subnet!) or whole /48 -- seems like a heavy baggage for that. > > The cost of allowing the requesting router to express its preferences > isn't all that great - a simple delegating router can simply ignore > the requesting router's preferences... Certainly. I see this as a potential problem from two directions: 1) delegating router handling untrusted input values, creating delegations based on them, and 2) the requesting router requesting something that architectually differs *a lot* from what's given (example: /64's directly for its interfaces, and one /48 delegated). Then what? Can the requesting router handle this kind of situation? The problem is that entering preferences *in-band* (instead of out-of-band, as usual) seems problematic, as it creates difficult situations at both ends in the cases the preferences are not met (and policy decisions even if met). At the very least, one should clarify something along the lines of "In any case, the requesting router MUST NOT depend on any of its preferences to be honored" if this feature is really necessary. > > option-code: OPTION_IA_PD (TBD) > > > > option-length: 12 + length of IA_PD-options field. > > > >==> is it necessary to say how the option-code is stored/transported > >(signed/unsigned) ? I guess this is clear enough? > > The format of the option code is (should be?) specified in the > DHCPv6 spec. Ok -- it's just that AFAICS, I don't see that a connection has been made between the two (even if they use the same name). > > The requesting router MUST ignore any Advertise message that includes > > a Status Code option containing the value NoPrefixAvail, > > > >==> where is the defintion of NoPrefixAvail or other codes? > > Needs a pointer to the DHCPv6 spec? At the minimum. > > message for the user, a Server Identifier option with the delegating > > router's DUID and a Client Identifier option with the requesting > > router's DUID. > > > >==> DUID used for the first time (inherited from DHCPv6 spec I think), > >spell it out? > > Needs a pointer to the DHCPv6 spec? Yes please, and spell out the abbreviation in the text (no need to put it up in terminology IMO). > > When a requesting router subnets a delegated prefix, it must assign > > additional bits to the prefix to generate unique, longer prefixes. > > For example, if the requesting router in Figure 1 were delegated > > 3FFE:FFFF:0::/48, it might generate 3FFE:FFFF:0:1::/64 and > > 3FFE:FFFF:0:2::/64 for assignment to the two links in the subscriber > > network. > > > >==> I'm not sure if the first sentence is entirely accurate. One could > >use prefix delegation to get multiple /64's directly from your ISP, then > >extra bits wouldn't be needed at all. > > But that wouldn't be "subnetting", I don't think - just reassignment? Ah, got me there :-). The problem with the language seems to be that even though it says "when ... subnets", there are no other "whens" so this paragraph is taken to imply all of it (especially since the main form of prefix delegation always includes subnetting, as noted earlier in the draft). > >14. Security Considerations > > > >==> personally I'm rather worried about the requestor being able to give > >"guidance" to the delegator what on what it wants. Unreliable input could > >lead to bad results in an implementation which hasn't been done carefully > >(requesting link/site-local prefixes which don't exist, effect of bogus > >prefixlengths etc.etc.). [more of this was above] > > Paranoid delegating routers can simply ignore the guidance... Yep, put that in there :-) -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Feb 25 05:59:00 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23027; Tue, 25 Feb 2003 05:59:00 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1PB7ip18306; Tue, 25 Feb 2003 06:07:45 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1P6hZp23550 for ; Tue, 25 Feb 2003 01:43:35 -0500 Received: from netcore.fi (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08078 for ; Tue, 25 Feb 2003 01:34:11 -0500 (EST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h1P6Tmq25476; Tue, 25 Feb 2003 08:29:51 +0200 Date: Tue, 25 Feb 2003 08:29:48 +0200 (EET) From: Pekka Savola To: Vijayabhaskar A K cc: "'Ralph Droms'" , , Subject: RE: [dhcwg] Re: WG last call on draft-ietf-dhc-dhcpv6-opt-prefix-delegation-02.txt In-Reply-To: <001901c2dc32$7a55e400$38e62a0f@nt23056> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , On Mon, 24 Feb 2003, Vijayabhaskar A K wrote: > > That is, the requesting router is in charge of all the prefixes until > > they expire. The robust requesting router implementation will perform > > some sane refreshing of these bindings way before they expire, even > > periodically. > > > > Thus, I fail to see any reason why these values would have to be > > communicated from the delegator. > > Yes, I agree that the it can refresh the bindings at any periodic > intervals it want. But, what if the delegating router is dead > and not responding at all? Then it will try again a bit later and succeed. > Hence, dhcpv6 provides you with > two values: > T1 -> This is the time at which the requesting router starts > contacting the delegating router for the renewal of the lease... > T2 -> If till the expiration of T2 it didn't get the response > from the delegating router, it can contact any available > dhcpv6 server to refresh its bindings. Do you mean that similar T1 & T2 values are being used by DHCP base spec? In that case I guess it's ok, but otherwise, I still fail to see the usability. > Ofcourse, the requesting router can generate these values itself. > With DHCPv6 server sending T1 and T2 values, the requesting > router dont need to recalculate the values again and again.. > Trust the DHCPv6 server, the values provided by it makes the > requesting router to refresh its bindings well before the expiry.. Well, typically the conventional wisdom is *not* to trust any external parties to any extent greater than necessary :-) > > Prefix delegation by DHCP is not meant to be > > all-purpose-zero-configuration tool for routers, I think. > > > > This seems conflicting -- a fringe case which should not came up. > > > > Better would be just require that the requesting router will get a > > delegation from all the ISP's for itself, and subnet accordingly. > > > > If the following does not apply, it seems to me that there > > must be routers > > connected to the downstreaming interfaces -- which in turn > > could perform > > prefix delegation directly from the ISP, the first router acting as a > > relay. > > > > Doesn't seem to be need for this.. > > Need not be. Simple case is Home networks, they dont afford to have > individual routers for every ISPs. They may need multiple ISPs > for high availablity or some other reason. In this case, there will > be only one border router with mutiple appliances/nodes in the > downstreaming interfaces, which may span in one or more links. > In this case, it needs to unique IA_PD for every ISP. Seems a bit far-fetched, IMO, but ok.. > > Regardless of that, I'm not sure how the requesting router would > > discover more of these delegating routers -- how would they be > > connected? Which kind of infrastructure would typically be between > > requesting router and multiple delegating routers? > > I beleive there will be unique dialup connection with each ISPs. .. as above, I've yet to see dial-up routers deployed which would have two dial-out adapters and phone jacks, but ok.. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Feb 25 06:46:13 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24971; Tue, 25 Feb 2003 06:46:13 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1PBt6p21220; Tue, 25 Feb 2003 06:55:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1PBqbp21120 for ; Tue, 25 Feb 2003 06:52:37 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24191; Tue, 25 Feb 2003 06:43:08 -0500 (EST) Message-Id: <200302251143.GAA24191@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: dhcwg@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 25 Feb 2003 06:43:08 -0500 Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-dhcpv6-interop-00.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Title : Results from Interoperability Tests of DHCPv6 Implementations Author(s) : R. Droms Filename : draft-ietf-dhc-dhcpv6-interop-00.txt Pages : 12 Date : 2003-2-24 This document publishes issues with the DHCPv6 protocols specifications, based on the results of interoperability testing among several implementations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-interop-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dhc-dhcpv6-interop-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-dhcpv6-interop-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: <2003-2-24141918.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-dhcpv6-interop-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-dhcpv6-interop-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-2-24141918.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Feb 25 14:06:04 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10943; Tue, 25 Feb 2003 14:06:04 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1PJEMp22674; Tue, 25 Feb 2003 14:14:22 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1PJC5p22616 for ; Tue, 25 Feb 2003 14:12:05 -0500 Received: from palrel12.hp.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10850 for ; Tue, 25 Feb 2003 14:02:25 -0500 (EST) Received: from iconsrv5.india.hp.com (iconsrv5.india.hp.com [15.42.229.13]) by palrel12.hp.com (Postfix) with ESMTP id CE7A41C0178F; Tue, 25 Feb 2003 11:06:16 -0800 (PST) Received: from nt23056 (nt23056.india.hp.com [15.42.230.56]) by iconsrv5.india.hp.com (8.9.3/8.9.3 SMKit7.02) with SMTP id AAA14218; Wed, 26 Feb 2003 00:35:33 +0530 (IST) Reply-To: From: "Vijayabhaskar A K" To: "'Pekka Savola'" Cc: "'Ralph Droms'" , , Subject: RE: [dhcwg] Re: WG last call on draft-ietf-dhc-dhcpv6-opt-prefix-delegation-02.txt Date: Wed, 26 Feb 2003 00:34:49 +0530 Message-ID: <001e01c2dd00$c5e3bbd0$38e62a0f@nt23056> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Importance: Normal Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > -----Original Message----- > From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org]On Behalf Of > Pekka Savola > Sent: Tuesday, February 25, 2003 12:00 PM > To: Vijayabhaskar A K > Cc: 'Ralph Droms'; dhcwg@ietf.org; ipng@sunroof.eng.sun.com > Subject: RE: [dhcwg] Re: WG last call on > draft-ietf-dhc-dhcpv6-opt-prefix-delegation-02.txt > > > On Mon, 24 Feb 2003, Vijayabhaskar A K wrote: > > > That is, the requesting router is in charge of all the > prefixes until > > > they expire. The robust requesting router implementation > will perform > > > some sane refreshing of these bindings way before they > expire, even > > > periodically. > > > > > > Thus, I fail to see any reason why these values would have to be > > > communicated from the delegator. > > > > Yes, I agree that the it can refresh the bindings at any periodic > > intervals it want. But, what if the delegating router is dead > > and not responding at all? > > Then it will try again a bit later and succeed. The time "bit later" is well defined by DHCPv6 base architecture. > > > Hence, dhcpv6 provides you with > > two values: > > T1 -> This is the time at which the requesting router starts > > contacting the delegating router for the renewal of the lease... > > T2 -> If till the expiration of T2 it didn't get the response > > from the delegating router, it can contact any available > > dhcpv6 server to refresh its bindings. > > Do you mean that similar T1 & T2 values are being used by > DHCP base spec? > In that case I guess it's ok, but otherwise, I still fail to see the > usability. Yes, T1 and T2 values are being used in DHCPv6 base spec. > > > Ofcourse, the requesting router can generate these values itself. > > With DHCPv6 server sending T1 and T2 values, the requesting > > router dont need to recalculate the values again and again.. > > Trust the DHCPv6 server, the values provided by it makes the > > requesting router to refresh its bindings well before the expiry.. > > Well, typically the conventional wisdom is *not* to trust any > external > parties to any extent greater than necessary :-) If you are able to trust the prefixes given by DHCPv6, then there will be no harm in trusting the time values provided by it :-) > > > > Prefix delegation by DHCP is not meant to be > > > all-purpose-zero-configuration tool for routers, I think. > > > > > > This seems conflicting -- a fringe case which should not came up. > > > > > > Better would be just require that the requesting router > will get a > > > delegation from all the ISP's for itself, and subnet accordingly. > > > > > > If the following does not apply, it seems to me that there > > > must be routers > > > connected to the downstreaming interfaces -- which in turn > > > could perform > > > prefix delegation directly from the ISP, the first router > acting as a > > > relay. > > > > > > Doesn't seem to be need for this.. > > > > Need not be. Simple case is Home networks, they dont afford to have > > individual routers for every ISPs. They may need multiple ISPs > > for high availablity or some other reason. In this case, there will > > be only one border router with mutiple appliances/nodes in the > > downstreaming interfaces, which may span in one or more links. > > In this case, it needs to unique IA_PD for every ISP. > > Seems a bit far-fetched, IMO, but ok.. > > > > Regardless of that, I'm not sure how the requesting router would > > > discover more of these delegating routers -- how would they be > > > connected? Which kind of infrastructure would typically > be between > > > requesting router and multiple delegating routers? > > > > I beleive there will be unique dialup connection with each ISPs. > > .. as above, I've yet to see dial-up routers deployed which > would have two > dial-out adapters and phone jacks, but ok.. > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Feb 25 14:51:18 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12706; Tue, 25 Feb 2003 14:51:17 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1PK0Ap25748; Tue, 25 Feb 2003 15:00:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1PJxNp25693 for ; Tue, 25 Feb 2003 14:59:23 -0500 Received: from palrel13.hp.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12530 for ; Tue, 25 Feb 2003 14:49:42 -0500 (EST) Received: from iconsrv5.india.hp.com (iconsrv5.india.hp.com [15.42.229.13]) by palrel13.hp.com (Postfix) with ESMTP id DE8CA1C00DC3; Tue, 25 Feb 2003 11:53:33 -0800 (PST) Received: from nt23056 (nt23056.india.hp.com [15.42.230.56]) by iconsrv5.india.hp.com (8.9.3/8.9.3 SMKit7.02) with SMTP id BAA16759; Wed, 26 Feb 2003 01:22:51 +0530 (IST) Reply-To: From: "Vijayabhaskar A K" To: "'Pekka Savola'" , "'Ralph Droms'" Cc: , Subject: RE: [dhcwg] Re: WG last call on draft-ietf-dhc-dhcpv6-opt-prefix-delegation-02.txt Date: Wed, 26 Feb 2003 01:22:07 +0530 Message-ID: <002101c2dd07$6128d250$38e62a0f@nt23056> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Importance: Normal Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > -----Original Message----- > From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org]On Behalf Of > Pekka Savola > Sent: Tuesday, February 25, 2003 12:19 PM > To: Ralph Droms > Cc: dhcwg@ietf.org; ipng@sunroof.eng.sun.com > Subject: Re: [dhcwg] Re: WG last call on > draft-ietf-dhc-dhcpv6-opt-prefix-delegation-02.txt > > > Similar discussion has already been had, so I'll try to keep > it at the > minimum. > > On Mon, 24 Feb 2003, Ralph Droms wrote: > > At 10:57 PM 2/22/2003 +0200, Pekka Savola wrote: > > >On Tue, 11 Feb 2003, Ralph Droms wrote: > > > > draft-ietf-dhc-dhcpv6-opt-prefix-delegation-02.txt > describes new DHCPv6 > > > > options and a mechanism through which a "delegating > router" (e.g., an ISP > > > > aggregation device) can assign and delegate one or more > prefixes to a > > > > "requesting router" (e.g., CPE). This draft is available as > > > > > > > > http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-opt- > prefix-delegation-02.txt > > > > > >A few comments. > > > > > >Bigger issues -- I'm sorry for bringing them up so late > (relatively), but > > >I haven't really thought/read about the big picture, before. > > > > > >1) I fail to see why to add T1 and T2 in IA_PD. They seem to be > > >mostly redundant -- the requesting router should just take > the minimum of > > >lifetimes of the prefixes, calculate it in the same > fashion, that's it. > > >Of course, there is an assumption (which doesn't seem to > be properly > > >addressed!) that the requesting router is free to refresh > the delegation > > >when it feels right, even every hour, day, month etc. > without regard to > > >the lifetimes -- indeed, I think *NO* implementation would > just wait until > > >the last minute to refresh them. > > > > > >Is there something I'm missing? > > > > The spec allows for flexibility in deployment scenarios by > > allowing the ISP (through the delegating router) to control > > the behavior of the requesting router, or by leaving the > > behavior under the control of the requesting router > > by setting T1 and T2 to 0 (see section 8 of the draft). > > Yes, I noticed they can be zero -- all I'm questioning is the > usability of > this flexibility. I fail to see why such flexibility is useful. The > requesting router can be as flexible as it wants -- and > refresh bindings > when it deems it necessary even without guidance. On reading your previous mail, i thought you have agreed with T1 and T2 :-) Probably, the routers which are "wise" enough to rely up of prefixes provided by the DHCPv6 server and "dumb" enough to trust the time values provided by it, may need this ;-) Perhaps, these T1 and T2 values exist from DHCPv4 architecture itself and worked successfully. If the requesting routers doesn't want to trust the time values, they can just ignore the T1 and T2 values and refresh the leases whenever it wishes. > > > >2) Multiple IA_PD looks unnecessarily complex. Are there any valid > > >reasons why it wouldn't be just enough to have only one IA_PD per > > >requesting router? (The option to and subsequent complexity of) > > >generating one for each interface seems like a completely > unnecessary > > >feature to me -- it's the router which should be doing > prefix delegation > > >to it's downstream interfaces! > > > > > >The only feature I can quickly think of which could profit > from this is > > >kind of "shared routers" where the connected interfaces > are separate > > >administrative entities with differently configured > properties at the ISP. > > >This seems questionable to me, a case for manual configuration or > > >"advanced prefix delegation" to me. > > > > > >So, I think the possibility to do prefix delegation in > more complex ways > > >than really necessary should be seriously considered. > Keep it Simple, > > >Stupid would be a good rule. > > > > There is no requirement that the delegating router supply more than > > one IA_PD to the requesting router, and limiting the delegation to > > only one IA_PD seems overly restrictive. For example, a delegating > > router might send one IA_PD for each ISP used by a customer site. > > I don't see it overly restrictive myself: as an operator and > end-user, if > someone connects to two ISP's, it's (almost, at least) always > done either > from two separate routers (no use doing it from one, really), or in a > serial fashion (terminate one, establish the other -- like dialup). Simultaneous connection is also needed in some cases, as i told earlier, like, high availablity > > > It is not the intention of the draft that the requesting router > > receive one IA_PD for each of its downstream interfaces. If that > > is your understanding of the draft, then we need to clarify > > the text. In section 11.1, the draft specifies that the > > requesting router assigns subnets from the delegated prefixes > > to each of its downstream interfaces. > > I understood well that the particular behaviour is only > optional, but the > problem seems to be that the "main behaviour" is described quickly > (indeed, it's rather simple) and then the spec goes on at > great length > describing the fringe cases. This makes an unwary reader > think the fringe > cases are actually more than just fringe cases. > > At least, there should be some clearer separation between the two and > possibly some guidance when (for example) not to use special > mechanisms. > > > >3) One item that may also need some consideration is the > option to let the > > >requesting router give its preference to some values > (prefix length, > > >lifetimes, IAprefix-options contents (maybe?), the > prefixes). I'm not > > >sure of the usefulness of these, really. In the real > world, I think ISP's > > >set them, either to some values communicated off-band, or > otherwise. The > > >complexity required (policy, policy,...) when the > delegating router must > > >decide whether it can agree to the requested values seems > like a big hit. > > >I'm not really sure whether it's worth it, even though it > may offer some > > >flexibility for some corner cases. The only commonly used > one I could > > >think of would be whether the customer wants _single_ /64 > (for the only > > >one subnet!) or whole /48 -- seems like a heavy baggage for that. > > > > The cost of allowing the requesting router to express its > preferences > > isn't all that great - a simple delegating router can simply ignore > > the requesting router's preferences... > > Certainly. I see this as a potential problem from two directions: > > 1) delegating router handling untrusted input values, creating > delegations based on them, and > > 2) the requesting router requesting something that > architectually differs > *a lot* from what's given (example: /64's directly for its > interfaces, and > one /48 delegated). The same problem will occur, when the requesting router is expecting the /48 and the server ignoring its preference and just gives it /64. The solution would be, 1) when a site registers with ISP, preconfigure the topology of the site in the dhcpv6 server. Thus, it can provide the requesting router with necessary prefixes. 2) If the site topology is not known, configure dhcpv6 server with some dynamic pool which always provide a single /64 prefix for the IA_PD. Let the requesting router send as many as IA_PD it wants. But, here the concept of subnetting dies. If there is no preconfiguration, then the server wont be able to provide the preferred prefix of the requesting routers. This problem remains unsolved. Basically, the site which is connecting to ISP is authenticated, moreover, they pay for whatever service they use, i dont see that any harm in taking the preference from the requesting router and assign the prefix accordingly. > Then what? Can the requesting router > handle this > kind of situation? The problem is that entering preferences > *in-band* > (instead of out-of-band, as usual) seems problematic, as it creates > difficult situations at both ends in the cases the > preferences are not met > (and policy decisions even if met). > > At the very least, one should clarify something along the > lines of "In any > case, the requesting router MUST NOT depend on any of its > preferences to > be honored" if this feature is really necessary. I pay for my using the services provided by ISPs, why shouldn't my preferences be honoured? > > > > > option-code: OPTION_IA_PD (TBD) > > > > > > option-length: 12 + length of IA_PD-options field. > > > > > >==> is it necessary to say how the option-code is > stored/transported > > >(signed/unsigned) ? I guess this is clear enough? > > > > The format of the option code is (should be?) specified in the > > DHCPv6 spec. > > Ok -- it's just that AFAICS, I don't see that a connection > has been made > between the two (even if they use the same name). > > > > The requesting router MUST ignore any Advertise message > that includes > > > a Status Code option containing the value NoPrefixAvail, > > > > > >==> where is the defintion of NoPrefixAvail or other codes? > > > > Needs a pointer to the DHCPv6 spec? > > At the minimum. > > > > message for the user, a Server Identifier option with > the delegating > > > router's DUID and a Client Identifier option with the > requesting > > > router's DUID. > > > > > >==> DUID used for the first time (inherited from DHCPv6 > spec I think), > > >spell it out? > > > > Needs a pointer to the DHCPv6 spec? > > Yes please, and spell out the abbreviation in the text (no > need to put it > up in terminology IMO). > > > > When a requesting router subnets a delegated prefix, > it must assign > > > additional bits to the prefix to generate unique, > longer prefixes. > > > For example, if the requesting router in Figure 1 were > delegated > > > 3FFE:FFFF:0::/48, it might generate 3FFE:FFFF:0:1::/64 and > > > 3FFE:FFFF:0:2::/64 for assignment to the two links in > the subscriber > > > network. > > > > > >==> I'm not sure if the first sentence is entirely > accurate. One could > > >use prefix delegation to get multiple /64's directly from > your ISP, then > > >extra bits wouldn't be needed at all. > > > > But that wouldn't be "subnetting", I don't think - just > reassignment? > > Ah, got me there :-). The problem with the language seems to > be that even > though it says "when ... subnets", there are no other "whens" so this > paragraph is taken to imply all of it (especially since the > main form of > prefix delegation always includes subnetting, as noted earlier in the > draft). > > > >14. Security Considerations > > > > > >==> personally I'm rather worried about the requestor > being able to give > > >"guidance" to the delegator what on what it wants. > Unreliable input could > > >lead to bad results in an implementation which hasn't been > done carefully > > >(requesting link/site-local prefixes which don't exist, > effect of bogus > > >prefixlengths etc.etc.). [more of this was above] > > > > Paranoid delegating routers can simply ignore the guidance... > > Yep, put that in there :-) > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Feb 25 15:27:17 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13941; Tue, 25 Feb 2003 15:27:17 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1PKaMp28140; Tue, 25 Feb 2003 15:36:22 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1PKYup28085 for ; Tue, 25 Feb 2003 15:34:56 -0500 Received: from rtp-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13869 for ; Tue, 25 Feb 2003 15:25:15 -0500 (EST) Received: from goblet.cisco.com (IDENT:mirapoint@goblet.cisco.com [161.44.168.80]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h1PKT7JR011558; Tue, 25 Feb 2003 15:29:07 -0500 (EST) Received: from KKINNEAR-W2K.cisco.com (che-vpn-cluster-1-40.cisco.com [10.86.240.40]) by goblet.cisco.com (Mirapoint) with ESMTP id ACR49037; Tue, 25 Feb 2003 15:29:05 -0500 (EST) Message-Id: <4.3.2.7.2.20030225152521.0244f068@goblet.cisco.com> X-Sender: kkinnear@goblet.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 25 Feb 2003 15:29:09 -0500 To: Ralph Droms , Thomas Narten From: Kim Kinnear Subject: Re: [dhcwg] lease query question Cc: dhcwg@ietf.org, kkinnear@cisco.com In-Reply-To: <4.3.2.7.2.20030219122513.03d54ee8@funnel.cisco.com> References: <4.3.2.7.2.20030210170642.025d8f08@goblet.cisco.com> <200302041628.h14GSfc26441@rotala.raleigh.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Ralph, Thanks! That's a great problem statement. Thomas, Would replacing the current problem statement with this one suggested by Ralph be sufficient to meet (enough of) your concerns to allow the draft to proceed? Is there something instead of or in addition to that change that you would suggest we do in order to move forward here? Thanks -- Kim At 12:51 PM 2/19/2003, Ralph Droms wrote: >Kim, > >Based on the discussion and current draft of the spec, it looks to me like the protocol has evolved beyond simply reporting lease information into a mechanism for populating an access concentrator with device identity and location information. It's more than a mere formality to ensure that the problem statement and design motivation match the protocol itself - those readers who have not been part of the evolution need to be able match up the problem statement and the protocol spec to effectively evaluate the correctness and applicability of the protocol. > >For example, I think the following problem statement more accurately reflects the current protocol and the problem that is causing its evolution: > > Router-type devices which want to enforce some level of access > control over which IP addresses are allowed on their links > need to maintain information concerning IP<->MAC/client-id > mappings. One way in which these devices can obtain > information about IP<->MAC/client-id bindings is through "DHCP > gleaning", in which the device extracts useful information > from DHCP messages exchanged between hosts and DHCP servers. > > However, these devices don't typically have stable storage > sufficient to keep this information over reloads. There may > be additional information that is useful to the device that > cannot be obtained through DHCP gleaning. The leasequery > request message described in this document allows a device to > obtain information about IP<->MAC/client-id bindings from a > DHCP server. This information may include currently active > bindings, bindings involving previously assigned addresses for > which the lease on the address has expired and static bindings > for devices that are otherwise configured and not using DHCP > for address assignment. > >- Ralph > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Feb 25 18:56:34 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22790; Tue, 25 Feb 2003 18:56:34 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1Q05gp09758; Tue, 25 Feb 2003 19:05:42 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1Q02Bp09681 for ; Tue, 25 Feb 2003 19:02:11 -0500 Received: from beta.jnpr.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22731 for ; Tue, 25 Feb 2003 18:52:25 -0500 (EST) Received: from pi-smtp.jnpr.net ([10.10.2.36]) by beta.jnpr.net with Microsoft SMTPSVC(5.0.2195.5329); Tue, 25 Feb 2003 15:56:20 -0800 Received: from OPHELIA.jnpr.net ([10.10.2.95]) by pi-smtp.jnpr.net with Microsoft SMTPSVC(5.0.2195.5329); Tue, 25 Feb 2003 18:55:56 -0500 Received: from rhussongpc.dhcp.west.unispherenetworks.com ([10.10.121.9]) by OPHELIA.jnpr.net with Microsoft SMTPSVC(5.0.2195.5329); Tue, 25 Feb 2003 18:55:56 -0500 From: Richard Hussong To: dhcwg@ietf.org Date: Tue, 25 Feb 2003 18:56:07 -0500 Organization: Juniper Networks, Inc. Message-ID: <6qvn5vgpq188v9lq0ihpkgkrvkvjebbg6u@4ax.com> X-Mailer: Forte Agent 1.92/32.572 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-OriginalArrivalTime: 25 Feb 2003 23:55:56.0121 (UTC) FILETIME=[6FF04490:01C2DD29] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h1Q02Bp09682 Subject: [dhcwg] is Solicit required in DHCPv6? Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Maybe I'm just missing something, but I don't see anything in dhcpv6-28 that says that the first message sent from a client to a server must be a Solicit. Assuming that a client happens to know the server ID of a DHCPv6 server, is it legal for the first message sent to the server to be a Request (it must be multicast, of course)? How about an Information-request? If so, is it legal for the Information-request message to be unicast if the client also happens to know an address for the server? - Richard Hussong _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Feb 25 20:56:52 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA25014; Tue, 25 Feb 2003 20:56:52 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1Q25np16359; Tue, 25 Feb 2003 21:05:49 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1Q22pp16254 for ; Tue, 25 Feb 2003 21:02:51 -0500 Received: from sj-msg-core-4.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24860 for ; Tue, 25 Feb 2003 20:53:04 -0500 (EST) Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by sj-msg-core-4.cisco.com (8.12.2/8.12.6) with ESMTP id h1Q1uu6N016139; Tue, 25 Feb 2003 17:56:57 -0800 (PST) Received: (from otroan@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id BAA18783; Wed, 26 Feb 2003 01:56:56 GMT X-Authentication-Warning: mrwint.cisco.com: otroan set sender to ot@cisco.com using -f To: Pekka Savola Cc: Ralph Droms , dhcwg@ietf.org, From: Ole Troan Date: Wed, 26 Feb 2003 01:56:56 +0000 In-Reply-To: (Pekka Savola's message of "Sat, 22 Feb 2003 22:57:10 +0200 (EET)") Message-ID: <7t5vfz7yfbr.fsf@mrwint.cisco.com> User-Agent: Gnus/5.090011 (Oort Gnus v0.11) Emacs/21.2.95 (sparc-sun-solaris2.8) References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [dhcwg] Re: WG last call on draft-ietf-dhc-dhcpv6-opt-prefix-delegation-02.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Pekka, > 2) Multiple IA_PD looks unnecessarily complex. Are there any valid > reasons why it wouldn't be just enough to have only one IA_PD per > requesting router? (The option to and subsequent complexity of) > generating one for each interface seems like a completely unnecessary > feature to me -- it's the router which should be doing prefix delegation > to it's downstream interfaces! let me pick this one up from the start. the reasons for allowing multiple IA_PDs are: - consistency with address assignment as you can use multiple IA_NAs - future-proofing. in the ISP/user scenario I do see little need for multiple IA_PDs. if PD is used within an administrative domain assigning prefixes to downstream interfaces may make more sense it does add some complexity, and I think we've made it pretty clear in the draft that the typical usage will be to use one IA_PD. we just didn't want to close the door on possible future uses of the protocol. /ot _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Feb 25 21:56:23 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25904; Tue, 25 Feb 2003 21:56:23 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1Q35Qp19639; Tue, 25 Feb 2003 22:05:26 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1PJfnp24842 for ; Tue, 25 Feb 2003 14:41:49 -0500 Received: from netcore.fi (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11832 for ; Tue, 25 Feb 2003 14:32:09 -0500 (EST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h1PJPuH30388; Tue, 25 Feb 2003 21:25:56 +0200 Date: Tue, 25 Feb 2003 21:25:55 +0200 (EET) From: Pekka Savola To: Vijayabhaskar A K cc: "'Ralph Droms'" , , Subject: RE: [dhcwg] Re: WG last call on draft-ietf-dhc-dhcpv6-opt-prefix-delegation-02.txt In-Reply-To: <001e01c2dd00$c5e3bbd0$38e62a0f@nt23056> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , On Wed, 26 Feb 2003, Vijayabhaskar A K wrote: > > > Ofcourse, the requesting router can generate these values itself. > > > With DHCPv6 server sending T1 and T2 values, the requesting > > > router dont need to recalculate the values again and again.. > > > Trust the DHCPv6 server, the values provided by it makes the > > > requesting router to refresh its bindings well before the expiry.. > > > > Well, typically the conventional wisdom is *not* to trust any > > external > > parties to any extent greater than necessary :-) > > If you are able to trust the prefixes given by DHCPv6, then there will be > no harm in trusting the time values provided by it :-) It's not about that kind of trust -- rather "I trust that the times provided to me by the operator are the best possible choices, and they have in fact provided them" -- I'd imagine you trust your own DHCPv6 implementation and configuration more than your ISP's. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Feb 25 21:58:47 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25964; Tue, 25 Feb 2003 21:58:47 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1Q37pp20467; Tue, 25 Feb 2003 22:07:52 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1PLarp32230 for ; Tue, 25 Feb 2003 16:36:53 -0500 Received: from netcore.fi (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18221 for ; Tue, 25 Feb 2003 16:27:09 -0500 (EST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h1PLMLs31053; Tue, 25 Feb 2003 23:22:21 +0200 Date: Tue, 25 Feb 2003 23:22:20 +0200 (EET) From: Pekka Savola To: Vijayabhaskar A K cc: "'Ralph Droms'" , , Subject: RE: [dhcwg] Re: WG last call on draft-ietf-dhc-dhcpv6-opt-prefix-delegation-02.txt In-Reply-To: <002101c2dd07$6128d250$38e62a0f@nt23056> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , On Wed, 26 Feb 2003, Vijayabhaskar A K wrote: > > > The spec allows for flexibility in deployment scenarios by > > > allowing the ISP (through the delegating router) to control > > > the behavior of the requesting router, or by leaving the > > > behavior under the control of the requesting router > > > by setting T1 and T2 to 0 (see section 8 of the draft). > > > > Yes, I noticed they can be zero -- all I'm questioning is the > > usability of > > this flexibility. I fail to see why such flexibility is useful. The > > requesting router can be as flexible as it wants -- and > > refresh bindings > > when it deems it necessary even without guidance. > > On reading your previous mail, i thought you have agreed with T1 and T2 :-) Well, if it's DHCPv6 functionality, it's ok to keep some of those intact even if misguided.. :-) > Probably, the routers which are "wise" enough to rely up of prefixes > provided by the DHCPv6 server and "dumb" enough to trust the time > values provided by it, may need this ;-) Perhaps, these T1 and T2 values > exist from > DHCPv4 architecture itself and worked successfully. Well, the routers MUST have this code *anyway*, as they cannot be sure T1/T2 will always be provided, so I really see little use.. > > I don't see it overly restrictive myself: as an operator and end-user, > > if someone connects to two ISP's, it's (almost, at least) always done > > either from two separate routers (no use doing it from one, really), > > or in a serial fashion (terminate one, establish the other -- like > > dialup). > > Simultaneous connection is also needed in some cases, as i told > earlier, like, high availablity High availability to two ISP's from one router is a joke. > > Certainly. I see this as a potential problem from two directions: > > > > 1) delegating router handling untrusted input values, creating > > delegations based on them, and > > > > 2) the requesting router requesting something that > > architectually differs > > *a lot* from what's given (example: /64's directly for its > > interfaces, and > > one /48 delegated). > > The same problem will occur, when the requesting router is expecting > the /48 and the server ignoring its preference and just gives > it /64. Sure. (Or the same for different changes in prefix lengths.) > The solution would be, > 1) when a site registers with ISP, preconfigure the topology of the > site in the dhcpv6 server. Thus, it can provide the requesting > router with necessary prefixes. I think it is natural to be able to expect that the ISP configures this kind of stuff (one /64, multiple /64, /48 -- that's all they need!) out-of-band. As currently. I don't think there's any reason to expect otherwise. > 2) If the site topology is not known, configure dhcpv6 server > with some dynamic pool which always provide a single /64 prefix > for the IA_PD. Let the requesting router send as many as IA_PD > it wants. But, here the concept of subnetting dies. Very discourageable, IMO. > Basically, the site which is connecting to ISP is authenticated, > moreover, they pay for whatever service they use, i dont see > that any harm in taking the preference from the requesting > router and assign the prefix accordingly. You fail to understand the relationship between the ISP and the user. Whether they use /64, /48 or whatever is, and will typically be, pre-agreed when people sign up for the service. Communicated out-of-band. I don't think that typically the user is able to affect that decision (at prefix delegation time) at all. Of course, ISP's could change their models, but don't count on it.. > > Then what? Can the requesting router > > handle this > > kind of situation? The problem is that entering preferences > > *in-band* > > (instead of out-of-band, as usual) seems problematic, as it creates > > difficult situations at both ends in the cases the > > preferences are not met > > (and policy decisions even if met). > > > > At the very least, one should clarify something along the > > lines of "In any > > case, the requesting router MUST NOT depend on any of its > > preferences to > > be honored" if this feature is really necessary. > > I pay for my using the services provided by ISPs, why shouldn't > my preferences be honoured? ISP's will love you for spending 50$/mo for the premium service instead of 30$/mo, so -- maybe they'll let you say the preference. For the rest, it won't matter and it's configured out-of-band. Most agreements with ISP's are very draconian. The problems like these are not solved with specifications. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Feb 25 22:01:02 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26054; Tue, 25 Feb 2003 22:01:02 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1Q3A9p20558; Tue, 25 Feb 2003 22:10:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1PMm4p05670 for ; Tue, 25 Feb 2003 17:48:04 -0500 Received: from pianosa.catch22.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20416 for ; Tue, 25 Feb 2003 17:38:20 -0500 (EST) Received: by pianosa.catch22.org (Postfix, from userid 1000) id 8225660; Tue, 25 Feb 2003 14:42:13 -0800 (PST) Date: Tue, 25 Feb 2003 16:42:13 -0600 From: David Terrell To: dhcwg@ietf.org, ipng@sunroof.eng.sun.com, namedroppers@ops.ietf.org Subject: Re: [dhcwg] Re: WG last call on draft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt Message-ID: <20030225224213.GA19540@pianosa.catch22.org> Reply-To: David Terrell References: <1045910906.26677.29.camel@devil> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1045910906.26677.29.camel@devil> User-Agent: Mutt/1.4i X-vi: Version 1.79 (10/23/96) The CSRG, University of California, Berkeley. X-Nethack: You feel like someone is making a pointless Nethack reference.--More-- X-Uptime: 4:40PM up 9 days, 20:07, 42 users, load averages: 0.90, 0.72, 0.72 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , On Sat, Feb 22, 2003 at 12:48:27PM +0200, Mika Liljeberg wrote: > Is that necessary? IPv4 addresses can be returned in IPv4 Mapped format > if necessary. Just add some text explaining this. With our hybrid > IPv4/IPv6 stack implementation this would work out of the box. Did I miss some announcement that mapped addresses were suddenly allowed to be present on the wire? They were supposed to be only used in the socket API. Camels... tents.... -- David Terrell | "War is peace, Prime Minister, Nebcorp | freedom is slavery, dbt@meat.net | ignorance is strength http://wwn.nebcorp.com/ | Dishes are clean." - Chris Fester _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Feb 25 22:22:15 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26416; Tue, 25 Feb 2003 22:22:14 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1Q3VIp21442; Tue, 25 Feb 2003 22:31:18 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1Q3SJp21334 for ; Tue, 25 Feb 2003 22:28:19 -0500 Received: from ariel.nishansystems.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26361 for ; Tue, 25 Feb 2003 22:18:29 -0500 (EST) Received: by ariel.nishansystems.com with Internet Mail Service (5.5.2653.19) id ; Tue, 25 Feb 2003 19:17:40 -0800 Message-ID: From: Charles Monia To: "Ips (E-mail)" , "DHCP (E-mail)" Date: Tue, 25 Feb 2003 19:17:30 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Subject: [dhcwg] [iSNS]:draft-ietf-dhc-isnsoption-05.txt submitted to archive Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Hi: draft-ietf-dhc-isnsoption-05.txt incorporates the suggested editorial changes related to identifying the IPv4 version of DHCP along with other minor editorial changes. Until it is available from the IETF archive, a PDF copy may be obtained from: http://www.nishansystems.com/ietf/draft-ietf-dhc-isnsoption-05.pdf -- Charles ----------------------------------------- Charles Monia Senior Technology Consultant Nishan Systems email: cmonia@nishansystems.com voice: (408) 519-3986 fax: (408) 435-8385 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Feb 25 23:00:40 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA27322; Tue, 25 Feb 2003 23:00:40 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1Q49hp26268; Tue, 25 Feb 2003 23:09:43 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1Q46sp25355 for ; Tue, 25 Feb 2003 23:06:54 -0500 Received: from imr1.ericy.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA27248 for ; Tue, 25 Feb 2003 22:57:03 -0500 (EST) Received: from mr5.exu.ericsson.se (mr5u3.ericy.com [208.237.135.124]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id h1Q40wd07660; Tue, 25 Feb 2003 22:00:58 -0600 (CST) Received: from eamrcnt761.exu.ericsson.se (eamrcnt761.exu.ericsson.se [138.85.133.39]) by mr5.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id h1Q40wk25833; Tue, 25 Feb 2003 22:00:58 -0600 (CST) Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2656.59) id ; Tue, 25 Feb 2003 22:00:57 -0600 Message-ID: From: "Bernie Volz (EUD)" To: "'Richard Hussong'" , dhcwg@ietf.org Subject: RE: [dhcwg] is Solicit required in DHCPv6? Date: Tue, 25 Feb 2003 21:59:17 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2DD4B.6EDC9712" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2DD4B.6EDC9712 Content-Type: text/plain; charset="iso-8859-1" Define what you mean by "first message"? When a client starts (restarts), if it has existing addresses that it obtained from a DHCP server (and the lifetimes had not expired while it was down), it would first send a CONFIRM message to determine if these addresses are still valid (since the client may have been moved to a new network while it was down). If no "NotOnLink" status is returned, the client can continue to use the addresses and may, at an appropriate time, send Renew or other messages. In this case, if a client needed additional addresses (such as temporary ones), there is no reason why it could not just send a Request to the server it used to get earlier addresses. If you're trying to simplify the message exchange, consider the Solicit w/Rapid Commit. If you're to develop an access concentrator (such as for dial-up, GGSN, etc) and its acting as a proxy, it would be dangerous to assume that Solicit can be skipped for all but the first client especially if you're not preconfigured to contact specific servers (or relays). The reason is that things like load balancing (see draft-ietf-dhc-dhcpv6-loadb-02.txt) could get you in trouble as you could be sending requests to the wrong server (and therefore not get service or very delayed service). - Bernie -----Original Message----- From: Richard Hussong [mailto:rhussong@juniper.net] Sent: Tuesday, February 25, 2003 6:56 PM To: dhcwg@ietf.org Subject: [dhcwg] is Solicit required in DHCPv6? Maybe I'm just missing something, but I don't see anything in dhcpv6-28 that says that the first message sent from a client to a server must be a Solicit. Assuming that a client happens to know the server ID of a DHCPv6 server, is it legal for the first message sent to the server to be a Request (it must be multicast, of course)? How about an Information-request? If so, is it legal for the Information-request message to be unicast if the client also happens to know an address for the server? - Richard Hussong _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg ------_=_NextPart_001_01C2DD4B.6EDC9712 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] is Solicit required in DHCPv6?

Define what you mean by "first = message"?

When a client starts (restarts), if it has existing = addresses that it
obtained from a DHCP server (and the lifetimes had = not expired while
it was down), it would first send a CONFIRM message = to
determine if these addresses are still valid (since = the client may
have been moved to a new network while it was down). = If no "NotOnLink"
status is returned, the client can continue to use = the addresses and
may, at an appropriate time, send Renew or other = messages.

In this case, if a client needed additional addresses = (such as
temporary ones), there is no reason why it could not = just send a
Request to the server it used to get earlier = addresses.

If you're trying to simplify the message exchange, = consider the
Solicit w/Rapid Commit.

If you're to develop an access concentrator (such as = for dial-up,
GGSN, etc) and its acting as a proxy, it would be = dangerous to
assume that Solicit can be skipped for all but the = first client
especially if you're not preconfigured to contact = specific servers
(or relays). The reason is that things like load = balancing (see
draft-ietf-dhc-dhcpv6-loadb-02.txt) could get you in = trouble as
you could be sending requests to the wrong server = (and therefore
not get service or very delayed service).

- Bernie

-----Original Message-----
From: Richard Hussong [mailto:rhussong@juniper.net]
Sent: Tuesday, February 25, 2003 6:56 PM
To: dhcwg@ietf.org
Subject: [dhcwg] is Solicit required in = DHCPv6?


Maybe I'm just missing something, but I don't see = anything in dhcpv6-28
that says that the first message sent from a client = to a server must be
a Solicit.  Assuming that a client happens to = know the server ID of a
DHCPv6 server, is it legal for the first message = sent to the server to
be a Request (it must be multicast, of = course)?

How about an Information-request?  If so, is it = legal for the
Information-request message to be unicast if the = client also happens to
know an address for the server?

- Richard Hussong

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg

------_=_NextPart_001_01C2DD4B.6EDC9712-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Feb 26 09:00:17 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04920; Wed, 26 Feb 2003 09:00:17 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QE9dp10753; Wed, 26 Feb 2003 09:09:39 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QE8Ip10677 for ; Wed, 26 Feb 2003 09:08:18 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04384; Wed, 26 Feb 2003 08:58:16 -0500 (EST) Message-Id: <200302261358.IAA04384@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: dhcwg@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 26 Feb 2003 08:58:16 -0500 Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-subnet-alloc-00.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Title : Subnet Allocation using DHCP Author(s) : R. Johnson et al. Filename : draft-ietf-dhc-subnet-alloc-00.txt Pages : 24 Date : 2003-2-25 This document defines a new DHCP option which is passed between the DHCP Client to the DHCP Server to request dynamic allocation of a subnet, give specifications of subnet(s) allocated, and report usage statistics. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-subnet-alloc-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-subnet-alloc-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-subnet-alloc-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: <2003-2-25155731.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-subnet-alloc-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-subnet-alloc-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-2-25155731.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Feb 26 09:49:00 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08096; Wed, 26 Feb 2003 09:48:59 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QEwHp14635; Wed, 26 Feb 2003 09:58:18 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1Q6e4p02674 for ; Wed, 26 Feb 2003 01:40:04 -0500 Received: from netcore.fi (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA00320 for ; Wed, 26 Feb 2003 01:30:12 -0500 (EST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h1Q6Xt201278; Wed, 26 Feb 2003 08:33:55 +0200 Date: Wed, 26 Feb 2003 08:33:55 +0200 (EET) From: Pekka Savola To: Ole Troan cc: Ralph Droms , , In-Reply-To: <7t5vfz7yfbr.fsf@mrwint.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [dhcwg] Re: WG last call on draft-ietf-dhc-dhcpv6-opt-prefix-delegation-02.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , On Wed, 26 Feb 2003, Ole Troan wrote: > > 2) Multiple IA_PD looks unnecessarily complex. Are there any valid > > reasons why it wouldn't be just enough to have only one IA_PD per > > requesting router? (The option to and subsequent complexity of) > > generating one for each interface seems like a completely unnecessary > > feature to me -- it's the router which should be doing prefix delegation > > to it's downstream interfaces! > > let me pick this one up from the start. > the reasons for allowing multiple IA_PDs are: > > - consistency with address assignment as you can use multiple IA_NAs > - future-proofing. in the ISP/user scenario I do see little need for > multiple IA_PDs. if PD is used within an administrative domain > assigning prefixes to downstream interfaces may make more sense My take on this is is that "we don't need that yet, so why add it yet"; leaving the "base prefix delegation spec" extendable (e.g. define multiple IA_PD's in a later document) would be just fine. > it does add some complexity, and I think we've made it pretty clear in > the draft that the typical usage will be to use one IA_PD. we just > didn't want to close the door on possible future uses of the protocol. IMO, it wasn't as clear as that. I can live with this, but I can't help wondering why the base spec has to cover even all the theoretical cases. I'd much rather see a very simple basic version of prefix delegation which can be used to get started. There's no way we could anticipate what will be needed in 3-5 years and we could further define the extensions when they're needed. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Feb 26 10:22:17 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10746; Wed, 26 Feb 2003 10:22:17 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QFV4p17408; Wed, 26 Feb 2003 10:31:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QFS7p17213 for ; Wed, 26 Feb 2003 10:28:07 -0500 Received: from imr1.ericy.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10624 for ; Wed, 26 Feb 2003 10:18:02 -0500 (EST) Received: from mr5.exu.ericsson.se (mr5u3.ericy.com [208.237.135.124]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id h1QFLud13707 for ; Wed, 26 Feb 2003 09:21:56 -0600 (CST) Received: from eamrcnt760.exu.ericsson.se (eamrcnt760.exu.ericsson.se [138.85.133.38]) by mr5.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id h1QFLuA15078 for ; Wed, 26 Feb 2003 09:21:56 -0600 (CST) Received: by eamrcnt760.exu.ericsson.se with Internet Mail Service (5.5.2656.59) id ; Wed, 26 Feb 2003 09:21:56 -0600 Message-ID: From: "Bernie Volz (EUD)" To: dhcwg@ietf.org Date: Wed, 26 Feb 2003 09:20:16 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C2DDAA.38AD1EE6" Subject: [dhcwg] FW: I-D ACTION:draft-volz-dhc-extended-optioncodes-00.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C2DDAA.38AD1EE6 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2DDAA.38AD1EE6" ------_=_NextPart_001_01C2DDAA.38AD1EE6 Content-Type: text/plain; charset="ISO-8859-1" I'd like to bring this draft to the attention of the DHC WG. It is work that I'd will request to be considered a WG item. Comments on the draft or it becoming a WG item (pro or con) are welcome. - Bernie Volz -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Sent: Wednesday, February 26, 2003 8:59 AM Subject: I-D ACTION:draft-volz-dhc-extended-optioncodes-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Extending DHCP Options Codes Author(s) : B. Volz et al. Filename : draft-volz-dhc-extended-optioncodes-00.txt Pages : 7 Date : 2003-2-25 RFC 2132 defines the DHCP for IPv4 options 1 to 127 as the DHCP public option space which is managed by IANA as documented in RFC 2939. As this public option space has few unassigned options at this time, it is prudent to define a mechanism to extend this option space before it is too late. This Internet-Draft proposes two means to extend this option space. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-volz-dhc-extended-optioncodes-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-volz-dhc-extended-optioncodes-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-volz-dhc-extended-optioncodes-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_001_01C2DDAA.38AD1EE6 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable FW: I-D = ACTION:draft-volz-dhc-extended-optioncodes-00.txt

I'd like to bring this draft to the attention of the = DHC WG. It is work that
I'd will request to be considered a WG item.

Comments on the draft or it becoming a WG item (pro = or con) are welcome.

- Bernie Volz

-----Original Message-----
From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org= ]
Sent: Wednesday, February 26, 2003 8:59 AM
Subject: I-D = ACTION:draft-volz-dhc-extended-optioncodes-00.txt


A New Internet-Draft is available from the on-line = Internet-Drafts directories.


        Title           : = Extending DHCP Options Codes
        Author(s)       : B. Volz et = al.
        Filename        : = draft-volz-dhc-extended-optioncodes-00.txt
        Pages           : = 7
        Date    =         : 2003-2-25
       =20
RFC 2132 defines the DHCP for IPv4 options 1 to 127 = as the DHCP
public option space which is managed by IANA as = documented in RFC
2939. As this public option space has few unassigned = options at this
time, it is prudent to define a mechanism to extend = this option space
before it is too late. This Internet-Draft proposes = two means to
extend this option space.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-volz-dhc-ext= ended-optioncodes-00.txt

To remove yourself from the IETF Announcement list, = send a message to
ietf-announce-request with the word unsubscribe in = the body of the message.

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-volz-dhc-extended-optioncodes-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-volz-dhc-extended-optioncodes-00.txt".
       =20
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.
        =        =20
        =        =20
Below is the data which will enable a MIME compliant = mail reader
implementation to automatically retrieve the ASCII = version of the
Internet-Draft.

  ------_=_NextPart_001_01C2DDAA.38AD1EE6-- ------_=_NextPart_000_01C2DDAA.38AD1EE6 Content-Type: message/rfc822 To: Subject: Date: Wed, 26 Feb 2003 09:21:56 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/mixed; boundary="----_=_NextPart_002_01C2DDAA.38AD1EE6" ------_=_NextPart_002_01C2DDAA.38AD1EE6 Content-Type: multipart/alternative; boundary="----_=_NextPart_003_01C2DDAA.38AD1EE6" ------_=_NextPart_003_01C2DDAA.38AD1EE6 Content-Type: text/plain ------_=_NextPart_003_01C2DDAA.38AD1EE6 Content-Type: text/html

  ------_=_NextPart_003_01C2DDAA.38AD1EE6-- ------_=_NextPart_002_01C2DDAA.38AD1EE6 Content-Type: application/octet-stream; name="ATT44520" Content-Disposition: attachment; filename="ATT44520" Content-type: message/external-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-2-25155916.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-volz-dhc-extended-optioncodes-00.txt ------_=_NextPart_002_01C2DDAA.38AD1EE6 Content-Type: message/external-body; site="internet-drafts"; dir="draft-volz-dhc-extended-optioncodes-00.txt"; mode="ftp.ietf.org"; access-type="anon-ftp" ------_=_NextPart_002_01C2DDAA.38AD1EE6-- ------_=_NextPart_000_01C2DDAA.38AD1EE6-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Feb 26 10:38:40 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12243; Wed, 26 Feb 2003 10:38:40 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QFm8p19683; Wed, 26 Feb 2003 10:48:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QFl7p19615 for ; Wed, 26 Feb 2003 10:47:07 -0500 Received: from e32.co.us.ibm.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12111 for ; Wed, 26 Feb 2003 10:37:02 -0500 (EST) Received: from westrelay03.boulder.ibm.com (westrelay03.boulder.ibm.com [9.17.194.24]) by e32.co.us.ibm.com (8.12.7/8.12.2) with ESMTP id h1QFdcJi048628; Wed, 26 Feb 2003 10:39:38 -0500 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.27.12.14]) by westrelay03.boulder.ibm.com (8.12.3/NCO/VER6.5) with ESMTP id h1QFdfFU087932; Wed, 26 Feb 2003 08:39:41 -0700 Received: from rotala.raleigh.ibm.com (localhost.localdomain [127.0.0.1]) by rotala.raleigh.ibm.com (8.12.5/8.12.5) with ESMTP id h1QFYlem004463; Wed, 26 Feb 2003 10:34:47 -0500 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.12.5/8.12.5/Submit) with ESMTP id h1QFYkmY004458; Wed, 26 Feb 2003 10:34:47 -0500 Message-Id: <200302261534.h1QFYkmY004458@rotala.raleigh.ibm.com> To: Kim Kinnear cc: Ralph Droms , dhcwg@ietf.org Subject: Re: [dhcwg] lease query question In-Reply-To: Message from kkinnear@cisco.com of "Tue, 25 Feb 2003 15:29:09 EST." <4.3.2.7.2.20030225152521.0244f068@goblet.cisco.com> Date: Wed, 26 Feb 2003 10:34:46 -0500 From: Thomas Narten Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , > Would replacing the current problem statement with this one > suggested by Ralph be sufficient to meet (enough of) your > concerns to allow the draft to proceed? Not really. What we had originally (I had thought) was is a relatively simple problem, with a relatively simple solution, and one that didn't really change DHC in any serious way. The solution seem to have taken on feature creap, where the problem got expanded, and the solution got expanded. Sure, given any solution, one can go back and rewrite the problem statement to make it match the solution. While that is certainly necessary to make the document accurate, I have to wonder whether the problem statement actually makes sense or is well defined. > > Router-type devices which want to enforce some level of access > > control over which IP addresses are allowed on their links > > need to maintain information concerning IP<->MAC/client-id > > mappings. One way in which these devices can obtain > > information about IP<->MAC/client-id bindings is through "DHCP > > gleaning", in which the device extracts useful information > > from DHCP messages exchanged between hosts and DHCP > > servers. So far, simple. > > However, these devices don't typically have stable storage > > sufficient to keep this information over reloads. There may > > be additional information that is useful to the device that > > cannot be obtained through DHCP gleaning. The leasequery > > request message described in this document allows a device to > > obtain information about IP<->MAC/client-id bindings from a > > DHCP server. This information may include currently active > > bindings, bindings involving previously assigned addresses for > > which the lease on the address has expired and static bindings > > for devices that are otherwise configured and not using DHCP > > for address assignment. Note, that above is pretty vague and doesn't say what information the access device needs. It's hard to look at the problem statement and say "yes, I understand the boundaries of the problem" and then "and the solution seems like a good match for the problem". Popping up a level, how is it even appropriate for the DHC WG to be doing work on "access control in router type devices"? One can argue that work of this broad a scope is well out-of-scope for this WG (e.g., look at the recently approved charter). I'm far from clear that work of this scope should be done in DHC or that the problem is well enough understood to conclude that DHC lease query is the right solution or that any DHC-based solution is the right one. What about routers wanting to do access control that don't use DHC, for instance? And note, I'm not raising these issue just to be a PITA. These are questions that I expect that the IESG would ask if I brought the document forward. Thus, I need to have reasonable responses to those questions. Otherwise, I can predict the likely outcome. Thomas _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Feb 26 10:50:44 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08095; Wed, 26 Feb 2003 09:48:59 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QEwOp14693; Wed, 26 Feb 2003 09:58:24 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1Q810p18157 for ; Wed, 26 Feb 2003 03:01:00 -0500 Received: from shuttle.wide.toshiba.co.jp (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27475 for ; Wed, 26 Feb 2003 02:51:05 -0500 (EST) Received: from localhost (unknown [3ffe:501:4819:2000:200:39ff:fe10:85d7]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 6741315215; Wed, 26 Feb 2003 16:55:15 +0900 (JST) Date: Wed, 26 Feb 2003 16:55:12 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Ralph Droms Cc: dhcwg@ietf.org, ipng@sunroof.eng.sun.com Subject: Re: [dhcwg] WG last call on draft-ietf-dhc-dhcpv6-opt-prefix-delegation-02.txt In-Reply-To: <4.3.2.7.2.20030220132513.00ba9a40@funnel.cisco.com> References: <4.3.2.7.2.20030220132513.00ba9a40@funnel.cisco.com> User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.2 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 65 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , >>>>> On Mon, 24 Feb 2003 08:00:00 -0500, >>>>> Ralph Droms said: > Please review draft-ietf-dhc-dhcpv6-opt-prefix-delegation-02.txt and > reply with comments. If you recommend the document for advancement without > revision, please respond with a quick acknowledgment. No response will be > interpreted as a lack of support for advancing the document. I've finally reviewed the latest draft. As I said before, I basically support the document. However, I don't think the current revision is ready to be published. IMO, it is still incomplete and has not fully addressed open issues. Detailed comments follow: 1. Issues about the preferred and valid lifetimes were not fully addressed. I've not seen consensus on this in the dhc-wg ML. Please re-check the thread entitled "PD lifetimes" that started on Thu, 23 Jan 2003 19:18:57 +0900. 2. Section 11.1 now specifies the requesting router to use Rebind/Reply exchanges to verify an existing binding (instead of Renew/Reply exchanges). According to the very recent clarifications on the base DHCPv6 spec, however, I'm not sure if Rebind is appropriate here; the server should drop the Rebind message unless it has an explicit knowledge about the validity or invalidity of the prefix, which should not be the case (e.g.) when the upstream link flaps. 3. Section 10.2 contains the following sentence (newly added in the latest revision): If the delegating router cannot delegate any prefixes to an IA_PD in the message from the requesting router, the delegating router MUST include the IA_PD in the Reply message with no prefixes in the IA_PD and a Status Code option in the IA_PD containing status code NoPrefixAvail. I guess the "Reply" should be "Advertisement" here, because this section is talking about "Delegating Router Solicitation." I also guess the sentence was added in response to a question of mine in the ML. If so, a similar clarification should be introduced to Section 11.2 as well. Additionally, the corresponding client behaviors should also be documented. 4. The PD draft should reflect some parts of draft-ietf-dhc-dhcpv6-interop-00.txt. With a quick look, Sections 1, 2, 3, 4, 5, 6, 9, 10, and 11 should also apply to the PD draft. We may be able to omit some of them as trivial clarifications, but we should reflect some other part of them because the base DHCPv6 spec (and thus the clarifications for it) is too specific to address assignment. In some cases, implementors can use analogy of the base spec to implement the PD draft, but we should basically provide comprehensive information in the PD draft itself to ensure better interoperability. (As some people, including me, have repeatedly pointed out, the best approach would be to make the base spec generic so that each stateful method can just refer to the base spec. Since we could not make it due to the "it's too late" reason, we should be responsible to implementors for providing detailed information within the PD specification). JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Feb 26 11:04:08 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13779; Wed, 26 Feb 2003 11:04:08 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QGDRp21624; Wed, 26 Feb 2003 11:13:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QGCxp21605 for ; Wed, 26 Feb 2003 11:12:59 -0500 Received: from sj-msg-core-3.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13688 for ; Wed, 26 Feb 2003 11:02:54 -0500 (EST) Received: from jschnizl-w2k.cisco.com (rtp-vpn1-157.cisco.com [10.82.224.157]) by sj-msg-core-3.cisco.com (8.12.2/8.12.6) with ESMTP id h1QG6ZP8022136; Wed, 26 Feb 2003 08:06:35 -0800 (PST) Message-Id: <4.3.2.7.2.20030226104131.03ccaee0@wells.cisco.com> X-Sender: jschnizl@wells.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 26 Feb 2003 10:45:07 -0500 To: "Bernie Volz (EUD)" From: John Schnizlein Cc: dhcwg@ietf.org In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [dhcwg] Re: draft-volz-dhc-extended-optioncodes-00.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , At 10:20 AM 2/26/2003, Bernie Volz (EUD) wrote: >I'd like to bring this draft to the attention of the DHC WG. It is work that >I'd will request to be considered a WG item. > >Comments on the draft or it becoming a WG item (pro or con) are welcome. This is good idea, and should be adopted by the WG. The (now blank) recommendation should say that both methods should be pursued. Please provide (maybe discuss in SF?) some background for this belief: However, there are believed to be few sites that make heavy use of site-specific options and they would have many years to redeploy. John _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Feb 26 11:18:31 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14366; Wed, 26 Feb 2003 11:18:31 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QGRpp22532; Wed, 26 Feb 2003 11:27:51 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QGQ1p22413 for ; Wed, 26 Feb 2003 11:26:01 -0500 Received: from imr1.ericy.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14232 for ; Wed, 26 Feb 2003 11:15:55 -0500 (EST) Received: from mr5.exu.ericsson.se (mr5u3.ericy.com [208.237.135.124]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id h1QGJod12375; Wed, 26 Feb 2003 10:19:50 -0600 (CST) Received: from eamrcnt761.exu.ericsson.se (eamrcnt761.exu.ericsson.se [138.85.133.39]) by mr5.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id h1QGJoQ08964; Wed, 26 Feb 2003 10:19:50 -0600 (CST) Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2656.59) id ; Wed, 26 Feb 2003 10:19:49 -0600 Message-ID: From: "Bernie Volz (EUD)" To: "'John Schnizlein'" , "Bernie Volz (EUD)" Cc: dhcwg@ietf.org Date: Wed, 26 Feb 2003 10:18:09 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2DDB2.A701CB28" Subject: [dhcwg] RE: draft-volz-dhc-extended-optioncodes-00.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2DDB2.A701CB28 Content-Type: text/plain; charset="iso-8859-1" John: Thanks for your support! >The (now blank) recommendation should say that both methods should be pursued. Agreed. However, eventually it will need to specify which of the two (or perhaps some other) method should be adopted. >Please provide (maybe discuss in SF?) some background for this belief: > However, there are believed to be few sites that make heavy use of > site-specific options and they would have many years to redeploy. Not sure I can except to say that I've experienced very few instances where people have used these ... if you have information that contradicts this, please do provide it!!! Also note that by this statement I was referring to true and proper use of site-specific options and not those options that vendors may have defined for their own needs within the current site-specific options range - as those options violate the true meaning of site-specific and should be moved to either using vendor specific options OR consider documenting the use and getting an officially (IANA) assigned option number. - Bernie -----Original Message----- From: John Schnizlein [mailto:jschnizl@cisco.com] Sent: Wednesday, February 26, 2003 10:45 AM To: Bernie Volz (EUD) Cc: dhcwg@ietf.org Subject: Re: draft-volz-dhc-extended-optioncodes-00.txt At 10:20 AM 2/26/2003, Bernie Volz (EUD) wrote: >I'd like to bring this draft to the attention of the DHC WG. It is work that >I'd will request to be considered a WG item. > >Comments on the draft or it becoming a WG item (pro or con) are welcome. This is good idea, and should be adopted by the WG. The (now blank) recommendation should say that both methods should be pursued. Please provide (maybe discuss in SF?) some background for this belief: However, there are believed to be few sites that make heavy use of site-specific options and they would have many years to redeploy. John ------_=_NextPart_001_01C2DDB2.A701CB28 Content-Type: text/html; charset="iso-8859-1" RE: draft-volz-dhc-extended-optioncodes-00.txt

John:

Thanks for your support!

>The (now blank) recommendation should say that both methods should be pursued.

Agreed. However, eventually it will need to specify which of the two (or perhaps
some other) method should be adopted.

>Please provide (maybe discuss in SF?) some background for this belief:
>   However, there are believed to be few sites that make heavy use of
>   site-specific options and they would have many years to redeploy.

Not sure I can except to say that I've experienced very few instances where
people have used these ... if you have information that contradicts this,
please do provide it!!!

Also note that by this statement I was referring to true and proper use
of site-specific options and not those options that vendors may have defined
for their own needs within the current site-specific options range - as those
options violate the true meaning of site-specific and should be moved to
either using vendor specific options OR consider documenting the use and
getting an officially (IANA) assigned option number.

- Bernie

-----Original Message-----
From: John Schnizlein [mailto:jschnizl@cisco.com]
Sent: Wednesday, February 26, 2003 10:45 AM
To: Bernie Volz (EUD)
Cc: dhcwg@ietf.org
Subject: Re: draft-volz-dhc-extended-optioncodes-00.txt


At 10:20 AM 2/26/2003, Bernie Volz (EUD) wrote:

>I'd like to bring this draft to the attention of the DHC WG. It is work that
>I'd will request to be considered a WG item.
>
>Comments on the draft or it becoming a WG item (pro or con) are welcome.

This is good idea, and should be adopted by the WG.
The (now blank) recommendation should say that both methods should be pursued.
Please provide (maybe discuss in SF?) some background for this belief:
   However, there are believed to be few sites that make heavy use of
   site-specific options and they would have many years to redeploy.

John

------_=_NextPart_001_01C2DDB2.A701CB28-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Feb 26 12:04:57 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16108; Wed, 26 Feb 2003 12:04:57 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QHEQp27076; Wed, 26 Feb 2003 12:14:26 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QHDUp27038 for ; Wed, 26 Feb 2003 12:13:30 -0500 Received: from rtp-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16082 for ; Wed, 26 Feb 2003 12:03:23 -0500 (EST) Received: from goblet.cisco.com (IDENT:mirapoint@goblet.cisco.com [161.44.168.80]) by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h1QH7HNh021621; Wed, 26 Feb 2003 12:07:17 -0500 (EST) Received: from KKINNEAR-W2K.cisco.com (dhcp-161-44-149-161.cisco.com [161.44.149.161]) by goblet.cisco.com (Mirapoint) with ESMTP id ACR65737; Wed, 26 Feb 2003 12:07:15 -0500 (EST) Message-Id: <4.3.2.7.2.20030226115402.024c1818@goblet.cisco.com> X-Sender: kkinnear@goblet.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 26 Feb 2003 12:07:14 -0500 To: Thomas Narten , Kim Kinnear From: Kim Kinnear Subject: Re: [dhcwg] lease query question Cc: Ralph Droms , dhcwg@ietf.org In-Reply-To: <200302261534.h1QFYkmY004458@rotala.raleigh.ibm.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Thomas, This approach to access control was developed by joint work with the folks building our access concentrators and several of us in the DHCP implementation group. They found that the functionality delivered to actual users was of sufficient value to those users to be worth the cost of engineering this particular solution. We supported them in moving the implementation forward. The solution was not based on the charter of the DHC working group either then or now -- it was based on a rather pragmatic approach to meeting the needs of users, which it has seemed to do. In my view at least, it fits within spirit of the DHC WG activities, and was a logical extension of the those activities. It isn't a comprehensive approach to any sort of security (nor was it designed to be such) -- it is a supporting piece of technology to one limited form of access control. We decided to bring this work to IETF to see if anyone felt it was worthwhile to standardize it, and at the time the sense of the working group was that standardization was appropriate. We did this knowing full well that we would have to re-implement our support after the standardization process was complete, but felt that something this valuable should be standardized and available to all. I think it is time to ask that question again of the DHC WG -- is there any value to standardizing the leasequery capability? I will do so in a separate email, and we'll see just where this work stands with the other members of the working group. Kim At 10:34 AM 2/26/2003, Thomas Narten wrote: >> Would replacing the current problem statement with this one >> suggested by Ralph be sufficient to meet (enough of) your >> concerns to allow the draft to proceed? > >Not really. > >What we had originally (I had thought) was is a relatively simple >problem, with a relatively simple solution, and one that didn't really >change DHC in any serious way. The solution seem to have taken on >feature creap, where the problem got expanded, and the solution got >expanded. Sure, given any solution, one can go back and rewrite the >problem statement to make it match the solution. While that is >certainly necessary to make the document accurate, I have to wonder >whether the problem statement actually makes sense or is well defined. > >> > Router-type devices which want to enforce some level of access >> > control over which IP addresses are allowed on their links >> > need to maintain information concerning IP<->MAC/client-id >> > mappings. One way in which these devices can obtain >> > information about IP<->MAC/client-id bindings is through "DHCP >> > gleaning", in which the device extracts useful information >> > from DHCP messages exchanged between hosts and DHCP >> > servers. > >So far, simple. > >> > However, these devices don't typically have stable storage >> > sufficient to keep this information over reloads. There may >> > be additional information that is useful to the device that >> > cannot be obtained through DHCP gleaning. The leasequery >> > request message described in this document allows a device to >> > obtain information about IP<->MAC/client-id bindings from a >> > DHCP server. This information may include currently active >> > bindings, bindings involving previously assigned addresses for >> > which the lease on the address has expired and static bindings >> > for devices that are otherwise configured and not using DHCP >> > for address assignment. > >Note, that above is pretty vague and doesn't say what information the >access device needs. It's hard to look at the problem statement and >say "yes, I understand the boundaries of the problem" and then "and >the solution seems like a good match for the problem". > >Popping up a level, how is it even appropriate for the DHC WG to be >doing work on "access control in router type devices"? One can argue >that work of this broad a scope is well out-of-scope for this WG >(e.g., look at the recently approved charter). I'm far from clear that >work of this scope should be done in DHC or that the problem is well >enough understood to conclude that DHC lease query is the right >solution or that any DHC-based solution is the right one. What about >routers wanting to do access control that don't use DHC, for instance? > >And note, I'm not raising these issue just to be a PITA. These are >questions that I expect that the IESG would ask if I brought the >document forward. Thus, I need to have reasonable responses to those >questions. Otherwise, I can predict the likely outcome. > >Thomas >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Feb 26 12:34:52 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17226; Wed, 26 Feb 2003 12:34:52 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QHiHp29077; Wed, 26 Feb 2003 12:44:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QHhCp29023 for ; Wed, 26 Feb 2003 12:43:12 -0500 Received: from rtp-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17097 for ; Wed, 26 Feb 2003 12:33:04 -0500 (EST) Received: from goblet.cisco.com (IDENT:mirapoint@goblet.cisco.com [161.44.168.80]) by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h1QHavNh023112; Wed, 26 Feb 2003 12:36:58 -0500 (EST) Received: from KKINNEAR-W2K.cisco.com (dhcp-161-44-149-161.cisco.com [161.44.149.161]) by goblet.cisco.com (Mirapoint) with ESMTP id ACR66435; Wed, 26 Feb 2003 12:36:56 -0500 (EST) Message-Id: <4.3.2.7.2.20030226120723.025d5628@goblet.cisco.com> X-Sender: kkinnear@goblet.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 26 Feb 2003 12:36:55 -0500 To: dhcwg@ietf.org From: Kim Kinnear Cc: Ralph Droms , Thomas Narten , Kim Kinnear In-Reply-To: <200302261534.h1QFYkmY004458@rotala.raleigh.ibm.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [dhcwg] Leasequery: should it be standardized? Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Folks, We have come to something of a impasse on the leasequery draft, and I need *your* support if you believe we should continue to pursue this draft. =============================================================== Without considerable support from the DHC WG, we will halt work on the leasequery draft and all attempts to bring this work to standard status. =============================================================== If you believe that there is any value in standardizing the leasequery capability, please at least respond to this list ASAP with your positive support. If you have the time and expertise, please read the rest of this email and see if you can offer cogent arguments as to why this is work that the DHC working group should be pursuing. If we don't standardize the leasequery capability, each vendor of access concentrators and DHCP products that wish to use this approach will then need to work together (possibly in some other forum) to try to get their products to be compatible. Of course, it may well be that we are the only folks who see this as a useful capability, and so that may not be an issue at all. Thanks -- Kim ----------------------- Summary ----------------------- In case you haven't been following the email between Thomas Narten and myself, he has been questioning the problem statement of the leasequery draft. Ralph proposed a new problem statement, but Thomas feels that this whole capability is questionable. You are invited to respond to Thomas' arguments, which I have distilled as follows: 1. Doing anything in the DHC WG like supporting "access control in router type devices" is out of scope for the working group, and doesn't fit its current charter. 2. Access control in router type devices is not well enough understood to be sure that: a) leasequery is the right solution. b) any DHC-based approach is the "right" approach to solve this problem. 3. Until we are sure of 2(a), then we should not proceed with this work (I believe that this statement is implicit in Thomas' comments.) ----------------------- Background --------------------------- Here is Ralph's proposed problem statement: Router-type devices which want to enforce some level of access control over which IP addresses are allowed on their links need to maintain information concerning IP<-MAC/client-id mappings. One way in which these devices can obtain information about IP<-MAC/client-id bindings is through "DHCP gleaning", in which the device extracts useful information from DHCP messages exchanged between hosts and DHCP servers. However, these devices don't typically have stable storage sufficient to keep this information over reloads. There may be additional information that is useful to the device that cannot be obtained through DHCP gleaning. The leasequery request message described in this document allows a device to obtain information about IP<-MAC/client-id bindings from a DHCP server. This information may include currently active bindings, bindings involving previously assigned addresses for which the lease on the address has expired and static bindings for devices that are otherwise configured and not using DHCP for address assignment. Thomas' concerns center on the second paragraph above, and he says: Note, that above is pretty vague and doesn't say what information the access device needs. It's hard to look at the problem statement and say "yes, I understand the boundaries of the problem" and then "and the solution seems like a good match for the problem". Popping up a level, how is it even appropriate for the DHC WG to be doing work on "access control in router type devices"? One can argue that work of this broad a scope is well out-of-scope for this WG (e.g., look at the recently approved charter). I'm far from clear that work of this scope should be done in DHC or that the problem is well enough understood to conclude that DHC lease query is the right solution or that any DHC-based solution is the right one. What about routers wanting to do access control that don't use DHC, for instance? And note, I'm not raising these issue just to be a PITA. These are questions that I expect that the IESG would ask if I brought the document forward. Thus, I need to have reasonable responses to those questions. Otherwise, I can predict the likely outcome. My response to Thomas was: This approach to access control was developed by joint work with the folks building our access concentrators and several of us in the DHCP implementation group. They found that the functionality delivered to actual users was of sufficient value to those users to be worth the cost of engineering this particular solution. We supported them in moving the implementation forward. The solution was not based on the charter of the DHC working group either then or now -- it was based on a rather pragmatic approach to meeting the needs of users, which it has seemed to do. In my view at least, it fits within spirit of the DHC WG activities, and was a logical extension of the those activities. It isn't a comprehensive approach to any sort of security (nor was it designed to be such) -- it is a supporting piece of technology to one limited form of access control. Thanks for your interest in the leasequery capability. Kim _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Feb 26 12:54:48 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17933; Wed, 26 Feb 2003 12:54:47 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QI4Fp29884; Wed, 26 Feb 2003 13:04:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QI0Pp29726 for ; Wed, 26 Feb 2003 13:00:25 -0500 Received: from rtp-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17752 for ; Wed, 26 Feb 2003 12:50:17 -0500 (EST) Received: from goblet.cisco.com (IDENT:mirapoint@goblet.cisco.com [161.44.168.80]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h1QHsAJR013558; Wed, 26 Feb 2003 12:54:10 -0500 (EST) Received: from KKINNEAR-W2K.cisco.com (dhcp-161-44-149-161.cisco.com [161.44.149.161]) by goblet.cisco.com (Mirapoint) with ESMTP id ACR66900; Wed, 26 Feb 2003 12:54:08 -0500 (EST) Message-Id: <4.3.2.7.2.20030226125220.025d85b8@goblet.cisco.com> X-Sender: kkinnear@goblet.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 26 Feb 2003 12:54:07 -0500 To: "Bernie Volz (EUD)" , "'John Schnizlein'" , "Bernie Volz (EUD)" From: Kim Kinnear Subject: Re: [dhcwg] RE: draft-volz-dhc-extended-optioncodes-00.txt Cc: dhcwg@ietf.org In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , At 11:18 AM 2/26/2003, Bernie Volz (EUD) wrote: >John: > >Thanks for your support! > >>The (now blank) recommendation should say that both methods should be pursued. > >Agreed. However, eventually it will need to specify which of the two (or perhaps >some other) method should be adopted. > >>Please provide (maybe discuss in SF?) some background for this belief: >> However, there are believed to be few sites that make heavy use of >> site-specific options and they would have many years to redeploy. > >Not sure I can except to say that I've experienced very few instances where >people have used these ... if you have information that contradicts this, >please do provide it!!! > >Also note that by this statement I was referring to true and proper use >of site-specific options and not those options that vendors may have defined >for their own needs within the current site-specific options range - as those >options violate the true meaning of site-specific and should be moved to >either using vendor specific options OR consider documenting the use and >getting an officially (IANA) assigned option number. I don't recall *any* use of true site-specific options, though there are several cases of vendor "selected" options in the site-specific area (as Bernie notes) that we have encountered. So, I agree wholeheartedly with Bernie. Cheers -- Kim >- Bernie > >-----Original Message----- >From: John Schnizlein [mailto:jschnizl@cisco.com] >Sent: Wednesday, February 26, 2003 10:45 AM >To: Bernie Volz (EUD) >Cc: dhcwg@ietf.org >Subject: Re: draft-volz-dhc-extended-optioncodes-00.txt > >At 10:20 AM 2/26/2003, Bernie Volz (EUD) wrote: > >>I'd like to bring this draft to the attention of the DHC WG. It is work that >>I'd will request to be considered a WG item. >> >>Comments on the draft or it becoming a WG item (pro or con) are welcome. > >This is good idea, and should be adopted by the WG. >The (now blank) recommendation should say that both methods should be pursued. >Please provide (maybe discuss in SF?) some background for this belief: > However, there are believed to be few sites that make heavy use of > site-specific options and they would have many years to redeploy. > >John _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Feb 26 15:14:44 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22555; Wed, 26 Feb 2003 15:14:44 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QKMwp07179; Wed, 26 Feb 2003 15:22:58 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QKL9p07125 for ; Wed, 26 Feb 2003 15:21:09 -0500 Received: from grizzly (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA22398 for ; Wed, 26 Feb 2003 15:10:58 -0500 (EST) Received: from endeavor.poss.com ([198.70.184.137]) by grizzly; Wed, 26 Feb 2003 15:08:48 -0500 (EST) Received: from knoll (user56.net384.nc.sprint-hsd.net [65.40.69.56]) by endeavor.poss.com (iPlanet Messaging Server 5.2 HotFix 0.9 (built Jul 29 2002)) with ESMTPA id <0HAX00KP3MWNMR@endeavor.poss.com> for dhcwg@ietf.org; Wed, 26 Feb 2003 15:14:50 -0500 (EST) Date: Wed, 26 Feb 2003 15:17:20 -0500 From: "Kevin A. Noll" Subject: RE: [dhcwg] Leasequery: should it be standardized? In-reply-to: <4.3.2.7.2.20030226120723.025d5628@goblet.cisco.com> To: Kim Kinnear , dhcwg@ietf.org Cc: Ralph Droms , Thomas Narten Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7BIT Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT Kim, At the risk of sounding foolish since I'm not an active participant in the WG... I think there is a need to standardize leasequery. It seems to me that the problem statement is the real issue. LeaseQuery should not be positioned in any way as an access control mechanism or *necessarily* involved in such, especially since there are other uses for this information. Leasequery is just what the name implies - a *standard* method for external entities (whether they be routers or some other system) to query the DHCP server for lease information. As it is today, there is no *standard* backend DHCP database that can be queried. Some use text files, some use LDAP, some use proprietary databases, etc. Therefore, the ability to query a DHCP server for lease information does not exist except through proprietary methods. This limits interoperability of the various vendors systems. For example, there is no way for vendor X to query vendor Y's DHCP server unless they cooperate outside the standards bodies. This functionality is not limited to routers (or other devices) using the information for access control. There are cases (not necessarily well documented) where systems external to the DHCP server need to find out about a lease for network management or troubleshooting reasons. One example is a helpdesk staffer trying to find out whether a device is up or down, but only knows the MAC address of the device. How does he/she find out the IP? Okay, DNS could be consulted, but it isn't authoritative for information regarding MAC-to-IP mapping, only NAME-to-IP mapping. There have been various schemes to store this information in DNS (e.g. the NAME is easily derived given the MAC, etc), but there are all kinds of issues that arise with this solution (what if we don't *want* that information in DNS, etc.) The stable storage statements in the current problem statement aren't necessarily relevant, either. My suggestion is that the problem statement be centered around making the DHCP server the *authority* for lease information. An alternative would be to write a new draft (maybe not within this WG) that would define a way to make some existing network database (probably DNS) authoritative for this information. I think we could come up with a better problem statement that would get your leasequery draft further down the road. Anyway, that's my 2 cents worth. --kan-- -- Kevin A. Noll, KD4WOZ Kevin.Noll@perfectorder.com CCIE,CCDP Perfect Order, Inc. 717-796-1936 -----Original Message----- From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org]On Behalf Of Kim Kinnear Sent: Wednesday, 26 February, 2003 12:37 PM To: dhcwg@ietf.org Cc: Ralph Droms; Thomas Narten; Kim Kinnear Subject: [dhcwg] Leasequery: should it be standardized? Folks, We have come to something of a impasse on the leasequery draft, and I need *your* support if you believe we should continue to pursue this draft. =============================================================== Without considerable support from the DHC WG, we will halt work on the leasequery draft and all attempts to bring this work to standard status. =============================================================== If you believe that there is any value in standardizing the leasequery capability, please at least respond to this list ASAP with your positive support. If you have the time and expertise, please read the rest of this email and see if you can offer cogent arguments as to why this is work that the DHC working group should be pursuing. If we don't standardize the leasequery capability, each vendor of access concentrators and DHCP products that wish to use this approach will then need to work together (possibly in some other forum) to try to get their products to be compatible. Of course, it may well be that we are the only folks who see this as a useful capability, and so that may not be an issue at all. Thanks -- Kim ----------------------- Summary ----------------------- In case you haven't been following the email between Thomas Narten and myself, he has been questioning the problem statement of the leasequery draft. Ralph proposed a new problem statement, but Thomas feels that this whole capability is questionable. You are invited to respond to Thomas' arguments, which I have distilled as follows: 1. Doing anything in the DHC WG like supporting "access control in router type devices" is out of scope for the working group, and doesn't fit its current charter. 2. Access control in router type devices is not well enough understood to be sure that: a) leasequery is the right solution. b) any DHC-based approach is the "right" approach to solve this problem. 3. Until we are sure of 2(a), then we should not proceed with this work (I believe that this statement is implicit in Thomas' comments.) ----------------------- Background --------------------------- Here is Ralph's proposed problem statement: Router-type devices which want to enforce some level of access control over which IP addresses are allowed on their links need to maintain information concerning IP<-MAC/client-id mappings. One way in which these devices can obtain information about IP<-MAC/client-id bindings is through "DHCP gleaning", in which the device extracts useful information from DHCP messages exchanged between hosts and DHCP servers. However, these devices don't typically have stable storage sufficient to keep this information over reloads. There may be additional information that is useful to the device that cannot be obtained through DHCP gleaning. The leasequery request message described in this document allows a device to obtain information about IP<-MAC/client-id bindings from a DHCP server. This information may include currently active bindings, bindings involving previously assigned addresses for which the lease on the address has expired and static bindings for devices that are otherwise configured and not using DHCP for address assignment. Thomas' concerns center on the second paragraph above, and he says: Note, that above is pretty vague and doesn't say what information the access device needs. It's hard to look at the problem statement and say "yes, I understand the boundaries of the problem" and then "and the solution seems like a good match for the problem". Popping up a level, how is it even appropriate for the DHC WG to be doing work on "access control in router type devices"? One can argue that work of this broad a scope is well out-of-scope for this WG (e.g., look at the recently approved charter). I'm far from clear that work of this scope should be done in DHC or that the problem is well enough understood to conclude that DHC lease query is the right solution or that any DHC-based solution is the right one. What about routers wanting to do access control that don't use DHC, for instance? And note, I'm not raising these issue just to be a PITA. These are questions that I expect that the IESG would ask if I brought the document forward. Thus, I need to have reasonable responses to those questions. Otherwise, I can predict the likely outcome. My response to Thomas was: This approach to access control was developed by joint work with the folks building our access concentrators and several of us in the DHCP implementation group. They found that the functionality delivered to actual users was of sufficient value to those users to be worth the cost of engineering this particular solution. We supported them in moving the implementation forward. The solution was not based on the charter of the DHC working group either then or now -- it was based on a rather pragmatic approach to meeting the needs of users, which it has seemed to do. In my view at least, it fits within spirit of the DHC WG activities, and was a logical extension of the those activities. It isn't a comprehensive approach to any sort of security (nor was it designed to be such) -- it is a supporting piece of technology to one limited form of access control. Thanks for your interest in the leasequery capability. Kim _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Feb 26 15:28:42 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23271; Wed, 26 Feb 2003 15:28:42 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QKcAp08495; Wed, 26 Feb 2003 15:38:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QKb8p08021 for ; Wed, 26 Feb 2003 15:37:08 -0500 Received: from toccata.fugue.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23041 for ; Wed, 26 Feb 2003 15:26:58 -0500 (EST) Received: from nominum.com (dsl093-187-232.chi2.dsl.speakeasy.net [66.93.187.232]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id h1QKS1J17965; Wed, 26 Feb 2003 14:28:02 -0600 (CST) Date: Wed, 26 Feb 2003 14:30:51 -0600 Subject: Re: [dhcwg] Leasequery: should it be standardized? Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: dhcwg@ietf.org, Ralph Droms , Thomas Narten To: Kim Kinnear From: Ted Lemon In-Reply-To: <4.3.2.7.2.20030226120723.025d5628@goblet.cisco.com> Message-Id: <32706BFC-49C9-11D7-AF3B-00039367340A@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > If you believe that there is any value in standardizing the > leasequery capability, please at least respond to this list ASAP > with your positive support. Yes, DHCPLEASEQUERY is a good thing, and I support it. I don't know how to address Thomas' complaints about its relevance to the WG charter - perhaps it should be advanced in some other WG, or independent of a WG - but it's certainly a good idea, and certainly whether or not there is some other WG in which it need also be discussed, it was highly appropriate to raise it here, since it is an extension to DHCP, and this is where the DHCP expertise is concentrated. My recollection, though, was that back in the beginning of all this, DHCPLEASEQUERY was about providing a way to refresh the ARP cache of a concentrator without having to broadcast an ARP request to every one of the concentrator's ports. Is that no longer the case? _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Feb 26 15:55:40 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24840; Wed, 26 Feb 2003 15:55:40 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QL5Bp09854; Wed, 26 Feb 2003 16:05:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QL4Ap09802 for ; Wed, 26 Feb 2003 16:04:10 -0500 Received: from e31.co.us.ibm.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24779 for ; Wed, 26 Feb 2003 15:53:59 -0500 (EST) Received: from westrelay03.boulder.ibm.com (westrelay03.boulder.ibm.com [9.17.194.24]) by e31.co.us.ibm.com (8.12.7/8.12.2) with ESMTP id h1QKvR0Z049178; Wed, 26 Feb 2003 15:57:27 -0500 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.27.12.14]) by westrelay03.boulder.ibm.com (8.12.3/NCO/VER6.5) with ESMTP id h1QKvOFU077048; Wed, 26 Feb 2003 13:57:25 -0700 Received: from rotala.raleigh.ibm.com (localhost.localdomain [127.0.0.1]) by rotala.raleigh.ibm.com (8.12.5/8.12.5) with ESMTP id h1QKqRem006032; Wed, 26 Feb 2003 15:52:27 -0500 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.12.5/8.12.5/Submit) with ESMTP id h1QKqRSm006027; Wed, 26 Feb 2003 15:52:27 -0500 Message-Id: <200302262052.h1QKqRSm006027@rotala.raleigh.ibm.com> To: Ted Lemon cc: Kim Kinnear , dhcwg@ietf.org, Ralph Droms Subject: Re: [dhcwg] Leasequery: should it be standardized? In-Reply-To: Message from Ted.Lemon@nominum.com of "Wed, 26 Feb 2003 14:30:51 CST." <32706BFC-49C9-11D7-AF3B-00039367340A@nominum.com> Date: Wed, 26 Feb 2003 15:52:27 -0500 From: Thomas Narten Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , > My recollection, though, was that back in the beginning of all this, > DHCPLEASEQUERY was about providing a way to refresh the ARP cache of a > concentrator without having to broadcast an ARP request to every one of > the concentrator's ports. Is that no longer the case? Apparently so, and that is what has prompted my asking questions. The scope of the problem seems to have expanded quite a bit beyond: "providing a way to refresh the ARP cache of a concentrator without having to broadcast an ARP request to every one of the concentrator's ports", to something perhaps closer to providing "access control in router type devices", including cases where DHCP isn't even being used. I don't have a real problem with leasequery as it was originally described. But if the scope of the problem being solved expands well beyond the original problem, it's no longer clear that: - the problem statement is adequately well understood and accepted by the broader community (or maybe even the DHC community). Maybe other folk not familiar with DHC need a solution to the broader problem and will see this solution as being deficient for their needs. - it's no longer clear whether DHC has the right expertise to get the problem defined properly or to work out a good solution. - it's no longer obvious that DHC is the best solution to the expanded problem. I am not saying that leasequery as a concept is flawed, but I am asking questions about the current version of the leasequery draft and whether it has the right level of functionality and features in it and is the right thing to standardize on. Thomas _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Feb 26 15:56:50 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24890; Wed, 26 Feb 2003 15:56:50 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QL6Op09920; Wed, 26 Feb 2003 16:06:24 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QKfKp08814 for ; Wed, 26 Feb 2003 15:41:20 -0500 Received: from grizzly (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA23605 for ; Wed, 26 Feb 2003 15:31:09 -0500 (EST) Received: from endeavor.poss.com ([198.70.184.137]) by grizzly; Wed, 26 Feb 2003 15:29:02 -0500 (EST) Received: from knoll (user56.net384.nc.sprint-hsd.net [65.40.69.56]) by endeavor.poss.com (iPlanet Messaging Server 5.2 HotFix 0.9 (built Jul 29 2002)) with ESMTPA id <0HAX00KYXNUDMR@endeavor.poss.com> for dhcwg@ietf.org; Wed, 26 Feb 2003 15:35:04 -0500 (EST) Date: Wed, 26 Feb 2003 15:37:34 -0500 From: "Kevin A. Noll" Subject: RE: [dhcwg] Leasequery: should it be standardized? In-reply-to: To: Kim Kinnear , dhcwg@ietf.org Cc: Ralph Droms , Thomas Narten Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7BIT Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT Kim, At the risk of sounding foolish since I'm not an active participant in the WG... I think there is a need to standardize leasequery. It seems to me that the problem statement is the real issue. LeaseQuery should not be positioned in any way as an access control mechanism or *necessarily* involved in such, especially since there are other uses for this information. Leasequery is just what the name implies - a *standard* method for external entities (whether they be routers or some other system) to query the DHCP server for lease information. As it is today, there is no *standard* backend DHCP database that can be queried. Some use text files, some use LDAP, some use proprietary databases, etc. Therefore, the ability to query a DHCP server for lease information does not exist except through proprietary methods. This limits interoperability of the various vendors systems. For example, there is no way for vendor X to query vendor Y's DHCP server unless they cooperate outside the standards bodies. This functionality is not limited to routers (or other devices) using the information for access control. There are cases (not necessarily well documented) where systems external to the DHCP server need to find out about a lease for network management or troubleshooting reasons. One example is a helpdesk staffer trying to find out whether a device is up or down, but only knows the MAC address of the device. How does he/she find out the IP? Okay, DNS could be consulted, but it isn't authoritative for information regarding MAC-to-IP mapping, only NAME-to-IP mapping. There have been various schemes to store this information in DNS (e.g. the NAME is easily derived given the MAC, etc), but there are all kinds of issues that arise with this solution (what if we don't *want* that information in DNS, etc.) The stable storage statements in the current problem statement aren't necessarily relevant, either. My suggestion is that the problem statement be centered around making the DHCP server the *authority* for lease information. An alternative would be to write a new draft (maybe not within this WG) that would define a way to make some existing network database (probably DNS) authoritative for this information. I think we could come up with a better problem statement that would get your leasequery draft further down the road. Anyway, that's my 2 cents worth. --kan-- -- Kevin A. Noll, KD4WOZ Kevin.Noll@perfectorder.com CCIE,CCDP Perfect Order, Inc. 717-796-1936 -----Original Message----- From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org]On Behalf Of Kim Kinnear Sent: Wednesday, 26 February, 2003 12:37 PM To: dhcwg@ietf.org Cc: Ralph Droms; Thomas Narten; Kim Kinnear Subject: [dhcwg] Leasequery: should it be standardized? Folks, We have come to something of a impasse on the leasequery draft, and I need *your* support if you believe we should continue to pursue this draft. =============================================================== Without considerable support from the DHC WG, we will halt work on the leasequery draft and all attempts to bring this work to standard status. =============================================================== If you believe that there is any value in standardizing the leasequery capability, please at least respond to this list ASAP with your positive support. If you have the time and expertise, please read the rest of this email and see if you can offer cogent arguments as to why this is work that the DHC working group should be pursuing. If we don't standardize the leasequery capability, each vendor of access concentrators and DHCP products that wish to use this approach will then need to work together (possibly in some other forum) to try to get their products to be compatible. Of course, it may well be that we are the only folks who see this as a useful capability, and so that may not be an issue at all. Thanks -- Kim ----------------------- Summary ----------------------- In case you haven't been following the email between Thomas Narten and myself, he has been questioning the problem statement of the leasequery draft. Ralph proposed a new problem statement, but Thomas feels that this whole capability is questionable. You are invited to respond to Thomas' arguments, which I have distilled as follows: 1. Doing anything in the DHC WG like supporting "access control in router type devices" is out of scope for the working group, and doesn't fit its current charter. 2. Access control in router type devices is not well enough understood to be sure that: a) leasequery is the right solution. b) any DHC-based approach is the "right" approach to solve this problem. 3. Until we are sure of 2(a), then we should not proceed with this work (I believe that this statement is implicit in Thomas' comments.) ----------------------- Background --------------------------- Here is Ralph's proposed problem statement: Router-type devices which want to enforce some level of access control over which IP addresses are allowed on their links need to maintain information concerning IP<-MAC/client-id mappings. One way in which these devices can obtain information about IP<-MAC/client-id bindings is through "DHCP gleaning", in which the device extracts useful information from DHCP messages exchanged between hosts and DHCP servers. However, these devices don't typically have stable storage sufficient to keep this information over reloads. There may be additional information that is useful to the device that cannot be obtained through DHCP gleaning. The leasequery request message described in this document allows a device to obtain information about IP<-MAC/client-id bindings from a DHCP server. This information may include currently active bindings, bindings involving previously assigned addresses for which the lease on the address has expired and static bindings for devices that are otherwise configured and not using DHCP for address assignment. Thomas' concerns center on the second paragraph above, and he says: Note, that above is pretty vague and doesn't say what information the access device needs. It's hard to look at the problem statement and say "yes, I understand the boundaries of the problem" and then "and the solution seems like a good match for the problem". Popping up a level, how is it even appropriate for the DHC WG to be doing work on "access control in router type devices"? One can argue that work of this broad a scope is well out-of-scope for this WG (e.g., look at the recently approved charter). I'm far from clear that work of this scope should be done in DHC or that the problem is well enough understood to conclude that DHC lease query is the right solution or that any DHC-based solution is the right one. What about routers wanting to do access control that don't use DHC, for instance? And note, I'm not raising these issue just to be a PITA. These are questions that I expect that the IESG would ask if I brought the document forward. Thus, I need to have reasonable responses to those questions. Otherwise, I can predict the likely outcome. My response to Thomas was: This approach to access control was developed by joint work with the folks building our access concentrators and several of us in the DHCP implementation group. They found that the functionality delivered to actual users was of sufficient value to those users to be worth the cost of engineering this particular solution. We supported them in moving the implementation forward. The solution was not based on the charter of the DHC working group either then or now -- it was based on a rather pragmatic approach to meeting the needs of users, which it has seemed to do. In my view at least, it fits within spirit of the DHC WG activities, and was a logical extension of the those activities. It isn't a comprehensive approach to any sort of security (nor was it designed to be such) -- it is a supporting piece of technology to one limited form of access control. Thanks for your interest in the leasequery capability. Kim _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Feb 26 16:02:34 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25294; Wed, 26 Feb 2003 16:02:34 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QLC6p11041; Wed, 26 Feb 2003 16:12:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QLBfp11012 for ; Wed, 26 Feb 2003 16:11:41 -0500 Received: from imr2.ericy.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25260 for ; Wed, 26 Feb 2003 16:01:24 -0500 (EST) Received: from mr5.exu.ericsson.se (mr5att.ericy.com [138.85.224.141]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id h1QL4lb20945; Wed, 26 Feb 2003 15:04:47 -0600 (CST) Received: from eamrcnt760.exu.ericsson.se (eamrcnt760.exu.ericsson.se [138.85.133.38]) by mr5.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id h1QL4lC11887; Wed, 26 Feb 2003 15:04:47 -0600 (CST) Received: by eamrcnt760.exu.ericsson.se with Internet Mail Service (5.5.2656.59) id ; Wed, 26 Feb 2003 15:04:47 -0600 Message-ID: From: "Bernie Volz (EUD)" To: "'Kevin A. Noll'" , Kim Kinnear , dhcwg@ietf.org Cc: Ralph Droms , Thomas Narten Subject: RE: [dhcwg] Leasequery: should it be standardized? Date: Wed, 26 Feb 2003 15:03:06 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2DDDA.741F7D68" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2DDDA.741F7D68 Content-Type: text/plain; charset="ISO-8859-1" Kim/Kevin: I agree with Kevin's statements. I too think it is important that this is standardize by the IETF (which WG is less critical, though DHC WG seems like a good home to me because it is after all DHCP). I agree with Kevin's point about there needing to be some standard means to query the DHCP server's database about clients. For example, this might also be used by routers or other devices on the network to handle admission control. The first packet for an IP address that is not in the router's OK list (or hasn't been checked in a while) could be confirmed (IP + MAC) via leasequery. There are also other uses of this, for example for network monitoring. Perhaps there are other ways this problem could be solved, for example by finishing up an SNMP MIB for DHCP that allows this kind of information to be obtained. But, that road has been tried and has not been finalized. And, finally there are probably future uses of this kind of capability that we've never would have thought about. So, setting up something that is more flexible and powerful than just solving a very small and specific problem is, IMHO, the IETF way. Perhaps a fix is to state that the original problem statement was blah, blah, blah, and leasequery meets those needs, plus more. - Bernie Volz -----Original Message----- From: Kevin A. Noll [mailto:kevin.noll@perfectorder.com] Sent: Wednesday, February 26, 2003 3:17 PM To: Kim Kinnear; dhcwg@ietf.org Cc: Ralph Droms; Thomas Narten Subject: RE: [dhcwg] Leasequery: should it be standardized? Kim, At the risk of sounding foolish since I'm not an active participant in the WG... I think there is a need to standardize leasequery. It seems to me that the problem statement is the real issue. LeaseQuery should not be positioned in any way as an access control mechanism or *necessarily* involved in such, especially since there are other uses for this information. Leasequery is just what the name implies - a *standard* method for external entities (whether they be routers or some other system) to query the DHCP server for lease information. As it is today, there is no *standard* backend DHCP database that can be queried. Some use text files, some use LDAP, some use proprietary databases, etc. Therefore, the ability to query a DHCP server for lease information does not exist except through proprietary methods. This limits interoperability of the various vendors systems. For example, there is no way for vendor X to query vendor Y's DHCP server unless they cooperate outside the standards bodies. This functionality is not limited to routers (or other devices) using the information for access control. There are cases (not necessarily well documented) where systems external to the DHCP server need to find out about a lease for network management or troubleshooting reasons. One example is a helpdesk staffer trying to find out whether a device is up or down, but only knows the MAC address of the device. How does he/she find out the IP? Okay, DNS could be consulted, but it isn't authoritative for information regarding MAC-to-IP mapping, only NAME-to-IP mapping. There have been various schemes to store this information in DNS (e.g. the NAME is easily derived given the MAC, etc), but there are all kinds of issues that arise with this solution (what if we don't *want* that information in DNS, etc.) The stable storage statements in the current problem statement aren't necessarily relevant, either. My suggestion is that the problem statement be centered around making the DHCP server the *authority* for lease information. An alternative would be to write a new draft (maybe not within this WG) that would define a way to make some existing network database (probably DNS) authoritative for this information. I think we could come up with a better problem statement that would get your leasequery draft further down the road. Anyway, that's my 2 cents worth. --kan-- -- Kevin A. Noll, KD4WOZ Kevin.Noll@perfectorder.com CCIE,CCDP Perfect Order, Inc. 717-796-1936 -----Original Message----- From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org]On Behalf Of Kim Kinnear Sent: Wednesday, 26 February, 2003 12:37 PM To: dhcwg@ietf.org Cc: Ralph Droms; Thomas Narten; Kim Kinnear Subject: [dhcwg] Leasequery: should it be standardized? Folks, We have come to something of a impasse on the leasequery draft, and I need *your* support if you believe we should continue to pursue this draft. =============================================================== Without considerable support from the DHC WG, we will halt work on the leasequery draft and all attempts to bring this work to standard status. =============================================================== If you believe that there is any value in standardizing the leasequery capability, please at least respond to this list ASAP with your positive support. If you have the time and expertise, please read the rest of this email and see if you can offer cogent arguments as to why this is work that the DHC working group should be pursuing. If we don't standardize the leasequery capability, each vendor of access concentrators and DHCP products that wish to use this approach will then need to work together (possibly in some other forum) to try to get their products to be compatible. Of course, it may well be that we are the only folks who see this as a useful capability, and so that may not be an issue at all. Thanks -- Kim ----------------------- Summary ----------------------- In case you haven't been following the email between Thomas Narten and myself, he has been questioning the problem statement of the leasequery draft. Ralph proposed a new problem statement, but Thomas feels that this whole capability is questionable. You are invited to respond to Thomas' arguments, which I have distilled as follows: 1. Doing anything in the DHC WG like supporting "access control in router type devices" is out of scope for the working group, and doesn't fit its current charter. 2. Access control in router type devices is not well enough understood to be sure that: a) leasequery is the right solution. b) any DHC-based approach is the "right" approach to solve this problem. 3. Until we are sure of 2(a), then we should not proceed with this work (I believe that this statement is implicit in Thomas' comments.) ----------------------- Background --------------------------- Here is Ralph's proposed problem statement: Router-type devices which want to enforce some level of access control over which IP addresses are allowed on their links need to maintain information concerning IP<-MAC/client-id mappings. One way in which these devices can obtain information about IP<-MAC/client-id bindings is through "DHCP gleaning", in which the device extracts useful information from DHCP messages exchanged between hosts and DHCP servers. However, these devices don't typically have stable storage sufficient to keep this information over reloads. There may be additional information that is useful to the device that cannot be obtained through DHCP gleaning. The leasequery request message described in this document allows a device to obtain information about IP<-MAC/client-id bindings from a DHCP server. This information may include currently active bindings, bindings involving previously assigned addresses for which the lease on the address has expired and static bindings for devices that are otherwise configured and not using DHCP for address assignment. Thomas' concerns center on the second paragraph above, and he says: Note, that above is pretty vague and doesn't say what information the access device needs. It's hard to look at the problem statement and say "yes, I understand the boundaries of the problem" and then "and the solution seems like a good match for the problem". Popping up a level, how is it even appropriate for the DHC WG to be doing work on "access control in router type devices"? One can argue that work of this broad a scope is well out-of-scope for this WG (e.g., look at the recently approved charter). I'm far from clear that work of this scope should be done in DHC or that the problem is well enough understood to conclude that DHC lease query is the right solution or that any DHC-based solution is the right one. What about routers wanting to do access control that don't use DHC, for instance? And note, I'm not raising these issue just to be a PITA. These are questions that I expect that the IESG would ask if I brought the document forward. Thus, I need to have reasonable responses to those questions. Otherwise, I can predict the likely outcome. My response to Thomas was: This approach to access control was developed by joint work with the folks building our access concentrators and several of us in the DHCP implementation group. They found that the functionality delivered to actual users was of sufficient value to those users to be worth the cost of engineering this particular solution. We supported them in moving the implementation forward. The solution was not based on the charter of the DHC working group either then or now -- it was based on a rather pragmatic approach to meeting the needs of users, which it has seemed to do. In my view at least, it fits within spirit of the DHC WG activities, and was a logical extension of the those activities. It isn't a comprehensive approach to any sort of security (nor was it designed to be such) -- it is a supporting piece of technology to one limited form of access control. Thanks for your interest in the leasequery capability. Kim _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg ------_=_NextPart_001_01C2DDDA.741F7D68 Content-Type: text/html; charset="ISO-8859-1" RE: [dhcwg] Leasequery: should it be standardized?

Kim/Kevin:

I agree with Kevin's statements. I too think it is important that this is
standardize by the IETF (which WG is less critical, though DHC WG seems
like a good home to me because it is after all DHCP).

I agree with Kevin's point about there needing to be some standard
means to query the DHCP server's database about clients.

For example, this might also be used by routers or other devices on the
network to handle admission control. The first packet for an IP address
that is not in the router's OK list (or hasn't been checked in a while)
could be confirmed (IP + MAC) via leasequery.

There are also other uses of this, for example for network monitoring.
Perhaps there are other ways this problem could be solved, for example
by finishing up an SNMP MIB for DHCP that allows this kind of information
to be obtained. But, that road has been tried and has not been finalized.

And, finally there are probably future uses of this kind of capability
that we've never would have thought about. So, setting up something that
is more flexible and powerful than just solving a very small and specific
problem is, IMHO, the IETF way.

Perhaps a fix is to state that the original problem statement was blah,
blah, blah, and leasequery meets those needs, plus more.

- Bernie Volz

-----Original Message-----
From: Kevin A. Noll [mailto:kevin.noll@perfectorder.com]
Sent: Wednesday, February 26, 2003 3:17 PM
To: Kim Kinnear; dhcwg@ietf.org
Cc: Ralph Droms; Thomas Narten
Subject: RE: [dhcwg] Leasequery: should it be standardized?



Kim,

At the risk of sounding foolish since I'm not an active
participant in the WG...

I think there is a need to standardize leasequery.

It seems to me that the problem statement is the real issue.

LeaseQuery should not be positioned in any way as an access
control mechanism or *necessarily* involved in such, especially
since there are other uses for this information.

Leasequery is just what the name implies - a *standard* method for
external entities (whether they be routers or some other system)
to query the DHCP server for lease information.

As it is today, there is no *standard* backend DHCP database that
can be queried. Some use text files, some use LDAP, some use proprietary
databases, etc. Therefore, the ability to query a DHCP server for
lease information does not exist except through proprietary methods.

This limits interoperability of the various vendors systems. For example,
there is no way for vendor X to query vendor Y's DHCP server unless
they cooperate outside the standards bodies.

This functionality is not limited to routers (or other devices)
using the information for access control. There are cases (not
necessarily well documented) where systems external to the DHCP
server need to find out about a lease for network management or
troubleshooting reasons.

One example is a helpdesk staffer trying to find out whether a
device is up or down, but only knows the MAC address of the device.
How does he/she find out the IP?

Okay, DNS could be consulted, but it isn't authoritative for information
regarding MAC-to-IP mapping, only NAME-to-IP mapping. There have been
various schemes to store this information in DNS (e.g. the NAME is easily
derived given the MAC, etc), but there are all kinds of issues that arise
with this solution (what if we don't *want* that information in DNS, etc.)

The stable storage statements in the current problem statement aren't
necessarily relevant, either.

My suggestion is that the problem statement be centered around making the
DHCP server the *authority* for lease information.

An alternative would be to write a new draft (maybe not within this WG) that
would define a way to make some existing network database (probably DNS)
authoritative for this information.

I think we could come up with a better problem statement that
would get your leasequery draft further down the road.

Anyway, that's my 2 cents worth.

--kan--
--
Kevin A. Noll, KD4WOZ                           Kevin.Noll@perfectorder.com
CCIE,CCDP
Perfect Order, Inc.                             717-796-1936



-----Original Message-----
From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org]On Behalf Of Kim
Kinnear
Sent: Wednesday, 26 February, 2003 12:37 PM
To: dhcwg@ietf.org
Cc: Ralph Droms; Thomas Narten; Kim Kinnear
Subject: [dhcwg] Leasequery: should it be standardized?



Folks,

We have come to something of a impasse on the leasequery draft,
and I need *your* support if you believe we should continue to
pursue this draft.

===============================================================
Without considerable support from the DHC WG, we will halt work
on the leasequery draft and all attempts to bring this work to
standard status.
===============================================================

If you believe that there is any value in standardizing the
leasequery capability, please at least respond to this list ASAP
with your positive support.

If you have the time and expertise, please read the rest of this
email and see if you can offer cogent arguments as to why this is
work that the DHC working group should be pursuing.

If we don't standardize the leasequery capability, each vendor of
access concentrators and DHCP products that wish to use this
approach will then need to work together (possibly in some other
forum) to try to get their products to be compatible.  Of course,
it may well be that we are the only folks who see this as a
useful capability, and so that may not be an issue at all.

Thanks -- Kim

-----------------------  Summary -----------------------

In case you haven't been following the email between Thomas
Narten and myself, he has been questioning the problem statement
of the leasequery draft.  Ralph proposed a new problem statement,
but Thomas feels that this whole capability is questionable.

You are invited to respond to Thomas' arguments, which I have
distilled as follows:

  1.  Doing anything in the DHC WG like supporting "access
  control in router type devices" is out of scope for the working
  group, and doesn't fit its current charter.

  2.  Access control in router type devices is not well enough
  understood to be sure that:

        a) leasequery is the right solution.


        b) any DHC-based approach is the "right" approach to
        solve this problem.

  3.  Until we are sure of 2(a), then we should not proceed with
  this work (I believe that this statement is implicit in Thomas'
  comments.)

-----------------------  Background ---------------------------

Here is Ralph's proposed problem statement:

   Router-type devices which want to enforce some level of access
   control over which IP addresses are allowed on their links
   need to maintain information concerning IP<-MAC/client-id
   mappings.  One way in which these devices can obtain
   information about IP<-MAC/client-id bindings is through "DHCP
   gleaning", in which the device extracts useful information
   from DHCP messages exchanged between hosts and DHCP servers.

   However, these devices don't typically have stable storage
   sufficient to keep this information over reloads.  There may
   be additional information that is useful to the device that
   cannot be obtained through DHCP gleaning.  The leasequery
   request message described in this document allows a device to
   obtain information about IP<-MAC/client-id bindings from a
   DHCP server.  This information may include currently active
   bindings, bindings involving previously assigned addresses for
   which the lease on the address has expired and static bindings
   for devices that are otherwise configured and not using DHCP
   for address assignment.

Thomas' concerns center on the second paragraph above, and he says:

   Note, that above is pretty vague and doesn't say what
   information the access device needs.  It's hard to look at the
   problem statement and say "yes, I understand the boundaries of
   the problem" and then "and the solution seems like a good
   match for the problem".

   Popping up a level, how is it even appropriate for the DHC WG
   to be doing work on "access control in router type devices"?
   One can argue that work of this broad a scope is well
   out-of-scope for this WG (e.g., look at the recently approved
   charter).  I'm far from clear that work of this scope should
   be done in DHC or that the problem is well enough understood
   to conclude that DHC lease query is the right solution or that
   any DHC-based solution is the right one.  What about routers
   wanting to do access control that don't use DHC, for instance?

   And note, I'm not raising these issue just to be a PITA. These
   are questions that I expect that the IESG would ask if I
   brought the document forward.  Thus, I need to have reasonable
   responses to those questions.  Otherwise, I can predict the
   likely outcome.

My response to Thomas was:

   This approach to access control was developed by joint work
   with the folks building our access concentrators and several
   of us in the DHCP implementation group.  They found that the
   functionality delivered to actual users was of sufficient
   value to those users to be worth the cost of engineering this
   particular solution.  We supported them in moving the
   implementation forward.

   The solution was not based on the charter of the DHC working
   group either then or now -- it was based on a rather pragmatic
   approach to meeting the needs of users, which it has seemed to
   do.  In my view at least, it fits within spirit of the DHC WG
   activities, and was a logical extension of the those
   activities.

   It isn't a comprehensive approach to any sort of security (nor
   was it designed to be such) -- it is a supporting piece of
   technology to one limited form of access control.

Thanks for your interest in the leasequery capability.

Kim

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg



_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg

------_=_NextPart_001_01C2DDDA.741F7D68-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Feb 26 16:05:24 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25460; Wed, 26 Feb 2003 16:05:24 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QLF4p11255; Wed, 26 Feb 2003 16:15:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QLEOp11205 for ; Wed, 26 Feb 2003 16:14:24 -0500 Received: from imr1.ericy.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25390 for ; Wed, 26 Feb 2003 16:04:13 -0500 (EST) Received: from mr5.exu.ericsson.se (mr5u3.ericy.com [208.237.135.124]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id h1QL7Sd29000; Wed, 26 Feb 2003 15:07:28 -0600 (CST) Received: from eamrcnt761.exu.ericsson.se (eamrcnt761.exu.ericsson.se [138.85.133.39]) by mr5.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id h1QL7SC12932; Wed, 26 Feb 2003 15:07:28 -0600 (CST) Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2656.59) id ; Wed, 26 Feb 2003 15:07:28 -0600 Message-ID: From: "Bernie Volz (EUD)" To: "'Kim Kinnear'" , Ted Lemon Cc: dhcwg@ietf.org, Ralph Droms , Thomas Narten Subject: RE: [dhcwg] Leasequery: should it be standardized? Date: Wed, 26 Feb 2003 15:05:48 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2DDDA.BE655F1E" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2DDDA.BE655F1E Content-Type: text/plain; charset="iso-8859-1" And, ARP refreshes only work if the two devices (access + client) are on the same physical network segment. That's I think one other reason ARP isn't a good solution for this. - Bernie -----Original Message----- From: Kim Kinnear [mailto:kkinnear@cisco.com] Sent: Wednesday, February 26, 2003 3:59 PM To: Ted Lemon; Kim Kinnear Cc: dhcwg@ietf.org; Ralph Droms; Thomas Narten Subject: Re: [dhcwg] Leasequery: should it be standardized? At 03:30 PM 2/26/2003, Ted Lemon wrote: >>If you believe that there is any value in standardizing the >>leasequery capability, please at least respond to this list ASAP >>with your positive support. > >Yes, DHCPLEASEQUERY is a good thing, and I support it. I don't know how to address Thomas' complaints about its relevance to the WG charter - perhaps it should be advanced in some other WG, or independent of a WG - but it's certainly a good idea, and certainly whether or not there is some other WG in which it need also be discussed, it was highly appropriate to raise it here, since it is an extension to DHCP, and this is where the DHCP expertise is concentrated. Thanks. Of course I agree, or I would never have bothered to spend time on it. >My recollection, though, was that back in the beginning of all this, DHCPLEASEQUERY was about providing a way to refresh the ARP cache of a concentrator without having to broadcast an ARP request to every one of the concentrator's ports. Is that no longer the case? Strangely, that was never actually the reason that I thought we were doing leasequery. ARP is mentioned in the draft as an inadequate solution to recovering IP address <-> MAC address relationships originally discovered by DHCP "gleaning". Perhaps that is synonymous with refreshing the ARP cache. Certainly that involves the same information, but perhaps the use to which an ARP cache is put is not the same as the use to which the IP address <-> MAC address relationships discovered from DHCP gleaning is to be put. Cheers -- Kim _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg ------_=_NextPart_001_01C2DDDA.BE655F1E Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] Leasequery: should it be standardized?

And, ARP refreshes only work if the two devices = (access + client) are on the
same physical network segment. That's I think one = other reason ARP isn't a good
solution for this.

- Bernie

-----Original Message-----
From: Kim Kinnear [mailto:kkinnear@cisco.com]=
Sent: Wednesday, February 26, 2003 3:59 PM
To: Ted Lemon; Kim Kinnear
Cc: dhcwg@ietf.org; Ralph Droms; Thomas = Narten
Subject: Re: [dhcwg] Leasequery: should it be = standardized?


At 03:30 PM 2/26/2003, Ted Lemon wrote:
>>If you believe that there is any value in = standardizing the
>>leasequery capability, please at least = respond to this list ASAP
>>with your positive support.
>
>Yes, DHCPLEASEQUERY is a good thing, and I = support it.   I don't know how to address Thomas' complaints = about its relevance to the WG charter - perhaps it should be advanced = in some other WG, or independent of a WG - but it's certainly a good = idea, and certainly whether or not there is some other WG in which it = need also be discussed, it was highly appropriate to raise it here, = since it is an extension to DHCP, and this is where the DHCP expertise = is concentrated.

        = Thanks.  Of course I agree, or I would never    =
        have = bothered to spend time on it.


>My recollection, though, was that back in the = beginning of all this, DHCPLEASEQUERY was about providing a way to = refresh the ARP cache of a concentrator without having to broadcast an = ARP request to every one of the concentrator's ports.   Is = that no longer the case?

        Strangely, = that was never actually the reason that I
        thought = we were doing leasequery.  ARP is mentioned in
        the draft = as an inadequate solution to recovering IP
        address = <-> MAC address relationships originally
        = discovered by DHCP "gleaning".  Perhaps that is
        = synonymous with refreshing the ARP cache.  Certainly that
        involves = the same information, but perhaps the use to
        which an = ARP cache is put is not the same as the use to
        which the = IP address <-> MAC address relationships
        = discovered from DHCP gleaning is to be put.

        Cheers -- = Kim



_______________________________________________=
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg

------_=_NextPart_001_01C2DDDA.BE655F1E-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Feb 26 16:50:45 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24893; Wed, 26 Feb 2003 15:56:52 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QL6Pp09936; Wed, 26 Feb 2003 16:06:25 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QL5jp09874 for ; Wed, 26 Feb 2003 16:05:45 -0500 Received: from rtp-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24837 for ; Wed, 26 Feb 2003 15:55:35 -0500 (EST) Received: from goblet.cisco.com (IDENT:mirapoint@goblet.cisco.com [161.44.168.80]) by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h1QKxRNh005555; Wed, 26 Feb 2003 15:59:27 -0500 (EST) Received: from KKINNEAR-W2K.cisco.com (dhcp-161-44-149-161.cisco.com [161.44.149.161]) by goblet.cisco.com (Mirapoint) with ESMTP id ACR72329; Wed, 26 Feb 2003 15:59:25 -0500 (EST) Message-Id: <4.3.2.7.2.20030226155456.02267f08@goblet.cisco.com> X-Sender: kkinnear@goblet.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 26 Feb 2003 15:59:24 -0500 To: Ted Lemon , Kim Kinnear From: Kim Kinnear Subject: Re: [dhcwg] Leasequery: should it be standardized? Cc: dhcwg@ietf.org, Ralph Droms , Thomas Narten In-Reply-To: <32706BFC-49C9-11D7-AF3B-00039367340A@nominum.com> References: <4.3.2.7.2.20030226120723.025d5628@goblet.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , At 03:30 PM 2/26/2003, Ted Lemon wrote: >>If you believe that there is any value in standardizing the >>leasequery capability, please at least respond to this list ASAP >>with your positive support. > >Yes, DHCPLEASEQUERY is a good thing, and I support it. I don't know how to address Thomas' complaints about its relevance to the WG charter - perhaps it should be advanced in some other WG, or independent of a WG - but it's certainly a good idea, and certainly whether or not there is some other WG in which it need also be discussed, it was highly appropriate to raise it here, since it is an extension to DHCP, and this is where the DHCP expertise is concentrated. Thanks. Of course I agree, or I would never have bothered to spend time on it. >My recollection, though, was that back in the beginning of all this, DHCPLEASEQUERY was about providing a way to refresh the ARP cache of a concentrator without having to broadcast an ARP request to every one of the concentrator's ports. Is that no longer the case? Strangely, that was never actually the reason that I thought we were doing leasequery. ARP is mentioned in the draft as an inadequate solution to recovering IP address <-> MAC address relationships originally discovered by DHCP "gleaning". Perhaps that is synonymous with refreshing the ARP cache. Certainly that involves the same information, but perhaps the use to which an ARP cache is put is not the same as the use to which the IP address <-> MAC address relationships discovered from DHCP gleaning is to be put. Cheers -- Kim _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Feb 26 17:16:10 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28975; Wed, 26 Feb 2003 17:16:10 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QMPip16414; Wed, 26 Feb 2003 17:25:45 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QMODp16369 for ; Wed, 26 Feb 2003 17:24:13 -0500 Received: from rtp-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28925 for ; Wed, 26 Feb 2003 17:14:00 -0500 (EST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h1QMHsJR012893; Wed, 26 Feb 2003 17:17:54 -0500 (EST) Received: from paduffy-w2k.cisco.com (dhcp-161-44-149-94.cisco.com [161.44.149.94]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id RAA18073; Wed, 26 Feb 2003 17:17:53 -0500 (EST) Message-Id: <4.3.2.7.2.20030226170700.023e6bd8@funnel.cisco.com> X-Sender: paduffy@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 26 Feb 2003 17:17:13 -0500 To: dhcwg@ietf.org From: Paul Duffy Subject: Re: [dhcwg] Comments on draft-ietf-dhc-pktc-kerb-tckt-00.txt Cc: Sam Hartman , Ken Raeburn Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Thanks for the careful read Sam/Ken...inline please... At 04:06 PM 2/21/2003 -0500, you wrote: >Hi. I'm not subscribed to the list, so please copy me on responses. >I'm sending these comments because a review of the option from a >Kerberos viewpoint was requested. > >First, I do not believe this document is an appropriate work item of >the IETF for the following reasons. I do not think it likely there >will ever be multiple implementations of the standard, so I do not >think it likely that the the standard will meet criteria for >advancement. The standard seems focused on a specific deployment >situation and in fact on a specific category of tightly specified >devices and has insufficient generic applicability to devices outside >that specific environment to be an Internet standard. I understand >these devices are being deployed on the open Internet. However it is >not necessary for the IETF to specify all protocols that are used over >the Internet. I realize this concern applies equally to the base >packetcable configuration option and as such will probably be >discarded. Objection noted, but the DHC WG and the IESG have already decided that it is appropriate for CableLabs to seek RFC status for its DHCP needs. Given that DHCP option 122 has been IESG approved, I do not see why it is any more/less appropriate to discuss this sub-option than any of the sub-options currently contained in DHCP option 122. See http://www.ietf.org/internet-drafts/draft-ietf-dhc-packetcable-06.txt Regarding your comment re: lack of "multiple implementations"...there are currently several dozen manufacturers that implement the PacketCable provisioning, security, signalling, etc, protocols. >The second reason this document seems poorly scoped for the IETF is >that while based on Kerberos, the authentication technology discussed >is not in fact Kerberos. The Packetcable group needed a standard and >could not wait for the Kerberos working group to conclude and publish >a document. As such they adopted a draft that is incompatible both >with RFC 1510 and with current drafts within the Kerberos working >group. Fields are added to protocol messages in a manner that does >cause implementations of RFC 1510 to reject the messages and will >interfere with future expansion of the protocol. The mandatory to use >encryption systems for Packetcable Kerberos are not even specified in >the IETF drafts or published RFCs. The Kerberos working group has >decided not to standardize the encryption systems that Packetcable >uses in part because the encryption systems that are being >standardized are significantly stronger. It may be possible to >implement a system that supports both Packetcable Kerberos and IETF >Kerberos--I know one vendor who is trying to do that. For many reasons (some of which you point out above...time being THE biggest, we need to get a product to market), PacketCable does not strictly adhere to RFC 1510. It is my hope that we can avoid expanding this discussion into a full-blown, fine-tooth-combing of the PacketCable Security architecture...this would take far too long. The simple intent of this draft, in context of the PacketCable Security architecture, is to give the service provider a mechanism to force ticket expiration on a remote device. The need to expire the ticket is independent from the specific flavor/variant of Kerberos employed. I sense that your main objection to this draft is that it implies that PacketCable Security is not 100% RFC 1510 compliant. Will one or two lines clarifying this, along with a ref to the PacketCable Security spec, suffice? >However it seems that the IETF should not spend time standardizing a >DHCP sub option for controlling an authentication system outside of the >scope of the IETF for use in a limited environment. Disagree...same reasoning as my first point. >If the IETF decides that this work is within our scope, a note needs >to be added to the draft clarifying the Kerberos compatibility issue. >A pointer to the Packetcable Kerberos specification should be added >along with a note that this specification is incompatible with current >RFC 1510 implementations and with ongoing working in the IETF. Something along the line of... "Note that the PacketCable Security Specification differs from RFC 1510, see [ref] for full technical details of PacketCable's Kerberos implementation". >The rationale for this draft claims that it will be used among other >reasons to cancel subscriber service. The presence of a Kerberos >ticket should not be used to imply authorization to use a service; >this is incompatible both with RFC 1510 and with current Kerberos >drafts. Even if the authorization data field is used to convey >authorization along with authentication, service tickets with should >not be issued with lifetimes longer than are acceptable. I.E. you >should only issue a ticket with a lifetime as long as you are willing >to have authorization cached. > >I believe that this problem should be fixed by removing the text >proposing that using this option is appropriate to notify a device >that service has been canceled and adding a requirement that the >security of the deployment MUST NOT depend on this option being >honored. The option if it exists should serve to invalidate caches to >deal with operational problems such as emergency rekeying of services >or testing, and the only effect of failing to honor this option should >be a temporary loss of service. Agreed. Service authorization is a bogus/incorrect argument. The text... "The service provider requires this capability to support operational functions such as disabling a subscriber's service, forcing re- establishment of security associations, or for testing and remote diagnostic of CCDs. " ...needs to be changed to something like... "The service provider requires this capability to support operational functions such as forcing re-establishment of security associations or for testing and remote diagnostic of CCDs. " >The format of this option is insufficiently extensible. Many of the >sixteen code points for available services have already been used and >experiences shows new Kerberos services tend to be deployed over time. 2 of 16 bits == many ? The PacketCable provisioning team collectively came up with the 16 bit field and feels this is sufficient for the foreseeable future. If we run out of bits, we can always extend into another sub-option. >Why would you want to selectively invalidate some but not all tickets? >If this option exists, it seems like providing a mechanism to >completely invalidate the cache should be sufficient. I share Kens concerns re: forcing all tickets to expire. Public key ops are expensive and we try to avoid them when possible (for scaling reasons, avalanche restart conditions, etc.). >Finally security considerations need to discuss the disadvantages of >storing persistent Kerberos tickets. Other deployments of Kerberos >are moving away from doing this and instead storing tickets in >volatile memory. It would be excellent if the write up of this issue >in the security considerations section gave numbers to justify the >need for persistent tickets, although requiring this would be >excessive. A couple of points here... It is my feeling that the security considerations section should specifically address the contents/functionality of this specific sub-option. An expanded general discussion re: pro/con of storing tickets is beyond what is needed here. That said, the PacketCable Security spec recommends specific ticket lifetime limits that are driven by the encryption algorithm selection. Per previous option 122 discussions, all agreed that the Cablelab's drafts should not be duplicating the PacketCable specifications. >--Sam Ken's point re: the verb "persist" is noted. I'll change the text. Cheers, >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www1.ietf.org/mailman/listinfo/dhcwg -- Paul Duffy Cisco Systems, Inc. paduffy@cisco.com _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Feb 26 17:23:50 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29690; Wed, 26 Feb 2003 17:23:50 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QMXJp16930; Wed, 26 Feb 2003 17:33:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QMWmp16870 for ; Wed, 26 Feb 2003 17:32:48 -0500 Received: from toccata.fugue.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29630 for ; Wed, 26 Feb 2003 17:22:35 -0500 (EST) Received: from nominum.com (dsl093-187-232.chi2.dsl.speakeasy.net [66.93.187.232]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id h1QMNcJ19485 for ; Wed, 26 Feb 2003 16:23:38 -0600 (CST) Date: Wed, 26 Feb 2003 16:26:29 -0600 Subject: Re: [dhcwg] Leasequery: should it be standardized? Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) From: Ted Lemon To: dhcwg@ietf.org Content-Transfer-Encoding: 7bit In-Reply-To: Message-Id: <59ABE704-49D9-11D7-AF3B-00039367340A@nominum.com> X-Mailer: Apple Mail (2.551) Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > And, ARP refreshes only work if the two devices (access + client) are > on the > same physical network segment. That's I think one other reason ARP > isn't a good > solution for this. The other thing that I recall, that I left out of my original message, is that it can be handy for concentrators to have access to the relay agent information option associated with a particular IP address, so that they can know on which circuit to send a packet to that client, again without checking all the circuits to see to which circuit the client is connected. Thomas, I don't know how you'd solve this problem without DHCP. As we get away from DHCP to access control, I agree that it could be a problem, but the basic function of this draft isn't access control - it's querying the DHCP server. I don't know why there's even a reason to mention access control in the problem statement. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Feb 26 17:35:43 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29983; Wed, 26 Feb 2003 17:35:43 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QMjEp18170; Wed, 26 Feb 2003 17:45:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QMiUp18126 for ; Wed, 26 Feb 2003 17:44:30 -0500 Received: from sj-msg-core-3.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29962 for ; Wed, 26 Feb 2003 17:34:15 -0500 (EST) Received: from mjs-w2k01.cisco.com (dhcp-161-44-149-90.cisco.com [161.44.149.90]) by sj-msg-core-3.cisco.com (8.12.2/8.12.6) with ESMTP id h1QMbsP8007596; Wed, 26 Feb 2003 14:37:54 -0800 (PST) Message-Id: <4.3.2.7.2.20030226171308.01dd94b8@goblet.cisco.com> X-Sender: mjs@goblet.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 26 Feb 2003 17:38:05 -0500 To: Thomas Narten From: Mark Stapp Subject: RE: [dhcwg] Leasequery: should it be standardized? Cc: "Bernie Volz (EUD)" , "'Kevin A. Noll'" , Kim Kinnear , dhcwg@ietf.org, Ralph Droms In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , I agree with Bernie and Kevin. I particularly liked the 'data-centric' words in Kevin's post. DHCP servers tend to know information about DHCP clients and IP addresses, they're the sole authority for that information, and that information may be useful to other applications or entities on the network. Copying the information into some other database may be possible in some cases. Or some devices may be able to watch all DHCP traffic and build up their own copies of the data that the DHCP servers know. Or SNMP may eventually be available both at the servers and at the queriers. But lease-query is sort of an application-level INFORM, I think: it's the lowest common denominator way to ask about this useful data. The senders of the queries aren't necessarily looking for DHCP address leases, but they are looking for information that the DHCP servers know, and the senders already know how to read and write DHCP packets. Lease-query isn't policy - it's not 'enforcement', it's not 'admission control', and it doesn't require that the servers or the queriers be able to do those things. It's a protocol: it defines bits on the wire. There are multiple interoperating implementations in multiple OSs and devices. There's been enough interest in it to draw competing vendors to invest resources in implementing it. There's been enough interest in it that the initial implementors were asked in ietf meetings to bring it into the working group and advance it there. There's no question that DHCP servers know some interesting things, and that other processes might use what they know to make sophisticated decisions or be more robust or provide other enhanced capabilities. I have the feeling that someone saw some 'policy' words in the 'problem statement'. The solution to that might be to remove those words, and talk only about making data that the DHCP server possesses available through a DHCP message. That is something worth doing, and something that is reasonably done within this working group. -- Mark At 03:03 PM 2/26/2003 -0600, Bernie Volz (EUD) wrote: >Kim/Kevin: > >I agree with Kevin's statements. I too think it is important that this is >standardize by the IETF (which WG is less critical, though DHC WG seems >like a good home to me because it is after all DHCP). > >I agree with Kevin's point about there needing to be some standard >means to query the DHCP server's database about clients. > >For example, this might also be used by routers or other devices on the >network to handle admission control. The first packet for an IP address >that is not in the router's OK list (or hasn't been checked in a while) >could be confirmed (IP + MAC) via leasequery. > >There are also other uses of this, for example for network monitoring. >Perhaps there are other ways this problem could be solved, for example >by finishing up an SNMP MIB for DHCP that allows this kind of information >to be obtained. But, that road has been tried and has not been finalized. > >And, finally there are probably future uses of this kind of capability >that we've never would have thought about. So, setting up something that >is more flexible and powerful than just solving a very small and specific >problem is, IMHO, the IETF way. > >Perhaps a fix is to state that the original problem statement was blah, >blah, blah, and leasequery meets those needs, plus more. > >- Bernie Volz > >-----Original Message----- >From: Kevin A. Noll >[mailto:kevin.noll@perfectorder.com] >Sent: Wednesday, February 26, 2003 3:17 PM >To: Kim Kinnear; dhcwg@ietf.org >Cc: Ralph Droms; Thomas Narten >Subject: RE: [dhcwg] Leasequery: should it be standardized? > > >Kim, > >At the risk of sounding foolish since I'm not an active >participant in the WG... > >I think there is a need to standardize leasequery. > >It seems to me that the problem statement is the real issue. > >LeaseQuery should not be positioned in any way as an access >control mechanism or *necessarily* involved in such, especially >since there are other uses for this information. > >Leasequery is just what the name implies - a *standard* method for >external entities (whether they be routers or some other system) >to query the DHCP server for lease information. > >As it is today, there is no *standard* backend DHCP database that >can be queried. Some use text files, some use LDAP, some use proprietary >databases, etc. Therefore, the ability to query a DHCP server for >lease information does not exist except through proprietary methods. > >This limits interoperability of the various vendors systems. For example, >there is no way for vendor X to query vendor Y's DHCP server unless >they cooperate outside the standards bodies. > >This functionality is not limited to routers (or other devices) >using the information for access control. There are cases (not >necessarily well documented) where systems external to the DHCP >server need to find out about a lease for network management or >troubleshooting reasons. > >One example is a helpdesk staffer trying to find out whether a >device is up or down, but only knows the MAC address of the device. >How does he/she find out the IP? > >Okay, DNS could be consulted, but it isn't authoritative for information >regarding MAC-to-IP mapping, only NAME-to-IP mapping. There have been >various schemes to store this information in DNS (e.g. the NAME is easily >derived given the MAC, etc), but there are all kinds of issues that arise >with this solution (what if we don't *want* that information in DNS, etc.) > >The stable storage statements in the current problem statement aren't >necessarily relevant, either. > >My suggestion is that the problem statement be centered around making the >DHCP server the *authority* for lease information. > >An alternative would be to write a new draft (maybe not within this WG) that >would define a way to make some existing network database (probably DNS) >authoritative for this information. > >I think we could come up with a better problem statement that >would get your leasequery draft further down the road. > >Anyway, that's my 2 cents worth. > >--kan-- >-- >Kevin A. Noll, KD4WOZ Kevin.Noll@perfectorder.com >CCIE,CCDP >Perfect Order, Inc. 717-796-1936 > > >-----Original Message----- >From: dhcwg-admin@ietf.org >[mailto:dhcwg-admin@ietf.org]On Behalf Of Kim >Kinnear >Sent: Wednesday, 26 February, 2003 12:37 PM >To: dhcwg@ietf.org >Cc: Ralph Droms; Thomas Narten; Kim Kinnear >Subject: [dhcwg] Leasequery: should it be standardized? > > >Folks, > >We have come to something of a impasse on the leasequery draft, >and I need *your* support if you believe we should continue to >pursue this draft. > >=============================================================== >Without considerable support from the DHC WG, we will halt work >on the leasequery draft and all attempts to bring this work to >standard status. >=============================================================== > >If you believe that there is any value in standardizing the >leasequery capability, please at least respond to this list ASAP >with your positive support. > >If you have the time and expertise, please read the rest of this >email and see if you can offer cogent arguments as to why this is >work that the DHC working group should be pursuing. > >If we don't standardize the leasequery capability, each vendor of >access concentrators and DHCP products that wish to use this >approach will then need to work together (possibly in some other >forum) to try to get their products to be compatible. Of course, >it may well be that we are the only folks who see this as a >useful capability, and so that may not be an issue at all. > >Thanks -- Kim > >----------------------- Summary ----------------------- > >In case you haven't been following the email between Thomas >Narten and myself, he has been questioning the problem statement >of the leasequery draft. Ralph proposed a new problem statement, >but Thomas feels that this whole capability is questionable. > >You are invited to respond to Thomas' arguments, which I have >distilled as follows: > > 1. Doing anything in the DHC WG like supporting "access > control in router type devices" is out of scope for the working > group, and doesn't fit its current charter. > > 2. Access control in router type devices is not well enough > understood to be sure that: > > a) leasequery is the right solution. > > b) any DHC-based approach is the "right" approach to > solve this problem. > > 3. Until we are sure of 2(a), then we should not proceed with > this work (I believe that this statement is implicit in Thomas' > comments.) > >----------------------- Background --------------------------- > >Here is Ralph's proposed problem statement: > > Router-type devices which want to enforce some level of access > control over which IP addresses are allowed on their links > need to maintain information concerning IP<-MAC/client-id > mappings. One way in which these devices can obtain > information about IP<-MAC/client-id bindings is through "DHCP > gleaning", in which the device extracts useful information > from DHCP messages exchanged between hosts and DHCP servers. > > However, these devices don't typically have stable storage > sufficient to keep this information over reloads. There may > be additional information that is useful to the device that > cannot be obtained through DHCP gleaning. The leasequery > request message described in this document allows a device to > obtain information about IP<-MAC/client-id bindings from a > DHCP server. This information may include currently active > bindings, bindings involving previously assigned addresses for > which the lease on the address has expired and static bindings > for devices that are otherwise configured and not using DHCP > for address assignment. > >Thomas' concerns center on the second paragraph above, and he says: > > Note, that above is pretty vague and doesn't say what > information the access device needs. It's hard to look at the > problem statement and say "yes, I understand the boundaries of > the problem" and then "and the solution seems like a good > match for the problem". > > Popping up a level, how is it even appropriate for the DHC WG > to be doing work on "access control in router type devices"? > One can argue that work of this broad a scope is well > out-of-scope for this WG (e.g., look at the recently approved > charter). I'm far from clear that work of this scope should > be done in DHC or that the problem is well enough understood > to conclude that DHC lease query is the right solution or that > any DHC-based solution is the right one. What about routers > wanting to do access control that don't use DHC, for instance? > > And note, I'm not raising these issue just to be a PITA. These > are questions that I expect that the IESG would ask if I > brought the document forward. Thus, I need to have reasonable > responses to those questions. Otherwise, I can predict the > likely outcome. > >My response to Thomas was: > > This approach to access control was developed by joint work > with the folks building our access concentrators and several > of us in the DHCP implementation group. They found that the > functionality delivered to actual users was of sufficient > value to those users to be worth the cost of engineering this > particular solution. We supported them in moving the > implementation forward. > > The solution was not based on the charter of the DHC working > group either then or now -- it was based on a rather pragmatic > approach to meeting the needs of users, which it has seemed to > do. In my view at least, it fits within spirit of the DHC WG > activities, and was a logical extension of the those > activities. > > It isn't a comprehensive approach to any sort of security (nor > was it designed to be such) -- it is a supporting piece of > technology to one limited form of access control. > >Thanks for your interest in the leasequery capability. > >Kim > >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www1.ietf.org/mailman/listinfo/dhcwg > > > >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www1.ietf.org/mailman/listinfo/dhcwg > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Feb 26 17:42:27 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00237; Wed, 26 Feb 2003 17:42:27 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QMq6p18482; Wed, 26 Feb 2003 17:52:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QMpTp18419 for ; Wed, 26 Feb 2003 17:51:29 -0500 Received: from rtp-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00185 for ; Wed, 26 Feb 2003 17:41:15 -0500 (EST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h1QMj9Nh023700; Wed, 26 Feb 2003 17:45:10 -0500 (EST) Received: from paduffy-w2k.cisco.com (dhcp-161-44-149-94.cisco.com [161.44.149.94]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id RAA20122; Wed, 26 Feb 2003 17:45:09 -0500 (EST) Message-Id: <4.3.2.7.2.20030226173835.025fe120@funnel.cisco.com> X-Sender: paduffy@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 26 Feb 2003 17:45:10 -0500 To: dhcwg@ietf.org From: Paul Duffy Subject: Re: [dhcwg] draft-ietf-dhc-pktc-kerb-tckt-00.txt Cc: Sam Hartman , Ken Raeburn Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Draft needs a change... Section 4. Old text... "A bit value of 0 means the CCD MUST NOT invalidate the locally persisted ticket for the server/server group. A bit value of 1 means the CCD MUST invalidate the locally persisted ticket for the server/server group." New text... "A bit value of 0 means the CCD MUST apply normal invalidation rules (defined in [X]) to the locally persisted ticket for the server/server group. A bit value of 1 means the CCD MUST immediately invalidate the locally persisted ticket for the server/server group." X will be a normative reference to the PacketCable Security Specification. Cheers, -- Paul Duffy Cisco Systems, Inc. paduffy@cisco.com _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Feb 26 19:24:09 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03755; Wed, 26 Feb 2003 19:24:09 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1R0Xgp24454; Wed, 26 Feb 2003 19:33:42 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1R0Wdp24392 for ; Wed, 26 Feb 2003 19:32:39 -0500 Received: from sj-msg-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03740 for ; Wed, 26 Feb 2003 19:22:23 -0500 (EST) Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by sj-msg-core-2.cisco.com (8.12.2/8.12.6) with ESMTP id h1R0PwHK025885; Wed, 26 Feb 2003 16:25:59 -0800 (PST) Received: (from otroan@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id AAA26668; Thu, 27 Feb 2003 00:26:16 GMT X-Authentication-Warning: mrwint.cisco.com: otroan set sender to ot@cisco.com using -f To: Pekka Savola Cc: Ralph Droms , , From: Ole Troan Date: Thu, 27 Feb 2003 00:26:16 +0000 In-Reply-To: (Pekka Savola's message of "Wed, 26 Feb 2003 08:33:55 +0200 (EET)") Message-ID: <7t5znoiwouv.fsf@mrwint.cisco.com> User-Agent: Gnus/5.090011 (Oort Gnus v0.11) Emacs/21.2.95 (sparc-sun-solaris2.8) References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [dhcwg] Re: WG last call on draft-ietf-dhc-dhcpv6-opt-prefix-delegation-02.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Pekka, >> > 2) Multiple IA_PD looks unnecessarily complex. Are there any valid >> > reasons why it wouldn't be just enough to have only one IA_PD per >> > requesting router? (The option to and subsequent complexity of) >> > generating one for each interface seems like a completely unnecessary >> > feature to me -- it's the router which should be doing prefix delegation >> > to it's downstream interfaces! >> >> let me pick this one up from the start. >> the reasons for allowing multiple IA_PDs are: >> >> - consistency with address assignment as you can use multiple IA_NAs >> - future-proofing. in the ISP/user scenario I do see little need for >> multiple IA_PDs. if PD is used within an administrative domain >> assigning prefixes to downstream interfaces may make more sense > > My take on this is is that "we don't need that yet, so why add it yet"; > leaving the "base prefix delegation spec" extendable (e.g. define multiple > IA_PD's in a later document) would be just fine. > >> it does add some complexity, and I think we've made it pretty clear in >> the draft that the typical usage will be to use one IA_PD. we just >> didn't want to close the door on possible future uses of the protocol. > > IMO, it wasn't as clear as that. > > I can live with this, but I can't help wondering why the base spec has to > cover even all the theoretical cases. I'd much rather see a very simple > basic version of prefix delegation which can be used to get started. > There's no way we could anticipate what will be needed in 3-5 years and we > could further define the extensions when they're needed. well, I have to disagree with you there. keeping PD consistent with other DHCP options makes for an easier understanding of how it works and for a simpler implementation. the fundamental idea behind using DHCP for PD is to re-use the existing DHCP infrastructure including option semantics. Distilled into one line: "Prefix Delegation with DHCP is done in exactly the same way as address assignment with DHCP is". /ot _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Feb 27 06:09:45 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25183; Thu, 27 Feb 2003 06:09:45 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RBJYp08412; Thu, 27 Feb 2003 06:19:34 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1R7gXp27491 for ; Thu, 27 Feb 2003 02:42:33 -0500 Received: from netcore.fi (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21598 for ; Thu, 27 Feb 2003 02:32:10 -0500 (EST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h1R7Zq610310; Thu, 27 Feb 2003 09:35:52 +0200 Date: Thu, 27 Feb 2003 09:35:52 +0200 (EET) From: Pekka Savola To: Ole Troan cc: Ralph Droms , , In-Reply-To: <7t5znoiwouv.fsf@mrwint.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [dhcwg] Re: WG last call on draft-ietf-dhc-dhcpv6-opt-prefix-delegation-02.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , On Thu, 27 Feb 2003, Ole Troan wrote: > > cover even all the theoretical cases. I'd much rather see a very simple > > basic version of prefix delegation which can be used to get started. > > There's no way we could anticipate what will be needed in 3-5 years and we > > could further define the extensions when they're needed. > > well, I have to disagree with you there. keeping PD consistent with > other DHCP options makes for an easier understanding of how it works > and for a simpler implementation. the fundamental idea behind using > DHCP for PD is to re-use the existing DHCP infrastructure including > option semantics. Distilled into one line: "Prefix Delegation with > DHCP is done in exactly the same way as address assignment with DHCP is". I can live with that. I hear many (two sets of groups) are implementing DHCPv6 either for: - configuration parameters - prefix delegation (for the lack of alternatives) If you don't want address assignment in DHCP, doing it the same way in PD may seem like a burden. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Feb 27 06:09:53 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25222; Thu, 27 Feb 2003 06:09:53 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RBJkp08432; Thu, 27 Feb 2003 06:19:46 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1R9scp03143 for ; Thu, 27 Feb 2003 04:54:38 -0500 Received: from raven.ecs.soton.ac.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23893 for ; Thu, 27 Feb 2003 04:44:11 -0500 (EST) Received: from pigeon.ecs.soton.ac.uk (ns1 [152.78.68.1]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id JAA07406; Thu, 27 Feb 2003 09:47:55 GMT Received: from login.ecs.soton.ac.uk (login [152.78.68.162]) by pigeon.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id JAA25517; Thu, 27 Feb 2003 09:47:55 GMT Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id h1R9ltw01797; Thu, 27 Feb 2003 09:47:55 GMT Date: Thu, 27 Feb 2003 09:47:54 +0000 From: Tim Chown To: Pekka Savola Cc: Ole Troan , Ralph Droms , dhcwg@ietf.org, ipng@sunroof.eng.sun.com Message-ID: <20030227094754.GB1648@login.ecs.soton.ac.uk> Mail-Followup-To: Pekka Savola , Ole Troan , Ralph Droms , dhcwg@ietf.org, ipng@sunroof.eng.sun.com References: <7t5znoiwouv.fsf@mrwint.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i Subject: [dhcwg] Re: WG last call on draft-ietf-dhc-dhcpv6-opt-prefix-delegation-02.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , On Thu, Feb 27, 2003 at 09:35:52AM +0200, Pekka Savola wrote: > > I hear many (two sets of groups) are implementing DHCPv6 either for: > - configuration parameters > - prefix delegation (for the lack of alternatives) I would just add a "flag wave" for 6NET's Deliverable D3.2.3 which reports on DHCPv6 implementations which may be of interest to people here [apologies if a pointer has already been posted - just dipping in :] Tim _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Feb 27 16:15:26 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24095; Thu, 27 Feb 2003 16:15:26 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RLPNp22306; Thu, 27 Feb 2003 16:25:23 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RLNgp22221 for ; Thu, 27 Feb 2003 16:23:42 -0500 Received: from c015.snv.cp.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA24050 for ; Thu, 27 Feb 2003 16:13:02 -0500 (EST) Received: (cpmta 8082 invoked from network); 27 Feb 2003 13:16:56 -0800 Received: from 4.36.57.222 (HELO STEVEPC) by smtp.relicore.com (209.228.35.127) with SMTP; 27 Feb 2003 13:16:56 -0800 X-Sent: 27 Feb 2003 21:16:56 GMT From: "Steve Gonczi" To: "Mark Stapp" Cc: Subject: RE: [dhcwg] Leasequery: should it be standardized? Date: Thu, 27 Feb 2003 16:16:03 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <4.3.2.7.2.20030226171308.01dd94b8@goblet.cisco.com> Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Greetings, You guys are clearly on to something here. I have just re-read the 04 draft. It proposes a solution to a rather specific problem. It would indeed make sense to generalize it into a more broadly applicable query protocol. Let's try bit more radical tack: It would be useful to add a list-query capability, so that the protocol could return lists of addresses, based on a flexible set of search criteria. E.g.: all assigned IP-s on subnet x. Also, the query could enumerate the pieces of information e desired.(e.g. expiration time, client id... whatever) The currently specified 04 draft would be a functional subset of the general purpose protocol. BTW.. I am surprised to see that the messaging formats is very much inspired by the DHCP/BOOTP message structure. Since this would be a brand new protocol, I fail to see the need to carry this baggage. Err.. why do we need to have the bootp header in the messages? I respectfully propose to lay out the protocol messages in a compact manner, fitted to the need of the query protocol itself. For all intensive purposes, the protocol could even be TCP based, similar to the failover protocol. If there is sufficient interest, I will be glad to provide some examples of "general purpose" query and response formats. /sG -----Original Message----- From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org]On Behalf Of Mark Stapp Sent: Wednesday, February 26, 2003 5:38 PM To: Thomas Narten Cc: Bernie Volz (EUD); 'Kevin A. Noll'; Kim Kinnear; dhcwg@ietf.org; Ralph Droms Subject: RE: [dhcwg] Leasequery: should it be standardized? > I agree with Bernie and Kevin. I particularly liked the 'data-centric' > words in Kevin's post. DHCP servers tend to know information about DHCP > clients and IP addresses, they're the sole authority for that information, > and that information may be useful to other applications or entities on the > network.... .....rest of the discussion clipped...... _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Feb 27 16:39:25 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25044; Thu, 27 Feb 2003 16:39:25 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RLnNp24231; Thu, 27 Feb 2003 16:49:23 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RLmRp24198 for ; Thu, 27 Feb 2003 16:48:27 -0500 Received: from sj-msg-core-3.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24985 for ; Thu, 27 Feb 2003 16:37:46 -0500 (EST) Received: from mjs-w2k01.cisco.com (dhcp-161-44-149-90.cisco.com [161.44.149.90]) by sj-msg-core-3.cisco.com (8.12.2/8.12.6) with ESMTP id h1RLfSP8009280; Thu, 27 Feb 2003 13:41:28 -0800 (PST) Message-Id: <4.3.2.7.2.20030227163310.01e32248@goblet.cisco.com> X-Sender: mjs@goblet.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 27 Feb 2003 16:41:10 -0500 To: "Steve Gonczi" From: Mark Stapp Subject: RE: [dhcwg] Leasequery: should it be standardized? Cc: In-Reply-To: References: <4.3.2.7.2.20030226171308.01dd94b8@goblet.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , I don't have much interest in a new, tcp-based, general-purpose query protocol. There was interest in a way for dhcp speakers to ask some questions, and that's what leasequery offers, and it's been implemented and deployed by several vendors. The point was that the questions be askable by devices and applications that already knew dhcp. -- Mark At 04:16 PM 2/27/2003 -0500, Steve Gonczi wrote: >Greetings, > >You guys are clearly on to something here. > >I have just re-read the 04 draft. It proposes a solution to a rather >specific problem. It would indeed make sense to generalize it into >a more broadly applicable query protocol. > >Let's try bit more radical tack: > >It would be useful to add a list-query capability, so that the >protocol could return lists of addresses, based on a flexible set of >search criteria. >E.g.: all assigned IP-s on subnet x. Also, the query could enumerate the >pieces of information e desired.(e.g. expiration time, client id... >whatever) > >The currently specified 04 draft would be a functional subset of the >general purpose protocol. > >BTW.. I am surprised to see that the messaging formats is >very much inspired by the DHCP/BOOTP message structure. > >Since this would be a brand new protocol, I fail to see the need to >carry this baggage. Err.. why do we need to have the bootp header in >the messages? > >I respectfully propose to lay out the protocol messages >in a compact manner, fitted to the need of the >query protocol itself. > >For all intensive purposes, the protocol could even be TCP based, >similar to the failover protocol. > >If there is sufficient interest, I will be glad to provide some >examples of "general purpose" query and response formats. > >/sG > > > >-----Original Message----- >From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org]On Behalf Of >Mark Stapp >Sent: Wednesday, February 26, 2003 5:38 PM >To: Thomas Narten >Cc: Bernie Volz (EUD); 'Kevin A. Noll'; Kim Kinnear; dhcwg@ietf.org; >Ralph Droms >Subject: RE: [dhcwg] Leasequery: should it be standardized? > > > > I agree with Bernie and Kevin. I particularly liked the 'data-centric' > > words in Kevin's post. DHCP servers tend to know information about DHCP > > clients and IP addresses, they're the sole authority for that information, > > and that information may be useful to other applications or entities on >the > > network.... > >.....rest of the discussion clipped...... > >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Feb 27 17:10:15 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25929; Thu, 27 Feb 2003 17:10:15 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RMKHp26545; Thu, 27 Feb 2003 17:20:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RMJkp26483 for ; Thu, 27 Feb 2003 17:19:46 -0500 Received: from imr2.ericy.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25905 for ; Thu, 27 Feb 2003 17:09:03 -0500 (EST) Received: from mr5.exu.ericsson.se (mr5att.ericy.com [138.85.224.141]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id h1RMCsb03765; Thu, 27 Feb 2003 16:12:54 -0600 (CST) Received: from eamrcnt760.exu.ericsson.se (eamrcnt760.exu.ericsson.se [138.85.133.38]) by mr5.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id h1RMCss27015; Thu, 27 Feb 2003 16:12:54 -0600 (CST) Received: by eamrcnt760.exu.ericsson.se with Internet Mail Service (5.5.2656.59) id ; Thu, 27 Feb 2003 16:12:53 -0600 Message-ID: From: "Bernie Volz (EUD)" To: "'Mark Stapp'" , Steve Gonczi Cc: dhcwg@ietf.org Subject: RE: [dhcwg] Leasequery: should it be standardized? Date: Thu, 27 Feb 2003 16:11:07 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2DEAC.F65BD5B0" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2DEAC.F65BD5B0 Content-Type: text/plain; charset="ISO-8859-1" I agree ... we don't want to restart this process. There's a lot of good reasons why DHCP should be used - it is after all DHCP information. The existing framework is fine regardless of whether the devices and applications already knew dhcp. - Bernie -----Original Message----- From: Mark Stapp [mailto:mjs@cisco.com] Sent: Thursday, February 27, 2003 4:41 PM To: Steve Gonczi Cc: dhcwg@ietf.org Subject: RE: [dhcwg] Leasequery: should it be standardized? I don't have much interest in a new, tcp-based, general-purpose query protocol. There was interest in a way for dhcp speakers to ask some questions, and that's what leasequery offers, and it's been implemented and deployed by several vendors. The point was that the questions be askable by devices and applications that already knew dhcp. -- Mark At 04:16 PM 2/27/2003 -0500, Steve Gonczi wrote: >Greetings, > >You guys are clearly on to something here. > >I have just re-read the 04 draft. It proposes a solution to a rather >specific problem. It would indeed make sense to generalize it into >a more broadly applicable query protocol. > >Let's try bit more radical tack: > >It would be useful to add a list-query capability, so that the >protocol could return lists of addresses, based on a flexible set of >search criteria. >E.g.: all assigned IP-s on subnet x. Also, the query could enumerate the >pieces of information e desired.(e.g. expiration time, client id... >whatever) > >The currently specified 04 draft would be a functional subset of the >general purpose protocol. > >BTW.. I am surprised to see that the messaging formats is >very much inspired by the DHCP/BOOTP message structure. > >Since this would be a brand new protocol, I fail to see the need to >carry this baggage. Err.. why do we need to have the bootp header in >the messages? > >I respectfully propose to lay out the protocol messages >in a compact manner, fitted to the need of the >query protocol itself. > >For all intensive purposes, the protocol could even be TCP based, >similar to the failover protocol. > >If there is sufficient interest, I will be glad to provide some >examples of "general purpose" query and response formats. > >/sG > > > >-----Original Message----- >From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org]On Behalf Of >Mark Stapp >Sent: Wednesday, February 26, 2003 5:38 PM >To: Thomas Narten >Cc: Bernie Volz (EUD); 'Kevin A. Noll'; Kim Kinnear; dhcwg@ietf.org; >Ralph Droms >Subject: RE: [dhcwg] Leasequery: should it be standardized? > > > > I agree with Bernie and Kevin. I particularly liked the 'data-centric' > > words in Kevin's post. DHCP servers tend to know information about DHCP > > clients and IP addresses, they're the sole authority for that information, > > and that information may be useful to other applications or entities on >the > > network.... > >.....rest of the discussion clipped...... > >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg ------_=_NextPart_001_01C2DEAC.F65BD5B0 Content-Type: text/html; charset="ISO-8859-1" RE: [dhcwg] Leasequery: should it be standardized?

I agree ... we don't want to restart this process. There's a lot of good
reasons why DHCP should be used - it is after all DHCP information. The
existing framework is fine regardless of whether the devices and
applications already knew dhcp.

- Bernie

-----Original Message-----
From: Mark Stapp [mailto:mjs@cisco.com]
Sent: Thursday, February 27, 2003 4:41 PM
To: Steve Gonczi
Cc: dhcwg@ietf.org
Subject: RE: [dhcwg] Leasequery: should it be standardized?


I don't have much interest in a new, tcp-based, general-purpose query
protocol. There was interest in a way for dhcp speakers to ask some
questions, and that's what leasequery offers, and it's been implemented and
deployed by several vendors. The point was that the questions be askable by
devices and applications that already knew dhcp.

-- Mark

At 04:16 PM 2/27/2003 -0500, Steve Gonczi wrote:
>Greetings,
>
>You guys are clearly on to something here.
>
>I have just re-read the 04 draft. It proposes a solution to a rather
>specific problem. It would indeed make sense to generalize it into
>a more broadly applicable query protocol.
>
>Let's try bit more radical tack:
>
>It would be useful to add a list-query capability, so that the
>protocol could return lists of addresses, based on a flexible set of
>search criteria.
>E.g.: all assigned IP-s on subnet x. Also, the query could enumerate the
>pieces of information e desired.(e.g. expiration time, client id...
>whatever)
>
>The currently specified 04 draft would be a functional subset of the
>general purpose protocol.
>
>BTW.. I am surprised to see that the messaging formats is
>very much inspired by the DHCP/BOOTP message structure.
>
>Since this would be a brand new protocol, I fail to see the need to
>carry this baggage. Err.. why do we need to have the bootp header in
>the messages?
>
>I respectfully propose to lay out the protocol messages
>in a compact manner, fitted to the need of the
>query protocol itself.
>
>For all intensive purposes, the protocol could even be TCP based,
>similar to the failover protocol.
>
>If there is sufficient interest, I will be glad to provide some
>examples of "general purpose" query and response formats.
>
>/sG
>
>
>
>-----Original Message-----
>From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org]On Behalf Of
>Mark Stapp
>Sent: Wednesday, February 26, 2003 5:38 PM
>To: Thomas Narten
>Cc: Bernie Volz (EUD); 'Kevin A. Noll'; Kim Kinnear; dhcwg@ietf.org;
>Ralph Droms
>Subject: RE: [dhcwg] Leasequery: should it be standardized?
>
>
> > I agree with Bernie and Kevin. I particularly liked the 'data-centric'
> > words in Kevin's post. DHCP servers tend to know information about DHCP
> > clients and IP addresses, they're the sole authority for that information,
> > and that information may be useful to other applications or entities on
>the
> > network....
>
>.....rest of the discussion clipped......
>
>_______________________________________________
>dhcwg mailing list
>dhcwg@ietf.org
>https://www1.ietf.org/mailman/listinfo/dhcwg

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg

------_=_NextPart_001_01C2DEAC.F65BD5B0-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Feb 27 18:29:32 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27610; Thu, 27 Feb 2003 18:29:32 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RNdVp31235; Thu, 27 Feb 2003 18:39:31 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RNclp31215 for ; Thu, 27 Feb 2003 18:38:47 -0500 Received: from fujitsu1a.fujitsu.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27588 for ; Thu, 27 Feb 2003 18:28:03 -0500 (EST) Received: from fujitsu1a.fujitsu.com (localhost [127.0.0.1]) by fujitsu1a.fujitsu.com (8.11.4/8.11.4) with ESMTP id h1RNZ2u24130 for ; Thu, 27 Feb 2003 15:35:02 -0800 (PST) Received: from fujitsui.fna.fujitsu.com (fujitsui [133.164.253.1]) by fujitsu1a.fujitsu.com (8.11.4/8.11.4) with ESMTP id h1RNZ1u24111 for ; Thu, 27 Feb 2003 15:35:02 -0800 (PST) Received: from fujitsui.fna.fujitsu.com (localhost [127.0.0.1]) by fujitsui.fna.fujitsu.com (8.11.4/8.11.4) with ESMTP id h1RNVv510863 for ; Thu, 27 Feb 2003 15:31:57 -0800 (PST) Received: from otter (otter [133.164.11.6]) by fujitsui.fna.fujitsu.com (8.11.4/8.11.4) with ESMTP id h1RNVur10859 for ; Thu, 27 Feb 2003 15:31:57 -0800 (PST) From: "YiTing Liu" To: Date: Thu, 27 Feb 2003 15:33:40 -0800 Organization: Fujitsu America, Inc. Message-ID: <010c01c2deb8$a8d9ccf0$060ba485@otter> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_010D_01C2DE75.9AB68CF0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: [dhcwg] (no subject) Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_010D_01C2DE75.9AB68CF0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit unsubscribe ------=_NextPart_000_010D_01C2DE75.9AB68CF0 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

unsubscribe

 

------=_NextPart_000_010D_01C2DE75.9AB68CF0-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Feb 27 19:13:02 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28492; Thu, 27 Feb 2003 19:13:02 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1S0NAp00930; Thu, 27 Feb 2003 19:23:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1S0MRp00901 for ; Thu, 27 Feb 2003 19:22:27 -0500 Received: from smtp017.mail.yahoo.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA28480 for ; Thu, 27 Feb 2003 19:11:42 -0500 (EST) Received: from adsl-64-169-89-92.dsl.snfc21.pacbell.net (HELO BarrH63p601) (rbhibbs@pacbell.net@64.169.89.92 with login) by smtp.mail.vip.sc5.yahoo.com with SMTP; 28 Feb 2003 00:15:38 -0000 Reply-To: From: "Barr Hibbs" To: Subject: RE: [dhcwg] Leasequery: should it be standardized? Date: Thu, 27 Feb 2003 16:15:28 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <4.3.2.7.2.20030226120723.025d5628@goblet.cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Kim-- I agree that the proposed leasequery mechanism is of value for refreshing stateless devices such as access concentrators, relay agents, and others. I further agree that using the existing BOOTP packet layout as the framework for requesting and supplying information is appropriate. I do have a few nits with the draft, however. The position of the "R" bit flag needs to be identified, or at least, proposed. Selectively quoting from the -04 draft: 3. Background The focus of this document is to enable access concentrators to send DHCPLEASEQUERY messages to DHCP servers, to obtain location information of broadband access network devices. 5. Protocol Overview The access concentrator initiates all DHCPLEASEQUERY message conversations. 7. Security Considerations Access concentrators SHOULD minimize potential denial of service attacks on the DHCP servers by minimizing the generation of DHCPLEASEQUERY messages. These three excerpts suggest, but do not mandate, that a leasequery exchange is solely between the access concentrator and server. Two issues with this: (1) I have a mild objection to using the term "access concentrator" solely because that is not a component of the DHCP model environment, which consists of clients, servers, and relay agents. Since your proposed definition states that an access concentrator must contain relay agent functionality, why not just call it a relay agent? (2) There is no language prohibiting forwarding of leasequery messages from a downstream device, presumably because relay agents are often cascaded when constructing large networks. This suggests that dhcp clients or other network hosts may originate leasequery messages: a relay agent must forward the messages because there is no mechanism defined to prevent this. Hence, a potential Denial of Service attack, initiated by a rogue client or other rogue host. Note that I don't have any suggestions short of the use of DHCP Authentication to prevent this. A more general question arises with respect to the "R" flag. Why is it important to know if the IP to MAC or IP to Client Identifier mappings exist(ed) because of a reservation? If a reservation exists, but the server has not had a protocol exchange with the client, the server would respond with DHCPLEASEKNOWN, and if queried for the IP Address Lease Time, the server could respond with an all-ones entry (signifying infinite). I also contend that an unused reservation should not receive a DHCPLEASEACTIVE reply as that somewhat misstates the circumstances. For your information, Glenn and I will be submitting the -08 draft of the DHCPv4 server MIB prior to the San Francisco meeting. In the [hopefully final] draft there is a table defined, the dhcpv4ServerClientTable, that contains the IP address, last client request type and time of request, and the last server response type, indexed by the 3-tuple, 'hlen,' 'htype,' and 'chaddr.' There is a second table, the dhcpv4ServerAddressTable, that contains the lease type (static, dynamic, expired, reserved, unusable), allowed and served protocol, physical address, client identifier, host name, and domain name, indexed by the IP address. So, while this covers the same information (and more) as the proposed leasequery option, it is much less usable for lightweight inquiries. --Barr _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Feb 27 19:44:32 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28942; Thu, 27 Feb 2003 19:44:32 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1S0sUp02647; Thu, 27 Feb 2003 19:54:30 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1S0rTp02626 for ; Thu, 27 Feb 2003 19:53:29 -0500 Received: from sj-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28921 for ; Thu, 27 Feb 2003 19:42:43 -0500 (EST) Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by sj-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h1S0kc56017744; Thu, 27 Feb 2003 16:46:39 -0800 (PST) Received: (from otroan@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id AAA09304; Fri, 28 Feb 2003 00:46:37 GMT X-Authentication-Warning: mrwint.cisco.com: otroan set sender to ot@cisco.com using -f To: JINMEI Tatuya / =?iso-2022-jp?b?GyRCP0BMQEMjOkgbKEI=?= Cc: Ralph Droms , dhcwg@ietf.org, ipng@sunroof.eng.sun.com Subject: Re: [dhcwg] WG last call on draft-ietf-dhc-dhcpv6-opt-prefix-delegation-02.txt From: Ole Troan Date: Fri, 28 Feb 2003 00:46:37 +0000 In-Reply-To: (JINMEI Tatuya / =?iso-2022-jp?b?GyRCP0BMQEMjOkgbKEIncw==?= message of "Wed, 26 Feb 2003 16:55:12 +0900") Message-ID: <7t5r89tut8y.fsf@mrwint.cisco.com> User-Agent: Gnus/5.090011 (Oort Gnus v0.11) Emacs/21.2.95 (sparc-sun-solaris2.8) References: <4.3.2.7.2.20030220132513.00ba9a40@funnel.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Jinmei-san, thanks for your comments! answers inline. >> Please review draft-ietf-dhc-dhcpv6-opt-prefix-delegation-02.txt and >> reply with comments. If you recommend the document for advancement without >> revision, please respond with a quick acknowledgment. No response will be >> interpreted as a lack of support for advancing the document. > > I've finally reviewed the latest draft. As I said before, I basically > support the document. However, I don't think the current revision is > ready to be published. IMO, it is still incomplete and has not fully > addressed open issues. > > Detailed comments follow: > > 1. Issues about the preferred and valid lifetimes were not fully > addressed. I've not seen consensus on this in the dhc-wg ML. > Please re-check the thread entitled "PD lifetimes" that started on > Thu, 23 Jan 2003 19:18:57 +0900. what specifically are you referring to here? in my opinion we reached consensus that: - both preferred and valid lifetimes are needed - prefixes or addresses derived from the prefix MUST not be used beyond the valid lifetime - adding P and V bits to specify if a prefix advertised in an RA should use a fixed lifetime or a real time lifetime, is not needed as it does not seem to add value or solve any specific problem. > 2. Section 11.1 now specifies the requesting router to use > Rebind/Reply exchanges to verify an existing binding (instead of > Renew/Reply exchanges). According to the very recent > clarifications on the base DHCPv6 spec, however, I'm not sure if > Rebind is appropriate here; the server should drop the Rebind > message unless it has an explicit knowledge about the validity or > invalidity of the prefix, which should not be the case (e.g.) when > the upstream link flaps. Rebind now behaves just like Confirm. if by link flap you mean change of link to another delegating router, the delegating router can reply to a Rebind even without a binding if it knows through explicit configuration that the prefixes in the IA_PD is not valid for the link. > 3. Section 10.2 contains the following sentence (newly added in the > latest revision): > > If the delegating router cannot delegate any prefixes to an IA_PD in > the message from the requesting router, the delegating router MUST > include the IA_PD in the Reply message with no prefixes in the IA_PD > and a Status Code option in the IA_PD containing status code > NoPrefixAvail. > > I guess the "Reply" should be "Advertisement" here, because this > section is talking about "Delegating Router Solicitation." I also > guess the sentence was added in response to a question of mine in > the ML. If so, a similar clarification should be introduced to > Section 11.2 as well. Additionally, the corresponding client > behaviors should also be documented. yes, well spotted. > 4. The PD draft should reflect some parts of > draft-ietf-dhc-dhcpv6-interop-00.txt. With a quick look, Sections > 1, 2, 3, 4, 5, 6, 9, 10, and 11 should also apply to the PD draft. I have made the changes where appropriate, i.e where we already have cut and pasted text from the DHCPv6 base specification. > We may be able to omit some of them as trivial clarifications, but > we should reflect some other part of them because the base DHCPv6 > spec (and thus the clarifications for it) is too specific to > address assignment. In some cases, implementors can use analogy of > the base spec to implement the PD draft, but we should basically > provide comprehensive information in the PD draft itself to ensure > better interoperability. (As some people, including me, have > repeatedly pointed out, the best approach would be to make the base > spec generic so that each stateful method can just refer to the > base spec. Since we could not make it due to the "it's too late" > reason, we should be responsible to implementors for providing > detailed information within the PD specification). the PD specification is not meant to be complete and needs to be read in conjunction with the base DHCP specification. /ot _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Feb 28 10:46:53 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02294; Fri, 28 Feb 2003 10:46:53 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SFvCp05780; Fri, 28 Feb 2003 10:57:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SFtpp05686 for ; Fri, 28 Feb 2003 10:55:51 -0500 Received: from rtp-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02178 for ; Fri, 28 Feb 2003 10:44:49 -0500 (EST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h1SFmiNh007562 for ; Fri, 28 Feb 2003 10:48:44 -0500 (EST) Received: from rdroms-w2k.cisco.com (dhcp-161-44-149-251.cisco.com [161.44.149.251]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id KAA09227 for ; Fri, 28 Feb 2003 10:48:43 -0500 (EST) Message-Id: <4.3.2.7.2.20030228103812.00bb0590@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 28 Feb 2003 10:48:12 -0500 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [dhcwg] Recovery of unused DHCP option codes Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , I've published a document, draft-ietf-dhc-unused-optioncodes-00, that lists several opcodes that were assigned prior to the publication of RFC2489 (which was updated by RFC2939). For a variety of reasons, the options associated with these opcodes were never accepted as standards and published as RFCs. The publication of draft-ietf-dhc-unused-optioncodes-00 is the first step in the return of these opcodes to IANA for assignment to future DHCP options. Here's the plan: 1. Make an announcement on dhcwg asking for dhc WG review of the draft; explicitly ask for report of actual use of any options listed in the draft 2. Revise the draft in the form of an Informational RFC explicitly directing IANA to make the option codes listed in the draft available for assignment to new options in the future 3. Make an announcement to the IETF as a whole asking for review of the draft and report of any option known to be in use 4. Submit this document to the IESG for publication as an Informational RFC This announcement is step 1 from the list. Please review draft-ietf-dhc-unused-optioncodes-00 and respond to the dhc WG mailing list if you know of any of the options listed in the document that are in use, or if you have any other comments on the contents of the draft. We'll take a couple of minutes to discuss the draft and solicit input at the WG meeting in SF, as well. - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Feb 28 10:55:40 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02570; Fri, 28 Feb 2003 10:55:39 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SG66p06355; Fri, 28 Feb 2003 11:06:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SG5cp06295 for ; Fri, 28 Feb 2003 11:05:38 -0500 Received: from rtp-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02521 for ; Fri, 28 Feb 2003 10:54:36 -0500 (EST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h1SFwUNh008167 for ; Fri, 28 Feb 2003 10:58:31 -0500 (EST) Received: from rdroms-w2k.cisco.com (dhcp-161-44-149-251.cisco.com [161.44.149.251]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id KAA10525 for ; Fri, 28 Feb 2003 10:58:30 -0500 (EST) Message-Id: <4.3.2.7.2.20030228104908.00ba1da8@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 28 Feb 2003 10:58:29 -0500 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [dhcwg] Extending DHCP option codes Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Bernie, Ted and I have written a draft, draft-volz-dhc-extended-optioncodes-00.txt, which describes two methods for extending the list of option codes available for assignment to DHCP options. RFC2132 specifies that option codes 1-127 are available for assignment to DHCP options. The option most recently accepted as a standard, in draft-ietf-dhc-packetcable-06.txt, will likely be assigned option code 122. At the SF dhc WG meeting, we'll consider the requirements for extending the options codes and review the two methods described in draft-volz-dhc-extended-optioncodes-00.txt. Please review the draft prior to the WG meeting and respond to the mailing list if you have any comments. Note that some option codes < 122 (for example, 102-107) are currently available for assignment; see http://www.iana.org/assignments/bootp-dhcp-parameters for details. Also note that if all of the unused option codes listed in draft-ietf-dhc-unused-optioncodes-00.txt are returned to IANA, there will be approximately 25 options codes available for assignment to future DHCP option codes. - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Feb 28 11:10:39 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02917; Fri, 28 Feb 2003 11:10:39 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SGL8p07706; Fri, 28 Feb 2003 11:21:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SGKgp07687 for ; Fri, 28 Feb 2003 11:20:42 -0500 Received: from rtp-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02905 for ; Fri, 28 Feb 2003 11:09:39 -0500 (EST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h1SGDXJR017911; Fri, 28 Feb 2003 11:13:34 -0500 (EST) Received: from rdroms-w2k.cisco.com (dhcp-161-44-149-251.cisco.com [161.44.149.251]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id LAA12518; Fri, 28 Feb 2003 11:13:33 -0500 (EST) Message-Id: <4.3.2.7.2.20030228105934.00ba65b8@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 28 Feb 2003 11:13:32 -0500 To: dhcwg@ietf.org, ipng@sunroof.eng.sun.com From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [dhcwg] Results from interoperability testing of DHCPv6 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , We did some interoperability testing of independent DHCPv6 implementations at the recent TAHI interoperability testing event. I've published a list of issues, draft-ietf-dhc-dhcpv6-interop-00.txt, identified through the interoperability testing. The DHCPv6 specification has been accepted as a Proposed Standard, but has not yet been published as an RFC. To improve the text in the spec based on our experience with the interoperability testing, I will make the editorial clarifications listed as "resolution" in draft-ietf-dhc-dhcpv6-interop-00.txt prior to publication of the DHCPv6 RFC. Please review draft-ietf-dhc-dhcpv6-interop-00.txt and respond with any comments to the dhcwg mailing list. - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Feb 28 11:17:38 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03543; Fri, 28 Feb 2003 11:17:38 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SGS4p08260; Fri, 28 Feb 2003 11:28:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SGRMp08232 for ; Fri, 28 Feb 2003 11:27:22 -0500 Received: from rtp-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03517 for ; Fri, 28 Feb 2003 11:16:19 -0500 (EST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h1SGKDJR018400 for ; Fri, 28 Feb 2003 11:20:14 -0500 (EST) Received: from rdroms-w2k.cisco.com (dhcp-161-44-149-251.cisco.com [161.44.149.251]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id LAA13177 for ; Fri, 28 Feb 2003 11:20:13 -0500 (EST) Message-Id: <4.3.2.7.2.20030228111718.0379ced8@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 28 Feb 2003 11:20:12 -0500 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [dhcwg] Recharter of dhc WG Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , The new charter for the dhc WG has been accepted and published, http://www.ietf.org/html.charters/dhc-charter.html We need to add milestones to the charter for the outstanding WG drafts. Draft authors - we'll take a few minutes at the WG meeting in SF to talk about what we want to put in the charter as milestones and what would be realistic milestones. - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Feb 28 12:18:21 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05273; Fri, 28 Feb 2003 12:18:21 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SHSgp13267; Fri, 28 Feb 2003 12:28:42 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SHRsp13208 for ; Fri, 28 Feb 2003 12:27:54 -0500 Received: from rtp-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05226; Fri, 28 Feb 2003 12:16:40 -0500 (EST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h1SHKYJR022199; Fri, 28 Feb 2003 12:20:34 -0500 (EST) Received: from rdroms-w2k.cisco.com (dhcp-161-44-171-109.cisco.com [161.44.171.109]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id MAA17920; Fri, 28 Feb 2003 12:20:33 -0500 (EST) Message-Id: <4.3.2.7.2.20030228121852.03751068@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 28 Feb 2003 12:20:32 -0500 To: dhcwg@ietf.org From: Ralph Droms Cc: agenda@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [dhcwg] Draft agenda and request for agenda items Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Included below is the most recent draft agenda for the dhc WG meeting in SF. Please contact me if you have anything you'd like to add to the agenda. - Ralph DHC WG agenda - IETF 56 (Last revised 2/28/03 12:18) ------------------------------ Administrivia; agenda bashing; WG progress report Ralph Droms 5 minutes Review of new charter; request for milestones Ralph Droms 10 minutes DHCP security review team report Barr Hibbs 10 minutes Option code recovery Ralph Droms 5 minutes Option code extensions Bernie Volz 10 minutes Authentication of relay agent options John Schnizlein 10 minutes Review of DHCP RFCs Barr Hibbs 10 minutes Failover protocol Kim Kinnear 10 minutes Lease query protocol Kim Kinnear 10 minutes 'Securing DHCP with DNSSEC bourne public keys' Ted Lemon 15 minutes DHCPv6 status Ralph Droms 10 minutes DHCPv6 Interoperability test results DHCPv6 options ---------- Total 105 minutes _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Feb 28 12:24:44 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05575; Fri, 28 Feb 2003 12:24:44 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SHZ5p13565; Fri, 28 Feb 2003 12:35:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SHQ8p13144 for ; Fri, 28 Feb 2003 12:26:08 -0500 Received: from shuttle.wide.toshiba.co.jp (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05208 for ; Fri, 28 Feb 2003 12:15:03 -0500 (EST) Received: from localhost (unknown [3ffe:501:100f:f::6]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 712C715210; Sat, 1 Mar 2003 02:19:20 +0900 (JST) Date: Sat, 01 Mar 2003 02:19:09 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Ralph Droms Cc: dhcwg@ietf.org, ipng@sunroof.eng.sun.com In-Reply-To: <4.3.2.7.2.20030228105934.00ba65b8@funnel.cisco.com> References: <4.3.2.7.2.20030228105934.00ba65b8@funnel.cisco.com> User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.2 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 29 Subject: [dhcwg] Re: Results from interoperability testing of DHCPv6 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , >>>>> On Fri, 28 Feb 2003 11:13:32 -0500, >>>>> Ralph Droms said: > We did some interoperability testing thof independent DHCPv6 implementations > at the recent TAHI interoperability testing event. I've published a list > of issues, draft-ietf-dhc-dhcpv6-interop-00.txt, identified through the > interoperability testing. > The DHCPv6 specification has been accepted as a Proposed Standard, but has > not yet been published as an RFC. To improve the text in the spec based on > our experience with the interoperability testing, I will make the editorial > clarifications listed as "resolution" in > draft-ietf-dhc-dhcpv6-interop-00.txt prior to publication of the DHCPv6 RFC. > Please review draft-ietf-dhc-dhcpv6-interop-00.txt and respond with any > comments to the dhcwg mailing list. For the record, I fully support the action; I support the DHCPv6 spec to be published, and I belive it would be great if the published version of the DHCPv6 spec contains the clarifications described in the dhcpv6-interop draft. (Since I happened to have a chance to review the clarification draft beforehand, I don't have further comments on it.) JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Feb 28 12:47:57 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07088; Fri, 28 Feb 2003 12:47:57 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SHwHp15260; Fri, 28 Feb 2003 12:58:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SHv5p15204 for ; Fri, 28 Feb 2003 12:57:05 -0500 Received: from rtp-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07006 for ; Fri, 28 Feb 2003 12:45:59 -0500 (EST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h1SHnrNh014087; Fri, 28 Feb 2003 12:49:54 -0500 (EST) Received: from rdroms-w2k.cisco.com (dhcp-161-44-149-251.cisco.com [161.44.149.251]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id MAA20367; Fri, 28 Feb 2003 12:49:53 -0500 (EST) Message-Id: <4.3.2.7.2.20030228124404.0378ceb0@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 28 Feb 2003 12:49:52 -0500 To: dhcwg@ietf.org, ipng@sunroof.eng.sun.com, namedroppers@ops.ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [dhcwg] Revision of DHCPv6 DNS configuration options Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , I've revised "DNS Configuration options for DHCPv6" based on input received during the WG last call. Here is the summary of changes to the document: Changes from draft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt This document includes the following changes in response to comments made during the dhc/dnsext WG last call: o Combined RFC2119 reference and reference to DHCPv6 specification into one "Terminology" section; added explicit normative reference to DHCPv6 specification. o Changed name of "Domain Name Server" option to "DNS Resolver" option. o Clarified and corrected filed names and descriptions of fields in the option format diagrams. o Reworded "Appearance of these options" for clarity; removed Confirm from list of messages in which the options can appear. o Clarified the type of attack that can be mounted through the Domain Search List option by copying text from RFC3997 As these changes are editorial or clarifying, draft-ietf-dhc-dhcpv6 opt-dnsconfig-03.txt is ready for IESG review as a Proposed Standard. - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Feb 28 15:06:41 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11441; Fri, 28 Feb 2003 15:06:41 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SKGVp25035; Fri, 28 Feb 2003 15:16:31 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SKFap24980 for ; Fri, 28 Feb 2003 15:15:36 -0500 Received: from quiet-like-a-panther.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA11241 for ; Fri, 28 Feb 2003 15:04:49 -0500 (EST) Received: (qmail 8404 invoked by uid 511); 28 Feb 2003 20:08:23 -0000 Message-ID: <20030228200823.8403.qmail@quiet-like-a-panther.org> References: <4.3.2.7.2.20030228103812.00bb0590@funnel.cisco.com> In-Reply-To: <4.3.2.7.2.20030228103812.00bb0590@funnel.cisco.com> From: Michael Johnston To: Ralph Droms Cc: dhcwg@ietf.org Date: Fri, 28 Feb 2003 20:08:23 GMT Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [dhcwg] Re: Recovery of unused DHCP option codes Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Ralph, Options 93 (client system architecture), 94 (client network interface identifier) and 97 (client machine identfier (UUID)) are in heavy use today and are, and have been for several years, required for all new business PCs with built-in network devices to pass Microsoft WHQL. %%michael Ralph Droms writes: > I've published a document, draft-ietf-dhc-unused-optioncodes-00, that > lists several opcodes that were assigned prior to the publication of > RFC2489 (which was updated by RFC2939). For a variety of reasons, the > options associated with these opcodes were never accepted as standards and > published as RFCs. > > The publication of draft-ietf-dhc-unused-optioncodes-00 is the first step > in the return of these opcodes to IANA for assignment to future DHCP > options. Here's the plan: > > 1. Make an announcement on dhcwg asking for dhc WG > review of the draft; explicitly ask for report > of actual use of any options listed in the draft > 2. Revise the draft in the form of an Informational > RFC explicitly directing IANA to make the > option codes listed in the draft available for > assignment to new options in the future > 3. Make an announcement to the IETF as a whole asking > for review of the draft and report of any option > known to be in use > 4. Submit this document to the IESG for publication > as an Informational RFC > > This announcement is step 1 from the list. Please review > draft-ietf-dhc-unused-optioncodes-00 and respond to the dhc WG mailing > list if you know of any of the options listed in the document that are in > use, or if you have any other comments on the contents of the draft. > We'll take a couple of minutes to discuss the draft and solicit input at > the WG meeting in SF, as well. > > - Ralph > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Feb 28 15:15:23 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12147; Fri, 28 Feb 2003 15:15:23 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SKM5p25241; Fri, 28 Feb 2003 15:22:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SKLqp25224 for ; Fri, 28 Feb 2003 15:21:52 -0500 Received: from rtp-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12048 for ; Fri, 28 Feb 2003 15:11:29 -0500 (EST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h1SKEcJR003235; Fri, 28 Feb 2003 15:14:39 -0500 (EST) Received: from rdroms-w2k.cisco.com (dhcp-161-44-149-251.cisco.com [161.44.149.251]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id PAA03232; Fri, 28 Feb 2003 15:14:38 -0500 (EST) Message-Id: <4.3.2.7.2.20030228151419.037ebed0@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 28 Feb 2003 15:14:37 -0500 To: Michael Johnston From: Ralph Droms Subject: Re: [dhcwg] Re: Recovery of unused DHCP option codes Cc: dhcwg@ietf.org In-Reply-To: <20030228200823.8403.qmail@quiet-like-a-panther.org> References: <4.3.2.7.2.20030228103812.00bb0590@funnel.cisco.com> <4.3.2.7.2.20030228103812.00bb0590@funnel.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , OK, thanks... - Ralph At 08:08 PM 2/28/2003 +0000, Michael Johnston wrote: >Ralph, > >Options 93 (client system architecture), 94 (client network interface >identifier) and 97 (client machine identfier (UUID)) are in heavy use >today and are, and have been for several years, required for all new >business PCs with built-in network devices to pass Microsoft WHQL. >%%michael > >Ralph Droms writes: >>I've published a document, draft-ietf-dhc-unused-optioncodes-00, that >>lists several opcodes that were assigned prior to the publication of >>RFC2489 (which was updated by RFC2939). For a variety of reasons, the >>options associated with these opcodes were never accepted as standards >>and published as RFCs. >>The publication of draft-ietf-dhc-unused-optioncodes-00 is the first step >>in the return of these opcodes to IANA for assignment to future DHCP >>options. Here's the plan: >>1. Make an announcement on dhcwg asking for dhc WG >> review of the draft; explicitly ask for report >> of actual use of any options listed in the draft >>2. Revise the draft in the form of an Informational >> RFC explicitly directing IANA to make the >> option codes listed in the draft available for >> assignment to new options in the future >>3. Make an announcement to the IETF as a whole asking >> for review of the draft and report of any option >> known to be in use >>4. Submit this document to the IESG for publication >> as an Informational RFC >>This announcement is step 1 from the list. Please review >>draft-ietf-dhc-unused-optioncodes-00 and respond to the dhc WG mailing >>list if you know of any of the options listed in the document that are in >>use, or if you have any other comments on the contents of the draft. >>We'll take a couple of minutes to discuss the draft and solicit input at >>the WG meeting in SF, as well. >>- Ralph >>_______________________________________________ >>dhcwg mailing list >>dhcwg@ietf.org >>https://www1.ietf.org/mailman/listinfo/dhcwg >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Feb 28 17:02:21 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14691; Fri, 28 Feb 2003 17:02:21 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SMAsp32406; Fri, 28 Feb 2003 17:10:54 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SM9Hp32367 for ; Fri, 28 Feb 2003 17:09:17 -0500 Received: from chimera.incognito.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14673 for ; Fri, 28 Feb 2003 17:00:03 -0500 (EST) Received: from homerdmz.incognito.com ([207.102.214.106] helo=homer.incognito.com.) by chimera.incognito.com with smtp (Exim 3.35 #1 (Debian)) id 18osYp-0000SM-00; Fri, 28 Feb 2003 14:00:55 -0800 Received: by homer.incognito.com. with Internet Mail Service (5.5.2653.19) id ; Fri, 28 Feb 2003 14:07:31 -0800 Message-ID: <4FB49E60CFBA724E88867317DAA3D198A67A5E@homer.incognito.com.> From: "Kostur, Andre" To: "'Ralph Droms'" , Michael Johnston Cc: dhcwg@ietf.org Subject: RE: [dhcwg] Re: Recovery of unused DHCP option codes Date: Fri, 28 Feb 2003 14:07:31 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2DF75.CA0729F0" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2DF75.CA0729F0 Content-Type: text/plain; charset="iso-8859-1" I guess on a related note, shouldn't those options be properly published in a Draft then? > -----Original Message----- > From: Ralph Droms [mailto:rdroms@cisco.com] > Sent: Friday, February 28, 2003 12:15 PM > To: Michael Johnston > Cc: dhcwg@ietf.org > Subject: Re: [dhcwg] Re: Recovery of unused DHCP option codes > > > OK, thanks... > > - Ralph > > At 08:08 PM 2/28/2003 +0000, Michael Johnston wrote: > >Ralph, > > > >Options 93 (client system architecture), 94 (client network > interface > >identifier) and 97 (client machine identfier (UUID)) are in > heavy use > >today and are, and have been for several years, required for all new > >business PCs with built-in network devices to pass Microsoft WHQL. > >%%michael > > > >Ralph Droms writes: > >>I've published a document, > draft-ietf-dhc-unused-optioncodes-00, that > >>lists several opcodes that were assigned prior to the > publication of > >>RFC2489 (which was updated by RFC2939). For a variety of > reasons, the > >>options associated with these opcodes were never accepted > as standards > >>and published as RFCs. > >>The publication of draft-ietf-dhc-unused-optioncodes-00 is > the first step > >>in the return of these opcodes to IANA for assignment to > future DHCP > >>options. Here's the plan: > >>1. Make an announcement on dhcwg asking for dhc WG > >> review of the draft; explicitly ask for report > >> of actual use of any options listed in the draft > >>2. Revise the draft in the form of an Informational > >> RFC explicitly directing IANA to make the > >> option codes listed in the draft available for > >> assignment to new options in the future > >>3. Make an announcement to the IETF as a whole asking > >> for review of the draft and report of any option > >> known to be in use > >>4. Submit this document to the IESG for publication > >> as an Informational RFC > >>This announcement is step 1 from the list. Please review > >>draft-ietf-dhc-unused-optioncodes-00 and respond to the dhc > WG mailing > >>list if you know of any of the options listed in the > document that are in > >>use, or if you have any other comments on the contents of the draft. > >>We'll take a couple of minutes to discuss the draft and > solicit input at > >>the WG meeting in SF, as well. > >>- Ralph > >>_______________________________________________ > >>dhcwg mailing list > >>dhcwg@ietf.org > >>https://www1.ietf.org/mailman/listinfo/dhcwg > >_______________________________________________ > >dhcwg mailing list > >dhcwg@ietf.org > >https://www1.ietf.org/mailman/listinfo/dhcwg > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg > ------_=_NextPart_001_01C2DF75.CA0729F0 Content-Type: text/html; charset="iso-8859-1" RE: [dhcwg] Re: Recovery of unused DHCP option codes

I guess on a related note, shouldn't those options be properly published in a Draft then?

> -----Original Message-----
> From: Ralph Droms [mailto:rdroms@cisco.com]
> Sent: Friday, February 28, 2003 12:15 PM
> To: Michael Johnston
> Cc: dhcwg@ietf.org
> Subject: Re: [dhcwg] Re: Recovery of unused DHCP option codes
>
>
> OK, thanks...
>
> - Ralph
>
> At 08:08 PM 2/28/2003 +0000, Michael Johnston wrote:
> >Ralph,
> >
> >Options 93 (client system architecture), 94 (client network
> interface
> >identifier) and 97 (client machine identfier (UUID)) are in
> heavy use
> >today and are, and have been for several years, required for all new
> >business PCs with built-in network devices to pass Microsoft WHQL.
> >%%michael
> >
> >Ralph Droms writes:
> >>I've published a document,
> draft-ietf-dhc-unused-optioncodes-00, that
> >>lists several opcodes that were assigned prior to the
> publication of
> >>RFC2489 (which was updated by RFC2939).  For a variety of
> reasons, the
> >>options associated with these opcodes were never accepted
> as standards
> >>and published as RFCs.
> >>The publication of draft-ietf-dhc-unused-optioncodes-00 is
> the first step
> >>in the return of these opcodes to IANA for assignment to
> future DHCP
> >>options.  Here's the plan:
> >>1. Make an announcement on dhcwg asking for dhc WG
> >>    review of the draft; explicitly ask for report
> >>    of actual use of any options listed in the draft
> >>2. Revise the draft in the form of an Informational
> >>    RFC explicitly directing IANA to make the
> >>    option codes listed in the draft available for
> >>    assignment to new options in the future
> >>3. Make an announcement to the IETF as a whole asking
> >>    for review of the draft and report of any option
> >>    known to be in use
> >>4. Submit this document to the IESG for publication
> >>    as an Informational RFC
> >>This announcement is step 1 from the list.  Please review
> >>draft-ietf-dhc-unused-optioncodes-00 and respond to the dhc
> WG mailing
> >>list if you know of any of the options listed in the
> document that are in
> >>use, or if you have any other comments on the contents of the draft.
> >>We'll take a couple of minutes to discuss the draft and
> solicit input at
> >>the WG meeting in SF, as well.
> >>- Ralph
> >>_______________________________________________
> >>dhcwg mailing list
> >>dhcwg@ietf.org
> >>https://www1.ietf.org/mailman/listinfo/dhcwg
> >_______________________________________________
> >dhcwg mailing list
> >dhcwg@ietf.org
> >https://www1.ietf.org/mailman/listinfo/dhcwg
>
> _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org
> https://www1.ietf.org/mailman/listinfo/dhcwg
>

------_=_NextPart_001_01C2DF75.CA0729F0-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Feb 28 17:07:24 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14899; Fri, 28 Feb 2003 17:07:24 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SMG3p32612; Fri, 28 Feb 2003 17:16:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SMFZp32587 for ; Fri, 28 Feb 2003 17:15:35 -0500 Received: from rtp-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14864 for ; Fri, 28 Feb 2003 17:06:23 -0500 (EST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h1SM8JJR009949; Fri, 28 Feb 2003 17:08:20 -0500 (EST) Received: from rdroms-w2k.cisco.com (dhcp-161-44-149-251.cisco.com [161.44.149.251]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id RAA12042; Fri, 28 Feb 2003 17:08:19 -0500 (EST) Message-Id: <4.3.2.7.2.20030228170321.03787e10@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 28 Feb 2003 17:08:16 -0500 To: "Kostur, Andre" From: Ralph Droms Subject: RE: [dhcwg] Re: Recovery of unused DHCP option codes Cc: dhcwg@ietf.org In-Reply-To: <4FB49E60CFBA724E88867317DAA3D198A67A5E@homer.incognito.com .> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Yes, the options should be documented through the IETF standards process. The dhc WG will have to devise a plan to make that process happen. I'm trying to identify any sources of documentation for these options (http://www.pix.net/software/pxeboot/archive/pxespec.pdf) is a starting point, and who will take responsibility for shepherding the specs for the options through the IETF standards process. - Ralph At 02:07 PM 2/28/2003 -0800, you wrote: >I guess on a related note, shouldn't those options be properly published >in a Draft then? > > > -----Original Message----- > > From: Ralph Droms [mailto:rdroms@cisco.com] > > Sent: Friday, February 28, 2003 12:15 PM > > To: Michael Johnston > > Cc: dhcwg@ietf.org > > Subject: Re: [dhcwg] Re: Recovery of unused DHCP option codes > > > > > > OK, thanks... > > > > - Ralph > > > > At 08:08 PM 2/28/2003 +0000, Michael Johnston wrote: > > >Ralph, > > > > > >Options 93 (client system architecture), 94 (client network > > interface > > >identifier) and 97 (client machine identfier (UUID)) are in > > heavy use > > >today and are, and have been for several years, required for all new > > >business PCs with built-in network devices to pass Microsoft WHQL. > > >%%michael > > > > > >Ralph Droms writes: > > >>I've published a document, > > draft-ietf-dhc-unused-optioncodes-00, that > > >>lists several opcodes that were assigned prior to the > > publication of > > >>RFC2489 (which was updated by RFC2939). For a variety of > > reasons, the > > >>options associated with these opcodes were never accepted > > as standards > > >>and published as RFCs. > > >>The publication of draft-ietf-dhc-unused-optioncodes-00 is > > the first step > > >>in the return of these opcodes to IANA for assignment to > > future DHCP > > >>options. Here's the plan: > > >>1. Make an announcement on dhcwg asking for dhc WG > > >> review of the draft; explicitly ask for report > > >> of actual use of any options listed in the draft > > >>2. Revise the draft in the form of an Informational > > >> RFC explicitly directing IANA to make the > > >> option codes listed in the draft available for > > >> assignment to new options in the future > > >>3. Make an announcement to the IETF as a whole asking > > >> for review of the draft and report of any option > > >> known to be in use > > >>4. Submit this document to the IESG for publication > > >> as an Informational RFC > > >>This announcement is step 1 from the list. Please review > > >>draft-ietf-dhc-unused-optioncodes-00 and respond to the dhc > > WG mailing > > >>list if you know of any of the options listed in the > > document that are in > > >>use, or if you have any other comments on the contents of the draft. > > >>We'll take a couple of minutes to discuss the draft and > > solicit input at > > >>the WG meeting in SF, as well. > > >>- Ralph > > >>_______________________________________________ > > >>dhcwg mailing list > > >>dhcwg@ietf.org > > >>https://www1.ietf.org/ma > ilman/listinfo/dhcwg > > >_______________________________________________ > > >dhcwg mailing list > > >dhcwg@ietf.org > > >https://www1.ietf.org/mai > lman/listinfo/dhcwg > > > > _______________________________________________ > > dhcwg mailing list > > dhcwg@ietf.org > > > https://www1.ietf.org/mailman/listinfo/dhcwg > > > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Feb 28 19:53:49 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18809; Fri, 28 Feb 2003 19:53:49 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2112Op08679; Fri, 28 Feb 2003 20:02:24 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h21116p08651 for ; Fri, 28 Feb 2003 20:01:06 -0500 Received: from sj-msg-core-3.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18797 for ; Fri, 28 Feb 2003 19:51:50 -0500 (EST) Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-msg-core-3.cisco.com (8.12.2/8.12.6) with ESMTP id h210rYP7016648; Fri, 28 Feb 2003 16:53:34 -0800 (PST) Received: from cisco.com (junxie-u10.cisco.com [128.107.162.197]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id AEP05155; Fri, 28 Feb 2003 16:48:47 -0800 (PST) Message-ID: <3E60049B.913B3991@cisco.com> Date: Fri, 28 Feb 2003 16:53:47 -0800 From: Jun Xie X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Ralph Droms CC: dhcwg@ietf.org Subject: Re: [dhcwg] Revision of DHCPv6 DNS configuration options References: <4.3.2.7.2.20030228124404.0378ceb0@funnel.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > o Changed name of "Domain Name Server" option to "DNS Resolver" > option. "DNS Resolver" sounds confusing to me. I believe the change is in response to the following comment: "From a purist's point of view I'm tempted to say that you're not really looking for a DNS server here but instead for a (list of) recursive resolvers." The section 2.4. of RFC 1034 says: "RESOLVERS are programs that extract information from name servers in response to client requests... A resolver will typically be a system routine that is directly accessible to user programs; hence no protocol is necessary between the resolver and the user program." So a resolver is a DNS client that can be invoked by users through a simple OS call. There is no such concept as "recursive resolver" in DNS. A DNS _server_ may be "recursive" or "iterative". A recursive server can call a local resolver to pursue the query for the client at another server. A root name server is always iterative. I think the option really means a list of name servers, recursive or iterative. So "Domain Name Server" makes more sense to me. Jun Ralph Droms wrote: > > I've revised "DNS Configuration options for DHCPv6" draft-ietf-dhc-dhcpv6 opt-dnsconfig-03.txt> based on input received during > the WG last call. Here is the summary of changes to the document: > > Changes from draft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt > > This document includes the following changes in response to comments > made during the dhc/dnsext WG last call: > > o Combined RFC2119 reference and reference to DHCPv6 specification > into one "Terminology" section; added explicit normative reference > to DHCPv6 specification. > > o Changed name of "Domain Name Server" option to "DNS Resolver" > option. > > o Clarified and corrected filed names and descriptions of fields in > the option format diagrams. > > o Reworded "Appearance of these options" for clarity; removed > Confirm from list of messages in which the options can appear. > > o Clarified the type of attack that can be mounted through the > Domain Search List option by copying text from RFC3997 > > As these changes are editorial or clarifying, draft-ietf-dhc-dhcpv6 > opt-dnsconfig-03.txt is ready for IESG review as a Proposed Standard. > > - Ralph > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Feb 28 22:22:47 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21219; Fri, 28 Feb 2003 22:22:47 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h213VPp15970; Fri, 28 Feb 2003 22:31:25 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h213Ujp15943 for ; Fri, 28 Feb 2003 22:30:45 -0500 Received: from toccata.fugue.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21207 for ; Fri, 28 Feb 2003 22:21:27 -0500 (EST) Received: from nominum.com (dsl093-187-232.chi2.dsl.speakeasy.net [66.93.187.232]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id h213K8J01032; Fri, 28 Feb 2003 21:20:11 -0600 (CST) Date: Fri, 28 Feb 2003 21:23:21 -0600 Subject: Re: [dhcwg] Revision of DHCPv6 DNS configuration options Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: dhcwg@ietf.org, Ralph Droms To: Jun Xie From: Ted Lemon In-Reply-To: <3E60049B.913B3991@cisco.com> Message-Id: <274CFC68-4B95-11D7-9787-00039367340A@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit If you wanted to, you could call it a Caching Name Server, or a Recursive Resolver. I don't think it's terribly important to make a distinction here, though, unless we think that there might be some other kind of name server that the DHCP server would want to talk about. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Feb 28 23:39:08 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA22140; Fri, 28 Feb 2003 23:39:08 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h214lWp20008; Fri, 28 Feb 2003 23:47:32 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h214k5p19976 for ; Fri, 28 Feb 2003 23:46:05 -0500 Received: from sj-msg-core-3.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA22130 for ; Fri, 28 Feb 2003 23:36:45 -0500 (EST) Received: from skothapa-w2k1.cisco.com (sjc-vpn1-458.cisco.com [10.21.97.202]) by sj-msg-core-3.cisco.com (8.12.2/8.12.6) with ESMTP id h214cTP8000382; Fri, 28 Feb 2003 20:38:29 -0800 (PST) Message-Id: <4.3.2.7.2.20030228202840.00b00300@mira-sjcm-2.cisco.com> X-Sender: junxie@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 28 Feb 2003 20:37:59 -0800 To: Ted Lemon From: Jun Xie Subject: Re: [dhcwg] Revision of DHCPv6 DNS configuration options Cc: dhcwg@ietf.org, Ralph Droms In-Reply-To: <274CFC68-4B95-11D7-9787-00039367340A@nominum.com> References: <3E60049B.913B3991@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Caching name server is only one special kind of name servers. I don't think the option is limited to specify caching name servers only. I think domain name server is more general and appropriate here. At 09:23 PM 2/28/2003 -0600, Ted Lemon wrote: >If you wanted to, you could call it a Caching Name Server, or a Recursive >Resolver. I don't think it's terribly important to make a distinction >here, though, unless we think that there might be some other kind of name >server that the DHCP server would want to talk about. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg