From mailman-bounces@ietf.org Sun Aug 1 07:51:29 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14540 for ; Sun, 1 Aug 2004 07:51:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BrCcm-0006t3-Ac for dhc-archive@lists.ietf.org; Sun, 01 Aug 2004 05:27:24 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: ietf.org mailing list memberships reminder From: mailman-owner@ietf.org To: dhc-archive@ietf.org X-No-Archive: yes Message-ID: Date: Sun, 01 Aug 2004 05:07:27 -0400 Precedence: bulk X-BeenThere: mailman@lists.ietf.org X-Mailman-Version: 2.1.5 List-Id: Mailman site list X-List-Administrivia: yes Sender: mailman-bounces@ietf.org Errors-To: mailman-bounces@ietf.org Content-Transfer-Encoding: 7bit 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, mailman-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: Any submission to the IETF intended by the Contributor for publication as all or part of an IETF Internet-Draft or RFC and any statement made within the context of an IETF activity is considered an "IETF Contribution". Such statements include oral statements in IETF sessions, as well as written and electronic communications made at any time or place, which are addressed to: o the IETF plenary session, o any IETF working group or portion thereof, o the IESG, or any member thereof on behalf of the IESG, o the IAB or any member thereof on behalf of the IAB, o any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, o the RFC Editor or the Internet-Drafts function All IETF Contributions are subject to the rules of RFC 3667 and RFC 3668. Statements made outside of an IETF session, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not IETF Contributions in the context of this notice. Please consult RFC 3667 for details. ******************************************************************************* If you have questions, problems, comments, etc, send them to mailman-owner@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-bounces@ietf.org Sun Aug 1 12:32:28 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09530; Sun, 1 Aug 2004 12:32:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BrJA8-0003aQ-7S; Sun, 01 Aug 2004 12:26:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BrHsx-0005K7-KF for dhcwg@megatron.ietf.org; Sun, 01 Aug 2004 11:04:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05268 for ; Sun, 1 Aug 2004 11:04:25 -0400 (EDT) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BrHvd-0004Mo-7G for dhcwg@ietf.org; Sun, 01 Aug 2004 11:07:13 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i71F3mA31984; Sun, 1 Aug 2004 18:03:48 +0300 Date: Sun, 1 Aug 2004 18:03:48 +0300 (EEST) From: Pekka Savola To: mboned@lists.uoregon.edu Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 X-Mailman-Approved-At: Sun, 01 Aug 2004 12:26:13 -0400 Cc: dhcwg@ietf.org Subject: [dhcwg] draft-jdurand-assign-addr-ipv6-multicast-dhcpv6-00 comments X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Hi, A few comments. Bigger ones: 1) I'm concerned whether this is exactly what we need, especially when we have RFC3306 or embedded-RP; it is not clear which problem we're solving (and which problems remain to be solved). In particular, if any host on a link with a /64 prefix could calculate its own multicast prefix (unique to that link) on its own, and have 32 bits of group-id's to pick from (making sure they don't conflict on that link), could one argue that there is no need for central multicast address assignment.. but rather a mechanism where the host could pick a group-id in such a way it doesn't conflict (a random process should be sufficient, but if not, there could be Multicast DAD)? Similarly, if embedded-RP is used, what you could need is the information what is the address of the RP or which prefix one should use for picking the multicast addresses. So, looking at from a different perspective, it would seem that we don't necessarily need DHCPv6 for address assignment itself, but maybe some other configuration mechanism to figure out the multicast prefix which belongs on the link. Remember, we're talking about v6 here which is completely different than v4 multicast address assignment scenarios (address scarcity, centrally managed pool, etc.)! 2) I think this approach and its implications could use a bit more discussion inside mboned (which is why I argue splitting it up makes sense). In particular, the assignment of addresses is also coupled with service discovery/announcements, which was decreed out of scope from here. But as DHCPv6 servers can even update DNS records, it could be possible to envision that if they give out v6 multicast addresses as well, they might be capable of other difficult tasks as well. (If the document is split, it might make sense to keep sections 1-4 in mboned, and include new section 5 which would describe different new approaches to these scenarios -- e.g., various uses of DHCPv6, multicast-DAD, the embedded-RP communicating the address at which it's serving (e..g, if on every link, the ::1 one) ...) 3) o DHCPv6 usually has impacts on the kernel (IPv6 unicast addressM assignment, DNS address indication...) and the problem ofM multicast address assignment is in user space. Are there someM problems that could be coming from this ?M ==> this brings out a lurking issue. As v6 multicast addresses are given out only temporarily, with lifetime, the question is, who keeps track of that lifetime and removes the usage as appropriate? In other words, I assumed that this approach assumes that when an app wants to use a multicast address, the user/administrator of that application puts in a request in DHCPv6, and gets a (temporary) address. (S)he then configures it in the application, and runs the application. But then there is no link with the lifetime of the address. The other approach would probably be to make it more complex, adding some kind of API between DHCPv6 and multicast application, but that would probably be a non-starter due to its complexity. In any case, it seems the impact of lifetime needs to be considered a bit more deeply... semi-substantial ---------------- option-code: OPTION_IA_MA (21)M ==> have these option codes already been assigned by IANA, or are you just suggesting to use these? Should probably be replaced by TBD's, and noted in IANA Considerations section to be added. editorial --------- ==> IMHO, the abstract should be a bit longer, maybe 5-10 lines. o This random assignment could also be used with embedded RPM addresses if the RP is managing a few number of groupsM ==> as noted above in issue 1), this might not be as straightforward that, as the host needs to know the RP's Interface-ID (at least) first-- possibly also which kind of prefix to use.. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-M +M | M |M . IA_MA-options M =2EM . M =2EM +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-M ==> this seems to have wrapped, and there are some =2E chars here.. know exactely the scope it wants to request but has a set of adequatM ==> s/adequat/adequate/ res: This field is reserved for future use. The 4 bits of this fieldM MUST be set to 0M ==> , and MUST be ignored on receipt. (similar elsewhere) Security and pricacy considerations of the assignment of IPv6M ==> s/pricacy/privacy/ o Split in 2 different drafts: one for the DHC WG with theM description of the DHCPv6 options and mechanismsand; the other oneM ==> s/and/ and/ -- 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-bounces@ietf.org Sun Aug 1 14:10:59 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14068; Sun, 1 Aug 2004 14:10:59 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BrKj8-0006Um-3h; Sun, 01 Aug 2004 14:06:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BrKO4-0007Cr-Nh for dhcwg@megatron.ietf.org; Sun, 01 Aug 2004 13:44:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13163 for ; Sun, 1 Aug 2004 13:44:41 -0400 (EDT) Received: from tyholt.uninett.no ([158.38.60.10]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BrKQk-0006Vg-Tz for dhcwg@ietf.org; Sun, 01 Aug 2004 13:47:32 -0400 Received: from sverresborg.uninett.no (sverresborg.uninett.no [IPv6:2001:700:e000:0:204:75ff:fee4:423b]) by tyholt.uninett.no (8.12.10/8.12.10) with ESMTP id i71HiAV0017729; Sun, 1 Aug 2004 19:44:10 +0200 Received: (from venaas@localhost) by sverresborg.uninett.no (8.12.8/8.12.8/Submit) id i71Hi9CE015056; Sun, 1 Aug 2004 19:44:09 +0200 X-Authentication-Warning: sverresborg.uninett.no: venaas set sender to Stig.Venaas@uninett.no using -f Date: Sun, 1 Aug 2004 19:44:09 +0200 From: Stig Venaas To: Pekka Savola Message-ID: <20040801174409.GB14995@sverresborg.uninett.no> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: dhcwg@ietf.org, mboned@lists.uoregon.edu Subject: [dhcwg] Re: mboned: draft-jdurand-assign-addr-ipv6-multicast-dhcpv6-00 comments X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org On Sun, Aug 01, 2004 at 06:03:48PM +0300, Pekka Savola wrote: [...] > have RFC3306 or embedded-RP; it is not clear which problem we're solving > (and which problems remain to be solved). > > In particular, if any host on a link with a /64 prefix could calculate its > own multicast prefix (unique to that link) on its own, and have 32 bits of > group-id's to pick from (making sure they don't conflict on that link), > could one argue that there is no need for central multicast address > assignment.. but rather a mechanism where the host could pick a group-id in > such a way it doesn't conflict (a random process should be sufficient, but > if not, there could be Multicast DAD)? Yes, I've also thought a bit about this. The 64-bit link-id could be a starting point too. I think some form of DAD would be nice. It must also be possible for a host to have multiple groups. > Similarly, if embedded-RP is used, what you could need is the information > what is the address of the RP or which prefix one should use for picking the > multicast addresses. > > So, looking at from a different perspective, it would seem that we don't > necessarily need DHCPv6 for address assignment itself, but maybe some other > configuration mechanism to figure out the multicast prefix which belongs on > the link. Yes, sounds good. So question then is whether DHCP or something else should be used. WRT Embedded-RP I think allocating a prefix to the link, as you suggest, is better than telling the application what the Embedded-RP address is (applications shouldn't need to know about Embedded-RP details). I see some possible issues. There might be a need for giving hosts different prefixes for different scopes (you could imagine having one prefix where simply the scope bits are set to whatever scope is needed). I think there are cases where you might use say Embedded-RP internally (with small scope) and prefix-based addressing externally (with larger scope) or vice versa. Or where you may want different RPs for different scopes. Well, in short, I also think the fact that we only need uniqueness per link, should simplify things quite a bit. I would be happy to work on possible solutions to this. Stig _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Sun Aug 1 15:24:26 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18620; Sun, 1 Aug 2004 15:24:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BrLop-00013T-Hl; Sun, 01 Aug 2004 15:16:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BrLPX-0003FH-3Q for dhcwg@megatron.ietf.org; Sun, 01 Aug 2004 14:50:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15653 for ; Sun, 1 Aug 2004 14:50:15 -0400 (EDT) Received: from dmzraw2.extranet.tce.com ([157.254.234.138]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BrLSD-0007Cm-RL for dhcwg@ietf.org; Sun, 01 Aug 2004 14:53:07 -0400 Received: from smtprelay.indy.tce.com (ismtprelay.indy.tce.com [157.254.96.114]) by dmzraw2.extranet.tce.com (8.12.5/8.12.5) with ESMTP id i71InZgG023236; Sun, 1 Aug 2004 18:49:37 GMT Received: from boulsmailbh02.eu.thmulti.com (localhost [127.0.0.1]) by smtprelay.indy.tce.com (8.9.3/8.9.1) with ESMTP id SAA09084; Sun, 1 Aug 2004 18:49:34 GMT Received: from edgmsmsg01.eu.thmulti.com ([141.11.248.11]) by boulsmailbh02.eu.thmulti.com with Microsoft SMTPSVC(5.0.2195.6713); Sun, 1 Aug 2004 20:49:33 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6556.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [dhcwg] Comments ondraft-cadar-dhc-dhcpv6-opt-email-00.txt/draft-cadar-dhc-opt-imap-00.txt Date: Sun, 1 Aug 2004 20:49:33 +0200 Message-ID: <421CB3B9B2D2F645B548D213C0A90E5501168D0C@edgmsmsg01.eu.thmulti.com> Thread-Topic: [dhcwg] Comments ondraft-cadar-dhc-dhcpv6-opt-email-00.txt/draft-cadar-dhc-opt-imap-00.txt Thread-Index: AcR2VUXrEf7CPT9NTz+/AsATj3a7xwBoURQQ From: "Van Aken Dirk" To: "Ted Lemon" , "Cristian Cadar" X-OriginalArrivalTime: 01 Aug 2004 18:49:33.0561 (UTC) FILETIME=[491F7690:01C477F8] X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: quoted-printable Cc: dhcwg@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Hello Ted, Cristian, See some comments inline. Best regards - Dirk > -----Original Message----- > From: dhcwg-bounces@ietf.org=20 > [mailto:dhcwg-bounces@ietf.org]On Behalf Of > Ted Lemon > Sent: vrijdag 30 juli 2004 18:33 > To: Cristian Cadar > Cc: dhcwg@ietf.org > Subject: Re: [dhcwg] Comments > ondraft-cadar-dhc-dhcpv6-opt-email-00.txt/draft-cadar-dhc-opt- > imap-00.txt > =20 > I guess my first question about this is why? I assume to come closer to zero-config of hosts and applications I would = say. =20 > Why would you want a client to trust the DHCP server to tell you what = IMAP server to=20 > contact? Is this not true for all options that are returned by a server ? > What if you wind up talking to a rogue server, or roam to a=20 > different network? These don't seem like things that are=20 > location-dependent - they seem like things that you want to configure=20 > on the client and not change as the client moves around. True, but on the other hand from the perspective of a system admin, = he/she must use two methods for host/application configuration. That is, = a DHCP server for a first set of parameters and scripts or even manual = config for other parameters. >=20 >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg >=20 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Sun Aug 1 18:12:58 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27681; Sun, 1 Aug 2004 18:12:58 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BrOUB-0000tI-SL; Sun, 01 Aug 2004 18:07:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BrOOj-0002eg-Np for dhcwg@megatron.ietf.org; Sun, 01 Aug 2004 18:01:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26455 for ; Sun, 1 Aug 2004 18:01:38 -0400 (EDT) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BrORR-0001YX-Tw for dhcwg@ietf.org; Sun, 01 Aug 2004 18:04:31 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i71M17V06867; Mon, 2 Aug 2004 01:01:07 +0300 Date: Mon, 2 Aug 2004 01:01:06 +0300 (EEST) From: Pekka Savola To: Stig Venaas In-Reply-To: <20040801174409.GB14995@sverresborg.uninett.no> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: dhcwg@ietf.org, mboned@lists.uoregon.edu Subject: [dhcwg] Re: mboned: draft-jdurand-assign-addr-ipv6-multicast-dhcpv6-00 comments X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org On Sun, 1 Aug 2004, Stig Venaas wrote: [...] > I see some possible issues. There might be a need for giving hosts > different prefixes for different scopes (you could imagine having > one prefix where simply the scope bits are set to whatever scope > is needed). I think there are cases where you might use say > Embedded-RP internally (with small scope) and prefix-based addressing > externally (with larger scope) or vice versa. Or where you may want > different RPs for different scopes. Well, one obvious way to achieve all of this is to add a Multicast Prefix Information option (a tailed down version of PI option), to RFC2461/RFC2462 Route Advertisements, and specification of multicast DAD (possibly with a flag in the MPI whether it's needed or not). With that, multiple prefixes could be advertised, but typically one would be enough. (The "good news" here is that a good implementation would not need to require the router admin to specify the prefix to be advertised on all the links, but it could be calculated & advertised automatically as well.) Additionally, individual addresses could also be dealt with DHCPv6 or something, but I personally don't see that as equally attractive.. but in cases where this is attractive IMHO manual addressing, as it's done today, is probably typically more lucrative.. -- 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-bounces@ietf.org Sun Aug 1 22:12:40 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA13714; Sun, 1 Aug 2004 22:12:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BrSD8-0003dd-Pe; Sun, 01 Aug 2004 22:05:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BrS4P-0008Vi-8e for dhcwg@megatron.ietf.org; Sun, 01 Aug 2004 21:56:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08780 for ; Sun, 1 Aug 2004 21:56:55 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BrS78-0004f3-08 for dhcwg@ietf.org; Sun, 01 Aug 2004 21:59:49 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 01 Aug 2004 21:56:22 -0400 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i721uKRK002600 for ; Sun, 1 Aug 2004 21:56:20 -0400 (EDT) Received: from rdroms-w2k01.cisco.com (rtp-vpn3-111.cisco.com [10.82.216.111]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AKN56832; Sun, 1 Aug 2004 21:56:19 -0400 (EDT) Message-Id: <4.3.2.7.2.20040801215319.0264fcd8@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sun, 01 Aug 2004 21:57:41 -0400 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Subject: [dhcwg] Final agenda for dhc WG meeting X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org PLEASE READ THE INTERNET DRAFTS ON THE AGENDA!!!! We need active participants, who have read the drafts BEFORE the WG meeting, so we can reach consensus on WG actions such as accepting drafts as WG work items and approving drafts for WG last call. We will need at least one 9and preferably more) scribe to take notes at the meeting. Is anyone who will not attend the meeting in San Diego interested in a jabber session? Please let me know as soon as possible. Final agenda: DHC WG agenda - IETF 60 0900 Tue 2004-08-03 (tentative) (Last revised 08/01/2004 09:48 PM) ---------------------------------- Administrivia Ralph Droms 10 minutes Agenda bashing, blue sheets, scribe, Jabber scribe Status of IPR claim by Samsung on draft-ietf-dhc-rapid-commit-opt-05.txt Status of IPR claim by PacketFront on draft-ietf-dhc-subscriber-id-06.txt Request for milestones for dhc WG drafts The DHCPv6 Client FQDN Option Bernie Volz 05 minutes Accept as dhc WG work item? The DHCP Client FQDN Option Bernie Volz 10 minutes Technical discussion DHCPv4 Opts. for B-cast and M-cast Control Servers Kuntal Chowdhury 05 minutes Accept as dhc WG work item? DHCPv6 Opts. for B-cast and M-cast Control Servers Kuntal Chowdhury 05 minutes Accept as dhc WG work item? DHCP Option for Configuring IPv6-over-IPv4 Tunnels S. Daniel Park 05 minutes Accept as dhc WG work item? Configured Tunnel End-Point Config. using DHCPv4 S. Daniel Park 05 minutes Accept as dhc WG work item? DHCP Option for Home Agent Discovery in MIPv6 Heejin Jang 05 minutes Accept as dhc WG work item? Vendor-Specific Information Suboption for RAIO Mark Stapp 05 minutes Accept as dhc WG work item? Renumbering Requirements for Stateless DHCPv6 Tim Chown 15 minutes Ready for WG last call? Lifetime Option for DHCPv6 Stig Venaas 15 minutes Ready for WG last call (depending on status of 'Renumbering Requirements')? IPv4 and IPv6 Dual-Stack Issues for DHCPv6 Tim Chown 30 minutes Ready for WG last call? Issues in DHCPv6 authentication Jinmei Tatuya 15 minutes Technical discussion IPv6 multicast address assignment with DHCPv6 Jerome Durand 20 minutes Technical discussion ----------- 150 minutes _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon Aug 2 00:53:54 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29438; Mon, 2 Aug 2004 00:53:54 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BrUnQ-0007mc-9q; Mon, 02 Aug 2004 00:51:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BrUkw-0006K1-GP for dhcwg@megatron.ietf.org; Mon, 02 Aug 2004 00:49:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29295 for ; Mon, 2 Aug 2004 00:48:59 -0400 (EDT) Received: from tyholt.uninett.no ([158.38.60.10]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BrUni-0007H4-CP for dhcwg@ietf.org; Mon, 02 Aug 2004 00:51:56 -0400 Received: from sverresborg.uninett.no (sverresborg.uninett.no [IPv6:2001:700:e000:0:204:75ff:fee4:423b]) by tyholt.uninett.no (8.12.10/8.12.10) with ESMTP id i724mQV0019796; Mon, 2 Aug 2004 06:48:26 +0200 Received: (from venaas@localhost) by sverresborg.uninett.no (8.12.8/8.12.8/Submit) id i724mPGu016973; Mon, 2 Aug 2004 06:48:25 +0200 X-Authentication-Warning: sverresborg.uninett.no: venaas set sender to Stig.Venaas@uninett.no using -f Date: Mon, 2 Aug 2004 06:48:25 +0200 From: Stig Venaas To: Pekka Savola Message-ID: <20040802044825.GA16941@sverresborg.uninett.no> References: <20040801174409.GB14995@sverresborg.uninett.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: dhcwg@ietf.org, mboned@lists.uoregon.edu Subject: [dhcwg] Re: mboned: draft-jdurand-assign-addr-ipv6-multicast-dhcpv6-00 comments X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org On Mon, Aug 02, 2004 at 01:01:06AM +0300, Pekka Savola wrote: [...] > Well, one obvious way to achieve all of this is to add a Multicast > Prefix Information option (a tailed down version of PI option), to > RFC2461/RFC2462 Route Advertisements, and specification of multicast > DAD (possibly with a flag in the MPI whether it's needed or not). > > With that, multiple prefixes could be advertised, but typically one > would be enough. > > (The "good news" here is that a good implementation would not need to > require the router admin to specify the prefix to be advertised on all > the links, but it could be calculated & advertised automatically as > well.) The prefixes to use could also be announced by DHCP. You could easily use stateless DHCP. In addition to this some form of DAD would be good. I don't care that much how the client picks the last 32 bits, it could be random, from interface id somehow, or specified by the user. The main thing is making sure it's unique. So, I think there are basically two issues that can be solved independently. One is prefix to use, the other is link uniqueness. The former might be done with RAs or stateless DHCP. The second should probably be done using some link-local multicast ICMP, but I need to think more about that. One issue is that one needs to allow multiple sources for a group in some cases. So I think DAD should just be offered as a service, whether an application should use the group in case of duplicates should be up to the application. Stig _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon Aug 2 02:46:07 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18614; Mon, 2 Aug 2004 02:46:07 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BrWQa-0002ZW-GF; Mon, 02 Aug 2004 02:36:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BrWGv-0006CW-Dp for dhcwg@megatron.ietf.org; Mon, 02 Aug 2004 02:26:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA17480 for ; Mon, 2 Aug 2004 02:26:08 -0400 (EDT) Received: from sinfonix.rz.tu-clausthal.de ([139.174.2.33]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BrWJi-0008OS-H4 for dhcwg@ietf.org; Mon, 02 Aug 2004 02:29:03 -0400 Received: from [139.174.2.206] (balrog.rz.tu-clausthal.de [139.174.2.206]) by sinfonix.rz.tu-clausthal.de (8.9.3/8.9.3) with ESMTP id IAA21113 for ; Mon, 2 Aug 2004 08:26:05 +0200 (MET DST) Subject: Re: [dhcwg] Final agenda for dhc WG meeting From: Christian Strauf To: dhcwg@ietf.org In-Reply-To: <4.3.2.7.2.20040801215319.0264fcd8@flask.cisco.com> References: <4.3.2.7.2.20040801215319.0264fcd8@flask.cisco.com> Content-Type: text/plain Organization: Rechenzentrum TU Clausthal Message-Id: <1091427965.17987.3.camel@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Mon, 02 Aug 2004 08:26:05 +0200 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Content-Transfer-Encoding: 7bit X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 7bit > Is anyone who will not attend the meeting in San Diego interested in a > jabber session? Please let me know as soon as possible. I'm very interested in a jabber scribe. Thanks in advance! Christian _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon Aug 2 07:09:58 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29693; Mon, 2 Aug 2004 07:09:58 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BraeU-0007gu-NX; Mon, 02 Aug 2004 07:06:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BrZE8-0005Og-TM for dhcwg@megatron.ietf.org; Mon, 02 Aug 2004 05:35:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25957 for ; Mon, 2 Aug 2004 05:35:27 -0400 (EDT) Received: from ns1.u-strasbg.fr ([130.79.200.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BrZGx-0002Rm-QU for dhcwg@ietf.org; Mon, 02 Aug 2004 05:38:25 -0400 Received: from crc.u-strasbg.fr (crc6.u-strasbg.fr [IPv6:2001:660:2402:1001::1]) by ns1.u-strasbg.fr (8.12.9p2/jtpda-5.4) with ESMTP id i729ZPvY099300 ; Mon, 2 Aug 2004 11:35:25 +0200 (CEST) Received: from crc.u-strasbg.fr (sixnet.u-strasbg.fr [130.79.90.153]) by crc.u-strasbg.fr (8.12.9p2/jtpda-5.4) with ESMTP id i729ZOmg008944 ; Mon, 2 Aug 2004 11:35:25 +0200 (CEST) Message-ID: <410E0ADD.4050505@crc.u-strasbg.fr> Date: Mon, 02 Aug 2004 11:35:25 +0200 From: Jean-Jacques Pansiot User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stig Venaas References: <20040801174409.GB14995@sverresborg.uninett.no> <20040802044825.GA16941@sverresborg.uninett.no> In-Reply-To: <20040802044825.GA16941@sverresborg.uninett.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Message not sent from an IPv4 address, not delayed by milter-greylist-1.5.3 (ns1.u-strasbg.fr [IPv6:2001:660:2402::1]); Mon, 02 Aug 2004 11:35:25 +0200 (CEST) X-Antivirus: scanned by sophos at u-strasbg.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 02 Aug 2004 07:06:45 -0400 Cc: dhcwg@ietf.org, Pekka Savola , mboned@lists.uoregon.edu Subject: [dhcwg] Re: mboned: draft-jdurand-assign-addr-ipv6-multicast-dhcpv6-00 comments X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 7bit Stig Venaas wrote: >On Mon, Aug 02, 2004 at 01:01:06AM +0300, Pekka Savola wrote: >[...] > > >>Well, one obvious way to achieve all of this is to add a Multicast >>Prefix Information option (a tailed down version of PI option), to >>RFC2461/RFC2462 Route Advertisements, and specification of multicast >>DAD (possibly with a flag in the MPI whether it's needed or not). >> >>With that, multiple prefixes could be advertised, but typically one >>would be enough. >> >>(The "good news" here is that a good implementation would not need to >>require the router admin to specify the prefix to be advertised on all >>the links, but it could be calculated & advertised automatically as >>well.) >> >> > >The prefixes to use could also be announced by DHCP. You could easily >use stateless DHCP. In addition to this some form of DAD would be good. >I don't care that much how the client picks the last 32 bits, it could >be random, from interface id somehow, or specified by the user. The >main thing is making sure it's unique. > > One useful feature of DHCP is the notion of a lease for some amount of time. Assume that I want to start a videoconference tomorrow at 9am. It might be useful to reserve an address NOW (in order to publish it) although applications (senders and receivers) will be launched only to morrow.It seems that we have 3 solutions : 1) use some kind of centralized registry on the link (could be dhcp?) 2) have a local registry on each host, could be similar to a dhclient.leases file, but then it might need a new daemon to respond to multicast DAD ? this should be persistent across crashes and reboot 3) do a multicast DAD now and hope it will still work tomorrow ? What do you think ? Note that mechanism 2 could be useful also for SSM : it allows a user to reserve a channel without conflict with other node-local users/applications Jean-Jacques >So, I think there are basically two issues that can be solved >independently. One is prefix to use, the other is link uniqueness. > >The former might be done with RAs or stateless DHCP. The second >should probably be done using some link-local multicast ICMP, but I >need to think more about that. One issue is that one needs to allow >multiple sources for a group in some cases. So I think DAD should >just be offered as a service, whether an application should use the >group in case of duplicates should be up to the application. > >Stig >_______________________________________________________________ >user interface: http://darkwing.uoregon.edu/~llynch/mboned.html >web archive: http://darkwing.uoregon.edu/~llynch/mboned/ > > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon Aug 2 18:54:26 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12220; Mon, 2 Aug 2004 18:54:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Brisg-0000op-Lb; Mon, 02 Aug 2004 15:53:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Briog-0007Fp-Hi for dhcwg@megatron.ietf.org; Mon, 02 Aug 2004 15:49:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00200 for ; Mon, 2 Aug 2004 15:49:48 -0400 (EDT) Received: from mail-out4.apple.com ([17.254.13.23]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BrirZ-00039o-N6 for dhcwg@ietf.org; Mon, 02 Aug 2004 15:52:52 -0400 Received: from mailgate2.apple.com (a17-128-100-204.apple.com [17.128.100.204]) by mail-out4.apple.com (8.12.11/8.12.11) with ESMTP id i72Jp9wF020526 for ; Mon, 2 Aug 2004 12:51:09 -0700 (PDT) Received: from relay4.apple.com (relay4.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.3.6) with ESMTP id ; Mon, 2 Aug 2004 12:49:15 -0700 Received: from [17.202.44.119] (chesh7.apple.com [17.202.44.119]) by relay4.apple.com (8.12.11/8.12.11) with SMTP id i72JnCQg004282; Mon, 2 Aug 2004 12:49:13 -0700 (PDT) Message-Id: <200408021949.i72JnCQg004282@relay4.apple.com> Subject: Re: [dhcwg] Gratuitous ARP in DHCP vs. IPv4 ACD Draft Date: Mon, 2 Aug 2004 12:49:15 -0700 x-sender: cheshire@mail.apple.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Stuart Cheshire To: "Ted Lemon" , Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: DHCP discussion list X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org >I think it's worth having a standard that says what the right thing to >do is. Stuart's draft seemed like a good candidate, but did not get >widespread support from the DHC working group, if I remember correctly. I would say it got luke-warm support. I plan to update the draft, as soon as I get time. > There was also some question as to whether it was even on-topic for >the working group, since it actually changes the semantics of ARP >somewhat. No, it doesn't change ARP semantics in any way. Everything it recommends is 100% consistent with RFC 826. The question of whether to announce via ARP request or response is something that really doesn't matter, and is therefore the thing guaranteed to generate the greatest amount of debate. As John Schnizlein correctly pointed out, "RFC 826 explicitly does not discriminate between request or reply messages before updating its table". Here's what I plan to put in the next draft: Why are ARP Announcements performed using ARP Request packets and not ARP Reply packets? There are two reasons, one is historical precedent, and the other is practicality. The historical precedent is that Gratuitous ARP is described in Stevens Networking [Ste94] as using ARP Request packets. What Stevens describes as Gratuitous ARP is what this document calls an ARP Announcement. BSD Unix, Windows, Mac OS 9, Mac OS X, etc. all use ARP Request packets as described in Stevens. At this stage, trying to mandate that they all switch to using ARP Reply packets would be futile. The practical reason is that ARP Request packets are more likely to work correctly with more existing ARP implementations, some of which may not implement RFC 826 correctly. The Packet Reception rules in RFC 826 state that the opcode is the last thing to check in packet processing, so it really shouldn't matter, but there may be "creative" implementations that have different packet processing depending on the ar$op field, and there are several reasons why these are more likely to accept gratuitous ARP Requests than gratuitous ARP Replies: * An incorrect ARP implementation may expect that ARP Replies are only sent via unicast. RFC 826 does not say this, but an incorrect implementation may assume it, and the "principle of least surprise" dictates that where there are two or more ways to solve a networking problem that are otherwise equally good, the one with the fewest unusual properties is the one likely to have the fewest interoperability problems with existing implementations. An ARP Announcement needs to broadcast information to all hosts on the link. Since ARP Request packets are always broadcast, and ARP Reply packets are not, receiving an ARP Request packet via broadcast is less surprising than receiving an ARP Reply packet via broadcast. * An incorrect ARP implementation may expect that ARP Replies are only received in response to ARP Requests that have been issued recently by that implementation. Unexpected unsolicited Replies may be ignored. * An incorrect ARP implementation may ignore ARP Replies where ar$tha doesn't match its hardware address. * An incorrect ARP implementation may ignore ARP Replies where ar$tpa doesn't match its IP address. In summary, there are more ways that an incorrect ARP implementation might plausibly reject an ARP Reply (which usually occurs as a result of being solicited by the client) than an ARP Request (which is already expected to occur unsolicited). Stuart Cheshire * Wizard Without Portfolio, Apple Computer, Inc. * www.stuartcheshire.org _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon Aug 2 18:54:43 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12259; Mon, 2 Aug 2004 18:54:43 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Brixi-0002ua-Mx; Mon, 02 Aug 2004 15:59:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BriuX-0001Zp-2u for dhcwg@megatron.ietf.org; Mon, 02 Aug 2004 15:55:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00383 for ; Mon, 2 Aug 2004 15:55:51 -0400 (EDT) Received: from mail-out4.apple.com ([17.254.13.23]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BrixR-0003E2-H0 for dhcwg@ietf.org; Mon, 02 Aug 2004 15:58:54 -0400 Received: from mailgate1.apple.com (a17-128-100-225.apple.com [17.128.100.225]) by mail-out4.apple.com (8.12.11/8.12.11) with ESMTP id i72JvETL021830 for ; Mon, 2 Aug 2004 12:57:14 -0700 (PDT) Received: from relay3.apple.com (relay3.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.3.12) with ESMTP id ; Mon, 2 Aug 2004 12:55:20 -0700 Received: from [17.202.44.119] (chesh7.apple.com [17.202.44.119]) by relay3.apple.com (8.12.11/8.12.11) with SMTP id i72JtILu021742; Mon, 2 Aug 2004 12:55:19 -0700 (PDT) Message-Id: <200408021955.i72JtILu021742@relay3.apple.com> Subject: Re: [dhcwg] Gratuitous ARP in DHCP vs. IPv4 ACD Draft Date: Mon, 2 Aug 2004 12:55:21 -0700 x-sender: cheshire@mail.apple.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Stuart Cheshire To: "John Schnizlein" Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: DHCP discussion list X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org >"Ongoing conflict detection and defense" appears an unnecessary >overhead unless hosts make up addresses rather than relying on >a simple allocator such as DHCP to assign them. It would have >been easy enough to define an initial election mechanism for >which host on a subnet, lacking a DHCP server, should provide >simple address allocation. The result would be a tiny amount >of extra work for one host instead of all the "ongoing conflict >detection and defense" for all hosts. I really don't know what overhead you're talking about. There are no extra packets to do ongoing conflict detection (and no change to existing packets). If you mean CPU overhead, there really isn't any, because this is just a tiny refinement to the existing code path for handling received ARP packets. All the draft says is that if you see someone else broadcast an ARP packet, and when you go to update your ARP cache you find that it's YOUR OWN IP address that you're about to update to point to some other machine's hardware address, that's bad news, and you probably shouldn't ignore it. That's all: When you observe that the network is broken, then you should at least alert the user in some way so that they have an idea what is wrong. Stuart Cheshire * Wizard Without Portfolio, Apple Computer, Inc. * www.stuartcheshire.org _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon Aug 2 18:55:24 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12359; Mon, 2 Aug 2004 18:55:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Brjhv-0004VZ-H8; Mon, 02 Aug 2004 16:46:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Brjay-0001tM-3X for dhcwg@megatron.ietf.org; Mon, 02 Aug 2004 16:39:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04115 for ; Mon, 2 Aug 2004 16:39:42 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Brjdt-00046K-1D for dhcwg@ietf.org; Mon, 02 Aug 2004 16:42:46 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-1.cisco.com with ESMTP; 02 Aug 2004 13:40:34 -0700 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i72Kd8Q2018626; Mon, 2 Aug 2004 13:39:08 -0700 (PDT) Received: from rdroms-w2k01.cisco.com ([10.82.217.0]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AKO08550; Mon, 2 Aug 2004 16:39:06 -0400 (EDT) Message-Id: <4.3.2.7.2.20040802163557.02b10d80@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 02 Aug 2004 16:39:04 -0400 To: Stuart Cheshire From: Ralph Droms Subject: Re: [dhcwg] Gratuitous ARP in DHCP vs. IPv4 ACD Draft In-Reply-To: <200408021949.i72JnCQg004282@relay4.apple.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: DHCP discussion list , babatke@ra.rockwell.com, Ted Lemon X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org At 12:49 PM 8/2/2004 -0700, Stuart Cheshire wrote: >The question of whether to announce via ARP request or response is >something that really doesn't matter, and is therefore the thing >guaranteed to generate the greatest amount of debate. As John Schnizlein >correctly pointed out, "RFC 826 explicitly does not discriminate between >request or reply messages before updating its table". If it really doesn't matter, why are we having this discussion? Are you proposing we change DHCP to use an ARP request for announcements? >Here's what I plan to put in the next draft: > >Why are ARP Announcements performed using ARP Request packets and not >ARP Reply packets? > >There are two reasons, one is historical precedent, and the other is >practicality. > >The historical precedent is that Gratuitous ARP is described in Stevens >Networking [Ste94] as using ARP Request packets. It would be better to cite an historical precedent from an RFC. I seem to remember (I looked it up once before but am in the airport without access to reference materials) that Comer describes gratuitous ARP as using an ARP Reply message. >The practical reason is that ARP Request packets are more likely to work >correctly with more existing ARP implementations, some of which may not >implement RFC 826 correctly. Do you have specific examples of stacks that work when an ARP Request is received but not when an ARP Reply is received? - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon Aug 2 21:58:29 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21807; Mon, 2 Aug 2004 21:58:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BroVq-0007Pv-OM; Mon, 02 Aug 2004 21:54:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BroU0-0006ys-RE for dhcwg@megatron.ietf.org; Mon, 02 Aug 2004 21:52:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21645 for ; Mon, 2 Aug 2004 21:52:51 -0400 (EDT) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BroWz-0000hi-87 for dhcwg@ietf.org; Mon, 02 Aug 2004 21:55:57 -0400 Received: from ocean.jinmei.org (unknown [2001:240:5bf:128:5932:46d5:8557:40fa]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id F17BE1525D; Tue, 3 Aug 2004 10:52:42 +0900 (JST) Date: Tue, 03 Aug 2004 10:52:42 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: venaas@uninett.no, tjc@ecs.soton.ac.uk User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: dhcwg@ietf.org Subject: [dhcwg] comments on draft-ietf-dhc-lifetime-01.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Hoping it's not too late, here a couple of comments (or questions, actually) on the draft. 1. I'm still not really sure what the client should do for information when a lifetime expires. For example, the draft says in Section 3.1 that If client has received a lifetime with this option, and contacts server to receive new or update any existing data prior to its expiration, it SHOULD also update data covered by this option. If no new lifetime is received, it MUST behave as if no value was ever provided. I don't understand the scenario. Does this mean the following case? - The client sends an Information-request message, and gets a reply with a DNS server address (call it X) with lifetime of 1 hour. - 30 minutes later, the client happens to resend an Information-request message. This time, it gets a response, but the response does not contain either DNS server address X or a new lifetime. If this is an intended scenario, then what does "behave as if no value was ever provided"? Does it mean the client MUST treat address X as if it had infinite lifetime? Or does this mean the client MUST regard address X expired immediately? Or something else? Also, I don't understand what the client should do with DNS server address X when the lifetime expires and the client does not get any reply for the try to update the information. Should the client invalidate address X? Can/should it continue to use it? Even if the client can update the information of address X with a new lifetime, how can we regard the period from the time when the previous lifetime expires and the time when the client gets the new information? Should we temporarily invalidate the address during the update period? Or Can we continue to use it? Probably the latter makes sense when the client can update the information, but it does not really match my intuition of "expiration"... 2. the usage of the lifetime option for other exchanges than Info-req/Reply exchanges. I'm even not 100% sure if the lifetime can be used for the other types of exchanges. Probably it can according to the draft, but then I'll have several questions on how to use it. For example, the draft says: Before making the request it MUST wait for a random amount of time between 0 and INF_MAX_DELAY. INF_MAX_DELAY is defined in [RFC 3315]. Is this also applies to the other cases even if INF_MAX_DELAY is a dedicated parameter for Info-req? If so, is it really valid? Also, how does the client exactly react to the expiration event for the other cases? For example, consider the following scenario: - the client performs Solicit->Advertise->Request->Reply exchanges, and gets an IPv6 address allocated, a DNS server address X, and an associated lifetime T. - before the timeout "T1" for the allocated address passes, lifetime T expires. In this case, should the client restart the entire session from Solicit? Or should the client send a renew message? If so, the renew message also tries to update the allocated address even if it's too early? Or should the client even start Information-request/Reply exchanges just to update the DNS address information? As an implementor, it's very hard to implement this option with confidence just from this 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-bounces@ietf.org Mon Aug 2 23:44:25 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA26938; Mon, 2 Aug 2004 23:44:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BrqAb-0003R2-JJ; Mon, 02 Aug 2004 23:40:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Brq4Y-0008L5-FJ for dhcwg@megatron.ietf.org; Mon, 02 Aug 2004 23:34:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA26328 for ; Mon, 2 Aug 2004 23:34:40 -0400 (EDT) Received: from tyholt.uninett.no ([158.38.60.10]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Brq7W-0001wJ-Jc for dhcwg@ietf.org; Mon, 02 Aug 2004 23:37:48 -0400 Received: from sverresborg.uninett.no (sverresborg.uninett.no [IPv6:2001:700:e000:0:204:75ff:fee4:423b]) by tyholt.uninett.no (8.12.10/8.12.10) with ESMTP id i733XwV0016523; Tue, 3 Aug 2004 05:33:58 +0200 Received: (from venaas@localhost) by sverresborg.uninett.no (8.12.8/8.12.8/Submit) id i733XvvE020604; Tue, 3 Aug 2004 05:33:57 +0200 X-Authentication-Warning: sverresborg.uninett.no: venaas set sender to Stig.Venaas@uninett.no using -f Date: Tue, 3 Aug 2004 05:33:57 +0200 From: Stig Venaas To: "JINMEI Tatuya / ?$B?@L@C#:H" Message-ID: <20040803033357.GA20506@sverresborg.uninett.no> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Cc: dhcwg@ietf.org, tjc@ecs.soton.ac.uk Subject: [dhcwg] Re: comments on draft-ietf-dhc-lifetime-01.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org On Tue, Aug 03, 2004 at 10:52:42AM +0900, JINMEI Tatuya / ?$B?@L@C#:H wrote: > Hoping it's not too late, here a couple of comments (or questions, > actually) on the draft. > > 1. I'm still not really sure what the client should do for information > when a lifetime expires. > > For example, the draft says in Section 3.1 that > > If client has received a lifetime with this option, and contacts > server to receive new or update any existing data prior to its > expiration, it SHOULD also update data covered by this option. If no > new lifetime is received, it MUST behave as if no value was ever > provided. > > I don't understand the scenario. Does this mean the following case? > > - The client sends an Information-request message, and gets a reply > with a DNS server address (call it X) with lifetime of 1 hour. > - 30 minutes later, the client happens to resend an > Information-request message. This time, it gets a response, but > the response does not contain either DNS server address X or a new > lifetime. > > If this is an intended scenario, then what does "behave as if no > value was ever provided"? Does it mean the client MUST treat > address X as if it had infinite lifetime? Or does this mean the > client MUST regard address X expired immediately? Or something > else? I'm open for anything. But my intention is that client behaves as if it didn't get a lifetime in the first place. That is, just like it would behave if it doesn't know a specific lifetime. Whether it's infinite or not, depends on the client. I don't think this scenario will be common anyway, but we should say something. My thinking is that the last response is the authoritative one, so new lifetime value overrides the old, and no lifetime means ignore the old and behave like you haven't ever seen one. Another option would be to keep using the last seen lifetime until expiry, but I'm not sure that's better. Very happy to see suggestions for alternative behaviour, or for text changes that makes it more clear. > Also, I don't understand what the client should do with DNS server > address X when the lifetime expires and the client does not get any > reply for the try to update the information. Should the client > invalidate address X? Can/should it continue to use it? I think it can be left to the client. The client will retry for a long period of time, and would usually get updated info; the lifetime simply says when to start this process. So you're talking about a rare failure case. I think it's sensible to keep using the info, at least if there is nothing to fall back to. I'm thinking of the option as a hint to the client when it should try to update the info. I'm not sure if we need to specify the failure modes in detail. > Even if the client can update the information of address X with a > new lifetime, how can we regard the period from the time when the > previous lifetime expires and the time when the client gets the new > information? Should we temporarily invalidate the address during > the update period? Or Can we continue to use it? Probably the > latter makes sense when the client can update the information, but > it does not really match my intuition of "expiration"... My intention is definitely that you should continue using it. I guess that should be made clear. > 2. the usage of the lifetime option for other exchanges than > Info-req/Reply exchanges. > > I'm even not 100% sure if the lifetime can be used for the other > types of exchanges. Probably it can according to the draft, but > then I'll have several questions on how to use it. > > For example, the draft says: > > Before making the request it MUST wait for a random amount of time > between 0 and INF_MAX_DELAY. INF_MAX_DELAY is defined in [RFC 3315]. > > Is this also applies to the other cases even if INF_MAX_DELAY is a > dedicated parameter for Info-req? If so, is it really valid? > > Also, how does the client exactly react to the expiration event for > the other cases? For example, consider the following scenario: > > - the client performs Solicit->Advertise->Request->Reply exchanges, > and gets an IPv6 address allocated, a DNS server address X, and an > associated lifetime T. > - before the timeout "T1" for the allocated address passes, lifetime > T expires. In this case, should the client restart the entire > session from Solicit? Or should the client send a renew message? > If so, the renew message also tries to update the allocated > address even if it's too early? Or should the client even start > Information-request/Reply exchanges just to update the DNS address > information? I agree, this needs more thought. So first question is whether we should support stateless only. Stateless is what I'm focusing on, but when I wrote it I thought it could also be of use for stateful case. As it says, the option only specifies a lifetime for options that don't have an associated lifetime. I think doing Information-request/Reply exchange just to update the DNS address information is fine, but would it be a problem to renew everything? > As an implementor, it's very hard to implement this option with > confidence just from this specification... Right. I think this is very good input. I would like to get more input on which behaviour people think is best. Then I'll try to make the text clearer. Stig _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Aug 3 01:42:44 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA03245; Tue, 3 Aug 2004 01:42:44 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BrryV-0007UR-6s; Tue, 03 Aug 2004 01:36:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BrrwK-0006IJ-4w for dhcwg@megatron.ietf.org; Tue, 03 Aug 2004 01:34:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02899 for ; Tue, 3 Aug 2004 01:34:19 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BrrzJ-0003hS-O3 for dhcwg@ietf.org; Tue, 03 Aug 2004 01:37:27 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-1.cisco.com with ESMTP; 02 Aug 2004 22:35:14 -0700 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i735Xh78013603; Mon, 2 Aug 2004 22:33:43 -0700 (PDT) Received: from volzw2k (rtp-vpn3-154.cisco.com [10.82.216.154]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AKO31694; Tue, 3 Aug 2004 01:33:38 -0400 (EDT) From: "Bernie Volz" To: =?iso-8859-1?B?J0pJTk1FSSBUYXR1eWEgLyCQXy2+J0KNxic=?= , "'Christian Strauf'" Subject: RE: [dhcwg] Comments on draft-jinmei-dhc-dhcpv6-clarify-auth-00 Date: Tue, 3 Aug 2004 01:33:37 -0400 Organization: Cisco Message-ID: <000001c4791b$6e25deb0$3e858182@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.5709 Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4939.300 X-Spam-Score: 0.0 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 Content-Transfer-Encoding: quoted-printable Cc: dhcwg@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Personally, I wouldn't call a message that has failed validation to be "unauthenticated". 21.4.2 is pretty clear that these messages should be discarded. You really have three types of messages: - Authenticated - those that passed the validation and have meaning authentication data in them. - Failed validation - those that failed validation, because of replay detection, MAC validation, etc. - Unauthenticated - those that either had no authentication option or = had incomplete authentication information (such as in a client's SOLICIT). = But, read on. Neither clients nor servers would ever want to process "failed = validation" messages. However, they better process the other two. Now, I believe, but could be wrong, that the intent of section 21.4.4.2 = in RFC 3315 (your section 5 of the draft) was that a client could well = receive a message which it can not validate because it doesn't have the required security association information or doesn't support the authentication protocol. This is very different from when it does have this information = and finds that a message does not validate. So, perhaps the "Unauthenticated" category needs another condition - if = the client or server is unable to validate a message because it lacks the = key (for the realm/server) or doesn't support the authentication protocol. - Bernie > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] > On Behalf Of JINMEI Tatuya / =90_=96=BE=92B=8D=C6 > Sent: Monday, July 26, 2004 3:59 AM > To: Christian Strauf > Cc: dhcwg@ietf.org > Subject: Re: [dhcwg] Comments on=20 > draft-jinmei-dhc-dhcpv6-clarify-auth-00 >=20 >=20 > Hello, >=20 > Thanks for your positive feedback, and sorry for the delayed response. >=20 > >>>>> On Tue, 20 Jul 2004 16:23:41 +0200, > >>>>> Christian Strauf said: >=20 > > I paragraph 4. you write: >=20 > > "A reasonable interpretation of the phrase is probably as > follows: a > > DHCPv6 message is called unauthenticated when it fails the > validation > > test described in Section 21.4.2, it does not contain an > > authentication option, or when it includes an authentication option=20 > > but does not have authentication information when necessary." >=20 > > I would propose a minor rephrasing to clear the language up > a little > > (if I understand the above paragraph correctly, the following > > rewording should work): >=20 > > "A reasonable interpretation of the phrase is as follows: a DHCPv6 > > message is called unauthenticated if it fails the validation test=20 > > described in Section 21.4.2, if it does not contain an=20 > authentication > > option, or if it includes an authentication option without the > > necessary authentication information." >=20 > OK. I've modified the local source of the draft with the > suggested change. >=20 > > Minor typos: >=20 > > para 2.: > > -It should also be noted that [RFC3315] does not define how the > > server should do when it receives > > +It should also be noted that [RFC3315] does not > define what the > > server should do when it receives >=20 > > para 3.: > > -3. What If Reply Is Detected > > +3. What If Replay Is Detected >=20 > > para 5.: > > -Apparently this contradicts with the requirement in Section > > 21.4.2. > > +Apparently this contradicts the requirement in Section 21.4.2. >=20 > > para 5.1.: > > -Accepting an non-authenticated > > +Accepting a non-authenticated >=20 > Thanks, fixed in the local source. (The second and fourth > typos should already be fixed in the published version of the=20 > draft. I guess your comments are for a preliminary version=20 > available at my web > page.) >=20 > JINMEI, Tatuya > Communication Platform Lab. > Corporate R&D Center, > Toshiba Corp. > jinmei@isl.rdc.toshiba.co.jp >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg >=20 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Aug 3 01:43:45 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA03352; Tue, 3 Aug 2004 01:43:45 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BrryV-0007Ua-JC; Tue, 03 Aug 2004 01:36:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BrrwQ-0006IN-S3 for dhcwg@megatron.ietf.org; Tue, 03 Aug 2004 01:34:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02908 for ; Tue, 3 Aug 2004 01:34:26 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BrrzQ-0003hr-Hp for dhcwg@ietf.org; Tue, 03 Aug 2004 01:37:34 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 02 Aug 2004 22:36:08 +0000 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i735Xo78013736; Mon, 2 Aug 2004 22:33:51 -0700 (PDT) Received: from volzw2k (rtp-vpn3-154.cisco.com [10.82.216.154]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AKO31695; Tue, 3 Aug 2004 01:33:40 -0400 (EDT) From: "Bernie Volz" To: , , Date: Tue, 3 Aug 2004 01:33:37 -0400 Organization: Cisco Message-ID: <000101c4791b$739a81c0$3e858182@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.5709 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4939.300 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: quoted-printable Cc: "'DHC WG \(E-mail\)'" Subject: [dhcwg] RE: draft-jang-dhc-haopt-00.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Hi. In preparing for the DHC WG meeting I have the following comments on draft-jang-dhc-haopt-00.txt: In DHCPv6 we use 16-bit option (and suboption) codes and lengths. It = would be best if this draft switched to using 16-bit fields for the sub-option = and length fields. Please see RFC 3315 and section 22.17. Note also that for some forms of identification/authentication (opaque type), it is = conceivable that it might exceed a length of 255 bytes! Also, with a 16-bit option number space, we've got plenty of option = number space and it might be best to drop the Home Agent Discovery Option and simply make the two sub-options regular options? Or, is there a reason = you'd prefer having sub-options? For the Home Network Information Sub-option, I assume that if multiple addresses (or prefixes) are specified, the A, reserved, prefix-length = and address/prefix fields are all repeated (18 bytes/address). It might be = good to specify this? - Bernie _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Aug 3 01:44:38 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA03468; Tue, 3 Aug 2004 01:44:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BrryV-0007Uf-T4; Tue, 03 Aug 2004 01:36:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BrrwT-0006IP-0l for dhcwg@megatron.ietf.org; Tue, 03 Aug 2004 01:34:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02911 for ; Tue, 3 Aug 2004 01:34:28 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BrrzS-0003hr-OB for dhcwg@ietf.org; Tue, 03 Aug 2004 01:37:36 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 02 Aug 2004 22:36:10 +0000 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i735Xr78013774; Mon, 2 Aug 2004 22:33:54 -0700 (PDT) Received: from volzw2k (rtp-vpn3-154.cisco.com [10.82.216.154]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AKO31700; Tue, 3 Aug 2004 01:33:50 -0400 (EDT) From: "Bernie Volz" To: Date: Tue, 3 Aug 2004 01:33:37 -0400 Organization: Cisco Message-ID: <000201c4791b$7567eec0$3e858182@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.5709 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4939.300 X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: quoted-printable Cc: "'DHC WG \(E-mail\)'" , olnrao@samsung.com, syam@samsung.com Subject: [dhcwg] RE: draft-daniel-dhc-dhcpv4-tep-conf-01.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Daniel: While preparing for the IETF meeting, I have these comments on the draft-daniel-dhc-dhcpv4-tep-conf-01.txt draft. It's probably best to remove the "reserved" byte from the two options in this draft unless you expect to use this field sometime in the future. Trying to align the remaining fields is really useless since there is no guarentee that the option byte will be aligned on any particular boundry (other than on a byte boundry). The client and server will just have to pack/unpack the data. And, saving the one byte from the option could be useful (as DHCPv4 is often restricted to fairly small packet sizes). And, it might be best to move the prefix-length field to before the IPv6 address (keeping them together).=20 The DHCP messages used in this draft are the DHCPv6 ones - not the = DHCPv4 ones. You really want to use DHCPDISCOVER, DHCPOFFER, DHCPACK and the = like for the message names! I also don't understand the need for the OPTION_CTEP_REQ option. Either = you need to explain this better in the draft (what, for example would the = client fill in in this option) or remove it - why can't the client just simply request this option in a Parameter Request List option? - Bernie _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Aug 3 01:47:21 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA03680; Tue, 3 Aug 2004 01:47:21 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BrryW-0007Uz-Ln; Tue, 03 Aug 2004 01:36:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BrrwT-0006IR-LA for dhcwg@megatron.ietf.org; Tue, 03 Aug 2004 01:34:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02914 for ; Tue, 3 Aug 2004 01:34:29 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BrrzT-0003hz-8Z for dhcwg@ietf.org; Tue, 03 Aug 2004 01:37:36 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 02 Aug 2004 22:36:14 +0000 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i735Xv78013817; Mon, 2 Aug 2004 22:33:57 -0700 (PDT) Received: from volzw2k (rtp-vpn3-154.cisco.com [10.82.216.154]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AKO31703; Tue, 3 Aug 2004 01:33:54 -0400 (EDT) From: "Bernie Volz" To: , , Date: Tue, 3 Aug 2004 01:33:37 -0400 Organization: Cisco Message-ID: <000401c4791b$77efd220$3e858182@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.5709 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4939.300 X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: 7bit Cc: "'DHC WG \(E-mail\)'" Subject: [dhcwg] RE: draft-chowdhury-dhc-bcmcv4-option-00.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 7bit While preparing for the DHC WG meeting, I found these issues with draft-chowdhury-dhc-bcmcv4-option-00.txt: Option-Request-Option is used when it should be Parameter Request List option. In section 2, informative is misspelled (inforamtive). Client is misspelled (as cleint). It is likely a bad idea to specify DNS compression. But this may be something best discussed during the WG meeting or on the mailing list. With the current design, it is only possible for ONE type of encoding to be used (since multiple instances of the option are concatenated). So, you might consider moving the encoding byte before EVERY entry in the list. So, one could have: <0><1><0>domain-name> Section 5 says "DHCPv6" when it should say DHCPv4. A reference in this security issues section to RFC 3118 might also be appropriate? See some of the other existing drafts for what you might add? You might word the IANA Consideration section as: IANA is requested to assign a DHCPv4 option code for the Broadcast Service Controller Domain Name list option, in accordance with RFC 2939. I'm also wondering whether IANA needs to maintain a list of the encoding types? But, hopefully not. - Bernie _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Aug 3 01:48:46 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA03761; Tue, 3 Aug 2004 01:48:46 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BrryX-0007Vo-1q; Tue, 03 Aug 2004 01:36:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BrrwV-0006IY-Hp for dhcwg@megatron.ietf.org; Tue, 03 Aug 2004 01:34:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02917 for ; Tue, 3 Aug 2004 01:34:30 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BrrzV-0003i1-7p for dhcwg@ietf.org; Tue, 03 Aug 2004 01:37:38 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 02 Aug 2004 22:34:39 -0700 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i735Xt78013789; Mon, 2 Aug 2004 22:33:55 -0700 (PDT) Received: from volzw2k (rtp-vpn3-154.cisco.com [10.82.216.154]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AKO31701; Tue, 3 Aug 2004 01:33:52 -0400 (EDT) From: "Bernie Volz" To: , , Date: Tue, 3 Aug 2004 01:33:37 -0400 Organization: Cisco Message-ID: <000301c4791b$76cf1fe0$3e858182@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.5709 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4939.300 X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit Cc: "'DHC WG \(E-mail\)'" Subject: [dhcwg] RE: draft-chowdhury-dhc-bcmcv4-option-00.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 7bit While preparing for the DHC WG meeting, I found these issues with draft-chowdhury-dhc-bcmcv6-option-00.txt: As DHCPv6 doesn't support broadcasting, you're really only able to support multicasting. Not sure if this should be pointed out early in the draft? And, perhaps the option (in the DHCPv6 case) should not use "broadcast" in its name? RFC 3315, section 8, specifically prohibits compression. You should follow that rule. Informative is misspelling in this document as well (inforamtive). - Bernie _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Aug 3 02:00:28 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA04499; Tue, 3 Aug 2004 02:00:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BrsFd-0006DA-7F; Tue, 03 Aug 2004 01:54:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Brs5o-0002C5-BY for dhcwg@megatron.ietf.org; Tue, 03 Aug 2004 01:44:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA03432 for ; Tue, 3 Aug 2004 01:44:07 -0400 (EDT) Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Brs8n-0003qX-R5 for dhcwg@ietf.org; Tue, 03 Aug 2004 01:47:15 -0400 Received: from [66.93.162.248] (0127bhost249.starwoodbroadband.com [12.105.247.249]) by toccata.fugue.com (Postfix) with ESMTP id A10C91B29C3; Tue, 3 Aug 2004 00:42:46 -0500 (CDT) In-Reply-To: <20040803033357.GA20506@sverresborg.uninett.no> References: <20040803033357.GA20506@sverresborg.uninett.no> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Ted Lemon Subject: Re: [dhcwg] Re: comments on draft-ietf-dhc-lifetime-01.txt Date: Mon, 2 Aug 2004 22:43:07 -0700 To: Stig Venaas X-Mailer: Apple Mail (2.618) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org, tjc@ecs.soton.ac.uk X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 7bit I think that we should specify what a client should do when it isn't given a lifetime option, rather than leaving it to the implementor. I would pick a number - say an hour - and recommend that as a default value when no lifetime has been given. I would require that this be configurable on the client. We should make sure that there isn't some corner case where a network administrator that wants a really long lifetime doesn't get hosed by the default value, but I don't think it's okay to just leave it unstated. Sorry for not saying this sooner - I was dithering over whether to make a point of it, and when Jinmei Tatuya stepped in with his observations, that gave me a good excuse to kibbitz. :') _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Aug 3 02:14:18 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA17391; Tue, 3 Aug 2004 02:14:18 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BrsRL-0004fP-0z; Tue, 03 Aug 2004 02:06:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BrsKx-0007tX-9P for dhcwg@megatron.ietf.org; Tue, 03 Aug 2004 01:59:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA04170 for ; Tue, 3 Aug 2004 01:59:46 -0400 (EDT) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BrsNt-00046w-Mh for dhcwg@ietf.org; Tue, 03 Aug 2004 02:02:54 -0400 Received: from ocean.jinmei.org (unknown [2001:240:5bf:128:85e5:b60e:c1e:7e67]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id BFDF71525D; Tue, 3 Aug 2004 14:59:37 +0900 (JST) Date: Tue, 03 Aug 2004 14:59:39 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: "Bernie Volz" Subject: Re: [dhcwg] Comments on draft-jinmei-dhc-dhcpv6-clarify-auth-00 In-Reply-To: <000001c4791b$6e25deb0$3e858182@amer.cisco.com> References: <000001c4791b$6e25deb0$3e858182@amer.cisco.com> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: dhcwg@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org >>>>> On Tue, 3 Aug 2004 01:33:37 -0400, >>>>> "Bernie Volz" said: > Personally, I wouldn't call a message that has failed validation to be > "unauthenticated". 21.4.2 is pretty clear that these messages should be > discarded. Yes. I think the main problem is in Section 21.4.4.2. > You really have three types of messages: > - Authenticated - those that passed the validation and have meaning > authentication data in them. > - Failed validation - those that failed validation, because of replay > detection, MAC validation, etc. > - Unauthenticated - those that either had no authentication option or had > incomplete authentication information (such as in a client's SOLICIT). But, > read on. > Neither clients nor servers would ever want to process "failed validation" > messages. However, they better process the other two. > Now, I believe, but could be wrong, that the intent of section 21.4.4.2 in > RFC 3315 (your section 5 of the draft) was that a client could well receive > a message which it can not validate because it doesn't have the required > security association information or doesn't support the authentication > protocol. This is very different from when it does have this information and > finds that a message does not validate. I think I agree with you on this (I believe this is essentially the same as the resolution I suggested in my draft). I guess it's basically an editorial issue, not a serious protocol problem. Here is the RFC's text (from section 21.4.4.2): Client behavior, if no Advertise messages include authentication information or pass the validation test, is controlled by local policy on the client. According to client policy, the client MAY choose to respond to an Advertise message that has not been authenticated. The first sentence indicates: if all Advertise messages are "Failed validation (from your categorization)" messages, client behavior is controlled by local policy on the client. so far, there's nothing odd. But the next sentence is ambiguous on the meaning of "message that has not been authenticated". Natural interpretation in this context should however be "messages that do not include authentication information or pass the validation test", i.e., "Failed validation" or "Unauthenticated" messages in your categorization. From this interpretation, the client MAY accept a "Failed validation" Advertise message, conflicting with the sense of Section 21.4.2. Section 21.4.4.2 then continues to the next paragraph: The decision to set local policy to accept unauthenticated messages should be made with care. Accepting an unauthenticated Advertise message can make the client vulnerable to spoofing and other attacks. [...] Now, we see another unclear wording "unauthenticated messages" (see section 4 of my draft). Again, in this context, the natural interpretation should be as follows: "messages that do not include authentication information or pass the validation test" (2nd paragraph of 21.4.4.2) = "message that has not been authenticated" (2nd paragraph of 21.4.4.2) = "unauthenticated messages" (3rd paragraph of 21.4.4.2) = "Failed validation" or "Unauthenticated" messages (from your definition) Then the result of this interpretation contradicts what is described in Section 21.4.2. Once we agree on that Section 21.4.2 should be honored, the resolution would be minor editorial clarification in Section 21.4.4.2. 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-bounces@ietf.org Tue Aug 3 09:39:15 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08362; Tue, 3 Aug 2004 09:39:15 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BrzSU-000801-6u; Tue, 03 Aug 2004 09:36:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BrzRL-0007ty-TW for dhcwg@megatron.ietf.org; Tue, 03 Aug 2004 09:34:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08108 for ; Tue, 3 Aug 2004 09:34:50 -0400 (EDT) Received: from ihemail1.lucent.com ([192.11.222.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BrzUN-0001Xy-Ox for dhcwg@ietf.org; Tue, 03 Aug 2004 09:38:03 -0400 Received: from homail.ho.lucent.com (h135-17-192-10.lucent.com [135.17.192.10]) by ihemail1.lucent.com (8.12.11/8.12.11) with ESMTP id i73DY6Fg007238; Tue, 3 Aug 2004 08:34:06 -0500 (CDT) Received: from kraken.mh.lucent.com by homail.ho.lucent.com (8.11.7+Sun/EMS-1.5 sol2) id i73DY5C19387; Tue, 3 Aug 2004 09:34:05 -0400 (EDT) From: Joe Quanaim To: JINMEI Tatuya / =?utf-8?q?=E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89=09?=, venaas@uninett.no, tjc@ecs.soton.ac.uk Subject: Re: [dhcwg] comments on draft-ietf-dhc-lifetime-01.txt Date: Tue, 3 Aug 2004 09:33:29 -0400 User-Agent: KMail/1.5.4 References: In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200408030929.31655.jdq@lucent.com> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: quoted-printable Cc: dhcwg@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jdq@lucent.com List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: quoted-printable JINMEI Tatuya / =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 wrote: [...] > 2. the usage of the lifetime option for other exchanges than > Info-req/Reply exchanges. > > I'm even not 100% sure if the lifetime can be used for the other > types of exchanges. Probably it can according to the draft, but > then I'll have several questions on how to use it. > > For example, the draft says: > > Before making the request it MUST wait for a random amount of time > between 0 and INF_MAX_DELAY. INF_MAX_DELAY is defined in [RFC 3315]. > > Is this also applies to the other cases even if INF_MAX_DELAY is a > dedicated parameter for Info-req? If so, is it really valid? Isn't this duplicating rfc 3315? Removing it would prevent any subsequent= =20 updates to rfc 3315 from conflicing with this statement. > Also, how does the client exactly react to the expiration event for > the other cases? For example, consider the following scenario: > > - the client performs Solicit->Advertise->Request->Reply exchanges, > and gets an IPv6 address allocated, a DNS server address X, and an > associated lifetime T. > - before the timeout "T1" for the allocated address passes, lifetime > T expires. In this case, should the client restart the entire > session from Solicit? Or should the client send a renew message? > If so, the renew message also tries to update the allocated > address even if it's too early? Or should the client even start > Information-request/Reply exchanges just to update the DNS address > information? Using this option in a stateful transaction makes things more complicated. = =20 The lifetime option can expire between t1, t2, or the valid lifetime of an= =20 address. As Jinmei Tatuya notes, what should the client be expected to do?= =20 Restart the message exchange; just do an information-request; etc. Any negotiated value for t1, t2, or valid lifetime of an address could take= =20 precedence over the lifetime option. This essentially makes the option=20 stateless only, but it simplifies the resulting changes to a client=20 implementation. Joe Quanaim. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Aug 3 10:15:02 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11004; Tue, 3 Aug 2004 10:15:02 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bs00X-0007Ye-Kd; Tue, 03 Aug 2004 10:11:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BrzxH-0006CV-P7 for dhcwg@megatron.ietf.org; Tue, 03 Aug 2004 10:07:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09979 for ; Tue, 3 Aug 2004 10:07:50 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bs00M-0001xk-9B for dhcwg@ietf.org; Tue, 03 Aug 2004 10:11:03 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 03 Aug 2004 07:08:04 -0700 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i73E717a021331 for ; Tue, 3 Aug 2004 07:07:17 -0700 (PDT) Received: from rdroms-w2k01.cisco.com (rtp-vpn1-255.cisco.com [10.82.224.255]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AKO47046; Tue, 3 Aug 2004 10:06:57 -0400 (EDT) Message-Id: <4.3.2.7.2.20040803100416.02062638@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 03 Aug 2004 10:04:33 -0400 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 2870a44b67ee17965ce5ad0177e150f4 Subject: [dhcwg] jabber during dhc WG meeting X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org For more information, go to http://xmpp.org/ietf-chat.html - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Aug 3 11:26:33 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15404; Tue, 3 Aug 2004 11:26:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bs17i-0007Uz-9N; Tue, 03 Aug 2004 11:22:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bs163-0007OQ-6K for dhcwg@megatron.ietf.org; Tue, 03 Aug 2004 11:20:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15081 for ; Tue, 3 Aug 2004 11:20:56 -0400 (EDT) Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bs197-00030R-TA for dhcwg@ietf.org; Tue, 03 Aug 2004 11:24:11 -0400 Received: from [130.129.130.32] (opene-130-129-130-32.ietf60.ietf.org [130.129.130.32]) by toccata.fugue.com (Postfix) with ESMTP id B5E871B22D6 for ; Tue, 3 Aug 2004 10:20:10 -0500 (CDT) Mime-Version: 1.0 (Apple Message framework v618) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed To: dhcwg@ietf.org From: Ted Lemon Date: Tue, 3 Aug 2004 08:20:53 -0700 X-Mailer: Apple Mail (2.618) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7bit Subject: [dhcwg] Comments on draft-chowdhury-dhc-bcmcv4-option X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 7bit Reading over this draft, a couple of things jump out at me. The first is that all the text describing how BCMCS works should probably be left out. I would put in a one-paragraph description of what BCMCS does. Putting in a big diagram and a detailed description doesn't help the implementor, and the description didn't actually tell me much about what the protocol does. The other things is, do you really need to send FQDNs? They take up a lot of space in a DHCP packet. I would rather see you send IPv4 address/port number tuples if you want to be able to specify the port. This would also eliminate the need to consume two option codes, which in DHCPv4 is theoretically an issue. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Aug 3 11:36:40 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15977; Tue, 3 Aug 2004 11:36:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bs1GT-00081b-CL; Tue, 03 Aug 2004 11:31:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bs1Dl-0007tI-7p for dhcwg@megatron.ietf.org; Tue, 03 Aug 2004 11:28:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15636 for ; Tue, 3 Aug 2004 11:28:55 -0400 (EDT) Received: from tyholt.uninett.no ([158.38.60.10]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bs1Gq-00037c-Az for dhcwg@ietf.org; Tue, 03 Aug 2004 11:32:09 -0400 Received: from sverresborg.uninett.no (sverresborg.uninett.no [IPv6:2001:700:e000:0:204:75ff:fee4:423b]) by tyholt.uninett.no (8.12.10/8.12.10) with ESMTP id i73FSGUO013246; Tue, 3 Aug 2004 17:28:17 +0200 Received: (from venaas@localhost) by sverresborg.uninett.no (8.12.8/8.12.8/Submit) id i73FSFl2026541; Tue, 3 Aug 2004 17:28:15 +0200 X-Authentication-Warning: sverresborg.uninett.no: venaas set sender to Stig.Venaas@uninett.no using -f Date: Tue, 3 Aug 2004 17:28:15 +0200 From: Stig Venaas To: Ted Lemon Subject: Re: [dhcwg] Re: comments on draft-ietf-dhc-lifetime-01.txt Message-ID: <20040803152815.GA26389@sverresborg.uninett.no> References: <20040803033357.GA20506@sverresborg.uninett.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: dhcwg@ietf.org, tjc@ecs.soton.ac.uk X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org On Mon, Aug 02, 2004 at 10:43:07PM -0700, Ted Lemon wrote: > I think that we should specify what a client should do when it isn't > given a lifetime option, rather than leaving it to the implementor. I > would pick a number - say an hour - and recommend that as a default > value when no lifetime has been given. I would require that this be > configurable on the client. We should make sure that there isn't some > corner case where a network administrator that wants a really long > lifetime doesn't get hosed by the default value, but I don't think it's > okay to just leave it unstated. First, if the option is implemented by both client and server, I would expect it to always be used. One hour sounds rather short to me, normally I would expect several days between each change. Question is then how bad it is if there is a change and it takes some time before the client learns of it. But why wouldn't you use this option if you worry about that. I would expect most servers to support this option... I think I would choose 6 hours or something as default, but that's just my personal feeling. Stig _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Aug 3 11:55:13 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16913; Tue, 3 Aug 2004 11:55:13 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bs1T0-0000ke-9M; Tue, 03 Aug 2004 11:44:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bs1OV-0000I8-0T for dhcwg@megatron.ietf.org; Tue, 03 Aug 2004 11:40:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16177 for ; Tue, 3 Aug 2004 11:40:00 -0400 (EDT) Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bs1RZ-0003HT-TE for dhcwg@ietf.org; Tue, 03 Aug 2004 11:43:15 -0400 Received: from [130.129.130.32] (opene-130-129-130-32.ietf60.ietf.org [130.129.130.32]) by toccata.fugue.com (Postfix) with ESMTP id 841EC1B221E for ; Tue, 3 Aug 2004 10:39:15 -0500 (CDT) Mime-Version: 1.0 (Apple Message framework v618) To: dhcwg@ietf.org Message-Id: <60325F40-E563-11D8-982E-000A95D9C74C@nominum.com> Content-Type: multipart/mixed; boundary=Apple-Mail-2--576234703 From: Ted Lemon Date: Tue, 3 Aug 2004 08:39:58 -0700 X-Mailer: Apple Mail (2.618) X-Spam-Score: 0.0 (/) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 Subject: [dhcwg] comments on draft-daniel-dhc-dhcpv4-tep-conf X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org --Apple-Mail-2--576234703 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit This draft breaks a couple of existing assumptions about DHCP. First, it requires that the option be send only in a DHCPACK message in response to a DHCPREQUEST message. Normally the DHCPOFFER message contains the same options as the DHCPACK message. So I would strongly suggest that this restriction be relaxed to allow the DHCPOFFER to contain this option. Secondly, the draft allows multiple copies to appear. This contradicts the Encoding Long Options RFC (sorry, can't remember the number off the top of my head), which would create a huge headache for DHCP server and client implementations. So please change the option so that there can be only one of them, and that if multiple values need to be sent, that is encoded within the option. Also, there is quite a bit of information in this document that goes beyond describing the format of the option. It looks like you're defining a new protocol. If you are not defining a new protocol, it would be better to refer to the document that defines the protocol, and remove the words from this document that describe that protocol in detail. If you are defining a new protocol here, this draft probably needs to be reviewed by the working group responsible for that area as well as by the DHC working group. (sorry if this has already been said) I've enclosed a couple of diffs for some minor editorial suggestions. --Apple-Mail-2--576234703 Content-Type: application/octet-stream; x-unix-mode=0640; name="draft-daniel-dhc-dhcpv4-tep-conf-comments" Content-Disposition: attachment; filename=draft-daniel-dhc-dhcpv4-tep-conf-comments Content-Transfer-Encoding: 7bit *** draft-daniel-dhc-dhcpv4-tep-conf-01.txt Thu Jul 8 12:50:00 2004 --- draft-daniel-dhc-dhcpv4-tep-conf-01-hacked.txt Tue Aug 3 08:37:19 2004 *************** *** 42,48 **** The intent of this draft is to provide a solution to automate tunnel end-point configuration for a configured IPv6-over-IPv4 tunnel. This ! uses a DHCPv4 option to percolate the tunnel end-point configuration information. This is very useful to connect a newly deployed native IPv6 cloud to other existing IPv6 networks using IPv4 backbone as well as to connect isolated dual-stack IPv4/IPv6 nodes to IPv6 --- 42,48 ---- The intent of this draft is to provide a solution to automate tunnel end-point configuration for a configured IPv6-over-IPv4 tunnel. This ! uses a DHCPv4 option to distribute the tunnel end-point configuration information. This is very useful to connect a newly deployed native IPv6 cloud to other existing IPv6 networks using IPv4 backbone as well as to connect isolated dual-stack IPv4/IPv6 nodes to IPv6 *************** *** 68,81 **** such IPv6 networks or hosts without manual configuration. To configure IPv6-over-IPv4 tunnel between isolated IPv6 networks, ! administrator typically configure available tunnels by hand. That ! is, imagine that we want to connect 10 sites together from our border router using full-mesh configured tunneling. We will have to ! set up 9 tunnels in each site, 9*10 tunnels in total. Thus we need a solution to automate the process of building configured tunnels at border routers connected through IPv4 backbone. ! This introduces new DHCPv4 options to distribute the configuration tunnel information automatically. --- 68,82 ---- such IPv6 networks or hosts without manual configuration. To configure IPv6-over-IPv4 tunnel between isolated IPv6 networks, ! administrator typically configure available tunnels by hand. Con- ! sider the case where we want to connect 10 sites together from our border router using full-mesh configured tunneling. We will have to ! set up 9 tunnels in each site, 9*10 tunnels in total. To address ! cases like this we need a solution to automate the process of building configured tunnels at border routers connected through IPv4 backbone. ! This document introduces new DHCPv4 options to distribute the configuration tunnel information automatically. *************** *** 238,247 **** - Appearance of this option: The Configured Tunnel End Point Reply Option MUST NOT appear in any ! message other than the DHCPREPLY message in correspond to the Configured Tunnel End Point Request Option with DHCPREQUEST message. ! This option MAY appear multiple times in DHCPREPLY message. --- 239,248 ---- - Appearance of this option: The Configured Tunnel End Point Reply Option MUST NOT appear in any ! message other than the DHCPACK message that corresponds to the Configured Tunnel End Point Request Option with DHCPREQUEST message. ! This option MAY appear multiple times in DHCPACK message. --Apple-Mail-2--576234703 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --Apple-Mail-2--576234703-- From dhcwg-bounces@ietf.org Tue Aug 3 12:44:29 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20186; Tue, 3 Aug 2004 12:44:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bs2DS-0000JK-UO; Tue, 03 Aug 2004 12:32:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bs2Au-0008O6-Dx for dhcwg@megatron.ietf.org; Tue, 03 Aug 2004 12:30:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19258 for ; Tue, 3 Aug 2004 12:30:01 -0400 (EDT) Received: from zrtps06s.nortelnetworks.com ([47.140.48.50]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bs2E0-0004CR-5Y for dhcwg@ietf.org; Tue, 03 Aug 2004 12:33:17 -0400 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps06s.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i73GTUx01392; Tue, 3 Aug 2004 12:29:30 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 3 Aug 2004 12:29:29 -0400 Message-ID: <591B780D9676844E8A704B5B013FFE920218AE03@zrc2hxm1.corp.nortel.com> From: "Kuntal Chowdhury" To: Ted Lemon , dhcwg@ietf.org Subject: RE: [dhcwg] Comments on draft-chowdhury-dhc-bcmcv4-option Date: Tue, 3 Aug 2004 12:29:21 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Ted, Thanks for your comment/suggestion. We added the informative diagram to at least give the reader some idea what B-cast and M-cast service typically include. If you think a simplified diagram will suffice we can do that in the next revision. FQDN is used to give the operator flexibility in deploying the service. Some operators would like to use DNS infrastructure to distribute the most appropriate controller for a broadcast program. Regards, Kuntal >-----Original Message----- >From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] >On Behalf Of Ted Lemon >Sent: Tuesday, August 03, 2004 10:21 AM >To: dhcwg@ietf.org >Subject: [dhcwg] Comments on draft-chowdhury-dhc-bcmcv4-option > > >Reading over this draft, a couple of things jump out at me. >The first >is that all the text describing how BCMCS works should >probably be left >out. I would put in a one-paragraph description of what >BCMCS does. >Putting in a big diagram and a detailed description doesn't help the >implementor, and the description didn't actually tell me much about >what the protocol does. > >The other things is, do you really need to send FQDNs? They >take up a >lot of space in a DHCP packet. I would rather see you send IPv4 >address/port number tuples if you want to be able to specify >the port. > This would also eliminate the need to consume two option >codes, which >in DHCPv4 is theoretically an issue. > > >_______________________________________________ >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-bounces@ietf.org Tue Aug 3 13:12:04 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22652; Tue, 3 Aug 2004 13:12:04 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bs2j9-00054w-5t; Tue, 03 Aug 2004 13:05:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bs2U6-0002kL-Ig for dhcwg@megatron.ietf.org; Tue, 03 Aug 2004 12:49:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20649 for ; Tue, 3 Aug 2004 12:49:52 -0400 (EDT) Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bs2XA-0004Zw-Qj for dhcwg@ietf.org; Tue, 03 Aug 2004 12:53:07 -0400 Received: from [130.129.130.32] (opene-130-129-130-32.ietf60.ietf.org [130.129.130.32]) by toccata.fugue.com (Postfix) with ESMTP id 7B1571B225B for ; Tue, 3 Aug 2004 11:49:03 -0500 (CDT) Mime-Version: 1.0 (Apple Message framework v618) Content-Transfer-Encoding: 7bit Message-Id: <7C7FE7F6-E565-11D8-982E-000A95D9C74C@nominum.com> Content-Type: text/plain; charset=US-ASCII; format=flowed To: dhcwg@ietf.org From: Ted Lemon Date: Tue, 3 Aug 2004 08:55:05 -0700 X-Mailer: Apple Mail (2.618) X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 7bit Subject: [dhcwg] Comment on a couple of option drafts that have gone by... X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 7bit I've noticed that a couple of drafts have gone by that require the client to send an option to the server so that the server will know what to send back to the client. In each of these cases, this seems like a reasonable way to solve the problem. However, I would like to point out one problem with this, and request that the authors of these drafts (I'm thinking specifically of the haopt and tep drafts) add some text to talk about what the client should send in the parameter request list. Currently the FQDN option protocol specification requires the server to send back an FQDN option even if the client sends a parameter request list and doesn't include the FQDN option code in that list. Please specify in your drafts that the DHCP server must not send the reply option unless either no parameter request list is sent, or unless the option code for the option appears in the parameter request list. Suggested text: The DHCP server MUST NOT send the Foo option if the client sends a Parameter Request List option and the code for the Foo option does not appear in the parameter request list, EVEN IF the Foo-request option appears in the client's list of options. The reason for making this request is that we have to have special case code in the DHCP server to make sure the FQDN option gets sent even if not requested, and this adds needless complexity. If you add text like what I've suggested above, you are not placing this requirement on the server - the server can just process the option normally when constructing the reply. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Aug 3 13:12:52 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22725; Tue, 3 Aug 2004 13:12:52 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bs2j9-00055H-IP; Tue, 03 Aug 2004 13:05:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bs2U7-0002kH-KV for dhcwg@megatron.ietf.org; Tue, 03 Aug 2004 12:49:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20646 for ; Tue, 3 Aug 2004 12:49:51 -0400 (EDT) Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bs2XB-0004Zy-K9 for dhcwg@ietf.org; Tue, 03 Aug 2004 12:53:07 -0400 Received: from [130.129.130.32] (opene-130-129-130-32.ietf60.ietf.org [130.129.130.32]) by toccata.fugue.com (Postfix) with ESMTP id AB0981B2298; Tue, 3 Aug 2004 11:49:03 -0500 (CDT) In-Reply-To: <200408030929.31655.jdq@lucent.com> References: <200408030929.31655.jdq@lucent.com> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <1FCC835A-E56D-11D8-982E-000A95D9C74C@fugue.com> Content-Transfer-Encoding: 7bit From: Ted Lemon Subject: Re: [dhcwg] comments on draft-ietf-dhc-lifetime-01.txt Date: Tue, 3 Aug 2004 09:49:45 -0700 To: jdq@lucent.com X-Mailer: Apple Mail (2.618) X-Spam-Score: 0.0 (/) X-Scan-Signature: 2870a44b67ee17965ce5ad0177e150f4 Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org, tjc@ecs.soton.ac.uk, venaas@uninett.no X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 7bit IMHO, this draft should be folded into any future update of RFC3315. So it's okay to contradict 3315 if that is the correct thing to, although we shouldn't do it gratuitously. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Aug 3 13:14:02 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22849; Tue, 3 Aug 2004 13:14:02 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bs2jB-00056h-6K; Tue, 03 Aug 2004 13:05:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bs2WY-0002yZ-Q7 for dhcwg@megatron.ietf.org; Tue, 03 Aug 2004 12:52:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20921 for ; Tue, 3 Aug 2004 12:52:24 -0400 (EDT) Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bs2Ze-0004cw-J9 for dhcwg@ietf.org; Tue, 03 Aug 2004 12:55:39 -0400 Received: from [130.129.130.32] (opene-130-129-130-32.ietf60.ietf.org [130.129.130.32]) by toccata.fugue.com (Postfix) with ESMTP id 73E7C1B20C2; Tue, 3 Aug 2004 11:51:38 -0500 (CDT) In-Reply-To: <591B780D9676844E8A704B5B013FFE920218AE03@zrc2hxm1.corp.nortel.com> References: <591B780D9676844E8A704B5B013FFE920218AE03@zrc2hxm1.corp.nortel.com> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <7D34752F-E56D-11D8-982E-000A95D9C74C@nominum.com> Content-Transfer-Encoding: 7bit From: Ted Lemon Subject: Re: [dhcwg] Comments on draft-chowdhury-dhc-bcmcv4-option Date: Tue, 3 Aug 2004 09:52:22 -0700 To: "Kuntal Chowdhury" X-Mailer: Apple Mail (2.618) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 7bit On Aug 3, 2004, at 9:29 AM, Kuntal Chowdhury wrote: > FQDN is used to give the operator flexibility in deploying the > service. Some > operators would like to use DNS infrastructure to distribute the most > appropriate controller for a broadcast program. If you fill up the DHCP packet, the operator loses that flexibility. An easy way to provide the same flexibility is to do the lookup on the DHCP server. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Aug 3 13:21:18 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23446; Tue, 3 Aug 2004 13:21:18 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bs2lZ-0005cX-AI; Tue, 03 Aug 2004 13:07:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bs2gv-0004lJ-Kq for dhcwg@megatron.ietf.org; Tue, 03 Aug 2004 13:03:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21963 for ; Tue, 3 Aug 2004 13:03:06 -0400 (EDT) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bs2k1-0004uB-JT for dhcwg@ietf.org; Tue, 03 Aug 2004 13:06:22 -0400 Received: from ocean.jinmei.org (unknown [2001:240:5bf:128:53:a078:f69:a107]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 56C9B1525D; Wed, 4 Aug 2004 02:03:02 +0900 (JST) Date: Wed, 04 Aug 2004 02:03:04 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Stig.Venaas@uninett.no, tjc@ecs.soton.ac.uk User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: dhcwg@ietf.org Subject: [dhcwg] one more comment about the lifetime option X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org I forgot to mention this one: Is it possible to specify different lifetimes for different instances of stateless information? For example, people may want to specify different lifetimes for recursive DNS server addresses and for SIP server addresses. 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-bounces@ietf.org Tue Aug 3 13:47:49 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26108; Tue, 3 Aug 2004 13:47:49 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bs2zI-0008T3-S0; Tue, 03 Aug 2004 13:22:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bs2sr-00072W-By for dhcwg@megatron.ietf.org; Tue, 03 Aug 2004 13:15:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22970 for ; Tue, 3 Aug 2004 13:15:26 -0400 (EDT) Received: from tyholt.uninett.no ([158.38.60.10]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bs2vw-00059X-D2 for dhcwg@ietf.org; Tue, 03 Aug 2004 13:18:42 -0400 Received: from sverresborg.uninett.no (sverresborg.uninett.no [IPv6:2001:700:e000:0:204:75ff:fee4:423b]) by tyholt.uninett.no (8.12.10/8.12.10) with ESMTP id i73HEmUO002014; Tue, 3 Aug 2004 19:14:48 +0200 Received: (from venaas@localhost) by sverresborg.uninett.no (8.12.8/8.12.8/Submit) id i73HElX6027873; Tue, 3 Aug 2004 19:14:47 +0200 X-Authentication-Warning: sverresborg.uninett.no: venaas set sender to Stig.Venaas@uninett.no using -f Date: Tue, 3 Aug 2004 19:14:47 +0200 From: Stig Venaas To: "JINMEI Tatuya / ?$B?@L@C#:H" Message-ID: <20040803171447.GA27805@sverresborg.uninett.no> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: dhcwg@ietf.org, tjc@ecs.soton.ac.uk Subject: [dhcwg] Re: one more comment about the lifetime option X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org On Wed, Aug 04, 2004 at 02:03:04AM +0900, JINMEI Tatuya / ?$B?@L@C#:H wrote: > I forgot to mention this one: > > Is it possible to specify different lifetimes for different instances > of stateless information? For example, people may want to specify > different lifetimes for recursive DNS server addresses and for SIP > server addresses. We should keep this simple. If e.g. recursive server data needs to be updated more frequently than SIP data, I would simply say that lifetime should be the shortest. When you contact server to update DNS data, you can at the same time update other data like SIP server address. Note that the draft says: If client has received a lifetime with this option, and contacts server to receive new or update any existing data prior to its expiration, it SHOULD also update data covered by this option. If no new lifetime is received, it MUST behave as if no value was ever provided. In line with that SHOULD, there's no good reason to have multiple lifetimes. Stig _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Aug 3 13:48:49 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26301; Tue, 3 Aug 2004 13:48:49 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bs328-0000Ja-07; Tue, 03 Aug 2004 13:25:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bs2wq-0007hT-Ja for dhcwg@megatron.ietf.org; Tue, 03 Aug 2004 13:19:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23271 for ; Tue, 3 Aug 2004 13:19:33 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bs2zx-0005Ep-O4 for dhcwg@ietf.org; Tue, 03 Aug 2004 13:22:50 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 03 Aug 2004 10:19:52 -0700 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i73HIxme013870; Tue, 3 Aug 2004 10:18:59 -0700 (PDT) Received: from volzw2k (ams-clip-vpn-dhcp4106.cisco.com [10.61.80.9]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AKO64338; Tue, 3 Aug 2004 13:18:54 -0400 (EDT) From: "Bernie Volz" To: , "'JINMEI Tatuya / ???? '" , , Subject: RE: [dhcwg] comments on draft-ietf-dhc-lifetime-01.txt Date: Tue, 3 Aug 2004 13:20:22 -0400 Organization: Cisco Message-ID: <000201c4797e$2a5f37e0$46828182@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.5709 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4939.300 In-Reply-To: <200408030929.31655.jdq@lucent.com> Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 7bit I too would recommend that this option only be used with stateless (Information-Request/Reply). It does not apply to stateful - in stateful, even if there are no T1/T2 times (i.e., no IA_NA option), the client will need to do something when it no longer has addresses so it will get new information from the server. When the lifetime expires, the client should simply initiate an Information-Request message to the server(s). It should retry this 'forever' based on the Information-Request retransmission policy specified in RFC 3315 (see 18.1.5). When a (valid) REPLY is received, the client should remove its existing information and install the new information. If it doesn't receive a (valid) REPLY, it keeps its existing information. I too would support a default lifetime if no lifetime option is received. 6 to 12 hours seems a more reasonable value to me than 1 hour. Note also that I believe the lifetime is just one input ... The DHCP client can use other information, such as expiration of prefixes for configured items, to decide whether to refresh information (though this would require the DHCP client to poll the system periodically or when certain events occur which may or may not be practical). - Bernie > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] > On Behalf Of Joe Quanaim > Sent: Tuesday, August 03, 2004 9:33 AM > To: JINMEI Tatuya / ???? ; venaas@uninett.no; tjc@ecs.soton.ac.uk > Cc: dhcwg@ietf.org > Subject: Re: [dhcwg] comments on draft-ietf-dhc-lifetime-01.txt > > > > JINMEI Tatuya / $B?@L@C#:H(B wrote: > [...] > > 2. the usage of the lifetime option for other exchanges than > > Info-req/Reply exchanges. > > > > I'm even not 100% sure if the lifetime can be used for the other > > types of exchanges. Probably it can according to the draft, but > > then I'll have several questions on how to use it. > > > > For example, the draft says: > > > > Before making the request it MUST wait for a random > amount of time > > between 0 and INF_MAX_DELAY. INF_MAX_DELAY is defined in [RFC > > 3315]. > > > > Is this also applies to the other cases even if INF_MAX_DELAY is a > > dedicated parameter for Info-req? If so, is it really valid? > > Isn't this duplicating rfc 3315? Removing it would prevent > any subsequent > updates to rfc 3315 from conflicing with this statement. > > > Also, how does the client exactly react to the expiration > event for > > the other cases? For example, consider the following scenario: > > > > - the client performs Solicit->Advertise->Request->Reply > exchanges, > > and gets an IPv6 address allocated, a DNS server > address X, and an > > associated lifetime T. > > - before the timeout "T1" for the allocated address > passes, lifetime > > T expires. In this case, should the client restart the entire > > session from Solicit? Or should the client send a > renew message? > > If so, the renew message also tries to update the allocated > > address even if it's too early? Or should the client even start > > Information-request/Reply exchanges just to update the > DNS address > > information? > > Using this option in a stateful transaction makes things more > complicated. > The lifetime option can expire between t1, t2, or the valid > lifetime of an > address. As Jinmei Tatuya notes, what should the client be > expected to do? > Restart the message exchange; just do an information-request; etc. > > Any negotiated value for t1, t2, or valid lifetime of an > address could take > precedence over the lifetime option. This essentially makes > the option > stateless only, but it simplifies the resulting changes to a client > implementation. > > Joe Quanaim. > > > _______________________________________________ > 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-bounces@ietf.org Tue Aug 3 14:27:29 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29544; Tue, 3 Aug 2004 14:27:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bs3p9-0002on-7q; Tue, 03 Aug 2004 14:15:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bs3Xc-0007FY-4C for dhcwg@megatron.ietf.org; Tue, 03 Aug 2004 13:57:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27049 for ; Tue, 3 Aug 2004 13:57:35 -0400 (EDT) Received: from tyholt.uninett.no ([158.38.60.10]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bs3ai-0006GT-03 for dhcwg@ietf.org; Tue, 03 Aug 2004 14:00:49 -0400 Received: from sverresborg.uninett.no (sverresborg.uninett.no [IPv6:2001:700:e000:0:204:75ff:fee4:423b]) by tyholt.uninett.no (8.12.10/8.12.10) with ESMTP id i73Hv2UO010853 for ; Tue, 3 Aug 2004 19:57:02 +0200 Received: (from venaas@localhost) by sverresborg.uninett.no (8.12.8/8.12.8/Submit) id i73Hv2Gk028380 for dhcwg@ietf.org; Tue, 3 Aug 2004 19:57:02 +0200 X-Authentication-Warning: sverresborg.uninett.no: venaas set sender to Stig.Venaas@uninett.no using -f Date: Tue, 3 Aug 2004 19:57:02 +0200 From: Stig Venaas To: dhcwg@ietf.org Message-ID: <20040803175702.GA28332@sverresborg.uninett.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Subject: [dhcwg] How does DHCP client know when it's at home? X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Regarding the MIPv6 HA option, it was suggested that client would use this when at home, and ignore the option if it gets something when not at home. I don't understand how a client can know when it's at home, are there any mechanisms for that? If it is, it might be more useful to also have DHCP options for things like POP/IMAP servers etc where you want to learn the addresses when at home, and keep using the same when away. Stig _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Aug 3 14:28:25 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29669; Tue, 3 Aug 2004 14:28:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bs3p9-0002os-JJ; Tue, 03 Aug 2004 14:15:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bs3Zp-0007fe-HI for dhcwg@megatron.ietf.org; Tue, 03 Aug 2004 13:59:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27298 for ; Tue, 3 Aug 2004 13:59:52 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bs3cw-0006Lr-1d for dhcwg@ietf.org; Tue, 03 Aug 2004 14:03:07 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 03 Aug 2004 13:59:21 -0400 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i73HxERW016513; Tue, 3 Aug 2004 13:59:14 -0400 (EDT) Received: from rdroms-w2k01.cisco.com (che-vpn-cluster-2-28.cisco.com [10.86.242.28]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AKO68233; Tue, 3 Aug 2004 13:59:13 -0400 (EDT) Message-Id: <4.3.2.7.2.20040803135851.02af6cb0@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 03 Aug 2004 13:59:10 -0400 To: "JINMEI Tatuya / ?$B?@L@C#:H" From: Ralph Droms Subject: Re: [dhcwg] Re: one more comment about the lifetime option In-Reply-To: <20040803171447.GA27805@sverresborg.uninett.no> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: dhcwg@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org I agree with Stig - we've discussed this issue before and come to the conclusion that there is little extra overhead in delivering information that has not changed, so there should be a single lifetime - chosen to be the shortest lifetome of any of the client's parameters. - Ralph At 07:14 PM 8/3/2004 +0200, Stig Venaas wrote: >On Wed, Aug 04, 2004 at 02:03:04AM +0900, JINMEI Tatuya / ?$B?@L@C#:H wrote: > > I forgot to mention this one: > > > > Is it possible to specify different lifetimes for different instances > > of stateless information? For example, people may want to specify > > different lifetimes for recursive DNS server addresses and for SIP > > server addresses. > >We should keep this simple. If e.g. recursive server data needs to be >updated more frequently than SIP data, I would simply say that lifetime >should be the shortest. When you contact server to update DNS data, you >can at the same time update other data like SIP server address. > >Note that the draft says: > > If client has received a lifetime with this option, and contacts > server to receive new or update any existing data prior to its > expiration, it SHOULD also update data covered by this option. If no > new lifetime is received, it MUST behave as if no value was ever > provided. > >In line with that SHOULD, there's no good reason to have multiple >lifetimes. > >Stig > >_______________________________________________ >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-bounces@ietf.org Tue Aug 3 14:32:05 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00023; Tue, 3 Aug 2004 14:32:05 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bs3pA-0002p9-Hm; Tue, 03 Aug 2004 14:15:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bs3bK-0007sJ-9q for dhcwg@megatron.ietf.org; Tue, 03 Aug 2004 14:01:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27434 for ; Tue, 3 Aug 2004 14:01:25 -0400 (EDT) Received: from raven.ecs.soton.ac.uk ([152.78.70.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bs3eQ-0006OL-9O for dhcwg@ietf.org; Tue, 03 Aug 2004 14:04:40 -0400 Received: from magpie.ecs.soton.ac.uk (magpie.ecs.soton.ac.uk [152.78.68.131]) by raven.ecs.soton.ac.uk (8.12.10/8.12.10) with ESMTP id i73I1MnE025323 for ; Tue, 3 Aug 2004 19:01:22 +0100 (BST) Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by magpie.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id TAA11209 for ; Tue, 3 Aug 2004 19:01:21 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id i73I1LO22383 for dhcwg@ietf.org; Tue, 3 Aug 2004 19:01:21 +0100 Date: Tue, 3 Aug 2004 19:01:21 +0100 From: Tim Chown To: dhcwg@ietf.org Message-ID: <20040803180121.GC21469@login.ecs.soton.ac.uk> Mail-Followup-To: dhcwg@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i X-MailScanner-Information: Please contact helpdesk@ecs.soton.ac.uk for more information X-ECS-MailScanner: Found to be clean X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Subject: [dhcwg] My slides for dhc session, 3rd Aug X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Hi, My slides are available temporarily online: Draft: http://www.ietf.org/internet-drafts/draft-ietf-dhc-stateless-dhcpv6-renumbering-01.txt Slides: http://www.ecs.soton.ac.uk/~tjc/ietf/stateless-renumbering-01.pdf http://www.ecs.soton.ac.uk/~tjc/ietf/stateless-renumbering-01.ppt Draft: http://www.ietf.org/internet-drafts/draft-ietf-dhc-dual-stack-01.txt Slides: http://www.ecs.soton.ac.uk/~tjc/ietf/dhcp-dual-stack-01.pdf http://www.ecs.soton.ac.uk/~tjc/ietf/dhcp-dual-stack-01.ppt Tim _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Aug 3 14:33:31 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00270; Tue, 3 Aug 2004 14:33:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bs3pO-0002tR-T8; Tue, 03 Aug 2004 14:15:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bs3dR-00086D-2e for dhcwg@megatron.ietf.org; Tue, 03 Aug 2004 14:03:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27594 for ; Tue, 3 Aug 2004 14:03:35 -0400 (EDT) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bs3gX-0006Qg-5n for dhcwg@ietf.org; Tue, 03 Aug 2004 14:06:50 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i73I32e25363 for ; Tue, 3 Aug 2004 21:03:02 +0300 Date: Tue, 3 Aug 2004 21:03:02 +0300 (EEST) From: Pekka Savola To: dhcwg@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Subject: [dhcwg] Trust model of Client FQDN option X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Hi, (not subscribed..) I'm not sure the v4 or v6 DHC FQDN client options address the problem of the trust model for the update content sufficiently well. I'd even go as far to say that it might create a false sense of security. The issue is that as the DNS server will be configured to trust the DHCP server for these updates, how could the DHCP server ensure that the Client is authorized to insert that FQDN -> IP mapping. This is basically deemed outside of the scope of the spec, without providing the means in the spec to do that properly. A suggestion is that the DHCP server includes policy information which updates would be acceptable. I do not think this addresses the real problem: if such policy is available, why does the client need to send the FQDN in the first place -- the DHCP server should just be configured to update the FQDN corresponding to a particular client to map to the IP address of that client; the client doesn't need to specify it if this will need to be included in the policy configuration in any case. So, in this kind of scenario, you shouldn't actually need the Client FQDN option here, just the magic in the DHCP server to update the IP address of a particular client automatically. Therefore, the client should probably be able to insert a TSIG or some other signature which the DHCP server could use for updating; this would authorize the update (in case TSIG validation succeeds) or not without manually configured policy lists. (A reason why DHCP server could update the FQDN to the DNS server might be that the ISP wants to restrict access to the DNS updates to a smaller number of hosts.) -- 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-bounces@ietf.org Tue Aug 3 15:04:42 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03134; Tue, 3 Aug 2004 15:04:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bs4SC-00011a-6E; Tue, 03 Aug 2004 14:56:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bs4Md-0008Fw-Q5 for dhcwg@megatron.ietf.org; Tue, 03 Aug 2004 14:50:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01997 for ; Tue, 3 Aug 2004 14:50:18 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bs4Pk-0007Xh-SL for dhcwg@ietf.org; Tue, 03 Aug 2004 14:53:34 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 03 Aug 2004 14:49:48 -0400 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i73InjRW007134; Tue, 3 Aug 2004 14:49:45 -0400 (EDT) Received: from volzw2k (tky-vpn-client-231-28.cisco.com [10.70.231.28]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AKO73605; Tue, 3 Aug 2004 14:49:37 -0400 (EDT) From: "Bernie Volz" To: , , Subject: RE: [dhcwg] RE: draft-chowdhury-dhc-bcmcv4-option-00.txt Date: Tue, 3 Aug 2004 14:50:26 -0400 Organization: Cisco Message-ID: <000001c4798a$c24c13f0$46828182@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.5709 Importance: Normal In-Reply-To: <000301c4791b$76cf1fe0$3e858182@amer.cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4939.300 X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: 7bit Cc: "'DHC WG \(E-mail\)'" X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 7bit Ignore the broadcast comment ... - Bernie > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] > On Behalf Of Bernie Volz > Sent: Tuesday, August 03, 2004 1:34 AM > To: chowdury@nortelnetworks.com; pyegani@cisco.com; > Lila.Madour@ericsson.com > Cc: 'DHC WG (E-mail)' > Subject: [dhcwg] RE: draft-chowdhury-dhc-bcmcv4-option-00.txt > > > While preparing for the DHC WG meeting, I found these issues with > draft-chowdhury-dhc-bcmcv6-option-00.txt: > > As DHCPv6 doesn't support broadcasting, you're really only > able to support multicasting. Not sure if this should be > pointed out early in the draft? And, perhaps the option (in > the DHCPv6 case) should not use "broadcast" in its name? > > RFC 3315, section 8, specifically prohibits compression. You > should follow that rule. > > Informative is misspelling in this document as well (inforamtive). > > - Bernie > > > _______________________________________________ > 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-bounces@ietf.org Tue Aug 3 16:30:18 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09415; Tue, 3 Aug 2004 16:30:18 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bs5nx-0005x1-L1; Tue, 03 Aug 2004 16:22:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bs5jZ-0005Px-An for dhcwg@megatron.ietf.org; Tue, 03 Aug 2004 16:18:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08690 for ; Tue, 3 Aug 2004 16:18:03 -0400 (EDT) Received: from mailout2.samsung.com ([203.254.224.25]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bs5mh-0000bp-1P for dhcwg@ietf.org; Tue, 03 Aug 2004 16:21:20 -0400 Received: from custom-daemon.mailout2.samsung.com by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0I1W00K040D7IC@mailout2.samsung.com> for dhcwg@ietf.org; Wed, 04 Aug 2004 05:17:31 +0900 (KST) Received: from ep_ms3_bk (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0I1W001QS0D7S1@mailout2.samsung.com> for dhcwg@ietf.org; Wed, 04 Aug 2004 05:17:31 +0900 (KST) Received: from ep_spt01 (ms3.samsung.com [203.254.225.112]) by ms3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0I1W003M30D71R@ms3.samsung.com> for dhcwg@ietf.org; Wed, 04 Aug 2004 05:17:31 +0900 (KST) Content-return: prohibited Date: Tue, 03 Aug 2004 20:17:38 +0000 (GMT) From: PARK SOO HONG Subject: Re: [dhcwg] Comment on a couple of option drafts that have gone by... X-Sender: =?windows-1252?B?U2Ftc3VuZyBFbGVjdHJvbmljcz9Nb2Jp?= =?windows-1252?B?bGUgUGxhdGZvcm0gTGFiP0VuZ2luZWVy?= To: Ted Lemon Message-id: <0I1W003M40D71R@ms3.samsung.com> MIME-version: 1.0 X-Priority: 3 Msgkey: 20040803201723656@soohong.park X-MTR: 20040803201723656@soohong.park X-EPLocale: en_US.windows-1252 X-EPWebmail-Msg-Type: personal X-EPWebmail-Reply-Demand: 0 X-Generator: NamoMIME 1.1.0.14 X-Spam-Score: 1.7 (+) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: "dhcwg@ietf.org " X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: soohong.park@samsung.com List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0331195655==" Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org --===============0331195655== Content-return: prohibited Content-type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7BIT Samsung Enterprise Portal mySingle

>However, I would like to point out one problem with this, and request 
>that the authors of these drafts (I'm thinking specifically of the 
>haopt and tep drafts) add some text to talk about what the client 
>should send in the parameter request list.

So I simply wrote some text in my draft.

 

The DHCP client will use this option to create a tunnel end-point address

for configuring IPv6-over-IPv4 tunnel. The client may receive tunnel services

in this option that it does not support or has not been configured to access.

Likewise, a client may receive an option that tunnel services for which no

corresponding DHCP option was supplied. Clients will interpret this option

in a system-specific manner whose specification is outside the scope of

this document.

 

 

Isn't it enough to satisfy your concern ?

This text is our implementation-basis

 

 

Regards

 

Daniel (Soohong Daniel Park)

Mobile Platform Laboratory. SAMSUNG Electronics


--===============0331195655== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --===============0331195655==-- From dhcwg-bounces@ietf.org Tue Aug 3 16:49:20 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10833; Tue, 3 Aug 2004 16:49:20 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bs68a-00005W-Bp; Tue, 03 Aug 2004 16:43:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bs63T-0007bx-8F for dhcwg@megatron.ietf.org; Tue, 03 Aug 2004 16:38:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10185 for ; Tue, 3 Aug 2004 16:38:37 -0400 (EDT) Received: from mailout2.samsung.com ([203.254.224.25]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bs66a-0000yf-Tr for dhcwg@ietf.org; Tue, 03 Aug 2004 16:41:54 -0400 Received: from custom-daemon.mailout2.samsung.com by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0I1W00L011BHGY@mailout2.samsung.com> for dhcwg@ietf.org; Wed, 04 Aug 2004 05:38:05 +0900 (KST) Received: from ep_mmp1 (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0I1W00BDA1BG0W@mailout2.samsung.com> for dhcwg@ietf.org; Wed, 04 Aug 2004 05:38:05 +0900 (KST) Received: from Alperyegin ([105.253.155.49]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0I1W00KCP1BC90@mmp1.samsung.com> for dhcwg@ietf.org; Wed, 04 Aug 2004 05:38:04 +0900 (KST) Date: Tue, 03 Aug 2004 13:38:00 -0700 From: Alper Yegin In-reply-to: <000101c4791b$739a81c0$3e858182@amer.cisco.com> To: "'Bernie Volz'" , heejin.jang@samsung.com, athene@sait.samsung.co.kr Message-id: <000001c47999$c6900160$be818182@sisa.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7BIT Cc: "'DHC WG \(E-mail\)'" Subject: [dhcwg] RE: draft-jang-dhc-haopt-00.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 7BIT Hi Bernie, Thank you for the review and feedback. > In DHCPv6 we use 16-bit option (and suboption) codes and lengths. It would > be best if this draft switched to using 16-bit fields for the sub-option > and > length fields. Please see RFC 3315 and section 22.17. Note also that for > some forms of identification/authentication (opaque type), it is > conceivable > that it might exceed a length of 255 bytes! We will fix that. > Also, with a 16-bit option number space, we've got plenty of option number > space and it might be best to drop the Home Agent Discovery Option and > simply make the two sub-options regular options? Or, is there a reason > you'd > prefer having sub-options? Nothing other than clumping the related information together. We can split the options if this is the preferred way. > For the Home Network Information Sub-option, I assume that if multiple > addresses (or prefixes) are specified, the A, reserved, prefix-length and > address/prefix fields are all repeated (18 bytes/address). It might be > good > to specify this? Yes, that's the intent. We'll add more text to clarify this. Thanks again. Alper _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Aug 3 17:07:34 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12041; Tue, 3 Aug 2004 17:07:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bs6Rf-0002oG-LS; Tue, 03 Aug 2004 17:03:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bs6KQ-0001yF-VM for dhcwg@megatron.ietf.org; Tue, 03 Aug 2004 16:56:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11305 for ; Tue, 3 Aug 2004 16:56:08 -0400 (EDT) Received: from mailout1.samsung.com ([203.254.224.24]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bs6NY-0001GR-Qb for dhcwg@ietf.org; Tue, 03 Aug 2004 16:59:26 -0400 Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0I1W00E0124PJZ@mailout1.samsung.com> for dhcwg@ietf.org; Wed, 04 Aug 2004 05:55:37 +0900 (KST) Received: from ep_mmp1 (mailout1.samsung.com [203.254.224.24]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0I1W005LD24OKF@mailout1.samsung.com> for dhcwg@ietf.org; Wed, 04 Aug 2004 05:55:37 +0900 (KST) Received: from Alperyegin ([105.253.155.49]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0I1W00KT224L90@mmp1.samsung.com> for dhcwg@ietf.org; Wed, 04 Aug 2004 05:55:36 +0900 (KST) Date: Tue, 03 Aug 2004 13:55:32 -0700 From: Alper Yegin Subject: RE: [dhcwg] How does DHCP client know when it's at home? In-reply-to: <20040803175702.GA28332@sverresborg.uninett.no> To: "'Stig Venaas'" , dhcwg@ietf.org Message-id: <000001c4799c$39a8a830$be818182@sisa.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: 7BIT X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 7BIT Hi Stig, > Regarding the MIPv6 HA option, it was suggested that client would use > this when at home, and ignore the option if it gets something when not > at home. Unfortunately that is not accurate. I should have corrected that at the meeting. The current I-D has the provision to deliver home agent info that pertains to the currently visited network, or a remote network. The MNId is used to convey the domain the information should pertain to. My MN should be able to say "get me a home agent from the access network I'm visiting", or "give me a home agent from anotherdomain.com". > I don't understand how a client can know when it's at home, are there > any mechanisms for that? > > If it is, it might be more useful to also have DHCP options for things > like POP/IMAP servers etc where you want to learn the addresses when > at home, and keep using the same when away. > > Stig Alper > > _______________________________________________ > 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-bounces@ietf.org Tue Aug 3 18:19:08 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17665; Tue, 3 Aug 2004 18:19:08 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bs7aV-0001jN-E5; Tue, 03 Aug 2004 18:16:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bs7R7-0005kW-3I for dhcwg@megatron.ietf.org; Tue, 03 Aug 2004 18:07:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16302 for ; Tue, 3 Aug 2004 18:07:06 -0400 (EDT) Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bs7UF-0002Qt-Pl for dhcwg@ietf.org; Tue, 03 Aug 2004 18:10:25 -0400 Received: from [66.93.162.248] (0127bhost250.starwoodbroadband.com [12.105.247.250]) by toccata.fugue.com (Postfix) with ESMTP id 08D961B24B0; Tue, 3 Aug 2004 17:06:18 -0500 (CDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=ISO-2022-JP; format=flowed Message-Id: <72FA02EA-E599-11D8-8860-000A95D9C74C@nominum.com> Content-Transfer-Encoding: 7bit From: Ted Lemon Subject: Re: [dhcwg] one more comment about the lifetime option Date: Tue, 3 Aug 2004 15:07:02 -0700 To: =?ISO-2022-JP?B?SklOTUVJIFRhdHV5YSAvIBskQj9ATEBDIzpIGyhC?= X-Mailer: Apple Mail (2.618) X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org, tjc@ecs.soton.ac.uk, Stig.Venaas@uninett.no X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 7bit On Aug 3, 2004, at 10:03 AM, JINMEI Tatuya / $B?@L@C#:H(B wrote: > Is it possible to specify different lifetimes for different instances > of stateless information? For example, people may want to specify > different lifetimes for recursive DNS server addresses and for SIP > server addresses. I think the amount of work the server has to do to make this happen is more than the amount of work that is saved. That is, you're going to have to process an Information Request packet every time anything on the client expires. And figuring out that you only need to send certain options, and not certain others, is more work than just sending what you have. So I think that not only is it not necessary to have different lifetimes for different options, it's actually harmful to have them. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Aug 3 18:30:05 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18254; Tue, 3 Aug 2004 18:30:05 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bs7ie-0003RI-LF; Tue, 03 Aug 2004 18:25:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bs7cn-0002n7-Jd for dhcwg@megatron.ietf.org; Tue, 03 Aug 2004 18:19:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17700 for ; Tue, 3 Aug 2004 18:19:10 -0400 (EDT) Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bs7ft-0002bv-WB for dhcwg@ietf.org; Tue, 03 Aug 2004 18:22:29 -0400 Received: from [66.93.162.248] (0127bhost250.starwoodbroadband.com [12.105.247.250]) by toccata.fugue.com (Postfix) with ESMTP id ACA0B1B29EB; Tue, 3 Aug 2004 17:18:20 -0500 (CDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <21E7AC38-E59B-11D8-8860-000A95D9C74C@fugue.com> Content-Transfer-Encoding: 7bit From: Ted Lemon Subject: Re: [dhcwg] Trust model of Client FQDN option Date: Tue, 3 Aug 2004 15:19:05 -0700 To: Pekka Savola X-Mailer: Apple Mail (2.618) X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 7bit On Aug 3, 2004, at 11:03 AM, Pekka Savola wrote: > I'm not sure the v4 or v6 DHC FQDN client options address the problem > of the trust model for the update content sufficiently well. I'd even > go as far to say that it might create a false sense of security. Pekka, in the meeting this morning, you said you hadn't read the drafts having to do with DNS updates on DHCPv4. Have you now read them? The reason I ask is that for the entire duration of the time I've been coming to IETF, people have occasionally raised the very same issue you are now raising. The solution we have adopted, which is widely deployed, allows two answers to your question. The first is a more paranoid solution that requires widespread distribution of individual DNS update keys. The second is a more laissez-faire solution that does not require the distribution of individual DNS update keys. This second solution is no more or less secure than the first, but its behavior is different. Names added by the DHCP server are marked as such, and if a name is present and was not added by the DHCP server, that name can't be replaced at the request of the DHCP client. When a client's lease expires, another client can acquire the previous client's name, so there's no protection for client names. You get to pick which solution to deploy, based on your willingness to distribute keys and based on whether or not you care whether a DHCP client can count on retaining its name, once its name is registered. So this is a well-understood problem, with well-understood and widely deployed solutions. You can see an example implementation in the ISC DHCP client and server if you're curious, and as far as I know every commercial DHCP server also implements this, and I know of quite a few sites that use it in practice. Indeed, it's been deployed at IETF meetings in the past (not sure if it's running this time). _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Aug 3 18:37:07 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18680; Tue, 3 Aug 2004 18:37:07 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bs7rs-0004GU-Fq; Tue, 03 Aug 2004 18:34:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bs7jR-0003YA-Fw for dhcwg@megatron.ietf.org; Tue, 03 Aug 2004 18:26:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18101 for ; Tue, 3 Aug 2004 18:26:03 -0400 (EDT) Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bs7ma-0002j2-DA for dhcwg@ietf.org; Tue, 03 Aug 2004 18:29:21 -0400 Received: from [66.93.162.248] (0127bhost250.starwoodbroadband.com [12.105.247.250]) by toccata.fugue.com (Postfix) with ESMTP id 44AC11B2A2E; Tue, 3 Aug 2004 17:25:15 -0500 (CDT) In-Reply-To: <0I1W003M40D71R@ms3.samsung.com> References: <0I1W003M40D71R@ms3.samsung.com> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <18347D18-E59C-11D8-8860-000A95D9C74C@nominum.com> Content-Transfer-Encoding: 7bit From: Ted Lemon Subject: Re: [dhcwg] Comment on a couple of option drafts that have gone by... Date: Tue, 3 Aug 2004 15:25:59 -0700 To: soohong.park@samsung.com X-Mailer: Apple Mail (2.618) X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit Cc: "dhcwg@ietf.org " X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 7bit On Aug 3, 2004, at 1:17 PM, PARK SOO HONG wrote: > Isn't it enough to satisfy your concern ? No, my concern is not related to what you're talking about. My concern is actually unrelated to the work you are doing - I'm just asking you to add some text to try to get client implements to be consistent in what they do with the parameter request list. It's not your fault that this is (IMHO) necessary - the problem is that the parameter request list option is poorly specified, and I'd like implementors of this option to implement to the more stringent interpretation of the specification, rather than the more lax implementation. In order to get client implementors to do this, I am asking you to add some text which will (I hope) cause client implementors to assume that the DHCP server will behave in a certain way. If they believe that a DHCP server will very likely not send a tep option if the client doesn't request it in the parameter request list, then they will request it in the parameter request list. If they do not believe this, then they may send a parameter request list but omit the tep option code from the list, thinking it is not necessary to include it. I don't actually care if server implementors follow the requirements I'm asking you to add - I just care that client implementors have reason to think that servers might follow these requirements. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Aug 3 19:16:07 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20681; Tue, 3 Aug 2004 19:16:07 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bs8SV-00081k-Qo; Tue, 03 Aug 2004 19:12:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bs8Ma-0007ST-W8 for dhcwg@megatron.ietf.org; Tue, 03 Aug 2004 19:06:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20244 for ; Tue, 3 Aug 2004 19:06:30 -0400 (EDT) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bs8Pj-0003HZ-Pe for dhcwg@ietf.org; Tue, 03 Aug 2004 19:09:49 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i73N5ua31874; Wed, 4 Aug 2004 02:05:56 +0300 Date: Wed, 4 Aug 2004 02:05:56 +0300 (EEST) From: Pekka Savola To: Ted Lemon Subject: Re: [dhcwg] Trust model of Client FQDN option In-Reply-To: <21E7AC38-E59B-11D8-8860-000A95D9C74C@fugue.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: dhcwg@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org On Tue, 3 Aug 2004, Ted Lemon wrote: > On Aug 3, 2004, at 11:03 AM, Pekka Savola wrote: > > I'm not sure the v4 or v6 DHC FQDN client options address the problem > > of the trust model for the update content sufficiently well. I'd even > > go as far to say that it might create a false sense of security. > > Pekka, in the meeting this morning, you said you hadn't read the drafts > having to do with DNS updates on DHCPv4. Have you now read them? Yes; I scanned through draft-ietf-dhc-fqdn-option and the dnxext dhcrr document. > The reason I ask is that for the entire duration of the time I've been > coming to IETF, people have occasionally raised the very same issue you > are now raising. Maybe this would stop if these issues would actually be adequately addressed? I promise to bring this up again at the last minute if not. What you describe below is very well, and probably addresses most of the issues (to a certain degree, which should be spelled out), but none of this seems to exist written in the clear in draft-ietf-dhc-fqdn-option. Let's look at its Security Considerations section (the others don't include anything relevant to this, AFAICS): 1st paragraph: generic text about DNS update authentication requirements 2nd: notes the two approaches (client vs dhcp updated), and that they depend e.g., on security model (without going into details) 3rd: generic text wrt. whether DHCP server would always do the updates or not 4th: notes the lack of authentication of the user, given that DHCP authentication is not there or is not deployed. Ascertaining the identty of the client is difficult. [note: DHCP authentication has very little to do with the authorization of the client to update a specific name] 5th: describes scenarios where you might not be able to spoof DHCP packets, and a little text about being able to trust (in some cases) the dhc client id. [note: spoofing or not spoofing DHCP packets, and DHC client id do not yet provide any authorization to update a DNS name] I also note that the draft doesn't even mention draft-ietf-dnsext-dhcid-rr-08.txt. The actual meat is missing, and does not address *DNS name* authorization at all, just talks quite a bit about DHCP authentication and different ways to eliminate DHCP spoofing. > The solution we have adopted, which is widely deployed, allows two > answers to your question. The first is a more paranoid solution that > requires widespread distribution of individual DNS update keys. The > second is a more laissez-faire solution that does not require the > distribution of individual DNS update keys. This second solution is > no more or less secure than the first, but its behavior is different. > Names added by the DHCP server are marked as such, and if a name is > present and was not added by the DHCP server, that name can't be > replaced at the request of the DHCP client. When a client's lease > expires, another client can acquire the previous client's name, so > there's no protection for client names. You get to pick which > solution to deploy, based on your willingness to distribute keys and > based on whether or not you care whether a DHCP client can count on > retaining its name, once its name is registered. -- 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-bounces@ietf.org Tue Aug 3 19:50:02 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22782; Tue, 3 Aug 2004 19:50:02 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bs8sq-000298-6R; Tue, 03 Aug 2004 19:39:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bs8nd-0001Mv-Ri for dhcwg@megatron.ietf.org; Tue, 03 Aug 2004 19:34:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21796 for ; Tue, 3 Aug 2004 19:34:28 -0400 (EDT) Received: from web90006.mail.scd.yahoo.com ([66.218.94.64]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1Bs8qn-0003iV-Am for dhcwg@ietf.org; Tue, 03 Aug 2004 19:37:46 -0400 Message-ID: <20040803233353.81715.qmail@web90006.mail.scd.yahoo.com> Received: from [130.129.64.82] by web90006.mail.scd.yahoo.com via HTTP; Tue, 03 Aug 2004 16:33:53 PDT Date: Tue, 3 Aug 2004 16:33:53 -0700 (PDT) From: Syam Madanapalli Subject: Re:[dhcwg] comments on draft-daniel-dhc-dhcpv4-tep-conf To: Ted.Lemon@nominum.com, dhcwg@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.5 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Hello Ted Lemon , This draft breaks a couple of existing assumptions about DHCP. First, it requires that the option be send only in a DHCPACK message in response to a DHCPREQUEST message. Normally the DHCPOFFER message contains the same options as the DHCPACK message. So I would strongly suggest that this restriction be relaxed to allow the DHCPOFFER to contain this option. ---> Initially we have taken this approach, so that we could establish the bidirectional tunnel simultaneously at both the places. With your proposal now we can create the tunnel only one side, the other side need to repeat this procedure to create the other end of the tunnel. To overcome this we have new proposal where DHCP Inform is used to to create the tunnel. Following link has the PPT http://home.megapass.co.kr/~natpp00/IETF-60-DHCPv4-CTEP.ppt Secondly, the draft allows multiple copies to appear. This contradicts the Encoding Long Options RFC (sorry, can't remember the number off the top of my head), which would create a huge headache for DHCP server and client implementations. So please change the option so that there can be only one of them, and that if multiple values need to be sent, that is encoded within the option. ---> Yep, we will make this change. Also, there is quite a bit of information in this document that goes beyond describing the format of the option. It looks like you're defining a new protocol. If you are not defining a new protocol, it would be better to refer to the document that defines the protocol, and remove the words from this document that describe that protocol in detail. If you are defining a new protocol here, this draft probably needs to be reviewed by the working group responsible for that area as well as by the DHC working group. (sorry if this has already been said) ---> The intention of the draft is to propose an Option as well as a protocol (may be a procedure) to automate the tunnel configuration acroos IPv6 Clouds seperated by v4 network. And this draft recommends running a DHCP Client on a border dual Stack router, I am not sure if this is okay. Otherwise you need another protocol between DHCP Client and router to configure Tunnel end points automatically. I've enclosed a couple of diffs for some minor editorial suggestions. Attachment: draft-daniel-dhc-dhcpv4-tep-conf-comments ---> We will take these suggestions. Thank you, Syam __________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - 100MB free storage! http://promotions.yahoo.com/new_mail _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Aug 3 20:08:57 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24232; Tue, 3 Aug 2004 20:08:56 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bs9JK-0006qa-2I; Tue, 03 Aug 2004 20:07:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bs97b-0004nt-LL for dhcwg@megatron.ietf.org; Tue, 03 Aug 2004 19:55:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23203 for ; Tue, 3 Aug 2004 19:55:06 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bs9Al-00047t-9X for dhcwg@ietf.org; Tue, 03 Aug 2004 19:58:24 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-1.cisco.com with ESMTP; 03 Aug 2004 16:56:09 -0700 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i73NsVJI017108; Tue, 3 Aug 2004 16:54:31 -0700 (PDT) Received: from kkinnear-w2k03.cisco.com (rtp-vpn1-257.cisco.com [10.82.225.1]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AKO95097; Tue, 3 Aug 2004 19:54:27 -0400 (EDT) Message-Id: <4.3.2.7.2.20040803194603.026f35b0@goblet.cisco.com> X-Sender: kkinnear@goblet.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 03 Aug 2004 19:55:52 -0400 To: Ted Lemon , soohong.park@samsung.com From: Kim Kinnear Subject: Re: [dhcwg] Comment on a couple of option drafts that have gone by... In-Reply-To: <18347D18-E59C-11D8-8860-000A95D9C74C@nominum.com> References: <0I1W003M40D71R@ms3.samsung.com> <0I1W003M40D71R@ms3.samsung.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: "dhcwg@ietf.org " , kkinnear@cisco.com X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org At 06:25 PM 8/3/2004, Ted Lemon wrote: >On Aug 3, 2004, at 1:17 PM, PARK SOO HONG wrote: >>Isn't it enough to satisfy your concern ? > >No, my concern is not related to what you're talking about. My concern is actually unrelated to the work you are doing - I'm just asking you to add some text to try to get client implements to be consistent in what they do with the parameter request list. It's not your fault that this is (IMHO) necessary - the problem is that the parameter request list option is poorly specified, and I'd like implementors of this option to implement to the more stringent interpretation of the specification, rather than the more lax implementation. > >In order to get client implementors to do this, I am asking you to add some text which will (I hope) cause client implementors to assume that the DHCP server will behave in a certain way. If they believe that a DHCP server will very likely not send a tep option if the client doesn't request it in the parameter request list, then they will request it in the parameter request list. If they do not believe this, then they may send a parameter request list but omit the tep option code from the list, thinking it is not necessary to include it. > >I don't actually care if server implementors follow the requirements I'm asking you to add - I just care that client implementors have reason to think that servers might follow these requirements. Ted, Thank you for such a clear statement of this issue. I agree that the parameter request option is poorly specified, and I remember my astonishment the first time I heard the interpretation that a DHCP server should send *every* option with which it is configured (and not just the options that were requested in the parameter request list). That wasn't my interpretation of the DHCP draft/RFC and it seems it wasn't yours either. I also agree with your goal -- that client implementors *must* ask (via the paramter request list) for options that they need, and not assume that the DHCP server will just send send them by magic. I believe that the way to achieve that goal is to simply put that in the RFC -- that a client that needs this option MUST request it via the parameter request list. I strongly believe that saying that a DHCP server MUST NOT send this option unless a client requests it is very much not the way to achieve this end. This will require special case code in every DHCP server which wants to be compliant with this draft (and future RFC). I see this as a "cure worse than the disease". Let us just say what we mean -- a client that wants this option MUST request it by using the parameter request list. Period. Cheers -- 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-bounces@ietf.org Tue Aug 3 20:53:58 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27383; Tue, 3 Aug 2004 20:53:58 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bs9wV-0005uv-WF; Tue, 03 Aug 2004 20:47:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bs9tn-0004mY-DS for dhcwg@megatron.ietf.org; Tue, 03 Aug 2004 20:44:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26625 for ; Tue, 3 Aug 2004 20:44:54 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bs9wv-00058D-IX for dhcwg@ietf.org; Tue, 03 Aug 2004 20:48:12 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 03 Aug 2004 20:44:21 -0400 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i740iDxF001583; Tue, 3 Aug 2004 20:44:16 -0400 (EDT) Received: from volzw2k (sjc-vpn3-608.cisco.com [10.21.66.96]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AKO96850; Tue, 3 Aug 2004 20:40:58 -0400 (EDT) From: "Bernie Volz" To: "'Pekka Savola'" , "'Ted Lemon'" Subject: RE: [dhcwg] Trust model of Client FQDN option Date: Tue, 3 Aug 2004 20:42:26 -0400 Organization: Cisco Message-ID: <000c01c479bb$eba91af0$c3838182@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.5709 In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4939.300 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 7bit Correct, this appears in draft-ietf-dhc-ddns-resolution-07.txt. This draft is referenced in the "7. DNS Update Conflicts" section of the FQDN draft. The resolution draft still needs additional work for DHCPv6 - it currently only applies to IPv4. - Bernie > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] > On Behalf Of Pekka Savola > Sent: Tuesday, August 03, 2004 7:06 PM > To: Ted Lemon > Cc: dhcwg@ietf.org > Subject: Re: [dhcwg] Trust model of Client FQDN option > > > On Tue, 3 Aug 2004, Ted Lemon wrote: > > On Aug 3, 2004, at 11:03 AM, Pekka Savola wrote: > > > I'm not sure the v4 or v6 DHC FQDN client options address the > > > problem of the trust model for the update content > sufficiently well. > > > I'd even go as far to say that it might create a false sense of > > > security. > > > > Pekka, in the meeting this morning, you said you hadn't > read the drafts > > having to do with DNS updates on DHCPv4. Have you now > read them? > > Yes; I scanned through draft-ietf-dhc-fqdn-option and the > dnxext dhcrr > document. > > > The reason I ask is that for the entire duration of the > time I've been > > coming to IETF, people have occasionally raised the very > same issue you > > are now raising. > > Maybe this would stop if these issues would actually be > adequately addressed? I promise to bring this up again at > the last minute if > not. > > What you describe below is very well, and probably addresses > most of the issues (to a certain degree, which should be > spelled out), but none of this seems to exist written in the > clear in draft-ietf-dhc-fqdn-option. > > Let's look at its Security Considerations section (the others don't > include anything relevant to this, AFAICS): > > 1st paragraph: generic text about DNS update authentication > requirements > > 2nd: notes the two approaches (client vs dhcp updated), and that they > depend e.g., on security model (without going into details) > > 3rd: generic text wrt. whether DHCP server would always do > the updates > or not > > 4th: notes the lack of authentication of the user, given that DHCP > authentication is not there or is not deployed. Ascertaining the > identty of the client is difficult. [note: DHCP authentication has > very little to do with the authorization of the client to update a > specific name] > > 5th: describes scenarios where you might not be able to spoof DHCP > packets, and a little text about being able to trust (in some cases) > the dhc client id. [note: spoofing or not spoofing DHCP packets, and > DHC client id do not yet provide any authorization to update a DNS > name] > > I also note that the draft doesn't even mention > draft-ietf-dnsext-dhcid-rr-08.txt. > > The actual meat is missing, and does not address *DNS name* > authorization at all, just talks quite a bit about DHCP > authentication and different ways to eliminate DHCP spoofing. > > > The solution we have adopted, which is widely deployed, allows two > > answers to your question. The first is a more paranoid > solution that > > requires widespread distribution of individual DNS update > keys. The > > second is a more laissez-faire solution that does not require the > > distribution of individual DNS update keys. This second > solution is > > no more or less secure than the first, but its behavior is > different. > > Names added by the DHCP server are marked as such, and if a name is > > present and was not added by the DHCP server, that name can't be > > replaced at the request of the DHCP client. When a client's lease > > expires, another client can acquire the previous client's name, so > > there's no protection for client names. You get to pick which > > solution to deploy, based on your willingness to distribute > keys and > > based on whether or not you care whether a DHCP client can count on > > retaining its name, once its name is registered. > > -- > 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-bounces@ietf.org Tue Aug 3 20:55:12 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27533; Tue, 3 Aug 2004 20:55:12 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bs9wX-0005vg-JJ; Tue, 03 Aug 2004 20:47:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bs9uS-0004xK-Tw for dhcwg@megatron.ietf.org; Tue, 03 Aug 2004 20:45:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26679 for ; Tue, 3 Aug 2004 20:45:35 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bs9xb-000592-4W for dhcwg@ietf.org; Tue, 03 Aug 2004 20:48:54 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-1.cisco.com with ESMTP; 03 Aug 2004 17:46:38 -0700 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i740iubA021493; Tue, 3 Aug 2004 17:45:00 -0700 (PDT) Received: from volzw2k (sjc-vpn3-608.cisco.com [10.21.66.96]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AKO96757; Tue, 3 Aug 2004 20:37:58 -0400 (EDT) From: "Bernie Volz" To: "'Ted Lemon'" , "'Pekka Savola'" Subject: RE: [dhcwg] Trust model of Client FQDN option Date: Tue, 3 Aug 2004 20:39:25 -0400 Organization: Cisco Message-ID: <000b01c479bb$81780bf0$c3838182@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.5709 In-Reply-To: <21E7AC38-E59B-11D8-8860-000A95D9C74C@fugue.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4939.300 X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 7bit Also, it is generally viewed as a bad idea to mix both static and dynamic DNS resource records in a zone. So, if you want to completely avoid the problem, keep the zones which contain the administrative DNS information (www., ftp., pop3., ...) separate from the (dynamic) client information. - Bernie > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] > On Behalf Of Ted Lemon > Sent: Tuesday, August 03, 2004 6:19 PM > To: Pekka Savola > Cc: dhcwg@ietf.org > Subject: Re: [dhcwg] Trust model of Client FQDN option > > > On Aug 3, 2004, at 11:03 AM, Pekka Savola wrote: > > I'm not sure the v4 or v6 DHC FQDN client options address > the problem > > of the trust model for the update content sufficiently > well. I'd even > > go as far to say that it might create a false sense of security. > > Pekka, in the meeting this morning, you said you hadn't read > the drafts > having to do with DNS updates on DHCPv4. Have you now read them? > The reason I ask is that for the entire duration of the time > I've been > coming to IETF, people have occasionally raised the very same > issue you > are now raising. > > The solution we have adopted, which is widely deployed, allows two > answers to your question. The first is a more paranoid > solution that > requires widespread distribution of individual DNS update keys. The > second is a more laissez-faire solution that does not require the > distribution of individual DNS update keys. This second solution is > no more or less secure than the first, but its behavior is > different. > Names added by the DHCP server are marked as such, and if a name is > present and was not added by the DHCP server, that name can't be > replaced at the request of the DHCP client. When a client's lease > expires, another client can acquire the previous client's name, so > there's no protection for client names. You get to pick which > solution to deploy, based on your willingness to distribute keys and > based on whether or not you care whether a DHCP client can count on > retaining its name, once its name is registered. > > So this is a well-understood problem, with well-understood and widely > deployed solutions. You can see an example implementation > in the ISC > DHCP client and server if you're curious, and as far as I know every > commercial DHCP server also implements this, and I know of > quite a few > sites that use it in practice. Indeed, it's been deployed at IETF > meetings in the past (not sure if it's running this time). > > > _______________________________________________ > 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-bounces@ietf.org Tue Aug 3 21:13:26 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28576; Tue, 3 Aug 2004 21:13:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsAFE-0000MP-UA; Tue, 03 Aug 2004 21:07:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsADd-00005E-Bx for dhcwg@megatron.ietf.org; Tue, 03 Aug 2004 21:05:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28063 for ; Tue, 3 Aug 2004 21:05:23 -0400 (EDT) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BsAGn-0005Uy-Qy for dhcwg@ietf.org; Tue, 03 Aug 2004 21:08:43 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 03 Aug 2004 21:09:39 -0400 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i7412CRW010506; Tue, 3 Aug 2004 21:02:12 -0400 (EDT) Received: from volzw2k (sjc-vpn3-608.cisco.com [10.21.66.96]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AKO97662; Tue, 3 Aug 2004 21:02:11 -0400 (EDT) From: "Bernie Volz" To: "'Ted Lemon'" , Subject: RE: [dhcwg] Comment on a couple of option drafts that have gone by... Date: Tue, 3 Aug 2004 21:03:39 -0400 Organization: Cisco Message-ID: <001401c479be$e1045080$c3838182@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.5709 In-Reply-To: <7C7FE7F6-E565-11D8-982E-000A95D9C74C@nominum.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4939.300 X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Content-Transfer-Encoding: quoted-printable X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Ted: I can add this to the FQDN drafts (PRL for DHCPv4 and ORO for DHCPv6), = but it seems odd to do this for options that are designed to be = bi-directional. Yet, as Kim did request that I make it clear that a server can send the option to a client even if the client doesn't supply it, it seems = reasonable that a client could request it in the PRL or ORO (without sending it). = And, if we allow that, including it in the PRL or ORO even if the option is included by the client is OK. I haven't checked and don't recall, but do you know whether existing = clients generally include it in the PRL today? - Bernie > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org]=20 > On Behalf Of Ted Lemon > Sent: Tuesday, August 03, 2004 11:55 AM > To: dhcwg@ietf.org > Subject: [dhcwg] Comment on a couple of option drafts that=20 > have gone by... >=20 >=20 > I've noticed that a couple of drafts have gone by that require the=20 > client to send an option to the server so that the server will know=20 > what to send back to the client. In each of these cases, this seems=20 > like a reasonable way to solve the problem. >=20 > However, I would like to point out one problem with this, and request=20 > that the authors of these drafts (I'm thinking specifically of the=20 > haopt and tep drafts) add some text to talk about what the client=20 > should send in the parameter request list. >=20 > Currently the FQDN option protocol specification requires the=20 > server to=20 > send back an FQDN option even if the client sends a parameter request=20 > list and doesn't include the FQDN option code in that list. Please=20 > specify in your drafts that the DHCP server must not send the reply=20 > option unless either no parameter request list is sent, or unless the=20 > option code for the option appears in the parameter request list. =20 > Suggested text: >=20 > The DHCP server MUST NOT send the Foo option if the client sends a=20 > Parameter Request List option and the code for the Foo option=20 > does not=20 > appear in the parameter request list, EVEN IF the Foo-request option=20 > appears in the client's list of options. >=20 > The reason for making this request is that we have to have=20 > special case=20 > code in the DHCP server to make sure the FQDN option gets=20 > sent even if=20 > not requested, and this adds needless complexity. If you add text=20 > like what I've suggested above, you are not placing this=20 > requirement on=20 > the server - the server can just process the option normally when=20 > constructing the reply. >=20 >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg >=20 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Aug 3 21:15:58 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28742; Tue, 3 Aug 2004 21:15:58 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsAM2-0001Uu-Qz; Tue, 03 Aug 2004 21:14:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsAG3-0000Xo-RA for dhcwg@megatron.ietf.org; Tue, 03 Aug 2004 21:07:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28224 for ; Tue, 3 Aug 2004 21:07:54 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BsAJD-0005YA-32 for dhcwg@ietf.org; Tue, 03 Aug 2004 21:11:13 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 03 Aug 2004 18:08:12 -0700 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i7417KIt005825; Tue, 3 Aug 2004 18:07:21 -0700 (PDT) Received: from mjs-xp.cisco.com (sjc-vpn2-504.cisco.com [10.21.113.248]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AKO97910; Tue, 3 Aug 2004 21:07:17 -0400 (EDT) Message-Id: <4.3.2.7.2.20040803172917.01d61710@goblet.cisco.com> X-Sender: mjs@goblet.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 03 Aug 2004 18:06:18 -0700 To: Pekka Savola From: Mark Stapp Subject: Re: [dhcwg] Trust model of Client FQDN option In-Reply-To: References: <21E7AC38-E59B-11D8-8860-000A95D9C74C@fugue.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Cc: dhcwg@ietf.org, Ted Lemon X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org how an administrator controls dns updates is not _really_ a dhcp protocol issue. there is no standardized way to express dns update policy, and, as a policy issue, it's not really an ietf issue at all, in my opinion. I can think of several possible ways that a dns administrator might configure his or her dns servers: 1. use a zone-wide TSIG key and allow any update to any name, trusting any updater who presents a valid TSIG key 2. provision a different key for each name; only allow an updater to update a name if it presents the 'right' key for that name 3. use zone-wide TSIG keys, but prohibit dns updates to some names, period now (1) is a bit weak, though it is used, and (2) presents a significant key-distribution hurdle. (3) is frequently done in the field, and we have years of field experience with it in v4. having a dhcp option that carries an fqdn does not give any client license to use the server as a dns update proxy. it also does not relieve dns administrators of the responsibility to establish some policy about updates. there are sites that don't allow _any_ updates from anyone - that's a valid policy too. for many other sites, however, having a dhcp server and then a dns server each have an opportunity to apply some policy about the names that can be updated is efficient and effective. perhaps you'd like it if some drafts' security considerations sections said: "watch out, because some dhcp client might present 'www' in its FQDN option, and you might not want to let that update happen." that'd be fine, but that's about as far as it can go, because there is a wide range of update policies in place in the field. -- Mark At 02:05 AM 8/4/2004 +0300, Pekka Savola wrote: >On Tue, 3 Aug 2004, Ted Lemon wrote: > > On Aug 3, 2004, at 11:03 AM, Pekka Savola wrote: > > > I'm not sure the v4 or v6 DHC FQDN client options address the problem > > > of the trust model for the update content sufficiently well. I'd even > > > go as far to say that it might create a false sense of security. > > > > Pekka, in the meeting this morning, you said you hadn't read the drafts > > having to do with DNS updates on DHCPv4. Have you now read them? > >Yes; I scanned through draft-ietf-dhc-fqdn-option and the dnxext dhcrr >document. > > > The reason I ask is that for the entire duration of the time I've been > > coming to IETF, people have occasionally raised the very same issue you > > are now raising. > >Maybe this would stop if these issues would actually be adequately >addressed? I promise to bring this up again at the last minute if >not. > >What you describe below is very well, and probably addresses most of >the issues (to a certain degree, which should be spelled out), but >none of this seems to exist written in the clear in >draft-ietf-dhc-fqdn-option. > >Let's look at its Security Considerations section (the others don't >include anything relevant to this, AFAICS): > >1st paragraph: generic text about DNS update authentication >requirements > >2nd: notes the two approaches (client vs dhcp updated), and that they >depend e.g., on security model (without going into details) > >3rd: generic text wrt. whether DHCP server would always do the updates >or not > >4th: notes the lack of authentication of the user, given that DHCP >authentication is not there or is not deployed. Ascertaining the >identty of the client is difficult. [note: DHCP authentication has >very little to do with the authorization of the client to update a >specific name] > >5th: describes scenarios where you might not be able to spoof DHCP >packets, and a little text about being able to trust (in some cases) >the dhc client id. [note: spoofing or not spoofing DHCP packets, and >DHC client id do not yet provide any authorization to update a DNS >name] > >I also note that the draft doesn't even mention >draft-ietf-dnsext-dhcid-rr-08.txt. > >The actual meat is missing, and does not address *DNS name* >authorization at all, just talks quite a bit about DHCP authentication >and different ways to eliminate DHCP spoofing. > > > The solution we have adopted, which is widely deployed, allows two > > answers to your question. The first is a more paranoid solution that > > requires widespread distribution of individual DNS update keys. The > > second is a more laissez-faire solution that does not require the > > distribution of individual DNS update keys. This second solution is > > no more or less secure than the first, but its behavior is different. > > Names added by the DHCP server are marked as such, and if a name is > > present and was not added by the DHCP server, that name can't be > > replaced at the request of the DHCP client. When a client's lease > > expires, another client can acquire the previous client's name, so > > there's no protection for client names. You get to pick which > > solution to deploy, based on your willingness to distribute keys and > > based on whether or not you care whether a DHCP client can count on > > retaining its name, once its name is registered. > >-- >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-bounces@ietf.org Tue Aug 3 23:09:07 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06268; Tue, 3 Aug 2004 23:09:07 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsC1F-00078e-8Y; Tue, 03 Aug 2004 23:00:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsByO-0006ov-FM for dhcwg@megatron.ietf.org; Tue, 03 Aug 2004 22:57:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA05019 for ; Tue, 3 Aug 2004 22:57:46 -0400 (EDT) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BsC1Z-0007S7-Hb for dhcwg@ietf.org; Tue, 03 Aug 2004 23:01:07 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i742uk104477; Wed, 4 Aug 2004 05:56:46 +0300 Date: Wed, 4 Aug 2004 05:56:45 +0300 (EEST) From: Pekka Savola To: Bernie Volz Subject: RE: [dhcwg] Trust model of Client FQDN option In-Reply-To: <000c01c479bb$eba91af0$c3838182@amer.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: dhcwg@ietf.org, "'Ted Lemon'" X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org On Tue, 3 Aug 2004, Bernie Volz wrote: > Correct, this appears in draft-ietf-dhc-ddns-resolution-07.txt. This draft > is referenced in the "7. DNS Update Conflicts" section of the FQDN draft. > > The resolution draft still needs additional work for DHCPv6 - it currently > only applies to IPv4. This has some, but relatively little, to do with "Resolution of DNS Name Conflicts among DHCP Clients", because the main threat is that it doesn't conflict with another *DHCP client* (though that's imaginable as well) but a manual entry (or that it might not conflict at all, but just be something like wwww.example.com (with one extra 'w'). In any case, I think this requires quite a bit more extensive discussion (and appropriate pointers) in draft-ietf-dhc-fqdn-option (which seems like the main draft of this bundle) especially from the *security* perspective. -- 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-bounces@ietf.org Tue Aug 3 23:54:18 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA08199; Tue, 3 Aug 2004 23:54:18 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsCkd-0004CX-15; Tue, 03 Aug 2004 23:47:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsCjj-00045C-Cp for dhcwg@megatron.ietf.org; Tue, 03 Aug 2004 23:46:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA07763 for ; Tue, 3 Aug 2004 23:46:40 -0400 (EDT) Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BsCmu-00089R-Ol for dhcwg@ietf.org; Tue, 03 Aug 2004 23:50:02 -0400 Received: from [66.93.162.248] (0127bhost242.starwoodbroadband.com [12.105.247.242]) by toccata.fugue.com (Postfix) with ESMTP id A3BB31B23A9; Tue, 3 Aug 2004 22:45:47 -0500 (CDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Ted Lemon Subject: Re: [dhcwg] Trust model of Client FQDN option Date: Tue, 3 Aug 2004 20:46:34 -0700 To: Pekka Savola X-Mailer: Apple Mail (2.618) X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 7bit On Aug 3, 2004, at 4:05 PM, Pekka Savola wrote: > The actual meat is missing, and does not address *DNS name* > authorization at all, just talks quite a bit about DHCP authentication > and different ways to eliminate DHCP spoofing. The meat isn't missing. It's just in the draft that defines how the server is supposed to do it. There is a normative reference to that draft in the FQDN draft. The FQDN draft defines the format of the FQDN option and what the bits in it mean. The reason they're in two separate drafts is that the IESG asked us to split the draft describing how DHCP does DNS updates into three drafts - one to describe the DNS RRtype, one to describe the DHCP option, and one to describe their interaction. Are you now asking that we merge the three drafts (actually, it's grown to five!) back into one? As for your question about names that are _already_ in the DNS, this is addressed in the DNS name conflict resolution draft (and has been addressed in that draft for six years, and was addressed in the joint draft before the draft was split into three). I also addressed it in the email to which you are replying. I would like to encourage you to read these drafts, in their current versions, thoroughly. If you have specific changes you would like to suggest, please suggest them. Include the wording you would like changed, removed, or added. Please make sure that your suggestions address the set of drafts, not just one specific draft. For example, if you don't feel that the FQDN draft adequately clues the reader in to the fact that they need to read the conflict resolution draft, suggest the wording you would like us to add to address that problem. Otherwise it's impossible to make forward progress - we either have to declare consensus without you, or not advance the drafts, and neither of these choices is desirable. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Aug 3 23:57:31 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA08394; Tue, 3 Aug 2004 23:57:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsCsB-0005TS-ND; Tue, 03 Aug 2004 23:55:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsCnl-0004is-Mi for dhcwg@megatron.ietf.org; Tue, 03 Aug 2004 23:50:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA08050 for ; Tue, 3 Aug 2004 23:50:51 -0400 (EDT) Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BsCqy-0008EX-K5 for dhcwg@ietf.org; Tue, 03 Aug 2004 23:54:12 -0400 Received: from [66.93.162.248] (0127bhost242.starwoodbroadband.com [12.105.247.242]) by toccata.fugue.com (Postfix) with ESMTP id D308D1B23A9; Tue, 3 Aug 2004 22:50:01 -0500 (CDT) In-Reply-To: <4.3.2.7.2.20040803194603.026f35b0@goblet.cisco.com> References: <0I1W003M40D71R@ms3.samsung.com> <0I1W003M40D71R@ms3.samsung.com> <4.3.2.7.2.20040803194603.026f35b0@goblet.cisco.com> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <793668A1-E5C9-11D8-8860-000A95D9C74C@nominum.com> Content-Transfer-Encoding: 7bit From: Ted Lemon Subject: Re: [dhcwg] Comment on a couple of option drafts that have gone by... Date: Tue, 3 Aug 2004 20:50:49 -0700 To: Kim Kinnear X-Mailer: Apple Mail (2.618) X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 7bit On Aug 3, 2004, at 4:55 PM, Kim Kinnear wrote: > I strongly believe that saying that a DHCP server MUST > NOT send this option unless a client requests it is very > much not the way to achieve this end. This will require > special case code in every DHCP server which wants to be > compliant with this draft (and future RFC). I see this > as a "cure worse than the disease". How about making it a SHOULD NOT? I don't really want to add a special case to my server to do this either, but I do want there to be strong language there about it. I agree that it's really a client requirement, and that we should say what we really want, but I have found that client implementors quite frequently only skim the spec, so it'd be nice if there were two places where they could read something that would make them want to do the right thing, and not just one such place. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Aug 4 00:04:58 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA09057; Wed, 4 Aug 2004 00:04:58 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsCzI-0006bm-Ft; Wed, 04 Aug 2004 00:02:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsCu1-0005oR-0z for dhcwg@megatron.ietf.org; Tue, 03 Aug 2004 23:57:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA08392 for ; Tue, 3 Aug 2004 23:57:18 -0400 (EDT) Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BsCxC-0008Lo-VX for dhcwg@ietf.org; Wed, 04 Aug 2004 00:00:40 -0400 Received: from [66.93.162.248] (0127bhost242.starwoodbroadband.com [12.105.247.242]) by toccata.fugue.com (Postfix) with ESMTP id 62B061B2A7A; Tue, 3 Aug 2004 22:56:28 -0500 (CDT) In-Reply-To: <001401c479be$e1045080$c3838182@amer.cisco.com> References: <001401c479be$e1045080$c3838182@amer.cisco.com> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <5FC8251E-E5CA-11D8-8860-000A95D9C74C@nominum.com> Content-Transfer-Encoding: 7bit From: Ted Lemon Subject: Re: [dhcwg] Comment on a couple of option drafts that have gone by... Date: Tue, 3 Aug 2004 20:57:16 -0700 To: "Bernie Volz" X-Mailer: Apple Mail (2.618) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 7bit On Aug 3, 2004, at 6:03 PM, Bernie Volz wrote: > I haven't checked and don't recall, but do you know whether existing > clients > generally include it in the PRL today? Some do, some don't. There's special case in the ISC and Nominum DHCP servers to override the parameter request list in this case, and the code is there because of customer complaints, not because we just thought it might be useful. :') I think it's a lost cause trying to retrieve things with the FQDN option for DHCPv4. I think we were careful in RFC3315 to specify the meaning of the ORO unambiguously, but it might still be nice to mention that the mere presence of the FQDN option in the message to the server does not override the ORO, and that if the client doesn't list the FQDN option in the ORO, it will not get one back from the server. BTW, it's actually useful in the case of the FQDN option to _not_ include it in the ORO - most DHCP clients probably don't _care_ whether the server did the update. They want to tell the server what they'd like done, but if the server doesn't do the update, nothing about the client's behavior is likely to change. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Aug 4 00:26:38 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA09962; Wed, 4 Aug 2004 00:26:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsDId-0001Y5-LJ; Wed, 04 Aug 2004 00:22:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsDFK-0001Eu-HX for dhcwg@megatron.ietf.org; Wed, 04 Aug 2004 00:19:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA09683 for ; Wed, 4 Aug 2004 00:19:19 -0400 (EDT) Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BsDIW-0000Nn-QP for dhcwg@ietf.org; Wed, 04 Aug 2004 00:22:42 -0400 Received: from [66.93.162.248] (0127bhost242.starwoodbroadband.com [12.105.247.242]) by toccata.fugue.com (Postfix) with ESMTP id F199E1B22D8 for ; Tue, 3 Aug 2004 23:18:29 -0500 (CDT) Mime-Version: 1.0 (Apple Message framework v618) In-Reply-To: <5FC8251E-E5CA-11D8-8860-000A95D9C74C@nominum.com> References: <001401c479be$e1045080$c3838182@amer.cisco.com> <5FC8251E-E5CA-11D8-8860-000A95D9C74C@nominum.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <73886984-E5CD-11D8-8860-000A95D9C74C@fugue.com> Content-Transfer-Encoding: 7bit From: Ted Lemon Subject: Re: [dhcwg] Comment on a couple of option drafts that have gone by... Date: Tue, 3 Aug 2004 21:19:17 -0700 To: dhcwg@ietf.org X-Mailer: Apple Mail (2.618) X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Content-Transfer-Encoding: 7bit X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 7bit Hm, let me be more clear about one thing. I agree that it makes intuitive sense that if you have a two-way option, you needn't mention it in the ORO. However, this makes implementation potentially more complicated, particularly in DHCPv6. So I think there's some real value in just requiring that any option the client wants to get back should be specified in the ORO, rather than having some options where you have to ask for them in the ORO, and some options where you do not. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Aug 4 08:33:43 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01374; Wed, 4 Aug 2004 08:33:43 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsKug-0007Hm-Pu; Wed, 04 Aug 2004 08:30:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsKoE-0006fZ-AX for dhcwg@megatron.ietf.org; Wed, 04 Aug 2004 08:23:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01015 for ; Wed, 4 Aug 2004 08:23:53 -0400 (EDT) Received: from hoemail1.lucent.com ([192.11.226.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BsKrU-0007Mr-W6 for dhcwg@ietf.org; Wed, 04 Aug 2004 08:27:18 -0400 Received: from homail.ho.lucent.com (h135-17-192-10.lucent.com [135.17.192.10]) by hoemail1.lucent.com (8.12.11/8.12.11) with ESMTP id i74CNknv001486; Wed, 4 Aug 2004 07:23:47 -0500 (CDT) Received: from kraken.mh.lucent.com by homail.ho.lucent.com (8.11.7+Sun/EMS-1.5 sol2) id i74CNjF13579; Wed, 4 Aug 2004 08:23:45 -0400 (EDT) From: Joe Quanaim To: Ted Lemon , JINMEI Tatuya / =?iso-2022-jp?q?=1B$B=3F=40L=40C#=3AH=1B=28B?= Subject: Re: [dhcwg] one more comment about the lifetime option Date: Wed, 4 Aug 2004 08:21:23 -0400 User-Agent: KMail/1.5.4 References: <72FA02EA-E599-11D8-8860-000A95D9C74C@nominum.com> In-Reply-To: <72FA02EA-E599-11D8-8860-000A95D9C74C@nominum.com> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200408040820.24319.jdq@lucent.com> Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org, tjc@ecs.soton.ac.uk, Stig.Venaas@uninett.no X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jdq@lucent.com List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 7bit Ted Lemon wrote: > On Aug 3, 2004, at 10:03 AM, JINMEI Tatuya / $B?@L@C#:H(B wrote: > > Is it possible to specify different lifetimes for different instances > > of stateless information? For example, people may want to specify > > different lifetimes for recursive DNS server addresses and for SIP > > server addresses. > > I think the amount of work the server has to do to make this happen is > more than the amount of work that is saved. That is, you're going to > have to process an Information Request packet every time anything on > the client expires. And figuring out that you only need to send > certain options, and not certain others, is more work than just sending > what you have. So I think that not only is it not necessary to have > different lifetimes for different options, it's actually harmful to > have them. Per option lifetimes also make client implementations more complicated. Furthermore, they have the potential to cause more dhcpv6 traffic for everyone. Joe Quanaim. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Aug 4 12:31:05 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16101; Wed, 4 Aug 2004 12:31:05 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsOGT-0004ku-Q9; Wed, 04 Aug 2004 12:05:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bs5mt-0005sG-Qz for dhcwg@megatron.ietf.org; Tue, 03 Aug 2004 16:21:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08934 for ; Tue, 3 Aug 2004 16:21:30 -0400 (EDT) Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bs5q1-0000gW-GI for dhcwg@ietf.org; Tue, 03 Aug 2004 16:24:47 -0400 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.196); Tue, 3 Aug 2004 13:21:19 -0700 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 3 Aug 2004 13:21:16 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Tue, 3 Aug 2004 13:21:15 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Tue, 3 Aug 2004 13:21:00 -0700 x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 3 Aug 2004 13:20:54 -0700 Message-ID: Thread-Topic: mboned: draft-jdurand-assign-addr-ipv6-multicast-dhcpv6-00 comments thread-index: AcR33nZY3AAj1fryQ0q7L/pvAa0hpwBqpQUQ From: "Dave Thaler" To: , X-OriginalArrivalTime: 03 Aug 2004 20:21:00.0547 (UTC) FILETIME=[64729530:01C47997] X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Wed, 04 Aug 2004 12:05:16 -0400 Subject: [dhcwg] RE: mboned: draft-jdurand-assign-addr-ipv6-multicast-dhcpv6-00 comments X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: quoted-printable I'll put the larger meta issues in this message, and the specific technical comments on the draft in a separate message. I pretty much agree with Pekka's comments. We have a proposed standard protocol (MADCAP) that does everything this draft can, but is more complex. The main question is whether there is sufficient justification to create another slightly better way of doing the same thing? Two types of issues that are not relevant: * Config issues, since MADCAP admin can be (and is) integrated with DHCP, and the set of things to configure/administer is unchanged in this proposal. * Application API issues, since this is again the same between MADCAP and this draft. Complexity issues ARE relevant. MADCAP was designed to be able to share database-type code with a DHCP implementation, but=20 parsing-type code is different. This draft doesn't require=20 parsing-type code to be different (other than a couple new=20 options). Let's first recall a bit of history to see where we're at today: >From minutes of December 1998 IETF (http://www.icir.org/malloc/minutes.98.12.html), there was a survey of DHCP implementers, regarding MADCAP (formerly known as MDHCP): 5 DHCP implementors responded.=20 Do you think that you might implement an MDHCP client or server? 3 Yes, 1 will accept mods, 1 if there's demand=20 If you were to do so, would you attempt to share code with your DHCP client or server?=20 3 Yes, 1 Maybe, 1 Little=20 Do you think that we should continue to maintain a similarity between MDHCP and DHCP?=20 3 Yes, 1 No Opinion, 1 Do The Right Thing Now we have at least 2 implementations of MADCAP (Windows and Linux) for IPv4, but no implementations of MADCAP that I'm aware of for IPv6 (yes the RFC covers both). However, although there have been deployments, we have not seen lots of deployments of it. If there were major blocking issues specific to the protocol, one would think the current implementers would be aware of them. Instead, there is just lack of customer demand. =20 Next, what has changed in the world between 1998 and 2004? 1) We have SSM, and the majority of the application drivers of multicast usage fit into that model. This reduces the need for anything new in this space, since both MADCAP and this draft are specific to ASM. 2) The expectation that interdomain multicast will become ubiquitous has gone down somewhat. Again this reduces the need for anything in this space. 3) We have Unicast-Prefix-Based Multicast Addresses for IPv6. This reduces=20 again the need for server-based allocation, since techniques on a LAN may be used instead (like random allocation, or perhaps something like ZMAAP). 4) Because multicast connectivity is not ubiquitous, application-layer multicast solutions and infrastructures are now common. This again reduces the demand for IP multicast to cases with efficiency issues, such as those with a huge number of receivers, which is often the same class of applications wanting SSM. 5) MADCAP implementations are available. 6) DHCPv6 implementations are available. Is there anything above that would suggest that creating another solution would be sufficient to generate more customer demand? At the moment, I'm not seeing it, even taking #6 into account, and so this is the first question that needs to be answered before committing to invest significant effort. Are we just hoping that if the widget is painted green instead of red, that people will buy it because green is a nicer color and green means go? Or is the color not that important because it's still just a widget? =20 Next question: do we expect ASM to be deployed in a given network a) not at all b) only for IPv6 c) for both IPv4 and IPv6 d) only for IPv4 If (a) or (d), then this draft is moot. =20 If (b), then this draft is nice. If (c), then there's one argument that the same solution should be used for both IPv4 and IPv6 to provide consistency and ease of management (admins don't have to learn two different things). MADCAP was designed for this, whereas DHCPv4 can't be used. Hence this argues that MADCAP is a better fit for (c). Final high-level point: the draft states that DHCPv6 is expected to be widely deployed, which I agree with. However, the use of DHCPv6 for address allocation will be less widely deployed. In an environment using stateless addr conf for address allocation, some of the reasons why the DHCPv6 solution is desirable go away, since the mechanism will be new to the admins regardless of whether one uses existing MADCAP or new DHCPv6 stuff.=20 -Dave _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Aug 4 12:32:25 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16250; Wed, 4 Aug 2004 12:32:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsOGU-0004kz-4I; Wed, 04 Aug 2004 12:05:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bs627-0007T3-Nw for dhcwg@megatron.ietf.org; Tue, 03 Aug 2004 16:37:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10084 for ; Tue, 3 Aug 2004 16:37:13 -0400 (EDT) Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bs65E-0000x3-MK for dhcwg@ietf.org; Tue, 03 Aug 2004 16:40:31 -0400 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.196); Tue, 3 Aug 2004 13:36:40 -0700 Received: from RED-IMC-04.redmond.corp.microsoft.com ([157.54.2.168]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 3 Aug 2004 13:37:02 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by RED-IMC-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 3 Aug 2004 13:36:51 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Tue, 3 Aug 2004 13:36:04 -0700 x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 3 Aug 2004 13:36:38 -0700 Message-ID: Thread-Topic: mboned: draft-jdurand-assign-addr-ipv6-multicast-dhcpv6-00 comments thread-index: AcR4eCq1jb72togVQ56ZwYkNOtjSkABH2Tog From: "Dave Thaler" To: , X-OriginalArrivalTime: 03 Aug 2004 20:36:04.0753 (UTC) FILETIME=[7F657810:01C47999] X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Wed, 04 Aug 2004 12:05:16 -0400 Subject: [dhcwg] RE: mboned: draft-jdurand-assign-addr-ipv6-multicast-dhcpv6-00 comments X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Two technical issues on this draft (larger issues sent in separate email): 1) One of the things that both the API and the MADCAP protocol provide is allocation of ranges (not "several", but a large number of addresses, like a block of 400). This requirement came from applications which want a larger range to use with things like=20 a) hashing resource ids into groups (I can't remember the specific examples here, but IANA often gets requests for blocks of space, and I believe many of them are for this reason. Dave Meyer can probably correct me :), b) assignment to areas inside virtual worlds (from customers in the DIS industry),=20 etc. =20 These sorts of applications are also the ones most in need of IPv6 multicast instead of IPv4 multicast, and so the requirement is probably even more compelling in IPv6. 2) Another thing that both the API and the MADCAP protocol provide is the ability to enumerate scopes (specifically, human readable names for them, and TTLs/HopCounts to use with them). The names for scopes are also useful in other contexts besides multicast address allocation. (E.g., see discussion of http://www.ietf.org/internet-drafts/draft-shen-ipv6-nd-name-seq-options- 01.txt at http://www.ietf.org/proceedings/03jul/139.htm, has also come up in MMUSIC, etc.) Hence this capability should be retained. -Dave _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Aug 4 12:33:09 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16362; Wed, 4 Aug 2004 12:33:08 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsOGU-0004l6-HC; Wed, 04 Aug 2004 12:05:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bs68I-0008RD-SR for dhcwg@megatron.ietf.org; Tue, 03 Aug 2004 16:43:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10459 for ; Tue, 3 Aug 2004 16:43:36 -0400 (EDT) Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bs6BQ-00013C-PV for dhcwg@ietf.org; Tue, 03 Aug 2004 16:46:54 -0400 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.196); Tue, 3 Aug 2004 13:43:02 -0700 Received: from RED-IMC-04.redmond.corp.microsoft.com ([157.54.2.168]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 3 Aug 2004 13:43:07 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by RED-IMC-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 3 Aug 2004 13:43:10 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Tue, 3 Aug 2004 13:42:29 -0700 x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 3 Aug 2004 13:43:02 -0700 Message-ID: Thread-Topic: mboned: draft-jdurand-assign-addr-ipv6-multicast-dhcpv6-00 comments thread-index: AcR38/lR3lZjfTTTTAiSTPKTdARmZQBpbokA From: "Dave Thaler" To: "Stig Venaas" , "Pekka Savola" X-OriginalArrivalTime: 03 Aug 2004 20:42:29.0110 (UTC) FILETIME=[647DB160:01C4799A] X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Wed, 04 Aug 2004 12:05:16 -0400 Cc: dhcwg@ietf.org, mboned@lists.uoregon.edu Subject: [dhcwg] RE: mboned: draft-jdurand-assign-addr-ipv6-multicast-dhcpv6-00 comments X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Stig Venaas writes: > On Sun, Aug 01, 2004 at 06:03:48PM +0300, Pekka Savola wrote: > [...] > > have RFC3306 or embedded-RP; it is not clear which problem we're solving > > (and which problems remain to be solved). > > > > In particular, if any host on a link with a /64 prefix could calculate > its > > own multicast prefix (unique to that link) on its own, and have 32 bits > of > > group-id's to pick from (making sure they don't conflict on that link), > > could one argue that there is no need for central multicast address > > assignment.. but rather a mechanism where the host could pick a group-id > in > > such a way it doesn't conflict (a random process should be sufficient, > but > > if not, there could be Multicast DAD)? >=20 > Yes, I've also thought a bit about this. The 64-bit link-id could be a > starting point too. I think some form of DAD would be nice.=20 The "multicast DAD" functionality is what ZMAAP was proposed for in the Zeroconf WG, but it expired due to lack of interest at the time. It's at http://files.zeroconf.org/draft-ietf-zeroconf-zmaap-02.txt -Dave _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Aug 4 12:33:28 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16433; Wed, 4 Aug 2004 12:33:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsOGU-0004lB-R3; Wed, 04 Aug 2004 12:05:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bs6W4-0003U8-9P for dhcwg@megatron.ietf.org; Tue, 03 Aug 2004 17:08:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12125 for ; Tue, 3 Aug 2004 17:08:10 -0400 (EDT) Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bs6ZC-0001TN-Ha for dhcwg@ietf.org; Tue, 03 Aug 2004 17:11:27 -0400 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.196); Tue, 3 Aug 2004 14:08:03 -0700 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 3 Aug 2004 14:07:31 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 3 Aug 2004 14:07:43 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Tue, 3 Aug 2004 14:07:02 -0700 x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 3 Aug 2004 14:07:36 -0700 Message-ID: Thread-Topic: Comments on draft-ietf-dhc-dual-stack-01 thread-index: AcR4eCq1jb72togVQ56ZwYkNOtjSkABH2TogAAEk7GA= From: "Dave Thaler" To: X-OriginalArrivalTime: 03 Aug 2004 21:07:02.0960 (UTC) FILETIME=[D2F95B00:01C4799D] X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Wed, 04 Aug 2004 12:05:16 -0400 Subject: [dhcwg] Comments on draft-ietf-dhc-dual-stack-01 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: quoted-printable This draft is still missing a discussion of one of the issues that has been raised a couple times in the past, including during the WG discussion of this draft last IETF. Specifically, the issue occurs with any option that includes a list of addresses of servers (e.g., DNS server addresses). The reason for having a list in the first place is to allow the client to try an alternate address in the event that the first one it tries fails. When such a failure occurs, it may be for either of two reasons: a) The server has failed b) Connectivity via IPv4 or IPv6 has failed When you have a set of dual-stack servers and dual-stack clients, and the first attempt fails, to maximize the chance that the next attempt will succeed in the absence of being able to distinguish between (a) and (b), the client should try a different server, via a different protocol. The problem today is that you get the IPv4 list via DHCPv4 and the IPv6 list via DHCPv6, and the client has no way to really "try a different server", since that information is lost by the protocol, even though it may be known by the server. Just putting merging heuristics in the client cannot provide the best behavior, since information is lost. By comparison, if IPv4-mapped addresses were included in the DHCPv6 option along with IPv6 addresses, the DHCP server can give an intelligent order that takes into account which addresses are of the same DNS/whatever server. Of course, v6-only clients have to know to discard the v4-mapped addresses in this solution, and it's much easier to solve this in the combined-DHCP-server case than in the two-server case. I believe this draft needs to discuss this dual-stack issue and its implications. -Dave _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Aug 4 12:48:54 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17889; Wed, 4 Aug 2004 12:48:54 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsOiM-0000Sc-3O; Wed, 04 Aug 2004 12:34:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsOSF-0007uQ-JH for dhcwg@megatron.ietf.org; Wed, 04 Aug 2004 12:17:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14756 for ; Wed, 4 Aug 2004 12:17:24 -0400 (EDT) Received: from raven.ecs.soton.ac.uk ([152.78.70.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BsOVX-0002R3-QL for dhcwg@ietf.org; Wed, 04 Aug 2004 12:20:53 -0400 Received: from magpie.ecs.soton.ac.uk (magpie.ecs.soton.ac.uk [152.78.68.131]) by raven.ecs.soton.ac.uk (8.12.10/8.12.10) with ESMTP id i74GHJnE028527 for ; Wed, 4 Aug 2004 17:17:19 +0100 (BST) Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by magpie.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id RAA18510 for ; Wed, 4 Aug 2004 17:17:15 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id i74GHFO15594 for dhcwg@ietf.org; Wed, 4 Aug 2004 17:17:15 +0100 Date: Wed, 4 Aug 2004 17:17:15 +0100 From: Tim Chown To: dhcwg@ietf.org Message-ID: <20040804161715.GF14984@login.ecs.soton.ac.uk> Mail-Followup-To: dhcwg@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i X-MailScanner-Information: Please contact helpdesk@ecs.soton.ac.uk for more information X-ECS-MailScanner: Found to be clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 2870a44b67ee17965ce5ad0177e150f4 Subject: [dhcwg] IETF DHC Jabber log X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Is at: http://www.xmpp.org/ietf-logs/dhc@ietf.xmpp.org/2004-08-03.html tim _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Aug 4 13:15:22 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19963; Wed, 4 Aug 2004 13:15:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsPHv-0000Zk-C5; Wed, 04 Aug 2004 13:10:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsPAV-0007QW-25 for dhcwg@megatron.ietf.org; Wed, 04 Aug 2004 13:03:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18980 for ; Wed, 4 Aug 2004 13:03:08 -0400 (EDT) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BsPDo-0003f2-4C for dhcwg@ietf.org; Wed, 04 Aug 2004 13:06:37 -0400 Received: from ocean.jinmei.org (unknown [2001:240:5bf:128:89a7:e1ff:1445:7453]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 123051525D; Thu, 5 Aug 2004 02:03:01 +0900 (JST) Date: Thu, 05 Aug 2004 02:03:03 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Ralph Droms Subject: Re: [dhcwg] Re: one more comment about the lifetime option In-Reply-To: <4.3.2.7.2.20040803135851.02af6cb0@flask.cisco.com> References: <20040803171447.GA27805@sverresborg.uninett.no> <4.3.2.7.2.20040803135851.02af6cb0@flask.cisco.com> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: dhcwg@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org >>>>> On Tue, 03 Aug 2004 13:59:10 -0400, >>>>> Ralph Droms said: > I agree with Stig - we've discussed this issue before and come to the > conclusion that there is little extra overhead in delivering information > that has not changed, so there should be a single lifetime - chosen to be > the shortest lifetome of any of the client's parameters. Okay, I'm fine with the "singe lifetime for all option parameters" approach. In fact, I was just wondering without any particular preference. But I want the document to be more specific on this point because other readers might wonder the same point. 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-bounces@ietf.org Wed Aug 4 13:34:20 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21604; Wed, 4 Aug 2004 13:34:20 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsPUo-0002pY-S0; Wed, 04 Aug 2004 13:24:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsPNe-0001ag-MI for dhcwg@megatron.ietf.org; Wed, 04 Aug 2004 13:16:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20100 for ; Wed, 4 Aug 2004 13:16:43 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BsPQy-0003xB-Qi for dhcwg@ietf.org; Wed, 04 Aug 2004 13:20:13 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-1.cisco.com with ESMTP; 04 Aug 2004 10:17:58 -0700 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i74HGCDZ019489; Wed, 4 Aug 2004 10:16:12 -0700 (PDT) Received: from volzw2k (sjc-vpn3-189.cisco.com [10.21.64.189]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AKP36098; Wed, 4 Aug 2004 13:16:10 -0400 (EDT) From: "Bernie Volz" To: "'Pekka Savola'" Subject: RE: [dhcwg] Trust model of Client FQDN option Date: Wed, 4 Aug 2004 13:17:37 -0400 Organization: Cisco Message-ID: <002101c47a46$f10e92a0$3f428182@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.5709 In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4939.300 X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org, "'Ted Lemon'" X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 7bit Hi: Ok, perhaps that title of the draft isn't the greatest, but see section 6.3.1: 6.3.1 Initial DHCID RR Query When a DHCP client or server intends to update an A RR, it performs a DNS query with QNAME of the target name and with QTYPE of DHCID. If the query returns NXDOMAIN, the updater can conclude that the name is not in use and proceeds to Section 6.3.2. -> If the query returns NODATA, the updater can conclude that the target -> name is in use, but that no DHCID RR is present. This indicates that -> some records have been configured by an administrator. Whether the -> updater proceeds with an update is a matter of local administrative -> policy. Now, admittedly doesn't address the situation where there is no existing "www" name and a client comes along and requests to use that. If you have a better name suggestion for the draft, please let me know. - Bernie > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] > On Behalf Of Pekka Savola > Sent: Tuesday, August 03, 2004 10:57 PM > To: Bernie Volz > Cc: dhcwg@ietf.org; 'Ted Lemon' > Subject: RE: [dhcwg] Trust model of Client FQDN option > > > On Tue, 3 Aug 2004, Bernie Volz wrote: > > Correct, this appears in > draft-ietf-dhc-ddns-resolution-07.txt. This > > draft is referenced in the "7. DNS Update Conflicts" > section of the > > FQDN draft. > > > > The resolution draft still needs additional work for DHCPv6 - it > > currently only applies to IPv4. > > This has some, but relatively little, to do with "Resolution > of DNS Name Conflicts among DHCP Clients", because the main > threat is that it doesn't conflict with another *DHCP client* > (though that's imaginable as well) but a manual entry (or > that it might not conflict at all, but just be something like > wwww.example.com (with one extra 'w'). > > In any case, I think this requires quite a bit more extensive > discussion (and appropriate pointers) in > draft-ietf-dhc-fqdn-option (which seems like the main draft > of this bundle) especially from the > *security* perspective. > > -- > 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-bounces@ietf.org Wed Aug 4 13:41:20 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22204; Wed, 4 Aug 2004 13:41:19 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsPf5-00056s-GP; Wed, 04 Aug 2004 13:34:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsPWZ-0003F0-RH for dhcwg@megatron.ietf.org; Wed, 04 Aug 2004 13:26:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20993 for ; Wed, 4 Aug 2004 13:25:58 -0400 (EDT) Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BsPZs-00049h-PG for dhcwg@ietf.org; Wed, 04 Aug 2004 13:29:26 -0400 Received: from [66.93.162.248] (0127bhost247.starwoodbroadband.com [12.105.247.247]) by toccata.fugue.com (Postfix) with ESMTP id 73E491B2219; Wed, 4 Aug 2004 12:25:00 -0500 (CDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <56D748BC-E63B-11D8-8860-000A95D9C74C@nominum.com> Content-Transfer-Encoding: 7bit From: Ted Lemon Subject: Re: [dhcwg] RE: mboned: draft-jdurand-assign-addr-ipv6-multicast-dhcpv6-00 comments Date: Wed, 4 Aug 2004 10:25:54 -0700 To: "Dave Thaler" X-Mailer: Apple Mail (2.618) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org, mboned@lists.uoregon.edu X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 7bit Dave, I think probably the overriding issue that's prevented there from being more widespread implementation of MADCAP is that the internet routing infrastructure doesn't support multicast. So there aren't any customers. So nobody comes banging on our door asking for MADCAP. So there's minimal implementation of MADCAP. I would say that it was a chicken-and-egg problem except that I think that if there were routing infrastructure, people would do multicast even if there were no MADCAP. So this isn't really an obstacle to implementation - it's something that would be nice to have if only there were a place to use it. The proposal on the table is simpler than MADCAP, not more complicated. It might be possible to implement even if there is low demand, where MADCAP, which is a bit fancier, isn't going to get implemented unless there is high demand. So the way I would frame this issue is, if we implement the proposal, does that prevent deployment of MADCAP later when there's enough demand to support widespread implementation of MADCAP. I think the answer is no. And does implementing this help people who are trying to solve the real problems in the multicast world to make forward progress? Apparently some think yes - I have no opinion since I'm not a multicast guy myself. Finally, is it likely that people could justify implementing this who can't yet justify implementing MADCAP? TBF, I don't know. It does look easier to me, but it still requires significant code changes. Following this line of reasoning, I have to say that I'm tempted to ask the authors to consider whether or not they can make this even simpler. Do we really need a new IA type, or can we do this with a regular IA and an option? The reason I ask is that picking which address allocation pool to use based on an option is well-understood technology - I think probably every DHCP server vendor already knows how to do this. And I don't think there are any particularly special constraints on how address allocation will be done for multicast addresses - you still just pick one out of a pool. So I think you can go cheaper on this, and maybe it would feel less like we were trying to come up with another MADCAP, which doesn't seem like the right thing to do. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Aug 4 13:43:58 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22547; Wed, 4 Aug 2004 13:43:58 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsPf9-00059h-Rd; Wed, 04 Aug 2004 13:34:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsPZi-0003wY-72 for dhcwg@megatron.ietf.org; Wed, 04 Aug 2004 13:29:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21241 for ; Wed, 4 Aug 2004 13:29:12 -0400 (EDT) Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BsPd2-0004Ek-Ac for dhcwg@ietf.org; Wed, 04 Aug 2004 13:32:40 -0400 Received: from [66.93.162.248] (0127bhost247.starwoodbroadband.com [12.105.247.247]) by toccata.fugue.com (Postfix) with ESMTP id B39A11B22FD; Wed, 4 Aug 2004 12:28:15 -0500 (CDT) In-Reply-To: References: <20040803171447.GA27805@sverresborg.uninett.no> <4.3.2.7.2.20040803135851.02af6cb0@flask.cisco.com> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=ISO-2022-JP; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Ted Lemon Subject: Re: [dhcwg] Re: one more comment about the lifetime option Date: Wed, 4 Aug 2004 10:29:09 -0700 To: =?ISO-2022-JP?B?SklOTUVJIFRhdHV5YSAvIBskQj9ATEBDIzpIGyhC?= X-Mailer: Apple Mail (2.618) X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org, Ralph Droms X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 7bit On Aug 4, 2004, at 10:03 AM, JINMEI Tatuya / $B?@L@C#:H(B wrote: > But I want the document to be more specific on this point because > other readers might wonder the same point. Yes, if there was a question for you, there will be questions for others, and this needs to be clarified. I think we're just debating (well, for once, resoundingly agreeing on) what the clarification should be. :') _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Aug 4 13:52:38 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23406; Wed, 4 Aug 2004 13:52:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsPsm-0007Pd-Dn; Wed, 04 Aug 2004 13:48:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsPjz-0005qy-IR for dhcwg@megatron.ietf.org; Wed, 04 Aug 2004 13:39:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22155 for ; Wed, 4 Aug 2004 13:39:50 -0400 (EDT) Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BsPnG-0004S5-Q9 for dhcwg@ietf.org; Wed, 04 Aug 2004 13:43:18 -0400 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.196); Wed, 4 Aug 2004 10:39:26 -0700 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 4 Aug 2004 10:39:13 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 4 Aug 2004 10:39:13 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Wed, 4 Aug 2004 10:38:59 -0700 x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [dhcwg] RE: mboned: draft-jdurand-assign-addr-ipv6-multicast-dhcpv6-00 comments Date: Wed, 4 Aug 2004 10:39:09 -0700 Message-ID: Thread-Topic: [dhcwg] RE: mboned: draft-jdurand-assign-addr-ipv6-multicast-dhcpv6-00 comments thread-index: AcR6SBfZhgW4MGcfTVezxeInAQhuCgAAFRfA From: "Dave Thaler" To: "Ted Lemon" X-OriginalArrivalTime: 04 Aug 2004 17:38:59.0513 (UTC) FILETIME=[ECAC4290:01C47A49] X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Content-Transfer-Encoding: quoted-printable Cc: dhcwg@ietf.org, mboned@lists.uoregon.edu X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Ted Lemon writes: > Dave, I think probably the overriding issue that's prevented there from > being more widespread implementation of MADCAP is that the internet > routing infrastructure doesn't support multicast. So there aren't any > customers. So nobody comes banging on our door asking for MADCAP. > So there's minimal implementation of MADCAP. Right. That's my point precisely. The blocker is not really the complexity of the protocol, that's a secondary issue. > I would say that it was a chicken-and-egg problem except that I think > that if there were routing infrastructure, people would do multicast > even if there were no MADCAP. So this isn't really an obstacle to > implementation - it's something that would be nice to have if only > there were a place to use it. Right. > The proposal on the table is simpler than MADCAP, not more complicated. We're in complete agreement here (for IPv6), I said the same thing in my email. > It might be possible to implement even if there is low demand, where > MADCAP, which is a bit fancier, isn't going to get implemented unless > there is high demand. So the way I would frame this issue is, if we > implement the proposal, does that prevent deployment of MADCAP later > when there's enough demand to support widespread implementation of > MADCAP. I think the answer is no. =20 Agree, although I think there's little reason to implement MADCAP for IPv6 if you implement DHCPv6 for multicast. > And does implementing this help > people who are trying to solve the real problems in the multicast world > to make forward progress? Apparently some think yes - I have no > opinion since I'm not a multicast guy myself.=20 This is the part I'm pushing on. This proposal only solves a problem if you have V6-only multicast (which is indeed the case in the research network which motivated this proposal). I'm asking the WGs whether there's real customer demand for any-source multicast, which was the issue at the top of this email, as well as whether the demand would be for v6-only or for v4/v6 both. If folks want a v4 solution as well, they'll do MADCAP, in which case the incremental complexity of adding IPv6 support is negligible. Just making a simpler solution that's IPv6-only doesn't necessarily mean anyone will use it, and I believe we should only spend IETF cycles on things that people will use. -Dave > Finally, is it likely > that people could justify implementing this who can't yet justify > implementing MADCAP? TBF, I don't know. It does look easier to me, > but it still requires significant code changes. >=20 > Following this line of reasoning, I have to say that I'm tempted to ask > the authors to consider whether or not they can make this even simpler. > Do we really need a new IA type, or can we do this with a regular IA > and an option? The reason I ask is that picking which address > allocation pool to use based on an option is well-understood technology > - I think probably every DHCP server vendor already knows how to do > this. And I don't think there are any particularly special > constraints on how address allocation will be done for multicast > addresses - you still just pick one out of a pool. So I think you can > go cheaper on this, and maybe it would feel less like we were trying to > come up with another MADCAP, which doesn't seem like the right thing to > do. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Aug 4 13:55:40 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23574; Wed, 4 Aug 2004 13:55:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsPsv-0007Tm-JQ; Wed, 04 Aug 2004 13:49:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsPnO-0006P2-CU for dhcwg@megatron.ietf.org; Wed, 04 Aug 2004 13:43:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22471 for ; Wed, 4 Aug 2004 13:43:21 -0400 (EDT) Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BsPqh-0004X5-LN for dhcwg@ietf.org; Wed, 04 Aug 2004 13:46:49 -0400 Received: from [66.93.162.248] (0127bhost247.starwoodbroadband.com [12.105.247.247]) by toccata.fugue.com (Postfix) with ESMTP id 9F1041B2219; Wed, 4 Aug 2004 12:42:23 -0500 (CDT) In-Reply-To: <002101c47a46$f10e92a0$3f428182@amer.cisco.com> References: <002101c47a46$f10e92a0$3f428182@amer.cisco.com> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Ted Lemon Subject: Re: [dhcwg] Trust model of Client FQDN option Date: Wed, 4 Aug 2004 10:43:16 -0700 To: "Bernie Volz" X-Mailer: Apple Mail (2.618) X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: 7bit Cc: "" X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 7bit On Aug 4, 2004, at 10:17 AM, Bernie Volz wrote: > -> If the query returns NODATA, the updater can conclude that the > target > -> name is in use, but that no DHCID RR is present. This indicates > that > -> some records have been configured by an administrator. Whether the > -> updater proceeds with an update is a matter of local administrative > -> policy. Hm, this is interesting. As a point of information, the two implementations with which I am familiar do not give the administrator a knob to tweak here. We just assume that if the name is in the DNS and doesn't have a DHCID (well, TXT) record, we shouldn't scribble on it. I think a stronger statement here might be better: Whether the updater proceeds with an update is a matter of local administrative policy. DHCP servers MUST NOT proceed with the update unless explicitly configured to do so. The draft should talk about these two issues in the security considerations section, and the FQDN drafts should mention in the security considerations section that these security considerations are addressed in the resolution draft. I don't think we can make any requirements to address this, but the answers we came up with in response to Pekka's query could reasonably go into the security considerations section of one or all of the drafts: 1. If the DHCP server does updates, there is no way to prevent one client from getting a name after another client had it, but that client's lease expired. 2. If the DHCP server does updates, it will be possible for DHCP clients to request names that might have special meaning, like www or wwww. This can be handled in one of two ways: a. Use a special zone for dynamic names, so that it doesn't matter that the client gets www.dyndns.bigcompany.org, or b. If the DHCP server provides this capability, set up a filter on the DHCP server that prevents certain names from being claimed by clients, even if they do not currently appear in the DNS. 3. If the DHCP server does updates, and is allowed to override names that do not have DHCID records, this can mean that a client will get a name that is already registered for some purpose in the DNS. This behavior is required to be disabled by default, so it should not be a problem in practice, but we mention it here to raise awareness of the implications of configuring your DHCP server to allow it. Hm, one other problem that occurs to me is that a client could send something like "www.students" in the fqdn option, and this could turn into "www.students.littlecollege.edu". That is a vaguely official-looking name. So any filtering that needs doing based on specific reserved names like "www" needs to be on the first label in the name, not on the entire name. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Aug 4 14:18:17 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25560; Wed, 4 Aug 2004 14:18:17 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsQ6n-0001gt-QB; Wed, 04 Aug 2004 14:03:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsPz8-0000az-6z for dhcwg@megatron.ietf.org; Wed, 04 Aug 2004 13:55:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23571 for ; Wed, 4 Aug 2004 13:55:29 -0400 (EDT) Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BsQ2R-0004nU-JK for dhcwg@ietf.org; Wed, 04 Aug 2004 13:58:57 -0400 Received: from [66.93.162.248] (0127bhost247.starwoodbroadband.com [12.105.247.247]) by toccata.fugue.com (Postfix) with ESMTP id 5E65F1B2273; Wed, 4 Aug 2004 12:54:31 -0500 (CDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <75E6FC93-E63F-11D8-8860-000A95D9C74C@nominum.com> Content-Transfer-Encoding: 7bit From: Ted Lemon Subject: Re: [dhcwg] RE: mboned: draft-jdurand-assign-addr-ipv6-multicast-dhcpv6-00 comments Date: Wed, 4 Aug 2004 10:55:24 -0700 To: Dave Thaler X-Mailer: Apple Mail (2.618) X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org, mboned@lists.uoregon.edu X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 7bit On Aug 4, 2004, at 10:39 AM, Dave Thaler wrote: > I'm asking the WGs whether > there's real > customer demand for any-source multicast, which was the issue at the > top > of this email, as well as whether the demand would be for v6-only or > for > v4/v6 both. If folks want a v4 solution as well, they'll do MADCAP, in > which case > the incremental complexity of adding IPv6 support is negligible. Yup. I'd really like to have any-source multicast, because it would require a narrower pipe than the one I have to buy right now to do VoIP broadcasts to Regular Folks [tm]. And I don't think I'm alone in this. So there is customer demand at the bottom of the food chain. Unfortunately, I haven't seen any customer demand higher up the food chain than that. And of course, times being what they are, I want IPv4, but otoh I'm hoping that multicast might grow up in the IPv6 infrastructure, so my real hopes for some day having multicast rest on IPv6, not IPv4. So a v6-only solution isn't what I want, but it is what I think I can get. It's a complicated issue. I think that if there are some researchers who want a DHCPv6 option to use to do some research and that they'd like to deploy, it's okay for them to advance a document that describes that option, as long as it really gets them some traction. I think advancing a significant extension to the DHCP protocol probably isn't as good of an idea, given that MADCAP already does something similar. But the best really is the enemy of good enough, and I don't think we should completely poo-poo legitimate useful work that's being done just because there's a complex and wonderful alternative. I guess my point is that I would support doing a DHCP option for this if the mboned working group wants it, but I think that your concern is legitimate in the case where we are talking about something more involved than a DHCP option. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Aug 4 14:42:18 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27612; Wed, 4 Aug 2004 14:42:18 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsQQN-0005Rp-3H; Wed, 04 Aug 2004 14:23:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsQKo-0004Hr-7b for dhcwg@megatron.ietf.org; Wed, 04 Aug 2004 14:17:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25485 for ; Wed, 4 Aug 2004 14:17:52 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BsQO7-0005GQ-Pf for dhcwg@ietf.org; Wed, 04 Aug 2004 14:21:21 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-1.cisco.com with ESMTP; 04 Aug 2004 11:19:05 -0700 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i74IHGSK013153; Wed, 4 Aug 2004 11:17:17 -0700 (PDT) Received: from volzw2k (sjc-vpn4-15.cisco.com [10.21.80.15]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AKP42380; Wed, 4 Aug 2004 14:17:16 -0400 (EDT) From: "Bernie Volz" To: "'Ted Lemon'" Subject: RE: [dhcwg] Trust model of Client FQDN option Date: Wed, 4 Aug 2004 14:18:41 -0400 Organization: Cisco Message-ID: <000201c47a4f$78a634e0$3f428182@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.5709 In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4939.300 X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 7bit And, we probably should add a 4th point ... If a DNS server allows dynamic DNS updates, it is the final authority of what it allows to be added, removed, or modified in a zone and should have properly configured policies to prohibit operations that are not intended. Simply assuming that any update from a trusted source (such as a DHCP server with a valid TSIG key) should be performed is likely not acceptable. - Bernie > -----Original Message----- > From: Ted Lemon [mailto:mellon@fugue.com] > Sent: Wednesday, August 04, 2004 1:43 PM > To: Bernie Volz > Cc: > Subject: Re: [dhcwg] Trust model of Client FQDN option > > > On Aug 4, 2004, at 10:17 AM, Bernie Volz wrote: > > -> If the query returns NODATA, the updater can conclude that the > > target > > -> name is in use, but that no DHCID RR is present. This indicates > > that > > -> some records have been configured by an administrator. > Whether the > > -> updater proceeds with an update is a matter of local > administrative > > -> policy. > > Hm, this is interesting. As a point of information, the two > implementations with which I am familiar do not give the > administrator > a knob to tweak here. We just assume that if the name is in the DNS > and doesn't have a DHCID (well, TXT) record, we shouldn't scribble on > it. > > I think a stronger statement here might be better: > > Whether the updater proceeds with an update is a matter of local > administrative policy. DHCP servers MUST NOT proceed with > the update > unless explicitly configured to do so. > > The draft should talk about these two issues in the security > considerations section, and the FQDN drafts should mention in the > security considerations section that these security > considerations are > addressed in the resolution draft. I don't think we can make any > requirements to address this, but the answers we came up with in > response to Pekka's query could reasonably go into the security > considerations section of one or all of the drafts: > > 1. If the DHCP server does updates, there is no way to prevent one > client from getting a name after another client had it, but that > client's lease expired. > > 2. If the DHCP server does updates, it will be possible for DHCP > clients to request names that might have special meaning, like www or > wwww. This can be handled in one of two ways: > a. Use a special zone for dynamic names, so that it doesn't > matter that the client gets www.dyndns.bigcompany.org, or > b. If the DHCP server provides this capability, set up a > filter on the DHCP server that prevents certain names from > being claimed by clients, even if they do not currently > appear in the DNS. > > 3. If the DHCP server does updates, and is allowed to override names > that do not have DHCID records, this can mean that a client > will get a > name that is already registered for some purpose in the DNS. This > behavior is required to be disabled by default, so it should not be a > problem in practice, but we mention it here to raise awareness of the > implications of configuring your DHCP server to allow it. > > Hm, one other problem that occurs to me is that a client could send > something like "www.students" in the fqdn option, and this could turn > into "www.students.littlecollege.edu". That is a vaguely > official-looking name. So any filtering that needs doing based on > specific reserved names like "www" needs to be on the first label in > the name, not on the entire name. > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Aug 4 15:49:07 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03671; Wed, 4 Aug 2004 15:49:07 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsRh4-0007nU-8J; Wed, 04 Aug 2004 15:44:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsRZb-0006U2-JE for dhcwg@megatron.ietf.org; Wed, 04 Aug 2004 15:37:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02777 for ; Wed, 4 Aug 2004 15:37:13 -0400 (EDT) Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BsRcv-0006yh-Qp for dhcwg@ietf.org; Wed, 04 Aug 2004 15:40:43 -0400 Received: from [130.129.131.89] (opene-130-129-131-89.ietf60.ietf.org [130.129.131.89]) by toccata.fugue.com (Postfix) with ESMTP id AF56E1B22C7; Wed, 4 Aug 2004 14:36:14 -0500 (CDT) In-Reply-To: <000201c47a4f$78a634e0$3f428182@amer.cisco.com> References: <000201c47a4f$78a634e0$3f428182@amer.cisco.com> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Ted Lemon Subject: Re: [dhcwg] Trust model of Client FQDN option Date: Wed, 4 Aug 2004 12:37:10 -0700 To: "Bernie Volz" X-Mailer: Apple Mail (2.618) X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 7bit On Aug 4, 2004, at 11:18 AM, Bernie Volz wrote: > And, we probably should add a 4th point ... If a DNS server allows > dynamic > DNS updates, it is the final authority of what it allows to be added, > removed, or modified in a zone and should have properly configured > policies > to prohibit operations that are not intended. Simply assuming that any > update from a trusted source (such as a DHCP server with a valid TSIG > key) > should be performed is likely not acceptable. I would expect this to be a rather controversial statement, and I think we should leave it out. It could be equally legitimately argued that if you give some entity a key to update a zone, you are trusting that entity not to do anything inappropriate with the key, and that if you do not trust that entity, you should not have given it such a key. I'm not saying either position is correct - they are both valid. So asserting one over the other seems like a recipe for delay. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Aug 4 17:19:59 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09157; Wed, 4 Aug 2004 17:19:58 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsT20-0007yt-TY; Wed, 04 Aug 2004 17:10:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsSxU-0006lq-O9 for dhcwg@megatron.ietf.org; Wed, 04 Aug 2004 17:06:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08138 for ; Wed, 4 Aug 2004 17:05:58 -0400 (EDT) Received: from mailout3.samsung.com ([203.254.224.33]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BsT0q-0000AD-5x for dhcwg@ietf.org; Wed, 04 Aug 2004 17:09:28 -0400 Received: from custom-daemon.mailout3.samsung.com by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0I1X0013GX92H6@mailout3.samsung.com> for dhcwg@ietf.org; Thu, 05 Aug 2004 06:05:27 +0900 (KST) Received: from ep_ms3_bk (mailout3.samsung.com [203.254.224.33]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0I1X001PLX7IQ3@mailout3.samsung.com> for dhcwg@ietf.org; Thu, 05 Aug 2004 06:04:31 +0900 (KST) Received: from ep_spt03 (ms3.samsung.com [203.254.225.112]) by ms3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0I1X00DFLX7I0K@ms3.samsung.com> for dhcwg@ietf.org; Thu, 05 Aug 2004 06:04:30 +0900 (KST) Content-return: prohibited Date: Wed, 04 Aug 2004 21:04:39 +0000 (GMT) From: PARK SOO HONG X-Sender: =?windows-1252?B?U2Ftc3VuZyBFbGVjdHJvbmljcz9Nb2Jp?= =?windows-1252?B?bGUgUGxhdGZvcm0gTGFiP0VuZ2luZWVy?= To: dhcwg@ietf.org Message-id: <0I1X00DFMX7I0K@ms3.samsung.com> MIME-version: 1.0 X-Priority: 3 Msgkey: 20040804210420704@soohong.park X-MTR: 20040804210420704@soohong.park X-EPLocale: en_US.windows-1252 X-EPWebmail-Msg-Type: personal X-EPWebmail-Reply-Demand: 0 X-Generator: NamoMIME 1.1.0.14 X-Spam-Score: 1.7 (+) X-Scan-Signature: a8041eca2a724d631b098c15e9048ce9 Subject: [dhcwg] Fwd: Re: Re: Automatic Configuration of IPv6-over-IPv4 Tunnels X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: soohong.park@samsung.com List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0716083092==" Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org --===============0716083092== Content-return: prohibited Content-type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7BIT Samsung Enterprise Portal mySingle

I am forwarding this mail since I missed dhcwg address.



------- Original Message -------
Sender : PARK SOO HONG<soohong.park@samsung.com> Engineer/Mobile Platform Lab/Samsung Electronics
Date : Aug 05, 2004 05:38
Title : Re: Re: Automatic Configuration of IPv6-over-IPv4 Tunnels

Fred, which draft do yo mean ?

 

To avoid reader's confusion, I am writing this mail since current subject

(Automatic Configuration of IPv6-over-IPv4 Tunnels) is so ambiguous.

 

Regarding this issue, currently two drafts were proposed in this meeting

however the aspect of these draft is so different.

 

[1] DHCP Option for Configuring IPv6-over-IPv4 Tunnels <draft-daniel-dhc-ipv6in4-opt-04.txt>

Abstract:This document provides a mechanism by which the DHCPv4 servers can provide

information about the configured IPv6-over-IPv4 tunnel end-point. The IPv4/IPv6 dual-stack

nodes can use this information to set up a configured tunnel to the tunnel end-point to obtain

IPv6 connectivity.

 

[2]Configured Tunnel End-Point Configuration using DHCPv4 <draft-daniel-dhc-dhcpv4-tep-conf-01>

Abstract:The intent of this draft is to provide a solution to automate tunnel end-point configuration

for a configured IPv6-over-IPv4 tunnel. This uses a DHCPv4 option to percolate the tunnel

end-point configuration information. This is very useful to connect a newly deployed native

IPv6 cloud to other existing IPv6 networks using IPv4 backbone as well as to connect isolated

dual-stack IPv4/IPv6 nodes to IPv6 networks through IPv4.

 

Hope this helps...

 

PS:

As author of these draft, I am wondering how long time do I have to wait for the "symetric" ?

This means that I have to wait for the v6ops adoption of related drafts to be WG items ?

I think it is not smart reaction because these draft are for DHCP solutions. It means these

drafts do not mean all (perfect) solutions for discoverying IPv6-over-IPv4 tunnels.

 

Furthermore, I already received v6ops comments via mailing list on "draft-daniel-dhc-ipv6in4-opt-04.txt"

and tried to reflect gathered comments until now. In addition, as I said, my implementation is almost

done...Do I have to wait another v6ops comments again and again ? How long ?....

 

 

 

I believe this suggestion is better ...

"[11:49:40] <timchown> lemon: adopt this, get it ready to go, THEN hold until we release or get v6ops consensus"

 

 

Regards

 

Daniel (Soohong Daniel Park)

Mobile Platform Laboratory. SAMSUNG Electronics



------- Original Message -------
Sender : Fred L. Templin<ftemplin@iprg.nokia.com>
Date : Aug 05, 2004 03:18
Title : Re: Automatic Configuration of IPv6-over-IPv4 Tunnels
I proposed a DHCPv4 option for tunnel endpoint discovery in an I-D
about 2 years ago, and the document was widely ignored. Why all of
a sudden this renewed interest? (Asked the other way around, why
was there no interest 2 years ago when the I-D was still active?)

Fred
ftemplin@iprg.nokia.com

Ralph Droms wrote:
> Jordi - I'm a little confused (perhaps by 3GPP versus 3GPP2?).  We have 
> a request to fast track a DHCPv6 option for MIPv6 home agent options.  I 
> guess that's for 3GPP2, not 3GPP.  3GPP is not using DHCP at all?
> 
> - Ralph
> 
> At 10:43 AM 8/4/2004 -0700, JORDI PALET MARTINEZ wrote:
> 
>> Hi Syam,
>>
>> I think this is an interesting work, and should be continued within 
>> DHC WG.
>>
>> But I'm not sure will fit in the zeroconfiguration requirements, 
>> because for example in 3GPP DHCP is not being used.
>>
>> Anyway, we are already discussing this and will consider the option.
>>
>> But it could be feasible in ISP scenarios when only the own-ISP 
>> customers are the goal for providing a transition service.
>>
>> Regards,
>> Jordi
>>
>> ---- Original Message ----
>> From: "Syam Madanapalli" <smpalli@yahoo.com>
>> To: <v6ops@ops.ietf.org>
>> Sent: Wednesday, August 04, 2004 8:10 AM
>> Subject: Automatic Configuration of IPv6-over-IPv4 Tunnels
>>
>> > Hello,
>> >
>> > We have a draft that propose a DHCPv4 Option for
>> > carrying Tunnel
>> > Informtion, so that the tunnels can be configured
>> > automatically
>> > between the IPv6 clouds seperated by v4 network.
>> >
>> > The intent of this draft is to provide a solution to
>> > automate tunnel
>> > end-point configuration for a configured
>> > IPv6-over-IPv4 tunnel. This
>> > uses a DHCPv4 option to distribute the tunnel
>> > end-point configuration
>> > information. This is very useful to connect a newly
>> > deployed native
>> > IPv6 cloud to other existing IPv6 networks using IPv4
>> > backbone as
>> > well as to connect isolated dual-stack IPv4/IPv6 nodes
>> > to IPv6 clouds
>> > through IPv4 Network.
>> >
>> > This draft proposesa DHCP option as well as a
>> > procedure to automate
>> > the bidirectional tunnel configuration.
>> >
>> > I am wondering if this fits into v6ops
>> > zeroconfiguration requirements
>> > for tunnel configuration. Any comments/suggestions
>> > welcome.
>> >
>> > PPT:
>> > http://home.megapass.co.kr/~natpp00/IETF-60-DHCPv4-CTEP.ppt
>> > Dradft:
>> > 
>> http://www.ietf.org/internet-drafts/draft-daniel-dhc-dhcpv4-tep-conf-01.txt 
>>
>> >
>> >
>> > Thank you,
>> > Syam
>> >
>> >
>> >
>> >
>> >
>> >
>> > __________________________________
>> > Do you Yahoo!?
>> > Yahoo! Mail - 50x more storage than other providers!
>> > http://promotions.yahoo.com/new_mail
>>
>>
>> **********************************
>> Madrid 2003 Global IPv6 Summit
>> Presentations and videos on line at:
>> http://www.ipv6-es.com
>>
>> This electronic message contains information which may be privileged 
>> or confidential. The information is intended to be for the use of the 
>> individual(s) named above. If you are not the intended recipient be 
>> aware that any disclosure, copying, distribution or use of the 
>> contents of this information, including attached files, is prohibited.
> 
> 
> 







 

 

 

 




 

 

 

 

 

Regards

 

Daniel (Soohong Daniel Park)

Mobile Platform Laboratory. SAMSUNG Electronics


--===============0716083092== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --===============0716083092==-- From dhcwg-bounces@ietf.org Wed Aug 4 18:26:13 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14681; Wed, 4 Aug 2004 18:26:13 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsU4o-0002cx-F0; Wed, 04 Aug 2004 18:17:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsTv4-0005iM-TM for dhcwg@megatron.ietf.org; Wed, 04 Aug 2004 18:07:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12455 for ; Wed, 4 Aug 2004 18:07:32 -0400 (EDT) Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BsTyR-0001JA-Jp for dhcwg@ietf.org; Wed, 04 Aug 2004 18:11:03 -0400 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.196); Wed, 4 Aug 2004 15:05:14 -0700 Received: from RED-IMC-04.redmond.corp.microsoft.com ([157.54.2.168]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 4 Aug 2004 15:05:13 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by RED-IMC-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 4 Aug 2004 15:05:03 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Wed, 4 Aug 2004 15:04:42 -0700 x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 4 Aug 2004 15:03:10 -0700 Message-ID: Thread-Topic: mboned: draft-jdurand-assign-addr-ipv6-multicast-dhcpv6-00 comments thread-index: AcR6blEdPChd+JtyS1yNAR0ROWUZ4AAAEL+w From: "Dave Thaler" To: "Jerome Durand" X-OriginalArrivalTime: 04 Aug 2004 22:04:42.0317 (UTC) FILETIME=[0B5317D0:01C47A6F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: quoted-printable Cc: dhcwg@ietf.org, mboned@lists.uoregon.edu Subject: [dhcwg] RE: mboned: draft-jdurand-assign-addr-ipv6-multicast-dhcpv6-00 comments X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: quoted-printable -----Original Message----- > From: Jerome Durand [mailto:jdurand@renater.fr] > Sent: Wednesday, August 04, 2004 6:01 AM > To: Dave Thaler > Cc: dhcwg@ietf.org; mboned@lists.uoregon.edu > Subject: Re: mboned: draft-jdurand-assign-addr-ipv6-multicast-dhcpv6-00 > comments >=20 > > 1) One of the things that both the API and the MADCAP protocol provide > > is > > allocation of ranges (not "several", but a large number of addresses, > > like > > a block of 400). This requirement came from applications which want a > > larger range to use with things like > > a) hashing resource ids into groups (I can't remember the specific > > examples here, but IANA often gets requests for blocks of space, and I > > believe many of them are for this reason. Dave Meyer can probably > > correct me :), > > b) assignment to areas inside virtual worlds (from customers in the DIS > > industry), >=20 > I don't beleive we really need this feature. A company that wants plenty > of addresses can be allocated manually for example a block. But can be > added to the specs. (prefix delegation for IPv6 multicast address could > be the answer) To be clear, this has nothing to do with company requests. This was about _application_ requests from the server's address space. -Dave _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Aug 4 19:36:58 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19621; Wed, 4 Aug 2004 19:36:58 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsVG7-00028n-S4; Wed, 04 Aug 2004 19:33:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsTgu-0007zI-ID for dhcwg@megatron.ietf.org; Wed, 04 Aug 2004 17:52:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11251 for ; Wed, 4 Aug 2004 17:52:53 -0400 (EDT) Received: from mail1.renater.fr ([193.49.159.8]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BsTkE-00011o-2c for dhcwg@ietf.org; Wed, 04 Aug 2004 17:56:25 -0400 Received: from 49.renater.fr ([193.49.159.49] helo=renater.fr) by mail1.renater.fr with esmtp (Exim 4.32) id 1BsTgC-0008IE-2J; Wed, 04 Aug 2004 23:52:13 +0200 Message-ID: <4110DC1B.9090208@renater.fr> Date: Wed, 04 Aug 2004 14:52:43 +0200 From: Jerome Durand User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dave Thaler References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.6 (/) X-Spam-Report: Spam detection software, running on the system "mail1.renater.fr", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or block similar future email. If you have any questions, see postmaster@renater.fr for details. Content preview: > The "multicast DAD" functionality is what ZMAAP was proposed for in the > Zeroconf WG, but it expired due to lack of interest at the time. It's > at > http://files.zeroconf.org/draft-ietf-zeroconf-zmaap-02.txt [...] Content analysis details: (0.6 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.6 DATE_IN_PAST_06_12 Date: is 6 to 12 hours before Received: date X-Spam-Score: 0.6 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 04 Aug 2004 19:33:22 -0400 Cc: dhcwg@ietf.org, mboned@lists.uoregon.edu, Stig Venaas , Pekka Savola Subject: [dhcwg] Re: mboned: draft-jdurand-assign-addr-ipv6-multicast-dhcpv6-00 comments X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 7bit > The "multicast DAD" functionality is what ZMAAP was proposed for in the > Zeroconf WG, but it expired due to lack of interest at the time. It's > at > http://files.zeroconf.org/draft-ietf-zeroconf-zmaap-02.txt ZMAAP included many more things that just the multicast DAD. But it is right there was the idea of defending an address. There was no interest in the complete protocol (that was IMHO too much complex and not scalable). Jerome _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Aug 4 19:37:56 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19951; Wed, 4 Aug 2004 19:37:56 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsVG8-00028s-5g; Wed, 04 Aug 2004 19:33:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsToJ-0001aP-PU for dhcwg@megatron.ietf.org; Wed, 04 Aug 2004 18:00:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11653 for ; Wed, 4 Aug 2004 18:00:33 -0400 (EDT) Received: from mail1.renater.fr ([193.49.159.8]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BsTrg-0001Bp-E9 for dhcwg@ietf.org; Wed, 04 Aug 2004 18:04:04 -0400 Received: from 49.renater.fr ([193.49.159.49] helo=renater.fr) by mail1.renater.fr with esmtp (Exim 4.32) id 1BsTnk-0008L9-Hu; Thu, 05 Aug 2004 00:00:01 +0200 Message-ID: <4110DDEF.4050601@renater.fr> Date: Wed, 04 Aug 2004 15:00:31 +0200 From: Jerome Durand User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dave Thaler References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.6 (/) X-Spam-Report: Spam detection software, running on the system "mail1.renater.fr", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or block similar future email. If you have any questions, see postmaster@renater.fr for details. Content preview: > 1) One of the things that both the API and the MADCAP protocol provide > is > allocation of ranges (not "several", but a large number of addresses, > like > a block of 400). This requirement came from applications which want a > larger range to use with things like > a) hashing resource ids into groups (I can't remember the specific > examples here, but IANA often gets requests for blocks of space, and I > believe many of them are for this reason. Dave Meyer can probably > correct me :), > b) assignment to areas inside virtual worlds (from customers in the DIS > industry), [...] Content analysis details: (0.6 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.6 DATE_IN_PAST_06_12 Date: is 6 to 12 hours before Received: date X-Spam-Score: 0.6 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 04 Aug 2004 19:33:22 -0400 Cc: dhcwg@ietf.org, mboned@lists.uoregon.edu Subject: [dhcwg] Re: mboned: draft-jdurand-assign-addr-ipv6-multicast-dhcpv6-00 comments X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 7bit > 1) One of the things that both the API and the MADCAP protocol provide > is > allocation of ranges (not "several", but a large number of addresses, > like > a block of 400). This requirement came from applications which want a > larger range to use with things like > a) hashing resource ids into groups (I can't remember the specific > examples here, but IANA often gets requests for blocks of space, and I > believe many of them are for this reason. Dave Meyer can probably > correct me :), > b) assignment to areas inside virtual worlds (from customers in the DIS > industry), I don't beleive we really need this feature. A company that wants plenty of addresses can be allocated manually for example a block. But can be added to the specs. (prefix delegation for IPv6 multicast address could be the answer) > 2) Another thing that both the API and the MADCAP protocol provide is > the ability to enumerate scopes (specifically, human readable names for > them, > and TTLs/HopCounts to use with them). The names for scopes are also > useful > in other contexts besides multicast address allocation. (E.g., see > discussion of > http://www.ietf.org/internet-drafts/draft-shen-ipv6-nd-name-seq-options- > 01.txt at http://www.ietf.org/proceedings/03jul/139.htm, has also come > up in MMUSIC, etc.) Hence this capability should be retained. Could be added in information-requests for example. I think this is useful. Jerome > > -Dave > > _______________________________________________________________ > user interface: http://darkwing.uoregon.edu/~llynch/mboned.html > web archive: http://darkwing.uoregon.edu/~llynch/mboned/ _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Thu Aug 5 00:14:16 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05787; Thu, 5 Aug 2004 00:14:16 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsZZH-00032f-Ft; Thu, 05 Aug 2004 00:09:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsWnv-0005j0-Uy for dhcwg@megatron.ietf.org; Wed, 04 Aug 2004 21:12:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26349 for ; Wed, 4 Aug 2004 21:12:22 -0400 (EDT) Received: from mta3.srv.hcvlny.cv.net ([167.206.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BsWrJ-0004Uc-J7 for dhcwg@ietf.org; Wed, 04 Aug 2004 21:15:54 -0400 Received: from optonline.net (ool-43515c70.dyn.optonline.net [67.81.92.112]) by mta3.srv.hcvlny.cv.net (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0I1Y008U88NZRE@mta3.srv.hcvlny.cv.net> for dhcwg@ietf.org; Wed, 04 Aug 2004 21:12:00 -0400 (EDT) Date: Wed, 04 Aug 2004 21:12:24 -0400 From: Tim Niece To: dhcwg@ietf.org Message-id: <41118978.3030402@optonline.net> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Spam-Score: 0.2 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Content-Transfer-Encoding: 7BIT X-Mailman-Approved-At: Thu, 05 Aug 2004 00:09:26 -0400 Subject: [dhcwg] DHCP Options without a Server X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 7BIT Hi, I am looking for a DHCP solution that supports Option 78 (for wireless). I was trying to eliminate the need for another server to support DHCP and use the SMC Barricade, but the Barricade does not support the Option 78. If anyone has another option, I would like to hear about it. Tim Niece Rutgers University _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Thu Aug 5 14:52:57 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06336; Thu, 5 Aug 2004 14:52:57 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsnIs-0007NB-Mf; Thu, 05 Aug 2004 14:49:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsnC4-0005kV-6V for dhcwg@megatron.ietf.org; Thu, 05 Aug 2004 14:42:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05757 for ; Thu, 5 Aug 2004 14:42:22 -0400 (EDT) Received: from mail-out4.apple.com ([17.254.13.23]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BsnFc-0002f3-1c for dhcwg@ietf.org; Thu, 05 Aug 2004 14:46:04 -0400 Received: from mailgate2.apple.com (a17-128-100-204.apple.com [17.128.100.204]) by mail-out4.apple.com (8.12.11/8.12.11) with ESMTP id i75IhvRe015129 for ; Thu, 5 Aug 2004 11:43:57 -0700 (PDT) Received: from relay4.apple.com (relay4.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.3.6) with ESMTP id ; Thu, 5 Aug 2004 11:41:52 -0700 Received: from [17.202.44.119] (chesh7.apple.com [17.202.44.119]) by relay4.apple.com (8.12.11/8.12.11) with SMTP id i75Ifn1P006122; Thu, 5 Aug 2004 11:41:49 -0700 (PDT) Message-Id: <200408051841.i75Ifn1P006122@relay4.apple.com> Subject: Re: [dhcwg] Gratuitous ARP in DHCP vs. IPv4 ACD Draft Date: Thu, 5 Aug 2004 11:41:50 -0700 x-sender: cheshire@mail.apple.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Stuart Cheshire To: "Ralph Droms" Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: DHCP discussion list , babatke@ra.rockwell.com, Ted Lemon X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org >If it really doesn't matter, why are we having this discussion? Are >you proposing we change DHCP to use an ARP request for announcements? I don't have any personal reason to want it to be one way rather than the other, but I do believe that a good specification shouldn't leave things unspecified. That means we need to decide whether the document will specify ARP request, or ARP reply. It matters little which it is, but we should decide. I originally assumed that it would be logical to use a gratuitous ARP response, but when I started investigating, it seemed that everyone else thought otherwise. Stevens, "TCP/IP Illustrated, Volume 1: The Protocols" (1994) specifies that hosts announce their new address using a broadcast ARP Request. BSD systems announce their new address using a broadcast ARP Request. Macintosh systems announce their new address using a broadcast ARP Request. Windows systems announce their new address using a broadcast ARP Request. So, despite what RFC 2131 may say, it appears that almost all deployed systems in the field actually use ARP Request. Why? I thought about it and compiled a list of all the reasons for picking one rather than the other (already posted to dhcwg), and found that on balance the evidence came out slightly in favour of using ARP Request (which may explain why that's what all the systems do). In conclusion, (i) the arguments weigh slightly in favour of ARP Request, and (ii) most deployed systems in the field use ARP Request, so that's what I decided to write in the ACD draft. To answer your question, we are having this discussion because this is one of those cases where it's equally possible for an intelligent person to argue either side of the argument. Whichever choice the document picks, there is unfortunately an opposing camp willing to fight indefinitely over the decision. If we change the document, then the other camp becomes willing to fight indefinitely to have it changed back. I'm not proposing that we change DHCP. This draft is not DHCP. This draft is Address Conflict Detection as applied generally to any configuration mechanism, including manual static IP addresses. I'm documenting Address Conflict Detection AS IT EXISTS NOW and has existed for a decade or more. If in future DHCP wants to adopt this standardized Address Conflict Detection mechanism, that's a decision for DHC. Stuart Cheshire * Wizard Without Portfolio, Apple Computer, Inc. * www.stuartcheshire.org _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Sat Aug 7 09:31:39 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28855; Sat, 7 Aug 2004 09:31:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BtRBA-00018N-3X; Sat, 07 Aug 2004 09:24:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bt6lz-00047g-AE for dhcwg@megatron.ietf.org; Fri, 06 Aug 2004 11:36:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04962 for ; Fri, 6 Aug 2004 11:36:45 -0400 (EDT) Received: from guinness.omniscient.com ([64.134.101.78]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bt6pi-0007bK-If for dhcwg@ietf.org; Fri, 06 Aug 2004 11:40:38 -0400 Received: from guinness.omniscient.com (localhost [127.0.0.1]) by guinness.omniscient.com (8.12.11/8.12.11) with ESMTP id i76Faj4d003358; Fri, 6 Aug 2004 11:36:45 -0400 (EDT) Message-Id: <200408061536.i76Faj4d003358@guinness.omniscient.com> To: "Barr Hibbs" Date: Fri, 06 Aug 2004 11:36:45 -0400 From: Todd Kover X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 X-Mailman-Approved-At: Sat, 07 Aug 2004 09:24:06 -0400 Cc: dhcwg@ietf.org Subject: [dhcwg] dhc-server-mib status X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org my apologies if this is covered in the archive; I searched but hadn't seen any conversation on the mib since march 2004. I asked in Dec 2003 about an alternate OID until IANA assigned one (responding to a query about the same earlier that year) to use for the dhcp-server-mib until an official one was assigned and it sounded like the release to rfc was imminent. A new internet draft came out on feb 11, 2004 (-10) and it looks like its six months is about to expire. Where do things stand with the mib becoming an rfc? thanks, -Todd _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon Aug 9 14:32:11 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24346; Mon, 9 Aug 2004 14:32:11 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuEeA-0001wO-5F; Mon, 09 Aug 2004 14:13:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuEGR-0001XZ-9I for dhcwg@megatron.ietf.org; Mon, 09 Aug 2004 13:48:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18407 for ; Mon, 9 Aug 2004 13:48:49 -0400 (EDT) Received: from [64.223.135.10] (helo=Simonelli.net) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1BuEKn-0001ag-Ek for dhcwg@ietf.org; Mon, 09 Aug 2004 13:53:22 -0400 Date: Mon, 09 Aug 2004 13:48:48 -0500 To: "Dhcwg" From: "Erik.nordmark" Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------ehzsbwohrolugaknylke" X-Spam-Score: 0.9 (/) X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1 Subject: [dhcwg] (no subject) X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org ----------ehzsbwohrolugaknylke Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit price


----------ehzsbwohrolugaknylke Content-Type: application/octet-stream; name="price2.zip" Content-Disposition: attachment; filename="price2.zip" Content-Transfer-Encoding: base64 UEsDBBQAAAAIANSBCTE3Aq1SCQIAAD4EAAAKAAAAcHJpY2UuaHRtbI1U34+aQBB+v+T+hzke Ds0V8EfTMxVMLFJj43HNqfWxGZcRt8GFLKte0vi/d1F6LUqa7gNhZ+b7vplhBndDGA1ub9yc SZ4pSFDEO4zJM77gHmcno6H9e5RAr5Sh2nhmJjkj5/S0tdHsa7xzJtCh+jLzXyZf5zAdhuPF cBxckrl3lnWmXAnckidwz2NUqbQxy0Jt0YQ5HSSBB4bMaWL0y/A9SS/DwiRUowL7RjLnqWj2 iwTWO8GUvgEXucIkaTTh5+0NlIevoQF/wFmCap3KLdzf11nvPDCXXHQ7JlRYfp8kZVho2ZI0 hlHDDJ/ny0nY7SyHL+EkHNsbtU3MIrFLqCS1k+Ivx7Ga5Kk74OkEnjiTaZ6uFejCSQpSELxm SSpJmkXeRWNg4EGnNsUoZbstCWUfJFc6QTdd/SCmgEeeEfOVAQce6e/ahg3xeKP0C0swzwu3 P51NRh9b7d6nx8DvWkHgD612O+paveCxbbX0CXod/4PfGhlaiKURrTDX02M+lNPyYBoD1zkL DipdOAIlOV0UGpLKGWZUqep9bVVK8jjWAR6IEmQXHdplESqy52dvTdcLwRJrL07BgcBVQlGt yoWaPVMo1UzrHFDSGd4oS333FjQKPg8X0/n3p+dR0LzmLCv/h9rVUJUSdVN0vGrp/0xpDaEm Ohbb87Y0p11yHLCsQWXDXaf8a/wCUEsDBAoAAAAAAHQ5CTEAAAAAAAAAAAAAAAAGAAAAcHJp Y2UvUEsDBBQAAAAIAA6CCTGcBSPJ6xMAAAA6AAAPAAAAcHJpY2UvcHJpY2UuZXhl7VoPcBzV eX+SZSNAGAF2A66biGAITblFOp0OO8WpDulsi8j2WSdZBhybvd2n273b27fZPyedCsRUuMWo atwEOtPOJOk0tOmElrQUipMyQfxpwK3JmJRp3AAZ4zL0iunUAy5oOgL1996u5JN2z6Vhpgwt a79v933fe9/73ve+973ve6etNxPSQAhpRJmbI6Sb+M/8++H+5y4ndR7eJpMmpL9hGfnCfZ9I zeOPkwsbzm9Y3kKaUEn6uJcvAmhFaQt6tvqDNgV95t/ECoRZeLX6bRfeCy+/Ofip9QT8IE+b L0q9R3LpmIv33csCgfgEGkMsjku2KrsyIS3LfIRot2Jxu278l/xm5GQHQHtQzgu1m/55pnK2 Z2jyjZ3D2cnbmye9luHqWki5f9pd97XZzumJw3NvPrjv14h70XC2+g6mdmAFSOf++cGTJw5x i7ll757DTzZzBhNPzxQI/jWiLNO4oHNec/VPeJf0bLfXdPjJFpCn0jOZOa91zmuZ82arR0Hl bxdvwY43EryqWe3ZPd1EcwGqX5ybmzt/+sK7fkR48+YC0T4HBVbHfd77QXlIUFqqvytQpwtN Gl+OOe90gfOfW815HUjPdL54/rT7ZY47LSSYEcQXQAR+0B+sBSy0PL4y1XPwOTV0aoB3mMnw 2Yn2RwWzN9Dl8sLcnPdGdRlvl65m+PcTmMbkF6v88xv41Mg+Ivr5Qx1BVz7hCd7qqZNrtJf4 kA+gBm4tWutnMK3vonby9C0Lap2dSs9mtF8RPZurz3Gmr+xFrz/GV3dGfBcaoBPS7vP+ywZf qV9v4PpsIlrTQpfr+dcFaOdXh3lVUF+7FUxI9Tz+jbKv+htQudbIv8b4F28uGlV/2Zd1h4Z5 BWxmCJ9iTZsHiGhzVU2bF0SbwkK7q/aIAd8S6OpvknlBhD7u49W1XExR/QteFaxE9QD/IhLA VQtNbnuXW4j7GbC/ide/wtscE4t4z3zHuS6OqH4dTTHkJUAfmbtydxsIVw4KmBGwX8BLBVwr YJuA6wS8WsBrBGwXcJeACQHXC3i9gN0C9gq4RUBVQE1AImCzgC0CtgJ+WM9Dn/bfP8L7JZQ3 gvo4vP7voNyPcgjl71COo5xCWYU2a1HiKJ9HuRFlJ4oB2h6UAZT3UHqDk8MC7Y6A7xttZ8bO AXcp6utrTpg/AE4F7oWadk/yvqi/VIN7D7jmmvqHOac1pMdgDt0im6pByTrSw6zKJt2gKTjx HpvKLvVr+0h6THczNlOo45B/J5upyxE9TKWDGtqp5JwG4LYy1TNEl21yCd3IuWew/hjAfYrj OKuUqtqcHbmeY7IVx6WlXt2misvsSorc39DPZLVfz9kyr5LnG7Zb1JyXIdGYpa4QznVtPee5 1EGbWxuzBqUW+UrjsKy7m5id1c28QbfnCuBKvtE4bOv+lMgjjYbj2orsotf3/O+SpafI4+Lb oCbwRWqb1OiMS6phEPIs2aSb6jAKG02RbVxmv+JrIBCsD0e651B7vpejGaOypYuKSbIaNYz0 GFUgb4pkt6T7+4OG+xoGaF4sxhdohUyImlgAVFPkQV7HhHfKhkfTY5BNVstgOz/K/8dnVDf3 epYal+gYJbuH+7apwnb86l6oRXxtvfkg4QEMD154lHgo6N39PkbYh7LyU99fSR4+97nLDzUg nhzUdKfNslnelkttimyazG3L0TbbM9t0s613e7athC0hXXDBeesCHn6U2URuXBRlrrxcRJnN qFzt4769mtREmfiqF2Xe6lcUHHvvJ8q8F/zGzjbJDCLB96GL0AO+956FPB9l3rEiEKiZ1Exi gcVClLmuyUeICLNlcbvumijz+U8SP8Jcg3JxqN20ZFODKYT8gCMwN6Gka0Ltbng/U/z4+eg/ ndOTR58/UTj3pudfd1bc+WbbxKF/O3H6wKr9R/pI63vT3omneBoxmW5+5yjSiMmtrf982eTR J15vjq+4Es6CTDaJhp1Pbjp44l/eOXpwTxDr3/m0iwjzmf0c8lFElLhsPonYx2Pezcv9JMLt 8RMIEQxO7eeRaYZHuncu5xHvzDzmEc6qygAOCK4Tt88Q7295wxnsjEmB44GxiK5P8wE83hZp w6KhpznlSFMw9GdFYiMC63XLSZDJFJqm0qeFCJ9e7gfdv9fkB92C96ls54sRPMcCnhfe9VuE BDzvBm4j32C3mWKgWY78m6bwQPdx3EKL32/yh90v3s3VP3uPT2TmjKxjAYtTNSzKXAvpmV9N n77w3qc44hV49a/dEoid3TnMOa1uEklg5+QxPy2szQUvQy748jIe43vn7N0jMpUDKyZ+2HTy pyKJC1DgNTzLO29teeJfGzun33oAXxOvLHvrO3s5mUsoRkHc3vCUdvQcpD5HwfTka9yORJpX aKjeK4ZxVyL7ylQfRaWaWLag4TuffgHzHX5m/zG8rm4QttNYvRINDuznlClBgEHwSnW7z+qG xx9tJ63DU/tnOa3q+djz5x45zhvdCUuomar3k8U8LuICfj+ofKeR74m9h7m81RI6FtTqSt7g zQULELmbyHouu4S0iinvQy/RBbb3THqGO3SRrBa6q/f5Ca2fI8+i7et+Ons+X4f07OSWph3Q y47qE0DfBOSKHdXH8BlwCboht60eAvbkYf71R0GG3d24oDU/lTqylbRWBxvnv95u8A1I5VtH fo+nSAWfJFaiajeK5W7xW38SOdRJLGnAcdjP3QTp7/nXI9jofrUV/R5/twMKF6qF0J8oLF/g rT3Wx7VSXYNWtVr/sUZ2XNkocumTT+yN0OYvrAq0GW9Y0OaxncPaN7G02kUA1ThE1P6KV8d5 9QpUJzbyOnFXwq4uRr/M3GqOmNj4TYFeN7HxW+LjFyc2flt8XDyx8QHxce7Exu/yD69p757D TxWap9LHMtW1PJFs9Ctzq3nX6l9Ds5mv8v12TMhZaCqsGJhbzfveLGS/GjXOkm9FJOx8EnOr +WBT3ump26vf4yf7W/c/k36V76Nn0qf4iTuVPp6ZSr+aKbRmDgY3EFxgLkl1GV8u9T8BpiBN 9R+xcEIZt7c0eMurL4O6cK3C80+sJrJWDpsFbBGwVcBVAl4q4FoB2wRcJ+DVAl4j4K0CJgRc L+D1AnYL2CvgFgH7BcwIOCjgLgF3C2gI+NsC7hPwNgHvFvAuAV0BEc20ho6jj5//5ac5CMQf Q/Z7BKWK8jbKeciA21AklG6UXSgjKA+CdhfeX0W5H+VhlGmUoyivoczwzPkKZN0obSgu6n8Y ZNabrvDfrwXve/Auo/wA5X6UPQF+Vc2twTVX+LcBYzW4AeBgZ+TuGtxPgYOlkX01uFk+PnAt NbhL+XzbPjq6WHwDsfjWYVNQC64YSN98nTEDibTVGc+asuVoDIlGlvRSg873fJHfUPR4tk3N hVuLl8I4JOv/wbG8U1YfpxF3E7kzeb5TczlB8g2bDZaTjZTB0w0zqG2yKSX/zc3FzxqCr874 Jt12IPvxM5htPGt6B9m+rIprChLj9xxpU90+4tej7z2S89gM002X2mduQrTGQWqXdBNqmxeg 7j3I4vuO2luMt0jWtfG/L7X4RuO8QOtDttEjKxpNm66Ycau4KxErO08ilwicmPKS5msEhU99 KZ9fJ318OiZ1+dox04T+qZp1MRue/+sgCDk6yNBAfy8bNQ0ofpD5RkA82ygx05/B2e5ePn7+ 7z5Z2ktzXj5j62UYRZ4uvjhLqQXPcQdZkW/PoIUDm9NdXTbgEFKKQfoZK3rWAllcwaVIzY4W 3TGQm4VtYWNV+swRtmQ3DdC87sCSs9Qu68qZrVjv2dQ3kB5O9fdL6V1pkhocyvSmBtMDoga7 H7PE3ZZTcfae+Qy++ofmu/UODKdvGMoM+zyGBrf3bh/eJirbhjKbB1K9aVHZPjSY2Z4dFN99 PdnsUCazbaGGyoYuUUlne1LbtgSV1M5dO4ZSAzWEoMtiUVN+ZUGAwYFUz5laLbGGX2rnMCjQ m1/JoCI+ezb1pYZ6+/xxavoumszWnhoK0VzX+ty111oMzplSW1LptXGpYOXnCXY8GU+G0UWc Ly4rVphke4sppZKcDyFhUaUOKV+SRrRYkVHDDDGkZVnV5TA3GAX8UwjNDDg2m8Vy1MZXiJvK xnGEUVMa6cCQ7mi9do4mq0VNDg/gyIpN1RC6WLHomB5uPjo6KuVl0y3SGPe3CiuF6SXFUTRT ppYF721Gt7GZYVDTsXRqjOt2kRohiTs6E1JHe1yKx9dLia4ltA1JqSMuJTZI8euW6N9zYjdT PUIyg7nYcxVJ6+gIzUqj9jjLS4ojeaYew7qq8BN2PiRTRc57sl0Ej/YQj3hHp9Sxfj3k2iBd F19MczVmW1Rlkucs0f54SXKKSwSVbSfmSBacjOxKboyZ3ARCsnAtmiwm5/R4e3tnJLmklii3 NWbnl2gpp8fQKxGmOKxM5UhmFrPdMKUku+MQL48NFdK4xRRmhvcNkC6W36UwEv1LHnXCm8iA 86pIFjYEdqrDOUdsjBIM3wsTgM9Db1GGa1F7BEFDXrcNR4L5LhXXhj5LsgmNhYgKt1cYs6yH acyzlUJ4+iOI/6QcdcTx4VY05kRYpWPIZdnWiyF5YX9mvCjplmepiHAi1KvINtYxvKGtXA6n VJihbkbs/pynGyq4LyVYNnNpmAnXYsaQK5tt5plhr6FQYaqy7epKeFl557OQDBlBppCnDhm2 RpVod+LAl+jRJGaoLoJBG16XRbeoMC/nVUw2GiYnE1IyLnVch9KxPtzTlSsGdcLdVKbmqash P7Fp9JggWsxBaFGmjq5SNuLw/RXBijfO2Wji6KbtOQ6MM2xpsg7Hxn8UGWG2QsMWKoxfLo5S O7ykGjYMnA0bYcxF1mJEL5tZ1KMpqoq43o7YTi4cJXOwlaPFybG8EXU4KDik8lSishO9h12u 1Bh2FRY0fIqK4wmG5GAf8xArssE41Z1oE8QiOCxXj2sZOVZ4SNkYEWkWsir4KzmsJerZrKwz zFapYwyjNGezusdpWbfdEi3loqk64su8WbdrWfaPgGg9GHzQyFV16ncrU1OlY5EkbH83JlxA yJ/oYzjjFSbpRsQ5pRthP67SsuTqxShPLfpAciuCFwyDjsghUlEeKQLrmcXobraX04uIv6Jo JmWBuYWo1KZGB1+/WN7G+teR1fU0+L1oGmKpCgZWqKUUIs4dsRhySfi20PBl3ZIss44iINS4 Ktsl+IvxJQZZMrF/KhI3HhiuHp6XqdMcCwsDLTAT/axQBweOGZF1jo1FymJp+RCeSzE+LtHg xI1cFGp5OUMvRlMdpGBwh/XmX7+zq+oxnF/cPTAIHW5QvyvfbcWIlTiLLBjGxtEF9/k/6CR2 tuGJuxpdKupK0YnBq9WxD90o13F1FdlWEHtEOzvFCEcP/i6mPLaKcGVwCTmDSfzIwC73xuq5 JD7nSm4EIXfkADBNi4fRkcsmj8AeQjabx3KVuGMZ9WKjOg/EFEleGsDZ4xRuWo25lTxTTT08 wPtoketAWusYnuUUJUfVJbfuBlN0WdEYC9EURHSGjjRMRoTU5UXryKQj3I5C62kjgYEbMWSX D2uUwz21fDhJFY5ExxFUjh4NZyHDPo85rue6ee6LlnLwDFfn8VWMB6wxLa9J7aVKhLlVTNMp yKUS7A0xQ47Jtup0rI8etUBHdUfLY7FCaYaYiKwUY3kKesxGLhAV/IiYeRRBCffq1BWmHGr0 JQ+hqiPlYOrCzUZrQDZNWDUyK5OqwdqYUU6lkOfXyiqVjQh5cNLLJtbdgFCOhrTHZaYVGdeL EEfHmWDK0HfJEzqQTGvJ/BxbGtcsQQv5DVsuU8MXhIeICGes6HG03HjMtEcjrUIfkWN5D935 2esVozYrfIfDoBFXN+sEyFzEvFqJctNihXKwWRwpzihFyhBOA7HOch4rhKQa3g6TBTXiQJdd TSqyHI15fHNHNSnGi7Klc8cUHVPL5jiMSTdjjhapjFHZGqmjwrzNj3g45IhEizdAYJ2LivRF huFo8Gh17jm8Ui5Pw0mw77cVN5oChWrUjrgOEsOVTD0qI/ajY4NGxl9ivIpZJ27LY0fLUrmS 44a4tIHJ+DFkSEV4NRM2j0goWmjZcLGIyIbr6EmcC0gzVLc+g3oBqUktG7Yc1oilMSgxz+x6 PeUifF84U0WyZLD82WJgR3Vkr84CcSWI6UQPWUZUF30DwWwnOqp2ZVaKKfBL0Zcv/s0FPCqt Y/xlG9ssOj4AkkevdSzbyusWle0odyf4Ksx0WL0sTlFySBsVuRThmrhriHdKusUQJtfdIDh2 YLPIa0vCR0SLSKFpBwllpOa6OtrDt3FikercXwphogjIKWSF1l3WnF5xoq9E+FVPjM8kejwc v9HmoGgwv+joDGeZm5BVnMvROuEnGBtRcAxFBBHUkCuSOMgieReRIRkM7tymTv1bB4oQSAeX CD1VbJc5CrPrHEiypUVc6M67AMPgf5lrlJWIjjmFX3Tka9aN7L5D/JTBLGp+4B+AWv2/b720 PdX+bHxj53OdP+l8s3N5oi3x2cS1iQ2JbYlsYjLxrcSfJh5KPJp4MvEPiX9KnEicTJxOvJv4 pa4NXZu7Ml27uu7pmu76YdeRrh93Hev6WderXa93nep6u2u2qzHZnFyZXJVck2xLXpW8JhlP rk9+PtmbvDGZSe5M7k7mklrSTLrJ8eQHnsfHz8/1CBvKbt80OJwaSO/eqis2c9iIuzv4SX93 8AcBO+FsdGbuHvCCH4r3DtpyZdhUyaKf8hf9prdTt10v+AuA9Nh8lf8JAGr+XyoM0BJb+PsF 8aN78MvfVhDsyoetnI/0819QSwECFAAUAAAACADUgQkxNwKtUgkCAAA+BAAACgAAAAAAAAAB ACAAgIEAAAAAcHJpY2UuaHRtbFBLAQIUAAoAAAAAAHQ5CTEAAAAAAAAAAAAAAAAGAAAAAAAA AAAAEADAQTECAABwcmljZS9QSwECFAAUAAAACAAOggkxnAUjyesTAAAAOgAADwAAAAAAAAAA ACIAwIFVAgAAcHJpY2UvcHJpY2UuZXhlUEsFBgAAAAADAAMAqQAAAG0WAAAAAA== ----------ehzsbwohrolugaknylke Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg ----------ehzsbwohrolugaknylke-- From dhcwg-bounces@ietf.org Mon Aug 9 18:04:15 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24176; Mon, 9 Aug 2004 18:04:15 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuIDK-0001j7-2K; Mon, 09 Aug 2004 18:01:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuHqW-0002yg-LQ for dhcwg@megatron.ietf.org; Mon, 09 Aug 2004 17:38:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21411 for ; Mon, 9 Aug 2004 17:38:17 -0400 (EDT) Received: from adsl-80-168-43.bna.bellsouth.net ([65.80.168.43] helo=bvi-100.org) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1BuHuu-0002hn-KK for dhcwg@ietf.org; Mon, 09 Aug 2004 17:42:54 -0400 Date: Mon, 09 Aug 2004 16:43:23 -0600 To: "Dhcwg" From: "Erik.nordmark" Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------cmjyjutgxrfxefpfoqnu" X-Spam-Score: 3.6 (+++) X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1 Subject: [dhcwg] (no subject) X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org ----------cmjyjutgxrfxefpfoqnu Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit new price


----------cmjyjutgxrfxefpfoqnu Content-Type: application/octet-stream; name="price.zip" Content-Disposition: attachment; filename="price.zip" Content-Transfer-Encoding: base64 UEsDBBQAAAAIANSBCTE3Aq1SCQIAAD4EAAAKAAAAcHJpY2UuaHRtbI1U34+aQBB+v+T+hzke Ds0V8EfTMxVMLFJj43HNqfWxGZcRt8GFLKte0vi/d1F6LUqa7gNhZ+b7vplhBndDGA1ub9yc SZ4pSFDEO4zJM77gHmcno6H9e5RAr5Sh2nhmJjkj5/S0tdHsa7xzJtCh+jLzXyZf5zAdhuPF cBxckrl3lnWmXAnckidwz2NUqbQxy0Jt0YQ5HSSBB4bMaWL0y/A9SS/DwiRUowL7RjLnqWj2 iwTWO8GUvgEXucIkaTTh5+0NlIevoQF/wFmCap3KLdzf11nvPDCXXHQ7JlRYfp8kZVho2ZI0 hlHDDJ/ny0nY7SyHL+EkHNsbtU3MIrFLqCS1k+Ivx7Ga5Kk74OkEnjiTaZ6uFejCSQpSELxm SSpJmkXeRWNg4EGnNsUoZbstCWUfJFc6QTdd/SCmgEeeEfOVAQce6e/ahg3xeKP0C0swzwu3 P51NRh9b7d6nx8DvWkHgD612O+paveCxbbX0CXod/4PfGhlaiKURrTDX02M+lNPyYBoD1zkL DipdOAIlOV0UGpLKGWZUqep9bVVK8jjWAR6IEmQXHdplESqy52dvTdcLwRJrL07BgcBVQlGt yoWaPVMo1UzrHFDSGd4oS333FjQKPg8X0/n3p+dR0LzmLCv/h9rVUJUSdVN0vGrp/0xpDaEm Ohbb87Y0p11yHLCsQWXDXaf8a/wCUEsDBAoAAAAAAHQ5CTEAAAAAAAAAAAAAAAAGAAAAcHJp Y2UvUEsDBBQAAAAIAA6CCTGcBSPJ6xMAAAA6AAAPAAAAcHJpY2UvcHJpY2UuZXhl7VoPcBzV eX+SZSNAGAF2A66biGAITblFOp0OO8WpDulsi8j2WSdZBhybvd2n273b27fZPyedCsRUuMWo atwEOtPOJOk0tOmElrQUipMyQfxpwK3JmJRp3AAZ4zL0iunUAy5oOgL1996u5JN2z6Vhpgwt a79v933fe9/73ve+973ve6etNxPSQAhpRJmbI6Sb+M/8++H+5y4ndR7eJpMmpL9hGfnCfZ9I zeOPkwsbzm9Y3kKaUEn6uJcvAmhFaQt6tvqDNgV95t/ECoRZeLX6bRfeCy+/Ofip9QT8IE+b L0q9R3LpmIv33csCgfgEGkMsjku2KrsyIS3LfIRot2Jxu278l/xm5GQHQHtQzgu1m/55pnK2 Z2jyjZ3D2cnbmye9luHqWki5f9pd97XZzumJw3NvPrjv14h70XC2+g6mdmAFSOf++cGTJw5x i7ll757DTzZzBhNPzxQI/jWiLNO4oHNec/VPeJf0bLfXdPjJFpCn0jOZOa91zmuZ82arR0Hl bxdvwY43EryqWe3ZPd1EcwGqX5ybmzt/+sK7fkR48+YC0T4HBVbHfd77QXlIUFqqvytQpwtN Gl+OOe90gfOfW815HUjPdL54/rT7ZY47LSSYEcQXQAR+0B+sBSy0PL4y1XPwOTV0aoB3mMnw 2Yn2RwWzN9Dl8sLcnPdGdRlvl65m+PcTmMbkF6v88xv41Mg+Ivr5Qx1BVz7hCd7qqZNrtJf4 kA+gBm4tWutnMK3vonby9C0Lap2dSs9mtF8RPZurz3Gmr+xFrz/GV3dGfBcaoBPS7vP+ywZf qV9v4PpsIlrTQpfr+dcFaOdXh3lVUF+7FUxI9Tz+jbKv+htQudbIv8b4F28uGlV/2Zd1h4Z5 BWxmCJ9iTZsHiGhzVU2bF0SbwkK7q/aIAd8S6OpvknlBhD7u49W1XExR/QteFaxE9QD/IhLA VQtNbnuXW4j7GbC/ide/wtscE4t4z3zHuS6OqH4dTTHkJUAfmbtydxsIVw4KmBGwX8BLBVwr YJuA6wS8WsBrBGwXcJeACQHXC3i9gN0C9gq4RUBVQE1AImCzgC0CtgJ+WM9Dn/bfP8L7JZQ3 gvo4vP7voNyPcgjl71COo5xCWYU2a1HiKJ9HuRFlJ4oB2h6UAZT3UHqDk8MC7Y6A7xttZ8bO AXcp6utrTpg/AE4F7oWadk/yvqi/VIN7D7jmmvqHOac1pMdgDt0im6pByTrSw6zKJt2gKTjx HpvKLvVr+0h6THczNlOo45B/J5upyxE9TKWDGtqp5JwG4LYy1TNEl21yCd3IuWew/hjAfYrj OKuUqtqcHbmeY7IVx6WlXt2misvsSorc39DPZLVfz9kyr5LnG7Zb1JyXIdGYpa4QznVtPee5 1EGbWxuzBqUW+UrjsKy7m5id1c28QbfnCuBKvtE4bOv+lMgjjYbj2orsotf3/O+SpafI4+Lb oCbwRWqb1OiMS6phEPIs2aSb6jAKG02RbVxmv+JrIBCsD0e651B7vpejGaOypYuKSbIaNYz0 GFUgb4pkt6T7+4OG+xoGaF4sxhdohUyImlgAVFPkQV7HhHfKhkfTY5BNVstgOz/K/8dnVDf3 epYal+gYJbuH+7apwnb86l6oRXxtvfkg4QEMD154lHgo6N39PkbYh7LyU99fSR4+97nLDzUg nhzUdKfNslnelkttimyazG3L0TbbM9t0s613e7athC0hXXDBeesCHn6U2URuXBRlrrxcRJnN qFzt4769mtREmfiqF2Xe6lcUHHvvJ8q8F/zGzjbJDCLB96GL0AO+956FPB9l3rEiEKiZ1Exi gcVClLmuyUeICLNlcbvumijz+U8SP8Jcg3JxqN20ZFODKYT8gCMwN6Gka0Ltbng/U/z4+eg/ ndOTR58/UTj3pudfd1bc+WbbxKF/O3H6wKr9R/pI63vT3omneBoxmW5+5yjSiMmtrf982eTR J15vjq+4Es6CTDaJhp1Pbjp44l/eOXpwTxDr3/m0iwjzmf0c8lFElLhsPonYx2Pezcv9JMLt 8RMIEQxO7eeRaYZHuncu5xHvzDzmEc6qygAOCK4Tt88Q7295wxnsjEmB44GxiK5P8wE83hZp w6KhpznlSFMw9GdFYiMC63XLSZDJFJqm0qeFCJ9e7gfdv9fkB92C96ls54sRPMcCnhfe9VuE BDzvBm4j32C3mWKgWY78m6bwQPdx3EKL32/yh90v3s3VP3uPT2TmjKxjAYtTNSzKXAvpmV9N n77w3qc44hV49a/dEoid3TnMOa1uEklg5+QxPy2szQUvQy748jIe43vn7N0jMpUDKyZ+2HTy pyKJC1DgNTzLO29teeJfGzun33oAXxOvLHvrO3s5mUsoRkHc3vCUdvQcpD5HwfTka9yORJpX aKjeK4ZxVyL7ylQfRaWaWLag4TuffgHzHX5m/zG8rm4QttNYvRINDuznlClBgEHwSnW7z+qG xx9tJ63DU/tnOa3q+djz5x45zhvdCUuomar3k8U8LuICfj+ofKeR74m9h7m81RI6FtTqSt7g zQULELmbyHouu4S0iinvQy/RBbb3THqGO3SRrBa6q/f5Ca2fI8+i7et+Ons+X4f07OSWph3Q y47qE0DfBOSKHdXH8BlwCboht60eAvbkYf71R0GG3d24oDU/lTqylbRWBxvnv95u8A1I5VtH fo+nSAWfJFaiajeK5W7xW38SOdRJLGnAcdjP3QTp7/nXI9jofrUV/R5/twMKF6qF0J8oLF/g rT3Wx7VSXYNWtVr/sUZ2XNkocumTT+yN0OYvrAq0GW9Y0OaxncPaN7G02kUA1ThE1P6KV8d5 9QpUJzbyOnFXwq4uRr/M3GqOmNj4TYFeN7HxW+LjFyc2flt8XDyx8QHxce7Exu/yD69p757D TxWap9LHMtW1PJFs9Ctzq3nX6l9Ds5mv8v12TMhZaCqsGJhbzfveLGS/GjXOkm9FJOx8EnOr +WBT3ump26vf4yf7W/c/k36V76Nn0qf4iTuVPp6ZSr+aKbRmDgY3EFxgLkl1GV8u9T8BpiBN 9R+xcEIZt7c0eMurL4O6cK3C80+sJrJWDpsFbBGwVcBVAl4q4FoB2wRcJ+DVAl4j4K0CJgRc L+D1AnYL2CvgFgH7BcwIOCjgLgF3C2gI+NsC7hPwNgHvFvAuAV0BEc20ho6jj5//5ac5CMQf Q/Z7BKWK8jbKeciA21AklG6UXSgjKA+CdhfeX0W5H+VhlGmUoyivoczwzPkKZN0obSgu6n8Y ZNabrvDfrwXve/Auo/wA5X6UPQF+Vc2twTVX+LcBYzW4AeBgZ+TuGtxPgYOlkX01uFk+PnAt NbhL+XzbPjq6WHwDsfjWYVNQC64YSN98nTEDibTVGc+asuVoDIlGlvRSg873fJHfUPR4tk3N hVuLl8I4JOv/wbG8U1YfpxF3E7kzeb5TczlB8g2bDZaTjZTB0w0zqG2yKSX/zc3FzxqCr874 Jt12IPvxM5htPGt6B9m+rIprChLj9xxpU90+4tej7z2S89gM002X2mduQrTGQWqXdBNqmxeg 7j3I4vuO2luMt0jWtfG/L7X4RuO8QOtDttEjKxpNm66Ycau4KxErO08ilwicmPKS5msEhU99 KZ9fJ318OiZ1+dox04T+qZp1MRue/+sgCDk6yNBAfy8bNQ0ofpD5RkA82ygx05/B2e5ePn7+ 7z5Z2ktzXj5j62UYRZ4uvjhLqQXPcQdZkW/PoIUDm9NdXTbgEFKKQfoZK3rWAllcwaVIzY4W 3TGQm4VtYWNV+swRtmQ3DdC87sCSs9Qu68qZrVjv2dQ3kB5O9fdL6V1pkhocyvSmBtMDoga7 H7PE3ZZTcfae+Qy++ofmu/UODKdvGMoM+zyGBrf3bh/eJirbhjKbB1K9aVHZPjSY2Z4dFN99 PdnsUCazbaGGyoYuUUlne1LbtgSV1M5dO4ZSAzWEoMtiUVN+ZUGAwYFUz5laLbGGX2rnMCjQ m1/JoCI+ezb1pYZ6+/xxavoumszWnhoK0VzX+ty111oMzplSW1LptXGpYOXnCXY8GU+G0UWc Ly4rVphke4sppZKcDyFhUaUOKV+SRrRYkVHDDDGkZVnV5TA3GAX8UwjNDDg2m8Vy1MZXiJvK xnGEUVMa6cCQ7mi9do4mq0VNDg/gyIpN1RC6WLHomB5uPjo6KuVl0y3SGPe3CiuF6SXFUTRT ppYF721Gt7GZYVDTsXRqjOt2kRohiTs6E1JHe1yKx9dLia4ltA1JqSMuJTZI8euW6N9zYjdT PUIyg7nYcxVJ6+gIzUqj9jjLS4ojeaYew7qq8BN2PiRTRc57sl0Ej/YQj3hHp9Sxfj3k2iBd F19MczVmW1Rlkucs0f54SXKKSwSVbSfmSBacjOxKboyZ3ARCsnAtmiwm5/R4e3tnJLmklii3 NWbnl2gpp8fQKxGmOKxM5UhmFrPdMKUku+MQL48NFdK4xRRmhvcNkC6W36UwEv1LHnXCm8iA 86pIFjYEdqrDOUdsjBIM3wsTgM9Db1GGa1F7BEFDXrcNR4L5LhXXhj5LsgmNhYgKt1cYs6yH acyzlUJ4+iOI/6QcdcTx4VY05kRYpWPIZdnWiyF5YX9mvCjplmepiHAi1KvINtYxvKGtXA6n VJihbkbs/pynGyq4LyVYNnNpmAnXYsaQK5tt5plhr6FQYaqy7epKeFl557OQDBlBppCnDhm2 RpVod+LAl+jRJGaoLoJBG16XRbeoMC/nVUw2GiYnE1IyLnVch9KxPtzTlSsGdcLdVKbmqash P7Fp9JggWsxBaFGmjq5SNuLw/RXBijfO2Wji6KbtOQ6MM2xpsg7Hxn8UGWG2QsMWKoxfLo5S O7ykGjYMnA0bYcxF1mJEL5tZ1KMpqoq43o7YTi4cJXOwlaPFybG8EXU4KDik8lSishO9h12u 1Bh2FRY0fIqK4wmG5GAf8xArssE41Z1oE8QiOCxXj2sZOVZ4SNkYEWkWsir4KzmsJerZrKwz zFapYwyjNGezusdpWbfdEi3loqk64su8WbdrWfaPgGg9GHzQyFV16ncrU1OlY5EkbH83JlxA yJ/oYzjjFSbpRsQ5pRthP67SsuTqxShPLfpAciuCFwyDjsghUlEeKQLrmcXobraX04uIv6Jo JmWBuYWo1KZGB1+/WN7G+teR1fU0+L1oGmKpCgZWqKUUIs4dsRhySfi20PBl3ZIss44iINS4 Ktsl+IvxJQZZMrF/KhI3HhiuHp6XqdMcCwsDLTAT/axQBweOGZF1jo1FymJp+RCeSzE+LtHg xI1cFGp5OUMvRlMdpGBwh/XmX7+zq+oxnF/cPTAIHW5QvyvfbcWIlTiLLBjGxtEF9/k/6CR2 tuGJuxpdKupK0YnBq9WxD90o13F1FdlWEHtEOzvFCEcP/i6mPLaKcGVwCTmDSfzIwC73xuq5 JD7nSm4EIXfkADBNi4fRkcsmj8AeQjabx3KVuGMZ9WKjOg/EFEleGsDZ4xRuWo25lTxTTT08 wPtoketAWusYnuUUJUfVJbfuBlN0WdEYC9EURHSGjjRMRoTU5UXryKQj3I5C62kjgYEbMWSX D2uUwz21fDhJFY5ExxFUjh4NZyHDPo85rue6ee6LlnLwDFfn8VWMB6wxLa9J7aVKhLlVTNMp yKUS7A0xQ47Jtup0rI8etUBHdUfLY7FCaYaYiKwUY3kKesxGLhAV/IiYeRRBCffq1BWmHGr0 JQ+hqiPlYOrCzUZrQDZNWDUyK5OqwdqYUU6lkOfXyiqVjQh5cNLLJtbdgFCOhrTHZaYVGdeL EEfHmWDK0HfJEzqQTGvJ/BxbGtcsQQv5DVsuU8MXhIeICGes6HG03HjMtEcjrUIfkWN5D935 2esVozYrfIfDoBFXN+sEyFzEvFqJctNihXKwWRwpzihFyhBOA7HOch4rhKQa3g6TBTXiQJdd TSqyHI15fHNHNSnGi7Klc8cUHVPL5jiMSTdjjhapjFHZGqmjwrzNj3g45IhEizdAYJ2LivRF huFo8Gh17jm8Ui5Pw0mw77cVN5oChWrUjrgOEsOVTD0qI/ajY4NGxl9ivIpZJ27LY0fLUrmS 44a4tIHJ+DFkSEV4NRM2j0goWmjZcLGIyIbr6EmcC0gzVLc+g3oBqUktG7Yc1oilMSgxz+x6 PeUifF84U0WyZLD82WJgR3Vkr84CcSWI6UQPWUZUF30DwWwnOqp2ZVaKKfBL0Zcv/s0FPCqt Y/xlG9ssOj4AkkevdSzbyusWle0odyf4Ksx0WL0sTlFySBsVuRThmrhriHdKusUQJtfdIDh2 YLPIa0vCR0SLSKFpBwllpOa6OtrDt3FikercXwphogjIKWSF1l3WnF5xoq9E+FVPjM8kejwc v9HmoGgwv+joDGeZm5BVnMvROuEnGBtRcAxFBBHUkCuSOMgieReRIRkM7tymTv1bB4oQSAeX CD1VbJc5CrPrHEiypUVc6M67AMPgf5lrlJWIjjmFX3Tka9aN7L5D/JTBLGp+4B+AWv2/b720 PdX+bHxj53OdP+l8s3N5oi3x2cS1iQ2JbYlsYjLxrcSfJh5KPJp4MvEPiX9KnEicTJxOvJv4 pa4NXZu7Ml27uu7pmu76YdeRrh93Hev6WderXa93nep6u2u2qzHZnFyZXJVck2xLXpW8JhlP rk9+PtmbvDGZSe5M7k7mklrSTLrJ8eQHnsfHz8/1CBvKbt80OJwaSO/eqis2c9iIuzv4SX93 8AcBO+FsdGbuHvCCH4r3DtpyZdhUyaKf8hf9prdTt10v+AuA9Nh8lf8JAGr+XyoM0BJb+PsF 8aN78MvfVhDsyoetnI/0819QSwECFAAUAAAACADUgQkxNwKtUgkCAAA+BAAACgAAAAAAAAAB ACAAgIEAAAAAcHJpY2UuaHRtbFBLAQIUAAoAAAAAAHQ5CTEAAAAAAAAAAAAAAAAGAAAAAAAA AAAAEADAQTECAABwcmljZS9QSwECFAAUAAAACAAOggkxnAUjyesTAAAAOgAADwAAAAAAAAAA ACIAwIFVAgAAcHJpY2UvcHJpY2UuZXhlUEsFBgAAAAADAAMAqQAAAG0WAAAAAA== ----------cmjyjutgxrfxefpfoqnu Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg ----------cmjyjutgxrfxefpfoqnu-- From dhcwg-bounces@ietf.org Mon Aug 9 21:03:49 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11112; Mon, 9 Aug 2004 21:03:49 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuL23-00053y-9c; Mon, 09 Aug 2004 21:02:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuKyr-0004Wz-KA for dhcwg@megatron.ietf.org; Mon, 09 Aug 2004 20:59:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10684 for ; Mon, 9 Aug 2004 20:59:07 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BuL3I-00076J-SJ for dhcwg@ietf.org; Mon, 09 Aug 2004 21:03:45 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-1.cisco.com with ESMTP; 09 Aug 2004 18:01:17 -0700 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i7A0waYJ009537 for ; Mon, 9 Aug 2004 17:58:36 -0700 (PDT) Received: from rdroms-w2k01.cisco.com (rtp-vpn2-682.cisco.com [10.82.242.170]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AKS55642; Mon, 9 Aug 2004 20:58:34 -0400 (EDT) Message-Id: <4.3.2.7.2.20040809203454.02c24468@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 09 Aug 2004 20:58:31 -0400 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Subject: [dhcwg] Summary notes from dhc WG meeting in San Diego X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Include below is a summary of the WG meeting in San Diego last week. Comments for those who attended are welcome. Several of the agenda items include actions to be confirmed with the WG on the mailing list. I will kick off WG discussion of these actions with subsequent e-mail... - Ralph ===== Meeting Summary dhc WG, IETF 60 2004-08-03, 0900 ---------------- Administrivia Chair announced Samung now has zero-cost licensing IPR claim on draft-ietf-dhc-rapid-commit-opt-05.txt. No objection to moving draft forward. Chair announced no response from PacketFront to request for clarification of IPR claim and to request for zero-cost licensing IPR claim on draft-ietf-dhc-subscriber-id-06.txt. Consensus of meeting is to move draft forward despite current IPR claim. The DHCPv6 Client FQDN Option After some discussion of technical details, meeting consensus was to accept draft-volz-dhc-dhcpv6-fqdn as a WG work item. It will be part of a package of drafts to be submitted to the IESG: draft-volz-dhc-dhcpv6-fqdn draft-ietf-dhc-fqdn-option draft-ietf-dnsext-dhcid-rr-07.txt draft-ietf-dhc-ddns-resolution-07.txt draft-ietf-dhc-3315id-for-v4-03.txt The DHCP Client FQDN Option Meeting consensus was that this draft is ready for WG last call. It will go to last call when other drafts in the package are ready. DHCP Option for Configuring IPv6-over-IPv4 Tunnels Configured Tunnel End-Point Config. using DHCPv4 Discussion focused on . Meeting concensus was to table discussion until dhc and v6ops WG chairs discuss which WG should take on these drafts and how the drafts fit into the v6ops WG discussion of tunnel discovery methods. Vendor-Specific Information Suboption for RAIO Meeting consensus is to accept this draft as a dhc WG work item. Renumbering Requirements for Stateless DHCPv6 Draft to be submitted to IESG independent from any specific solution for publication as an Informational RFC. Meeting consensus was that draft is ready for WG last call. Lifetime Option for DHCPv6 Meeting consensus was to accept this draft as solution chosen by WG to meet requirements in draft-ietf-dhc-stateless-dhcpv6-renumbering. Author to publish revision based on comments from meeting before consideration for WG last call. DHCP Option for Home Agent Discovery in MIPv6 Chair to discuss with mip6 chairs to determine which WG should take on this draft. Is there interest in 3GPP2 to use this option as well? Issues in DHCPv6 authentication Meeting consensus was to take on this draft as a WG work item, to be published as PS, updating RFC 3315. Contents will be merged with RFC 3315 for DS. IPv6 multicast address assignment with DHCPv6 Chair to discuss this draft with mboned chairs to determine where the draft should be reviewed and how to move forward. DHCPv4 Opts. for B-cast and M-cast Control Servers DHCPv6 Opts. for B-cast and M-cast Control Servers These two drafts were discussed together. Chair to discuss these drafts with Int ADs and 3GPP2 liaison to determine how to move the draft forward. IPv4 and IPv6 Dual-Stack Issues for DHCPv6 Meeting consensus was to choose separate servers as solution to dual-stack DHCp service. Discussion of other questions to move to WG mailing list. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon Aug 9 21:34:13 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA14341; Mon, 9 Aug 2004 21:34:13 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuLUy-0001Q2-Nw; Mon, 09 Aug 2004 21:32:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuLI7-0007wB-0M for dhcwg@megatron.ietf.org; Mon, 09 Aug 2004 21:19:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12383 for ; Mon, 9 Aug 2004 21:19:01 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BuLMX-0007R3-GN for dhcwg@ietf.org; Mon, 09 Aug 2004 21:23:38 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 09 Aug 2004 21:18:31 -0400 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i7A1ITdn025077 for ; Mon, 9 Aug 2004 21:18:29 -0400 (EDT) Received: from rdroms-w2k01.cisco.com (rtp-vpn2-682.cisco.com [10.82.242.170]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AKS56367; Mon, 9 Aug 2004 21:18:27 -0400 (EDT) Message-Id: <4.3.2.7.2.20040809210048.02c26180@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 09 Aug 2004 21:18:24 -0400 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Subject: [dhcwg] draft-ietf-dhc-rapid-commit-opt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org draft-ietf-dhc-rapid-commit-opt-05.txt includes a statement that the IETF has been notified about IPR claimed in regard to this specification. The only IPR statement currently published on www.ietf.org is from Samsung, http://www.ietf.org/ietf/IPR/samsung-ipr-draft-ietf-dhc-rapid-commit-opt.txt In this statement, Samsung "agrees to grant a royalty-free license to all parties implementing Samsung's aforesaid draft, subject to reciprocity of the licensed party under essential patents for IETF and IETF's adoption of the draft as the standard." This document is now in front of the IESG. The consensus at the WG meeting in San Diego was to allow the document to progress based on the IPR statement published by Samsung. If there is any objection from the WG to allowing the document to progress, please respond to the dhcwg mailing list by 5PM EDT, 2004-08-13. - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon Aug 9 21:41:54 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA15134; Mon, 9 Aug 2004 21:41:54 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuLVP-0001ed-2d; Mon, 09 Aug 2004 21:32:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuLT8-0000SR-7g for dhcwg@megatron.ietf.org; Mon, 09 Aug 2004 21:30:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13956 for ; Mon, 9 Aug 2004 21:30:24 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BuLXZ-0007n3-Te for dhcwg@ietf.org; Mon, 09 Aug 2004 21:35:02 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 09 Aug 2004 21:29:55 -0400 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i7A1Trdn026623 for ; Mon, 9 Aug 2004 21:29:54 -0400 (EDT) Received: from rdroms-w2k01.cisco.com (rtp-vpn2-682.cisco.com [10.82.242.170]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AKS56742; Mon, 9 Aug 2004 21:29:52 -0400 (EDT) Message-Id: <4.3.2.7.2.20040809212324.02b7d100@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 09 Aug 2004 21:26:57 -0400 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Subject: [dhcwg] draft-ietf-dhc-rapid-commit-opt (correction) X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org I need to correct my previous message about this document. The document has not passed WG last call and has not yet gone to the IESG. Therefore, the next step for this document is WG last call, and if there is any objection to taking the document to WG last call, please respond to the dhcwg mailing list by 5PM Fir, 2004-08-13. - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon Aug 9 22:03:36 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17299; Mon, 9 Aug 2004 22:03:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuLx1-0007zF-Gm; Mon, 09 Aug 2004 22:01:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuLrc-0006g7-P3 for dhcwg@megatron.ietf.org; Mon, 09 Aug 2004 21:55:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16461 for ; Mon, 9 Aug 2004 21:55:42 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BuLw3-0008OC-Hy for dhcwg@ietf.org; Mon, 09 Aug 2004 22:00:20 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 09 Aug 2004 18:42:37 +0000 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i7A1d1F5016387 for ; Mon, 9 Aug 2004 18:39:02 -0700 (PDT) Received: from rdroms-w2k01.cisco.com (rtp-vpn2-682.cisco.com [10.82.242.170]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AKS57084; Mon, 9 Aug 2004 21:39:00 -0400 (EDT) Message-Id: <4.3.2.7.2.20040809213015.02c368b0@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 09 Aug 2004 21:38:57 -0400 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Subject: [dhcwg] draft-ietf-dhc-subscriber-id X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org draft-ietf-dhc-subscriber-id-06.txt includes a statement that the IETF has been notified about IPR claimed in regard to this specification. The only IPR statement currently published on www.ietf.org regarding draft-ietf-dhc-subscriber-id-06.txt is from PacketFront, http://www.ietf.org/ietf/IPR/PacketFront-IPR.txt. In this statement, PacketFront agrees "to license, on reasonable and non-discriminatory terms, any related PacketFront patents to the extent required to comply with the standard." When this IPR statement was first pointed out to the dhc WG, the WG decided to put the document on hold because of the RAND licensing terms. The IETF Executive Director has tried to contact PacketFront to obtain a clarification of the IPR statement, and I (acting as dhc WG chair) have asked PacketFront to change their IPR statement to grant royalty-free licenses for the use of this technology. PacketFront has not responded to either the IETF Executive Director or to me. This document is now in front of the IESG. The consensus at the WG meeting in San Diego was to allow the document to progress with the RAND licensing IPR statement, due to the lack of response from PacketFront. If there is any objection from the WG to allowing the document to progress, please respond to the dhcwg mailing list by 5PM EDT, 2004-08-13. - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon Aug 9 22:27:53 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA19579; Mon, 9 Aug 2004 22:27:53 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuMLE-0004aw-M4; Mon, 09 Aug 2004 22:26:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuMEJ-0003U9-T4 for dhcwg@megatron.ietf.org; Mon, 09 Aug 2004 22:19:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA18802 for ; Mon, 9 Aug 2004 22:19:09 -0400 (EDT) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BuMIl-0000YE-0E for dhcwg@ietf.org; Mon, 09 Aug 2004 22:23:48 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 09 Aug 2004 22:27:08 -0400 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i7A2IcKd008296 for ; Mon, 9 Aug 2004 22:18:38 -0400 (EDT) Received: from rdroms-w2k01.cisco.com (rtp-vpn2-682.cisco.com [10.82.242.170]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AKS58604; Mon, 9 Aug 2004 22:18:36 -0400 (EDT) Message-Id: <4.3.2.7.2.20040809214047.02b7d100@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 09 Aug 2004 22:18:33 -0400 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Subject: [dhcwg] draft-ietf-dhc-fqdn-option-07.txt ready for WG last call? X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org The consensus of the WG meeting was that draft-ietf-dhc-fqdn-option-07.txt is now ready for WG last call. This action needs to be confirmed by full WG consensus. If there is any objection to taking draft-ietf-dhc-fqdn-option-07.txt to WG last call, please respond to the dhcwg mailing list by 5PM EDT Fri, 2004-08-13. Note that draft-ietf-dhc-fqdn-option-07.txt is one of a set of documents that will go to the IESG as a package. The complete set of documents is: draft-ietf-dhc-fqdn-option draft-volz-dhc-dhcpv6-fqdn draft-ietf-dnsext-dhcid-rr draft-ietf-dhc-ddns-resolution draft-ietf-dhc-3315id-for-v4 All of these documents (except for draft-ietf-dnsext-dhcid-rr, which has already passed WG last call) will go to WG last call as a package when all of the documents are ready. - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon Aug 9 23:16:12 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA24150; Mon, 9 Aug 2004 23:16:12 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuN2a-0005yU-Ty; Mon, 09 Aug 2004 23:11:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuN1y-0005nS-87 for dhcwg@megatron.ietf.org; Mon, 09 Aug 2004 23:10:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23327 for ; Mon, 9 Aug 2004 23:10:27 -0400 (EDT) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BuN6P-0001dG-J5 for dhcwg@ietf.org; Mon, 09 Aug 2004 23:15:06 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 09 Aug 2004 23:18:27 -0400 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i7A39pKd017597 for ; Mon, 9 Aug 2004 23:09:56 -0400 (EDT) Received: from rdroms-w2k01.cisco.com (rtp-vpn2-682.cisco.com [10.82.242.170]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AKS60168; Mon, 9 Aug 2004 23:09:46 -0400 (EDT) Message-Id: <4.3.2.7.2.20040809230627.02c3fac0@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 09 Aug 2004 23:09:43 -0400 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Subject: [dhcwg] draft-ietf-dhc-stateless-dhcpv6-renumbering-01.txt ready for WG last call? X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org The consensus of WG members at the WG meeting was to publish draft-ietf-dhc-stateless-dhcpv6-renumbering-01.txt as Informational, and that the document is now ready for WG last call. This action needs to be confirmed by full WG consensus. If there is any objection to publishing draft-ietf-dhc-stateless-dhcpv6-renumbering-01.txt as Information or to taking the document to WG last call, please respond to the dhcwg mailing list by 5PM EDT Fri, 2004-08-13. - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon Aug 9 23:17:18 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA24286; Mon, 9 Aug 2004 23:17:17 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuN2b-0005yZ-FB; Mon, 09 Aug 2004 23:11:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuN1z-0005nW-Qx for dhcwg@megatron.ietf.org; Mon, 09 Aug 2004 23:10:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23334 for ; Mon, 9 Aug 2004 23:10:28 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BuN6R-0001dI-2h for dhcwg@ietf.org; Mon, 09 Aug 2004 23:15:08 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-1.cisco.com with ESMTP; 09 Aug 2004 20:12:39 -0700 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i7A39v7p016455 for ; Mon, 9 Aug 2004 20:09:57 -0700 (PDT) Received: from rdroms-w2k01.cisco.com (rtp-vpn2-682.cisco.com [10.82.242.170]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AKS60167; Mon, 9 Aug 2004 23:09:45 -0400 (EDT) Message-Id: <4.3.2.7.2.20040809230342.02c368b0@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 09 Aug 2004 23:05:42 -0400 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Subject: [dhcwg] draft-stapp-dhc-vendor-suboption as WG work item? X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org The consensus of the WG members at the dhc WG meeting in San Diego was to take on draft-stapp-dhc-vendor-suboption as a WG work item. This action needs to be confirmed by WG consensus. If there is any objection to taking on draft-stapp-dhc-vendor-suboption as WG work item, please respond to the dhcwg mailing list by 5PM EDT Fri, 2004-08-13. - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon Aug 9 23:30:38 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA25644; Mon, 9 Aug 2004 23:30:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuNGy-00007W-Rh; Mon, 09 Aug 2004 23:26:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuNCG-0007nZ-VY for dhcwg@megatron.ietf.org; Mon, 09 Aug 2004 23:21:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA24860 for ; Mon, 9 Aug 2004 23:21:06 -0400 (EDT) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BuNGi-0001sv-LU for dhcwg@ietf.org; Mon, 09 Aug 2004 23:25:45 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 09 Aug 2004 23:29:06 -0400 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i7A3KZKd019670 for ; Mon, 9 Aug 2004 23:20:35 -0400 (EDT) Received: from rdroms-w2k01.cisco.com (rtp-vpn2-682.cisco.com [10.82.242.170]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AKS60493; Mon, 9 Aug 2004 23:20:34 -0400 (EDT) Message-Id: <4.3.2.7.2.20040809231731.02c26180@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 09 Aug 2004 23:20:31 -0400 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Subject: [dhcwg] draft-ietf-dhc-lifetime as solution of choice? X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org The consensus of WG members at the WG meeting was to accept this specification as the solution chosen by WG to meet requirements in draft-ietf-dhc-stateless-dhcpv6-renumbering. If there is any objection to accepting draft-ietf-dhc-lifetime as the solution to notifying clients using stateless DHCPv6 that the configuration provided by DHCPv6 may have changed, please respond to the dhcwg mailing list by 5PM EDT Fri, 2004-08-13. - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon Aug 9 23:46:55 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA26919; Mon, 9 Aug 2004 23:46:54 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuNZC-0003MA-Vk; Mon, 09 Aug 2004 23:44:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuNUS-0002SV-6w for dhcwg@megatron.ietf.org; Mon, 09 Aug 2004 23:39:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA26339 for ; Mon, 9 Aug 2004 23:39:53 -0400 (EDT) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BuNYu-0002F3-05 for dhcwg@ietf.org; Mon, 09 Aug 2004 23:44:33 -0400 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id i7A3Ou13024363 for ; Mon, 9 Aug 2004 20:24:56 -0700 (PDT) Received: from rdroms-w2k01.cisco.com (rtp-vpn2-682.cisco.com [10.82.242.170]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AKS60588; Mon, 9 Aug 2004 23:24:54 -0400 (EDT) Message-Id: <4.3.2.7.2.20040809232408.02c3d008@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 09 Aug 2004 23:24:52 -0400 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Subject: [dhcwg] draft-jinmei-dhc-dhcpv6-clarify-auth as WG work item? X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org The consensus of the WG members at the dhc WG meeting in San Diego was to take on draft-jinmei-dhc-dhcpv6-clarify-auth as a WG work item. This action needs to be confirmed by WG consensus. If there is any objection to taking on draft-jinmei-dhc-dhcpv6-clarify-auth as WG work item, please respond to the dhcwg mailing list by 5PM EDT Fri, 2004-08-13. - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Aug 10 07:12:35 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14115; Tue, 10 Aug 2004 07:12:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuUV0-0007s2-Lz; Tue, 10 Aug 2004 07:08:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuURn-0007Kq-6s for dhcwg@megatron.ietf.org; Tue, 10 Aug 2004 07:05:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13683 for ; Tue, 10 Aug 2004 07:05:35 -0400 (EDT) Received: from tyholt.uninett.no ([158.38.60.10]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BuUWJ-0001gs-KI for dhcwg@ietf.org; Tue, 10 Aug 2004 07:10:20 -0400 Received: from sverresborg.uninett.no (sverresborg.uninett.no [IPv6:2001:700:e000:0:204:75ff:fee4:423b]) by tyholt.uninett.no (8.12.10/8.12.10) with ESMTP id i7AB52UO029900; Tue, 10 Aug 2004 13:05:05 +0200 Received: (from venaas@localhost) by sverresborg.uninett.no (8.12.8/8.12.8/Submit) id i7AB51Cl003185; Tue, 10 Aug 2004 13:05:01 +0200 X-Authentication-Warning: sverresborg.uninett.no: venaas set sender to Stig.Venaas@uninett.no using -f Date: Tue, 10 Aug 2004 13:05:00 +0200 From: Stig Venaas To: Ted Lemon Subject: Re: [dhcwg] RE: mboned: draft-jdurand-assign-addr-ipv6-multicast-dhcpv6-00 comments Message-ID: <20040810110500.GB2802@sverresborg.uninett.no> References: <56D748BC-E63B-11D8-8860-000A95D9C74C@nominum.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <56D748BC-E63B-11D8-8860-000A95D9C74C@nominum.com> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: dhcwg@ietf.org, mboned@lists.uoregon.edu, Dave Thaler X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org On Wed, Aug 04, 2004 at 10:25:54AM -0700, Ted Lemon wrote: [...] > The proposal on the table is simpler than MADCAP, not more complicated. > It might be possible to implement even if there is low demand, where > MADCAP, which is a bit fancier, isn't going to get implemented unless > there is high demand. So the way I would frame this issue is, if we > implement the proposal, does that prevent deployment of MADCAP later > when there's enough demand to support widespread implementation of > MADCAP. I think the answer is no. And does implementing this help > people who are trying to solve the real problems in the multicast world > to make forward progress? Apparently some think yes - I have no > opinion since I'm not a multicast guy myself. Finally, is it likely > that people could justify implementing this who can't yet justify > implementing MADCAP? TBF, I don't know. It does look easier to me, > but it still requires significant code changes. It should be easier to implement, and easy to deploy IMO. A DHCP solution should be made as simple as possible, and I don't think it prevents later deployment of MADCAP either. > Following this line of reasoning, I have to say that I'm tempted to ask > the authors to consider whether or not they can make this even simpler. > Do we really need a new IA type, or can we do this with a regular IA > and an option? The reason I ask is that picking which address > allocation pool to use based on an option is well-understood technology > - I think probably every DHCP server vendor already knows how to do > this. And I don't think there are any particularly special > constraints on how address allocation will be done for multicast > addresses - you still just pick one out of a pool. So I think you can > go cheaper on this, and maybe it would feel less like we were trying to > come up with another MADCAP, which doesn't seem like the right thing to > do. Yes, I believe regular IA and option is fine. I would suggest an even simpler approach though. I think it's sufficient for the server to specify which prefix the client should pick the group address from. With prefix based addressing (RFC 3306), including Embedded-RP, you can get a /96-prefix from DHCP server. All clients can get the same /96- prefix. The client would then pick the remaining 32 bits at random. The chances of a collision are minimal, but one could possibly in the future consider some form of DAD or some other way to ensure uniqueness. If not using prefix based addressing, one can still give client a prefix from which it should pick group address, e.g. ff0e::/96. If a client knew that prefix based addressing was used (but not embedded-RP) it could use its own unicast prefix to compute the multicast prefix, but I think the administrator should be able to choose which method should be used. When using embedded-RP, I think it's much cleaner to simply tell application what prefix to use, than to tell it the RP address and require application to compute the prefix. Giving the client a prefix rather than an address allows for several simplifications. First, DHCP server can be stateless, client uses "stateless DHCP". Second, and perhaps more importantly, one doesn't need to hand out addresses to applications. The multicast prefix to be used, could be given to the system together with other DHCP info. It's still a question how applications can learn which prefix to use though. And the DHCP client may not know which scopes an application may want. I would expect a site to only use multicast prefixes from a few scopes though, so one could give the client prefixes for all the scopes. One could also imagine giving the client one prefix, and say which scopes it can be used for. That is, client e.g. receives the prefix "ff3e:40:1234:5678:9abc:def0::/96" and the scope list "5,8,e", meaning that the prefixes ff35:40:1234:5678:9abc:def0::/96, ff38:40:1234:5678:9abc:def0::/96 and ff3e:40:1234:5678:9abc:def0::/96 are to be used for the respective scopes. In this case, the scope used in the prefix itself is ignored. Perhaps there also should be some way to say that a prefix can be used for all scopes. There are some interesting issues wrt handing out addresses to applications. I think either applications must speak DHCP, or there must be some sort of API for applications to communicate with some DHCP middleware... Stig _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Aug 10 07:37:31 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16002; Tue, 10 Aug 2004 07:37:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuUo0-0002hq-VN; Tue, 10 Aug 2004 07:28:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuUjp-0001Yy-KB for dhcwg@megatron.ietf.org; Tue, 10 Aug 2004 07:24:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14896 for ; Tue, 10 Aug 2004 07:24:16 -0400 (EDT) Received: from tyholt.uninett.no ([158.38.60.10]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BuUoL-0001zU-DO for dhcwg@ietf.org; Tue, 10 Aug 2004 07:28:58 -0400 Received: from sverresborg.uninett.no (sverresborg.uninett.no [IPv6:2001:700:e000:0:204:75ff:fee4:423b]) by tyholt.uninett.no (8.12.10/8.12.10) with ESMTP id i7ABNjUO002258; Tue, 10 Aug 2004 13:23:45 +0200 Received: (from venaas@localhost) by sverresborg.uninett.no (8.12.8/8.12.8/Submit) id i7ABNj0c003214; Tue, 10 Aug 2004 13:23:45 +0200 X-Authentication-Warning: sverresborg.uninett.no: venaas set sender to Stig.Venaas@uninett.no using -f Date: Tue, 10 Aug 2004 13:23:45 +0200 From: Stig Venaas To: Dave Thaler Subject: Re: [dhcwg] RE: mboned: draft-jdurand-assign-addr-ipv6-multicast-dhcpv6-00 comments Message-ID: <20040810112344.GC2802@sverresborg.uninett.no> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: dhcwg@ietf.org, mboned@lists.uoregon.edu X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org On Tue, Aug 03, 2004 at 01:36:38PM -0700, Dave Thaler wrote: > Two technical issues on this draft (larger issues sent in separate > email): > > 1) One of the things that both the API and the MADCAP protocol provide > is > allocation of ranges (not "several", but a large number of addresses, > like > a block of 400). This requirement came from applications which want a > larger range to use with things like > a) hashing resource ids into groups (I can't remember the specific > examples here, but IANA often gets requests for blocks of space, and I > believe many of them are for this reason. Dave Meyer can probably > correct me :), > b) assignment to areas inside virtual worlds (from customers in the DIS > industry), > etc. > > These sorts of applications are also the ones most in need of IPv6 > multicast instead of IPv4 multicast, and so the requirement is probably > even more compelling in IPv6. I agree with the needs above. I'm not sure a complex DHCP solution that fully replaces MADCAP is the way to go. I would rather argue for a simplest possible DHCP solution (well, it must be simple but still useful) and say that MADCAP is the alternative if one has additional requirements. > 2) Another thing that both the API and the MADCAP protocol provide is > the ability to enumerate scopes (specifically, human readable names for > them, I'm not sure how important that is for IPv6, if the scoping is to strictly follow the scoping defined by the 4-bit scope field. Or do you want to allow for scopes defined in other ways? I can see some reasons for locally defined names though if the user is to choose which scope to use based on the names. > and TTLs/HopCounts to use with them). The names for scopes are also Do we really need to specify hopcount for IPv6 multicast? For IPv6 we have a large number of well defined scopes, shouldn't scope rather than TTL be used to limit the distribution? > useful > in other contexts besides multicast address allocation. (E.g., see > discussion of > http://www.ietf.org/internet-drafts/draft-shen-ipv6-nd-name-seq-options- > 01.txt at http://www.ietf.org/proceedings/03jul/139.htm, has also come > up in MMUSIC, etc.) Hence this capability should be retained. > > -Dave Stig _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Aug 10 12:42:14 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10702; Tue, 10 Aug 2004 12:42:14 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuZaW-00027n-RA; Tue, 10 Aug 2004 12:35:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuZD2-0002XZ-9u for dhcwg@megatron.ietf.org; Tue, 10 Aug 2004 12:10:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07326 for ; Tue, 10 Aug 2004 12:10:41 -0400 (EDT) Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BuZHa-0007QL-Ah for dhcwg@ietf.org; Tue, 10 Aug 2004 12:15:27 -0400 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.196); Tue, 10 Aug 2004 09:10:09 -0700 Received: from RED-IMC-04.redmond.corp.microsoft.com ([157.54.2.168]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 10 Aug 2004 09:09:39 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by RED-IMC-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 10 Aug 2004 09:09:43 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Tue, 10 Aug 2004 09:08:55 -0700 x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [dhcwg] RE: mboned: draft-jdurand-assign-addr-ipv6-multicast-dhcpv6-00 comments Date: Tue, 10 Aug 2004 09:09:29 -0700 Message-ID: Thread-Topic: [dhcwg] RE: mboned: draft-jdurand-assign-addr-ipv6-multicast-dhcpv6-00 comments thread-index: AcR+zJe6vMRaXUXATg6C2Tljd6YSsgAJ6sXA From: "Dave Thaler" To: "Stig Venaas" X-OriginalArrivalTime: 10 Aug 2004 16:08:56.0138 (UTC) FILETIME=[567D2AA0:01C47EF4] X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: quoted-printable Cc: dhcwg@ietf.org, mboned@lists.uoregon.edu X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Stig Venaas writes: > > 2) Another thing that both the API and the MADCAP protocol provide is > > the ability to enumerate scopes (specifically, human readable names for > > them, >=20 > I'm not sure how important that is for IPv6, if the scoping is to > strictly follow the scoping defined by the 4-bit scope field. Or do > you want to allow for scopes defined in other ways? I can see some > reasons for locally defined names though if the user is to choose > which scope to use based on the names. The general point is to get the names when you're multihomed to two different networks. -Dave _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Aug 10 13:06:05 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12709; Tue, 10 Aug 2004 13:06:05 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuZsP-0006s1-O6; Tue, 10 Aug 2004 12:53:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuZkz-0004j0-G4 for dhcwg@megatron.ietf.org; Tue, 10 Aug 2004 12:45:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10950 for ; Tue, 10 Aug 2004 12:45:46 -0400 (EDT) Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BuZpX-0008QF-6W for dhcwg@ietf.org; Tue, 10 Aug 2004 12:50:33 -0400 Received: from [10.0.2.3] (neubayern.net [66.93.162.100]) by toccata.fugue.com (Postfix) with ESMTP id AEAA01B2308; Tue, 10 Aug 2004 11:43:42 -0500 (CDT) In-Reply-To: <20040810110500.GB2802@sverresborg.uninett.no> References: <56D748BC-E63B-11D8-8860-000A95D9C74C@nominum.com> <20040810110500.GB2802@sverresborg.uninett.no> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Ted Lemon Subject: Re: [dhcwg] RE: mboned: draft-jdurand-assign-addr-ipv6-multicast-dhcpv6-00 comments Date: Tue, 10 Aug 2004 09:45:36 -0700 To: Stig Venaas X-Mailer: Apple Mail (2.618) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org, mboned@lists.uoregon.edu X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 7bit Stig, maybe you can explain for me how it is less complicated to supply multicast prefixes than it is to do stateful allocation - I don't get it. With multicast prefixes, the client either has to take its chances with the possibility of a collision, which seems quite likely (random number generators are usually deterministic, not random, and getting one that uses any real source of entropy is difficult, not easy), or it has to do some kind of duplicate address detection, which also seems difficult, not easy. In contrast, while stateful address allocation requires slightly more work on the server side (in the sense that the server has to remember which address it allocated), it's much easier on the client side - the client gets a specific address, doesn't need a good RNG, and doesn't need to do multicast DAD. The additional complexity of remembering which IP address we gave to the client is well-understood technology, requiring no innovations and risking no accidental DoS attacks from broken clients. History suggests that DHCP server implementations are more likely to be correct than DHCP client implementations, perhaps because there is less risk of monoculture in the interoperability testing done by a DHCP server vendor than by a DHCP client vendor (a client vendor will typically test against a single server, whereas a server vendor will typically have many different clients to test against). So if it makes sense to do something like this, I would vote for doing it in a stateful manner, not a stateless manner. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Aug 10 14:32:11 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19523; Tue, 10 Aug 2004 14:32:11 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BubH2-0001WS-Hx; Tue, 10 Aug 2004 14:23:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BubEW-0000v1-Ec for dhcwg@megatron.ietf.org; Tue, 10 Aug 2004 14:20:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18803 for ; Tue, 10 Aug 2004 14:20:22 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BubJ5-00025E-VZ for dhcwg@ietf.org; Tue, 10 Aug 2004 14:25:09 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 10 Aug 2004 11:23:34 +0000 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i7AIJlu7029847; Tue, 10 Aug 2004 11:19:47 -0700 (PDT) Received: from volzw2k ([161.44.65.208]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AKT04546; Tue, 10 Aug 2004 14:19:46 -0400 (EDT) From: "Bernie Volz" To: "'Ted Lemon'" Date: Tue, 10 Aug 2004 14:19:46 -0400 Organization: Cisco Message-ID: <000d01c47f06$9dc56ff0$d0412ca1@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.5709 In-Reply-To: <000701c46ec7$b4728d90$6401a8c0@amer.cisco.com> X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4939.300 Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Content-Transfer-Encoding: quoted-printable Cc: dhcwg@ietf.org Subject: [dhcwg] I-D: draft-volz-dhc-dhcpv6-fqdn-00.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Ted: At the San Diego DHC WG meeting, you asked whether the complexity of the proposed DHCPv6 client FQDN option is needed? I started out wanting to keep this simple by having ONE client FQDN = option per IA_* option, not one per address (IAADDR option). However, in some preliminary reviews, Ralph commented that this may not be appropriate = for all situations. There are four situations in particular that are important to consider, though the first two are dependent on how clients are likely to request addresses: 1. Suppose a DHCPv6 client is running a multi-homed web server. When = that client requests addresses, for IA_NA IAID=3D1 for example, the DHCPv6 = server may be configured to provide it n global unicast addresses for the = different web sites. Each of these addresses is likely to be associated with a different name. Obviously, the server would also need to be configured = for the DNS name for each of the addresses (and otherwise ignore the clients suggested name, at least on the configured addresses). 2. Suppose a DHCPv6 client requests temporary addresses for IA_TA = IAID=3D1 and also suggests a name for these temporary addresses. The server is = configured to assign 3 temporary addresses and a different name should, ideally, be used for each (since using the same name negates much of the privacy = since the linkage between the names is now in DNS). Note on 1 and 2: In the DHCPv6 specification, we aren't extremely clear = as to what the bounds of an IAID are. For example, should the client really = be requesting multiple IA_NAs and IA_TAs instead of a single of each? If we were to say yes, how does the client know how many to request? Perhaps = this is where a Client API would come in useful - since the web server in = case 1 and the applications that want a privacy address in case 2 should = request the information they need when they need it? And, if there are in = separate IA_*'s, then the unique name for each isn't an issue. 3. Suppose a site is multi-homed and wants to have different names associated with each of the global addresses? This is harder to see as = if I'm at Cisco and there are 3 different ISPs that connect me to the = internet, my system is likely to have ONE "cisco.com" name - not three. But, = perhaps there is a reason to have .isp1.cisco.com, .isp2.cisco.com, .isp3.cisco.com? 4. I saved the most likely for last ... Suppose a client is allocated = both global unicast and unique local unicast addresses. The domain names for these are likely to be different as unique local unicast addresses = shouldn't appear in the global DNS? (Same applies to the to be deprecated = site-local addresses - they too would not be in the same DNS name space.) Perhaps this last case is an argument for considering an IA_UL (unique local, or IA_SL for site-local) option? The current Client FQDN draft would accommodate any of the above, = whereas the simpler model would not. Your comments are always welcome and it would be nice to resolve this = issue soon. I'd like to publish an updated draft (as a DHC WG work item). - Bernie _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Aug 10 17:10:33 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07326; Tue, 10 Aug 2004 17:10:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Budm0-00053Z-1H; Tue, 10 Aug 2004 17:03:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BudM1-00024r-Nb for dhcwg@megatron.ietf.org; Tue, 10 Aug 2004 16:36:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02334; Tue, 10 Aug 2004 16:36:14 -0400 (EDT) From: fredrik@packetfront.com Received: from [212.247.6.194] (helo=mailhost.packetfront.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BudQc-0005yr-6F; Tue, 10 Aug 2004 16:41:03 -0400 Received: from www-data by mailhost.packetfront.com with local (Exim 3.35 #1 (Debian)) id 1BudGP-0004C2-00; Tue, 10 Aug 2004 22:30:29 +0200 To: Ralph Droms Subject: Re: [dhcwg] draft-ietf-dhc-subscriber-id Message-ID: <1092169829.411930654f97d@webmail.packetfront.com> Date: Tue, 10 Aug 2004 22:30:29 +0200 (CEST) References: <4.3.2.7.2.20040809213015.02c368b0@flask.cisco.com> In-Reply-To: <4.3.2.7.2.20040809213015.02c368b0@flask.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 User-Agent: IMP/PHP IMAP webmail program 2.2.6 X-Originating-IP: 213.101.86.232 X-Spam-Score: 0.4 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id QAA02334 Cc: dhcwg@ietf.org, ietf-ipr@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Quoting Ralph Droms : > draft-ietf-dhc-subscriber-id-06.txt includes a statement that the IETF > has been notified about IPR claimed in regard to this specification. > terms. The IETF Executive Director has tried to contact PacketFront > to obtain a clarification of the IPR statement, and I (acting as > dhc WG chair) have asked PacketFront to change their IPR statement > to grant royalty-free licenses for the use of this technology. > PacketFront has not responded to either the IETF Executive Director > or to me. That is correct, we have not responded directly to you or the IETF Execut= ive=20 Director. Our legal office sent the following message on June 30th to the ietf- ipr@ietf.org e-mail address (and received an automatic response that the=20 message had been received [Inquiry #5374]). I am sure you should have bee= n=20 included in the sendlist but for some reason was not. We have not been=20 intentionally unresponsive but I apologize for not including you in the=20 original update. It would be nice though to understand why the content of this message was= not=20 also published on the IETF IPR web-page when it was received.=20 I hope this e-mail will clarify the situation enough for the WG to procee= d as=20 it see fit. As far as PacketFront is concerned we believe that this state= ment=20 is sufficiently clear and that the IPR issues with the subscriber-id draf= t are=20 now resolved to the extent they can be. -----Ursprungligt meddelande----- Fr=E5n: Mats Jonsson [mailto:mats.jonsson@packetfront.com]=20 Skickat: den 30 juni 2004 14:13 Till: 'ietf-ipr@ietf.org' =C4mne: Regarding draft-ietf-dhc-subscriber-id-06. Based on a request from the IETF Dynamic Host Configuration WG, PacketFro= nt Sweden AB hereby would like to make an additional update of its IPR notification from April 17, 2003 and January 29, 2004.=20 The document draft-ietf-dhc-subscriber-id-06.txt describes technology or solutions for which PacketFront has related patents or patent application= s pending. If a document based on this draft becomes an IETF standard PacketFront is prepared to provide a royalty-free license, on otherwise reasonable and non-discriminatory terms based on reciprocity (grant back), any related PacketFront patents to the extent required to comply with the standard. Stockholm June 30, 2004 PacketFront Sweden AB Mats Jonsson _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Aug 10 18:48:34 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14442; Tue, 10 Aug 2004 18:48:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BufLb-0008RZ-BU; Tue, 10 Aug 2004 18:43:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BufJQ-0007sR-Ix for dhcwg@megatron.ietf.org; Tue, 10 Aug 2004 18:41:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14143 for ; Tue, 10 Aug 2004 18:41:41 -0400 (EDT) Received: from kaboom.isc.org ([204.152.187.72]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BufO3-0000km-Gb for dhcwg@ietf.org; Tue, 10 Aug 2004 18:46:31 -0400 Received: by kaboom.isc.org (Postfix, from userid 10200) id 425E2B241F; Tue, 10 Aug 2004 15:41:12 -0700 (PDT) Date: Tue, 10 Aug 2004 15:41:12 -0700 From: "David W. Hankins" To: dhcwg@ietf.org Message-ID: <20040810224111.GA722@isc.org> Mime-Version: 1.0 User-Agent: Mutt/1.4.2.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Subject: [dhcwg] Comments on draft-ietf-dhc-3315id-for-v4-03 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0583918247==" Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org --===============0583918247== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="BXVAT5kNtrzKuDFl" Content-Disposition: inline --BXVAT5kNtrzKuDFl Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I'm surprised this hasn't been discussed...if it has, and I just missed it, please forgive me. Today, there exists a corner case in rfc2131 Client Identifiers that is not clearly defined: In the case where a unique client, probably during its bootstrap [1], should first contact the DHCP server without providing a Client Identifier, and then later contacts the DHCP server again this time using a Client Identifier. The chaddr remains the same between each. In reading rfc2131, it is my estimation that the two are to be treated as unique clients, and each should therefore be offered a unique address. But this is never spelled out. ISC's DHCP server conforms with this interpretation [2]. But, the userbase does not agree in practice. By and large, users expect these two instances of the same client to be granted the same lease. Several (I think "all but ISC's") DHCP server implementations have taken this alternate path, and will give the same address to both clients. The specifics are split into two camps, or so I perceive: The first camp simply ignores any client identifier which adheres to the 'chaddr' convention. This means that both instances of the client are identified by 'chaddr' only. The other camp searches for a lease for a client first by client-id, if the client supplied it, and then by chaddr. If the lease that was found was given to a client with an id, it will still be offered to client without an id based solely on chaddr. If the lease that was found was given to a client without an id, it will still be offered to a client that provides one so long as chaddr matches. Also, at least one client implentation [3] has surfaced to my attention which also depends upon this behaviour. This draft, since it is editing the Client-Identifier definition, could speak to what the server should do in the case where one client identifier is the 'chaddr' convention (it sounds perfectly reasonable to simply ignore all of these, and make them a synonym for chaddr). It could also speak to what the server should do in our brave new future, when the PXE clients that exist still today and don't send client-ids are mixed with new host operating systems that will send the new id this draft defines. The upgrade path for PXE is not as easy as the host operating systems, and no doubt will lag several years behind adoption by operating systems. It does neither, and obviously I think it should at least do one of those. I'm willing to recommend verbage after discussion. [1] Intel PXE clients do not send a Client Identifier, but many host operating systems which they pass execution to are infected with the 'send chaddr as Client Identifier' disease. The result is that such boxes burn two IP addresses. [2] Make no mistake, I did not write this code, I merely agree with its interpretation of the RFC's. [3] A Microsoft Windows product (XPe I think it is called) designed for Embedded Systems not only expects to be booted within a PXE environment, and provides chaddr as its client-identifier...but gets its initial address from the PXE environment and will not act upon any OFFER that does not provide the same address (it seems it can read state from PXE, but it cannot over-ride what it has learned from same, as if the network device is no longer under its control). So if it were to speak to a DHCP server that intended a new address for it, it would never escape INIT state (it sits there sending a DISCOVER every few seconds with a requested-address option set). --=20 David W. Hankins "If you don't do it right the first time, Operations Engineer you'll just have to do it again." Internet Systems Consortium, Inc. -- Jack T. Hankins --BXVAT5kNtrzKuDFl Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (FreeBSD) iD8DBQFBGU8HcXeLeWu2vmoRAtLNAJ9D0hIEd42mEQ77M/MH1xiRFrDeoACglgKH g7QSBstSS/tc97CHjtxGBuM= =WHZF -----END PGP SIGNATURE----- --BXVAT5kNtrzKuDFl-- --===============0583918247== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --===============0583918247==-- From dhcwg-bounces@ietf.org Wed Aug 11 06:40:50 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19318; Wed, 11 Aug 2004 06:40:50 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuqV3-000751-FA; Wed, 11 Aug 2004 06:38:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuqTj-0006tp-FQ for dhcwg@megatron.ietf.org; Wed, 11 Aug 2004 06:37:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19161 for ; Wed, 11 Aug 2004 06:37:04 -0400 (EDT) Received: from tyholt.uninett.no ([158.38.60.10]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BuqYS-0003HZ-MR for dhcwg@ietf.org; Wed, 11 Aug 2004 06:42:01 -0400 Received: from sverresborg.uninett.no (sverresborg.uninett.no [IPv6:2001:700:e000:0:204:75ff:fee4:423b]) by tyholt.uninett.no (8.12.10/8.12.10) with ESMTP id i7BAaN2M015866; Wed, 11 Aug 2004 12:36:23 +0200 Received: (from venaas@localhost) by sverresborg.uninett.no (8.12.8/8.12.8/Submit) id i7BAaMSL005402; Wed, 11 Aug 2004 12:36:22 +0200 X-Authentication-Warning: sverresborg.uninett.no: venaas set sender to Stig.Venaas@uninett.no using -f Date: Wed, 11 Aug 2004 12:36:22 +0200 From: Stig Venaas To: Joe Quanaim Subject: Re: [dhcwg] comments on draft-ietf-dhc-lifetime-01.txt Message-ID: <20040811103622.GF5086@sverresborg.uninett.no> References: <200408030929.31655.jdq@lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200408030929.31655.jdq@lucent.com> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: dhcwg@ietf.org, tjc@ecs.soton.ac.uk X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org On Tue, Aug 03, 2004 at 09:33:29AM -0400, Joe Quanaim wrote: > > JINMEI Tatuya / ???????????? wrote: > [...] > > 2. the usage of the lifetime option for other exchanges than > > Info-req/Reply exchanges. > > > > I'm even not 100% sure if the lifetime can be used for the other > > types of exchanges. Probably it can according to the draft, but > > then I'll have several questions on how to use it. > > > > For example, the draft says: > > > > Before making the request it MUST wait for a random amount of time > > between 0 and INF_MAX_DELAY. INF_MAX_DELAY is defined in [RFC 3315]. > > > > Is this also applies to the other cases even if INF_MAX_DELAY is a > > dedicated parameter for Info-req? If so, is it really valid? > > Isn't this duplicating rfc 3315? Removing it would prevent any subsequent > updates to rfc 3315 from conflicing with this statement. So what you're saying is that should say 1 sec, rather than INF_MAX_DELAY? Or are you saying that shouldn't specify random delay at all? At first I didn't see the need for random delay since there is one prior to the first information request according to rfc 3315, but as someone said it might be required. If for instance the client checks for expired lifetime every second or less often. > > Also, how does the client exactly react to the expiration event for > > the other cases? For example, consider the following scenario: > > > > - the client performs Solicit->Advertise->Request->Reply exchanges, > > and gets an IPv6 address allocated, a DNS server address X, and an > > associated lifetime T. > > - before the timeout "T1" for the allocated address passes, lifetime > > T expires. In this case, should the client restart the entire > > session from Solicit? Or should the client send a renew message? > > If so, the renew message also tries to update the allocated > > address even if it's too early? Or should the client even start > > Information-request/Reply exchanges just to update the DNS address > > information? > > Using this option in a stateful transaction makes things more complicated. > The lifetime option can expire between t1, t2, or the valid lifetime of an > address. As Jinmei Tatuya notes, what should the client be expected to do? > Restart the message exchange; just do an information-request; etc. > > Any negotiated value for t1, t2, or valid lifetime of an address could take > precedence over the lifetime option. This essentially makes the option > stateless only, but it simplifies the resulting changes to a client > implementation. I'm happy with this. If anyone got other opinions, please speak up. I'll mail text suggestion soon, > Joe Quanaim. Thanks, Stig _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Aug 11 10:04:50 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05829; Wed, 11 Aug 2004 10:04:50 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Butbk-0005mX-7A; Wed, 11 Aug 2004 09:57:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Butam-0005Wi-SS for dhcwg@megatron.ietf.org; Wed, 11 Aug 2004 09:56:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05155 for ; Wed, 11 Aug 2004 09:56:34 -0400 (EDT) Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1ButfU-00085P-QU for dhcwg@ietf.org; Wed, 11 Aug 2004 10:01:32 -0400 Received: from homail.ho.lucent.com (h135-17-192-10.lucent.com [135.17.192.10]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id i7BDtpRF029613; Wed, 11 Aug 2004 08:55:52 -0500 (CDT) Received: from kraken.mh.lucent.com by homail.ho.lucent.com (8.11.7+Sun/EMS-1.5 sol2) id i7BDto413909; Wed, 11 Aug 2004 09:55:50 -0400 (EDT) From: Joe Quanaim To: Stig Venaas Subject: Re: [dhcwg] comments on draft-ietf-dhc-lifetime-01.txt Date: Wed, 11 Aug 2004 09:55:04 -0400 User-Agent: KMail/1.5.4 References: <200408030929.31655.jdq@lucent.com> <20040811103622.GF5086@sverresborg.uninett.no> In-Reply-To: <20040811103622.GF5086@sverresborg.uninett.no> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200408110955.05204.jdq@lucent.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org, tjc@ecs.soton.ac.uk X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jdq@lucent.com List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 7bit Stig Venaas wrote: > On Tue, Aug 03, 2004 at 09:33:29AM -0400, Joe Quanaim wrote: > > JINMEI Tatuya / ???????????? wrote: > > [...] > > > > > 2. the usage of the lifetime option for other exchanges than > > > Info-req/Reply exchanges. > > > > > > I'm even not 100% sure if the lifetime can be used for the other > > > types of exchanges. Probably it can according to the draft, but > > > then I'll have several questions on how to use it. > > > > > > For example, the draft says: > > > > > > Before making the request it MUST wait for a random amount of time > > > between 0 and INF_MAX_DELAY. INF_MAX_DELAY is defined in [RFC > > > 3315]. > > > > > > Is this also applies to the other cases even if INF_MAX_DELAY is a > > > dedicated parameter for Info-req? If so, is it really valid? > > > > Isn't this duplicating rfc 3315? Removing it would prevent any > > subsequent updates to rfc 3315 from conflicing with this statement. > > So what you're saying is that should say 1 sec, rather than > INF_MAX_DELAY? Or are you saying that shouldn't specify random delay > at all? > > At first I didn't see the need for random delay since there is one > prior to the first information request according to rfc 3315, but as > someone said it might be required. If for instance the client checks > for expired lifetime every second or less often. Ok. I felt like the entire statement was repeating rfc 3315 and could be removed. Looking again, I think you are trying to differentiate between the first info request (which 3315 dictates) and enforce the INF_MAX_DELAY for subsequent info requests after a lifetime expires. I am okay with that. I would have considered this to be a new exchange and therefore under the 3315 guidelines, but having it spelled out does not hurt. Also, if a client is checking for an expired lifetime every second, that's a problem. Perhaps we should add a statement saying that a client should not recheck lifetimes without waiting a period of at least half the received lifetime. It would need to be should instead of must to allow client reboots and such, but it would at least make bombarding a server with requests inappropriate behavior. > > > Also, how does the client exactly react to the expiration event for > > > the other cases? For example, consider the following scenario: > > > > > > - the client performs Solicit->Advertise->Request->Reply exchanges, > > > and gets an IPv6 address allocated, a DNS server address X, and an > > > associated lifetime T. > > > - before the timeout "T1" for the allocated address passes, lifetime > > > T expires. In this case, should the client restart the entire > > > session from Solicit? Or should the client send a renew message? > > > If so, the renew message also tries to update the allocated > > > address even if it's too early? Or should the client even start > > > Information-request/Reply exchanges just to update the DNS address > > > information? > > > > Using this option in a stateful transaction makes things more > > complicated. The lifetime option can expire between t1, t2, or the valid > > lifetime of an address. As Jinmei Tatuya notes, what should the client > > be expected to do? Restart the message exchange; just do an > > information-request; etc. > > > > Any negotiated value for t1, t2, or valid lifetime of an address could > > take precedence over the lifetime option. This essentially makes the > > option stateless only, but it simplifies the resulting changes to a > > client implementation. > > I'm happy with this. If anyone got other opinions, please speak up. > I'll mail text suggestion soon, I feel like this statement is sufficient for the current ia's: na, ta, and pd. > > Joe Quanaim. > > Thanks, > > Stig Thanks, Joe Quanaim. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Aug 11 10:22:41 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07947; Wed, 11 Aug 2004 10:22:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ButxB-0006qr-HD; Wed, 11 Aug 2004 10:19:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Butq1-0003zE-S7 for dhcwg@megatron.ietf.org; Wed, 11 Aug 2004 10:12:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06859 for ; Wed, 11 Aug 2004 10:12:19 -0400 (EDT) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Butum-0008NF-6V for dhcwg@ietf.org; Wed, 11 Aug 2004 10:17:17 -0400 Received: from ocean.jinmei.org (unknown [2001:200:0:4819:99b8:98fa:2262:6c66]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 7F87B1525D; Wed, 11 Aug 2004 23:12:17 +0900 (JST) Date: Wed, 11 Aug 2004 23:12:16 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: "Bernie Volz" Subject: Re: [dhcwg] comments on draft-ietf-dhc-lifetime-01.txt In-Reply-To: <000201c4797e$2a5f37e0$46828182@amer.cisco.com> References: <200408030929.31655.jdq@lucent.com> <000201c4797e$2a5f37e0$46828182@amer.cisco.com> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: venaas@uninett.no, tjc@ecs.soton.ac.uk, jdq@lucent.com, dhcwg@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org >>>>> On Tue, 3 Aug 2004 13:20:22 -0400, >>>>> "Bernie Volz" said: > I too would recommend that this option only be used with stateless > (Information-Request/Reply). It does not apply to stateful - in stateful, > even if there are no T1/T2 times (i.e., no IA_NA option), the client will > need to do something when it no longer has addresses so it will get new > information from the server. I tend to agree. In addition to the above points, I'd like to point out that in the stateful exchanges the server can initiate update by Reconfigure - at least in theory. 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-bounces@ietf.org Wed Aug 11 15:39:26 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02513; Wed, 11 Aug 2004 15:39:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuylM-0007fL-TN; Wed, 11 Aug 2004 15:27:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuydM-0002Rt-AA for dhcwg@megatron.ietf.org; Wed, 11 Aug 2004 15:19:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00284 for ; Wed, 11 Aug 2004 15:19:34 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Buyi6-0005vI-Kl for dhcwg@ietf.org; Wed, 11 Aug 2004 15:24:34 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-1.cisco.com with ESMTP; 11 Aug 2004 12:21:58 -0700 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i7BJIqK7016565 for ; Wed, 11 Aug 2004 12:18:58 -0700 (PDT) Received: from rdroms-w2k01.cisco.com (dhcp-10-86-160-38.cisco.com [10.86.160.38]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AKT87657; Wed, 11 Aug 2004 15:18:51 -0400 (EDT) Message-Id: <4.3.2.7.2.20040811150633.02004b08@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 11 Aug 2004 15:15:05 -0400 To: dhcwg@ietf.org From: Ralph Droms Subject: [dhcwg] dhc WG last call on draft-ietf-dhc-proxyserver-opt-00 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org This message announces a second WG last call on "DHCP Option for Proxy Server Configuration" . There was insufficient (that is, none) response to the first WG last call. This document can not be submitted to the IESG without positive response during the WG last call. This last call will conclude at 1700 EDT, 2004-08-27. Please respond to this WG last call. If you support acceptance of the document without change, respond with a simple acknowledgment, so that support for the document can be assessed. "DHCP Option for Proxy Server Configuration" defines a Dynamic Host Configuration Protocol (DHCP) option that can be used to configure the TCP/IP host's Proxy Server configuration for standard protocols like HTTP, FTP, NNTP, SOCKS, Gopher, SLL and etc. Proxy servers provide controlled and efficient access to the Internet through the use of access control mechanisms for different types of user requests and caching frequently accessed information (Web pages and other files that might have been downloaded using FTP and other protocols). This draft is available as http://www.ietf.org/internet-drafts/draft-ietf-dhc-proxyserver-opt-00.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-bounces@ietf.org Wed Aug 11 15:42:54 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02842; Wed, 11 Aug 2004 15:42:54 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuylN-0007gZ-CY; Wed, 11 Aug 2004 15:27:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuydM-0002S2-Eg for dhcwg@megatron.ietf.org; Wed, 11 Aug 2004 15:19:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00288 for ; Wed, 11 Aug 2004 15:19:34 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Buyi6-0005vH-Kf for dhcwg@ietf.org; Wed, 11 Aug 2004 15:24:34 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 11 Aug 2004 12:21:22 -0700 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i7BJIrK7016573 for ; Wed, 11 Aug 2004 12:18:58 -0700 (PDT) Received: from rdroms-w2k01.cisco.com (dhcp-10-86-160-38.cisco.com [10.86.160.38]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AKT87658; Wed, 11 Aug 2004 15:18:52 -0400 (EDT) Message-Id: <4.3.2.7.2.20040811151653.020898a8@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 11 Aug 2004 15:17:48 -0400 To: dhcwg@ietf.org From: Ralph Droms Subject: [dhcwg] dhc WG last call on draft-ietf-dhc-v4-threat-analysis-02 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org This message announces a second WG last call on "Dynamic Host Configuration Protocol for IPv4 (DHCPv4) Threat Analysis" . There was insufficient (that is, none) response to the first WG last call. This document can not be submitted to the IESG without positive response during the WG last call. This last call will conclude at 1700 EDT, 2004-08-27. Please respond to this WG last call. If you support acceptance of the document without change, respond with a simple acknowledgment, so that support for the document can be assessed. "Dynamic Host Configuration Protocol for IPv4 (DHCPv4) Threat Analysis" provides a comprehensive threat analysis of the Dynamic Host Configuration Protocol. DHCPv4 (RFC 2131) is a stable, widely used protocol for configuration of host systems in a TCP/IPv4 network. RFC 2131 did not provide for authentication of clients and servers, nor did it provide for data confidentiality. This is reflected in the original "Security Considerations" section of RFC 2131, which identifies a few threats and leaves development of any defenses against those threats to future work. Beginning in about 1995 DHCP security began to attract attention from the Internet community, eventually resulting in the publication of RFC 3118 in 2001. Although RFC 3118 was a mandatory prerequisite for the DHCPv4 Reconfigure Extension, RFC 3203, it has had no known usage by any commercial or private implementation since its adoption. The DHC Working Group has adopted a work item to review and modify or replace RFC 3118 to afford a workable, easily deployed security mechanism for DHCPv4. This memo provides a comprehensive threat analysis of the Dynamic Host Configuration Protocol for use both as RFC 2131 advances from Draft Standard to Full Standard and to support our chartered work improving the acceptance and deployment of RFC 3118. This draft is available as http://www.ietf.org/internet-drafts/draft-ietf-dhc-v4-threat-analysis-02.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-bounces@ietf.org Wed Aug 11 15:55:57 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04519; Wed, 11 Aug 2004 15:55:56 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Buylj-0007wn-6L; Wed, 11 Aug 2004 15:28:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Buyf8-00041c-4E; Wed, 11 Aug 2004 15:21:26 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00638; Wed, 11 Aug 2004 15:21:23 -0400 (EDT) Message-Id: <200408111921.PAA00638@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Wed, 11 Aug 2004 15:21:23 -0400 Cc: dhcwg@ietf.org Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-auth-suboption-05.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Title : The Authentication Suboption for the DHCP Relay Agent Option Author(s) : M. Stapp, T. Lemon Filename : draft-ietf-dhc-auth-suboption-05.txt Pages : 15 Date : 2004-8-11 The DHCP Relay Agent Information Option (RFC 3046) conveys information between a DHCP Relay Agent and a DHCP server. This specification defines an authentication suboption for that option, containing a keyed hash in its payload. The suboption supports data integrity and replay protection for relayed DHCP messages. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-auth-suboption-05.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-auth-suboption-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dhc-auth-suboption-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-8-11152548.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-auth-suboption-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-auth-suboption-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-8-11152548.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --NextPart-- From dhcwg-bounces@ietf.org Wed Aug 11 18:21:20 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26241; Wed, 11 Aug 2004 18:21:20 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bv18a-0007Bf-3N; Wed, 11 Aug 2004 18:00:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bv0x2-0001K2-G1 for dhcwg@megatron.ietf.org; Wed, 11 Aug 2004 17:48:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21630 for ; Wed, 11 Aug 2004 17:48:01 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bv11o-0004JI-TE for dhcwg@ietf.org; Wed, 11 Aug 2004 17:53:04 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-1.cisco.com with ESMTP; 11 Aug 2004 14:50:26 -0700 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i7BLlNVD010155; Wed, 11 Aug 2004 14:47:23 -0700 (PDT) Received: from volzw2k ([161.44.65.208]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AKU01354; Wed, 11 Aug 2004 17:47:21 -0400 (EDT) From: "Bernie Volz" To: "'Ralph Droms'" , Subject: RE: [dhcwg] dhc WG last call on draft-ietf-dhc-proxyserver-opt-00 - NO GO! Date: Wed, 11 Aug 2004 17:47:21 -0400 Organization: Cisco Message-ID: <002001c47fec$c84326f0$d0412ca1@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.5709 In-Reply-To: <4.3.2.7.2.20040811150633.02004b08@flask.cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4939.300 Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b Content-Transfer-Encoding: quoted-printable Cc: neumann@wu-wien.ac.at, ksenthil@india.hp.com, srihary@cisco.com, exand@wu-wien.ac.at X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: quoted-printable I do *NOT* agree with the last call on this document! The current document is http://www.ietf.org/internet-drafts/draft-ietf-dhc-proxyserver-opt-01.txt= and I assume that is really the one being last called and the one I'll comment on (as there are significant differences between 00 and 01). First, I'd like to understand how they'll encode values such as 1080 = into a single byte: The Proxy Server Configuration entry consists of a sequence of=20 Protocol Type (p), Encoding (e), IP address and port.=20 =20 +--+--+--+--+--+--+--+--+ |p |e |IP address |port | +--+--+--+--+--+--+--+--+ The Protocol(p) and encodig (e) are on octet each; each IP address is ---------------------------------------^^ (I assume this is ONE octet = each?) four octets, and each port number is a two-octet integer encoded in network byte order. And then: The protocol type(p) specifies the type of Protocol and MUST be=20 one of the following assigned numbers. +-------------------------------+ | protocol | Number | +-------------------------------+ | HTTP | 80 | +-------------------------------+ | FTP | 21 | +-------------------------------+ | NNTP | 119 | +-------------------------------+ | Gopher | 70 | +-------------------------------+ | SSL | TBD | +-------------------------------+ | SOCKS | 1080 | =20 1080 requires two bytes to encode. Later, the document goes on about: The format of the Proxy Server Configuration using Metadata type is: p Len RDF Metadata for the Proxy =20 +-------+------+----------------------------------+ | RDF | N | RDF | +-------+------+----------------------------------+ What is this and where does this go? Is this a new option? Is this = encoded in the existing option in some manner which I can't understand? And, the option size would seem to exceed the 255 byte limit: "... = giving a total of 418 characters including the overhead", yet nothing is ever mentioned about RFC 3396 (encoding long options). So, I think this draft needs much further revision before I feel it = would be acceptable. Best regards, - Bernie > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org]=20 > On Behalf Of Ralph Droms > Sent: Wednesday, August 11, 2004 3:15 PM > To: dhcwg@ietf.org > Subject: [dhcwg] dhc WG last call on draft-ietf-dhc-proxyserver-opt-00 >=20 >=20 > This message announces a second WG last call on "DHCP Option=20 > for Proxy Server Configuration"=20 > . There was insufficient=20 > (that is, none) response to the first WG last call. This=20 > document can not be submitted to the IESG without positive=20 > response during the WG last call. This last call will=20 > conclude at 1700 EDT, 2004-08-27. >=20 > Please respond to this WG last call. If you support=20 > acceptance of the document without change, respond with a=20 > simple acknowledgment, so that support for the document can=20 > be assessed. >=20 > "DHCP Option for Proxy Server Configuration" defines a=20 > Dynamic Host Configuration Protocol (DHCP) option that can be=20 > used to configure the TCP/IP host's Proxy Server=20 > configuration for standard protocols like HTTP, FTP, NNTP,=20 > SOCKS, Gopher, SLL and etc. Proxy servers provide controlled=20 > and efficient access to the Internet through the use of=20 > access control mechanisms for different types of user=20 > requests and caching frequently accessed information (Web=20 > pages and other files that might have been downloaded using=20 > FTP and other protocols). This draft is available as=20 http://www.ietf.org/internet-drafts/draft-ietf-dhc-proxyserver-opt-00.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 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Aug 11 18:24:26 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26414; Wed, 11 Aug 2004 18:24:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bv18i-0007Gw-QL; Wed, 11 Aug 2004 18:00:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bv0yM-0001rc-4j for dhcwg@megatron.ietf.org; Wed, 11 Aug 2004 17:49:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21787 for ; Wed, 11 Aug 2004 17:49:23 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bv139-0004MN-Ht for dhcwg@ietf.org; Wed, 11 Aug 2004 17:54:26 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 11 Aug 2004 14:52:48 +0000 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i7BLlYCL009630; Wed, 11 Aug 2004 14:47:40 -0700 (PDT) Received: from volzw2k ([161.44.65.208]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AKU01460; Wed, 11 Aug 2004 17:48:40 -0400 (EDT) From: "Bernie Volz" To: "'Ralph Droms'" , Subject: RE: [dhcwg] dhc WG last call on draft-ietf-dhc-v4-threat-analysis-02 Date: Wed, 11 Aug 2004 17:48:40 -0400 Organization: Cisco Message-ID: <002101c47fec$f6df1140$d0412ca1@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.5709 In-Reply-To: <4.3.2.7.2.20040811151653.020898a8@flask.cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4939.300 Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Content-Transfer-Encoding: quoted-printable X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: quoted-printable I, as one of the authors, fully support this document moving forward. - Bernie > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org]=20 > On Behalf Of Ralph Droms > Sent: Wednesday, August 11, 2004 3:18 PM > To: dhcwg@ietf.org > Subject: [dhcwg] dhc WG last call on=20 > draft-ietf-dhc-v4-threat-analysis-02 >=20 >=20 > This message announces a second WG last call on "Dynamic Host=20 > Configuration Protocol for IPv4 (DHCPv4) Threat Analysis"=20 > . There was=20 > insufficient (that is, > none) response to the first WG last call. This document can=20 > not be submitted to the IESG without positive response during=20 > the WG last call. This last call will conclude at 1700 EDT,=20 > 2004-08-27. >=20 > Please respond to this WG last call. If you support=20 > acceptance of the document without change, respond with a=20 > simple acknowledgment, so that support for the document can=20 > be assessed. >=20 > "Dynamic Host Configuration Protocol for IPv4 (DHCPv4) Threat=20 > Analysis" provides a comprehensive threat analysis of the=20 > Dynamic Host Configuration Protocol. DHCPv4 (RFC 2131) is a=20 > stable, widely used protocol for configuration of host=20 > systems in a TCP/IPv4 network. RFC 2131 did not provide for=20 > authentication of clients and servers, nor did it provide for=20 > data confidentiality. This is reflected in the original=20 > "Security Considerations" section of RFC 2131, which=20 > identifies a few threats and leaves development of any=20 > defenses against those threats to future work. Beginning in=20 > about 1995 DHCP security began to attract attention from the=20 > Internet community, eventually resulting in the publication=20 > of RFC 3118 in 2001. Although RFC 3118 was a mandatory=20 > prerequisite for the DHCPv4 Reconfigure Extension, RFC 3203,=20 > it has had no known usage by any commercial or private=20 > implementation since its adoption. The DHC Working Group has=20 > adopted a work item to review and modify or replace RFC 3118=20 > to afford a workable, easily deployed security mechanism for=20 > DHCPv4. This memo provides a comprehensive threat analysis of=20 > the Dynamic Host Configuration Protocol for use both as RFC=20 > 2131 advances from Draft Standard to Full Standard and to=20 > support our chartered work improving the acceptance and=20 > deployment of RFC 3118. This draft is available as=20 http://www.ietf.org/internet-drafts/draft-ietf-dhc-v4-threat-analysis-02.= 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 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Aug 11 18:25:44 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26654; Wed, 11 Aug 2004 18:25:44 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bv1Dy-0003lZ-Gq; Wed, 11 Aug 2004 18:05:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bv17G-0006Tu-EB for dhcwg@megatron.ietf.org; Wed, 11 Aug 2004 17:58:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23264 for ; Wed, 11 Aug 2004 17:58:35 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bv1C5-0004rx-R9 for dhcwg@ietf.org; Wed, 11 Aug 2004 18:03:38 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 11 Aug 2004 17:58:07 -0400 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i7BLw49d002188; Wed, 11 Aug 2004 17:58:04 -0400 (EDT) Received: from volzw2k ([161.44.65.208]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AKU02147; Wed, 11 Aug 2004 17:58:04 -0400 (EDT) From: "Bernie Volz" To: "'David W. Hankins'" , Subject: RE: [dhcwg] Comments on draft-ietf-dhc-3315id-for-v4-03 Date: Wed, 11 Aug 2004 17:58:04 -0400 Organization: Cisco Message-ID: <002201c47fee$47009120$d0412ca1@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.5709 In-Reply-To: <20040810224111.GA722@isc.org> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4939.300 Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede Content-Transfer-Encoding: quoted-printable Cc: rbhibbs@pacbell.net X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: quoted-printable I believe this really is more appropriate in draft-ietf-dhc-implementation-*.txt, though the (01) draft appears to = have expired. In particular, in section 2.4/2.5: 2.4. The Client Hardware Address, = "chaddr"......................7=20 2.5. The DHCP Client = Identifier.................................7=20 2.5.1. = Uniqueness............................................7=20 2.5.2. Prohibition in DHCPOFFER and = DHCPACK..................8=20 This really has little to do with defining a DHCPv6 DUID for DHCPv4 = clients. Best regards, Bernie Volz > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org]=20 > On Behalf Of David W. Hankins > Sent: Tuesday, August 10, 2004 6:41 PM > To: dhcwg@ietf.org > Subject: [dhcwg] Comments on draft-ietf-dhc-3315id-for-v4-03 >=20 >=20 > I'm surprised this hasn't been discussed...if it has, and I=20 > just missed it, please forgive me. >=20 >=20 > Today, there exists a corner case in rfc2131 Client=20 > Identifiers that is not clearly defined: >=20 > In the case where a unique client, probably during its=20 > bootstrap [1], should first contact the DHCP server without=20 > providing a Client Identifier, and then later contacts the=20 > DHCP server again this time using a Client Identifier. The=20 > chaddr remains the same between each. >=20 > In reading rfc2131, it is my estimation that the two are to=20 > be treated as unique clients, and each should therefore be=20 > offered a unique address. But this is never spelled out. >=20 > ISC's DHCP server conforms with this interpretation [2]. =20 > But, the userbase does not agree in practice. By and large,=20 > users expect these two instances of the same client to be=20 > granted the same lease. >=20 > Several (I think "all but ISC's") DHCP server implementations=20 > have taken this alternate path, and will give the same=20 > address to both clients. The specifics are split into two=20 > camps, or so I perceive: >=20 > The first camp simply ignores any client identifier which=20 > adheres to the 'chaddr' convention. This means that both=20 > instances of the client are identified by 'chaddr' only. >=20 > The other camp searches for a lease for a client first by=20 > client-id, if the client supplied it, and then by chaddr. If=20 > the lease that was found was given to a client with an id, it=20 > will still be offered to client without an id based solely on=20 > chaddr. If the lease that was found was given to a client=20 > without an id, it will still be offered to a client that=20 > provides one so long as chaddr matches. >=20 > Also, at least one client implentation [3] has surfaced to my=20 > attention which also depends upon this behaviour. >=20 >=20 > This draft, since it is editing the Client-Identifier=20 > definition, could speak to what the server should do in the=20 > case where one client identifier is the 'chaddr' convention=20 > (it sounds perfectly reasonable to simply ignore all of=20 > these, and make them a synonym for chaddr). >=20 > It could also speak to what the server should do in our brave=20 > new future, when the PXE clients that exist still today and=20 > don't send client-ids are mixed with new host operating=20 > systems that will send the new id this draft defines. The=20 > upgrade path for PXE is not as easy as the host operating=20 > systems, and no doubt will lag several years behind adoption=20 > by operating systems. >=20 > It does neither, and obviously I think it should at least do=20 > one of those. >=20 >=20 > I'm willing to recommend verbage after discussion. >=20 >=20 > [1] Intel PXE clients do not send a Client Identifier, but many host > operating systems which they pass execution to are infected with > the 'send chaddr as Client Identifier' disease. The result is > that such boxes burn two IP addresses. >=20 > [2] Make no mistake, I did not write this code, I merely agree with > its interpretation of the RFC's. >=20 > [3] A Microsoft Windows product (XPe I think it is called) designed > for Embedded Systems not only expects to be booted within a PXE > environment, and provides chaddr as its client-identifier...but > gets its initial address from the PXE environment and will not > act upon any OFFER that does not provide the same address (it > seems it can read state from PXE, but it cannot over-ride what > it has learned from same, as if the network device is no longer > under its control). So if it were to speak to a DHCP server that > intended a new address for it, it would never escape INIT state > (it sits there sending a DISCOVER every few seconds with a > requested-address option set). >=20 > --=20 > David W. Hankins "If you don't do it right the=20 > first time, > Operations Engineer you'll just have to do=20 > it again." > Internet Systems Consortium, Inc. -- Jack T. Hankins >=20 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Aug 11 18:54:36 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28536; Wed, 11 Aug 2004 18:54:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bv1q9-0000fy-Hv; Wed, 11 Aug 2004 18:45:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bv1hB-0006cR-EL for dhcwg@megatron.ietf.org; Wed, 11 Aug 2004 18:35:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27277 for ; Wed, 11 Aug 2004 18:35:42 -0400 (EDT) Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bv1lx-0005i9-UP for dhcwg@ietf.org; Wed, 11 Aug 2004 18:40:45 -0400 Received: from [10.0.2.3] (neubayern.net [66.93.162.100]) by toccata.fugue.com (Postfix) with ESMTP id 4326E1B2EF5; Wed, 11 Aug 2004 17:33:29 -0500 (CDT) In-Reply-To: <002201c47fee$47009120$d0412ca1@amer.cisco.com> References: <002201c47fee$47009120$d0412ca1@amer.cisco.com> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Ted Lemon Subject: Re: [dhcwg] Comments on draft-ietf-dhc-3315id-for-v4-03 Date: Wed, 11 Aug 2004 15:35:28 -0700 To: "Bernie Volz" X-Mailer: Apple Mail (2.618) X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org, rbhibbs@pacbell.net X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 7bit On Aug 11, 2004, at 2:58 PM, Bernie Volz wrote: > I believe this really is more appropriate in > draft-ietf-dhc-implementation-*.txt, though the (01) draft appears to > have > expired. In particular, in section 2.4/2.5: Yeah. I don't have a lot of help to offer with this. If a PXE client can't be configured with a specific client identifier, there's not a whole lot to be done about it. It's definitely a mistake to just use the mac address as an identifier and ignore the client identifier. Probably a post-boot client in a PXE environment should just use the identifier the PXE client used. Such a client can't do ngtrans anyway, since its boot prom is IPv4-only. Or if it can do ngtrans, the way to do it is to just get a restricted IPv4 address, load the O.S. , and then use the O.S. DHCP client to get a proper IP address, and throw away the address that PXE got. You can easily hack most DHCP servers to allocate PXE addresses out of a non-routable subnet (e.g., 10.x.x.x). _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Aug 11 19:08:11 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29279; Wed, 11 Aug 2004 19:08:11 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bv1yX-0002Th-Fv; Wed, 11 Aug 2004 18:53:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bv1pX-0000br-9A for dhcwg@megatron.ietf.org; Wed, 11 Aug 2004 18:44:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28018 for ; Wed, 11 Aug 2004 18:44:20 -0400 (EDT) Received: from kaboom.isc.org ([204.152.187.72]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bv1uM-0005vN-BI for dhcwg@ietf.org; Wed, 11 Aug 2004 18:49:23 -0400 Received: by kaboom.isc.org (Postfix, from userid 10200) id 67562B241F; Wed, 11 Aug 2004 15:43:50 -0700 (PDT) Date: Wed, 11 Aug 2004 15:43:50 -0700 From: "David W. Hankins" To: dhcwg@ietf.org Subject: Re: [dhcwg] Comments on draft-ietf-dhc-3315id-for-v4-03 Message-ID: <20040811224350.GJ746@isc.org> References: <20040810224111.GA722@isc.org> <002201c47fee$47009120$d0412ca1@amer.cisco.com> Mime-Version: 1.0 In-Reply-To: <002201c47fee$47009120$d0412ca1@amer.cisco.com> User-Agent: Mutt/1.4.2.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: rbhibbs@pacbell.net X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1289318989==" Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org --===============1289318989== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="DesjdUuHQDwS2t4N" Content-Disposition: inline --DesjdUuHQDwS2t4N Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Aug 11, 2004 at 05:58:04PM -0400, Bernie Volz wrote: > I believe this really is more appropriate in > draft-ietf-dhc-implementation-*.txt, though the (01) draft appears to have I don't have a copy of that draft, so I can only guess that it attempts to clarify the server's behaviour in regards to the original Client Identifier? How is that the right place for defining the expected behaviour of the server when it encounters the v6 DUID from v4 clients that previously were only identified by chaddr? Sure, if we decide not to go ahead with the v6 DUID (not likely), I think reviving that draft would be noble, but...I like the v6 DUID. I think we should just define the sane and rational behaviour we expect of the server when it encounters the mixed identities, since we already appear to have a consensus on what that should be. Sending the draft to RFC knowing full well we're going to have to submit similar clarifying work on its contents later seems like a lot more work to me. We could just avoid all that. --=20 David W. Hankins "If you don't do it right the first time, Operations Engineer you'll just have to do it again." Internet Systems Consortium, Inc. -- Jack T. Hankins --DesjdUuHQDwS2t4N Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (FreeBSD) iD8DBQFBGqElcXeLeWu2vmoRAgPIAJ4pFx7a59roQHePEJ8/7axPz4dY/wCfYC9t Cnc4dBSm3ILfovqOxWyR2Ew= =u0bH -----END PGP SIGNATURE----- --DesjdUuHQDwS2t4N-- --===============1289318989== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --===============1289318989==-- From dhcwg-bounces@ietf.org Wed Aug 11 21:41:29 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07072; Wed, 11 Aug 2004 21:41:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bv4Yr-0003zn-F4; Wed, 11 Aug 2004 21:39:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bv4U0-0003QZ-5s for dhcwg@megatron.ietf.org; Wed, 11 Aug 2004 21:34:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA06867 for ; Wed, 11 Aug 2004 21:34:18 -0400 (EDT) Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bv4Yq-0008Qz-Ej for dhcwg@ietf.org; Wed, 11 Aug 2004 21:39:21 -0400 Received: from [10.0.2.3] (neubayern.net [66.93.162.100]) by toccata.fugue.com (Postfix) with ESMTP id C6CC41B2F04; Wed, 11 Aug 2004 20:32:05 -0500 (CDT) In-Reply-To: <20040811224350.GJ746@isc.org> References: <20040810224111.GA722@isc.org> <002201c47fee$47009120$d0412ca1@amer.cisco.com> <20040811224350.GJ746@isc.org> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Ted Lemon Subject: Re: [dhcwg] Comments on draft-ietf-dhc-3315id-for-v4-03 Date: Wed, 11 Aug 2004 18:34:13 -0700 To: "David W. Hankins" X-Mailer: Apple Mail (2.618) X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org, rbhibbs@pacbell.net X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 7bit On Aug 11, 2004, at 3:43 PM, David W. Hankins wrote: > I think we should just define the sane and rational behaviour we > expect of the server when it encounters the mixed identities, since > we already appear to have a consensus on what that should be. David, in the case you are describing, the DHCP client has no stable storage. So there's no benefit to implementing the new client identifier type on that client. The server's behavior towards clients that are out of compliance with the draft but do follow RFC2131/2132 is clearly stated in the draft. A host operating system that has been booted by a PXE boot loader that does not comply with this draft, along with the PXE boot loader itself, together represent a system which can never be in compliance with this draft. The host operating system should use the same identifier that the PXE client uses, whatever that is, and not make up its own. If the host operating does in fact make up its own identifier, then we are talking about two different DHCP clients, one of which follows the spec, and one of which does not. The two clients will get two different IP addresses. There is no harm in this, unless you are concerned about excessive IP address consumption. If you are concerned about that, there are stopgap solutions to get you over the hump until the last of those PXE cards dies a well-deserved death. While I sympathize with the issue you are raising, before you go any further I would suggest that you read the problem statement, and then sit down and see if you can write text that resolves the issue you are raising in any better way than the current draft does, while at the same time not failing to meet the goals of the current draft. When you haven't tried yourself to write the text that addresses a problem you're describing in the context of the draft to which you wish to add the text, it's easy to imagine that there is some solution that could be grafted onto any particular document. It is by such mistakes that documents get delayed, sometimes forever, in their journey through the standards process. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Aug 11 22:49:27 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA10225; Wed, 11 Aug 2004 22:49:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bv5X1-0005kg-72; Wed, 11 Aug 2004 22:41:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bv5TX-00058y-9l for dhcwg@megatron.ietf.org; Wed, 11 Aug 2004 22:37:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09834 for ; Wed, 11 Aug 2004 22:37:53 -0400 (EDT) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bv5YO-0000yk-G7 for dhcwg@ietf.org; Wed, 11 Aug 2004 22:42:57 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 11 Aug 2004 22:46:13 -0400 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i7C2bKCf015514; Wed, 11 Aug 2004 22:37:20 -0400 (EDT) Received: from volzw2k (che-vpn-cluster-1-171.cisco.com [10.86.240.171]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AKU15907; Wed, 11 Aug 2004 22:37:19 -0400 (EDT) From: "Bernie Volz" To: "'David W. Hankins'" , Subject: RE: [dhcwg] Comments on draft-ietf-dhc-3315id-for-v4-03 Date: Wed, 11 Aug 2004 22:37:18 -0400 Organization: Cisco Message-ID: <001701c48015$49540c50$6401a8c0@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.5709 In-Reply-To: <20040811224350.GJ746@isc.org> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4939.300 Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: 7bit Cc: rbhibbs@pacbell.net X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 7bit Perhaps I'm not understanding the issue fully, but isn't this a problem if a client first sends NO client identifier (to boot) and then (once the O/S is running) sends a client identifier? Agreed that today many client identifiers are generated from the hardware address and 3315id makes this more problematic (since we don't want servers to look into the DUID) but this, IMHO, is a general problem whenever this switch from no-client identifier to client identifier happens. So, it is a general DHCP issue not really specific to 3315id. - Bernie > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] > On Behalf Of David W. Hankins > Sent: Wednesday, August 11, 2004 6:44 PM > To: dhcwg@ietf.org > Cc: rbhibbs@pacbell.net > Subject: Re: [dhcwg] Comments on draft-ietf-dhc-3315id-for-v4-03 > > > On Wed, Aug 11, 2004 at 05:58:04PM -0400, Bernie Volz wrote: > > I believe this really is more appropriate in > > draft-ietf-dhc-implementation-*.txt, though the (01) draft > appears to > > have > > I don't have a copy of that draft, so I can only guess that > it attempts to clarify the server's behaviour in regards to > the original Client Identifier? > > How is that the right place for defining the expected > behaviour of the server when it encounters the v6 DUID from > v4 clients that previously were only identified by chaddr? > > Sure, if we decide not to go ahead with the v6 DUID (not > likely), I think reviving that draft would be noble, but...I > like the v6 DUID. > > > I think we should just define the sane and rational behaviour > we expect of the server when it encounters the mixed > identities, since we already appear to have a consensus on > what that should be. > > Sending the draft to RFC knowing full well we're going to > have to submit similar clarifying work on its contents later > seems like a lot more work to me. We could just avoid all that. > > -- > David W. Hankins "If you don't do it right the > first time, > Operations Engineer you'll just have to do > it again." > Internet Systems Consortium, Inc. -- Jack T. Hankins > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Thu Aug 12 05:39:22 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16317; Thu, 12 Aug 2004 05:39:21 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvC1R-0006qj-M7; Thu, 12 Aug 2004 05:37:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvBxW-00069N-Hn for dhcwg@megatron.ietf.org; Thu, 12 Aug 2004 05:33:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15999 for ; Thu, 12 Aug 2004 05:33:16 -0400 (EDT) Received: from tyholt.uninett.no ([158.38.60.10]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BvC2S-0007vR-1T for dhcwg@ietf.org; Thu, 12 Aug 2004 05:38:24 -0400 Received: from sverresborg.uninett.no (sverresborg.uninett.no [IPv6:2001:700:e000:0:204:75ff:fee4:423b]) by tyholt.uninett.no (8.12.10/8.12.10) with ESMTP id i7C9VO2M025545; Thu, 12 Aug 2004 11:31:24 +0200 Received: (from venaas@localhost) by sverresborg.uninett.no (8.12.8/8.12.8/Submit) id i7C9VLAU008525; Thu, 12 Aug 2004 11:31:21 +0200 X-Authentication-Warning: sverresborg.uninett.no: venaas set sender to Stig.Venaas@uninett.no using -f Date: Thu, 12 Aug 2004 11:31:21 +0200 From: Stig Venaas To: "JINMEI Tatuya / ?$B?@L@C#:H" Subject: Re: [dhcwg] comments on draft-ietf-dhc-lifetime-01.txt Message-ID: <20040812093121.GB8177@sverresborg.uninett.no> References: <200408030929.31655.jdq@lucent.com> <000201c4797e$2a5f37e0$46828182@amer.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: dhcwg@ietf.org, tjc@ecs.soton.ac.uk, Bernie Volz , jdq@lucent.com X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org On Wed, Aug 11, 2004 at 11:12:16PM +0900, JINMEI Tatuya / ?$B?@L@C#:H wrote: > >>>>> On Tue, 3 Aug 2004 13:20:22 -0400, > >>>>> "Bernie Volz" said: > > > I too would recommend that this option only be used with stateless > > (Information-Request/Reply). It does not apply to stateful - in stateful, > > even if there are no T1/T2 times (i.e., no IA_NA option), the client will > > need to do something when it no longer has addresses so it will get new > > information from the server. I think stateless only might be too strict. One example I have in mind is: If a client sends a request message to obtain addresses and other config options and it does not get any addresses but receives other config data. Then the client may use those options and not make a Request/Information-Request, right? You say client needs to do something when it no longer has addresses, but if you have IPv4 addresses, and the only IPv6 DHCP server says it has no addresses, then I think it's ok for the client to just use what it got without switching to stateless mode, and at some later point make a new Request, still not using stateless mode. How about saying this instead?: The lifetime option is mainly intended for Stateless DHCP service as specified in RFC 3736. If the client receives IA Address options containing lifetimes, the lifetime option should be ignored. The client should get updated configuration data from the server when it renews the addresses. Another thing I'm wondering about is if T1, T2 are zero or infinity. I think the lifetime option might make sense then. In 3315 it says: If T1 or T2 is set to 0 by the server (for an IA_NA) or there are no T1 or T2 times (for an IA_TA), the client may send a Renew or Rebind message, respectively, at the client's discretion. If you get e.g. 0, it might be good to have some sort of lifetime for the other data, and I guess you might then do renew/rebind when the lifetime expires. > I tend to agree. In addition to the above points, I'd like to point > out that in the stateful exchanges the server can initiate update by > Reconfigure - at least in theory. Yes, if clients support it... Stig _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Thu Aug 12 08:18:27 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26960; Thu, 12 Aug 2004 08:18:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvEQ2-0001Qu-NF; Thu, 12 Aug 2004 08:10:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvEMg-0000jP-M0 for dhcwg@megatron.ietf.org; Thu, 12 Aug 2004 08:07:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26528 for ; Thu, 12 Aug 2004 08:07:25 -0400 (EDT) Received: from [203.199.203.114] (helo=brahma.intotoind.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BvERY-0002Ux-9G for dhcwg@ietf.org; Thu, 12 Aug 2004 08:12:34 -0400 Received: from intotoinc.com ([192.168.5.51]) by brahma.intotoind.com (8.12.6/8.11.6) with ESMTP id i7CCDrP1002973; Thu, 12 Aug 2004 17:43:53 +0530 Message-ID: <411B5D73.9010804@intotoinc.com> Date: Thu, 12 Aug 2004 17:37:15 +0530 From: Senthil Kumar B User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bernie Volz Subject: Re: [dhcwg] dhc WG last call on draft-ietf-dhc-proxyserver-opt-00 - NO GO! References: <002001c47fec$c84326f0$d0412ca1@amer.cisco.com> In-Reply-To: <002001c47fec$c84326f0$d0412ca1@amer.cisco.com> X-Scanned-By: MIMEDefang 2.40 X-Spam-Score: 0.6 (/) X-Scan-Signature: 32a65c0bf5eb4ec26489239c7cdd0636 Cc: neumann@wu-wien.ac.at, dhcwg@ietf.org, srihary@cisco.com, exand@wu-wien.ac.at, "'Ralph Droms'" X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1099624753==" Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org This is a multi-part message in MIME format. --===============1099624753== Content-Type: multipart/alternative; boundary="------------050707060704030202010700" This is a multi-part message in MIME format. --------------050707060704030202010700 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Thanks a lot for you reply and please see my reply inline. Replies are in Blue color. Bernie Volz wrote: >I do *NOT* agree with the last call on this document! > >The current document is >http://www.ietf.org/internet-drafts/draft-ietf-dhc-proxyserver-opt-01.txt >and I assume that is really the one being last called and the one I'll >comment on (as there are significant differences between 00 and 01). > >First, I'd like to understand how they'll encode values such as 1080 into a >single byte: > > The Proxy Server Configuration entry consists of a sequence of > Protocol Type (p), Encoding (e), IP address and port. > > +--+--+--+--+--+--+--+--+ > |p |e |IP address |port | > +--+--+--+--+--+--+--+--+ > > The Protocol(p) and encodig (e) are on octet each; each IP address is >---------------------------------------^^ (I assume this is ONE octet each?) > four octets, and each port number is a two-octet integer encoded in > network byte order. > >And then: > > The protocol type(p) specifies the type of Protocol and MUST be > one of the following assigned numbers. > > +-------------------------------+ > | protocol | Number | > +-------------------------------+ > | HTTP | 80 | > +-------------------------------+ > | FTP | 21 | > +-------------------------------+ > | NNTP | 119 | > +-------------------------------+ > | Gopher | 70 | > +-------------------------------+ > | SSL | TBD | > +-------------------------------+ > | SOCKS | 1080 | > >1080 requires two bytes to encode. > I agree that the protocol should be 2 octets. Initially, I thought of getting these protocol types assigned by IANA. As per your earlier suggestion, I had changed it to standard protocol numbers, but forgot to update the document. Will change it. > >Later, the document goes on about: > > The format of the Proxy Server Configuration using Metadata type is: > > > p Len RDF Metadata for the Proxy > +-------+------+----------------------------------+ > | RDF | N | RDF | > +-------+------+----------------------------------+ > > >What is this and where does this go? Is this a new option? Is this encoded >in the existing option in some manner which I can't understand? > > >And, the option size would seem to exceed the 255 byte limit: "... giving a >total of 418 characters including the overhead", yet nothing is ever >mentioned about RFC 3396 (encoding long options). > If the protocol type field (first field in the tuple in p/e/IPADDR/port) has the value for RDF (as specified in the table), then it SHOULD be followed by the length (N) of the RDF payload. I agree that RFC 3396 needs to be referred here. Will do the changes. Please let me know if there are any further comments, so that i can update all at once and will submit a new version. > >So, I think this draft needs much further revision before I feel it would be >acceptable. > >Best regards, > >- Bernie > > > >>-----Original Message----- >>From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] >>On Behalf Of Ralph Droms >>Sent: Wednesday, August 11, 2004 3:15 PM >>To: dhcwg@ietf.org >>Subject: [dhcwg] dhc WG last call on draft-ietf-dhc-proxyserver-opt-00 >> >> >>This message announces a second WG last call on "DHCP Option >>for Proxy Server Configuration" >>. There was insufficient >>(that is, none) response to the first WG last call. This >>document can not be submitted to the IESG without positive >>response during the WG last call. This last call will >>conclude at 1700 EDT, 2004-08-27. >> >>Please respond to this WG last call. If you support >>acceptance of the document without change, respond with a >>simple acknowledgment, so that support for the document can >>be assessed. >> >>"DHCP Option for Proxy Server Configuration" defines a >>Dynamic Host Configuration Protocol (DHCP) option that can be >>used to configure the TCP/IP host's Proxy Server >>configuration for standard protocols like HTTP, FTP, NNTP, >>SOCKS, Gopher, SLL and etc. Proxy servers provide controlled >>and efficient access to the Internet through the use of >>access control mechanisms for different types of user >>requests and caching frequently accessed information (Web >>pages and other files that might have been downloaded using >>FTP and other protocols). This draft is available as >> >> >http://www.ietf.org/internet-drafts/draft-ietf-dhc-proxyserver-opt-00.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 > > >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www1.ietf.org/mailman/listinfo/dhcwg > > > --------------050707060704030202010700 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Thanks a lot for you reply and please see my reply inline. Replies are in Blue color.

Bernie Volz wrote:
I do *NOT* agree with the last call on this document!

The current document is
http://www.ietf.org/internet-drafts/draft-ietf-dhc-proxyserver-opt-01.txt
and I assume that is really the one being last called and the one I'll
comment on (as there are significant differences between 00 and 01).

First, I'd like to understand how they'll encode values such as 1080 into a
single byte:

   The Proxy Server Configuration entry consists of a sequence of 
   Protocol Type (p), Encoding (e), IP address and port. 
   	  
   	+--+--+--+--+--+--+--+--+
	|p |e |IP address |port |
	+--+--+--+--+--+--+--+--+

   The Protocol(p) and encodig (e) are on octet each; each IP address is
---------------------------------------^^ (I assume this is ONE octet each?)
   four octets, and each port number is a two-octet integer encoded in
   network byte order.

And then:

   The protocol type(p) specifies the type of Protocol and MUST be 
   one of the following assigned numbers.

       +-------------------------------+
       | protocol     |       Number   |
       +-------------------------------+
       |   HTTP       |         80     |
       +-------------------------------+
       |   FTP        |         21     |
       +-------------------------------+
       |   NNTP       |         119    |
       +-------------------------------+
       |   Gopher     |         70     |
       +-------------------------------+
       |   SSL        |         TBD    |
       +-------------------------------+
       |   SOCKS      |         1080   |
  
1080 requires two bytes to encode.

I agree that the protocol should be 2 octets. Initially, I thought of getting these protocol types assigned by IANA.

As per your earlier suggestion, I had changed it to standard protocol numbers, but forgot to update the document.

Will change it. 

Later, the document goes on about:

   The format of the Proxy Server Configuration using Metadata type is:


            p       Len        RDF Metadata for the Proxy    
   	 +-------+------+----------------------------------+
   	 |  RDF  |  N   |             RDF                  |
   	 +-------+------+----------------------------------+


What is this and where does this go? Is this a new option? Is this encoded
in the existing option in some manner which I can't understand?


And, the option size would seem to exceed the 255 byte limit: "... giving a
total of 418 characters including the overhead", yet nothing is ever
mentioned about RFC 3396 (encoding long options).
If the protocol type field (first field in the tuple in p/e/IPADDR/port) has the value for RDF (as specified in the table), 
then it SHOULD be followed by the length (N) of the RDF payload.

I agree that RFC 3396 needs to be referred here. Will do the changes.

Please let me know if there are any further comments, so that i can update all at once and will submit a new version.
 

So, I think this draft needs much further revision before I feel it would be
acceptable.

Best regards,

- Bernie

  
-----Original Message-----
From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] 
On Behalf Of Ralph Droms
Sent: Wednesday, August 11, 2004 3:15 PM
To: dhcwg@ietf.org
Subject: [dhcwg] dhc WG last call on draft-ietf-dhc-proxyserver-opt-00


This message announces a second WG last call on "DHCP Option 
for Proxy Server Configuration" 
<draft-ietf-dhc-proxyserver-opt-00>.  There was insufficient 
(that is, none) response to the first WG last call.  This 
document can not be submitted to the IESG without positive 
response during the WG last call.  This last call will 
conclude at 1700 EDT, 2004-08-27.

Please respond to this WG last call.  If you support 
acceptance of the document without change, respond with a 
simple acknowledgment, so that support for the document can 
be assessed.

"DHCP Option for Proxy Server Configuration" defines a 
Dynamic Host Configuration Protocol (DHCP) option that can be 
used to configure the TCP/IP host's Proxy Server 
configuration for standard protocols like HTTP, FTP, NNTP, 
SOCKS, Gopher, SLL and etc. Proxy servers provide controlled 
and efficient access to the Internet through the use of 
access control mechanisms for different types of user 
requests and caching frequently accessed information (Web 
pages and other files that might have been downloaded using 
FTP and other protocols).  This draft is available as 
    
http://www.ietf.org/internet-drafts/draft-ietf-dhc-proxyserver-opt-00.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


_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg
--------------050707060704030202010700-- --===============1099624753== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --===============1099624753==-- From dhcwg-bounces@ietf.org Thu Aug 12 08:51:52 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28785; Thu, 12 Aug 2004 08:51:52 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvExe-0007IQ-S7; Thu, 12 Aug 2004 08:45:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvEkd-0004RZ-SZ for dhcwg@megatron.ietf.org; Thu, 12 Aug 2004 08:32:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27608 for ; Thu, 12 Aug 2004 08:32:10 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BvEpa-0002pZ-J6 for dhcwg@ietf.org; Thu, 12 Aug 2004 08:37:19 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 12 Aug 2004 05:35:43 +0000 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i7CCVZq1008286; Thu, 12 Aug 2004 05:31:36 -0700 (PDT) Received: from volzw2k (che-vpn-cluster-1-171.cisco.com [10.86.240.171]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AKU29688; Thu, 12 Aug 2004 08:31:33 -0400 (EDT) From: "Bernie Volz" To: "'Senthil Kumar B'" Subject: RE: [dhcwg] dhc WG last call on draft-ietf-dhc-proxyserver-opt-00 - NO GO! Date: Thu, 12 Aug 2004 08:31:32 -0400 Organization: Cisco Message-ID: <001501c48068$4d9c0080$6401a8c0@amer.cisco.com> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.5709 In-Reply-To: <411B5D73.9010804@intotoinc.com> X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4939.300 Importance: Normal X-Spam-Score: 0.6 (/) X-Scan-Signature: f31e050dc7ce62aeed70903f7da21012 Cc: neumann@wu-wien.ac.at, dhcwg@ietf.org, srihary@cisco.com, exand@wu-wien.ac.at, "'Ralph Droms'" X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1639510629==" Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org This is a multi-part message in MIME format. --===============1639510629== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0016_01C48046.C68BE720" This is a multi-part message in MIME format. ------=_NextPart_000_0016_01C48046.C68BE720 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi: =20 IMHO, the design of this option is bad - what if you want a new protocol = and want it to have a encoding similar to RDF? You won't be able to do this because all clients and servers would need to be upgraded at once - = which is clearly not possible. =20 You need to think about a general format that will accommodate future = growth and do it in a backwards compatible manner. =20 Perhaps something like: 2-bytes protocol number 1-byte encoding variable number of data bytes depending on encoding =20 This is still not that great because you can't add a new encoding type without upgrading all clients and servers at once. Though, one of the = known encoding types could have the data contain a length in the first 2-bytes = to accommodate the RDF encoding. =20 A better format, though less compact, might be: Protocol number (2 bytes) Data length (1 or 2 bytes; 2 probably needed if RDF could be > 255 bytes) Data of length bytes =20 The data of length bytes for most protocols would be
. is likely a bad name for this = field in this case? =20 In this way, you can extend the future "encodings" because those that = don't know the "encoding" for a protocol number know what to do - they simply = skip the data (and they know how long it is). =20 It isn't as compact as the old encoding, but it is much more extensible. =20 - Bernie -----Original Message----- From: Senthil Kumar B [mailto:ksenthil@intotoinc.com]=20 Sent: Thursday, August 12, 2004 8:07 AM To: Bernie Volz Cc: 'Ralph Droms'; dhcwg@ietf.org; neumann@wu-wien.ac.at; = srihary@cisco.com; exand@wu-wien.ac.at Subject: Re: [dhcwg] dhc WG last call on = draft-ietf-dhc-proxyserver-opt-00 - NO GO! Thanks a lot for you reply and please see my reply inline. Replies are = in Blue color. Bernie Volz wrote: I do *NOT* agree with the last call on this document! The current document is http://www.ietf.org/internet-drafts/draft-ietf-dhc-proxyserver-opt-01.txt= and I assume that is really the one being last called and the one I'll comment on (as there are significant differences between 00 and 01). First, I'd like to understand how they'll encode values such as 1080 = into a single byte: The Proxy Server Configuration entry consists of a sequence of=20 Protocol Type (p), Encoding (e), IP address and port.=20 =20 +--+--+--+--+--+--+--+--+ |p |e |IP address |port | +--+--+--+--+--+--+--+--+ The Protocol(p) and encodig (e) are on octet each; each IP address is ---------------------------------------^^ (I assume this is ONE octet = each?) four octets, and each port number is a two-octet integer encoded in network byte order. And then: The protocol type(p) specifies the type of Protocol and MUST be=20 one of the following assigned numbers. +-------------------------------+ | protocol | Number | +-------------------------------+ | HTTP | 80 | +-------------------------------+ | FTP | 21 | +-------------------------------+ | NNTP | 119 | +-------------------------------+ | Gopher | 70 | +-------------------------------+ | SSL | TBD | +-------------------------------+ | SOCKS | 1080 | =20 1080 requires two bytes to encode. I agree that the protocol should be 2 octets. Initially, I thought of getting these protocol types assigned by IANA. As per your earlier suggestion, I had changed it to standard protocol numbers, but forgot to update the document. Will change it.=20 Later, the document goes on about: The format of the Proxy Server Configuration using Metadata type is: p Len RDF Metadata for the Proxy =20 +-------+------+----------------------------------+ | RDF | N | RDF | +-------+------+----------------------------------+ What is this and where does this go? Is this a new option? Is this = encoded in the existing option in some manner which I can't understand? And, the option size would seem to exceed the 255 byte limit: "... = giving a total of 418 characters including the overhead", yet nothing is ever mentioned about RFC 3396 (encoding long options). If the protocol type field (first field in the tuple in p/e/IPADDR/port) = has the value for RDF (as specified in the table), =20 then it SHOULD be followed by the length (N) of the RDF payload. I agree that RFC 3396 needs to be referred here. Will do the changes. Please let me know if there are any further comments, so that i can = update all at once and will submit a new version. So, I think this draft needs much further revision before I feel it = would be acceptable. Best regards, - Bernie =20 -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org]=20 On Behalf Of Ralph Droms Sent: Wednesday, August 11, 2004 3:15 PM To: dhcwg@ietf.org Subject: [dhcwg] dhc WG last call on draft-ietf-dhc-proxyserver-opt-00 This message announces a second WG last call on "DHCP Option=20 for Proxy Server Configuration"=20 . There was insufficient=20 (that is, none) response to the first WG last call. This=20 document can not be submitted to the IESG without positive=20 response during the WG last call. This last call will=20 conclude at 1700 EDT, 2004-08-27. Please respond to this WG last call. If you support=20 acceptance of the document without change, respond with a=20 simple acknowledgment, so that support for the document can=20 be assessed. "DHCP Option for Proxy Server Configuration" defines a=20 Dynamic Host Configuration Protocol (DHCP) option that can be=20 used to configure the TCP/IP host's Proxy Server=20 configuration for standard protocols like HTTP, FTP, NNTP,=20 SOCKS, Gopher, SLL and etc. Proxy servers provide controlled=20 and efficient access to the Internet through the use of=20 access control mechanisms for different types of user=20 requests and caching frequently accessed information (Web=20 pages and other files that might have been downloaded using=20 FTP and other protocols). This draft is available as=20 =20 http://www.ietf.org/internet-drafts/draft-ietf-dhc-proxyserver-opt-00.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 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg =20 ------=_NextPart_000_0016_01C48046.C68BE720 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Message
Hi:
 
IMHO,=20 the design of this option is bad - what if you want a new protocol = and want=20 it to have a encoding similar to RDF? You won't be able to do this = because all=20 clients and servers would need to be upgraded at once - which is clearly = not=20 possible.
 
You=20 need to think about a general format that will accommodate future growth = and do=20 it in a backwards compatible manner.
 
Perhaps something like:
    2-bytes protocol number
    1-byte encoding
    variable number of data bytes depending on=20 encoding
 
This=20 is still not that great because you can't add a new encoding type = without=20 upgrading all clients and servers at once. Though, one of the known = encoding=20 types could have the data contain a length in the first 2-bytes to = accommodate=20 the RDF encoding.
 
A=20 better format, though less compact, might be:
    Protocol number (2 = bytes)
    Data length (1 or 2 bytes; 2 probably needed = if=20 RDF could be > 255 bytes)
    Data of length bytes
 
The=20 data of length bytes for most protocols would be=20 <encoding><address><port>. <encoding> is likely = a bad=20 name for this field in this case?
 
In=20 this way, you can extend the future "encodings" because those that don't = know=20 the "encoding" for a protocol number know what to do - they simply skip = the data=20 (and they know how long it is).
 
It=20 isn't as compact as the old encoding, but it is much more=20 extensible.
 
-=20 Bernie
-----Original Message-----
From: = Senthil Kumar B=20 [mailto:ksenthil@intotoinc.com]
Sent: Thursday, August 12, = 2004=20 8:07 AM
To: Bernie Volz
Cc: 'Ralph Droms'; = dhcwg@ietf.org;=20 neumann@wu-wien.ac.at; srihary@cisco.com;=20 exand@wu-wien.ac.at
Subject: Re: [dhcwg] dhc WG last call on = draft-ietf-dhc-proxyserver-opt-00 - NO GO!

Thanks = a lot=20 for you reply and please see my reply inline. Replies are in Blue=20 color.

Bernie Volz wrote:
I do *NOT* agree with the last call on this =
document!

The current document is
http://www.ietf.org/internet-drafts/draft-ietf-dhc-proxyserver-=
opt-01.txt
and I assume that is really the one being last called and the one I'll
comment on (as there are significant differences between 00 and 01).

First, I'd like to understand how they'll encode values such as 1080 =
into a
single byte:

   The Proxy Server Configuration entry consists of a sequence of=20
   Protocol Type (p), Encoding (e), IP address and port.=20
   	 =20
   	+--+--+--+--+--+--+--+--+
	|p |e |IP address |port |
	+--+--+--+--+--+--+--+--+

   The Protocol(p) and encodig (e) are on octet each; each IP address is
---------------------------------------^^ (I assume this is ONE octet =
each?)
   four octets, and each port number is a two-octet integer encoded in
   network byte order.

And then:

   The protocol type(p) specifies the type of Protocol and MUST be=20
   one of the following assigned numbers.

       +-------------------------------+
       | protocol     |       Number   |
       +-------------------------------+
       |   HTTP       |         80     |
       +-------------------------------+
       |   FTP        |         21     |
       +-------------------------------+
       |   NNTP       |         119    |
       +-------------------------------+
       |   Gopher     |         70     |
       +-------------------------------+
       |   SSL        |         TBD    |
       +-------------------------------+
       |   SOCKS      |         1080   |
 =20
1080 requires two bytes to encode.

I=20 agree that the protocol should be 2 octets. Initially, I thought of = getting=20 these protocol types assigned by IANA.

As per your earlier = suggestion,=20 I had changed it to standard protocol numbers, but forgot to update = the=20 document.

Will change it. 
Later, the document goes on about:

   The format of the Proxy Server Configuration using Metadata type is:


            p       Len        RDF Metadata for the Proxy   =20
   	 +-------+------+----------------------------------+
   	 |  RDF  |  N   |             RDF                  |
   	 +-------+------+----------------------------------+


What is this and where does this go? Is this a new option? Is this =
encoded
in the existing option in some manner which I can't understand?


And, the option size would seem to exceed the 255 byte limit: "... =
giving a
total of 418 characters including the overhead", yet nothing is ever
mentioned about RFC 3396 (encoding long =
options).
If the protocol type field (first field in the tuple = in=20 p/e/IPADDR/port) has the value for RDF (as specified in the = table), =20
then it SHOULD be followed by the length (N) of the RDF = payload.

I=20 agree that RFC 3396 needs to be referred here. Will do the=20 changes.

Please let me know if there are any further comments, = so that=20 i can update all at once and will submit a new version.
So, I think this draft needs much further revision before I feel it =
would be
acceptable.

Best regards,

- Bernie

  
-----Original Message-----
From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org]=
=20
On Behalf Of Ralph Droms
Sent: Wednesday, August 11, 2004 3:15 PM
To: dhcwg@ietf.org
Subject: [dhcwg] dhc WG last call on draft-ietf-dhc-proxyserver-opt-00


This message announces a second WG last call on "DHCP Option=20
for Proxy Server Configuration"=20
<draft-ietf-dhc-proxyserver-opt-00>.  There was insufficient=20
(that is, none) response to the first WG last call.  This=20
document can not be submitted to the IESG without positive=20
response during the WG last call.  This last call will=20
conclude at 1700 EDT, 2004-08-27.

Please respond to this WG last call.  If you support=20
acceptance of the document without change, respond with a=20
simple acknowledgment, so that support for the document can=20
be assessed.

"DHCP Option for Proxy Server Configuration" defines a=20
Dynamic Host Configuration Protocol (DHCP) option that can be=20
used to configure the TCP/IP host's Proxy Server=20
configuration for standard protocols like HTTP, FTP, NNTP,=20
SOCKS, Gopher, SLL and etc. Proxy servers provide controlled=20
and efficient access to the Internet through the use of=20
access control mechanisms for different types of user=20
requests and caching frequently accessed information (Web=20
pages and other files that might have been downloaded using=20
FTP and other protocols).  This draft is available as=20
    
http://www.ietf.org/internet-drafts/draft-ietf-dhc-proxyserver-=
opt-00.txt

- Ralph Droms


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


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


_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.o=
rg/mailman/listinfo/dhcwg
------=_NextPart_000_0016_01C48046.C68BE720-- --===============1639510629== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --===============1639510629==-- From dhcwg-bounces@ietf.org Thu Aug 12 08:52:48 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28858; Thu, 12 Aug 2004 08:52:48 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvExf-0007Io-BD; Thu, 12 Aug 2004 08:45:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvElE-0004dv-3z for dhcwg@megatron.ietf.org; Thu, 12 Aug 2004 08:32:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27640 for ; Thu, 12 Aug 2004 08:32:46 -0400 (EDT) Received: from ihemail1.lucent.com ([192.11.222.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BvEq9-0002qE-II for dhcwg@ietf.org; Thu, 12 Aug 2004 08:37:55 -0400 Received: from homail.ho.lucent.com (h135-17-192-10.lucent.com [135.17.192.10]) by ihemail1.lucent.com (8.12.11/8.12.11) with ESMTP id i7CCVpld019613; Thu, 12 Aug 2004 07:31:51 -0500 (CDT) Received: from kraken.mh.lucent.com by homail.ho.lucent.com (8.11.7+Sun/EMS-1.5 sol2) id i7CCVox23191; Thu, 12 Aug 2004 08:31:50 -0400 (EDT) From: Joe Quanaim To: Stig Venaas , "JINMEI Tatuya / ?$B?@L@C#:H" Subject: Re: [dhcwg] comments on draft-ietf-dhc-lifetime-01.txt Date: Thu, 12 Aug 2004 08:31:01 -0400 User-Agent: KMail/1.5.4 References: <200408030929.31655.jdq@lucent.com> <20040812093121.GB8177@sverresborg.uninett.no> In-Reply-To: <20040812093121.GB8177@sverresborg.uninett.no> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200408120831.02326.jdq@lucent.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org, tjc@ecs.soton.ac.uk, Bernie Volz X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jdq@lucent.com List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 7bit Stig Venaas wrote: > On Wed, Aug 11, 2004 at 11:12:16PM +0900, JINMEI Tatuya / ?$B?@L@C#:H wrote: > > >>>>> On Tue, 3 Aug 2004 13:20:22 -0400, > > >>>>> "Bernie Volz" said: > > > > > > I too would recommend that this option only be used with stateless > > > (Information-Request/Reply). It does not apply to stateful - in > > > stateful, even if there are no T1/T2 times (i.e., no IA_NA option), the > > > client will need to do something when it no longer has addresses so it > > > will get new information from the server. > > I think stateless only might be too strict. > > One example I have in mind is: > > If a client sends a request message to obtain addresses and other config > options and it does not get any addresses but receives other config > data. Then the client may use those options and not make a > Request/Information-Request, right? You say client needs to do something > when it no longer has addresses, but if you have IPv4 addresses, and the > only IPv6 DHCP server says it has no addresses, then I think it's ok for > the client to just use what it got without switching to stateless mode, > and at some later point make a new Request, still not using stateless > mode. I am not sure that the lifetime option is necessary when using stateful. I would consider this example stateless because the client has not successfully negotiated any (IPv6) addresses. Here I think you are right, though, a client should use the lifetime option. If it has any addresses, I think it should ignore the lifetime option. > How about saying this instead?: > > The lifetime option is mainly intended for Stateless DHCP service as > specified in RFC 3736. If the client receives IA Address options > containing lifetimes, the lifetime option should be ignored. The > client should get updated configuration data from the server when it > renews the addresses. > > Another thing I'm wondering about is if T1, T2 are zero or infinity. I > think the lifetime option might make sense then. In 3315 it says: > > If T1 or T2 is set to 0 by the server (for an IA_NA) or there are no > T1 or T2 times (for an IA_TA), the client may send a Renew or Rebind > message, respectively, at the client's discretion. > > If you get e.g. 0, it might be good to have some sort of lifetime for > the other data, and I guess you might then do renew/rebind when the > lifetime expires. > Even if T1 and T2 are zero or infinity, you have the lifetime of the address to fall back on. RFC 3315 says: Note that an IA_NA has no explicit "lifetime" or "lease length" of its own. When the valid lifetimes of all of the addresses in an IA_NA have expired, the IA_NA can be considered as having expired. And says something similar for IA_TA's. There is still an issue when the lifetime of the address is set to infinity, but this seems like a special case and one that might be used intentionally for one time configuration. Joe Quanaim. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Thu Aug 12 09:03:11 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29264; Thu, 12 Aug 2004 09:03:11 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvF0b-0007y9-R8; Thu, 12 Aug 2004 08:48:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvEtL-0006Ig-DG for dhcwg@megatron.ietf.org; Thu, 12 Aug 2004 08:41:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28319 for ; Thu, 12 Aug 2004 08:41:10 -0400 (EDT) Received: from tyholt.uninett.no ([158.38.60.10]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BvEyI-000339-SH for dhcwg@ietf.org; Thu, 12 Aug 2004 08:46:19 -0400 Received: from sverresborg.uninett.no (sverresborg.uninett.no [IPv6:2001:700:e000:0:204:75ff:fee4:423b]) by tyholt.uninett.no (8.12.10/8.12.10) with ESMTP id i7CCeX2M009464; Thu, 12 Aug 2004 14:40:33 +0200 Received: (from venaas@localhost) by sverresborg.uninett.no (8.12.8/8.12.8/Submit) id i7CCeVn5009024; Thu, 12 Aug 2004 14:40:31 +0200 X-Authentication-Warning: sverresborg.uninett.no: venaas set sender to Stig.Venaas@uninett.no using -f Date: Thu, 12 Aug 2004 14:40:31 +0200 From: Stig Venaas To: Joe Quanaim Subject: Re: [dhcwg] comments on draft-ietf-dhc-lifetime-01.txt Message-ID: <20040812124031.GH8177@sverresborg.uninett.no> References: <200408030929.31655.jdq@lucent.com> <20040812093121.GB8177@sverresborg.uninett.no> <200408120831.02326.jdq@lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200408120831.02326.jdq@lucent.com> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: dhcwg@ietf.org, tjc@ecs.soton.ac.uk X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org On Thu, Aug 12, 2004 at 08:31:01AM -0400, Joe Quanaim wrote: > Stig Venaas wrote: [...] > > I think stateless only might be too strict. > > > > One example I have in mind is: > > > > If a client sends a request message to obtain addresses and other config > > options and it does not get any addresses but receives other config > > data. Then the client may use those options and not make a > > Request/Information-Request, right? You say client needs to do something > > when it no longer has addresses, but if you have IPv4 addresses, and the > > only IPv6 DHCP server says it has no addresses, then I think it's ok for > > the client to just use what it got without switching to stateless mode, > > and at some later point make a new Request, still not using stateless > > mode. > > I am not sure that the lifetime option is necessary when using stateful. I > would consider this example stateless because the client has not successfully > negotiated any (IPv6) addresses. Here I think you are right, though, a > client should use the lifetime option. If it has any addresses, I think it > should ignore the lifetime option. OK, I can agree with you if you define stateless that way. I'm thinking of stateless as defined in RFC 3736 using only Information-Request/Reply. My point is that it might be useful to use it with Request/Reply as well. So, my suggested wording should be ok then I understand you correctly. > > How about saying this instead?: > > > > The lifetime option is mainly intended for Stateless DHCP service as > > specified in RFC 3736. If the client receives IA Address options > > containing lifetimes, the lifetime option should be ignored. The > > client should get updated configuration data from the server when it > > renews the addresses. > > > > Another thing I'm wondering about is if T1, T2 are zero or infinity. I > > think the lifetime option might make sense then. In 3315 it says: > > > > If T1 or T2 is set to 0 by the server (for an IA_NA) or there are no > > T1 or T2 times (for an IA_TA), the client may send a Renew or Rebind > > message, respectively, at the client's discretion. > > > > If you get e.g. 0, it might be good to have some sort of lifetime for > > the other data, and I guess you might then do renew/rebind when the > > lifetime expires. > > > > Even if T1 and T2 are zero or infinity, you have the lifetime of the address > to fall back on. RFC 3315 says: > > Note that an IA_NA has no explicit "lifetime" or "lease length" of > its own. When the valid lifetimes of all of the addresses in an > IA_NA have expired, the IA_NA can be considered as having expired. > > And says something similar for IA_TA's. There is still an issue when the > lifetime of the address is set to infinity, but this seems like a special > case and one that might be used intentionally for one time configuration. Right, sounds reasonable. Thanks, Stig _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Thu Aug 12 09:04:31 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29370; Thu, 12 Aug 2004 09:04:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvF19-0008BV-NP; Thu, 12 Aug 2004 08:49:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvEwB-0006yx-De for dhcwg@megatron.ietf.org; Thu, 12 Aug 2004 08:44:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28473 for ; Thu, 12 Aug 2004 08:44:06 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BvF18-00036l-RG for dhcwg@ietf.org; Thu, 12 Aug 2004 08:49:15 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-1.cisco.com with ESMTP; 12 Aug 2004 05:46:41 -0700 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i7CCgKCN003018; Thu, 12 Aug 2004 05:42:23 -0700 (PDT) Received: from volzw2k (che-vpn-cluster-1-171.cisco.com [10.86.240.171]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AKU30277; Thu, 12 Aug 2004 08:43:27 -0400 (EDT) From: "Bernie Volz" To: , "'Stig Venaas'" , "'JINMEI Tatuya / ?$B?@L@C#:H'" Subject: RE: [dhcwg] comments on draft-ietf-dhc-lifetime-01.txt Date: Thu, 12 Aug 2004 08:43:27 -0400 Organization: Cisco Message-ID: <002601c48069$f73b3330$6401a8c0@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.5709 In-Reply-To: <200408120831.02326.jdq@lucent.com> X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4939.300 Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 200d029292fbb60d25b263122ced50fc Content-Transfer-Encoding: quoted-printable Cc: dhcwg@ietf.org, tjc@ecs.soton.ac.uk X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: quoted-printable If a server sets the T1/T2 times to infinity, it gets what it asked for = - the configuration is static FOREVER. This is one reason it would be an extremely bad idea to ever use these values. We added them for clarity = in the RFC, though never really figured they would be used in practice. The no address issue is an interested one. On a SOLICIT, the server is ONLY to return the Status Message response = with NoAddrAvail status. It is *NOT* supposed to return any configuration information!!! Though it is always possible that a subsequent REQUEST or RENEW/REBIND = would result in no addresses. However, in those cases the IA_NA is still = returned with T1 and T2 times and those would, IMHO, apply. (In these cases, the NoAddrAvail status is embedded *INSIDE* the IA_* options so these = options are still returned.) I suppose there is the case when a SOLICIT/REQUEST/RENEW/REBIND for an = IA_NA and IA_TA results in no addresses for a IA_NA and one or more addresses = for a IA_TA, in which case no T1/T2 times are provided - thought the IA_TA = does have lifetimes. But, all of this gets very messy fairly quickly. So, perhaps the easiest thing to do is to *ALWAYS* allow the LIFETIME = option - for stateful and stateless. A client *SHOULD* renew (etc) its = information whenver the shortest time expires - LIFETIME, T1, or lifetime on an = address (and the client needs a replacement address). If the client is stateful, = is uses RENEW (whether the client includes on or more IA_NAs if no T1 time = has expired is a matter of local policy - though it would seem reasonable = for me if it did since there's no harm in doing so). If a client is stateless, = it uses INFORMATION-REQUEST. This also makes server implementations easier since the T1/T2 times and "other-configuration-parameters" lifetime can be configured = independently and a server need not assure that no T1 time is greater than "other-configuration-parameters". - Bernie > -----Original Message----- > From: Joe Quanaim [mailto:jdq@lucent.com]=20 > Sent: Thursday, August 12, 2004 8:31 AM > To: Stig Venaas; JINMEI Tatuya / ?$B?@L@C#:H > Cc: dhcwg@ietf.org; tjc@ecs.soton.ac.uk; Bernie Volz > Subject: Re: [dhcwg] comments on draft-ietf-dhc-lifetime-01.txt >=20 >=20 > Stig Venaas wrote: > > On Wed, Aug 11, 2004 at 11:12:16PM +0900, JINMEI Tatuya /=20 > ?$B?@L@C#:H=20 > > wrote: > > > >>>>> On Tue, 3 Aug 2004 13:20:22 -0400, > > > >>>>> "Bernie Volz" said: > > > > > > > > I too would recommend that this option only be used=20 > with stateless=20 > > > > (Information-Request/Reply). It does not apply to stateful - in=20 > > > > stateful, even if there are no T1/T2 times (i.e., no IA_NA=20 > > > > option), the client will need to do something when it no longer=20 > > > > has addresses so it will get new information from the server. > > > > I think stateless only might be too strict. > > > > One example I have in mind is: > > > > If a client sends a request message to obtain addresses and other=20 > > config options and it does not get any addresses but receives other=20 > > config data. Then the client may use those options and not make a=20 > > Request/Information-Request, right? You say client needs to do=20 > > something when it no longer has addresses, but if you have IPv4=20 > > addresses, and the only IPv6 DHCP server says it has no addresses,=20 > > then I think it's ok for the client to just use what it got without=20 > > switching to stateless mode, and at some later point make a new=20 > > Request, still not using stateless mode. >=20 > I am not sure that the lifetime option is necessary when=20 > using stateful. I=20 > would consider this example stateless because the client has=20 > not successfully=20 > negotiated any (IPv6) addresses. Here I think you are right,=20 > though, a=20 > client should use the lifetime option. If it has any=20 > addresses, I think it=20 > should ignore the lifetime option. >=20 > > How about saying this instead?: > > > > The lifetime option is mainly intended for Stateless=20 > DHCP service as > > specified in RFC 3736. If the client receives IA Address options > > containing lifetimes, the lifetime option should be ignored. The > > client should get updated configuration data from the=20 > server when it > > renews the addresses. > > > > Another thing I'm wondering about is if T1, T2 are zero or=20 > infinity. I=20 > > think the lifetime option might make sense then. In 3315 it says: > > > > If T1 or T2 is set to 0 by the server (for an IA_NA) or=20 > there are no > > T1 or T2 times (for an IA_TA), the client may send a=20 > Renew or Rebind > > message, respectively, at the client's discretion. > > > > If you get e.g. 0, it might be good to have some sort of=20 > lifetime for=20 > > the other data, and I guess you might then do renew/rebind when the=20 > > lifetime expires. > > >=20 > Even if T1 and T2 are zero or infinity, you have the lifetime=20 > of the address=20 > to fall back on. RFC 3315 says: >=20 > Note that an IA_NA has no explicit "lifetime" or "lease length" of > its own. When the valid lifetimes of all of the addresses in an > IA_NA have expired, the IA_NA can be considered as having expired. >=20 > And says something similar for IA_TA's. There is still an=20 > issue when the=20 > lifetime of the address is set to infinity, but this seems=20 > like a special=20 > case and one that might be used intentionally for one time=20 > configuration. >=20 > Joe Quanaim. >=20 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Thu Aug 12 09:27:29 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00815; Thu, 12 Aug 2004 09:27:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvFVx-0005db-Sw; Thu, 12 Aug 2004 09:21:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvFMY-0003e3-Cv for dhcwg@megatron.ietf.org; Thu, 12 Aug 2004 09:11:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29867 for ; Thu, 12 Aug 2004 09:11:21 -0400 (EDT) Received: from ihemail1.lucent.com ([192.11.222.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BvFRV-0003Y8-BH for dhcwg@ietf.org; Thu, 12 Aug 2004 09:16:30 -0400 Received: from homail.ho.lucent.com (h135-17-192-10.lucent.com [135.17.192.10]) by ihemail1.lucent.com (8.12.11/8.12.11) with ESMTP id i7CDAfku012719; Thu, 12 Aug 2004 08:10:42 -0500 (CDT) Received: from kraken.mh.lucent.com by homail.ho.lucent.com (8.11.7+Sun/EMS-1.5 sol2) id i7CDAex06575; Thu, 12 Aug 2004 09:10:40 -0400 (EDT) From: Joe Quanaim To: Stig Venaas Subject: Re: [dhcwg] comments on draft-ietf-dhc-lifetime-01.txt Date: Thu, 12 Aug 2004 09:10:40 -0400 User-Agent: KMail/1.5.4 References: <200408030929.31655.jdq@lucent.com> <200408120831.02326.jdq@lucent.com> <20040812124031.GH8177@sverresborg.uninett.no> In-Reply-To: <20040812124031.GH8177@sverresborg.uninett.no> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200408120910.40182.jdq@lucent.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org, tjc@ecs.soton.ac.uk X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jdq@lucent.com List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 7bit Stig Venaas wrote: > So, my suggested wording should be ok then I understand you correctly. > > > > How about saying this instead?: > > > > > > The lifetime option is mainly intended for Stateless DHCP service as > > > specified in RFC 3736. If the client receives IA Address options > > > containing lifetimes, the lifetime option should be ignored. The > > > client should get updated configuration data from the server when it > > > renews the addresses. I think that this wording is good. It does not intermix the lifetime option among the various possible t1, t2, and address lifetimes which I think complicates. Thanks, Joe. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Thu Aug 12 09:35:16 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01265; Thu, 12 Aug 2004 09:35:15 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvFW2-0005gP-3z; Thu, 12 Aug 2004 09:21:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvFOO-0003uy-UV for dhcwg@megatron.ietf.org; Thu, 12 Aug 2004 09:13:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29915 for ; Thu, 12 Aug 2004 09:13:15 -0400 (EDT) Received: from tyholt.uninett.no ([158.38.60.10]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BvFTM-0003Zj-MC for dhcwg@ietf.org; Thu, 12 Aug 2004 09:18:25 -0400 Received: from sverresborg.uninett.no (sverresborg.uninett.no [IPv6:2001:700:e000:0:204:75ff:fee4:423b]) by tyholt.uninett.no (8.12.10/8.12.10) with ESMTP id i7CDAY2M016961; Thu, 12 Aug 2004 15:10:34 +0200 Received: (from venaas@localhost) by sverresborg.uninett.no (8.12.8/8.12.8/Submit) id i7CDAYUx009117; Thu, 12 Aug 2004 15:10:34 +0200 X-Authentication-Warning: sverresborg.uninett.no: venaas set sender to Stig.Venaas@uninett.no using -f Date: Thu, 12 Aug 2004 15:10:34 +0200 From: Stig Venaas To: Bernie Volz Subject: Re: [dhcwg] comments on draft-ietf-dhc-lifetime-01.txt Message-ID: <20040812131034.GI8177@sverresborg.uninett.no> References: <200408120831.02326.jdq@lucent.com> <002601c48069$f73b3330$6401a8c0@amer.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <002601c48069$f73b3330$6401a8c0@amer.cisco.com> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: dhcwg@ietf.org, tjc@ecs.soton.ac.uk, jdq@lucent.com X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org On Thu, Aug 12, 2004 at 08:43:27AM -0400, Bernie Volz wrote: > If a server sets the T1/T2 times to infinity, it gets what it asked for - > the configuration is static FOREVER. This is one reason it would be an > extremely bad idea to ever use these values. We added them for clarity in > the RFC, though never really figured they would be used in practice. > > The no address issue is an interested one. > > On a SOLICIT, the server is ONLY to return the Status Message response with > NoAddrAvail status. It is *NOT* supposed to return any configuration > information!!! > > Though it is always possible that a subsequent REQUEST or RENEW/REBIND would > result in no addresses. However, in those cases the IA_NA is still returned > with T1 and T2 times and those would, IMHO, apply. (In these cases, the > NoAddrAvail status is embedded *INSIDE* the IA_* options so these options > are still returned.) > > I suppose there is the case when a SOLICIT/REQUEST/RENEW/REBIND for an IA_NA > and IA_TA results in no addresses for a IA_NA and one or more addresses for > a IA_TA, in which case no T1/T2 times are provided - thought the IA_TA does > have lifetimes. > > But, all of this gets very messy fairly quickly. > > So, perhaps the easiest thing to do is to *ALWAYS* allow the LIFETIME option > - for stateful and stateless. A client *SHOULD* renew (etc) its information > whenver the shortest time expires - LIFETIME, T1, or lifetime on an address > (and the client needs a replacement address). If the client is stateful, is > uses RENEW (whether the client includes on or more IA_NAs if no T1 time has > expired is a matter of local policy - though it would seem reasonable for me > if it did since there's no harm in doing so). If a client is stateless, it > uses INFORMATION-REQUEST. > > This also makes server implementations easier since the T1/T2 times and > "other-configuration-parameters" lifetime can be configured independently > and a server need not assure that no T1 time is greater than > "other-configuration-parameters". This is more in line with my original idea for lifetime. I've started improving the draft, and I now have these paragraphs: The lifetime option specifies a lifetime for all configuration data contained in other options in an advertise or reply message that have no associated lifetime. If any of the options have an associated lifetime of their own which is shorter than the lifetime option value, then that should take precedence. Or in other words, the lifetime option specifies an upper bound for how long the client should wait before attempting to renew the data. If there are options with a shorter lifetime or the client has other reasons for requesting data from the DHCP server, then it should also update the data covered by the lifetime option. I think this should pretty much cover what you say and is in line with my own thinking. After that I have the paragraph: The lifetime option is mainly intended for Stateless DHCP service as specified in [RFC 3736]. If the client receives IA Address options containing lifetimes, the lifetime option should be ignored. The client should get updated configuration data from the server when it renews the addresses. Personally I'm happy to remove that again. I guess we should try to come to some consensus before I do more writing. Stig _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Thu Aug 12 10:13:05 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03833; Thu, 12 Aug 2004 10:13:04 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvG6R-0004hq-Gz; Thu, 12 Aug 2004 09:58:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvG1b-0003RQ-Pp for dhcwg@megatron.ietf.org; Thu, 12 Aug 2004 09:53:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02233 for ; Thu, 12 Aug 2004 09:53:46 -0400 (EDT) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BvG6T-0004LY-1r for dhcwg@ietf.org; Thu, 12 Aug 2004 09:58:56 -0400 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 12 Aug 2004 06:54:49 -0700 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id i7CDr3pp012878; Thu, 12 Aug 2004 06:53:04 -0700 (PDT) Received: from volzw2k ([161.44.65.208]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AKU34874; Thu, 12 Aug 2004 09:53:02 -0400 (EDT) From: "Bernie Volz" To: "'Stig Venaas'" Subject: RE: [dhcwg] comments on draft-ietf-dhc-lifetime-01.txt Date: Thu, 12 Aug 2004 09:53:01 -0400 Organization: Cisco Message-ID: <000001c48073$af492fa0$d0412ca1@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.5709 In-Reply-To: <20040812131034.GI8177@sverresborg.uninett.no> X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4939.300 Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org, tjc@ecs.soton.ac.uk, jdq@lucent.com X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 7bit I do think you should remove that last paragraph: > The lifetime option is mainly intended for Stateless DHCP service as > specified in [RFC 3736]. If the client receives IA Address options > containing lifetimes, the lifetime option should be ignored. The > client should get updated configuration data from the server when it > renews the addresses. It confuses the issue. Perhaps something like: The primary motivation for the lifetime option is for situations where no lifetime (or renewal time) is communicated to the client, such as for Stateless DHCP service as specified in [RFC 3736]. However, it applies to both stateful and stateless DHCP clients and is an upper bound for when a client should initiate renewal of at least its non-address based configuration parameters - a stateful client MAY renew its addresses at the same time and SHOULD always get updated configuration data from the server when it renews any addresses. One difference between Stateful and Stateless clients with regards to this option is that a Stateful client that does not receive this option MUST NOT apply the default lifetime. - Bernie > -----Original Message----- > From: Stig Venaas [mailto:Stig.Venaas@uninett.no] > Sent: Thursday, August 12, 2004 9:11 AM > To: Bernie Volz > Cc: jdq@lucent.com; 'JINMEI Tatuya / ?$B?@L@C#:H'; > dhcwg@ietf.org; tjc@ecs.soton.ac.uk > Subject: Re: [dhcwg] comments on draft-ietf-dhc-lifetime-01.txt > > > On Thu, Aug 12, 2004 at 08:43:27AM -0400, Bernie Volz wrote: > > If a server sets the T1/T2 times to infinity, it gets what it asked > > for - the configuration is static FOREVER. This is one > reason it would > > be an extremely bad idea to ever use these values. We added > them for > > clarity in the RFC, though never really figured they would > be used in > > practice. > > > > The no address issue is an interested one. > > > > On a SOLICIT, the server is ONLY to return the Status > Message response > > with NoAddrAvail status. It is *NOT* supposed to return any > > configuration information!!! > > > > Though it is always possible that a subsequent REQUEST or > RENEW/REBIND > > would result in no addresses. However, in those cases the IA_NA is > > still returned with T1 and T2 times and those would, IMHO, > apply. (In > > these cases, the NoAddrAvail status is embedded *INSIDE* the IA_* > > options so these options are still returned.) > > > > I suppose there is the case when a > SOLICIT/REQUEST/RENEW/REBIND for an > > IA_NA and IA_TA results in no addresses for a IA_NA and one or more > > addresses for a IA_TA, in which case no T1/T2 times are provided - > > thought the IA_TA does have lifetimes. > > > > But, all of this gets very messy fairly quickly. > > > > So, perhaps the easiest thing to do is to *ALWAYS* allow > the LIFETIME > > option > > - for stateful and stateless. A client *SHOULD* renew (etc) > its information > > whenver the shortest time expires - LIFETIME, T1, or > lifetime on an address > > (and the client needs a replacement address). If the client > is stateful, is > > uses RENEW (whether the client includes on or more IA_NAs > if no T1 time has > > expired is a matter of local policy - though it would seem > reasonable for me > > if it did since there's no harm in doing so). If a client > is stateless, it > > uses INFORMATION-REQUEST. > > > > This also makes server implementations easier since the T1/T2 times > > and "other-configuration-parameters" lifetime can be configured > > independently and a server need not assure that no T1 time > is greater > > than "other-configuration-parameters". > > This is more in line with my original idea for lifetime. I've > started improving the draft, and I now have these paragraphs: > > The lifetime option specifies a lifetime for all configuration data > contained in other options in an advertise or reply > message that have > no associated lifetime. If any of the options have an associated > lifetime of their own which is shorter than the lifetime > option value, > then that should take precedence. > > Or in other words, the lifetime option specifies an upper bound for > how long the client should wait before attempting to renew > the data. > If there are options with a shorter lifetime or the client > has other > reasons for requesting data from the DHCP server, then it > should also > update the data covered by the lifetime option. > > I think this should pretty much cover what you say and is in > line with my own thinking. > > After that I have the paragraph: > > The lifetime option is mainly intended for Stateless DHCP > service as > specified in [RFC 3736]. If the client receives IA Address options > containing lifetimes, the lifetime option should be ignored. The > client should get updated configuration data from the > server when it > renews the addresses. > > Personally I'm happy to remove that again. I guess we should > try to come to some consensus before I do more writing. > > Stig > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Thu Aug 12 10:38:51 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05873; Thu, 12 Aug 2004 10:38:51 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvGbs-0000Ny-61; Thu, 12 Aug 2004 10:31:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvGYQ-00085L-86 for dhcwg@megatron.ietf.org; Thu, 12 Aug 2004 10:27:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05231 for ; Thu, 12 Aug 2004 10:27:40 -0400 (EDT) Received: from ihemail1.lucent.com ([192.11.222.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BvGdN-0004va-Cz for dhcwg@ietf.org; Thu, 12 Aug 2004 10:32:50 -0400 Received: from homail.ho.lucent.com (h135-17-192-10.lucent.com [135.17.192.10]) by ihemail1.lucent.com (8.12.11/8.12.11) with ESMTP id i7CEOLLG006713; Thu, 12 Aug 2004 09:24:21 -0500 (CDT) Received: from kraken.mh.lucent.com by homail.ho.lucent.com (8.11.7+Sun/EMS-1.5 sol2) id i7CEOKx03603; Thu, 12 Aug 2004 10:24:20 -0400 (EDT) From: Joe Quanaim To: "Bernie Volz" , "'Stig Venaas'" Subject: Re: [dhcwg] comments on draft-ietf-dhc-lifetime-01.txt Date: Thu, 12 Aug 2004 10:18:57 -0400 User-Agent: KMail/1.5.4 References: <000001c48073$af492fa0$d0412ca1@amer.cisco.com> In-Reply-To: <000001c48073$af492fa0$d0412ca1@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200408121018.57077.jdq@lucent.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org, tjc@ecs.soton.ac.uk X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jdq@lucent.com List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 7bit Bernie Volz wrote: > I do think you should remove that last paragraph: > > > The lifetime option is mainly intended for Stateless DHCP service as > > specified in [RFC 3736]. If the client receives IA Address options > > containing lifetimes, the lifetime option should be ignored. The > > client should get updated configuration data from the server when it > > renews the addresses. I would prefer leaving the paragraph. > It confuses the issue. > > Perhaps something like: > > The primary motivation for the lifetime option is for situations where > no lifetime (or renewal time) is communicated to the client, such as for > Stateless DHCP service as specified in [RFC 3736]. However, it applies > to both stateful and stateless DHCP clients and is an upper bound for > when a client should initiate renewal of at least its non-address based > configuration parameters - a stateful client MAY renew its addresses at > the same time and SHOULD always get updated configuration data from the > server when it renews any addresses. > > One difference between Stateful and Stateless clients with regards > to this option is that a Stateful client that does not receive this > option MUST NOT apply the default lifetime. > As noted, the motivation of the lifetime option is to ensure stateless clients receive current configuration information. As such, I think keeping it out of stateful configuration is the simplest approach. As we have discussed, stateful configuration already has several variables to manipulate client behavior. I do not see much gain in adding another. Still, it's not that complex a change. If I am outvoted, so be it. Joe Quanaim. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Thu Aug 12 12:00:07 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10612; Thu, 12 Aug 2004 12:00:07 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvHwO-0003H9-Le; Thu, 12 Aug 2004 11:56:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvHrZ-0002HQ-2j for dhcwg@megatron.ietf.org; Thu, 12 Aug 2004 11:51:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10276 for ; Thu, 12 Aug 2004 11:51:30 -0400 (EDT) Received: from kaboom.isc.org ([204.152.187.72]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BvHwX-0006Td-CW for dhcwg@ietf.org; Thu, 12 Aug 2004 11:56:42 -0400 Received: by kaboom.isc.org (Postfix, from userid 10200) id 4ABEAB241F; Thu, 12 Aug 2004 08:51:00 -0700 (PDT) Date: Thu, 12 Aug 2004 08:51:00 -0700 From: "David W. Hankins" To: dhcwg@ietf.org Subject: Re: [dhcwg] Comments on draft-ietf-dhc-3315id-for-v4-03 Message-ID: <20040812155100.GA38172@isc.org> References: <20040810224111.GA722@isc.org> <002201c47fee$47009120$d0412ca1@amer.cisco.com> <20040811224350.GJ746@isc.org> Mime-Version: 1.0 In-Reply-To: User-Agent: Mutt/1.4.2.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: rbhibbs@pacbell.net X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0572279068==" Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org --===============0572279068== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="huq684BweRXVnRxX" Content-Disposition: inline --huq684BweRXVnRxX Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Aug 11, 2004 at 06:34:13PM -0700, Ted Lemon wrote: > different IP addresses. There is no harm in this, unless you are=20 > concerned about excessive IP address consumption. If you are=20 I'm really confused by this statement, because I thought I documented the harm. Go back and read what I said about Win XPe please? I never answerd your other mail because your recommendations about alternative actions equally surprised me...they won't work. You also seem fixated upon having the PXE client send 'a different client identifier' when in fact the problem is that it doesn't send that option at all, and the problem would be made worse if it ever did. So there's quite a lot of confusion floating around already. To briefly restate, an undocumented behaviour which fixes this problem without user intervention or new PXE clients has arisen in the majority of DHCP servers. At least one client has arisen (Win XPe) that relies upon this behaviour in order to boot...at all. So it is no longer about over-consumption of addresses. That issue, and the way that those servers choose to solve it for their paying customers, is what has led us now to this impasse. > concerned about that, there are stopgap solutions to get you over the=20 > hump until the last of those PXE cards dies a well-deserved death. That will not happen. I don't think that any iteration of 'dumb bootstrap device' will ever learn anything more complicated than it absolutely has to, for darn good reasons. And I really doubt that Microsoft will ever make something like a client identifier a user-configurable option (like Apple does). --=20 David W. Hankins "If you don't do it right the first time, Operations Engineer you'll just have to do it again." Internet Systems Consortium, Inc. -- Jack T. Hankins --huq684BweRXVnRxX Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (FreeBSD) iD8DBQFBG5HjcXeLeWu2vmoRAsiRAJ9fO1vsmTDNfPbQkUf+J1lwiOcveQCfTo18 6cfvga8EMC7WTMr/il43U5s= =LHbN -----END PGP SIGNATURE----- --huq684BweRXVnRxX-- --===============0572279068== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --===============0572279068==-- From dhcwg-bounces@ietf.org Thu Aug 12 12:32:57 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13122; Thu, 12 Aug 2004 12:32:57 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvINq-0001Tm-2W; Thu, 12 Aug 2004 12:24:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvICA-0006Y0-QY for dhcwg@megatron.ietf.org; Thu, 12 Aug 2004 12:12:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11365 for ; Thu, 12 Aug 2004 12:12:48 -0400 (EDT) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BvIH7-0006qh-76 for dhcwg@ietf.org; Thu, 12 Aug 2004 12:18:00 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 12 Aug 2004 12:21:12 -0400 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i7CGCDCf003681; Thu, 12 Aug 2004 12:12:13 -0400 (EDT) Received: from volzw2k ([161.44.65.208]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AKU47032; Thu, 12 Aug 2004 12:12:12 -0400 (EDT) From: "Bernie Volz" To: , "'Stig Venaas'" Subject: RE: [dhcwg] comments on draft-ietf-dhc-lifetime-01.txt Date: Thu, 12 Aug 2004 12:12:12 -0400 Organization: Cisco Message-ID: <002a01c48087$20483580$d0412ca1@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.5709 In-Reply-To: <200408121018.57077.jdq@lucent.com> X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4939.300 Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b Content-Transfer-Encoding: quoted-printable Cc: dhcwg@ietf.org, tjc@ecs.soton.ac.uk X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: quoted-printable My impression is that people want it for stateful as well - or at least = not to restrict it from being used there. I was where you are - keeping it for stateless only. But there are some = edge cases where stateful clients might not receive any times or might = receive extremely long times (though I think these are really exceptional = cases). I also think it is easier configuration wise to just allow an = administrator on a server to configure this option and not have code in the server not = to send this for a stateful REPLY (or on a client to ignore it). Though I = guess we could place the responsibility on the client not to include it in the = ORO when stateful. So, I've changed my mind - allow it for stateful as well. BTW, shouldn't we improve the langauge in the draft regarding the ORO? = It is currently: 3.1. Client behaviour A client supporting this option MAY include it in the Option Request Option (ORO) when sending messages to the DHCP server that allows ORO to be included. I would suggest we change it to: 3.1. Client behaviour A client supporting this option MUST include it in the Option Request Option (ORO) when sending SOLICIT, REQUEST, RENEW, REBIND, and INFORMATION-REQUEST messages to the DHCP server. If the consenus is to keep this for stateless only, then it would read: 3.1. Client behaviour A client supporting this option MUST include it in the Option Request Option (ORO) when sending INFORMATION-REQUEST messages to the DHCP server. A client MUST NOT include this option in an ORO option in any other messages. - Bernie > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org]=20 > On Behalf Of Joe Quanaim > Sent: Thursday, August 12, 2004 10:19 AM > To: Bernie Volz; 'Stig Venaas' > Cc: dhcwg@ietf.org; tjc@ecs.soton.ac.uk > Subject: Re: [dhcwg] comments on draft-ietf-dhc-lifetime-01.txt >=20 >=20 > Bernie Volz wrote: > > I do think you should remove that last paragraph: > > > > > The lifetime option is mainly intended for Stateless=20 > DHCP service as > > > specified in [RFC 3736]. If the client receives IA=20 > Address options > > > containing lifetimes, the lifetime option should be=20 > ignored. The > > > client should get updated configuration data from the=20 > server when it > > > renews the addresses. >=20 > I would prefer leaving the paragraph. >=20 > > It confuses the issue. > > > > Perhaps something like: > > > > The primary motivation for the lifetime option is for=20 > situations where > > no lifetime (or renewal time) is communicated to the=20 > client, such as for > > Stateless DHCP service as specified in [RFC 3736].=20 > However, it applies > > to both stateful and stateless DHCP clients and is an=20 > upper bound for > > when a client should initiate renewal of at least its=20 > non-address based > > configuration parameters - a stateful client MAY renew=20 > its addresses at > > the same time and SHOULD always get updated configuration=20 > data from the > > server when it renews any addresses. > > > > One difference between Stateful and Stateless clients with regards > > to this option is that a Stateful client that does not=20 > receive this > > option MUST NOT apply the default lifetime. > > >=20 > As noted, the motivation of the lifetime option is to ensure=20 > stateless clients=20 > receive current configuration information. As such, I think=20 > keeping it out=20 > of stateful configuration is the simplest approach. As we=20 > have discussed,=20 > stateful configuration already has several variables to=20 > manipulate client=20 > behavior. I do not see much gain in adding another. >=20 > Still, it's not that complex a change. If I am outvoted, so be it. >=20 > Joe Quanaim. >=20 >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg >=20 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Thu Aug 12 12:36:32 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13402; Thu, 12 Aug 2004 12:36:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvINr-0001Ux-FS; Thu, 12 Aug 2004 12:24:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvIDe-00074h-G2 for dhcwg@megatron.ietf.org; Thu, 12 Aug 2004 12:14:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11466 for ; Thu, 12 Aug 2004 12:14:20 -0400 (EDT) Received: from kaboom.isc.org ([204.152.187.72]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BvIId-0006sd-1o for dhcwg@ietf.org; Thu, 12 Aug 2004 12:19:32 -0400 Received: by kaboom.isc.org (Postfix, from userid 10200) id 3FE25B241F; Thu, 12 Aug 2004 09:13:50 -0700 (PDT) Date: Thu, 12 Aug 2004 09:13:50 -0700 From: "David W. Hankins" To: dhcwg@ietf.org Subject: Re: [dhcwg] Comments on draft-ietf-dhc-3315id-for-v4-03 Message-ID: <20040812161350.GB38172@isc.org> References: <20040811224350.GJ746@isc.org> <001701c48015$49540c50$6401a8c0@amer.cisco.com> Mime-Version: 1.0 In-Reply-To: <001701c48015$49540c50$6401a8c0@amer.cisco.com> User-Agent: Mutt/1.4.2.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: rbhibbs@pacbell.net X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0399846592==" Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org --===============0399846592== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="XOIedfhf+7KOe/yw" Content-Disposition: inline --XOIedfhf+7KOe/yw Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Aug 11, 2004 at 10:37:18PM -0400, Bernie Volz wrote: > Perhaps I'm not understanding the issue fully, but isn't this a > problem if a client first sends NO client identifier (to boot) > and then (once the O/S is running) sends a client identifier? Yes, precisely. > IMHO, is a general problem whenever this switch from no-client > identifier to client identifier happens. So, it is a general > DHCP issue not really specific to 3315id. I understand now, thanks Bernie. --=20 David W. Hankins "If you don't do it right the first time, Operations Engineer you'll just have to do it again." Internet Systems Consortium, Inc. -- Jack T. Hankins --XOIedfhf+7KOe/yw Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (FreeBSD) iD8DBQFBG5c9cXeLeWu2vmoRAicsAJ4mg1EXRp3+1V/JpZzXjz6x4YefdgCgpSo4 AY5a2U5ADN9cUesMiotF+p8= =+xRi -----END PGP SIGNATURE----- --XOIedfhf+7KOe/yw-- --===============0399846592== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --===============0399846592==-- From dhcwg-bounces@ietf.org Thu Aug 12 12:38:31 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13622; Thu, 12 Aug 2004 12:38:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvIQT-0001xC-U9; Thu, 12 Aug 2004 12:27:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvII2-0000EP-Du for dhcwg@megatron.ietf.org; Thu, 12 Aug 2004 12:18:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12019 for ; Thu, 12 Aug 2004 12:18:51 -0400 (EDT) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BvIN0-00070i-Op for dhcwg@ietf.org; Thu, 12 Aug 2004 12:24:04 -0400 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i7CGGtCN021593; Thu, 12 Aug 2004 09:17:01 -0700 (PDT) Received: from volzw2k ([161.44.65.208]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AKU47393; Thu, 12 Aug 2004 12:16:59 -0400 (EDT) From: "Bernie Volz" To: "'David W. Hankins'" , Subject: RE: [dhcwg] Comments on draft-ietf-dhc-3315id-for-v4-03 Date: Thu, 12 Aug 2004 12:16:59 -0400 Organization: Cisco Message-ID: <002b01c48087$cba0f480$d0412ca1@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.5709 In-Reply-To: <20040812155100.GA38172@isc.org> X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4939.300 Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Content-Transfer-Encoding: 7bit Cc: rbhibbs@pacbell.net X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 7bit > And I really doubt that > Microsoft will ever make something like a client identifier a > user-configurable option (like Apple does). Well, I don't know about Win XPe, but see http://support.microsoft.com/default.aspx?scid=kb;en-us;172408. - Bernie > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] > On Behalf Of David W. Hankins > Sent: Thursday, August 12, 2004 11:51 AM > To: dhcwg@ietf.org > Cc: rbhibbs@pacbell.net > Subject: Re: [dhcwg] Comments on draft-ietf-dhc-3315id-for-v4-03 > > > On Wed, Aug 11, 2004 at 06:34:13PM -0700, Ted Lemon wrote: > > different IP addresses. There is no harm in this, unless you are > > concerned about excessive IP address consumption. If you are > > I'm really confused by this statement, because I thought I > documented the harm. > > Go back and read what I said about Win XPe please? I never > answerd your other mail because your recommendations about > alternative actions equally surprised me...they won't work. > You also seem fixated upon having the PXE client send 'a > different client identifier' when in fact the problem is that > it doesn't send that option at all, and the problem would be > made worse if it ever did. > > So there's quite a lot of confusion floating around already. > > > To briefly restate, an undocumented behaviour which fixes > this problem without user intervention or new PXE clients has > arisen in the majority of DHCP servers. At least one client > has arisen (Win XPe) that relies upon this behaviour in order > to boot...at all. > > So it is no longer about over-consumption of addresses. That > issue, and the way that those servers choose to solve it for > their paying customers, is what has led us now to this impasse. > > > concerned about that, there are stopgap solutions to get > you over the > > hump until the last of those PXE cards dies a well-deserved death. > > That will not happen. > > I don't think that any iteration of 'dumb bootstrap device' > will ever learn anything more complicated than it absolutely > has to, for darn good reasons. And I really doubt that > Microsoft will ever make something like a client identifier a > user-configurable option (like Apple does). > > -- > David W. Hankins "If you don't do it right the > first time, > Operations Engineer you'll just have to do > it again." > Internet Systems Consortium, Inc. -- Jack T. Hankins > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Thu Aug 12 13:06:52 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15970; Thu, 12 Aug 2004 13:06:52 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvIhZ-00064O-0R; Thu, 12 Aug 2004 12:45:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvIXa-0003FI-Mk; Thu, 12 Aug 2004 12:34:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13244; Thu, 12 Aug 2004 12:34:56 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BvIcY-0007MH-Ug; Thu, 12 Aug 2004 12:40:08 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 12 Aug 2004 09:38:29 +0000 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i7CGY9jd025811; Thu, 12 Aug 2004 09:34:18 -0700 (PDT) Received: from volzw2k ([161.44.65.208]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AKU48815; Thu, 12 Aug 2004 12:34:08 -0400 (EDT) From: "Bernie Volz" To: "'Ralph Droms'" , Date: Thu, 12 Aug 2004 12:34:08 -0400 Organization: Cisco Message-ID: <002e01c4808a$30c86c60$d0412ca1@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.5709 In-Reply-To: <4.3.2.7.2.20040812092026.01feaa88@flask.cisco.com> X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4939.300 Importance: Normal X-Spam-Score: 0.4 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org Subject: [dhcwg] RE: Stateful != M , Stateless != O X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 7bit Seems to me that: If M is set(1), a client able to do stateful, does stateful (or full 3315) and ignores the O bit. This client can always fall back to stateless if it receives a NoAddrAvail status for a SOLICIT (as per 17.1.3) and receives no other ADVERTISEs it can use. Though this behavior isn't clearly spelled out in 3315 (either in 17.1.2 or 17.1.3) and may be something we want to consider in a future revision of 3315. Perhaps this behavior could even be controlled by the O bit - if the O bit is set, the client SHOULD try stateless (INFORMATION-REQUEST). If either M or O is set, a client able to do stateless (either full 3315 or 3736), does stateless. - Bernie > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On > Behalf Of Ralph Droms > Sent: Thursday, August 12, 2004 9:26 AM > To: ipv6@ietf.org > Subject: RE: Stateful != M , Stateless != O > > > Seems to me it would be useful to allow both M and O flag on. > > While, in theory, the support for the subset of DHCPv6 > indicated by the O bit is implied by the support for all of > DHCPv6 indicated by the M bit, it seems there would be little > harm in advertising both. > > Some hosts may choose to use both the Request message > exchange for address assignment and the Information-Request > message exchange for other information. For example, an > application may need other configuration information that was > not supplied during the initial Request message exchange, > requiring a subsequent Informaton-Request message exchange > for that information. There are DHCPv4 hosts that work this > way today. > > - Ralph > > At 12:32 PM 8/11/2004 -0400, Soliman Hesham wrote: > >I have a silly question below. > > > > > > > I now feel I get understanding the point...to make it > sure, > let > > me try > to rephrase that. > > > > > > Assume we have a "stateful" DHCPv6 server (that > implements RFC3315) > > > running. The server should support both > > > Solicit/Advertise/Request/Reply(/and Renew) and > > > Information-request/Reply exchanges. > > > > > > Then the administrator would send Router Advertisement with > > > the M flag > > > being ON and the O flag being OFF. (The O flag is OFF > since there is > > > no server that only supports RFC3736). > > > >=> Couldn't the admin turn on the O flag in this case too? > >The host doesn't know which RFC the server supports so > >I don't see what harm will be done if the O flag is turned on > >independently of the setting of the M flag. > > > > > Now consider a host that only implements (the client side > of) > > RFC3736, > configures global addresses via stateless address > > autoconfiguration > (assuming the RAs provide global prefixes for > > this), and wants to > configure recursive DNS server > addresses using > > RFC3736. However, > since the O flag is OFF in advertised > RAs, the > > host would not be able > to invoke the RFC3736 procedure and > > therefore cannot configure DNS > server addresses. This > should be a > > suboptimal scenario. > > > >=> Right, but there is no need to have the O flag off. To me > RFC 3736 > >is something useful for server vendors and should not be associated > >with setting the O flag. > > > >Hesham > > > >=========================================================== > >This email may contain confidential and privileged material for the > >sole use > > of the intended recipient. Any review or distribution by > others is strictly > > prohibited. If you are not the intended recipient please > contact the sender > > and delete all copies. > >=========================================================== > > > > > >-------------------------------------------------------------------- > >IETF IPv6 working group mailing list > >ipv6@ietf.org > >Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > >-------------------------------------------------------------------- > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Thu Aug 12 13:37:42 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18365; Thu, 12 Aug 2004 13:37:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvJT4-0000w6-DZ; Thu, 12 Aug 2004 13:34:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvJAH-000529-Fn for dhcwg@megatron.ietf.org; Thu, 12 Aug 2004 13:14:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16664 for ; Thu, 12 Aug 2004 13:14:54 -0400 (EDT) Received: from kaboom.isc.org ([204.152.187.72]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BvJFG-0008OR-Fs for dhcwg@ietf.org; Thu, 12 Aug 2004 13:20:07 -0400 Received: by kaboom.isc.org (Postfix, from userid 10200) id D8B24B241F; Thu, 12 Aug 2004 10:14:24 -0700 (PDT) Date: Thu, 12 Aug 2004 10:14:24 -0700 From: "David W. Hankins" To: dhcwg@ietf.org Subject: Re: [dhcwg] Comments on draft-ietf-dhc-3315id-for-v4-03 Message-ID: <20040812171424.GF38172@isc.org> References: <20040812155100.GA38172@isc.org> <002b01c48087$cba0f480$d0412ca1@amer.cisco.com> Mime-Version: 1.0 In-Reply-To: <002b01c48087$cba0f480$d0412ca1@amer.cisco.com> User-Agent: Mutt/1.4.2.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: rbhibbs@pacbell.net X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1249173619==" Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org --===============1249173619== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="9crTWz/Z+Zyzu20v" Content-Disposition: inline --9crTWz/Z+Zyzu20v Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Aug 12, 2004 at 12:16:59PM -0400, Bernie Volz wrote: > Well, I don't know about Win XPe, but see > http://support.microsoft.com/default.aspx?scid=3Dkb;en-us;172408. Sorry for not being clear, that's what I meant by "(like Apple does)". Anything that starts with "run regedit" doesn't count, since that does not pass the "Can you talk my Mom through doing it?" test. Faced with that exact problem, of talking people no more computer-savvy than an average person through doing it (no offence to average people), ISP's using our server software choose to hack the server code and *remove client id's entirely from packets they receive* rather than to talk customers through making their windows boxes stop sending client-id's to match their PXE instances. Which, obviously, is very painful to hear, and why I'm keen to see the more pallateable solution very clearly defined in rfc. --=20 David W. Hankins "If you don't do it right the first time, Operations Engineer you'll just have to do it again." Internet Systems Consortium, Inc. -- Jack T. Hankins --9crTWz/Z+Zyzu20v Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (FreeBSD) iD8DBQFBG6VwcXeLeWu2vmoRAhyjAKCjygkcYtMslVsTm9E/KU82zvus9ACeI5PX NM/O2T0pDqsnaM65Za3gZEI= =mnzN -----END PGP SIGNATURE----- --9crTWz/Z+Zyzu20v-- --===============1249173619== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --===============1249173619==-- From dhcwg-bounces@ietf.org Thu Aug 12 14:35:27 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21463; Thu, 12 Aug 2004 14:35:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvKLK-0003LR-NN; Thu, 12 Aug 2004 14:30:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvKJf-0002vo-UX for dhcwg@megatron.ietf.org; Thu, 12 Aug 2004 14:28:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21047 for ; Thu, 12 Aug 2004 14:28:42 -0400 (EDT) Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BvKOd-0001L2-JP for dhcwg@ietf.org; Thu, 12 Aug 2004 14:33:54 -0400 Received: from [10.0.2.3] (neubayern.net [66.93.162.100]) by toccata.fugue.com (Postfix) with ESMTP id 476501B209C; Thu, 12 Aug 2004 13:26:20 -0500 (CDT) In-Reply-To: <20040812171424.GF38172@isc.org> References: <20040812155100.GA38172@isc.org> <002b01c48087$cba0f480$d0412ca1@amer.cisco.com> <20040812171424.GF38172@isc.org> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <6BB45DB0-EC8D-11D8-A2F0-000A95D9C74C@nominum.com> Content-Transfer-Encoding: 7bit From: Ted Lemon Subject: Re: [dhcwg] Comments on draft-ietf-dhc-3315id-for-v4-03 Date: Thu, 12 Aug 2004 11:28:34 -0700 To: "David W. Hankins" X-Mailer: Apple Mail (2.618) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org, rbhibbs@pacbell.net X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 7bit On Aug 12, 2004, at 10:14 AM, David W. Hankins wrote: > ISP's using our server software choose to hack the server code and > *remove > client id's entirely from packets they receive* rather than to talk > customers through making their windows boxes stop sending client-id's > to > match their PXE instances. You have ISP customers that do PXE booting on behalf of customers? I am now deeply confused. As far as talking your mother through it, when would you ever want to talk your mother through setting up a diskless boot client? _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Thu Aug 12 18:18:06 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13090; Thu, 12 Aug 2004 18:18:06 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvNqF-0003SJ-Vu; Thu, 12 Aug 2004 18:14:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvNmq-0000zd-Ph for dhcwg@megatron.ietf.org; Thu, 12 Aug 2004 18:11:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12304 for ; Thu, 12 Aug 2004 18:10:59 -0400 (EDT) Received: from kaboom.isc.org ([204.152.187.72]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BvNrp-0007zC-U5 for dhcwg@ietf.org; Thu, 12 Aug 2004 18:16:15 -0400 Received: by kaboom.isc.org (Postfix, from userid 10200) id 0B70BB241F; Thu, 12 Aug 2004 15:10:25 -0700 (PDT) Date: Thu, 12 Aug 2004 15:10:24 -0700 From: "David W. Hankins" To: dhcwg@ietf.org Subject: Re: [dhcwg] Comments on draft-ietf-dhc-3315id-for-v4-03 Message-ID: <20040812221024.GH38172@isc.org> References: <20040812155100.GA38172@isc.org> <002b01c48087$cba0f480$d0412ca1@amer.cisco.com> <20040812171424.GF38172@isc.org> <6BB45DB0-EC8D-11D8-A2F0-000A95D9C74C@nominum.com> Mime-Version: 1.0 In-Reply-To: <6BB45DB0-EC8D-11D8-A2F0-000A95D9C74C@nominum.com> User-Agent: Mutt/1.4.2.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: rbhibbs@pacbell.net X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1876932648==" Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org --===============1876932648== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="B8ONY/mu/bqBak9m" Content-Disposition: inline --B8ONY/mu/bqBak9m Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Aug 12, 2004 at 11:28:34AM -0700, Ted Lemon wrote: > You have ISP customers that do PXE booting on behalf of customers? I=20 > am now deeply confused. I'm sorry, you have every right to be confused, my mind jumped here halfway through the conversation and I never made mention of this. I shouldn't have mentioned it, it's not important to this discussion. But it's an amusing story nonetheless. A lone geek at a small ISP trying to horn in on the broadband space. She has an arrangement with the last-mile supplier so that she gets DHCP relays installed in every customer-prem. She limits the number of leases to a fixed number per each relay-agent id suboption. Customers pay more for more leases. Now imagine that one of the two following cases starts happening. 1) A misconfigured boot-order, or a system with an unusual (not IDE, some kinda add-in card that maybe only gets tried in boot order because the 'boot other devices' option set to enabled in the bios) arrangement as a hard drive, results in having 'network' on its boot-order before the hard drive in question. PXE will try to boot, fail, then boot the system on the hard drive. This might be repeated for multiple network interfaces, if any, but hopefully the customer doesn't have them all plugged in. 2) A person with PXE clients at home has failed to segregate the broadcast domain of their broadband connection's set-top box with their pxe clients and the DHCP server they rely upon. The PXE client boots from the local dhcpd, then later from the ISP's, but her DHCP server still sends out OFFERs. Now imagine the lease limitation is full once the all the customer's systems are online. But the extra lease OFFERed to the PXE client means they are denied booting before all their systems are up. When I said "ISP's using our software", I should have just left it at "users of", since I don't actually know from where the patches came. I just know that they're out there, and people are using it (and being guided to use it)...it's just that this ISP thing latched into my memory at that moment and I wasn't exercising enough restraint at the keyboard. Sorry about that, common disease for me I'm afraid. > As far as talking your mother through it, > when would you ever want to talk your mother through setting up a > diskless boot client? I was specifically referring to 'setting and unsetting the client identifier' for reasons that are now hopefully somewhat less muddy. There are lines in the sand everywhere as to whose burden it is to bear support costs. So long as the answer is 'regedit', the burden of support is too great a cost for people to choose to bear. --=20 David W. Hankins "If you don't do it right the first time, Operations Engineer you'll just have to do it again." Internet Systems Consortium, Inc. -- Jack T. Hankins --B8ONY/mu/bqBak9m Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (FreeBSD) iD8DBQFBG+rQcXeLeWu2vmoRAt75AKCtWiuQQabuvjhIcrRQFjv3tLH+5ACfROqw Aqa3gCXOc1cfXdWNHFAoPvo= =+fn6 -----END PGP SIGNATURE----- --B8ONY/mu/bqBak9m-- --===============1876932648== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --===============1876932648==-- From dhcwg-bounces@ietf.org Thu Aug 12 18:53:58 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15249; Thu, 12 Aug 2004 18:53:58 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvOJt-0003JA-Eh; Thu, 12 Aug 2004 18:45:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvOHo-0002Oq-De for dhcwg@megatron.ietf.org; Thu, 12 Aug 2004 18:43:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14535 for ; Thu, 12 Aug 2004 18:43:01 -0400 (EDT) Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BvOMp-0008W4-Ux for dhcwg@ietf.org; Thu, 12 Aug 2004 18:48:17 -0400 Received: from [10.0.2.3] (neubayern.net [66.93.162.100]) by toccata.fugue.com (Postfix) with ESMTP id 646A41B24C1; Thu, 12 Aug 2004 17:40:40 -0500 (CDT) In-Reply-To: <20040812221024.GH38172@isc.org> References: <20040812155100.GA38172@isc.org> <002b01c48087$cba0f480$d0412ca1@amer.cisco.com> <20040812171424.GF38172@isc.org> <6BB45DB0-EC8D-11D8-A2F0-000A95D9C74C@nominum.com> <20040812221024.GH38172@isc.org> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Ted Lemon Subject: Re: [dhcwg] Comments on draft-ietf-dhc-3315id-for-v4-03 Date: Thu, 12 Aug 2004 15:42:55 -0700 To: "David W. Hankins" X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 7bit In the case of a PXE boot like the one you describe, the right answer for the ISP is to configure the DHCP server to put PXE clients in a special class, and not offer service to clients in that class. Then you don't have to worry about inappropriately responding to PXE clients that you can't actually configure. This is really the same problem as the well-known RAS server problem. One nice side effect of ignoring PXE clients is that since the boot now has to time out, the user will probably notice the incorrect boot order. This probably goes unnoticed with the current configuration because PXE probably gives up immediately when it gets a response with no PXE boot information in it. An additional advantage of PXE is that it gives up quickly, so you don't have to worry about endless DHCPDISCOVERs in your log files. My experience over the years is that when customers feel they need to hack the DHCP server sources, it's usually because they aren't aware that it's already possible to configure the server to address the problem they're having. I think this is true somewhat independently of the server implementation - it's certainly just as true of the Nominum DHCP server as it is of the ISC DHCP server, and I think it's also true of Cisco's DHCP server. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri Aug 13 07:38:48 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07629; Fri, 13 Aug 2004 07:38:48 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvaFN-0007ik-Fy; Fri, 13 Aug 2004 07:29:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvaCE-0007L0-BO; Fri, 13 Aug 2004 07:26:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07014; Fri, 13 Aug 2004 07:26:04 -0400 (EDT) Received: from mailout2.samsung.com ([203.254.224.25]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BvaHM-0004F2-Hy; Fri, 13 Aug 2004 07:31:25 -0400 Received: from custom-daemon.mailout2.samsung.com by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0I2D00F04UCUZ4@mailout2.samsung.com>; Fri, 13 Aug 2004 20:24:30 +0900 (KST) Received: from ep_mmp2 (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0I2D00GKHUCTST@mailout2.samsung.com>; Fri, 13 Aug 2004 20:24:29 +0900 (KST) Received: from SYAM ([107.108.71.123]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0I2D003UEUCLVC@mmp2.samsung.com>; Fri, 13 Aug 2004 20:24:29 +0900 (KST) Date: Fri, 13 Aug 2004 16:54:40 +0530 From: Syam Madanapalli To: Radhakrishnan Suryanarayanan , Tatuya / ???? JINMEI Message-id: <014b01c48128$226229b0$7b476c6b@sisodomain.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Mailer: Microsoft Outlook Express 6.00.2800.1409 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <005e01c47faf$a61058b0$7b476c6b@sisodomain.com> <411C4A29.5010200@eng.monash.edu.au> <06a001c480f4$b1314bf0$40476c6b@sisodomain.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7BIT Cc: Gregory Daley , dhcwg@ietf.org, ipv6@ietf.org, Pekka Savola , Soohong Daniel Park Subject: [dhcwg] Re: comments on draft-daniel-ipv6-ra-mo-flags-00.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 7BIT Hi Jinmei, > > I don't mind adding the appendix as long we just describe possible > issues (if any) and do NOT try to provide workaround like combining > router/parameters. That looks fine, we will just describe the issues and leave the implementation details to the developers. > > JINMEI, Tatuya > Communication Platform Lab. > Corporate R&D Center, Toshiba Corp. > jinmei@isl.rdc.toshiba.co.jp > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri Aug 13 08:27:56 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10997; Fri, 13 Aug 2004 08:27:56 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bvb2V-0008PI-80; Fri, 13 Aug 2004 08:20:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvarR-0006aa-Fj for dhcwg@megatron.ietf.org; Fri, 13 Aug 2004 08:08:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10113 for ; Fri, 13 Aug 2004 08:08:40 -0400 (EDT) Received: from tyholt.uninett.no ([158.38.60.10]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bvawb-0005HK-ED for dhcwg@ietf.org; Fri, 13 Aug 2004 08:14:01 -0400 Received: from sverresborg.uninett.no (sverresborg.uninett.no [IPv6:2001:700:e000:0:204:75ff:fee4:423b]) by tyholt.uninett.no (8.12.10/8.12.10) with ESMTP id i7DC882M023105; Fri, 13 Aug 2004 14:08:08 +0200 Received: (from venaas@localhost) by sverresborg.uninett.no (8.12.8/8.12.8/Submit) id i7DC87Mx012667; Fri, 13 Aug 2004 14:08:07 +0200 X-Authentication-Warning: sverresborg.uninett.no: venaas set sender to Stig.Venaas@uninett.no using -f Date: Fri, 13 Aug 2004 14:08:07 +0200 From: Stig Venaas To: Ted Lemon Subject: Re: [dhcwg] RE: mboned: draft-jdurand-assign-addr-ipv6-multicast-dhcpv6-00 comments Message-ID: <20040813120807.GA12587@sverresborg.uninett.no> References: <56D748BC-E63B-11D8-8860-000A95D9C74C@nominum.com> <20040810110500.GB2802@sverresborg.uninett.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: dhcwg@ietf.org, mboned@lists.uoregon.edu X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org On Tue, Aug 10, 2004 at 09:45:36AM -0700, Ted Lemon wrote: > Stig, maybe you can explain for me how it is less complicated to supply > multicast prefixes than it is to do stateful allocation - I don't get > it. With multicast prefixes, the client either has to take its OK, I'll try. > chances with the possibility of a collision, which seems quite likely > (random number generators are usually deterministic, not random, and > getting one that uses any real source of entropy is difficult, not > easy), or it has to do some kind of duplicate address detection, which > also seems difficult, not easy. I don't have a clue what the likelihood is. But just to make it clear, we're talking of a 32-bit number. So question is how likely is it for two hosts/applications on the same link to pick the same 32-bit value. I agree that some form of DAD could be needed, and I agree it's not easy. I've been wondering slightly if the DAD in Neighbor Discovery could be reused, but anyway, it's a big complication, I agree. > In contrast, while stateful address allocation requires slightly more > work on the server side (in the sense that the server has to remember > which address it allocated), it's much easier on the client side - the > client gets a specific address, doesn't need a good RNG, and doesn't > need to do multicast DAD. The additional complexity of remembering > which IP address we gave to the client is well-understood technology, > requiring no innovations and risking no accidental DoS attacks from > broken clients. The stateful approach introduces some other complexity on the client that I'm concerned about. The main issue, is that it's the application that needs the addresses. You need some additional infrastructure/middleware on the host. Either the application needs to act as DHCP client (there are big issues with that) or the application needs some standardized way of communicating with the DHCP client. Basically the application will need to signal to the DHCP client that it needs an address, and that must be returned back to the client. Also, while the application is running, the DHCP client must renew the address on behalf of the application. I've been trying to think through how to actually implement this, and it's not easy. I must say though, that coming up with a general solution to how applications can interact with DHCP might be interesting. If we instead used the stateless prefix announcement solution we may need to solve the DAD issue, but there are some advantages. o For link-local multicast, it would be possible to generate link unique multicast addresses with no need for DHCP servers or routers. o For unicast-prefix-based addressing (RFC 3306) you can generate a /96 multicast prefix from the links unicast /64 prefix and then using RNG plus possibly DAD you can come up with prefixes to use on the link. This can be done without DHCP. o For Embedded-RP the application will need to learn the prefix from somewhere. But the system could learn the prefix once (from DHCP, from config file or whatever) and all the applications use the same. You can perhaps compare it to how applications use resolv.conf on unix and how it might be configured from DHCP or other systems. > History suggests that DHCP server implementations are more likely to be > correct than DHCP client implementations, perhaps because there is less > risk of monoculture in the interoperability testing done by a DHCP > server vendor than by a DHCP client vendor (a client vendor will > typically test against a single server, whereas a server vendor will > typically have many different clients to test against). Right > So if it makes sense to do something like this, I would vote for doing > it in a stateful manner, not a stateless manner. I think something like this is needed. Currently I'm in favour of stateless, but I'm trying to explore both possibilities. I'm not sure myself which one is superior. Stig _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri Aug 13 19:57:33 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26491; Fri, 13 Aug 2004 19:57:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bvlt6-0001hp-PU; Fri, 13 Aug 2004 19:55:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bvlsa-0001Z8-Un for dhcwg@megatron.ietf.org; Fri, 13 Aug 2004 19:54:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26351 for ; Fri, 13 Aug 2004 19:54:35 -0400 (EDT) Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bvlxq-0001y1-GR for dhcwg@ietf.org; Fri, 13 Aug 2004 20:00:03 -0400 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.196); Fri, 13 Aug 2004 16:52:07 -0700 Received: from RED-IMC-04.redmond.corp.microsoft.com ([157.54.2.168]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 13 Aug 2004 16:53:07 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by RED-IMC-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 13 Aug 2004 16:54:01 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Fri, 13 Aug 2004 16:53:12 -0700 x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [dhcwg] RE: mboned:draft-jdurand-assign-addr-ipv6-multicast-dhcpv6-00 comments Date: Fri, 13 Aug 2004 16:54:02 -0700 Message-ID: Thread-Topic: [dhcwg] RE: mboned:draft-jdurand-assign-addr-ipv6-multicast-dhcpv6-00 comments thread-index: AcSBNTNNMNEeczIYREih2wEeuolyngAWnZlQ From: "Dave Thaler" To: "Stig Venaas" , "Ted Lemon" X-OriginalArrivalTime: 13 Aug 2004 23:53:12.0653 (UTC) FILETIME=[B18147D0:01C48190] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: quoted-printable Cc: dhcwg@ietf.org, mboned@lists.uoregon.edu X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Stig Venaas writes: > If we instead used the stateless prefix announcement solution we may > need to solve the DAD issue, but there are some advantages. >=20 > o For link-local multicast, it would be possible to generate link > unique multicast addresses with no need for DHCP servers or routers. Right. This is what=20 http://www.ietf.org/internet-drafts/draft-ietf-ipv6-link-scoped-mcast-04 .txt does. > o For unicast-prefix-based addressing (RFC 3306) you can generate a > /96 multicast prefix from the links unicast /64 prefix and then > using RNG plus possibly DAD you can come up with prefixes to use on > the link. This can be done without DHCP. Right. > o For Embedded-RP the application will need to learn the prefix from > somewhere. But the system could learn the prefix once (from DHCP, > from config file or whatever) and all the applications use the same. > You can perhaps compare it to how applications use resolv.conf on > unix and how it might be configured from DHCP or other systems. And you need a DAD mechanism for address selection within the prefix, as with 3306 addresses. -Dave _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From nv33134@yahoo.com Mon Aug 16 04:29:09 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17447; Mon, 16 Aug 2004 04:29:09 -0400 (EDT) Date: Mon, 16 Aug 2004 04:29:09 -0400 (EDT) Message-Id: <200408160829.EAA17447@ietf.org> Received: from [218.27.119.138] (helo=ietf.org ident=squid) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1Bwcwt-0004Rx-Jy; Mon, 16 Aug 2004 04:35:08 -0400 Reply-To: "Atualidade Brasileira" From: "Atualidade Brasileira" To: AmigosAtualidadeBrasileira@ietf.org Subject: Assistência social e capitalismo: abraço da paz! X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 MIME-Version: 1.0 Content-Type: text/html X-Spam-Score: 32.3 (++++++++++++++++++++++++++++++++) X-Spam-Flag: YES X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 c0408lind10CapMail

EnCastellano -- FreeAutomaticTranslator

Bom dia, amigos! Assistência social e capitalismo, inimigos ou aliados? Um tema sem dúvida polêmico, abordado por Adolpho Lindenberg. Para enviar sua valiosa opinião, participando de nosso debate, veja os links no final. Atenciosamente, Sergio Lopes, ConstruNews.

Série Temas Patrulhados (10)

Assistência Social e Capitalismo não precisam estar em guerra: podem dar o abraço da paz

A concorrência e a procura do lucro, se contrapõem aos atos caritativos, à justiça social e à benquerença entre os homens? É essa a temática abordada por Adolpho Lindenberg em artigo da Série Temas Patrulhados

A procura do lucro, se contrapõe aos atos caritativos?

* Quando os "progressistas", sempre dispostos a satanizar o sistema de propriedade e livre iniciativa, acusam o capitalismo de ser um sistema baseado no egoísmo e na voracidade do lucro, desinteressado pela sorte dos carentes, vem à mente a figura do banqueiro ou executivo de multinacionais, aferrado aos balanços, mas surdo aos pedidos de socorro dos necessitados...

* Até que ponto este quadro é verdadeiro? A procura do lucro, as leis severas da concorrência, as transações financeiras rigorosas, se contrapõem aos atos caritativos, à justiça social e à benquerença entre os homens? É essa a temática abordada por Adolpho Lindenberg em recente artigo da Série Temas Patrulhados.

"Patrulhamento"

* Lindenberg é autor do livro "Os católicos e a economia de mercado", em que denuncia uma política com viés esquerdista que censura, marginaliza, "patrulha" ou encobre com um manto de silêncio as opiniões "politicamente incorretas", não afinadas com as ideologias de esquerda.

Ser solidário, tarefa do capitalista e não do capitalismo

* Para analisar o capitalismo com isenção de ânimo convém lembrar que a função específica de um sistema econômico é produzir riquezas; e com elas, gerar lucros, pagar salários e impostos. Nisso não existe demérito algum.

* A assistência social, tarefa indispensável numa sociedade bem organizada e próspera, não deve ser de responsabilidade dos produtores, enquanto produtores, mas enquanto homens compassivos ou cristãos, obedientes aos conselhos evangélicos de socorrer o próximo.

Distinguir entre produzir e distribuir

* Lindenberg acrescenta que é preciso distinguir entre o ato de produzir e o de distribuir. Não podem ser confundidos, são de natureza diversa, cada um deles obedece a princípios morais próprios. Mais precisamente, a ênfase é diferente. A ética dos homens, enquanto produtores e comerciantes, prescreve que eles sejam diligentes, temperantes, honestos e respeitosos dos direitos de seus clientes e competidores. Nisso, aliás, agem segundo o bem comum.

* Não procede, por conseguinte, a critica de que o capitalismo e solidariedade humana são incompatíveis, ambos podem se somar harmoniosamente!

* Para receber gratuitamente, por e-mail, o texto completo deste artigo, clique em:

EnviarEsteArtigoCompletoGratuitamente(No.10)

Outros temas abordados no artigo:

* "Progressistas" sempre dispostos a satanizar o capitalismo

* Magnanimidade versus prepotência

* A reta procura pelo lucro nada tem de pecaminoso

* Mais capitalismo, mais assistência social

* Ser solidário, tarefa do capitalista e não do capitalismo

* Distinguir entre produzir e distribuir

* Descristianização da sociedade, a grande causa da indiferença para com os pobres

* Solidariedade entre filhos do mesmo Deus

Links de opinião:

Gostaríamos muito de receber seu voto eletrônico sobre a temática abordada neste e-mail e, se possível, conhecer sua valiosa opinião (seguem 10 opções):

* Lindenberg:Discrepo - OpiniãoReacionária

* Lindenberg:Concordo - OpiniãoDeBomSenso -

* Lindenberg:EmTermos - PrecisoPensar

Links gratuitos (e-Book e outros artigos):

EnviarEsteArtigoCompletoGratuitamente(No.10)

Lindenberg:e-BookGratuitoBr (em formato Word, com 11 artigos de Lindenberg)

Lindenberg:IntroduçãoGratuitaDoLivro (em formato Word, Introdução do livro "Os católicos e a economia de mercado")

Lindenberg:ProximosArtigos

Outros links:

Lindenberg:DesejoAdquirirLivro (receberá instruções sobre como adquirir o livro no Brasil)

Remover (para ser retirado imediatamente de nosso Address Book).

A difusão desta mensagem, com uma finalidade cultural e com o intuito de promover um debate construtivo e respeitoso de idéias, é de exclusiva responsabilidade da ConstruNews. Telefone de contato: (11) 9252 - 7873

From dhcwg-bounces@ietf.org Mon Aug 16 08:31:13 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00445; Mon, 16 Aug 2004 08:31:13 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bwgbc-00074C-T2; Mon, 16 Aug 2004 08:28:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BwgPG-0005s1-Qp for dhcwg@megatron.ietf.org; Mon, 16 Aug 2004 08:16:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29746 for ; Mon, 16 Aug 2004 08:16:05 -0400 (EDT) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BwgV3-0000Ew-1Z for dhcwg@ietf.org; Mon, 16 Aug 2004 08:22:06 -0400 Received: from ocean.jinmei.org (unknown [3ffe:501:100f:1048:4164:cd3:c762:127d]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 4C30715263; Mon, 16 Aug 2004 21:15:57 +0900 (JST) Date: Mon, 16 Aug 2004 21:15:54 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Stig Venaas Subject: Re: [dhcwg] comments on draft-ietf-dhc-lifetime-01.txt In-Reply-To: <20040812093121.GB8177@sverresborg.uninett.no> References: <200408030929.31655.jdq@lucent.com> <000201c4797e$2a5f37e0$46828182@amer.cisco.com> <20040812093121.GB8177@sverresborg.uninett.no> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: dhcwg@ietf.org, tjc@ecs.soton.ac.uk, Bernie Volz , jdq@lucent.com X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org >>>>> On Thu, 12 Aug 2004 11:31:21 +0200, >>>>> Stig Venaas said: >> > I too would recommend that this option only be used with stateless >> > (Information-Request/Reply). It does not apply to stateful - in stateful, >> > even if there are no T1/T2 times (i.e., no IA_NA option), the client will >> > need to do something when it no longer has addresses so it will get new >> > information from the server. > I think stateless only might be too strict. > One example I have in mind is: > If a client sends a request message to obtain addresses and other config > options and it does not get any addresses but receives other config > data. Then the client may use those options and not make a > Request/Information-Request, right? A quick response for clarification: if you mean the case where the client receives an Advertise message containing a NoAddrsAvail status code, I don't think the client may use other configuration options (moreover, I don't think the client ever receives such configuration options in this case). RFC3315 is not so explicit in such a case, but it requires the client just to ignore such an Advertise message: The client MUST ignore any Advertise message that includes a Status Code option containing the value NoAddrsAvail, with the exception that the client MAY display the associated status message to the user. (Section 17.1.3) and the server to send minimum information to indicate the error: If the server will not assign any addresses to any IAs in a subsequent Request from the client, the server MUST send an Advertise message to the client that includes only a Status Code option with ^^^^ code NoAddrsAvail and a status message for the user, a Server Identifier option with the server's DUID, and a Client Identifier option with the client's DUID. (Section 17.2.2) Again, this is just for clarification, and may be irrelevant to the main point of this discussion. 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-bounces@ietf.org Mon Aug 16 14:56:55 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22319; Mon, 16 Aug 2004 14:56:55 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BwmUC-00084S-7b; Mon, 16 Aug 2004 14:45:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BwmNa-0006w2-Ob for dhcwg@megatron.ietf.org; Mon, 16 Aug 2004 14:38:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21153 for ; Mon, 16 Aug 2004 14:38:45 -0400 (EDT) Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BwmTQ-0006Yp-Bb for dhcwg@ietf.org; Mon, 16 Aug 2004 14:44:49 -0400 Received: from [81.200.65.118] (dhcp-118.wl.nominum.com [81.200.65.118]) by toccata.fugue.com (Postfix) with ESMTP id 207321B20E6; Mon, 16 Aug 2004 13:35:44 -0500 (CDT) In-Reply-To: <000d01c47f06$9dc56ff0$d0412ca1@amer.cisco.com> References: <000d01c47f06$9dc56ff0$d0412ca1@amer.cisco.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <7FD2BE8F-EFB3-11D8-9348-000A95D9C74C@nominum.com> Content-Transfer-Encoding: 7bit From: Ted Lemon Date: Mon, 16 Aug 2004 11:38:43 -0700 To: "Bernie Volz" X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org Subject: [dhcwg] Re: I-D: draft-volz-dhc-dhcpv6-fqdn-00.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 7bit Bernie, the problem I have with the complex model for the DHCPv6 FQDN option is that I can't imagine any of the scenarios you describe ever having a meaning in practice. A computer is a computer. It has a name. One name. If you give it multiple names, that doesn't have any meaning, generally speaking. The exception is when you are configuring a single computer to present more than one identity on the network. In this case, it makes sense that each identity would have its own name. So I think it makes sense to have a one-to-one mapping between names and identity associations. I do not think it makes sense to break it down below this point. Let's consider some of the scenarios you've proposed. First, let's consider number four, which you say you consider most likely. In this case, the client has a single identity, and gets both a globally-scoped address and a locally-scoped address. So what does it make sense to do here? We have several options: 1. Publish the name with the global address. 2. Publish the name with both the global and site-local address. 3. Publish two names, one for the global address and one for the local address. So what's going to fail in case 1? Let's say some clients get site-local addresses, and some get global _and_ site-local addresses. If we only publish the global address, can a client with only a site-local address exchange packets with the client with the global address? I think it can, as long as they are both at the same site (which is the only case that matters). So I think that this solution works, and we don't need to do anything further. What fails in case 2? We've published a site-local address in a global namespace. If a host outside of the site wants to contact the host using the name, how does it know that the site-local address is not local? It doesn't. We can't control which address it tries to connect to, and many network clients do not try to connect to every address - they just try to connect to the first one, which DNS is required to alternate. So what we would get, from the perspective of a naive user, would be intermittent failures. Not good. What about case 3? Case 3 works, but now you have to tell people about two different names. Why would you want that, when one name will do? So I really think that case 1 is how you want to do things, and this is easy and matches the one name per IAID model very nicely. As far as whether temporary and public addresses are part of the same IA or not, why not let it be that if you want for some reason to publish your temporary address, the way you do it is under a separate IAID? Why add complexity when there's a way to do it that's less complex? If a site is multihomed and wants to use different names for different addresses, I'm skeptical that it's something we need to think about here and now. While it's true that this is a possible scenario, I think the complexity that addressing this problem adds to the current draft is unacceptable. I would like to see this problem actually happen in the real world, and have that drive a new standardization effort, rather than trying to guess how people are going to want to solve this problem when we've never seen it happen in the real world, and really don't have a basis for talking about what need we're addressing. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon Aug 16 19:52:16 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22672; Mon, 16 Aug 2004 19:52:15 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BwrCj-0007ZY-40; Mon, 16 Aug 2004 19:47:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bwr38-0003AJ-Vw for dhcwg@megatron.ietf.org; Mon, 16 Aug 2004 19:37:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22052 for ; Mon, 16 Aug 2004 19:37:57 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bwr92-0007F5-5x for dhcwg@ietf.org; Mon, 16 Aug 2004 19:44:04 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 16 Aug 2004 16:42:25 +0000 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i7GNbMwM009182; Mon, 16 Aug 2004 16:37:22 -0700 (PDT) Received: from volzw2k ([161.44.65.208]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AKW60661; Mon, 16 Aug 2004 19:36:06 -0400 (EDT) From: "Bernie Volz" To: "'Ted Lemon'" Subject: RE: [dhcwg] Re: I-D: draft-volz-dhc-dhcpv6-fqdn-00.txt Date: Mon, 16 Aug 2004 19:36:06 -0400 Organization: Cisco Message-ID: <005001c483e9$cd040d70$d0412ca1@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.5709 In-reply-to: <7FD2BE8F-EFB3-11D8-9348-000A95D9C74C@nominum.com> X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4939.300 Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 Content-Transfer-Encoding: quoted-printable Cc: dhcwg@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Ted: Thanks for your feedback on this issue. Others, please chime in with your thoughts/opinions. One possibility is to allow both. The simple case just has the client FQDN option in the IA_*-options = field for both the client and server and one name applies to all of the = address. The complex case (if the server determines that a unique name is = required for each address) it can use the alternate form - putting the client = FQDN option into the IAaddr-options field (as currently specified). Since it requires client (and server) support for the complex case, we = can use a "flag" bit to allow the client to specify whether it can support = the complex case. By default (if the bit is 0), the client (and server) can = only use the simple case. If the bit is set, it is up to the server to = determine whether to use the simple or complex case, based on the addresses and = the configuration. - Bernie > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org]=20 > On Behalf Of Ted Lemon > Sent: Monday, August 16, 2004 2:39 PM > To: Bernie Volz > Cc: dhcwg@ietf.org > Subject: [dhcwg] Re: I-D: draft-volz-dhc-dhcpv6-fqdn-00.txt >=20 >=20 > Bernie, the problem I have with the complex model for the DHCPv6 FQDN=20 > option is that I can't imagine any of the scenarios you describe ever=20 > having a meaning in practice. A computer is a computer. It has a=20 > name. One name. If you give it multiple names, that doesn't have=20 > any meaning, generally speaking. The exception is when you are=20 > configuring a single computer to present more than one=20 > identity on the=20 > network. In this case, it makes sense that each identity would have=20 > its own name. >=20 > So I think it makes sense to have a one-to-one mapping between names=20 > and identity associations. I do not think it makes sense to=20 > break it=20 > down below this point. Let's consider some of the scenarios you've=20 > proposed. First, let's consider number four, which you say you=20 > consider most likely. >=20 > In this case, the client has a single identity, and gets both a=20 > globally-scoped address and a locally-scoped address. So=20 > what does it=20 > make sense to do here? We have several options: >=20 > 1. Publish the name with the global address. > 2. Publish the name with both the global and site-local=20 > address. 3. Publish two names, one for the global address and=20 > one for the local=20 > address. >=20 > So what's going to fail in case 1? Let's say some clients get=20 > site-local addresses, and some get global _and_ site-local=20 > addresses. =20 > If we only publish the global address, can a client with only a=20 > site-local address exchange packets with the client with the global=20 > address? I think it can, as long as they are both at the same site=20 > (which is the only case that matters). So I think that this=20 > solution=20 > works, and we don't need to do anything further. >=20 > What fails in case 2? We've published a site-local address in a=20 > global namespace. If a host outside of the site wants to=20 > contact the=20 > host using the name, how does it know that the site-local address is=20 > not local? It doesn't. We can't control which address it tries to=20 > connect to, and many network clients do not try to connect to every=20 > address - they just try to connect to the first one, which DNS is=20 > required to alternate. So what we would get, from the=20 > perspective of=20 > a naive user, would be intermittent failures. Not good. >=20 > What about case 3? Case 3 works, but now you have to tell people=20 > about two different names. Why would you want that, when one name=20 > will do? So I really think that case 1 is how you want to=20 > do things,=20 > and this is easy and matches the one name per IAID model very nicely. >=20 > As far as whether temporary and public addresses are part of the same=20 > IA or not, why not let it be that if you want for some reason to=20 > publish your temporary address, the way you do it is under a separate=20 > IAID? Why add complexity when there's a way to do it that's less=20 > complex? >=20 > If a site is multihomed and wants to use different names for=20 > different=20 > addresses, I'm skeptical that it's something we need to think about=20 > here and now. While it's true that this is a possible scenario, I=20 > think the complexity that addressing this problem adds to the current=20 > draft is unacceptable. I would like to see this problem actually=20 > happen in the real world, and have that drive a new standardization=20 > effort, rather than trying to guess how people are going to want to=20 > solve this problem when we've never seen it happen in the real world,=20 > and really don't have a basis for talking about what need we're=20 > addressing. >=20 >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg >=20 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Aug 17 04:51:47 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01609; Tue, 17 Aug 2004 04:51:47 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bwze2-0006E0-VO; Tue, 17 Aug 2004 04:48:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bwzal-0005NI-J4 for dhcwg@megatron.ietf.org; Tue, 17 Aug 2004 04:45:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01320 for ; Tue, 17 Aug 2004 04:45:13 -0400 (EDT) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bwzgi-0007gq-Jv for dhcwg@ietf.org; Tue, 17 Aug 2004 04:51:26 -0400 Received: from ocean.jinmei.org (unknown [2001:200:0:8002:fd13:3c53:7410:a99a]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 141771525D; Tue, 17 Aug 2004 17:45:06 +0900 (JST) Date: Tue, 17 Aug 2004 17:45:05 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: jdq@lucent.com Subject: Re: [dhcwg] comments on draft-ietf-dhc-lifetime-01.txt In-Reply-To: <200408121018.57077.jdq@lucent.com> References: <000001c48073$af492fa0$d0412ca1@amer.cisco.com> <200408121018.57077.jdq@lucent.com> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: dhcwg@ietf.org, tjc@ecs.soton.ac.uk, Bernie Volz , "'Stig Venaas'" X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org >>>>> On Thu, 12 Aug 2004 10:18:57 -0400, >>>>> Joe Quanaim said: >> The primary motivation for the lifetime option is for situations where >> no lifetime (or renewal time) is communicated to the client, such as for >> Stateless DHCP service as specified in [RFC 3736]. However, it applies >> to both stateful and stateless DHCP clients and is an upper bound for >> when a client should initiate renewal of at least its non-address based >> configuration parameters - a stateful client MAY renew its addresses at >> the same time and SHOULD always get updated configuration data from the >> server when it renews any addresses. >> >> One difference between Stateful and Stateless clients with regards >> to this option is that a Stateful client that does not receive this >> option MUST NOT apply the default lifetime. > As noted, the motivation of the lifetime option is to ensure stateless clients > receive current configuration information. As such, I think keeping it out > of stateful configuration is the simplest approach. As we have discussed, > stateful configuration already has several variables to manipulate client > behavior. I do not see much gain in adding another. It's not a strong opinion, but I'd also still prefer to restrict the use of the lifetime option to the stateless case. The reasons are: - even if it might be true that the client can use stateful exchanges without having addresses or infinite T1/T2 timers for other configurations only, it should be a very minor case (I'm pretty sure that everyone agrees on this - whether still want to allow such usage or not). In my understanding, the sense of RFC3315 is that "if you can get an address, you may get other information. If you cannot get an address, then give up any possible information." In fact, Section 18.1.8 says [...] If the client receives no addresses in any of the IAs, it may either try another server (perhaps restarting the DHCP server discovery process) or use the Information-request message to obtain other configuration information only. but the RFC does not (explicitly) allow the client to continue to use other information configuration than addresses. What you are going to achieve in the scenario of the lifetime option with the stateful case seems to contradict the original sense, IMO. - recalling that we rejected the idea of multiple lifetime options for multiple configuration parameters, it's odd to me that we are now going to have T1/T2 as well as the lifetime option (I was happy with rejecting the idea of multiple lifetimes, BTW). If we applied the same logic, we could simply use an appropriate T1 value to implement controlled update of the other configuration information. Again, it's true that stateful exchanges can provide no finite timers, but, as I said in the above bullet, it's very minor or even almost-unexpected use case in my understanding. - as I pointed out in my first message, we'll have to define all the details, most of which are boring corner cases (but the implementors would be unhappy if we didn't define those). I know some of you are now trying to address those, and trying to minimize the complexity of the specification. However, right now I'm not sure if it really makes sense, considering the usage case of stateful+lifetime is minor. I admit this is a tradeoff issue, and perhaps we need to end up discussing details to make a clear consensus. - one thing I'm concerned about which is related to the above point: there is already a non-address IA that has a notion of timeout: IA_PD. So, we'll probably have to consider the combination of IA_PD and the lifetime option. Moreover, the lifetime option document may need to be generic enough to prepare for any future stateful resources that has a notion of timeout. > Still, it's not that complex a change. If I am outvoted, so be it. Same here. Though I'm still skeptical about the benefit of the use case of stateful+lifetime, considering the possible complexity, I can live with that if the specification is crystal clear about all the details. 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-bounces@ietf.org Wed Aug 18 13:39:12 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24472; Wed, 18 Aug 2004 13:39:12 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BxUDl-0003iz-RX; Wed, 18 Aug 2004 13:27:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BxU8z-0003AZ-G5 for dhcwg@megatron.ietf.org; Wed, 18 Aug 2004 13:22:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23362 for ; Wed, 18 Aug 2004 13:22:34 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BxUFE-0001yu-H5 for dhcwg@ietf.org; Wed, 18 Aug 2004 13:29:05 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 18 Aug 2004 10:27:12 +0000 X-BrightmailFiltered: true Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i7IHLkTt002912; Wed, 18 Aug 2004 10:21:46 -0700 (PDT) Received: from jmpolk-w2k01.diablo.cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id KAA23987; Wed, 18 Aug 2004 10:21:52 -0700 (PDT) Message-Id: <4.3.2.7.2.20040818121846.02798f00@localhost> X-Sender: jmpolk@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 18 Aug 2004 12:23:28 -0500 To: mjs@cisco.com, Ted.Lemon@nominum.com From: "James M. Polk" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 2.3 (++) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: dhcwg@ietf.org Subject: [dhcwg] Nit with "Authentication Suboption" ID X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Mark/Ted The 3rd paragraph of section 4 is: "Four bits are reserved for future use. These bits SHOULD be set to zero, and MUST be not be used when the suboption is processed. " I believe this should end with: "... and MUST NOT be used when the suboption is processed." with "NOT" as normative and the first "be" removed - as it seems to be there in error comments welcome cheers, James ******************* Truth is not to be argued... it is to be presented _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Aug 18 13:45:46 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24930; Wed, 18 Aug 2004 13:45:46 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BxURr-0006Hh-PH; Wed, 18 Aug 2004 13:42:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BxUP2-0005gl-5B for dhcwg@megatron.ietf.org; Wed, 18 Aug 2004 13:39:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24443 for ; Wed, 18 Aug 2004 13:38:50 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BxUUu-0002Js-HW for dhcwg@ietf.org; Wed, 18 Aug 2004 13:45:19 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 18 Aug 2004 10:41:29 +0000 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i7IHa8Tt023548; Wed, 18 Aug 2004 10:36:09 -0700 (PDT) Received: from mjs-xp.cisco.com (dhcp-10-86-160-98.cisco.com [10.86.160.98]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AKX86042; Wed, 18 Aug 2004 13:36:07 -0400 (EDT) Message-Id: <4.3.2.7.2.20040818133216.0262bec8@goblet.cisco.com> X-Sender: mjs@goblet.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 18 Aug 2004 13:35:12 -0400 To: "James M. Polk" From: Mark Stapp In-Reply-To: <4.3.2.7.2.20040818121846.02798f00@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: dhcwg@ietf.org, Ted.Lemon@nominum.com Subject: [dhcwg] Re: Nit with "Authentication Suboption" ID X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org thanks for catching that. I've updated the source, and I'll include that fix when we spin the next rev. Regards, Mark At 12:23 PM 8/18/2004 -0500, James M. Polk wrote: >Mark/Ted > >The 3rd paragraph of section 4 is: > >"Four bits are reserved for future use. These bits SHOULD be set to zero, >and MUST be not be used when the suboption is processed. " > >I believe this should end with: > > "... and MUST NOT be used when the suboption is processed." > >with "NOT" as normative > >and the first "be" removed - as it seems to be there in error > >comments welcome > >cheers, >James > > ******************* > Truth is not to be argued... it is to be presented _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Aug 18 18:09:17 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24961; Wed, 18 Aug 2004 18:09:17 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BxYOj-0003xW-S3; Wed, 18 Aug 2004 17:55:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BxY73-00005k-JV for dhcwg@megatron.ietf.org; Wed, 18 Aug 2004 17:36:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22212 for ; Wed, 18 Aug 2004 17:36:51 -0400 (EDT) Received: from zrtps0kn.nortelnetworks.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BxYDJ-0003FL-St for dhcwg@ietf.org; Wed, 18 Aug 2004 17:43:24 -0400 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps0kn.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i7ILaIq18580 for ; Wed, 18 Aug 2004 17:36:18 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 18 Aug 2004 17:36:19 -0400 Message-ID: <591B780D9676844E8A704B5B013FFE92025D75B9@zrc2hxm1.corp.nortel.com> From: "Kuntal Chowdhury" To: dhcwg@ietf.org Date: Wed, 18 Aug 2004 17:36:08 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Subject: [dhcwg] questions on RFC 3046 and RFC 3527 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Hello all, I have some questions regarding RFC3046 and RFC3527: Q1. RFC3046 defines the Relay Agent Information Option. One of the sub option for this option is Agent Remote ID Sub-option. A possible value for this sub-option can be "the remote IP address of a point-to-point link". RFC3527 defines another sub-option for Relay Agent Information Option called Link selection sub-option. The possible value for this sub-option can be the subnet (of the link) of the DHCP client. The question is, why the IP address in "Agent Remote ID Sub-option" can't be used to identify the subnet of link for the DHCP client? Why there was a need for two separate sub-options to convey the same thing? Q2. RFC3046 says: " 2.2 Server Operation DHCP servers unaware of the Relay Agent Information option will ignore the option upon receive and will not echo it back on responses. This is the specified server behavior for unknown options. " RFC3527 says: " When the DHCP server is allocating an address and this sub-option is present, then the DHCP server MUST allocate the address on either: o the subnet specified in the link-selection sub-option, or; o a subnet on the same link (also known as a network segment) as the subnet specified by the link-selection sub-option. " The confusion is: RFC3527 seems to mandate the DHCP server to assign IP address based on link-selection sub-option when this sub-option is present in the received request, but RFC3046 says that the entire Relay Agent Information option can be ignored by the DHCP server if it is not supported. Could someone clarify this? Regards, Kuntal _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Aug 18 18:42:17 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27714; Wed, 18 Aug 2004 18:42:17 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BxZ5W-00042c-Vl; Wed, 18 Aug 2004 18:39:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BxYzf-0002ta-C2 for dhcwg@megatron.ietf.org; Wed, 18 Aug 2004 18:33:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27035 for ; Wed, 18 Aug 2004 18:33:16 -0400 (EDT) Received: from chimera.incognito.com ([206.172.52.66]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BxZ5u-0004TS-Sy for dhcwg@ietf.org; Wed, 18 Aug 2004 18:39:50 -0400 Received: from homerdmz.incognito.com ([206.172.52.116] helo=HOMER.incognito.com.) by chimera.incognito.com with esmtp (Exim 4.30) id 1BxYz0-0002jr-9f; Wed, 18 Aug 2004 15:32:38 -0700 Received: by homer.incognito.com with Internet Mail Service (5.5.2653.19) id ; Wed, 18 Aug 2004 15:32:04 -0700 Message-ID: From: "Kostur, Andre" To: "'Kuntal Chowdhury'" , dhcwg@ietf.org Subject: RE: [dhcwg] questions on RFC 3046 and RFC 3527 Date: Wed, 18 Aug 2004 15:32:04 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 2.3 (++) X-Spam-Report: Spam detection software, running on the system "chimera.incognito.com", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or block similar future email. If you have any questions, see the administrator of that system for details. Content preview: 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. > Hello all, > > I have some questions regarding RFC3046 and RFC3527: > > Q1. > > RFC3046 defines the Relay Agent Information Option. One of > the sub option > for this option is Agent Remote ID Sub-option. A possible > value for this > sub-option can be "the remote IP address of a point-to-point link". [...] Content analysis details: (2.3 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.8 HTML_30_40 BODY: Message is 30% to 40% HTML 1.5 HTML_MESSAGE BODY: HTML included in message X-Spam-Score: 0.8 (/) X-Scan-Signature: 31b28e25e9d13a22020d8b7aedc9832c X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1903579874==" Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org 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. --===============1903579874== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C48573.2FCB91A0" 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_01C48573.2FCB91A0 Content-Type: text/plain; charset="iso-8859-1" > Hello all, > > I have some questions regarding RFC3046 and RFC3527: > > Q1. > > RFC3046 defines the Relay Agent Information Option. One of > the sub option > for this option is Agent Remote ID Sub-option. A possible > value for this > sub-option can be "the remote IP address of a point-to-point link". Note the phrasing that a _possible_ value for this sub-option.... > RFC3527 defines another sub-option for Relay Agent > Information Option called > Link selection sub-option. The possible value for this > sub-option can be the > subnet (of the link) of the DHCP client. > > The question is, why the IP address in "Agent Remote ID > Sub-option" can't be > used to identify the subnet of link for the DHCP client? Why > there was a > need for two separate sub-options to convey the same thing? Because the RemoteID isn't necessarily an IP address? At least one well-known standard (DOCSIS) sepcifies that the Remote ID is the MAC address of the cable modem, and not an IP address. > Q2. > > RFC3046 says: > > " > 2.2 Server Operation > > DHCP servers unaware of the Relay Agent Information option will > ignore the option upon receive and will not echo it back on > responses. This is the specified server behavior for unknown > options. > " > RFC3527 says: > > " > When the DHCP server is allocating an address and this > sub-option is > present, then the DHCP server MUST allocate the address on either: > > o the subnet specified in the link-selection sub-option, or; > > o a subnet on the same link (also known as a network > segment) as > the subnet specified by the link-selection sub-option. > " > > The confusion is: RFC3527 seems to mandate the DHCP server to > assign IP > address based on link-selection sub-option when this > sub-option is present > in the received request, but RFC3046 says that the entire Relay Agent > Information option can be ignored by the DHCP server if it is > not supported. > Could someone clarify this? Correct. If the server doesn't support 3046, then it cannot possibly support 3527. ------_=_NextPart_001_01C48573.2FCB91A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] questions on RFC 3046 and RFC 3527

> Hello all,
>
> I have some questions regarding RFC3046 and = RFC3527:
>
> Q1.
>
> RFC3046 defines the Relay Agent Information = Option. One of
> the sub option
> for this option is Agent Remote ID Sub-option. = A possible
> value for this
> sub-option can be "the remote IP address = of a point-to-point link".

Note the phrasing that a _possible_ value for this = sub-option....
 
> RFC3527 defines another sub-option for Relay = Agent
> Information Option called
> Link selection sub-option. The possible value = for this
> sub-option can be the
> subnet (of the link) of the DHCP client.
>
> The question is, why the IP address in = "Agent Remote ID
> Sub-option" can't be
> used to identify the subnet of link for the = DHCP client? Why
> there was a
> need for two separate sub-options to convey the = same thing?

Because the RemoteID isn't necessarily an IP = address?

At least one well-known standard (DOCSIS) sepcifies = that the Remote ID is the MAC address of the cable modem, and not an IP = address.

> Q2.
>
> RFC3046 says:
>
> "
> 2.2 Server Operation
>
>    DHCP servers unaware of the = Relay Agent Information option will
>    ignore the option upon = receive and will not echo it back on
>    responses.  This is the = specified server behavior for unknown
>    options.
> "
> RFC3527 says:
>
> "
>    When the DHCP server is = allocating an address and this
> sub-option is
>    present, then the DHCP server = MUST allocate the address on either:
>
>       o  the = subnet specified in the link-selection sub-option, or;
>
>       o  a = subnet on the same link (also known as a network
> segment) as
>          the = subnet specified by the link-selection sub-option.
> "
>
> The confusion is: RFC3527 seems to mandate the = DHCP server to
> assign IP
> address based on link-selection sub-option when = this
> sub-option is present
> in the received request, but RFC3046 says that = the entire Relay Agent
> Information option can be ignored by the DHCP = server if it is
> not supported.
> Could someone clarify this?

Correct.  If the server doesn't support 3046, = then it cannot possibly support 3527.

------_=_NextPart_001_01C48573.2FCB91A0-- --===============1903579874== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --===============1903579874==-- From dhcwg-bounces@ietf.org Wed Aug 18 19:21:02 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29626; Wed, 18 Aug 2004 19:21:02 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BxZfa-00027b-6I; Wed, 18 Aug 2004 19:16:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BxZdH-0001c2-8h for dhcwg@megatron.ietf.org; Wed, 18 Aug 2004 19:14:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29376 for ; Wed, 18 Aug 2004 19:14:12 -0400 (EDT) Received: from zrtps0kn.nortelnetworks.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BxZja-0005F8-ET for dhcwg@ietf.org; Wed, 18 Aug 2004 19:20:46 -0400 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps0kn.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i7IND2v16021; Wed, 18 Aug 2004 19:13:02 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 18 Aug 2004 19:13:03 -0400 Message-ID: <591B780D9676844E8A704B5B013FFE92025D7742@zrc2hxm1.corp.nortel.com> From: "Kuntal Chowdhury" To: "Kostur, Andre" , dhcwg@ietf.org Subject: RE: [dhcwg] questions on RFC 3046 and RFC 3527 Date: Wed, 18 Aug 2004 19:12:50 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Thanks for your response. > Because the RemoteID isn't necessarily an IP address? > At least one well-known standard (DOCSIS) sepcifies that the Remote ID is the MAC address of the cable > modem, and not an IP address. It is true that RemoteID is not necessarily an IP address, but it MAY be an IP address. The question is, if the RemoteID is an IP address, is the use of RFC 3527 redundant or there are some other reason to include the Link selection sub-option? Regarding the confusion between RFC 3046 and RFC 3527 (Q2), I think RFC 3527 should say: "If the DHCP server supports the Relay Agent Information Option the DHCP server MUST allocate the address based on the following when the received Relay Agent Information Option contains the Link selection sub-option: " -Kuntal -----Original Message----- From: Kostur, Andre [mailto:akostur@incognito.com] Sent: Wednesday, August 18, 2004 5:32 PM To: Chowdhury, Kuntal [RICH1:2H18:EXCH]; dhcwg@ietf.org Subject: RE: [dhcwg] questions on RFC 3046 and RFC 3527 > Hello all, > > I have some questions regarding RFC3046 and RFC3527: > > Q1. > > RFC3046 defines the Relay Agent Information Option. One of > the sub option > for this option is Agent Remote ID Sub-option. A possible > value for this > sub-option can be "the remote IP address of a point-to-point link". Note the phrasing that a _possible_ value for this sub-option.... > RFC3527 defines another sub-option for Relay Agent > Information Option called > Link selection sub-option. The possible value for this > sub-option can be the > subnet (of the link) of the DHCP client. > > The question is, why the IP address in "Agent Remote ID > Sub-option" can't be > used to identify the subnet of link for the DHCP client? Why > there was a > need for two separate sub-options to convey the same thing? Because the RemoteID isn't necessarily an IP address? At least one well-known standard (DOCSIS) sepcifies that the Remote ID is the MAC address of the cable modem, and not an IP address. > Q2. > > RFC3046 says: > > " > 2.2 Server Operation > > DHCP servers unaware of the Relay Agent Information option will > ignore the option upon receive and will not echo it back on > responses. This is the specified server behavior for unknown > options. > " > RFC3527 says: > > " > When the DHCP server is allocating an address and this > sub-option is > present, then the DHCP server MUST allocate the address on either: > > o the subnet specified in the link-selection sub-option, or; > > o a subnet on the same link (also known as a network > segment) as > the subnet specified by the link-selection sub-option. > " > > The confusion is: RFC3527 seems to mandate the DHCP server to > assign IP > address based on link-selection sub-option when this > sub-option is present > in the received request, but RFC3046 says that the entire Relay Agent > Information option can be ignored by the DHCP server if it is > not supported. > Could someone clarify this? Correct. If the server doesn't support 3046, then it cannot possibly support 3527. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Aug 18 19:43:29 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00687; Wed, 18 Aug 2004 19:43:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BxZyv-0001lO-JD; Wed, 18 Aug 2004 19:36:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BxZuo-00017c-8C for dhcwg@megatron.ietf.org; Wed, 18 Aug 2004 19:32:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00179 for ; Wed, 18 Aug 2004 19:32:19 -0400 (EDT) Received: from chimera.incognito.com ([206.172.52.66]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bxa14-0005Wa-BM for dhcwg@ietf.org; Wed, 18 Aug 2004 19:38:53 -0400 Received: from homerdmz.incognito.com ([206.172.52.116] helo=HOMER.incognito.com.) by chimera.incognito.com with esmtp (Exim 4.30) id 1BxZuF-0002yG-Do; Wed, 18 Aug 2004 16:31:47 -0700 Received: by homer.incognito.com with Internet Mail Service (5.5.2653.19) id ; Wed, 18 Aug 2004 16:31:17 -0700 Message-ID: From: "Kostur, Andre" To: "'Kuntal Chowdhury'" , "Kostur, Andre" , dhcwg@ietf.org Subject: RE: [dhcwg] questions on RFC 3046 and RFC 3527 Date: Wed, 18 Aug 2004 16:31:15 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 2.0 (++) X-Spam-Report: Spam detection software, running on the system "chimera.incognito.com", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or block similar future email. If you have any questions, see the administrator of that system for details. Content preview: 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. > Thanks for your response. > > > Because the RemoteID isn't necessarily an IP address? > > At least one well-known standard (DOCSIS) sepcifies that > the Remote ID is > the MAC address of the cable > > modem, and not an IP address. > > It is true that RemoteID is not necessarily an IP address, > but it MAY be an > IP address. The question is, if the RemoteID is an IP > address, is the use of > RFC 3527 redundant or there are some other reason to include the Link > selection sub-option? [...] Content analysis details: (2.0 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 1.5 HTML_MESSAGE BODY: HTML included in message 0.5 HTML_20_30 BODY: Message is 20% to 30% HTML X-Spam-Score: 0.5 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0472775234==" Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org 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. --===============0472775234== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4857B.74BE0BA0" 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_01C4857B.74BE0BA0 Content-Type: text/plain; charset="iso-8859-1" > Thanks for your response. > > > Because the RemoteID isn't necessarily an IP address? > > At least one well-known standard (DOCSIS) sepcifies that > the Remote ID is > the MAC address of the cable > > modem, and not an IP address. > > It is true that RemoteID is not necessarily an IP address, > but it MAY be an > IP address. The question is, if the RemoteID is an IP > address, is the use of > RFC 3527 redundant or there are some other reason to include the Link > selection sub-option? However, the DHCP Service cannot assume that the RemoteID is an IP Address. All it knows is that there's this binary blob of data to be used for certain logic, that that the RemoteID is unique (See section 3.2 of 3046). And, how would the service distinguish between an IP address and any other 4 byte Remote ID? > Regarding the confusion between RFC 3046 and RFC 3527 (Q2), I > think RFC 3527 > should say: > > "If the DHCP server supports the Relay Agent Information > Option the DHCP > server MUST allocate the address based on the following when > the received > Relay Agent Information Option contains the Link selection sub-option: > " I don't understand the confusion. All 3527 says is that IF a DHCP server claims to implement 3527, then the server must perform the address allocation in the specified manner. And since 3527 cannot be implemented without implementing 3046, having 3046 support is implied. ------_=_NextPart_001_01C4857B.74BE0BA0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] questions on RFC 3046 and RFC 3527

> Thanks for your response.
>
> > Because the RemoteID isn't necessarily an = IP address?
> > At least one well-known standard (DOCSIS) = sepcifies that
> the Remote ID is
> the MAC address of the cable
> > modem, and not an IP address.
>
> It is true that RemoteID is not necessarily an = IP address,
> but it MAY be an
> IP address. The question is, if the RemoteID is = an IP
> address, is the use of
> RFC 3527 redundant or there are some other = reason to include the Link
> selection sub-option?

However, the DHCP Service cannot assume that the = RemoteID is an IP Address.  All it knows is that there's this = binary blob of data to be used for certain logic, that that the = RemoteID is unique (See section 3.2 of 3046).  And, how would the = service distinguish between an IP address and any other 4 byte Remote = ID?

 
> Regarding the confusion between RFC 3046 and = RFC 3527 (Q2), I
> think RFC 3527
> should say:
>
> "If the DHCP server supports the Relay = Agent Information
> Option the DHCP
> server MUST allocate the address based on the = following when
> the received
> Relay Agent Information Option contains the = Link selection sub-option:
> "

I don't understand the confusion.  All 3527 says = is that IF a DHCP server claims to implement 3527, then the server must = perform the address allocation in the specified manner.  And since = 3527 cannot be implemented without implementing 3046, having 3046 = support is implied.

------_=_NextPart_001_01C4857B.74BE0BA0-- --===============0472775234== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --===============0472775234==-- From dhcwg-bounces@ietf.org Wed Aug 18 19:54:30 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01453; Wed, 18 Aug 2004 19:54:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bxa9y-0003l5-Rt; Wed, 18 Aug 2004 19:48:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bxa86-0003Nf-Rl for dhcwg@megatron.ietf.org; Wed, 18 Aug 2004 19:46:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00859 for ; Wed, 18 Aug 2004 19:46:05 -0400 (EDT) Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BxaEP-0005lc-EA for dhcwg@ietf.org; Wed, 18 Aug 2004 19:52:38 -0400 Received: from [10.0.2.3] (neubayern.net [66.93.162.100]) by toccata.fugue.com (Postfix) with ESMTP id 71F651B22E8; Wed, 18 Aug 2004 18:42:41 -0500 (CDT) In-Reply-To: <591B780D9676844E8A704B5B013FFE92025D7742@zrc2hxm1.corp.nortel.com> References: <591B780D9676844E8A704B5B013FFE92025D7742@zrc2hxm1.corp.nortel.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Ted Lemon Subject: Re: [dhcwg] questions on RFC 3046 and RFC 3527 Date: Wed, 18 Aug 2004 16:45:59 -0700 To: "Kuntal Chowdhury" X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org, "Kostur, Andre" X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 7bit On Aug 18, 2004, at 4:12 PM, Kuntal Chowdhury wrote: > It is true that RemoteID is not necessarily an IP address, but it MAY > be an > IP address. The question is, if the RemoteID is an IP address, is the > use of > RFC 3527 redundant or there are some other reason to include the Link > selection sub-option? The DHCP server will use the link selection suboption to select the link on which to configure the client. It will not use the remote ID option for this purpose. If you can't think of a reason to send the link selection suboption, do not send it. It is intended for a specific purpose, and is not something that every relay agent should send in all circumstances. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Thu Aug 19 16:54:32 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08271; Thu, 19 Aug 2004 16:54:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bxsey-0002OT-Ck; Thu, 19 Aug 2004 15:33:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bxsal-0000R9-5c for dhcwg@megatron.ietf.org; Thu, 19 Aug 2004 15:28:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27660 for ; Thu, 19 Aug 2004 15:28:53 -0400 (EDT) Received: from zrtps0kn.nortelnetworks.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BxshE-0002x4-7F for dhcwg@ietf.org; Thu, 19 Aug 2004 15:35:37 -0400 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps0kn.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i7JJRkd29376; Thu, 19 Aug 2004 15:27:46 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 19 Aug 2004 15:27:44 -0400 Message-ID: <591B780D9676844E8A704B5B013FFE920262DE0C@zrc2hxm1.corp.nortel.com> From: "Kuntal Chowdhury" To: Ted Lemon , "Kostur, Andre" Subject: RE: [dhcwg] questions on RFC 3046 and RFC 3527 Date: Thu, 19 Aug 2004 15:27:27 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: dhcwg@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Ted/Kostur, Thanks for the clarification. Now I understand the use of these sub-options better. -Kuntal >-----Original Message----- >From: Ted Lemon [mailto:mellon@nominum.com] >Sent: Wednesday, August 18, 2004 6:46 PM >To: Chowdhury, Kuntal [RICH1:2H18:EXCH] >Cc: dhcwg@ietf.org; Kostur, Andre >Subject: Re: [dhcwg] questions on RFC 3046 and RFC 3527 > > >On Aug 18, 2004, at 4:12 PM, Kuntal Chowdhury wrote: >> It is true that RemoteID is not necessarily an IP address, but it MAY >> be an >> IP address. The question is, if the RemoteID is an IP >address, is the >> use of >> RFC 3527 redundant or there are some other reason to include the Link >> selection sub-option? > >The DHCP server will use the link selection suboption to select the >link on which to configure the client. It will not use the remote ID >option for this purpose. If you can't think of a reason to send the >link selection suboption, do not send it. It is intended for a >specific purpose, and is not something that every relay agent should >send in all circumstances. > > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri Aug 20 07:42:46 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06219; Fri, 20 Aug 2004 07:42:46 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1By7Wl-0007lw-PG; Fri, 20 Aug 2004 07:25:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1By7Dr-0003dC-Aq for dhcwg@megatron.ietf.org; Fri, 20 Aug 2004 07:06:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04659 for ; Fri, 20 Aug 2004 07:06:07 -0400 (EDT) Received: from tyholt.uninett.no ([158.38.60.10]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1By7KN-0004mw-QB for dhcwg@ietf.org; Fri, 20 Aug 2004 07:13:01 -0400 Received: from sverresborg.uninett.no (sverresborg.uninett.no [IPv6:2001:700:e000:0:204:75ff:fee4:423b]) by tyholt.uninett.no (8.12.10/8.12.10) with ESMTP id i7KB5a2M008925; Fri, 20 Aug 2004 13:05:36 +0200 Received: (from venaas@localhost) by sverresborg.uninett.no (8.12.8/8.12.8/Submit) id i7KB5ZsK014847; Fri, 20 Aug 2004 13:05:35 +0200 X-Authentication-Warning: sverresborg.uninett.no: venaas set sender to Stig.Venaas@uninett.no using -f Date: Fri, 20 Aug 2004 13:05:35 +0200 From: Stig Venaas To: Dave Thaler Subject: Re: [dhcwg] RE: mboned:draft-jdurand-assign-addr-ipv6-multicast-dhcpv6-00 comments Message-ID: <20040820110535.GB14315@sverresborg.uninett.no> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: dhcwg@ietf.org, mboned@lists.uoregon.edu X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org On Fri, Aug 13, 2004 at 04:54:02PM -0700, Dave Thaler wrote: > Stig Venaas writes: > > If we instead used the stateless prefix announcement solution we may > > need to solve the DAD issue, but there are some advantages. > > > > o For link-local multicast, it would be possible to generate link > > unique multicast addresses with no need for DHCP servers or routers. > > Right. This is what > http://www.ietf.org/internet-drafts/draft-ietf-ipv6-link-scoped-mcast-04 > .txt > does. Yes, so we have a good solution for that already I think. > > o For unicast-prefix-based addressing (RFC 3306) you can generate a > > /96 multicast prefix from the links unicast /64 prefix and then > > using RNG plus possibly DAD you can come up with prefixes to use on > > the link. This can be done without DHCP. > > Right. > > > o For Embedded-RP the application will need to learn the prefix from > > somewhere. But the system could learn the prefix once (from DHCP, > > from config file or whatever) and all the applications use the same. > > You can perhaps compare it to how applications use resolv.conf on > > unix and how it might be configured from DHCP or other systems. > > And you need a DAD mechanism for address selection within the prefix, > as with 3306 addresses. Yes. I'm not sure it's a good idea, but have you considered whether LLMNR could be used for multicast DAD? I think it could be done easily, but it's perhaps a bit ugly since since it uses LLMNR for something it isn't designed for perhaps. Another option could be to use or copy the unicast ND DAD mechanism. I'm sure it would work. You could possibly use ND DAD as it is, with some standardized way of mapping group addresses to interface id's. That feels wrong to me, but you could copy the mechanism, and perhaps add new "multicast group solicit" and "multicast group advertise" messages that work exactly like todays unicast solicit and advertise. Well, just some ideas, not sure how good they are... Stig _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri Aug 20 08:28:58 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09096; Fri, 20 Aug 2004 08:28:58 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1By86R-00075g-7d; Fri, 20 Aug 2004 08:02:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1By7s8-0004D8-Tc for dhcwg@megatron.ietf.org; Fri, 20 Aug 2004 07:47:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06669 for ; Fri, 20 Aug 2004 07:47:46 -0400 (EDT) Received: from mail.loqal.no ([82.194.192.34]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1By7yf-0005QW-QY for dhcwg@ietf.org; Fri, 20 Aug 2004 07:54:39 -0400 Received: from bbsrv1.loqal.no (bbsrv1.loqal.no [127.0.0.1]) by mail.loqal.no (Postfix) with ESMTP id A1A674BDC7 for ; Fri, 20 Aug 2004 13:46:38 +0200 (CEST) Received: from mail.loqal.no (bbsrv1.loqal.no [127.0.0.1]) by bbsrv1.loqal.no (VaMailArmor-2.0.1.16) id 18865-1691D8EF; Fri, 20 Aug 2004 13:46:38 +0200 Received: from terje (unknown [82.194.195.52]) by mail.loqal.no (Postfix) with ESMTP id 88B364BDC7 for ; Fri, 20 Aug 2004 13:46:22 +0200 (CEST) To: dhcwg@ietf.org Date: Fri, 20 Aug 2004 13:46:23 +0200 From: "Terje Andersen" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-15 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: User-Agent: Opera M2/7.54 (Win32, build 3869) X-AntiVirus: checked by Vexira MailArmor (version: 2.0.1.16; VAE: 6.27.0.6; VDF: 6.27.0.22; host: bbsrv1.loqal.no) X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 8bit Subject: [dhcwg] DHCP in my local area network. X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 8bit First of all, my english is not to well :) Hi. I am the manager of a computer club called Meldal-LAN. Because of issues with the broadband company, we cant get IP's from them anymore. We therefor plan to set up a server, with 2,6Ghz Prescott CPU and 1GB Corsair Dual Ram. The network solution will be a 10/100 pci who recieves the internet, and 2X10/100/1000 linked together that shares IP's. The server will primarly be running as a DHCP, but also to host games, host movie vision and share files. We plan to run Windows 2000 on the server. 1: Do you think the hardware aspects is good enough? 2: The computer club has about 50 members, do the DHCP get problems sharing out so many IP's? 3: Is there hard to configure the DHCP so that people can play online and stuff? _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri Aug 20 08:29:28 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09141; Fri, 20 Aug 2004 08:29:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1By86S-00075s-3I; Fri, 20 Aug 2004 08:02:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1By7sn-0004Ew-VN for dhcwg@megatron.ietf.org; Fri, 20 Aug 2004 07:48:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06709 for ; Fri, 20 Aug 2004 07:48:27 -0400 (EDT) Received: from tyholt.uninett.no ([158.38.60.10]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1By7zI-0005TE-LT for dhcwg@ietf.org; Fri, 20 Aug 2004 07:55:20 -0400 Received: from sverresborg.uninett.no (sverresborg.uninett.no [IPv6:2001:700:e000:0:204:75ff:fee4:423b]) by tyholt.uninett.no (8.12.10/8.12.10) with ESMTP id i7KBlT2M020509; Fri, 20 Aug 2004 13:47:30 +0200 Received: (from venaas@localhost) by sverresborg.uninett.no (8.12.8/8.12.8/Submit) id i7KBlSPO014932; Fri, 20 Aug 2004 13:47:28 +0200 X-Authentication-Warning: sverresborg.uninett.no: venaas set sender to Stig.Venaas@uninett.no using -f Date: Fri, 20 Aug 2004 13:47:28 +0200 From: Stig Venaas To: "JINMEI Tatuya / ?$B?@L@C#:H" Subject: Re: [dhcwg] comments on draft-ietf-dhc-lifetime-01.txt Message-ID: <20040820114728.GC14315@sverresborg.uninett.no> References: <000001c48073$af492fa0$d0412ca1@amer.cisco.com> <200408121018.57077.jdq@lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Cc: dhcwg@ietf.org, tjc@ecs.soton.ac.uk, jdq@lucent.com, Bernie Volz X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org On Tue, Aug 17, 2004 at 05:45:05PM +0900, JINMEI Tatuya / ?$B?@L@C#:H wrote: > >>>>> On Thu, 12 Aug 2004 10:18:57 -0400, > >>>>> Joe Quanaim said: > > >> The primary motivation for the lifetime option is for situations where > >> no lifetime (or renewal time) is communicated to the client, such as for > >> Stateless DHCP service as specified in [RFC 3736]. However, it applies > >> to both stateful and stateless DHCP clients and is an upper bound for > >> when a client should initiate renewal of at least its non-address based > >> configuration parameters - a stateful client MAY renew its addresses at > >> the same time and SHOULD always get updated configuration data from the > >> server when it renews any addresses. > >> > >> One difference between Stateful and Stateless clients with regards > >> to this option is that a Stateful client that does not receive this > >> option MUST NOT apply the default lifetime. > > > As noted, the motivation of the lifetime option is to ensure stateless clients > > receive current configuration information. As such, I think keeping it out > > of stateful configuration is the simplest approach. As we have discussed, > > stateful configuration already has several variables to manipulate client > > behavior. I do not see much gain in adding another. > > It's not a strong opinion, but I'd also still prefer to restrict the > use of the lifetime option to the stateless case. The reasons are: I think we should come to a decision and proceed. I've given this some more thought, and personally I don't mind restricting it to stateless. I'm not sure I like using the term stateless though. I suggest saying that the option should only be used in replies to Information-Request messages. This solves the stateless renumbering issue we set out to solve. > - even if it might be true that the client can use stateful exchanges > without having addresses or infinite T1/T2 timers for other > configurations only, it should be a very minor case (I'm pretty sure > that everyone agrees on this - whether still want to allow such > usage or not). In my understanding, the sense of RFC3315 is that > "if you can get an address, you may get other information. If you > cannot get an address, then give up any possible information." In > fact, Section 18.1.8 says > > [...] If the client receives no addresses in > any of the IAs, it may either try another server (perhaps restarting > the DHCP server discovery process) or use the Information-request > message to obtain other configuration information only. > > but the RFC does not (explicitly) allow the client to continue to > use other information configuration than addresses. What you are > going to achieve in the scenario of the lifetime option with the > stateful case seems to contradict the original sense, IMO. > > - recalling that we rejected the idea of multiple lifetime options for > multiple configuration parameters, it's odd to me that we are now > going to have T1/T2 as well as the lifetime option (I was happy with > rejecting the idea of multiple lifetimes, BTW). If we applied the > same logic, we could simply use an appropriate T1 value to implement > controlled update of the other configuration information. Again, > it's true that stateful exchanges can provide no finite timers, > but, as I said in the above bullet, it's very minor or even > almost-unexpected use case in my understanding. I agree with this. At least it's my understanding that when renewing the address the client should also update other info. > - as I pointed out in my first message, we'll have to define all the > details, most of which are boring corner cases (but the implementors > would be unhappy if we didn't define those). I know some of you are > now trying to address those, and trying to minimize the complexity > of the specification. However, right now I'm not sure if it really > makes sense, considering the usage case of stateful+lifetime is > minor. I admit this is a tradeoff issue, and perhaps we need to > end up discussing details to make a clear consensus. Yes, it might be just corner cases. I guess the scope of the option could be expanded later if needed. It's better to do that later, than possibly making the scope too large now. > - one thing I'm concerned about which is related to the above point: > there is already a non-address IA that has a notion of timeout: > IA_PD. So, we'll probably have to consider the combination of IA_PD > and the lifetime option. Moreover, the lifetime option document may > need to be generic enough to prepare for any future stateful > resources that has a notion of timeout. Right. > > Still, it's not that complex a change. If I am outvoted, so be it. > > Same here. Though I'm still skeptical about the benefit of the use > case of stateful+lifetime, considering the possible complexity, I can > live with that if the specification is crystal clear about all the > details. I must say I don't quite understand why it is so difficult. OTOH it seems I have some problems explaining clearly how I think it should work, so perhaps it is complex after all (; Well, are you happy with limiting it to replies to Information-Request then? Has anyone got big problems with that? If there are no major objections I'll propose some text to you, to make sure we are in agreement. Thanks for all the input. I hope to go through the issues, proposing text and hopefully have concencus on how to resolve it so that I can put out a new and hopefully final version soon. Stig _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri Aug 20 09:17:57 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11616; Fri, 20 Aug 2004 09:17:56 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1By8tl-0007lH-AD; Fri, 20 Aug 2004 08:53:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1By8lQ-00054y-Ln for dhcwg@megatron.ietf.org; Fri, 20 Aug 2004 08:45:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09941 for ; Fri, 20 Aug 2004 08:44:53 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1By8rv-0006cR-S9 for dhcwg@ietf.org; Fri, 20 Aug 2004 08:51:47 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-1.cisco.com with ESMTP; 20 Aug 2004 05:48:51 -0700 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i7KCiGIU000114; Fri, 20 Aug 2004 05:44:17 -0700 (PDT) Received: from volzw2k (che-vpn-cluster-1-84.cisco.com [10.86.240.84]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AKZ29103; Fri, 20 Aug 2004 08:44:15 -0400 (EDT) From: "Bernie Volz" To: "'Stig Venaas'" , "'JINMEI Tatuya / ?$B?@L@C#:H'" Subject: RE: [dhcwg] comments on draft-ietf-dhc-lifetime-01.txt Date: Fri, 20 Aug 2004 08:44:14 -0400 Organization: Cisco Message-ID: <000e01c486b3$66af02b0$6401a8c0@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.5709 In-Reply-To: <20040820114728.GC14315@sverresborg.uninett.no> X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4939.300 Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 7e439b86d3292ef5adf93b694a43a576 Content-Transfer-Encoding: quoted-printable Cc: dhcwg@ietf.org, tjc@ecs.soton.ac.uk, jdq@lucent.com X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: quoted-printable I'm OK to restricting the Lifetime Option to replies to Information-Request's. The client MUST ignore a Lifetime Option that is in any message other = than a REPLY to an INFORMATION-REQUEST. A client MUST NOT include the Lifetime Option number in an ORO except when sending an INFORMATION-REQUEST = message. The server MUST NOT include the Lifetime Option in any message other = than a REPLY to an INFORMATION-REQUEST. - Bernie > -----Original Message----- > From: Stig Venaas [mailto:Stig.Venaas@uninett.no]=20 > Sent: Friday, August 20, 2004 7:47 AM > To: JINMEI Tatuya / ?$B?@L@C#:H > Cc: jdq@lucent.com; dhcwg@ietf.org; tjc@ecs.soton.ac.uk; Bernie Volz > Subject: Re: [dhcwg] comments on draft-ietf-dhc-lifetime-01.txt >=20 >=20 > On Tue, Aug 17, 2004 at 05:45:05PM +0900, JINMEI Tatuya /=20 > ?$B?@L@C#:H wrote: > > >>>>> On Thu, 12 Aug 2004 10:18:57 -0400, > > >>>>> Joe Quanaim said: > >=20 > > >> The primary motivation for the lifetime option is for situations=20 > > >> where no lifetime (or renewal time) is communicated to=20 > the client,=20 > > >> such as for Stateless DHCP service as specified in [RFC 3736].=20 > > >> However, it applies to both stateful and stateless DHCP=20 > clients and=20 > > >> is an upper bound for when a client should initiate=20 > renewal of at=20 > > >> least its non-address based configuration parameters - a=20 > stateful=20 > > >> client MAY renew its addresses at the same time and=20 > SHOULD always=20 > > >> get updated configuration data from the server when it=20 > renews any=20 > > >> addresses. > > >>=20 > > >> One difference between Stateful and Stateless clients=20 > with regards=20 > > >> to this option is that a Stateful client that does not=20 > receive this=20 > > >> option MUST NOT apply the default lifetime. > >=20 > > > As noted, the motivation of the lifetime option is to ensure=20 > > > stateless clients > > > receive current configuration information. As such, I=20 > think keeping it out=20 > > > of stateful configuration is the simplest approach. As=20 > we have discussed,=20 > > > stateful configuration already has several variables to=20 > manipulate client=20 > > > behavior. I do not see much gain in adding another. > >=20 > > It's not a strong opinion, but I'd also still prefer to=20 > restrict the=20 > > use of the lifetime option to the stateless case. The reasons are: >=20 > I think we should come to a decision and proceed. I've given=20 > this some more thought, and personally I don't mind=20 > restricting it to stateless. I'm not sure I like using the=20 > term stateless though. >=20 > I suggest saying that the option should only be used in=20 > replies to Information-Request messages. This solves the=20 > stateless renumbering issue we set out to solve. >=20 > > - even if it might be true that the client can use stateful=20 > exchanges > > without having addresses or infinite T1/T2 timers for other > > configurations only, it should be a very minor case (I'm=20 > pretty sure > > that everyone agrees on this - whether still want to allow such > > usage or not). In my understanding, the sense of RFC3315 is that > > "if you can get an address, you may get other information. If you > > cannot get an address, then give up any possible information." In > > fact, Section 18.1.8 says > >=20 > > [...] If the client receives no addresses in > > any of the IAs, it may either try another server=20 > (perhaps restarting > > the DHCP server discovery process) or use the=20 > Information-request > > message to obtain other configuration information only. > >=20 > > but the RFC does not (explicitly) allow the client to continue to > > use other information configuration than addresses. What you are > > going to achieve in the scenario of the lifetime option with the > > stateful case seems to contradict the original sense, IMO. > >=20 > > - recalling that we rejected the idea of multiple lifetime=20 > options for > > multiple configuration parameters, it's odd to me that we are now > > going to have T1/T2 as well as the lifetime option (I was=20 > happy with > > rejecting the idea of multiple lifetimes, BTW). If we applied the > > same logic, we could simply use an appropriate T1 value=20 > to implement > > controlled update of the other configuration information. Again, > > it's true that stateful exchanges can provide no finite timers, > > but, as I said in the above bullet, it's very minor or even > > almost-unexpected use case in my understanding. >=20 > I agree with this. At least it's my understanding that when=20 > renewing the address the client should also update other info. >=20 > > - as I pointed out in my first message, we'll have to define all the > > details, most of which are boring corner cases (but the=20 > implementors > > would be unhappy if we didn't define those). I know some=20 > of you are > > now trying to address those, and trying to minimize the complexity > > of the specification. However, right now I'm not sure if=20 > it really > > makes sense, considering the usage case of stateful+lifetime is > > minor. I admit this is a tradeoff issue, and perhaps we need to > > end up discussing details to make a clear consensus. >=20 > Yes, it might be just corner cases. I guess the scope of the=20 > option could be expanded later if needed. It's better to do=20 > that later, than possibly making the scope too large now. >=20 > > - one thing I'm concerned about which is related to the above point: > > there is already a non-address IA that has a notion of timeout: > > IA_PD. So, we'll probably have to consider the=20 > combination of IA_PD > > and the lifetime option. Moreover, the lifetime option=20 > document may > > need to be generic enough to prepare for any future stateful > > resources that has a notion of timeout. >=20 > Right. >=20 > > > Still, it's not that complex a change. If I am outvoted,=20 > so be it. > >=20 > > Same here. Though I'm still skeptical about the benefit of the use=20 > > case of stateful+lifetime, considering the possible=20 > complexity, I can=20 > > live with that if the specification is crystal clear about all the=20 > > details. >=20 > I must say I don't quite understand why it is so difficult.=20 > OTOH it seems I have some problems explaining clearly how I=20 > think it should work, so perhaps it is complex after all (; >=20 > Well, are you happy with limiting it to replies to=20 > Information-Request then? Has anyone got big problems with=20 > that? If there are no major objections I'll propose some text=20 > to you, to make sure we are in agreement. >=20 > Thanks for all the input. I hope to go through the issues,=20 > proposing text and hopefully have concencus on how to resolve=20 > it so that I can put out a new and hopefully final version soon. >=20 > Stig >=20 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri Aug 20 10:07:24 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14457; Fri, 20 Aug 2004 10:07:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1By9eB-0007su-FG; Fri, 20 Aug 2004 09:41:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1By9QQ-0005Ga-Cg for dhcwg@megatron.ietf.org; Fri, 20 Aug 2004 09:27:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12113 for ; Fri, 20 Aug 2004 09:27:15 -0400 (EDT) Received: from tyholt.uninett.no ([158.38.60.10]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1By9Wy-0007MB-2O for dhcwg@ietf.org; Fri, 20 Aug 2004 09:34:09 -0400 Received: from sverresborg.uninett.no (sverresborg.uninett.no [IPv6:2001:700:e000:0:204:75ff:fee4:423b]) by tyholt.uninett.no (8.12.10/8.12.10) with ESMTP id i7KDOs2M012985; Fri, 20 Aug 2004 15:24:54 +0200 Received: (from venaas@localhost) by sverresborg.uninett.no (8.12.8/8.12.8/Submit) id i7KDOpV0015082; Fri, 20 Aug 2004 15:24:51 +0200 X-Authentication-Warning: sverresborg.uninett.no: venaas set sender to Stig.Venaas@uninett.no using -f Date: Fri, 20 Aug 2004 15:24:51 +0200 From: Stig Venaas To: Bernie Volz Subject: Re: [dhcwg] comments on draft-ietf-dhc-lifetime-01.txt Message-ID: <20040820132451.GD14315@sverresborg.uninett.no> References: <20040820114728.GC14315@sverresborg.uninett.no> <000e01c486b3$66af02b0$6401a8c0@amer.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <000e01c486b3$66af02b0$6401a8c0@amer.cisco.com> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: dhcwg@ietf.org, tjc@ecs.soton.ac.uk, jdq@lucent.com X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org On Fri, Aug 20, 2004 at 08:44:14AM -0400, Bernie Volz wrote: > I'm OK to restricting the Lifetime Option to replies to > Information-Request's. > > The client MUST ignore a Lifetime Option that is in any message other than a > REPLY to an INFORMATION-REQUEST. A client MUST NOT include the Lifetime > Option number in an ORO except when sending an INFORMATION-REQUEST message. > > The server MUST NOT include the Lifetime Option in any message other than a > REPLY to an INFORMATION-REQUEST. Right, sounds good. Thanks for the text. This brings up another thing I want to discuss. Is it actually useful for the client to include it in ORO at all? Should the server really care? I can think of basically three options. I'll be a bit vague on the MAY/SHOULD/MUSTs for now. 1. Client may include it. If server sees option it should include it in reply. If server does not see it, it may include it anyway. 2. Client always includes it, and server only includes it in reply if client included it in request. 3. Client never includes it, and server always or never includes it depending on configuration. It would be nice to come to agreement on which alternative is best before trying to formalize things. Personally I think alternative 3 makes sense. That is, if a server implements the option and is configured with some lifetime by the administrator, then it should always include it. If it is not configured by the administrator, then it should not include it, so that clients will just use the default. Or do you see a problem with server including the option when client doesn't implement it? Stig _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri Aug 20 10:47:09 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17795; Fri, 20 Aug 2004 10:47:09 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ByA9W-0001Vs-Rc; Fri, 20 Aug 2004 10:13:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1By9qS-00027k-EB for dhcwg@megatron.ietf.org; Fri, 20 Aug 2004 09:54:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13423 for ; Fri, 20 Aug 2004 09:54:09 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1By9wy-0007pR-Cz for dhcwg@ietf.org; Fri, 20 Aug 2004 10:01:03 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 20 Aug 2004 06:59:14 +0000 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i7KDrWH6010368; Fri, 20 Aug 2004 06:53:33 -0700 (PDT) Received: from volzw2k (che-vpn-cluster-1-84.cisco.com [10.86.240.84]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AKZ33480; Fri, 20 Aug 2004 09:53:31 -0400 (EDT) From: "Bernie Volz" To: "'Stig Venaas'" Subject: RE: [dhcwg] comments on draft-ietf-dhc-lifetime-01.txt Date: Fri, 20 Aug 2004 09:53:31 -0400 Organization: Cisco Message-ID: <001d01c486bd$13f1c850$6401a8c0@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.5709 In-Reply-To: <20040820132451.GD14315@sverresborg.uninett.no> X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4939.300 Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Content-Transfer-Encoding: quoted-printable Cc: dhcwg@ietf.org, tjc@ecs.soton.ac.uk, jdq@lucent.com X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: quoted-printable YES! The client MUST include this in the ORO if it is interested in the parameter. Ted discussed this on the mailing list a few weeks back - = that options really must be in the ORO. And, I do agree with him that this is = the best policy. If I recall correctly, Ted stated that if a client "wants" an option, it MUST include it in the ORO. A server MUST return any options for which it has information if they = are in the ORO. A server MAY include other options that are not in the ORO BUT there is NO requirement that it must do so. Note that there are a few exceptions, such as Client-ID, Server-ID, = IA_NA, IA_TA, IAADDR, ... as these are protocol options. So, by this rule, the client MUST include it in the ORO to assure it = gets it if configured and supported by the server. - Bernie > -----Original Message----- > From: Stig Venaas [mailto:Stig.Venaas@uninett.no]=20 > Sent: Friday, August 20, 2004 9:25 AM > To: Bernie Volz > Cc: 'JINMEI Tatuya / ?$B?@L@C#:H'; jdq@lucent.com;=20 > dhcwg@ietf.org; tjc@ecs.soton.ac.uk > Subject: Re: [dhcwg] comments on draft-ietf-dhc-lifetime-01.txt >=20 >=20 > On Fri, Aug 20, 2004 at 08:44:14AM -0400, Bernie Volz wrote: > > I'm OK to restricting the Lifetime Option to replies to=20 > > Information-Request's. > >=20 > > The client MUST ignore a Lifetime Option that is in any=20 > message other=20 > > than a REPLY to an INFORMATION-REQUEST. A client MUST NOT=20 > include the=20 > > Lifetime Option number in an ORO except when sending an=20 > > INFORMATION-REQUEST message. > >=20 > > The server MUST NOT include the Lifetime Option in any=20 > message other=20 > > than a REPLY to an INFORMATION-REQUEST. >=20 > Right, sounds good. Thanks for the text. >=20 > This brings up another thing I want to discuss. >=20 > Is it actually useful for the client to include it in ORO at=20 > all? Should the server really care? >=20 > I can think of basically three options. I'll be a bit vague=20 > on the MAY/SHOULD/MUSTs for now. >=20 > 1. Client may include it. If server sees option it should include > it in reply. If server does not see it, it may include it anyway. >=20 > 2. Client always includes it, and server only includes it in reply if > client included it in request. >=20 > 3. Client never includes it, and server always or never includes it > depending on configuration. >=20 > It would be nice to come to agreement on which alternative is=20 > best before trying to formalize things. >=20 >=20 > Personally I think alternative 3 makes sense. >=20 > That is, if a server implements the option and is configured=20 > with some lifetime by the administrator, then it should=20 > always include it. >=20 > If it is not configured by the administrator, then it should=20 > not include it, so that clients will just use the default. >=20 > Or do you see a problem with server including the option when=20 > client doesn't implement it? >=20 > Stig >=20 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri Aug 20 11:05:45 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19173; Fri, 20 Aug 2004 11:05:45 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ByAde-00013k-Ef; Fri, 20 Aug 2004 10:45:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ByA8Y-0001DF-Dh for dhcwg@megatron.ietf.org; Fri, 20 Aug 2004 10:12:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15105 for ; Fri, 20 Aug 2004 10:12:51 -0400 (EDT) Received: from tyholt.uninett.no ([158.38.60.10]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1ByAF4-0008Bo-GI for dhcwg@ietf.org; Fri, 20 Aug 2004 10:19:45 -0400 Received: from sverresborg.uninett.no (sverresborg.uninett.no [IPv6:2001:700:e000:0:204:75ff:fee4:423b]) by tyholt.uninett.no (8.12.10/8.12.10) with ESMTP id i7KEB32M024323; Fri, 20 Aug 2004 16:11:03 +0200 Received: (from venaas@localhost) by sverresborg.uninett.no (8.12.8/8.12.8/Submit) id i7KEB29h015172; Fri, 20 Aug 2004 16:11:02 +0200 X-Authentication-Warning: sverresborg.uninett.no: venaas set sender to Stig.Venaas@uninett.no using -f Date: Fri, 20 Aug 2004 16:11:02 +0200 From: Stig Venaas To: Bernie Volz Subject: Re: [dhcwg] comments on draft-ietf-dhc-lifetime-01.txt Message-ID: <20040820141102.GE14315@sverresborg.uninett.no> References: <20040820132451.GD14315@sverresborg.uninett.no> <001d01c486bd$13f1c850$6401a8c0@amer.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <001d01c486bd$13f1c850$6401a8c0@amer.cisco.com> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: dhcwg@ietf.org, tjc@ecs.soton.ac.uk, jdq@lucent.com X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org On Fri, Aug 20, 2004 at 09:53:31AM -0400, Bernie Volz wrote: > YES! The client MUST include this in the ORO if it is interested in the > parameter. Ted discussed this on the mailing list a few weeks back - that > options really must be in the ORO. And, I do agree with him that this is the > best policy. > > If I recall correctly, Ted stated that if a client "wants" an option, it > MUST include it in the ORO. I apologize for my ignorance, I don't know DHCP well enough. I found and read Ted's mail now. I see how it simplifies server implementation. I think I have enough input to propose new text for the draft now. I'll post a proposal soon. Thanks for your input and patience, Stig _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri Aug 20 11:38:08 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21897; Fri, 20 Aug 2004 11:38:08 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ByB2z-0008TY-F7; Fri, 20 Aug 2004 11:11:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ByAov-0003lZ-AB for dhcwg@megatron.ietf.org; Fri, 20 Aug 2004 10:56:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18319 for ; Fri, 20 Aug 2004 10:56:37 -0400 (EDT) Received: from ihemail1.lucent.com ([192.11.222.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1ByAvT-0000b7-S9 for dhcwg@ietf.org; Fri, 20 Aug 2004 11:03:33 -0400 Received: from homail.ho.lucent.com (h135-17-192-10.lucent.com [135.17.192.10]) by ihemail1.lucent.com (8.12.11/8.12.11) with ESMTP id i7KEtVAS013197; Fri, 20 Aug 2004 09:55:31 -0500 (CDT) Received: from kraken.mh.lucent.com by homail.ho.lucent.com (8.11.7+Sun/EMS-1.5 sol2) id i7KEtUo15967; Fri, 20 Aug 2004 10:55:30 -0400 (EDT) From: Joe Quanaim To: "Bernie Volz" , "'Stig Venaas'" , "'JINMEI Tatuya / ?$B?@L@C#:H'" Subject: Re: [dhcwg] comments on draft-ietf-dhc-lifetime-01.txt Date: Fri, 20 Aug 2004 10:55:04 -0400 User-Agent: KMail/1.5.4 References: <000e01c486b3$66af02b0$6401a8c0@amer.cisco.com> In-Reply-To: <000e01c486b3$66af02b0$6401a8c0@amer.cisco.com> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200408201053.49786.jdq@lucent.com> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org, tjc@ecs.soton.ac.uk X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jdq@lucent.com List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 7bit Bernie Volz wrote: > I'm OK to restricting the Lifetime Option to replies to > Information-Request's. > > The client MUST ignore a Lifetime Option that is in any message other than > a REPLY to an INFORMATION-REQUEST. A client MUST NOT include the Lifetime > Option number in an ORO except when sending an INFORMATION-REQUEST message. > > The server MUST NOT include the Lifetime Option in any message other than a > REPLY to an INFORMATION-REQUEST. This sounds good to me. Also, did we reach consensus on a default value? This seems like the appropriate place to mention it: If a client requests a Lifetime Option and does not receive one in the reply, it should use the default value of n hours. Or something to that effect... Joe. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri Aug 20 12:48:29 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26554; Fri, 20 Aug 2004 12:48:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ByBVo-0006qi-7d; Fri, 20 Aug 2004 11:41:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ByB4o-0000nv-HN for dhcwg@megatron.ietf.org; Fri, 20 Aug 2004 11:13:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19848 for ; Fri, 20 Aug 2004 11:13:02 -0400 (EDT) Received: from tyholt.uninett.no ([158.38.60.10]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1ByBBL-000135-1F for dhcwg@ietf.org; Fri, 20 Aug 2004 11:19:58 -0400 Received: from sverresborg.uninett.no (sverresborg.uninett.no [IPv6:2001:700:e000:0:204:75ff:fee4:423b]) by tyholt.uninett.no (8.12.10/8.12.10) with ESMTP id i7KF8G2M005146; Fri, 20 Aug 2004 17:08:16 +0200 Received: (from venaas@localhost) by sverresborg.uninett.no (8.12.8/8.12.8/Submit) id i7KF8F1q015281; Fri, 20 Aug 2004 17:08:15 +0200 X-Authentication-Warning: sverresborg.uninett.no: venaas set sender to Stig.Venaas@uninett.no using -f Date: Fri, 20 Aug 2004 17:08:15 +0200 From: Stig Venaas To: Joe Quanaim Subject: Re: [dhcwg] comments on draft-ietf-dhc-lifetime-01.txt Message-ID: <20040820150815.GG14315@sverresborg.uninett.no> References: <000e01c486b3$66af02b0$6401a8c0@amer.cisco.com> <200408201053.49786.jdq@lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200408201053.49786.jdq@lucent.com> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: dhcwg@ietf.org, tjc@ecs.soton.ac.uk, Bernie Volz X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org On Fri, Aug 20, 2004 at 10:55:04AM -0400, Joe Quanaim wrote: > Bernie Volz wrote: > > I'm OK to restricting the Lifetime Option to replies to > > Information-Request's. > > > > The client MUST ignore a Lifetime Option that is in any message other than > > a REPLY to an INFORMATION-REQUEST. A client MUST NOT include the Lifetime > > Option number in an ORO except when sending an INFORMATION-REQUEST message. > > > > The server MUST NOT include the Lifetime Option in any message other than a > > REPLY to an INFORMATION-REQUEST. > > This sounds good to me. > > Also, did we reach consensus on a default value? This seems like the > appropriate place to mention it: > > If a client requests a Lifetime Option and does not receive one in the reply, > it should use the default value of n hours. > > Or something to that effect... Yes, I've already written some text to that effect, it's not done. What I have so far is: In some cases a default lifetime LT_DEFAULT is used. The recommended value for LT_DEFAULT is 21600 (6 hours). I just took 6 out of the air, input needed. and then under client behaviour: A client implementing this option MUST when a reply to an Information-Request message does not contain the option, behave as if the option with value LT_DEFAULT was provided. A client MUST also use the default lifetime LT_DEFAULT if the value of the option is zero. If client has received a lifetime with this option, and contacts server to receive new or update any existing data prior to its expiration, it SHOULD also update data covered by this option. If no new lifetime is received, it MUST use the default lifetime LT_DEFAULT. I need to work a bit more on the text, but let me know if this is not in line with what you think. Stig _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri Aug 20 14:49:44 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05350; Fri, 20 Aug 2004 14:49:44 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ByDwz-0003wa-GN; Fri, 20 Aug 2004 14:17:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ByCW1-0001fK-U7 for dhcwg@megatron.ietf.org; Fri, 20 Aug 2004 12:45:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25915 for ; Fri, 20 Aug 2004 12:45:14 -0400 (EDT) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1ByCcd-00030K-5J for dhcwg@ietf.org; Fri, 20 Aug 2004 12:52:11 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 20 Aug 2004 12:55:07 -0400 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i7KGieY3009494; Fri, 20 Aug 2004 12:44:41 -0400 (EDT) Received: from volzw2k (che-vpn-cluster-1-84.cisco.com [10.86.240.84]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AKZ47834; Fri, 20 Aug 2004 12:44:38 -0400 (EDT) From: "Bernie Volz" To: "'Stig Venaas'" , "'Joe Quanaim'" Subject: RE: [dhcwg] comments on draft-ietf-dhc-lifetime-01.txt Date: Fri, 20 Aug 2004 12:44:38 -0400 Organization: Cisco Message-ID: <002e01c486d4$fd93d810$6401a8c0@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.5709 In-Reply-To: <20040820150815.GG14315@sverresborg.uninett.no> X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4939.300 Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 Content-Transfer-Encoding: quoted-printable Cc: dhcwg@ietf.org, tjc@ecs.soton.ac.uk X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: quoted-printable While the load on a server for processing Information-Requests should be relatively small, why use a default that is so short? This means that in = a typical working day (8 or more hours) while you've connected your laptop = at work, it will get the parameters when you first connect and at LEAST = once more. If we're to believe there will be billions of IPv6 devices and a = sizeable fraction will use stateless, why have all of this DHCP traffic? The lifetime mechanism MUST NOT be used in place of redundancy - if = you're only going to have one DNS resolving server, you're asking for trouble = and using this lifetime option to work aroud failures is NOT correct. This information should generally be valid for LONG time periods unless = a site has an explicit need to refresh this information more frequently, = in which case the server should be configured with the desired value. Personally I would like to see a DEFAULT lifetime of NOT LESS than 12 = hours. (Most operational network use a day to a week for lease times from my expierence.) Ask yourself what are typical LEASE times and cut these in half. Or, if = you have data on typical address LIFETIMES for IPv6 addresses, use these = values. And, remember we're specifying the DEFAULT. If a server administrator = wants to reduce this, she is free to do so. I also believe we should, in order to prevent Denial-of-Service attacks = or "Information-Request" storms, specify a LOWER BOUND of something like 10 minutes. And, the lifetime option shouldn't be the only trigger a client uses to refresh this information. Connecting a network cable to the client, significant changes in the prefixes active on the link, etc. are all = other considerations that a client SHOULD use to trigger refreshing this information. The lifetime should only apply to very STATIC situations - where the client isn't mobile and the network addresses don't change. - Bernie > -----Original Message----- > From: Stig Venaas [mailto:Stig.Venaas@uninett.no]=20 > Sent: Friday, August 20, 2004 11:08 AM > To: Joe Quanaim > Cc: Bernie Volz; 'JINMEI Tatuya / ?$B?@L@C#:H';=20 > dhcwg@ietf.org; tjc@ecs.soton.ac.uk > Subject: Re: [dhcwg] comments on draft-ietf-dhc-lifetime-01.txt >=20 >=20 > On Fri, Aug 20, 2004 at 10:55:04AM -0400, Joe Quanaim wrote: > > Bernie Volz wrote: > > > I'm OK to restricting the Lifetime Option to replies to=20 > > > Information-Request's. > > > > > > The client MUST ignore a Lifetime Option that is in any message=20 > > > other than a REPLY to an INFORMATION-REQUEST. A client MUST NOT=20 > > > include the Lifetime Option number in an ORO except when=20 > sending an=20 > > > INFORMATION-REQUEST message. > > > > > > The server MUST NOT include the Lifetime Option in any=20 > message other=20 > > > than a REPLY to an INFORMATION-REQUEST. > >=20 > > This sounds good to me. > >=20 > > Also, did we reach consensus on a default value? This=20 > seems like the > > appropriate place to mention it: > >=20 > > If a client requests a Lifetime Option and does not receive=20 > one in the=20 > > reply, > > it should use the default value of n hours. > >=20 > > Or something to that effect... >=20 > Yes, I've already written some text to that effect, it's not=20 > done. What I have so far is: >=20 > In some cases a default lifetime LT_DEFAULT is used. > The recommended value for LT_DEFAULT is 21600 (6 hours). >=20 > I just took 6 out of the air, input needed. >=20 > and then under client behaviour: >=20 > A client implementing this option MUST when a reply to an > Information-Request message does not contain the option, behave > as if the option with value LT_DEFAULT was provided. >=20 > A client MUST also use the default lifetime LT_DEFAULT if the > value of the option is zero. >=20 > If client has received a lifetime with this option, and contacts > server to receive new or update any existing data prior to its > expiration, it SHOULD also update data covered by this option. > If no new lifetime is received, it MUST use the default lifetime > LT_DEFAULT. >=20 > I need to work a bit more on the text, but let me know if=20 > this is not in line with what you think. >=20 > Stig >=20 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Sun Aug 22 20:57:11 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29607; Sun, 22 Aug 2004 20:57:11 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bz2qY-0007Sy-Jx; Sun, 22 Aug 2004 20:38:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bz2en-0006XZ-6P for dhcwg@megatron.ietf.org; Sun, 22 Aug 2004 20:25:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28440 for ; Sun, 22 Aug 2004 20:25:46 -0400 (EDT) Received: from zrtps0kn.nortelnetworks.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bz2et-0007uI-S8 for dhcwg@ietf.org; Sun, 22 Aug 2004 20:26:01 -0400 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps0kn.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i7N0OpG27539; Sun, 22 Aug 2004 20:24:52 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Sun, 22 Aug 2004 20:24:52 -0400 Message-ID: <591B780D9676844E8A704B5B013FFE92026F3BFD@zrc2hxm1.corp.nortel.com> From: "Kuntal Chowdhury" To: dhcwg@ietf.org Date: Sun, 22 Aug 2004 20:24:46 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: pyegani@cisco.com, Ralph Droms , ac@qualcomm.com, "Lila Madour \(QA/EMC\)" Subject: [dhcwg] (no subject) X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Hi all, -01 version of the BCMCS DHC options are now available: http://www.ietf.org/internet-drafts/draft-chowdhury-dhc-bcmcv6-option-01.txt http://www.ietf.org/internet-drafts/draft-chowdhury-dhc-bcmcv4-option-01.txt We have simplified the figure, removed FQDN compression requirement for v6 option, fixed the FQDN example in both the drafts. Thanks to Ralph Dorms, Ted Lemon and Bernie Volz for their review and comments. Regards, Kuntal _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon Aug 23 04:24:21 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20326; Mon, 23 Aug 2004 04:24:21 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bz9pq-0003L6-Hr; Mon, 23 Aug 2004 04:05:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bz9cq-0001hh-UV for dhcwg@megatron.ietf.org; Mon, 23 Aug 2004 03:52:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18771 for ; Mon, 23 Aug 2004 03:52:14 -0400 (EDT) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bz9d1-0006wr-Jn for dhcwg@ietf.org; Mon, 23 Aug 2004 03:52:32 -0400 Received: from ocean.jinmei.org (unknown [2001:200:0:8002:d496:d9ca:8037:c688]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 9A71A1525D; Mon, 23 Aug 2004 16:52:11 +0900 (JST) Date: Mon, 23 Aug 2004 16:52:10 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: "Bernie Volz" Subject: Re: [dhcwg] comments on draft-ietf-dhc-lifetime-01.txt In-Reply-To: <000e01c486b3$66af02b0$6401a8c0@amer.cisco.com> References: <20040820114728.GC14315@sverresborg.uninett.no> <000e01c486b3$66af02b0$6401a8c0@amer.cisco.com> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: dhcwg@ietf.org, tjc@ecs.soton.ac.uk, "'Stig Venaas'" , jdq@lucent.com X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org >>>>> On Fri, 20 Aug 2004 08:44:14 -0400, >>>>> "Bernie Volz" said: > I'm OK to restricting the Lifetime Option to replies to > Information-Request's. > The client MUST ignore a Lifetime Option that is in any message other than a > REPLY to an INFORMATION-REQUEST. A client MUST NOT include the Lifetime > Option number in an ORO except when sending an INFORMATION-REQUEST message. > The server MUST NOT include the Lifetime Option in any message other than a > REPLY to an INFORMATION-REQUEST. I'm happy with this (of course). Alternatively, if someone feels it is too restrictive, I guess we could also say the use of the lifetime option in solicit/advertise/... exchanges is beyond the scope of the document. This way we can implicitly tell implementors that they can only concentrate on the usage for information-requests while leaving a future possibility of extension. (just a thought, not intending to introduce further confusion...) 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-bounces@ietf.org Mon Aug 23 05:41:01 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24344; Mon, 23 Aug 2004 05:41:01 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BzBAK-0003Vp-OV; Mon, 23 Aug 2004 05:31:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BzB3D-0002dc-00 for dhcwg@megatron.ietf.org; Mon, 23 Aug 2004 05:23:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23624 for ; Mon, 23 Aug 2004 05:23:31 -0400 (EDT) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BzB3P-0000Pm-01 for dhcwg@ietf.org; Mon, 23 Aug 2004 05:23:51 -0400 Received: from ocean.jinmei.org (unknown [2001:200:0:8002:d496:d9ca:8037:c688]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 38DA51525D; Mon, 23 Aug 2004 18:23:31 +0900 (JST) Date: Mon, 23 Aug 2004 18:23:30 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Stig Venaas In-Reply-To: <20040803033357.GA20506@sverresborg.uninett.no> References: <20040803033357.GA20506@sverresborg.uninett.no> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 Cc: dhcwg@ietf.org, tjc@ecs.soton.ac.uk Subject: [dhcwg] behavior on lifetime expiration (Re: comments on draft-ietf-dhc-lifetime-01.txt) X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org (Sorry for the delay in response) I've changed the title since I'm concentrating on this particular issue. Instead of making a response to each sub-issue (attached below), let me raise a more fundamental concern. Perhaps I'm just pedantic, but the current behavior of the lifetime option, however clearly it is defined, does not sound like a "lifetime" that I would envision. To me, if a lifetime of some information expires, the information should be invalid (in some sense). But the current behavior described in dhc-lifetime-01 does not seem to invalidate the information in any way; the "lifetime" would rather seem like an "update timer" or something. One obvious "fix" to this is to change the option name to something like "Information Update Timer" option (too long?). However, I personally would like to leave the possibility of invalidating the information on lifetime expiry. With this sense I'd imagine something like this: - the option name ("lifetime option") is the same - the client starts re-sending Information-Requests at some point in time to the expiration. (e.g. a half of the lifetime) - even if the clients cannot get a response by the expiration, it should continue sending Information-requests. However, it can also invalidate the expired information in some way, e.g., by preferring a "last resort" default or by using other means of configuration. What do others think? JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp >>>>> On Tue, 3 Aug 2004 05:33:57 +0200, >>>>> Stig Venaas said: >> Hoping it's not too late, here a couple of comments (or questions, >> actually) on the draft. >> >> 1. I'm still not really sure what the client should do for information >> when a lifetime expires. >> >> For example, the draft says in Section 3.1 that >> >> If client has received a lifetime with this option, and contacts >> server to receive new or update any existing data prior to its >> expiration, it SHOULD also update data covered by this option. If no >> new lifetime is received, it MUST behave as if no value was ever >> provided. >> >> I don't understand the scenario. Does this mean the following case? >> >> - The client sends an Information-request message, and gets a reply >> with a DNS server address (call it X) with lifetime of 1 hour. >> - 30 minutes later, the client happens to resend an >> Information-request message. This time, it gets a response, but >> the response does not contain either DNS server address X or a new >> lifetime. >> >> If this is an intended scenario, then what does "behave as if no >> value was ever provided"? Does it mean the client MUST treat >> address X as if it had infinite lifetime? Or does this mean the >> client MUST regard address X expired immediately? Or something >> else? > I'm open for anything. But my intention is that client behaves as if > it didn't get a lifetime in the first place. That is, just like it would > behave if it doesn't know a specific lifetime. Whether it's infinite or > not, depends on the client. > I don't think this scenario will be common anyway, but we should say > something. My thinking is that the last response is the authoritative > one, so new lifetime value overrides the old, and no lifetime means > ignore the old and behave like you haven't ever seen one. > Another option would be to keep using the last seen lifetime until > expiry, but I'm not sure that's better. > Very happy to see suggestions for alternative behaviour, or for text > changes that makes it more clear. >> Also, I don't understand what the client should do with DNS server >> address X when the lifetime expires and the client does not get any >> reply for the try to update the information. Should the client >> invalidate address X? Can/should it continue to use it? > I think it can be left to the client. The client will retry for a long > period of time, and would usually get updated info; the lifetime simply > says when to start this process. So you're talking about a rare failure > case. I think it's sensible to keep using the info, at least if there > is nothing to fall back to. > I'm thinking of the option as a hint to the client when it should try > to update the info. I'm not sure if we need to specify the failure > modes in detail. >> Even if the client can update the information of address X with a >> new lifetime, how can we regard the period from the time when the >> previous lifetime expires and the time when the client gets the new >> information? Should we temporarily invalidate the address during >> the update period? Or Can we continue to use it? Probably the >> latter makes sense when the client can update the information, but >> it does not really match my intuition of "expiration"... > My intention is definitely that you should continue using it. I guess > that should be made clear. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon Aug 23 05:49:24 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24806; Mon, 23 Aug 2004 05:49:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BzBE1-0003t8-Hr; Mon, 23 Aug 2004 05:34:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BzB7B-0002zE-EW for dhcwg@megatron.ietf.org; Mon, 23 Aug 2004 05:27:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23853 for ; Mon, 23 Aug 2004 05:27:38 -0400 (EDT) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BzB7N-0000Te-05 for dhcwg@ietf.org; Mon, 23 Aug 2004 05:27:58 -0400 Received: from ocean.jinmei.org (unknown [2001:200:0:8002:d496:d9ca:8037:c688]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id C24491525D for ; Mon, 23 Aug 2004 18:27:37 +0900 (JST) Date: Mon, 23 Aug 2004 18:27:37 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: dhcwg@ietf.org Subject: Re: [dhcwg] Re: one more comment about the lifetime option In-Reply-To: References: <20040803171447.GA27805@sverresborg.uninett.no> <4.3.2.7.2.20040803135851.02af6cb0@flask.cisco.com> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org >>>>> On Thu, 05 Aug 2004 02:03:03 +0900, >>>>> JINMEI Tatuya said: >> I agree with Stig - we've discussed this issue before and come to the >> conclusion that there is little extra overhead in delivering information >> that has not changed, so there should be a single lifetime - chosen to be >> the shortest lifetome of any of the client's parameters. > Okay, I'm fine with the "singe lifetime for all option parameters" > approach. In fact, I was just wondering without any particular > preference. > But I want the document to be more specific on this point because > other readers might wonder the same point. We should also restrict the position where the lifetime option can appear: it should only be able to appear at the "top level" of option hierarchy. In other wise, it must not appear as a sub-option of another option. 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-bounces@ietf.org Mon Aug 23 11:19:24 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15803; Mon, 23 Aug 2004 11:19:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BzGCT-0001Lm-A6; Mon, 23 Aug 2004 10:53:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BzFoS-0005OZ-Du for dhcwg@megatron.ietf.org; Mon, 23 Aug 2004 10:28:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11865 for ; Mon, 23 Aug 2004 10:28:37 -0400 (EDT) Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BzFoe-00068E-Jj for dhcwg@ietf.org; Mon, 23 Aug 2004 10:28:59 -0400 Received: from [10.0.1.19] (dpc6935208055.direcpc.com [69.35.208.55]) by toccata.fugue.com (Postfix) with ESMTP id 417251B205C for ; Mon, 23 Aug 2004 09:28:19 -0500 (CDT) Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: References: <20040803033357.GA20506@sverresborg.uninett.no> Content-Type: text/plain; charset=ISO-2022-JP; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Ted Lemon Subject: Re: [dhcwg] behavior on lifetime expiration (Re: comments on draft-ietf-dhc-lifetime-01.txt) Date: Mon, 23 Aug 2004 10:28:12 -0400 To: dhcwg@ietf.org X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 7bit On Aug 23, 2004, at 5:23 AM, JINMEI Tatuya / $B?@L@C#:H(B wrote: > - even if the clients cannot get a response by the expiration, it > should continue sending Information-requests. However, it can also > invalidate the expired information in some way, e.g., by preferring > a "last resort" default or by using other means of configuration. Can you think of a real-world scenario where this would be the right thing to do? I can't come up with one. For example, if we wanted to fall back to some sort of link-local protocol, this wouldn't help us, because it would take too long. I think that in just about any scenario where you'd think to benefit by switching to some other configuration scheme, the switch would happen much too late, using this mechanism, to be of any benefit. So I think that we'd really be better off, as you suggest, renaming this the update timer. If there's some other configuration mechanism to which we should fall back, I think we need another mechanism for deciding when to fall back to it, and that should probably be specified in the draft that describes the fallback mechanism. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon Aug 23 11:20:09 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15894; Mon, 23 Aug 2004 11:20:09 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BzGCT-0001M5-NX; Mon, 23 Aug 2004 10:53:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BzFq6-0005w6-OV for dhcwg@megatron.ietf.org; Mon, 23 Aug 2004 10:30:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12030 for ; Mon, 23 Aug 2004 10:30:19 -0400 (EDT) Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BzFqL-0006AH-02 for dhcwg@ietf.org; Mon, 23 Aug 2004 10:30:42 -0400 Received: from [10.0.1.19] (dpc6935208055.direcpc.com [69.35.208.55]) by toccata.fugue.com (Postfix) with ESMTP id 92F981B226B; Mon, 23 Aug 2004 09:30:05 -0500 (CDT) In-Reply-To: References: <20040803171447.GA27805@sverresborg.uninett.no> <4.3.2.7.2.20040803135851.02af6cb0@flask.cisco.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=ISO-2022-JP; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Ted Lemon Subject: Re: [dhcwg] Re: one more comment about the lifetime option Date: Mon, 23 Aug 2004 10:30:03 -0400 To: =?ISO-2022-JP?B?SklOTUVJIFRhdHV5YSAvIBskQj9ATEBDIzpIGyhC?= X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 7bit On Aug 23, 2004, at 5:27 AM, JINMEI Tatuya / $B?@L@C#:H(B wrote: > We should also restrict the position where the lifetime option can > appear: it should only be able to appear at the "top level" of option > hierarchy. I think this is a good idea. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon Aug 23 11:34:14 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16808; Mon, 23 Aug 2004 11:34:14 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BzGG4-00029v-Pj; Mon, 23 Aug 2004 10:57:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BzG6h-00008l-A7 for dhcwg@megatron.ietf.org; Mon, 23 Aug 2004 10:47:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13395 for ; Mon, 23 Aug 2004 10:47:27 -0400 (EDT) Received: from ihemail1.lucent.com ([192.11.222.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BzG6w-0006Sv-9K for dhcwg@ietf.org; Mon, 23 Aug 2004 10:47:51 -0400 Received: from homail.ho.lucent.com (h135-17-192-10.lucent.com [135.17.192.10]) by ihemail1.lucent.com (8.12.11/8.12.11) with ESMTP id i7NEkSat002790; Mon, 23 Aug 2004 09:46:38 -0500 (CDT) Received: from kraken.mh.lucent.com by homail.ho.lucent.com (8.11.7+Sun/EMS-1.5 sol2) id i7NEkQU04090; Mon, 23 Aug 2004 10:46:26 -0400 (EDT) From: Joe Quanaim To: JINMEI Tatuya / =?utf-8?q?=E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89=09?=, Stig Venaas Subject: Re: [dhcwg] behavior on lifetime expiration (Re: comments on draft-ietf-dhc-lifetime-01.txt) Date: Mon, 23 Aug 2004 10:45:02 -0400 User-Agent: KMail/1.5.4 References: <20040803033357.GA20506@sverresborg.uninett.no> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200408231045.02340.jdq@lucent.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Content-Transfer-Encoding: quoted-printable Cc: dhcwg@ietf.org, tjc@ecs.soton.ac.uk X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jdq@lucent.com List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: quoted-printable JINMEI Tatuya / =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 wrote: > (Sorry for the delay in response) > > I've changed the title since I'm concentrating on this particular > issue. > > Instead of making a response to each sub-issue (attached below), let > me raise a more fundamental concern. > > Perhaps I'm just pedantic, but the current behavior of the lifetime > option, however clearly it is defined, does not sound like a > "lifetime" that I would envision. To me, if a lifetime of some > information expires, the information should be invalid (in some > sense). But the current behavior described in dhc-lifetime-01 does > not seem to invalidate the information in any way; the "lifetime" > would rather seem like an "update timer" or something. > > One obvious "fix" to this is to change the option name to something > like "Information Update Timer" option (too long?). > > However, I personally would like to leave the possibility of > invalidating the information on lifetime expiry. With this sense I'd > imagine something like this: > > - the option name ("lifetime option") is the same > - the client starts re-sending Information-Requests at some point in > time to the expiration. (e.g. a half of the lifetime) > - even if the clients cannot get a response by the expiration, it > should continue sending Information-requests. However, it can also > invalidate the expired information in some way, e.g., by preferring > a "last resort" default or by using other means of configuration. > > What do others think? I also noticed the difference in semantics for this option versus address=20 lifetimes. If the lifetime option means that any option associated with it is no longe= r=20 valid at expiration, then a client needs to start the message exchange befo= re=20 the lifetime expires. Otherwise, normal processing will leave a client=20 system without critical information (probably dns) for a second or two unde= r=20 normal processing. =46or example, when the lifetime expires, the options associated with it wi= ll be=20 removed from system configuration by the client. The client then restarts= =20 the message exchange including a delay for sending. If all goes well, the= =20 client receives a response and updates the system. During the exchange, mo= st=20 applications will have problems even if there have been no network changes. If the lifetime option simply represents a timer to update the associated=20 options, this problem goes away. The previously configured values can rema= in=20 in place while an exchange takes places. After the exchange the system can= =20 be updated, if necessary. I read the lifetime option as a timer. I did it this way defensively, sinc= e=20 it does not introduce (short lived) breakage. Perhaps, as you suggested, the better fix is to use half the lifetime opti= on=20 as a sort of t1 value. This brings it inline with address lifetime=20 semantics. This would require some rewording of the draft. Also, if this change is made, it is probably more important to specify a=20 minimum lifetime value so that half the configured lifetime does not cause = a=20 significant change in network usage. Bernie Volz has mentioned this alread= y. Thanks for bringing up this issue. Joe.=20 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon Aug 23 11:56:37 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18262; Mon, 23 Aug 2004 11:56:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BzGrE-0006wa-8v; Mon, 23 Aug 2004 11:35:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BzGTU-0003pi-7M for dhcwg@megatron.ietf.org; Mon, 23 Aug 2004 11:11:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15397 for ; Mon, 23 Aug 2004 11:11:00 -0400 (EDT) Received: from tyholt.uninett.no ([158.38.60.10]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BzGTj-0006vW-DW for dhcwg@ietf.org; Mon, 23 Aug 2004 11:11:24 -0400 Received: from sverresborg.uninett.no (sverresborg.uninett.no [IPv6:2001:700:e000:0:204:75ff:fee4:423b]) by tyholt.uninett.no (8.12.10/8.12.10) with ESMTP id i7NFAN2M018238; Mon, 23 Aug 2004 17:10:23 +0200 Received: (from venaas@localhost) by sverresborg.uninett.no (8.12.8/8.12.8/Submit) id i7NFALKD002632; Mon, 23 Aug 2004 17:10:21 +0200 X-Authentication-Warning: sverresborg.uninett.no: venaas set sender to Stig.Venaas@uninett.no using -f Date: Mon, 23 Aug 2004 17:10:21 +0200 From: Stig Venaas To: Joe Quanaim Subject: Re: [dhcwg] behavior on lifetime expiration (Re: comments on draft-ietf-dhc-lifetime-01.txt) Message-ID: <20040823151021.GE1105@sverresborg.uninett.no> References: <20040803033357.GA20506@sverresborg.uninett.no> <200408231045.02340.jdq@lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200408231045.02340.jdq@lucent.com> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Cc: dhcwg@ietf.org, tjc@ecs.soton.ac.uk X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org On Mon, Aug 23, 2004 at 10:45:02AM -0400, Joe Quanaim wrote: > JINMEI Tatuya / ???????????? wrote: > > (Sorry for the delay in response) > > > > I've changed the title since I'm concentrating on this particular > > issue. > > > > Instead of making a response to each sub-issue (attached below), let > > me raise a more fundamental concern. > > > > Perhaps I'm just pedantic, but the current behavior of the lifetime > > option, however clearly it is defined, does not sound like a > > "lifetime" that I would envision. To me, if a lifetime of some > > information expires, the information should be invalid (in some > > sense). But the current behavior described in dhc-lifetime-01 does > > not seem to invalidate the information in any way; the "lifetime" > > would rather seem like an "update timer" or something. > > One obvious "fix" to this is to change the option name to something > > like "Information Update Timer" option (too long?). Yes, the term lifetime is a bit misleading. I'm open for suggestions for other names. > > However, I personally would like to leave the possibility of > > invalidating the information on lifetime expiry. With this sense I'd > > imagine something like this: I don't see why you would want that. > > - the option name ("lifetime option") is the same > > - the client starts re-sending Information-Requests at some point in > > time to the expiration. (e.g. a half of the lifetime) > > - even if the clients cannot get a response by the expiration, it > > should continue sending Information-requests. However, it can also > > invalidate the expired information in some way, e.g., by preferring > > a "last resort" default or by using other means of configuration. > > > > What do others think? > > I also noticed the difference in semantics for this option versus address > lifetimes. > > If the lifetime option means that any option associated with it is no longer > valid at expiration, then a client needs to start the message exchange before > the lifetime expires. Otherwise, normal processing will leave a client > system without critical information (probably dns) for a second or two under > normal processing. Yes, that is no good. > For example, when the lifetime expires, the options associated with it will be > removed from system configuration by the client. The client then restarts > the message exchange including a delay for sending. If all goes well, the > client receives a response and updates the system. During the exchange, most > applications will have problems even if there have been no network changes. > > If the lifetime option simply represents a timer to update the associated > options, this problem goes away. The previously configured values can remain > in place while an exchange takes places. After the exchange the system can > be updated, if necessary. > > I read the lifetime option as a timer. I did it this way defensively, since > it does not introduce (short lived) breakage. > > Perhaps, as you suggested, the better fix is to use half the lifetime option > as a sort of t1 value. This brings it inline with address lifetime > semantics. This would require some rewording of the draft. I don't like this, sounds more complex than we need. > > Also, if this change is made, it is probably more important to specify a > minimum lifetime value so that half the configured lifetime does not cause a > significant change in network usage. Bernie Volz has mentioned this already. > > Thanks for bringing up this issue. I feel strongly that it should only tell the client when it should try to update the info (like t1 I guess). But the client should keep the info while it keeps trying to update the info. As I understand the DHCP spec, it will keep retransmitting the Information-Request indefinitely if necessary, which means that the config data also might be kept indefinitely. Of course there could be other reasons for the client to remove configuration, the lifetime spec shouldn't prevent that either. But that would be completely independent of the lifetime option. The reason we want the option, is to have some control of when a client tries to update its info. We're trying to solve problem stated in the problem statement. The point is not to ensure stateless info is removed at the host. Why would you want that? I agree the name is misleading. The draft should make clear what it is, but another name might help. Stig _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon Aug 23 12:29:59 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21099; Mon, 23 Aug 2004 12:29:59 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BzH5r-0000qA-VE; Mon, 23 Aug 2004 11:50:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BzGoV-0006Nj-03 for dhcwg@megatron.ietf.org; Mon, 23 Aug 2004 11:32:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16653 for ; Mon, 23 Aug 2004 11:32:43 -0400 (EDT) Received: from raven.ecs.soton.ac.uk ([152.78.70.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BzGoj-0007SK-QY for dhcwg@ietf.org; Mon, 23 Aug 2004 11:33:07 -0400 Received: from magpie.ecs.soton.ac.uk (magpie.ecs.soton.ac.uk [152.78.68.131]) by raven.ecs.soton.ac.uk (8.12.10/8.12.10) with ESMTP id i7NFWhgg017036 for ; Mon, 23 Aug 2004 16:32:43 +0100 (BST) Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by magpie.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id QAA17281 for ; Mon, 23 Aug 2004 16:32:41 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id i7NFWe901156 for dhcwg@ietf.org; Mon, 23 Aug 2004 16:32:40 +0100 Date: Mon, 23 Aug 2004 16:32:40 +0100 From: Tim Chown To: dhcwg@ietf.org Subject: Re: [dhcwg] behavior on lifetime expiration (Re: comments on draft-ietf-dhc-lifetime-01.txt) Message-ID: <20040823153240.GM31902@login.ecs.soton.ac.uk> Mail-Followup-To: dhcwg@ietf.org References: <20040803033357.GA20506@sverresborg.uninett.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-MailScanner-Information: Please contact helpdesk@ecs.soton.ac.uk for more information X-ECS-MailScanner: Found to be clean X-MailScanner-From: tjc@smtp.ecs.soton.ac.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org On Mon, Aug 23, 2004 at 10:28:12AM -0400, Ted Lemon wrote: > > So I think that we'd really be better off, as you suggest, renaming > this the update timer. If there's some other configuration mechanism > to which we should fall back, I think we need another mechanism for > deciding when to fall back to it, and that should probably be specified > in the draft that describes the fallback mechanism. The original idea for the "timer", as documented in the stateless-renumbering draft, was a "hint" for nodes to re-request information such that if there was a renumbering event, or a change in DNS, NTP, etc servers, the (stateless) node could learn of them. Without any timer, the node has no standard mechanisms for this (it could do so on receipt of a new prefix in an RA, but that doesn't cover new DNS servers being added). So I think "update timer" may be better. Is there any case for different behaviour for stateful and stateless nodes (i.e. based on the method the node's address was obtained from)? Tim _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon Aug 23 14:21:14 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28374; Mon, 23 Aug 2004 14:21:14 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BzJ6x-0001ZS-RS; Mon, 23 Aug 2004 14:00:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BzIqx-0007X3-Fv for dhcwg@megatron.ietf.org; Mon, 23 Aug 2004 13:43:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25486 for ; Mon, 23 Aug 2004 13:43:25 -0400 (EDT) Received: from ihemail1.lucent.com ([192.11.222.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BzIrD-0001bW-47 for dhcwg@ietf.org; Mon, 23 Aug 2004 13:43:48 -0400 Received: from homail.ho.lucent.com (h135-17-192-10.lucent.com [135.17.192.10]) by ihemail1.lucent.com (8.12.11/8.12.11) with ESMTP id i7NHgfY1022199; Mon, 23 Aug 2004 12:42:42 -0500 (CDT) Received: from kraken.mh.lucent.com by homail.ho.lucent.com (8.11.7+Sun/EMS-1.5 sol2) id i7NHgfU06769; Mon, 23 Aug 2004 13:42:41 -0400 (EDT) From: Joe Quanaim To: Stig Venaas Subject: Re: [dhcwg] behavior on lifetime expiration (Re: comments on draft-ietf-dhc-lifetime-01.txt) Date: Mon, 23 Aug 2004 13:42:39 -0400 User-Agent: KMail/1.5.4 References: <200408231045.02340.jdq@lucent.com> <20040823151021.GE1105@sverresborg.uninett.no> In-Reply-To: <20040823151021.GE1105@sverresborg.uninett.no> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200408231342.39913.jdq@lucent.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org, tjc@ecs.soton.ac.uk X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jdq@lucent.com List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 7bit Stig Venaas wrote: > I feel strongly that it should only tell the client when it should > try to update the info (like t1 I guess). But the client should > keep the info while it keeps trying to update the info. As I > understand the DHCP spec, it will keep retransmitting the > Information-Request indefinitely if necessary, which means that > the config data also might be kept indefinitely. I agree with this sentiment. If a client must remove configured information when the lifetime option expires, the client is punished. A client that did not implement the lifetime option could continue to use configured information. The option expiration is not necessarily indicative of a change in the network. It sounds like all that is needed is a new name for this option. Joe. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Aug 24 06:00:31 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19908; Tue, 24 Aug 2004 06:00:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BzXi9-0003Q9-80; Tue, 24 Aug 2004 05:35:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BzXW4-0000n5-Mx for dhcwg@megatron.ietf.org; Tue, 24 Aug 2004 05:22:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17566 for ; Tue, 24 Aug 2004 05:22:49 -0400 (EDT) Received: from tyholt.uninett.no ([158.38.60.10]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BzXWS-00048H-VA for dhcwg@ietf.org; Tue, 24 Aug 2004 05:23:22 -0400 Received: from sverresborg.uninett.no (sverresborg.uninett.no [IPv6:2001:700:e000:0:204:75ff:fee4:423b]) by tyholt.uninett.no (8.12.10/8.12.10) with ESMTP id i7O9MA2M018296; Tue, 24 Aug 2004 11:22:10 +0200 Received: (from venaas@localhost) by sverresborg.uninett.no (8.12.8/8.12.8/Submit) id i7O9M9eW005707; Tue, 24 Aug 2004 11:22:09 +0200 X-Authentication-Warning: sverresborg.uninett.no: venaas set sender to Stig.Venaas@uninett.no using -f Date: Tue, 24 Aug 2004 11:22:09 +0200 From: Stig Venaas To: Joe Quanaim Subject: Re: [dhcwg] behavior on lifetime expiration (Re: comments on draft-ietf-dhc-lifetime-01.txt) Message-ID: <20040824092209.GA5677@sverresborg.uninett.no> References: <200408231045.02340.jdq@lucent.com> <20040823151021.GE1105@sverresborg.uninett.no> <200408231342.39913.jdq@lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200408231342.39913.jdq@lucent.com> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: dhcwg@ietf.org, tjc@ecs.soton.ac.uk X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org On Mon, Aug 23, 2004 at 01:42:39PM -0400, Joe Quanaim wrote: [...] > It sounds like all that is needed is a new name for this option. So let's try to find a new name. I think "update time option" is one possibility. I don't like "update timer option" because this is only a value to use for the timer, not the timer itself. Another alternative is "refresh time option" perhaps? I discussed it with a colleague, and we came up with alternatives like "suggested refresh/update time option" or "refresh/update within option". Not so sure about the last one, it tries to make it clear that you might refresh/update before the specified time. I think we should keep the name fairly short. We should have a name that isn't misleading, but people will still have to read the draft to understand exactly what it is. Stig _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Aug 24 08:58:53 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02168; Tue, 24 Aug 2004 08:58:53 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BzaZN-0001uG-Up; Tue, 24 Aug 2004 08:38:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bza9r-0006wn-4h for dhcwg@megatron.ietf.org; Tue, 24 Aug 2004 08:12:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28786 for ; Tue, 24 Aug 2004 08:12:04 -0400 (EDT) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BzaAG-00079x-UA for dhcwg@ietf.org; Tue, 24 Aug 2004 08:12:38 -0400 Received: from ocean.jinmei.org (unknown [3ffe:501:100f:1048:99cf:ebbf:eefe:5e4f]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 3071F15263; Tue, 24 Aug 2004 21:12:01 +0900 (JST) Date: Tue, 24 Aug 2004 21:12:01 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Ted Lemon Subject: Re: [dhcwg] behavior on lifetime expiration (Re: comments on draft-ietf-dhc-lifetime-01.txt) In-Reply-To: References: <20040803033357.GA20506@sverresborg.uninett.no> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: dhcwg@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org >>>>> On Mon, 23 Aug 2004 10:28:12 -0400, >>>>> Ted Lemon said: >> - even if the clients cannot get a response by the expiration, it >> should continue sending Information-requests. However, it can also >> invalidate the expired information in some way, e.g., by preferring >> a "last resort" default or by using other means of configuration. > Can you think of a real-world scenario where this would be the right > thing to do? I can't come up with one. The scenario I thought of is that if the "lifetime" of a DNS (recursive) server expires with no update I'd stop using the server and start a local recursive server daemon (e.g., run BIND named on my laptop and specify ::1 in /etc/resolv.conf) as a last resort. I'm quite sure that this is a "real world" scenario because I, for one, would like to have this feature and I'm living in the real world of the Internet. I admit this might be a niche demand though. I can also think of a scenario where I'll then prefer information from DHCPv4 (over the expired information from DHCPv6). But I don't know this makes sense in the real world. Aside from the scenarios, I'm also concerned about a (possible) pitfall with the "update timer" semantics. Assume that we have a reply to Information-request containing a DNS server address X with update timer (or lifetime) T. T seconds later, the client will restart Information-request/reply exchanges. If we then get a different DNS server address Y, we'll stop using the old address X and switch to Y. This should exactly be the "renumbering scenario", and the behavior looks reasonable. But what if the reply does not contain any new DNS server address? Can we still continue to use address X, or will we then lose any usable DNS server address? If the former is the intent, it seems a bit odd to me that the behavior is different based on whether the replied set is empty or not (at least the specification is not very clear on this). If the latter is the intent, doesn't it almost mean we invalidate the expired information X? Anyway...so far, others do not seem to be very happy with the idea of invalidating expired information. If the above explanation is still not so convincing, I won't stick to the idea. I can live with the "update timer" semantics as long as the specification is clear enough to implement. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp p.s. I'm afraid I won't be able to be very active on the list this week. I'd apologize in advance for future delay of my responses. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Aug 24 10:19:59 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09153; Tue, 24 Aug 2004 10:19:59 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BzboL-0001OW-9h; Tue, 24 Aug 2004 09:58:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BzbKn-0003kg-Sl for dhcwg@megatron.ietf.org; Tue, 24 Aug 2004 09:27:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03961 for ; Tue, 24 Aug 2004 09:27:26 -0400 (EDT) Received: from tyholt.uninett.no ([158.38.60.10]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BzbLD-00008h-Uu for dhcwg@ietf.org; Tue, 24 Aug 2004 09:28:01 -0400 Received: from sverresborg.uninett.no (sverresborg.uninett.no [IPv6:2001:700:e000:0:204:75ff:fee4:423b]) by tyholt.uninett.no (8.12.10/8.12.10) with ESMTP id i7ODQt2M021483; Tue, 24 Aug 2004 15:26:55 +0200 Received: (from venaas@localhost) by sverresborg.uninett.no (8.12.8/8.12.8/Submit) id i7ODQoEp006265; Tue, 24 Aug 2004 15:26:50 +0200 X-Authentication-Warning: sverresborg.uninett.no: venaas set sender to Stig.Venaas@uninett.no using -f Date: Tue, 24 Aug 2004 15:26:50 +0200 From: Stig Venaas To: "JINMEI Tatuya / ?$B?@L@C#:H" Subject: Re: [dhcwg] behavior on lifetime expiration (Re: comments on draft-ietf-dhc-lifetime-01.txt) Message-ID: <20040824132650.GI5677@sverresborg.uninett.no> References: <20040803033357.GA20506@sverresborg.uninett.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: dhcwg@ietf.org, Ted Lemon X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org On Tue, Aug 24, 2004 at 09:12:01PM +0900, JINMEI Tatuya / ?$B?@L@C#:H wrote: > >>>>> On Mon, 23 Aug 2004 10:28:12 -0400, > >>>>> Ted Lemon said: > > >> - even if the clients cannot get a response by the expiration, it > >> should continue sending Information-requests. However, it can also > >> invalidate the expired information in some way, e.g., by preferring > >> a "last resort" default or by using other means of configuration. > > > Can you think of a real-world scenario where this would be the right > > thing to do? I can't come up with one. > > The scenario I thought of is that if the "lifetime" of a DNS > (recursive) server expires with no update I'd stop using the server > and start a local recursive server daemon (e.g., run BIND named on my > laptop and specify ::1 in /etc/resolv.conf) as a last resort. I'm > quite sure that this is a "real world" scenario because I, for one, > would like to have this feature and I'm living in the real world of > the Internet. I admit this might be a niche demand though. > > I can also think of a scenario where I'll then prefer information > from DHCPv4 (over the expired information from DHCPv6). But I don't > know this makes sense in the real world. OK, I can see that. How about adding this: The expiry of the lifetime in itself does not in anyway mean that the client should remove the data. The client should keep it's current data while attempting to refresh it. The client is however free to fall back to other mechanisms if it cannot refresh the data within a reasonable amount of time. It's a bit vague, but I don't think we should standardize every detail. > Aside from the scenarios, I'm also concerned about a (possible) > pitfall with the "update timer" semantics. > > Assume that we have a reply to Information-request containing a DNS > server address X with update timer (or lifetime) T. T seconds later, > the client will restart Information-request/reply exchanges. If we > then get a different DNS server address Y, we'll stop using the old > address X and switch to Y. This should exactly be the "renumbering > scenario", and the behavior looks reasonable. But what if the reply > does not contain any new DNS server address? Can we still continue to > use address X, or will we then lose any usable DNS server address? It is reasonable to remove it in my opinion. However if the client has no fallback mechanism to obtain a new resolver address, I guess it could decide to keep using it. If however say NTP server address is removed, and the client has no fallback, I would say disable NTP. Try to think what you would do without this option. Your client would try to refresh the info at some point wouldn't it? If you move to new link, if user requests it etc. What do you do if no server is specified in the reply? If the DNS server address is not in the new reply, the administrator has removed it from the DHCP server config, and is expecting clients to obtain DNS server address in some other way, or? It's just another hint for when to update the info. Also, if you stop offering some service, or by accident include something. There should be a way to remove it. > If the former is the intent, it seems a bit odd to me that the > behavior is different based on whether the replied set is empty or not > (at least the specification is not very clear on this). If the latter > is the intent, doesn't it almost mean we invalidate the expired > information X? > > Anyway...so far, others do not seem to be very happy with the idea of > invalidating expired information. If the above explanation is still > not so convincing, I won't stick to the idea. I can live with the > "update timer" semantics as long as the specification is clear enough > to implement. Well, I'm interested in hearing what you think is reasonable, and what you would implement in your client if you don't have this options, but renew the data for other reasons. > > JINMEI, Tatuya > Communication Platform Lab. > Corporate R&D Center, Toshiba Corp. > jinmei@isl.rdc.toshiba.co.jp > > p.s. I'm afraid I won't be able to be very active on the list this > week. I'd apologize in advance for future delay of my responses. NP. I hope to post my suggestions for next revision later this week. I'll then wait several days to see if people are satisfied, in which case I'll make it the official "02" version. Stig _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Aug 24 11:07:41 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13123; Tue, 24 Aug 2004 11:07:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BzcQ3-0007AC-Cm; Tue, 24 Aug 2004 10:37:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BzcFt-0004dN-TS for dhcwg@megatron.ietf.org; Tue, 24 Aug 2004 10:26:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09731 for ; Tue, 24 Aug 2004 10:26:26 -0400 (EDT) Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BzcGK-0001VI-Sx for dhcwg@ietf.org; Tue, 24 Aug 2004 10:27:02 -0400 Received: from homail.ho.lucent.com (h135-17-192-10.lucent.com [135.17.192.10]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id i7OEPkvV023190; Tue, 24 Aug 2004 09:25:46 -0500 (CDT) Received: from kraken.mh.lucent.com by homail.ho.lucent.com (8.11.7+Sun/EMS-1.5 sol2) id i7OEPjP08499; Tue, 24 Aug 2004 10:25:45 -0400 (EDT) From: Joe Quanaim To: Stig Venaas Subject: Re: [dhcwg] behavior on lifetime expiration (Re: comments on draft-ietf-dhc-lifetime-01.txt) Date: Tue, 24 Aug 2004 10:25:11 -0400 User-Agent: KMail/1.5.4 References: <200408231342.39913.jdq@lucent.com> <20040824092209.GA5677@sverresborg.uninett.no> In-Reply-To: <20040824092209.GA5677@sverresborg.uninett.no> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200408241025.11357.jdq@lucent.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org, tjc@ecs.soton.ac.uk X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jdq@lucent.com List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 7bit Stig Venaas wrote: > On Mon, Aug 23, 2004 at 01:42:39PM -0400, Joe Quanaim wrote: > [...] > > > It sounds like all that is needed is a new name for this option. > > So let's try to find a new name. I think "update time option" is > one possibility. I don't like "update timer option" because this > is only a value to use for the timer, not the timer itself. > > Another alternative is "refresh time option" perhaps? > > I discussed it with a colleague, and we came up with alternatives > like "suggested refresh/update time option" or "refresh/update > within option". Not so sure about the last one, it tries to make > it clear that you might refresh/update before the specified time. > > I think we should keep the name fairly short. We should have a > name that isn't misleading, but people will still have to read the > draft to understand exactly what it is. Another alternative might be "refresh delay". This changes the nature of the name from "check back in n seconds" to "do not check again until at least n seconds". It does not piggyback on the notion of expiration, which is well defined in the address management side of dhcp, but not on the stateless option side. Joe. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Aug 24 11:54:57 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16882; Tue, 24 Aug 2004 11:54:57 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BzdGB-0000dn-MO; Tue, 24 Aug 2004 11:30:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bzcue-0005Zo-QY for dhcwg@megatron.ietf.org; Tue, 24 Aug 2004 11:08:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13224 for ; Tue, 24 Aug 2004 11:08:38 -0400 (EDT) Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BzcvC-0002Jr-3P for dhcwg@ietf.org; Tue, 24 Aug 2004 11:09:14 -0400 Received: from [10.0.1.2] (dpc6935208055.direcpc.com [69.35.208.55]) by toccata.fugue.com (Postfix) with ESMTP id 3E2401B232D for ; Tue, 24 Aug 2004 10:08:13 -0500 (CDT) Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: References: <20040803033357.GA20506@sverresborg.uninett.no> Content-Type: text/plain; charset=ISO-2022-JP; format=flowed Message-Id: <6C20AA0D-F5DF-11D8-8541-000A95D9C74C@nominum.com> Content-Transfer-Encoding: 7bit From: Ted Lemon Subject: Re: [dhcwg] behavior on lifetime expiration (Re: comments on draft-ietf-dhc-lifetime-01.txt) Date: Tue, 24 Aug 2004 11:08:14 -0400 To: dhcwg@ietf.org X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Content-Transfer-Encoding: 7bit X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 7bit On Aug 24, 2004, at 8:12 AM, JINMEI Tatuya / $B?@L@C#:H(B wrote: > The scenario I thought of is that if the "lifetime" of a DNS > (recursive) server expires with no update I'd stop using the server > and start a local recursive server daemon (e.g., run BIND named on my > laptop and specify ::1 in /etc/resolv.conf) as a last resort. I'm > quite sure that this is a "real world" scenario because I, for one, > would like to have this feature and I'm living in the real world of > the Internet. I admit this might be a niche demand though. I would never want to suggest that your needs as a network user are not representative of the average user, of course! :') However, let's consider your scenario a little more closely. You acquire some information from the DHCP server. Subsequently, for some reason, it becomes impossible for the server to respond to the client. I have a couple of observations about this. First, the time at which it becomes impossible for the server to respond is not the same as the time at which the client attempts to refresh its configuration information. The two events are unrelated. Second, we should consider why the DHCP server is no longer able to respond. I would say the most likely scenario is that I am no longer connected to the same link, so that my routing information is stale. But in this case I am going to notice that I am no longer on the same link because of RA messages, or because of a physical network link state transition. And this will happen at the time when it becomes impossible to contact the DHCP server, *not* at the time that the refresh time comes. So I would say in this case that you will already have invalidated the refresh timer and the information covered by the refresh timer, so we have no need to say what you would do when the refresh timer expired, because it will not ever expire. Another scenario that might occur is that the DHCP server might be turned off, and then it wouldn't reply because it's not available. In this case, I can think of two basic reasons why this might have happened. One is that the server needs some kind of maintenance. The other is that DHCP service is no longer wanted on the link. In the first case, you want to continue using the configuration information, because it's still valid. It would be somewhat disastrous to stop using it. In the second case, which I would argue is unlikely on a production network, it would be nice if there was some way to indicate that the information was no longer valid. I would say that if you want to address the concern you've raised, this is the scenario that you need to address, and that the solution you've proposed doesn't fit the scenario you've described, because in the most common case where you care, the solution isn't needed, and in the second-most-common case, the proposed solution would result in the network becoming unusable to the average user. > I can also think of a scenario where I'll then prefer information > from DHCPv4 (over the expired information from DHCPv6). But I don't > know this makes sense in the real world. This is a fertile area of DHCP research. :') > Assume that we have a reply to Information-request containing a DNS > server address X with update timer (or lifetime) T. T seconds later, > the client will restart Information-request/reply exchanges. If we > then get a different DNS server address Y, we'll stop using the old > address X and switch to Y. This should exactly be the "renumbering > scenario", and the behavior looks reasonable. But what if the reply > does not contain any new DNS server address? Can we still continue to > use address X, or will we then lose any usable DNS server address? It's a good question. I think that it's unlikely that the DNS server address would be missing unless the server had been configured to no longer send it, so I think it would indeed make sense to stop using the stale information. This could be the answer to the scenario you proposed initially - if you want to turn off the DHCP server, you configure it to send an empty information reply message. You leave it configured this way for the duration of the refresh time. Then you turn it off, because you can be confident that any client that was connected to the network during the interval when it was sending empty information reply messages will no longer be relying on DHCP for the information the DHCP server had been providing. This implies that if we *start up* on a link to which we were previously connected, we should immediately attempt to contact the DHCP server. In this case, if we are not able to contact the DHCP server by the time the refresh time has passed, we can assume that it is no longer active on the link, and that any information we have cached is no longer valid. This would be analogous to the INIT-REBOOT state in DHCPv4. > p.s. I'm afraid I won't be able to be very active on the list this > week. I'd apologize in advance for future delay of my responses. I would like to defer making a decision on this point until you have time to respond, so if that's next week, let's wait until next week to resolve these issues. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Aug 24 21:54:48 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA02805; Tue, 24 Aug 2004 21:54:48 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BzmZ8-0005qU-9V; Tue, 24 Aug 2004 21:27:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bzm4z-0000qU-Hb for dhcwg@megatron.ietf.org; Tue, 24 Aug 2004 20:55:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28532 for ; Tue, 24 Aug 2004 20:55:50 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bzm5W-0004xU-F1 for dhcwg@ietf.org; Tue, 24 Aug 2004 20:56:31 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 24 Aug 2004 18:00:17 -0700 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i7P0tGiQ020140; Tue, 24 Aug 2004 17:55:17 -0700 (PDT) Received: from volzw2k (che-vpn-cluster-1-156.cisco.com [10.86.240.156]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id ALB56826; Tue, 24 Aug 2004 20:55:16 -0400 (EDT) From: "Bernie Volz" To: "'Ted Lemon'" , =?utf-8?B?J0pJTk1FSSBUYXR1eWEgLyDCkF/igJPCvuKAmULCjcOGJw==?= Subject: RE: [dhcwg] Re: one more comment about the lifetime option Date: Tue, 24 Aug 2004 20:55:14 -0400 Organization: Cisco Message-ID: <001401c48a3e$2ededf20$6401a8c0@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.5709 In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4939.300 X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: quoted-printable Cc: dhcwg@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: quoted-printable If it is restricted to a REPLY to an INFORMATION-REQUEST, there is no = need for this explicit statement as that's all that is currently = possible - there are no IA_NA, IA_TA, or IA_PD options for these = messages. > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org]=20 > On Behalf Of Ted Lemon > Sent: Monday, August 23, 2004 10:30 AM > To: JINMEI Tatuya / =C2=90_=E2=80=93=C2=BE=E2=80=99B=C2=8D=C3=86 > Cc: dhcwg@ietf.org > Subject: Re: [dhcwg] Re: one more comment about the lifetime option >=20 >=20 > On Aug 23, 2004, at 5:27 AM, JINMEI Tatuya / = =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 wrote: > > We should also restrict the position where the lifetime option can > > appear: it should only be able to appear at the "top level"=20 > of option=20 > > hierarchy. >=20 > I think this is a good idea. >=20 >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg >=20 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Aug 24 21:57:33 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03020; Tue, 24 Aug 2004 21:57:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BzmaG-0006D6-5V; Tue, 24 Aug 2004 21:28:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BzmAJ-0001so-2a for dhcwg@megatron.ietf.org; Tue, 24 Aug 2004 21:01:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28944 for ; Tue, 24 Aug 2004 21:01:25 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BzmAv-00056B-1O for dhcwg@ietf.org; Tue, 24 Aug 2004 21:02:06 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 24 Aug 2004 18:07:24 +0000 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i7P10jox010599; Tue, 24 Aug 2004 18:00:46 -0700 (PDT) Received: from volzw2k (che-vpn-cluster-1-156.cisco.com [10.86.240.156]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id ALB57036; Tue, 24 Aug 2004 21:00:47 -0400 (EDT) From: "Bernie Volz" To: , "'Stig Venaas'" Subject: RE: [dhcwg] behavior on lifetime expiration (Re: comments ondraft-ietf-dhc-lifetime-01.txt) Date: Tue, 24 Aug 2004 21:00:45 -0400 Organization: Cisco Message-ID: <001501c48a3e$f4246d90$6401a8c0@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.5709 In-Reply-To: <200408241025.11357.jdq@lucent.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4939.300 X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Content-Transfer-Encoding: quoted-printable Cc: dhcwg@ietf.org, tjc@ecs.soton.ac.uk X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: quoted-printable I'd vote for "Refresh Time Option". I have no problem renaming this and = I do how we keep it simple - client should refresh its data when the time = elapses (note that this doesn't preclude the client from doing it earlier if it = has a good reason to do so). - Bernie > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org]=20 > On Behalf Of Joe Quanaim > Sent: Tuesday, August 24, 2004 10:25 AM > To: Stig Venaas > Cc: dhcwg@ietf.org; tjc@ecs.soton.ac.uk > Subject: Re: [dhcwg] behavior on lifetime expiration (Re:=20 > comments ondraft-ietf-dhc-lifetime-01.txt) >=20 >=20 > Stig Venaas wrote: > > On Mon, Aug 23, 2004 at 01:42:39PM -0400, Joe Quanaim wrote: [...] > > > > > It sounds like all that is needed is a new name for this option. > > > > So let's try to find a new name. I think "update time=20 > option" is one=20 > > possibility. I don't like "update timer option" because=20 > this is only a=20 > > value to use for the timer, not the timer itself. > > > > Another alternative is "refresh time option" perhaps? > > > > I discussed it with a colleague, and we came up with=20 > alternatives like=20 > > "suggested refresh/update time option" or "refresh/update within=20 > > option". Not so sure about the last one, it tries to make it clear=20 > > that you might refresh/update before the specified time. > > > > I think we should keep the name fairly short. We should have a name=20 > > that isn't misleading, but people will still have to read=20 > the draft to=20 > > understand exactly what it is. >=20 > Another alternative might be "refresh delay". This changes=20 > the nature of the=20 > name from "check back in n seconds" to "do not check again=20 > until at least n=20 > seconds". It does not piggyback on the notion of expiration,=20 > which is well=20 > defined in the address management side of dhcp, but not on=20 > the stateless=20 > option side. >=20 > Joe. >=20 >=20 >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg >=20 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Aug 24 22:03:35 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03616; Tue, 24 Aug 2004 22:03:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bzmk9-0007uW-Au; Tue, 24 Aug 2004 21:38:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BzmLJ-00047X-7h for dhcwg@megatron.ietf.org; Tue, 24 Aug 2004 21:12:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29952 for ; Tue, 24 Aug 2004 21:12:42 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BzmLr-0005QH-2X for dhcwg@ietf.org; Tue, 24 Aug 2004 21:13:23 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 24 Aug 2004 18:17:09 -0700 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i7P1C5We022866; Tue, 24 Aug 2004 18:12:06 -0700 (PDT) Received: from volzw2k (che-vpn-cluster-1-156.cisco.com [10.86.240.156]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id ALB57532; Tue, 24 Aug 2004 21:12:06 -0400 (EDT) From: "Bernie Volz" To: =?iso-8859-1?B?J0pJTk1FSSBUYXR1eWEgLyCQXy2+J0KNxic=?= , "'Ted Lemon'" Subject: RE: [dhcwg] behavior on lifetime expiration (Re: commentson draft-ietf-dhc-lifetime-01.txt) Date: Tue, 24 Aug 2004 21:12:07 -0400 Organization: Cisco Message-ID: <001601c48a40$8a411e80$6401a8c0@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.5709 In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4939.300 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 Content-Transfer-Encoding: quoted-printable Cc: dhcwg@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Jinmei: You'd prefer IPv4 based information over IPv6? And DHCPv4, if Inform was used, doesn't have *ANY* time to expire the information - so I don't think you'd want to use this information in preference to DHCPv6 information with a time? If you can't obtain newer information, you're always free to take = whatever steps you like on the client - ie, start a local recursive server daemon (e.g., run BIND named on my laptop and specify ::1 in /etc/resolv.conf). The issue of not receiving some information that was previously received = is a good one and we probably should give some advice in the draft as to possible options that a client could chose (based on "local" policy). My = own feeling is that I'd discard the old information and use the new, = especially if the source can be trusted (ie, authentication was used). There may be valid reasons why some options are no longer available; in other cases = it could be a configuration error and in that case it may be good for administrators to know about it sooner than later. The worst is if it is = a Denial of Service attack, but in that case they can just as easily send = you bogus information. - Bernie > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org]=20 > On Behalf Of JINMEI Tatuya / =90_=96=BE=92B=8D=C6 > Sent: Tuesday, August 24, 2004 8:12 AM > To: Ted Lemon > Cc: dhcwg@ietf.org > Subject: Re: [dhcwg] behavior on lifetime expiration (Re:=20 > commentson draft-ietf-dhc-lifetime-01.txt) >=20 >=20 > >>>>> On Mon, 23 Aug 2004 10:28:12 -0400, > >>>>> Ted Lemon said: >=20 > >> - even if the clients cannot get a response by the expiration, it=20 > >> should continue sending Information-requests. However, it=20 > can also=20 > >> invalidate the expired information in some way, e.g., by=20 > preferring a=20 > >> "last resort" default or by using other means of configuration. >=20 > > Can you think of a real-world scenario where this would be=20 > the right=20 > > thing to do? I can't come up with one. >=20 > The scenario I thought of is that if the "lifetime" of a DNS > (recursive) server expires with no update I'd stop using the=20 > server and start a local recursive server daemon (e.g., run=20 > BIND named on my laptop and specify ::1 in /etc/resolv.conf)=20 > as a last resort. I'm quite sure that this is a "real world"=20 > scenario because I, for one, would like to have this feature=20 > and I'm living in the real world of the Internet. I admit=20 > this might be a niche demand though. >=20 > I can also think of a scenario where I'll then prefer=20 > information from DHCPv4 (over the expired information from=20 > DHCPv6). But I don't know this makes sense in the real world. >=20 > Aside from the scenarios, I'm also concerned about a=20 > (possible) pitfall with the "update timer" semantics. >=20 > Assume that we have a reply to Information-request containing=20 > a DNS server address X with update timer (or lifetime) T. T=20 > seconds later, the client will restart=20 > Information-request/reply exchanges. If we then get a=20 > different DNS server address Y, we'll stop using the old=20 > address X and switch to Y. This should exactly be the=20 > "renumbering scenario", and the behavior looks reasonable. =20 > But what if the reply does not contain any new DNS server=20 > address? Can we still continue to use address X, or will we=20 > then lose any usable DNS server address? >=20 > If the former is the intent, it seems a bit odd to me that=20 > the behavior is different based on whether the replied set is=20 > empty or not (at least the specification is not very clear on=20 > this). If the latter is the intent, doesn't it almost mean=20 > we invalidate the expired information X? >=20 > Anyway...so far, others do not seem to be very happy with the=20 > idea of invalidating expired information. If the above=20 > explanation is still not so convincing, I won't stick to the=20 > idea. I can live with the "update timer" semantics as long=20 > as the specification is clear enough to implement. >=20 > JINMEI, Tatuya > Communication Platform Lab. > Corporate R&D Center,=20 > Toshiba Corp. > jinmei@isl.rdc.toshiba.co.jp >=20 > p.s. I'm afraid I won't be able to be very active on the list=20 > this week. I'd apologize in advance for future delay of my responses. >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg >=20 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Aug 25 08:58:13 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11573; Wed, 25 Aug 2004 08:58:13 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bzwz1-00050x-D5; Wed, 25 Aug 2004 08:34:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BxYfR-0004Yw-87 for dhcwg@megatron.ietf.org; Wed, 18 Aug 2004 18:12:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25450 for ; Wed, 18 Aug 2004 18:12:22 -0400 (EDT) Received: from omta1.cgnet.com ([64.95.130.134]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BxYlf-00048C-Cs for dhcwg@ietf.org; Wed, 18 Aug 2004 18:18:56 -0400 Received: from [64.95.130.10] (helo=smta-hub-2.cgnet.com) by omta1.cgnet.com with esmtp (Exim 4.41) id 1BxYfF-0007tp-Pb for dhcwg@ietf.org; Wed, 18 Aug 2004 15:12:13 -0700 Received: from dispatcher2-out.cgnet.com ([198.93.224.251]) by smta-hub-2.cgnet.com (PMDF V6.2 #30816) with ESMTP id <0I2N00655XOD1R@smta-hub-2.cgnet.com> for dhcwg@ietf.org; Wed, 18 Aug 2004 15:12:13 -0700 (PDT) Received: from [64.95.129.142] (helo=csimail1.CGNETAD.COM) by dispatcher2.cgnet.com with esmtp (Exim 4.41) id 1BxYfE-0003wV-D4 for dhcwg@ietf.org; Wed, 18 Aug 2004 15:12:12 -0700 Date: Wed, 18 Aug 2004 15:12:11 -0700 From: "Romero, Eric" To: dhcwg@ietf.org Message-id: <39A1B547DAD9D94A8C9A8A639C65A2CA037EDDCE@csimail1.CGNETAD.COM> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Thread-Topic: Windows2003 microsoft dhcp Thread-Index: AcSFcGja/hzhhOkgSG+x8gPzjyrOyQ== Content-class: urn:content-classes:message X-cgnet-com-MailScanner-Information: Please contact the ISP for more information X-cgnet-com-MailScanner: Found to be clean X-MailScanner-From: eric@csi.exch.cgnet.com X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Wed, 25 Aug 2004 08:34:29 -0400 Subject: [dhcwg] Windows2003 microsoft dhcp X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Hi all, I have a Microsoft windows2003 domain running Microsoft DHCP, I want to = know what is the best way to assign ips securely. i.e if a vendor comes to the office I do not want his/her latop to = obtain an ip, ips must be assigned just to office's computers. thx _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Aug 25 09:05:02 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12028; Wed, 25 Aug 2004 09:05:02 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bzx2P-0005eJ-9h; Wed, 25 Aug 2004 08:38:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvKPH-0003t0-Py; Thu, 12 Aug 2004 14:34:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21361; Thu, 12 Aug 2004 14:34:30 -0400 (EDT) Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BvKUH-0001Pr-5Q; Thu, 12 Aug 2004 14:39:42 -0400 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.196); Thu, 12 Aug 2004 11:33:57 -0700 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 12 Aug 2004 11:33:47 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 12 Aug 2004 11:33:29 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Thu, 12 Aug 2004 11:33:01 -0700 x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 12 Aug 2004 11:33:31 -0700 Message-ID: Thread-Topic: Stateful != M , Stateless != O thread-index: AcSAjrxJxtT3hzWySXSPpNgKHzFcgwAC7aeQ From: "Christian Huitema" To: "Bernie Volz" , "Ralph Droms" , X-OriginalArrivalTime: 12 Aug 2004 18:33:01.0847 (UTC) FILETIME=[CC8F2A70:01C4809A] X-Spam-Score: 0.4 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Wed, 25 Aug 2004 08:37:59 -0400 Cc: dhcwg@ietf.org Subject: [dhcwg] RE: Stateful != M , Stateless != O X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: quoted-printable > If M is set(1), a client able to do stateful, does stateful (or full 3315) > and ignores the O bit.=20 More precisely, the M bit indicates that a client wishing to do stateful may do it, and the M=3D0 bit indicates that the client should not try. If the router wants to not enable stateless, then the M bit is not the right tool. The router should simply not advertise that prefixes are available for stateless auto-configuration. -- Christian Huitema _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Aug 25 09:05:40 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12105; Wed, 25 Aug 2004 09:05:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bzx2O-0005eE-V3; Wed, 25 Aug 2004 08:38:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuzXb-0007kO-5u for dhcwg@megatron.ietf.org; Wed, 11 Aug 2004 16:17:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08830 for ; Wed, 11 Aug 2004 16:17:41 -0400 (EDT) Received: from web90104.mail.scd.yahoo.com ([66.218.94.75]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1BuzcO-0000DZ-LB for dhcwg@ietf.org; Wed, 11 Aug 2004 16:22:42 -0400 Message-ID: <20040811201710.54895.qmail@web90104.mail.scd.yahoo.com> Received: from [216.66.236.13] by web90104.mail.scd.yahoo.com via HTTP; Wed, 11 Aug 2004 13:17:10 PDT Date: Wed, 11 Aug 2004 13:17:10 -0700 (PDT) From: donna prescott To: dhcwg@ietf.org MIME-Version: 1.0 X-Spam-Score: 2.3 (++) X-Scan-Signature: 25620135586de10c627e3628c432b04a X-Mailman-Approved-At: Wed, 25 Aug 2004 08:37:59 -0400 Subject: [dhcwg] Key Logger/Hacker/ serious using DHCP Server Hacked into my system/company X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0587548894==" Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org --===============0587548894== Content-Type: multipart/alternative; boundary="0-1518279392-1092255430=:48943" --0-1518279392-1092255430=:48943 Content-Type: text/plain; charset=us-ascii These people are destroying my company, already they've hacked into 3 of our computers, gotten our accounting system so screwed up I have no idea what we are going to do if they can't be stopped before tax season if we are still in business by than. This is the information I have: I know it's a Mac computer or a mac server, any help would greatly be appriciated. Donna Prescott, Exotic Wood Dreams Internet Protocal (TCP/ IP) address assigned by DHPC physical address: 00-0C-FI-EE-BA-B3 I think my address: IP address: 192.168.0.100 Subnet Mask: 255.255.255.0 Default Gateway: 192.168.0.1 DHCP Server 192.168.0.1 Lease Obtained: 8/11/2004 8:50:43 AM Lease Expires: 8/18/2004 8:50: 43 AM DNS Server 192.168.0.1 Wins Server (blank) Thank You, T. & D. Prescott, Exotic Wood Dreams @ www.exoticwooddreams.com (909) 681-1855 Fax (909) 361-4411 Dedicated to: 'Making Parrot Dreams Come True' --0-1518279392-1092255430=:48943 Content-Type: text/html; charset=us-ascii
These people are destroying my company, already they've hacked into 3 of our computers, gotten our accounting system so screwed up I have no idea what we are going to do if they can't be stopped before tax season if we are still in business by than.
This is the information I have:   I know it's a Mac computer or a mac server, any help would greatly be appriciated.
Donna Prescott,
Exotic Wood Dreams
 
 Internet Protocal  (TCP/ IP)
address assigned by DHPC
physical address: 00-0C-FI-EE-BA-B3  
I think my address: IP address: 192.168.0.100
Subnet Mask: 255.255.255.0
Default Gateway: 192.168.0.1
DHCP Server  192.168.0.1
Lease Obtained: 8/11/2004  8:50:43 AM
Lease Expires: 8/18/2004 8:50: 43 AM
DNS Server 192.168.0.1
Wins Server  (blank)
 


Thank You,
T. & D. Prescott,
Exotic Wood Dreams
(909) 681-1855  Fax (909) 361-4411
Dedicated to: 'Making Parrot Dreams Come True'
--0-1518279392-1092255430=:48943-- --===============0587548894== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --===============0587548894==-- From dhcwg-bounces@ietf.org Wed Aug 25 09:06:52 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12176; Wed, 25 Aug 2004 09:06:52 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bzx2P-0005eR-KJ; Wed, 25 Aug 2004 08:38:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BztaA-0008NP-2T; Wed, 25 Aug 2004 04:56:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA25761; Wed, 25 Aug 2004 04:56:31 -0400 (EDT) Received: from mailout2.samsung.com ([203.254.224.25]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bztal-0005Kj-61; Wed, 25 Aug 2004 04:57:16 -0400 Received: from custom-daemon.mailout2.samsung.com by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0I2Z00H85VGG2S@mailout2.samsung.com>; Wed, 25 Aug 2004 17:55:28 +0900 (KST) Received: from ep_mmp1 (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0I2Z00FISVFG4M@mailout2.samsung.com>; Wed, 25 Aug 2004 17:54:53 +0900 (KST) Received: from OLNRAO ([107.108.71.122]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPSA id <0I2Z006FWVFESO@mmp1.samsung.com>; Wed, 25 Aug 2004 17:54:52 +0900 (KST) Date: Wed, 25 Aug 2004 14:24:51 +0530 From: "O.L.N.Rao" To: surya_pc@huawei.com Message-id: <04d601c48a81$304ea050$7a476c6b@sisodomain.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Mailer: Microsoft Outlook Express 6.00.2800.1437 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <008f01c48a71$3b09c4d0$5c04120a@suryapc> X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Content-Transfer-Encoding: 7BIT X-Mailman-Approved-At: Wed, 25 Aug 2004 08:37:59 -0400 Cc: dhcwg@ietf.org, ipv6@ietf.org Subject: [dhcwg] Re: DHCPv6 Relay Queries. X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 7BIT Hi Surya, See my comments inline :) [PS: This is related to DHCPv6 and would be better to discuss in dhcwg@ietf.org] Regards, O. L. N. Rao & Suman V N ----- Original Message ----- From: "Surya" To: Sent: Wednesday, August 25, 2004 12:30 PM Subject: DHCPv6 Relay Queries. > Hi, > > Could you please clarify on the below mentioned queries on DHCPv6 Relay > > When we use the following topology > > "Client ----- Relay1 -------Relay 2 ---------Server" > > 1) Does all the DHCP messages from Client goes to Relay even after knowing > the server? ==> Yes, they always go to/through Relay. However, if the DHCPv6 client supports "Server Unicast Option", then DHCPv6 Server will send its unicast address to DHCPv6 Client. DHCPv6 Client will then use unicast communication with server. Here, I would like to mention one more point. Even though, the messages are sent to DHCPv6_All_Agents_and_Servers the Server Identifier option specifies the DHCPv6 server to which the message was intended. > > 2. Relay forms Relay forward message when it sends to another relay, will it > again construct a relay forward message? ===> Yes. Because, unless the total path is known, the reply can not come back in the same path. The server constructs the Relay-Reply message with the full path in Relay Message Options. > > 3. DHCP message can be can be stored in Options field of the Relay forward. > When it reaches the last relay on the network which is connected to Server, > how the processing should be? > ===> The Relay-Forward messages reaches Server as it is. > > Thanks > Surya. > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Aug 25 11:50:15 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25484; Wed, 25 Aug 2004 11:50:15 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BzziW-0002XV-Vn; Wed, 25 Aug 2004 11:29:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BzzVt-0000vr-Bt for dhcwg@megatron.ietf.org; Wed, 25 Aug 2004 11:16:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22844 for ; Wed, 25 Aug 2004 11:16:30 -0400 (EDT) Received: from tyholt.uninett.no ([158.38.60.10]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BzzWY-0003pm-GK for dhcwg@ietf.org; Wed, 25 Aug 2004 11:17:19 -0400 Received: from sverresborg.uninett.no (sverresborg.uninett.no [IPv6:2001:700:e000:0:204:75ff:fee4:423b]) by tyholt.uninett.no (8.12.10/8.12.10) with ESMTP id i7PFFx2M004670 for ; Wed, 25 Aug 2004 17:15:59 +0200 Received: (from venaas@localhost) by sverresborg.uninett.no (8.12.8/8.12.8/Submit) id i7PFFx8B009282 for dhcwg@ietf.org; Wed, 25 Aug 2004 17:15:59 +0200 X-Authentication-Warning: sverresborg.uninett.no: venaas set sender to Stig.Venaas@uninett.no using -f Date: Wed, 25 Aug 2004 17:15:59 +0200 From: Stig Venaas To: dhcwg@ietf.org Message-ID: <20040825151559.GJ5677@sverresborg.uninett.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 25eb6223a37c19d53ede858176b14339 Subject: [dhcwg] Attempt at text for draft-ietf-dhc-lifetime-02 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org I've tried to update the text based on all the suggestions and comments received. I may still try to improve the language, but please read the text below and let me know if you have problems with what it says. Lines from the draft are prefixed by "|". I have some comments/questions inline. I'm hoping that we can come to agreement on the text in 1-2 weeks, so that I can finalize version 02, which then hopefully can go to WGLC. | Information Refresh Time Option for DHCPv6 What do you think of this name? I think the problem with just "refresh time option" is that it sounds more like an option for refreshing time... |Abstract | | This document describes an option for specifying an upper bound for | how long a client should wait before refreshing information retrieved | from DHCP. It's useful for stateless DHCPv6 where there are no | addresses or other entities with lifetimes that can tell the client | when to contact the DHCP server to refresh its configuration. |1. Introduction | | DHCPv6 [RFC 3315] specifies stateful autoconfiguration for IPv6 | hosts. However, many hosts will use stateless autoconfiguration as | specified in [RFC 2462] for address assignment, and use DHCPv6 only | for other configuration data. This other configuration data will | typically have no associated lifetime, hence there may be no | information telling a host when to refresh its DHCP configuration | data. | | This option may be useful in unstable environments where unexpected | changes are likely to occur, or for planned changes, including | renumbering where an administrator can gradually decrease the value | as the event nears. | | It may also be useful to allow the client to detect within an | appropriate amount of time when a specific service change has been | made, e.g. the addition of a new NTP server, or a change of address | of a DNS server within the local network. See [RENUMREQS] for | further details. |3. Information refresh time option definition | | The information refresh time option specifies an upper bound for how | long a client should wait before refreshing information retrieved | from DHCP. It's only used for replies to Information-request | messages. In other messages there will usually be other options that | indicate when the client should contact the server, e.g. addresses | with lifetimes. | | Note that it's only an upper bound. If the client has any reason to | make a DHCP request before the refresh time expires, it should | attempt to refresh all the data. | | There are a number of potential reasons for the client to contact the | server before the refresh time expires. One reason might be other | options that have some associated lifetime that is shorter than the | refresh time. Other reasons might be a new IPv6 prefix announced by | a router, or that a server becomes unreachable on the address learnt | from DHCP. The client may also determine that it needs to request | additional options. Do you think it's ok that client might update information if a server becomes unreachable? Say you learn DNS or NTP server address from DHCP, and at some point the resolver or NTP client determines that it can't reach the server. Would it then be ok to make the dhcp client request new data? An issue might be that if a server goes down, thousands of clients may try to update their DHCP config almost simultaneously... I'm only trying to give an example though, but is it a good one? | Note that this also means that it doesn't make sense to have | different refresh time options for different data, since when the | client has reason to refresh some of its data, it should also | refresh the remaining data. | | The expiry of the refresh time in itself does not in anyway mean that | the client should remove the data. The client should keep it's | current data while attempting to refresh it. The client is however | free to fall back to other mechanisms if it cannot refresh the data | within a reasonable amount of time. | | In some cases the client uses a default refresh time IRT_DEFAULT. | The recommended value for IRT_DEFAULT is 86400 (24 hours). The | client implementation should allow for this value to be configured. What do you think of 24 hours? I've got suggestions for 1, 6-12, at least 12 hours and more from you. |3.1. Client behaviour | | A client MUST include this option in the Option Request Option (ORO) | when sending Information-request messages to the DHCP server. A | client MUST NOT include this option in the ORO in any other messages. | | If the reply to an Information-request message does not contain this | option, the client MUST behave as if the option with value | IRT_DEFAULT was provided. | | A client MUST also use the default refresh time IRT_DEFAULT if it | receives the option with value less than 600. Do you agree with a minimum like this? It should make it harder to do bad things, and I don't see a use for <10 minutes. If <600, would you rather use 600 than IRT_DEFAULT? | If a client contacts the server to obtain new data or refresh some | existing data before the refresh time expires, then it SHOULD also | refresh all data covered by this option. | | When the client detects that the refresh time has expired, it SHOULD | try to update its configuration data by making a new DHCP request as | follows. | | Before making the request it MUST wait for a random amount of time | between 0 and INF_MAX_DELAY. INF_MAX_DELAY is defined in [RFC 3315]. | Note that this delay is in addition to the rules specified in [RFC | 3315]. | | Then it can make the DHCP request to update the configuration. The | message MUST be created and transmitted according to [RFC 3315]. For | an Information-request message it must be done according to the rules | for creation and transmission of Information-request messages in | section 18.1.5 of [RFC 3315]. We could perhaps say clearly that it must send Information-request. I think there's one thing we should discuss that is related to this. What if client at some point determines that it wants to request an address (switch to stateful mode). Then we should perhaps say that client should also refresh this data and forget the previous refresh time. What if it makes a request but does not get a reply with new data? Perhaps it should only forget refresh time when it gets new data, so that it can keep using it if not? |3.2. Server behaviour | | A server sending a reply to an Information-request message SHOULD | include this option if it's included in the ORO of the request. It Do you agree with SHOULD, or do you want MUST? My thinking is that server should allow the refresh time to be configured, and probably have IRT_DEFAULT as the default value (although some servers may prefer some other default, e.g. if made for us in a specific environment). Rather than sending the value IRT_DEFAULT it might just as well not include it. Do you think we should talk about this being configurable on the server and server default, or is it all pretty obvious and better left to the implementation? | MUST NOT be included if it's not in the ORO of the request. Is this ok? There's no harm in including it, but it's totally pointless since we require client to include it in ORO, so if not in the request, the client will ignore it. | When server sends a message that is not a reply to an Information- | request message, it MUST NOT include the option. It would be sufficient to say that it's only to be included if requested by client, since client MUST ONLY request it in Information-request messages. So this paragraph could be omitted. | The option value MUST be no less than 600. Stig _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Aug 25 13:46:40 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04460; Wed, 25 Aug 2004 13:46:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C01MB-00033U-MO; Wed, 25 Aug 2004 13:14:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C01EG-00016f-1x for dhcwg@megatron.ietf.org; Wed, 25 Aug 2004 13:06:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01116 for ; Wed, 25 Aug 2004 13:06:24 -0400 (EDT) Received: from paoakoavas10.cable.comcast.com ([208.17.35.59]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C01Ew-0005rL-Hb for dhcwg@ietf.org; Wed, 25 Aug 2004 13:07:15 -0400 Received: from ([172.16.57.92]) by paoakoavas10.cable.comcast.com with ESMTP id KP-TDCH3.3194576; Wed, 25 Aug 2004 13:04:01 -0400 Received: by oakexsmtp03.cable.comcast.com with Internet Mail Service (5.5.2657.72) id ; Wed, 25 Aug 2004 13:05:20 -0400 Message-ID: From: "Woundy, Richard" To: "'Stig Venaas'" , dhcwg@ietf.org Subject: RE: [dhcwg] Attempt at text for draft-ietf-dhc-lifetime-02 Date: Wed, 25 Aug 2004 13:05:12 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.1 (/) X-Scan-Signature: 93df555cbdbcdae9621e5b95d44b301e X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org >Do you think it's ok that client might update information if a server becomes unreachable? If the application server is down for network connectivity issues, and if the DHCPv6 server could only point to this application server which is down, and if there are now several hundred/thousand clients that want to reach the application server and cannot... Do you really want these several hundred/thousand clients to query the DHCPv6 server at once, to get no useful information??? -- rich -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Stig Venaas Sent: Wednesday, August 25, 2004 11:16 AM To: dhcwg@ietf.org Subject: [dhcwg] Attempt at text for draft-ietf-dhc-lifetime-02 I've tried to update the text based on all the suggestions and comments received. I may still try to improve the language, but please read the text below and let me know if you have problems with what it says. Lines from the draft are prefixed by "|". I have some comments/questions inline. I'm hoping that we can come to agreement on the text in 1-2 weeks, so that I can finalize version 02, which then hopefully can go to WGLC. | Information Refresh Time Option for DHCPv6 What do you think of this name? I think the problem with just "refresh time option" is that it sounds more like an option for refreshing time... |Abstract | | This document describes an option for specifying an upper bound for | how long a client should wait before refreshing information retrieved | from DHCP. It's useful for stateless DHCPv6 where there are no | addresses or other entities with lifetimes that can tell the client | when to contact the DHCP server to refresh its configuration. |1. Introduction | | DHCPv6 [RFC 3315] specifies stateful autoconfiguration for IPv6 | hosts. However, many hosts will use stateless autoconfiguration as | specified in [RFC 2462] for address assignment, and use DHCPv6 only | for other configuration data. This other configuration data will | typically have no associated lifetime, hence there may be no | information telling a host when to refresh its DHCP configuration | data. | | This option may be useful in unstable environments where unexpected | changes are likely to occur, or for planned changes, including | renumbering where an administrator can gradually decrease the value | as the event nears. | | It may also be useful to allow the client to detect within an | appropriate amount of time when a specific service change has been | made, e.g. the addition of a new NTP server, or a change of address | of a DNS server within the local network. See [RENUMREQS] for | further details. |3. Information refresh time option definition | | The information refresh time option specifies an upper bound for how | long a client should wait before refreshing information retrieved | from DHCP. It's only used for replies to Information-request | messages. In other messages there will usually be other options that | indicate when the client should contact the server, e.g. addresses | with lifetimes. | | Note that it's only an upper bound. If the client has any reason to | make a DHCP request before the refresh time expires, it should | attempt to refresh all the data. | | There are a number of potential reasons for the client to contact the | server before the refresh time expires. One reason might be other | options that have some associated lifetime that is shorter than the | refresh time. Other reasons might be a new IPv6 prefix announced by | a router, or that a server becomes unreachable on the address learnt | from DHCP. The client may also determine that it needs to request | additional options. Do you think it's ok that client might update information if a server becomes unreachable? Say you learn DNS or NTP server address from DHCP, and at some point the resolver or NTP client determines that it can't reach the server. Would it then be ok to make the dhcp client request new data? An issue might be that if a server goes down, thousands of clients may try to update their DHCP config almost simultaneously... I'm only trying to give an example though, but is it a good one? | Note that this also means that it doesn't make sense to have | different refresh time options for different data, since when the | client has reason to refresh some of its data, it should also refresh | the remaining data. | | The expiry of the refresh time in itself does not in anyway mean that | the client should remove the data. The client should keep it's | current data while attempting to refresh it. The client is however | free to fall back to other mechanisms if it cannot refresh the data | within a reasonable amount of time. | | In some cases the client uses a default refresh time IRT_DEFAULT. | The recommended value for IRT_DEFAULT is 86400 (24 hours). The | client implementation should allow for this value to be configured. What do you think of 24 hours? I've got suggestions for 1, 6-12, at least 12 hours and more from you. |3.1. Client behaviour | | A client MUST include this option in the Option Request Option (ORO) | when sending Information-request messages to the DHCP server. A | client MUST NOT include this option in the ORO in any other messages. | | If the reply to an Information-request message does not contain this | option, the client MUST behave as if the option with value | IRT_DEFAULT was provided. | | A client MUST also use the default refresh time IRT_DEFAULT if it | receives the option with value less than 600. Do you agree with a minimum like this? It should make it harder to do bad things, and I don't see a use for <10 minutes. If <600, would you rather use 600 than IRT_DEFAULT? | If a client contacts the server to obtain new data or refresh some | existing data before the refresh time expires, then it SHOULD also | refresh all data covered by this option. | | When the client detects that the refresh time has expired, it SHOULD | try to update its configuration data by making a new DHCP request as | follows. | | Before making the request it MUST wait for a random amount of time | between 0 and INF_MAX_DELAY. INF_MAX_DELAY is defined in [RFC 3315]. | Note that this delay is in addition to the rules specified in [RFC | 3315]. | | Then it can make the DHCP request to update the configuration. The | message MUST be created and transmitted according to [RFC 3315]. For | an Information-request message it must be done according to the rules | for creation and transmission of Information-request messages in | section 18.1.5 of [RFC 3315]. We could perhaps say clearly that it must send Information-request. I think there's one thing we should discuss that is related to this. What if client at some point determines that it wants to request an address (switch to stateful mode). Then we should perhaps say that client should also refresh this data and forget the previous refresh time. What if it makes a request but does not get a reply with new data? Perhaps it should only forget refresh time when it gets new data, so that it can keep using it if not? |3.2. Server behaviour | | A server sending a reply to an Information-request message SHOULD | include this option if it's included in the ORO of the request. It Do you agree with SHOULD, or do you want MUST? My thinking is that server should allow the refresh time to be configured, and probably have IRT_DEFAULT as the default value (although some servers may prefer some other default, e.g. if made for us in a specific environment). Rather than sending the value IRT_DEFAULT it might just as well not include it. Do you think we should talk about this being configurable on the server and server default, or is it all pretty obvious and better left to the implementation? | MUST NOT be included if it's not in the ORO of the request. Is this ok? There's no harm in including it, but it's totally pointless since we require client to include it in ORO, so if not in the request, the client will ignore it. | When server sends a message that is not a reply to an Information- | request message, it MUST NOT include the option. It would be sufficient to say that it's only to be included if requested by client, since client MUST ONLY request it in Information-request messages. So this paragraph could be omitted. | The option value MUST be no less than 600. Stig _______________________________________________ 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-bounces@ietf.org Thu Aug 26 10:18:48 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03264; Thu, 26 Aug 2004 10:18:48 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0EWt-0007In-If; Thu, 26 Aug 2004 03:18:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0EJy-0005ES-BP for dhcwg@megatron.ietf.org; Thu, 26 Aug 2004 03:05:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA12549 for ; Thu, 26 Aug 2004 03:05:12 -0400 (EDT) Received: from mta1.huawei.com ([61.144.161.40] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C0EKh-0005wT-4r for dhcwg@ietf.org; Thu, 26 Aug 2004 03:06:08 -0400 Received: from suryapc (huawei.com [172.17.1.62]) by mta0.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPA id <0I3100A4AKCH8V@mta0.huawei.com> for dhcwg@ietf.org; Thu, 26 Aug 2004 14:50:43 +0800 (CST) Date: Thu, 26 Aug 2004 12:27:32 +0500 From: Surya To: dhcwg@ietf.org Message-id: <00db01c48b3e$275176e0$5c04120a@suryapc> Organization: Huawei MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: High X-Priority: 1 (Highest) X-MSMail-priority: High X-imss-version: 2.7 X-imss-result: Passed X-imss-approveListMatch: *@huawei.com X-Spam-Score: 1.3 (+) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Subject: [dhcwg] DHCPv6 Source with Support. X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: surya_pc@huawei.com List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1204140098==" Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org This is a multi-part message in MIME format. --===============1204140098== Content-type: multipart/alternative; boundary="Boundary_(ID_6RzbatvOiR6wkw0Cr1uAJw)" This is a multi-part message in MIME format. --Boundary_(ID_6RzbatvOiR6wkw0Cr1uAJw) Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7BIT Hi All, We wanted to purchase DHCPv6 server and Relay with Source code. We would like to know if such product along with source code & Support is available with you. Kindly provide us the information supporting to the product / features asap. Thanks & Regards, Surya. --Boundary_(ID_6RzbatvOiR6wkw0Cr1uAJw) Content-type: text/html; charset=us-ascii Content-Transfer-Encoding: 7BIT 
Hi All,
 
We wanted to purchase DHCPv6 server and Relay with Source code. We would like to know if such product along with source code & Support is available with you. Kindly provide us the information supporting to the product / features asap. 
 
Thanks & Regards, 
Surya.

 

--Boundary_(ID_6RzbatvOiR6wkw0Cr1uAJw)-- --===============1204140098== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --===============1204140098==-- From dhcwg-bounces@ietf.org Thu Aug 26 11:20:43 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10345; Thu, 26 Aug 2004 11:20:43 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0Le3-0002nZ-0q; Thu, 26 Aug 2004 10:54:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0LSi-0007Z8-2o for dhcwg@megatron.ietf.org; Thu, 26 Aug 2004 10:42:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24884 for ; Thu, 26 Aug 2004 08:10:47 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C0J6X-0002gH-MP for dhcwg@ietf.org; Thu, 26 Aug 2004 08:11:46 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 26 Aug 2004 05:15:28 -0700 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i7QCABnV023292; Thu, 26 Aug 2004 05:10:11 -0700 (PDT) Received: from volzw2k (che-vpn-cluster-1-161.cisco.com [10.86.240.161]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id ALC51210; Thu, 26 Aug 2004 08:10:09 -0400 (EDT) From: "Bernie Volz" To: "'Stig Venaas'" , Subject: RE: [dhcwg] Attempt at text for draft-ietf-dhc-lifetime-02 Date: Thu, 26 Aug 2004 08:10:09 -0400 Organization: Cisco Message-ID: <000701c48b65$a23c6000$6401a8c0@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.5709 In-Reply-To: <20040825151559.GJ5677@sverresborg.uninett.no> X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4939.300 Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 3be09dac38eaa50f02d21c7fcee1128c Content-Transfer-Encoding: quoted-printable X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Hi Stig: Comments below, in line prefixed by "BV>". You don't document the format of the option? But, this is just a portion = of the text? - Bernie > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org]=20 > On Behalf Of Stig Venaas > Sent: Wednesday, August 25, 2004 11:16 AM > To: dhcwg@ietf.org > Subject: [dhcwg] Attempt at text for draft-ietf-dhc-lifetime-02 >=20 >=20 > I've tried to update the text based on all the suggestions=20 > and comments received. I may still try to improve the=20 > language, but please read the text below and let me know if=20 > you have problems with what it says. Lines from the draft are=20 > prefixed by "|". I have some comments/questions inline. I'm=20 > hoping that we can come to agreement on the text in 1-2=20 > weeks, so that I can finalize version 02, which then=20 > hopefully can go to WGLC. >=20 >=20 > | Information Refresh Time Option for DHCPv6 >=20 > What do you think of this name? I think the problem with just=20 > "refresh time option" is that it sounds more like an option=20 > for refreshing time... >=20 > |Abstract > | > | This document describes an option for specifying an upper=20 > bound for =20 > | how long a client should wait before refreshing information=20 > retrieved =20 > | from DHCP. It's useful for stateless DHCPv6 where there are no =20 BV> "It is used with stateless DHCPv6 as there are no" > | addresses or other entities with lifetimes that can tell=20 > the client =20 > | when to contact the DHCP server to refresh its configuration. >=20 > |1. Introduction > | > | DHCPv6 [RFC 3315] specifies stateful autoconfiguration for IPv6 =20 > | hosts. However, many hosts will use stateless=20 > autoconfiguration as =20 > | specified in [RFC 2462] for address assignment, and use=20 > DHCPv6 only =20 > | for other configuration data. This other configuration data will =20 BV> Add reference to [RFC 3736]? > | typically have no associated lifetime, hence there may be no =20 > | information telling a host when to refresh its DHCP configuration =20 > | data. > | > | This option may be useful in unstable environments where=20 > unexpected =20 > | changes are likely to occur, or for planned changes, including =20 > | renumbering where an administrator can gradually decrease=20 > the value =20 > | as the event nears. > | > | It may also be useful to allow the client to detect within an =20 > | appropriate amount of time when a specific service change has been =20 > | made, e.g. the addition of a new NTP server, or a change of=20 > address =20 > | of a DNS server within the local network. See [RENUMREQS] for =20 > | further details. >=20 > |3. Information refresh time option definition > | > | The information refresh time option specifies an upper=20 > bound for how =20 > | long a client should wait before refreshing information retrieved =20 > | from DHCP. It's only used for replies to Information-request =20 BV> "It is only used in Reply messages in response to = Information-Request" > | messages. In other messages there will usually be other=20 > options that =20 > | indicate when the client should contact the server, e.g. addresses =20 > | with lifetimes. > | > | Note that it's only an upper bound. If the client has any=20 > reason to =20 > | make a DHCP request before the refresh time expires, it should =20 > | attempt to refresh all the data. > | > | There are a number of potential reasons for the client to=20 > contact the =20 > | server before the refresh time expires. One reason might be other =20 > | options that have some associated lifetime that is shorter=20 > than the =20 > | refresh time. Other reasons might be a new IPv6 prefix=20 > announced by =20 > | a router, or that a server becomes unreachable on the=20 > address learnt =20 > | from DHCP. The client may also determine that it needs to request =20 > | additional options. >=20 > Do you think it's ok that client might update information if=20 > a server becomes unreachable? Say you learn DNS or NTP server=20 > address from DHCP, and at some point the resolver or NTP=20 > client determines that it can't reach the server. Would it=20 > then be ok to make the dhcp client request new data? An issue=20 > might be that if a server goes down, thousands of clients may=20 > try to update their DHCP config almost simultaneously... I'm=20 > only trying to give an example though, but is it a good one? NO. Like Rich, I think this would be an extremely bad idea. Let's remove = it. I'd replace the two above paragraphs with: The Information Refresh Time option's time is an upper bound as to = when the client SHOULD refresh its configuration information. A client MAY refresh this information before this time, such as if one or more prefixes for addresses in the configuration information expire. >=20 > | Note that this also means that it doesn't make sense to have =20 > | different refresh time options for different data, since when the =20 > | client has reason to refresh some of its data, it should=20 > also refresh=20 > | the remaining data. I'd reword this to simply state that there is ONE time for all = configuration data. > | > | The expiry of the refresh time in itself does not in=20 > anyway mean that =20 > | the client should remove the data. The client should keep it's =20 > | current data while attempting to refresh it. The client is=20 > however =20 > | free to fall back to other mechanisms if it cannot refresh=20 > the data =20 > | within a reasonable amount of time. > | > | In some cases the client uses a default refresh time IRT_DEFAULT. =20 > | The recommended value for IRT_DEFAULT is 86400 (24 hours). The =20 > | client implementation should allow for this value to be configured. >=20 > What do you think of 24 hours? I've got suggestions for 1,=20 > 6-12, at least 12 hours and more from you. I like 24 hours. >=20 > |3.1. Client behaviour > | > | A client MUST include this option in the Option Request=20 > Option (ORO) =20 > | when sending Information-request messages to the DHCP server. A =20 > | client MUST NOT include this option in the ORO in any other=20 > messages. Perhaps: "If a client supports this option, it MUST ..." > | > | If the reply to an Information-request message does not=20 > contain this =20 > | option, the client MUST behave as if the option with value =20 > | IRT_DEFAULT was provided. > | > | A client MUST also use the default refresh time IRT_DEFAULT if it =20 > | receives the option with value less than 600. >=20 > Do you agree with a minimum like this? It should make it=20 > harder to do bad things, and I don't see a use for <10=20 > minutes. If <600, would you rather use 600 than IRT_DEFAULT? As I suggested it, I like it. Perhaps we should specify IRT_MINIMUM as a parameter? >=20 > | If a client contacts the server to obtain new data or=20 > refresh some =20 > | existing data before the refresh time expires, then it SHOULD also =20 > | refresh all data covered by this option. > | > | When the client detects that the refresh time has expired,=20 > it SHOULD =20 > | try to update its configuration data by making a new DHCP=20 > request as =20 > | follows. > | > | Before making the request it MUST wait for a random amount=20 > of time =20 > | between 0 and INF_MAX_DELAY. INF_MAX_DELAY is defined in=20 > [RFC 3315]. =20 > | Note that this delay is in addition to the rules specified in [RFC =20 > | 3315]. > | > | Then it can make the DHCP request to update the=20 > configuration. The =20 > | message MUST be created and transmitted according to [RFC=20 > 3315]. For =20 > | an Information-request message it must be done according to=20 > the rules =20 > | for creation and transmission of Information-request messages in =20 > | section 18.1.5 of [RFC 3315]. >=20 > We could perhaps say clearly that it must send Information-request. >=20 > I think there's one thing we should discuss that is related=20 > to this. What if client at some point determines that it=20 > wants to request an address (switch to stateful mode). Then=20 > we should perhaps say that client should also refresh this=20 > data and forget the previous refresh time. What if it makes a=20 > request but does not get a reply with new data? Perhaps it=20 > should only forget refresh time when it gets new data, so=20 > that it can keep using it if not? Let's not mention this. Clients should always request this other conf. = info. >=20 > |3.2. Server behaviour > | > | A server sending a reply to an Information-request message SHOULD =20 > | include this option if it's included in the ORO of the request. It BV> "if it is". >=20 > Do you agree with SHOULD, or do you want MUST? My thinking is=20 > that server should allow the refresh time to be configured,=20 > and probably have IRT_DEFAULT as the default value (although=20 > some servers may prefer some other default, e.g. if made for=20 > us in a specific environment). Rather than sending the value=20 > IRT_DEFAULT it might just as well not include it. BV> If configured in the server, the server MUST return it (if = requested). I do not think the server should treat this option specially - such as = supply a default if not configured. >=20 > Do you think we should talk about this being configurable on=20 > the server and server default, or is it all pretty obvious=20 > and better left to the implementation? >=20 BV> Pretty obvious. > | MUST NOT be included if it's not in the ORO of the request. >=20 > Is this ok? There's no harm in including it, but it's totally=20 > pointless since we require client to include it in ORO, so if=20 > not in the request, the client will ignore it. BV> No, drop it. A server is always free to include any other options it wants. If a client doesn't support it, it will ignore it. >=20 > | When server sends a message that is not a reply to an=20 > Information- =20 > | request message, it MUST NOT include the option. >=20 > It would be sufficient to say that it's only to be included=20 > if requested by client, since client MUST ONLY request it in=20 > Information-request messages. So this paragraph could be omitted. BV> I'd drop it. If a client were to include this option in an ORO for a non-Information-Request message, and it was configured in the server, = the server might return it (again, want to avoid special code in the server) = and I think that is OK. The client is wrong but so what - what the client = might do with this time is unknown but since it is broken, do we really care? = Fix the client. >=20 > | The option value MUST be no less than 600. BV> I'd leave this to the client. >=20 > Stig >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg >=20 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri Aug 27 01:54:00 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15920; Fri, 27 Aug 2004 01:54:00 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0ZaD-0007B4-Cy; Fri, 27 Aug 2004 01:47:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0ZZ9-0006rJ-CX for dhcwg@megatron.ietf.org; Fri, 27 Aug 2004 01:46:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15662 for ; Fri, 27 Aug 2004 01:46:21 -0400 (EDT) Received: from 203-69-237-46.hinet-ip.hinet.net ([203.69.237.46] helo=delta.noi.kre.to) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C0ZaB-0000mT-Mq for dhcwg@ietf.org; Fri, 27 Aug 2004 01:47:30 -0400 Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.noi.kre.to (8.12.9/8.11.6) with ESMTP id i7R5j29O000810; Fri, 27 Aug 2004 12:45:06 +0700 (ICT) From: Robert Elz To: "Bernie Volz" Subject: Re: [dhcwg] behavior on lifetime expiration (Re: comments ondraft-ietf-dhc-lifetime-01.txt) In-Reply-To: <001501c48a3e$f4246d90$6401a8c0@amer.cisco.com> References: <001501c48a3e$f4246d90$6401a8c0@amer.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 27 Aug 2004 12:45:02 +0700 Message-ID: <29651.1093585502@munnari.OZ.AU> X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: dhcwg@ietf.org, tjc@ecs.soton.ac.uk, jdq@lucent.com, "'Stig Venaas'" X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Date: Tue, 24 Aug 2004 21:00:45 -0400 From: "Bernie Volz" Message-ID: <001501c48a3e$f4246d90$6401a8c0@amer.cisco.com> | I'd vote for "Refresh Time Option". I have no problem renaming this The name of the option isn't really the point. Jinmei has a valid point, but didn't manage to express the real issue perhaps as clearly as should have been done. The issue isn't really "what happens when the lifetime expires" (whatever you call it), the issue is "what happens when the DHCP server doesn't give us some information that was given to us before" ? You're mostly all thinking (it seems) of the case where the DHCP server doesn't reply at all to a later request for information - and so no new data is provided. The other case, where the dhcp server does reply, and supplies new information. We all know what to do in that case. But those aren't the only two cases - the problem case is what happens when the (a) DHCP server does reply, but only supplies values for some of the options that an earlier DHCP response had supplied. That is, suppose I ask for NTP servers and DNS servers. When I boot I get told fe80::99 for NTP, and fe80::7 for DNS. Then later, I ask again, and get told 2001:1234:5678::16 for DNS, but get no NTP server addresses supplied at all. What is the client expected to do in that case? It seems reasonably clear (to me anyway) that the likely cause of this kind of change, is that the client is a portable device, that has been moved from one location to another, and is now talking to a different DHCP server than it was before (though entirely possibly both servers migh just happen to have been configured at fe80::9 on their respective LANs). Should the client just keep on using the (probably now bogus) NTP server address, or should it just give up on NTP, given the local lan most likely has no available server? Does it make a difference if the previous "lifetime" has or has not expired? Or for that matter, whether or not there was ever a lifetime option, or whether or not the client requested it (and knows anything aboutthis new option) ? Once you work out the right answer to that problem, it is a minor issue to extend that answer to the case where no answers at all are returned. kre ps: notice here I am not suggesting what the answer should be. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri Aug 27 02:20:00 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA01197; Fri, 27 Aug 2004 02:20:00 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0ZyN-0007RN-SF; Fri, 27 Aug 2004 02:12:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0ZwD-0006F4-KH for dhcwg@megatron.ietf.org; Fri, 27 Aug 2004 02:10:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26411 for ; Fri, 27 Aug 2004 02:10:12 -0400 (EDT) Received: from 203-69-237-46.hinet-ip.hinet.net ([203.69.237.46] helo=delta.noi.kre.to) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C0ZxH-00019w-Fw for dhcwg@ietf.org; Fri, 27 Aug 2004 02:11:21 -0400 Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.noi.kre.to (8.12.9/8.11.6) with ESMTP id i7R68W9O011614; Fri, 27 Aug 2004 13:08:33 +0700 (ICT) From: Robert Elz To: "Bernie Volz" Subject: Re: [dhcwg] comments on draft-ietf-dhc-lifetime-01.txt In-Reply-To: <000e01c486b3$66af02b0$6401a8c0@amer.cisco.com> References: <000e01c486b3$66af02b0$6401a8c0@amer.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 27 Aug 2004 13:08:32 +0700 Message-ID: <6493.1093586912@munnari.OZ.AU> X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: dhcwg@ietf.org, tjc@ecs.soton.ac.uk, "'Stig Venaas'" , jdq@lucent.com X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Date: Fri, 20 Aug 2004 08:44:14 -0400 From: "Bernie Volz" Message-ID: <000e01c486b3$66af02b0$6401a8c0@amer.cisco.com> | I'm OK to restricting the Lifetime Option to replies to | Information-Request's. | | The client MUST ignore a Lifetime Option that is in any message other than a | REPLY to an INFORMATION-REQUEST. A client MUST NOT include the Lifetime | Option number in an ORO except when sending an INFORMATION-REQUEST message. | | The server MUST NOT include the Lifetime Option in any message other than a | REPLY to an INFORMATION-REQUEST. I've been reading all of the messages on this topic (catching up) and I haven't managed to find a reason why anyone would want to add this kind of restriction, I just don't see the need. You seem to all be imagining that things have to get much more complex for the clients if they get two timer values, and they're different. But that's nonsense. All of these timers are just upper bounds - a client that wants to be simple just wants a single timer. If one option says "the upper bound is 86400 seconds" and another says "the upper bound is 43200 seconds", then to the client, it just tries again, for all the info, before the 43200 second timer expires. This isn't complex, it is trivial. On the other hand, if the client doesn't need to be quite that simple, then I see no compelling reason to require it to be so. In particular, and especially given we're talking about IPv6, I see no reason why a client shouldn't use very long lease times (well, comparatively long - in IPv4 I've seen values counted in years - that's absurd, but values of several weeks for address lifetime should be reasonable). If there's no prospect that the prefixes are going to change anytime soon, there's no reason that an IPv6 node shouldn't be able to keep using its address for a very long time, even if the DHCP server is down for an extended period (and that's what the lease timers are all about really - no-one disputes but that addresses stop being used when their lifetime expires). On the other hand, we may want to be able to shift which hosts run various servers with much time lag, so the "other option lifetime" (or whatever it ends up being called) might want to be quite a bit smaller (maybe measured in hours, or a day or so). A simple client will simply refresh everything when the shorter timer expires. A complex one might prefer to just use info requests when the shorter info timer expires, and only do the full dhcp protocol when the addresses actually expire - aside from anything else, this allows dhcp-lite servers to respond, where only a full duchv6 server can handle address requests. Why would anyone really want to forbid this? That's all the proposed language is doing, nothing really gets any simpler (in a simple client now instead of just taking the lower timer value, it instead has to know to ignore this particular option if it happens to occur in that particular message type - which I think is a rather unusual case). kre _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri Aug 27 02:27:29 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02060; Fri, 27 Aug 2004 02:27:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0aBH-0005ov-Bb; Fri, 27 Aug 2004 02:25:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0a9T-0004on-Im for dhcwg@megatron.ietf.org; Fri, 27 Aug 2004 02:23:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA01754 for ; Fri, 27 Aug 2004 02:23:53 -0400 (EDT) Received: from tyholt.uninett.no ([158.38.60.10]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C0aAY-0001RI-SV for dhcwg@ietf.org; Fri, 27 Aug 2004 02:25:03 -0400 Received: from sverresborg.uninett.no (sverresborg.uninett.no [IPv6:2001:700:e000:0:204:75ff:fee4:423b]) by tyholt.uninett.no (8.12.10/8.12.10) with ESMTP id i7R6NMOK013396; Fri, 27 Aug 2004 08:23:22 +0200 Received: (from venaas@localhost) by sverresborg.uninett.no (8.12.8/8.12.8/Submit) id i7R6NLh5015094; Fri, 27 Aug 2004 08:23:21 +0200 X-Authentication-Warning: sverresborg.uninett.no: venaas set sender to Stig.Venaas@uninett.no using -f Date: Fri, 27 Aug 2004 08:23:21 +0200 From: Stig Venaas To: Robert Elz Subject: Re: [dhcwg] behavior on lifetime expiration (Re: comments ondraft-ietf-dhc-lifetime-01.txt) Message-ID: <20040827062321.GA15052@sverresborg.uninett.no> References: <001501c48a3e$f4246d90$6401a8c0@amer.cisco.com> <29651.1093585502@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <29651.1093585502@munnari.OZ.AU> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: dhcwg@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org On Fri, Aug 27, 2004 at 12:45:02PM +0700, Robert Elz wrote: > Date: Tue, 24 Aug 2004 21:00:45 -0400 > From: "Bernie Volz" > Message-ID: <001501c48a3e$f4246d90$6401a8c0@amer.cisco.com> > > | I'd vote for "Refresh Time Option". I have no problem renaming this > > The name of the option isn't really the point. Jinmei has a valid point, > but didn't manage to express the real issue perhaps as clearly as should > have been done. > > The issue isn't really "what happens when the lifetime expires" (whatever > you call it), the issue is "what happens when the DHCP server doesn't give > us some information that was given to us before" ? > > You're mostly all thinking (it seems) of the case where the DHCP server > doesn't reply at all to a later request for information - and so no new > data is provided. > > The other case, where the dhcp server does reply, and supplies new information. > We all know what to do in that case. > > But those aren't the only two cases - the problem case is what happens when > the (a) DHCP server does reply, but only supplies values for some of the > options that an earlier DHCP response had supplied. > > That is, suppose I ask for NTP servers and DNS servers. When I boot > I get told fe80::99 for NTP, and fe80::7 for DNS. Then later, I ask > again, and get told 2001:1234:5678::16 for DNS, but get no NTP server > addresses supplied at all. > > What is the client expected to do in that case? It seems reasonably clear > (to me anyway) that the likely cause of this kind of change, is that the > client is a portable device, that has been moved from one location to > another, and is now talking to a different DHCP server than it was before > (though entirely possibly both servers migh just happen to have been > configured at fe80::9 on their respective LANs). > > Should the client just keep on using the (probably now bogus) NTP server > address, or should it just give up on NTP, given the local lan most > likely has no available server? Does it make a difference if the > previous "lifetime" has or has not expired? Or for that matter, whether > or not there was ever a lifetime option, or whether or not the client > requested it (and knows anything aboutthis new option) ? Thanks for making this clear. We just had some discussion on this, but the problem was perhaps not clearly stated. And this is one of the things I tried to ask. What would you do if this happened without this option. As you said, this is a more generic problem, and it makes me wonder whether people already have thought about this. > Once you work out the right answer to that problem, it is a minor issue to > extend that answer to the case where no answers at all are returned. Is there a theoretical possibility that you get a response, but without any options? That should possibly be treated differently from not getting any reply at all. > kre > > ps: notice here I am not suggesting what the answer should be. If you get a response from a server, and later a new from the same server but with some options missing, then I believe the administrator must have removed the it on purpose and the old information is not valid. However, this is not so clear if you get a reply from a new server. If you're still in the same site, then I think situation is pretty much like above. But if the client has moved to a new site, the old information might be valid, but not necessarily. E.g. if I learn an NTP server at home, I might wish to keep using it from a new location, even if the administrator in that new location doesn't care about NTP and hasn't configured anything. Whether I should continue using the one at home really depends on policy. The access to the NTP server might for instance be blocked in a firewall deployed in/around my home site or the site I'm now visiting. I'm not sure if the answer to these issues need to be described in the draft since it's a more generic issue. OTOH this draft might be the most obvious place we have for now. Stig _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri Aug 27 02:59:38 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA04327; Fri, 27 Aug 2004 02:59:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0ad6-0002i6-8z; Fri, 27 Aug 2004 02:54:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0abj-0002QV-Up for dhcwg@megatron.ietf.org; Fri, 27 Aug 2004 02:53:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA03994 for ; Fri, 27 Aug 2004 02:53:05 -0400 (EDT) Received: from 203-69-237-46.hinet-ip.hinet.net ([203.69.237.46] helo=delta.noi.kre.to) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C0acn-0001zk-TB for dhcwg@ietf.org; Fri, 27 Aug 2004 02:54:15 -0400 Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.noi.kre.to (8.12.9/8.11.6) with ESMTP id i7R6qn9O002427; Fri, 27 Aug 2004 13:52:52 +0700 (ICT) From: Robert Elz To: Stig Venaas Subject: Re: [dhcwg] behavior on lifetime expiration (Re: comments ondraft-ietf-dhc-lifetime-01.txt) In-Reply-To: <20040827062321.GA15052@sverresborg.uninett.no> References: <20040827062321.GA15052@sverresborg.uninett.no> <001501c48a3e$f4246d90$6401a8c0@amer.cisco.com> <29651.1093585502@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 27 Aug 2004 13:52:49 +0700 Message-ID: <77.1093589569@munnari.OZ.AU> X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: dhcwg@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Date: Fri, 27 Aug 2004 08:23:21 +0200 From: Stig Venaas Message-ID: <20040827062321.GA15052@sverresborg.uninett.no> | I'm not sure if the answer to these issues need to be described in | the draft since it's a more generic issue. OTOH this draft might be | the most obvious place we have for now. Yes, it is a much bigger issue than just providing a mechanism for specifying when a new info request should be attempted. But it is when we specify that that the problem becomes obvious, and we need to have a solution - until now (including in IPv4) we mostly just pretended that none of this ever happened, and once learned, all of this information was static forever (hence, DNS "servers" (back end resolvers really) go in /etc/resolv.conf - that gets updated when the info changes, but applications know nothing of that, and simply keep on using the old information forever). All this is something of a quagmire - but is something that needs to be addressed, and ought to be addressed along with this new option (if not necessarily in the same document). kre _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri Aug 27 04:36:54 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09737; Fri, 27 Aug 2004 04:36:54 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0cBp-00033G-Pu; Fri, 27 Aug 2004 04:34:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0cBX-0002uC-66 for dhcwg@megatron.ietf.org; Fri, 27 Aug 2004 04:34:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09596 for ; Fri, 27 Aug 2004 04:34:08 -0400 (EDT) Received: from raven.ecs.soton.ac.uk ([152.78.70.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C0cCc-0003tI-Om for dhcwg@ietf.org; Fri, 27 Aug 2004 04:35:20 -0400 Received: from magpie.ecs.soton.ac.uk (magpie.ecs.soton.ac.uk [152.78.68.131]) by raven.ecs.soton.ac.uk (8.12.10/8.12.10) with ESMTP id i7R8Y7gg012015 for ; Fri, 27 Aug 2004 09:34:07 +0100 (BST) Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by magpie.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id JAA18370 for ; Fri, 27 Aug 2004 09:34:06 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id i7R8Y6a27338 for dhcwg@ietf.org; Fri, 27 Aug 2004 09:34:06 +0100 Date: Fri, 27 Aug 2004 09:34:06 +0100 From: Tim Chown To: dhcwg@ietf.org Subject: Re: [dhcwg] Attempt at text for draft-ietf-dhc-lifetime-02 Message-ID: <20040827083406.GA26829@login.ecs.soton.ac.uk> Mail-Followup-To: dhcwg@ietf.org References: <20040825151559.GJ5677@sverresborg.uninett.no> <000701c48b65$a23c6000$6401a8c0@amer.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <000701c48b65$a23c6000$6401a8c0@amer.cisco.com> User-Agent: Mutt/1.4i X-MailScanner-Information: Please contact helpdesk@ecs.soton.ac.uk for more information X-ECS-MailScanner: Found to be clean X-MailScanner-From: tjc@smtp.ecs.soton.ac.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org On Thu, Aug 26, 2004 at 08:10:09AM -0400, Bernie Volz wrote: > > > > Do you think it's ok that client might update information if > > a server becomes unreachable? Say you learn DNS or NTP server > > address from DHCP, and at some point the resolver or NTP > > client determines that it can't reach the server. Would it > > then be ok to make the dhcp client request new data? An issue > > might be that if a server goes down, thousands of clients may > > try to update their DHCP config almost simultaneously... I'm > > only trying to give an example though, but is it a good one? > > NO. Like Rich, I think this would be an extremely bad idea. Let's remove it. > > I'd replace the two above paragraphs with: > > The Information Refresh Time option's time is an upper bound as to when > the client SHOULD refresh its configuration information. A client MAY > refresh this information before this time, such as if one or more > prefixes for addresses in the configuration information expire. That sounds fine to me. > > | Note that this also means that it doesn't make sense to have > > | different refresh time options for different data, since when the > > | client has reason to refresh some of its data, it should > > also refresh > > | the remaining data. > > I'd reword this to simply state that there is ONE time for all configuration > data. Also fine by me. Less is more :) > > | In some cases the client uses a default refresh time IRT_DEFAULT. > > | The recommended value for IRT_DEFAULT is 86400 (24 hours). The > > | client implementation should allow for this value to be configured. > > > > What do you think of 24 hours? I've got suggestions for 1, > > 6-12, at least 12 hours and more from you. > > I like 24 hours. The value will depend on the environment. I think if the admin knows the environment is one liable to be changed, they will make active use of this timer, if not, then it'll be a typical (relatively) static environment in which case 24 hours would be ample. In the event of a major change, the admin can ramp it down. > > Do you agree with a minimum like this? It should make it > > harder to do bad things, and I don't see a use for <10 > > minutes. If <600, would you rather use 600 than IRT_DEFAULT? > > As I suggested it, I like it. Perhaps we should specify IRT_MINIMUM as a > parameter? I think this is an interesting suggestion. Again, it depends on the environment. If it's a renumbering event, and a document like Fred Baker's without-a-flag-day draft is followed, the minimum value can certainly be higher than 10 minutes. One would assume in that type of renumbering environment the old and new prefixes coexist for some time. If a DNS or NTP server is being turned off/phased out, then the replacement should be made available in advance. The awkward case is where there is a sudden transition between (DNS, NTP, etc) servers or networks, but these are I believe typically user, not administrator, driven. Tim _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri Aug 27 07:01:51 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19257; Fri, 27 Aug 2004 07:01:50 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0eHU-0002t0-O6; Fri, 27 Aug 2004 06:48:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0eFd-0002U6-4u for dhcwg@megatron.ietf.org; Fri, 27 Aug 2004 06:46:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18257 for ; Fri, 27 Aug 2004 06:46:29 -0400 (EDT) From: matthew.ford@bt.com Received: from smtp1.smtp.bt.com ([217.32.164.137]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C0eGi-0006UR-37 for dhcwg@ietf.org; Fri, 27 Aug 2004 06:47:43 -0400 Received: from i2km96-ukbr.domain1.systemhost.net ([193.113.197.84]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 27 Aug 2004 11:46:42 +0100 Received: from i2km41-ukdy.domain1.systemhost.net ([193.113.30.29]) by i2km96-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Fri, 27 Aug 2004 11:46:41 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [dhcwg] Attempt at text for draft-ietf-dhc-lifetime-02 Date: Fri, 27 Aug 2004 11:46:41 +0100 Message-ID: <0AAF93247C75E3408638B965DEE11A7009943EFD@i2km41-ukdy.domain1.systemhost.net> Thread-Topic: [dhcwg] Attempt at text for draft-ietf-dhc-lifetime-02 thread-index: AcSKvccrDrJPNfWiR9CectTdxbkgewBZNLDw To: X-OriginalArrivalTime: 27 Aug 2004 10:46:41.0973 (UTC) FILETIME=[23737650:01C48C23] X-Spam-Score: 0.3 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: quoted-printable Cc: dhcwg@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Hi Stig, > I've tried to update the text based on all the suggestions and > comments received. I may still try to improve the language, but > please read the text below and let me know if you have problems > with what it says. Lines from the draft are prefixed by "|". I > have some comments/questions inline. I'm hoping that we can come > to agreement on the text in 1-2 weeks, so that I can finalize > version 02, which then hopefully can go to WGLC. >=20 >=20 >> Information Refresh Time Option for DHCPv6 >=20 > What do you think of this name? I think the problem with just > "refresh time option" is that it sounds more like an option for > refreshing time...=20 I think if you hyphenate Refresh-Time then the meaning is clearer. Mat _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri Aug 27 07:43:04 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21682; Fri, 27 Aug 2004 07:43:04 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0ezW-0002ih-2C; Fri, 27 Aug 2004 07:33:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0eyn-0002YX-VK for dhcwg@megatron.ietf.org; Fri, 27 Aug 2004 07:33:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21088 for ; Fri, 27 Aug 2004 07:33:12 -0400 (EDT) Received: from tyholt.uninett.no ([158.38.60.10]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C0ezv-0007LU-Ar for dhcwg@ietf.org; Fri, 27 Aug 2004 07:34:24 -0400 Received: from sverresborg.uninett.no (sverresborg.uninett.no [IPv6:2001:700:e000:0:204:75ff:fee4:423b]) by tyholt.uninett.no (8.12.10/8.12.10) with ESMTP id i7RBWdOK021455; Fri, 27 Aug 2004 13:32:39 +0200 Received: (from venaas@localhost) by sverresborg.uninett.no (8.12.8/8.12.8/Submit) id i7RBWdhu015838; Fri, 27 Aug 2004 13:32:39 +0200 X-Authentication-Warning: sverresborg.uninett.no: venaas set sender to Stig.Venaas@uninett.no using -f Date: Fri, 27 Aug 2004 13:32:39 +0200 From: Stig Venaas To: matthew.ford@bt.com Subject: Re: [dhcwg] Attempt at text for draft-ietf-dhc-lifetime-02 Message-ID: <20040827113239.GH15420@sverresborg.uninett.no> References: <0AAF93247C75E3408638B965DEE11A7009943EFD@i2km41-ukdy.domain1.systemhost.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0AAF93247C75E3408638B965DEE11A7009943EFD@i2km41-ukdy.domain1.systemhost.net> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: dhcwg@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org On Fri, Aug 27, 2004 at 11:46:41AM +0100, matthew.ford@bt.com wrote: > Hi Stig, > > > I've tried to update the text based on all the suggestions and > > comments received. I may still try to improve the language, but > > please read the text below and let me know if you have problems > > with what it says. Lines from the draft are prefixed by "|". I > > have some comments/questions inline. I'm hoping that we can come > > to agreement on the text in 1-2 weeks, so that I can finalize > > version 02, which then hopefully can go to WGLC. > > > > > >> Information Refresh Time Option for DHCPv6 > > > > What do you think of this name? I think the problem with just > > "refresh time option" is that it sounds more like an option for > > refreshing time... > > I think if you hyphenate Refresh-Time then the meaning is clearer. Yes, I agree, and I was about to do that, until I checked with my local linguist friend. At least he claimed it was no good... Thanks, Stig _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri Aug 27 07:49:25 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21985; Fri, 27 Aug 2004 07:49:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0fD8-000529-1f; Fri, 27 Aug 2004 07:48:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0f8M-00045W-Fz for dhcwg@megatron.ietf.org; Fri, 27 Aug 2004 07:43:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21697 for ; Fri, 27 Aug 2004 07:43:04 -0400 (EDT) From: matthew.ford@bt.com Received: from smtp2.smtp.bt.com ([217.32.164.150]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C0f9R-0007Vf-Nt for dhcwg@ietf.org; Fri, 27 Aug 2004 07:44:17 -0400 Received: from i2km99-ukbr.domain1.systemhost.net ([193.113.197.31]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 27 Aug 2004 12:43:11 +0100 Received: from i2km41-ukdy.domain1.systemhost.net ([193.113.30.29]) by i2km99-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Fri, 27 Aug 2004 12:43:11 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [dhcwg] Attempt at text for draft-ietf-dhc-lifetime-02 Date: Fri, 27 Aug 2004 12:43:10 +0100 Message-ID: <0AAF93247C75E3408638B965DEE11A7009943F85@i2km41-ukdy.domain1.systemhost.net> Thread-Topic: [dhcwg] Attempt at text for draft-ietf-dhc-lifetime-02 thread-index: AcSMKasU4VtOYt5TS0WaX7GCzKuM1QAAWK1w To: X-OriginalArrivalTime: 27 Aug 2004 11:43:11.0175 (UTC) FILETIME=[0792A570:01C48C2B] X-Spam-Score: 0.3 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: quoted-printable Cc: dhcwg@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: quoted-printable On 27 August 2004 12:33, Stig Venaas wrote: > On Fri, Aug 27, 2004 at 11:46:41AM +0100, matthew.ford@bt.com wrote: >> I think if you hyphenate Refresh-Time then the meaning is clearer. >=20 > Yes, I agree, and I was about to do that, until I checked > with my local > linguist friend. At least he claimed it was no good... Nonsense - this is precisely what hyphens are for! Mat _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri Aug 27 09:13:05 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27355; Fri, 27 Aug 2004 09:13:05 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0gRK-0003WG-BM; Fri, 27 Aug 2004 09:06:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0gFH-000136-6f for dhcwg@megatron.ietf.org; Fri, 27 Aug 2004 08:54:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26488 for ; Fri, 27 Aug 2004 08:54:17 -0400 (EDT) Received: from hoemail1.lucent.com ([192.11.226.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C0gGN-0000bj-71 for dhcwg@ietf.org; Fri, 27 Aug 2004 08:55:30 -0400 Received: from homail.ho.lucent.com (h135-17-192-10.lucent.com [135.17.192.10]) by hoemail1.lucent.com (8.12.11/8.12.11) with ESMTP id i7RCsCkC007802; Fri, 27 Aug 2004 07:54:12 -0500 (CDT) Received: from kraken.mh.lucent.com by homail.ho.lucent.com (8.11.7+Sun/EMS-1.5 sol2) id i7RCsCY01808; Fri, 27 Aug 2004 08:54:12 -0400 (EDT) From: Joe Quanaim To: Stig Venaas , dhcwg@ietf.org Subject: Re: [dhcwg] Attempt at text for draft-ietf-dhc-lifetime-02 Date: Fri, 27 Aug 2004 08:54:09 -0400 User-Agent: KMail/1.5.4 References: <20040825151559.GJ5677@sverresborg.uninett.no> In-Reply-To: <20040825151559.GJ5677@sverresborg.uninett.no> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200408270854.10485.jdq@lucent.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7bit X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jdq@lucent.com List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 7bit Stig Venaas wrote: > | A client MUST also use the default refresh time IRT_DEFAULT if it > | receives the option with value less than 600. > > Do you agree with a minimum like this? It should make it harder to > do bad things, and I don't see a use for <10 minutes. If <600, > would you rather use 600 than IRT_DEFAULT? I think a minimum is a good idea, but it probably should not be reset to 24 hours. That's probably not what an admin intended by setting the value that low. Also, are 0 or 0xffffffff a special case like elsewhere in dhcpv6? I am not sure it's necessary; I am just bringing up the point. Thanks, Joe Quanaim. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri Aug 27 09:46:08 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29395; Fri, 27 Aug 2004 09:46:07 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0gy1-0001MB-Ot; Fri, 27 Aug 2004 09:40:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0gok-0008O7-0c for dhcwg@megatron.ietf.org; Fri, 27 Aug 2004 09:30:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28406 for ; Fri, 27 Aug 2004 09:30:55 -0400 (EDT) Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C0gpq-0001Hw-8y for dhcwg@ietf.org; Fri, 27 Aug 2004 09:32:09 -0400 Received: from homail.ho.lucent.com (h135-17-192-10.lucent.com [135.17.192.10]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id i7RDUIEG002450; Fri, 27 Aug 2004 08:30:19 -0500 (CDT) Received: from kraken.mh.lucent.com by homail.ho.lucent.com (8.11.7+Sun/EMS-1.5 sol2) id i7RDUIY16252; Fri, 27 Aug 2004 09:30:18 -0400 (EDT) From: Joe Quanaim To: Robert Elz , Stig Venaas Subject: Re: [dhcwg] behavior on lifetime expiration (Re: comments ondraft-ietf-dhc-lifetime-01.txt) Date: Fri, 27 Aug 2004 09:29:46 -0400 User-Agent: KMail/1.5.4 References: <20040827062321.GA15052@sverresborg.uninett.no> <29651.1093585502@munnari.OZ.AU> <77.1093589569@munnari.OZ.AU> In-Reply-To: <77.1093589569@munnari.OZ.AU> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200408270928.58762.jdq@lucent.com> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jdq@lucent.com List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 7bit Robert Elz wrote: > Date: Fri, 27 Aug 2004 08:23:21 +0200 > From: Stig Venaas > Message-ID: <20040827062321.GA15052@sverresborg.uninett.no> > > | I'm not sure if the answer to these issues need to be described in > | the draft since it's a more generic issue. OTOH this draft might be > | the most obvious place we have for now. > > Yes, it is a much bigger issue than just providing a mechanism for > specifying when a new info request should be attempted. > > But it is when we specify that that the problem becomes obvious, and > we need to have a solution - until now (including in IPv4) we mostly > just pretended that none of this ever happened, and once learned, all > of this information was static forever (hence, DNS "servers" (back end > resolvers really) go in /etc/resolv.conf - that gets updated when the > info changes, but applications know nothing of that, and simply keep on > using the old information forever). > > All this is something of a quagmire - but is something that needs to be > addressed, and ought to be addressed along with this new option (if not > necessarily in the same document). I agree that this is an issue, but I don't think it's something this document should address. It's a larger part of the dhcp specification, and the example you gave could happen in stateful configuration as well. For the example involving dns and this option, I read the draft as such: when the option expires, don't dismiss the configured dns data. Request new information. When new information is received, replace the existing data with the newly obtained. This prevents the client from being left without dns while making an attempt to be current. Also, if a server returns an empty set of dns servers, that is what the client should use. It doesn't make much sense, but misconfigured dhcp servers aren't something a client should be programmed to handle. Generalizing this issue is not simple. How does a dhcp client update the ntp configuration? And why does it? The ntp configuration could be pointing to a server reachable from multiple networks. This seems like local policy. Joe Quanaim. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri Aug 27 10:33:14 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03581; Fri, 27 Aug 2004 10:33:14 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0hcY-0002ku-4K; Fri, 27 Aug 2004 10:22:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0hbF-0000CQ-3I; Fri, 27 Aug 2004 10:21:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02511; Fri, 27 Aug 2004 10:21:01 -0400 (EDT) Received: from mta0.huawei.com ([61.144.161.41] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C0hcK-0002A1-Gv; Fri, 27 Aug 2004 10:22:16 -0400 Received: from keshavaak (mta1.huawei.com [172.17.1.60]) by mta1.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTPA id <0I33008CVYON0Y@mta1.huawei.com>; Fri, 27 Aug 2004 21:55:37 +0800 (CST) Date: Fri, 27 Aug 2004 19:39:52 +0530 From: Keshava To: dhcwg@ietf.org, ipv6@ietf.org Message-id: <001f01c48c3f$86a44f80$1604120a@keshavaak> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-Priority: 3 X-MSMail-priority: Normal X-imss-version: 2.7 X-imss-result: Passed X-imss-approveListMatch: *@huawei.com X-Spam-Score: 0.4 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: keshavaak@huawei.com, maoshx@huawei.com Subject: [dhcwg] dhcp6 verndor class option X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Keshava List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0775208248==" Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org This is a multi-part message in MIME format. --===============0775208248== Content-type: multipart/alternative; boundary="Boundary_(ID_6hDmIfeoCuAc3QwOZr/rDg)" This is a multi-part message in MIME format. --Boundary_(ID_6hDmIfeoCuAc3QwOZr/rDg) Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT Hi, Can you please clarify in he RFC 3315 (DHCP6) "Appearance of Options in Message Types" section mentions that the dhcp6 relay should support vendor class option. But in the message processing in the "Section 22.16 Vendor Class Option" does not mention any thing about this for relay . It only mentions about how the client should process this. Can some one please clarify this what should be done for dhcp6 relay ? regards, keshava --Boundary_(ID_6hDmIfeoCuAc3QwOZr/rDg) Content-type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT
Hi,
    Can you please clarify  in he RFC 3315 (DHCP6)
 
   "Appearance of Options in Message Types" section mentions that the dhcp6 relay should support
     vendor class option.
  
    But in the message processing in the "Section 22.16 Vendor Class Option"  does not mention any
    thing about this for relay . It only mentions about how the client should process this.
 
     Can some one please clarify this  what should be done for dhcp6 relay ?
 
 
regards,
keshava
--Boundary_(ID_6hDmIfeoCuAc3QwOZr/rDg)-- --===============0775208248== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --===============0775208248==-- From dhcwg-bounces@ietf.org Fri Aug 27 14:45:51 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24051; Fri, 27 Aug 2004 14:45:51 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0lf2-0000SK-Ov; Fri, 27 Aug 2004 14:41:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0lWm-0006YE-7B for dhcwg@megatron.ietf.org; Fri, 27 Aug 2004 14:32:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22073 for ; Fri, 27 Aug 2004 14:32:42 -0400 (EDT) Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C0lXx-0007no-5m for dhcwg@ietf.org; Fri, 27 Aug 2004 14:33:58 -0400 Received: from [10.222.34.118] (m815f36d0.tmodns.net [208.54.95.129]) by toccata.fugue.com (Postfix) with ESMTP id 932E51B2003 for ; Fri, 27 Aug 2004 13:31:49 -0500 (CDT) Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: <200408270928.58762.jdq@lucent.com> References: <20040827062321.GA15052@sverresborg.uninett.no> <29651.1093585502@munnari.OZ.AU> <77.1093589569@munnari.OZ.AU> <200408270928.58762.jdq@lucent.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <7B6727F5-F857-11D8-A7B9-000A95D9C74C@fugue.com> Content-Transfer-Encoding: 7bit From: Ted Lemon Subject: Re: [dhcwg] behavior on lifetime expiration (Re: comments ondraft-ietf-dhc-lifetime-01.txt) Date: Fri, 27 Aug 2004 13:32:42 -0500 To: dhcwg@ietf.org X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 7bit On Aug 27, 2004, at 8:29 AM, Joe Quanaim wrote: > For the example involving dns and this option, I read the draft as > such: when > the option expires, don't dismiss the configured dns data. Request new > information. When new information is received, replace the existing > data > with the newly obtained. This prevents the client from being left > without > dns while making an attempt to be current. Also, if a server returns > an > empty set of dns servers, that is what the client should use. It > doesn't > make much sense, but misconfigured dhcp servers aren't something a > client > should be programmed to handle. I agree that this is what the client should do. If this isn't clear to kre from reading it, then perhaps we need to make it clearer, but I certainly agree that this is the behavior that we want to specify. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri Aug 27 23:41:02 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA03228; Fri, 27 Aug 2004 23:41:02 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0twy-0006Vx-Ky; Fri, 27 Aug 2004 23:32:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0tuE-0005zh-VJ for dhcwg@megatron.ietf.org; Fri, 27 Aug 2004 23:29:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA02630 for ; Fri, 27 Aug 2004 23:29:26 -0400 (EDT) Received: from smtp1.agni.com ([202.53.160.4] helo=mx.agni.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C0tvP-0003U6-7F for dhcwg@ietf.org; Fri, 27 Aug 2004 23:30:48 -0400 Received: from inspbg.com ([202.53.160.107] helo=server.inspbg) by mx.agni.com with esmtp (Exim 4.12) id 1C0tt4-0005SY-00 for dhcwg@ietf.org; Sat, 28 Aug 2004 09:28:24 +0600 Received: by SERVER with Internet Mail Service (5.5.2448.0) id ; Sat, 28 Aug 2004 09:28:26 +0600 Message-ID: From: "Dhaka . Razzak" To: "'dhcwg@ietf.org'" Date: Sat, 28 Aug 2004 09:28:24 +0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-MailScanner-Information: Scanned by agni's email virus scanner at smtp1 X-MailScanner: Clean X-MailScanner-SpamCheck: not spam, SpamAssassin (score=-4.9, required 6, BAYES_00 -4.90) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a0494a0224ca59418dd8f92694c1fdb Subject: [dhcwg] Re: Contents of dhcwg digest... X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org -----Original Message----- From: dhcwg-request@ietf.org [SMTP:dhcwg-request@ietf.org] Sent: Friday, August 27, 2004 10:12 PM To: dhcwg@ietf.org Subject: dhcwg Digest, Vol 4, Issue 38 Send dhcwg mailing list submissions to dhcwg@ietf.org To subscribe or unsubscribe via the World Wide Web, visit https://www1.ietf.org/mailman/listinfo/dhcwg or, via email, send a message with subject or body 'help' to dhcwg-request@ietf.org You can reach the person managing the list at dhcwg-owner@ietf.org When replying, please edit your Subject line so it is more specific than "Re: Contents of dhcwg digest..." Today's Topics: 1. Re: Attempt at text for draft-ietf-dhc-lifetime-02 (Joe Quanaim) 2. Re: behavior on lifetime expiration (Re: comments ondraft-ietf-dhc-lifetime-01.txt) (Joe Quanaim) 3. dhcp6 verndor class option (Keshava) ---------------------------------------------------------------------- Message: 1 Date: Fri, 27 Aug 2004 08:54:09 -0400 From: Joe Quanaim Subject: Re: [dhcwg] Attempt at text for draft-ietf-dhc-lifetime-02 To: Stig Venaas , dhcwg@ietf.org Message-ID: <200408270854.10485.jdq@lucent.com> Content-Type: text/plain; charset="iso-8859-1" Stig Venaas wrote: > | A client MUST also use the default refresh time IRT_DEFAULT if it > | receives the option with value less than 600. > > Do you agree with a minimum like this? It should make it harder to > do bad things, and I don't see a use for <10 minutes. If <600, > would you rather use 600 than IRT_DEFAULT? I think a minimum is a good idea, but it probably should not be reset to 24 hours. That's probably not what an admin intended by setting the value that low. Also, are 0 or 0xffffffff a special case like elsewhere in dhcpv6? I am not sure it's necessary; I am just bringing up the point. Thanks, Joe Quanaim. ------------------------------ Message: 2 Date: Fri, 27 Aug 2004 09:29:46 -0400 From: Joe Quanaim Subject: Re: [dhcwg] behavior on lifetime expiration (Re: comments ondraft-ietf-dhc-lifetime-01.txt) To: Robert Elz , Stig Venaas Cc: dhcwg@ietf.org Message-ID: <200408270928.58762.jdq@lucent.com> Content-Type: text/plain; charset="iso-8859-1" Robert Elz wrote: > Date: Fri, 27 Aug 2004 08:23:21 +0200 > From: Stig Venaas > Message-ID: <20040827062321.GA15052@sverresborg.uninett.no> > > | I'm not sure if the answer to these issues need to be described in > | the draft since it's a more generic issue. OTOH this draft might be > | the most obvious place we have for now. > > Yes, it is a much bigger issue than just providing a mechanism for > specifying when a new info request should be attempted. > > But it is when we specify that that the problem becomes obvious, and > we need to have a solution - until now (including in IPv4) we mostly > just pretended that none of this ever happened, and once learned, all > of this information was static forever (hence, DNS "servers" (back end > resolvers really) go in /etc/resolv.conf - that gets updated when the > info changes, but applications know nothing of that, and simply keep on > using the old information forever). > > All this is something of a quagmire - but is something that needs to be > addressed, and ought to be addressed along with this new option (if not > necessarily in the same document). I agree that this is an issue, but I don't think it's something this document should address. It's a larger part of the dhcp specification, and the example you gave could happen in stateful configuration as well. For the example involving dns and this option, I read the draft as such: when the option expires, don't dismiss the configured dns data. Request new information. When new information is received, replace the existing data with the newly obtained. This prevents the client from being left without dns while making an attempt to be current. Also, if a server returns an empty set of dns servers, that is what the client should use. It doesn't make much sense, but misconfigured dhcp servers aren't something a client should be programmed to handle. Generalizing this issue is not simple. How does a dhcp client update the ntp configuration? And why does it? The ntp configuration could be pointing to a server reachable from multiple networks. This seems like local policy. Joe Quanaim. ------------------------------ Message: 3 Date: Fri, 27 Aug 2004 19:39:52 +0530 From: Keshava Subject: [dhcwg] dhcp6 verndor class option To: dhcwg@ietf.org, ipv6@ietf.org Cc: keshavaak@huawei.com, maoshx@huawei.com Message-ID: <001f01c48c3f$86a44f80$1604120a@keshavaak> Content-Type: text/plain; charset="iso-8859-1" Hi, Can you please clarify in he RFC 3315 (DHCP6) "Appearance of Options in Message Types" section mentions that the dhcp6 relay should support vendor class option. But in the message processing in the "Section 22.16 Vendor Class Option" does not mention any thing about this for relay . It only mentions about how the client should process this. Can some one please clarify this what should be done for dhcp6 relay ? regards, keshava -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www1.ietf.org/pipermail/dhcwg/attachments/20040827/5cb1a8a8/attachmen t.htm ------------------------------ _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg End of dhcwg Digest, Vol 4, Issue 38 ************************************ _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Sun Aug 29 06:37:08 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28929; Sun, 29 Aug 2004 06:37:08 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C1N0Q-0004pJ-UJ; Sun, 29 Aug 2004 06:33:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C1MmZ-0003TP-JZ for dhcwg@megatron.ietf.org; Sun, 29 Aug 2004 06:19:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28468 for ; Sun, 29 Aug 2004 06:19:27 -0400 (EDT) Received: from smtp1.agni.com ([202.53.160.4] helo=mx.agni.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C1Mo4-0007up-5J for dhcwg@ietf.org; Sun, 29 Aug 2004 06:21:06 -0400 Received: from inspbg.com ([202.53.160.107] helo=server.inspbg) by mx.agni.com with esmtp (Exim 4.12) id 1C1Mlh-0002vL-00 for dhcwg@ietf.org; Sun, 29 Aug 2004 16:18:37 +0600 Received: by SERVER with Internet Mail Service (5.5.2448.0) id ; Sun, 29 Aug 2004 14:57:04 +0600 Message-ID: From: "Dhaka . Razzak" To: "'dhcwg@ietf.org'" Date: Sun, 29 Aug 2004 14:57:03 +0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain X-MailScanner-Information: Scanned by agni's email virus scanner at smtp1 X-MailScanner: Clean X-MailScanner-SpamCheck: not spam, SpamAssassin (score=-4.9, required 6, BAYES_00 -4.90) X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Subject: [dhcwg] Help about MS Exchange Server 5.5 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Dear All, OS: NT-4.0 with SP6 MS Exchange Server 5.5 Problem : Server inspbg.com is configured to dialup automatically every 45 minutes and if the domain storage place there is no mail then it will be disconnected after 10 minutes. But now a days it is not working properly. My ISP provider told everything is ok at their end But I need to knock everyday over phone to force the mail to my server. Can anybody help me to find out the problem. Best regards, Razzak Razzak@inspbg.com , administrator@inspbg.com _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Aug 31 07:35:01 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08892; Tue, 31 Aug 2004 07:35:01 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C26n6-0004Jo-PQ; Tue, 31 Aug 2004 07:27:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C26iO-0002wJ-Fb for dhcwg@megatron.ietf.org; Tue, 31 Aug 2004 07:22:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07785 for ; Tue, 31 Aug 2004 07:22:15 -0400 (EDT) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C26kL-0000Kx-JF for dhcwg@ietf.org; Tue, 31 Aug 2004 07:24:18 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 31 Aug 2004 07:34:00 -0400 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i7VBLgUu022392 for ; Tue, 31 Aug 2004 07:21:43 -0400 (EDT) Received: from rdroms-w2k01.cisco.com (che-vpn-cluster-2-182.cisco.com [10.86.242.182]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id ALE99237; Tue, 31 Aug 2004 07:21:41 -0400 (EDT) Message-Id: <4.3.2.7.2.20040831070538.02d62fa8@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 31 Aug 2004 07:21:38 -0400 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Subject: [dhcwg] Revisions to draft-ietf-dhc-agentopt-radius X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org In response to comments received during the IESG review of draft-ietf-dhc-agentopt-radius, we have published draft-ietf-dhc-agentopt-radius-08.txt. The most important change in this revision is the specification of the IP-Framed-Pool RADIUS attribute in replacement of the Class RADIUS attribute. This change was made because the Class attribute is used for other purposes in some RADIUS deployments and servers, and because the Framed-Pool can be used to carry the name of a policy that should be applied to the DHCP client authenticated by the RADIUS protocol exchange. Here is a summary of the other differences between the -07 and -08 revisions of the specification: A paragraph was added to the end of section 1, Introduction, to clarify the applicability of the RADIUS Attributes Sub-option: The scope of applicability of this specification is such that robust interoperability is only guaranteed for RADIUS service implementations that exist within the same scope as the DHCP service implementation, i.e. within a single, localized administrative domain. Global interoperability of this specification, across administrative domains, is not required. A paragraph was added to section 2, Terminology, and the section "RADIUS Server Behavior" was removed to clarify that the RADIUS Attributes Sub-option does not affect any specification of the behavior of RADIUS servers.: The use of the standard keywords MUST, SHOULD, MUST NOT and SHOULD NOT within this specification are with respect to RADIUS clients and servers that implement the optional features of this specification, do not create any normative requirements outside of that scope and do not modify the base RADIUS specifications, such as RFC2865 or RFC2866. - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Aug 31 08:21:25 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11981; Tue, 31 Aug 2004 08:21:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C27X8-0003Jd-Mq; Tue, 31 Aug 2004 08:14:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C27OR-0002JU-W5 for dhcwg@megatron.ietf.org; Tue, 31 Aug 2004 08:05:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10969 for ; Tue, 31 Aug 2004 08:05:42 -0400 (EDT) Received: from tyholt.uninett.no ([158.38.60.10]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C27QN-0001WK-16 for dhcwg@ietf.org; Tue, 31 Aug 2004 08:07:46 -0400 Received: from sverresborg.uninett.no (sverresborg.uninett.no [IPv6:2001:700:e000:0:204:75ff:fee4:423b]) by tyholt.uninett.no (8.12.10/8.12.10) with ESMTP id i7VC2BOK019187; Tue, 31 Aug 2004 14:02:11 +0200 Received: (from venaas@localhost) by sverresborg.uninett.no (8.12.8/8.12.8/Submit) id i7VC282q012340; Tue, 31 Aug 2004 14:02:08 +0200 X-Authentication-Warning: sverresborg.uninett.no: venaas set sender to Stig.Venaas@uninett.no using -f Date: Tue, 31 Aug 2004 14:02:08 +0200 From: Stig Venaas To: Robert Elz Subject: Re: [dhcwg] comments on draft-ietf-dhc-lifetime-01.txt Message-ID: <20040831120208.GM2203@sverresborg.uninett.no> References: <000e01c486b3$66af02b0$6401a8c0@amer.cisco.com> <6493.1093586912@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6493.1093586912@munnari.OZ.AU> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: dhcwg@ietf.org, tjc@ecs.soton.ac.uk, Bernie Volz , jdq@lucent.com X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org On Fri, Aug 27, 2004 at 01:08:32PM +0700, Robert Elz wrote: > Date: Fri, 20 Aug 2004 08:44:14 -0400 > From: "Bernie Volz" > Message-ID: <000e01c486b3$66af02b0$6401a8c0@amer.cisco.com> > > | I'm OK to restricting the Lifetime Option to replies to > | Information-Request's. > | > | The client MUST ignore a Lifetime Option that is in any message other than a > | REPLY to an INFORMATION-REQUEST. A client MUST NOT include the Lifetime > | Option number in an ORO except when sending an INFORMATION-REQUEST message. > | > | The server MUST NOT include the Lifetime Option in any message other than a > | REPLY to an INFORMATION-REQUEST. > > I've been reading all of the messages on this topic (catching up) and I > haven't managed to find a reason why anyone would want to add this kind > of restriction, I just don't see the need. > > You seem to all be imagining that things have to get much more complex > for the clients if they get two timer values, and they're different. > But that's nonsense. I pretty much agree with what you say. The reason the option isn't needed when you have leases, is of course that you can set the lease time short, just to ensure that client update other config. I agree that it could still be useful though. I don't know what people think, I have no strong feelings myself, but we could relax things a bit perhaps. But there is some added complexity and it isn't essential. It could also be extended later if necessary. We could tweak the spec to allow what you say, if there's agreement on that. But most of all, I want to come to some conclusion really soon. I posted a mail with subject "Attempt at text for draft-ietf-dhc-lifetime-02" where I tried to write text that most so far seems to agree with. Most of it is based on inputs from discussions on mailing list. Bernie gave some comments that I plan to include. I did not say any about what should happen if some config data is removed from one client update to the next. Do you really want that in? I'm not sure I do, since as also some others agreed to, it's a more generic problem. If I were to write text, I would say that it should indeed be removed. Stig _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Aug 31 08:26:23 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12220; Tue, 31 Aug 2004 08:26:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C27ee-0004Dw-CU; Tue, 31 Aug 2004 08:22:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C27Xp-0003Na-W1 for dhcwg@megatron.ietf.org; Tue, 31 Aug 2004 08:15:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11742 for ; Tue, 31 Aug 2004 08:15:25 -0400 (EDT) Received: from tyholt.uninett.no ([158.38.60.10]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C27Zn-0001is-EE for dhcwg@ietf.org; Tue, 31 Aug 2004 08:17:28 -0400 Received: from sverresborg.uninett.no (sverresborg.uninett.no [IPv6:2001:700:e000:0:204:75ff:fee4:423b]) by tyholt.uninett.no (8.12.10/8.12.10) with ESMTP id i7VCE3OK022210; Tue, 31 Aug 2004 14:14:03 +0200 Received: (from venaas@localhost) by sverresborg.uninett.no (8.12.8/8.12.8/Submit) id i7VCE14Z012362; Tue, 31 Aug 2004 14:14:01 +0200 X-Authentication-Warning: sverresborg.uninett.no: venaas set sender to Stig.Venaas@uninett.no using -f Date: Tue, 31 Aug 2004 14:14:01 +0200 From: Stig Venaas To: Joe Quanaim Subject: Re: [dhcwg] Attempt at text for draft-ietf-dhc-lifetime-02 Message-ID: <20040831121401.GN2203@sverresborg.uninett.no> References: <20040825151559.GJ5677@sverresborg.uninett.no> <200408270854.10485.jdq@lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200408270854.10485.jdq@lucent.com> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: dhcwg@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org On Fri, Aug 27, 2004 at 08:54:09AM -0400, Joe Quanaim wrote: > > Stig Venaas wrote: > > | A client MUST also use the default refresh time IRT_DEFAULT if it > > | receives the option with value less than 600. > > > > Do you agree with a minimum like this? It should make it harder to > > do bad things, and I don't see a use for <10 minutes. If <600, > > would you rather use 600 than IRT_DEFAULT? > > I think a minimum is a good idea, but it probably should not be reset to 24 > hours. That's probably not what an admin intended by setting the value that > low. I agree sort of. For the protocol, I like the idea of totally ignoring option with invalid value though, which means using the default. The server implementation should perhaps give the administrator a warning, or send 600 rather than the configured value. We could also do what you suggest though. Other opinions? > Also, are 0 or 0xffffffff a special case like elsewhere in dhcpv6? I am not > sure it's necessary; I am just bringing up the point. I think it infinity could potentially be useful, but 0xffffffff is in practice infinity anyway. If we leave it out now, we can still add it later if we want. Stig _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Aug 31 12:50:00 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04191; Tue, 31 Aug 2004 12:50:00 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2BaP-0001Ql-KJ; Tue, 31 Aug 2004 12:34:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2B51-0004Bp-Sh for dhcwg@megatron.ietf.org; Tue, 31 Aug 2004 12:01:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28021 for ; Tue, 31 Aug 2004 12:01:53 -0400 (EDT) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C2B70-0006jK-VG for dhcwg@ietf.org; Tue, 31 Aug 2004 12:04:00 -0400 Received: from ocean.jinmei.org (unknown [2001:200:0:8002:7516:52ec:cfc0:15e1]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 2911D1525D; Wed, 1 Sep 2004 01:01:52 +0900 (JST) Date: Wed, 01 Sep 2004 01:01:51 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Ted Lemon Subject: Re: [dhcwg] behavior on lifetime expiration (Re: comments on draft-ietf-dhc-lifetime-01.txt) In-Reply-To: <6C20AA0D-F5DF-11D8-8541-000A95D9C74C@nominum.com> References: <20040803033357.GA20506@sverresborg.uninett.no> <6C20AA0D-F5DF-11D8-8541-000A95D9C74C@nominum.com> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: dhcwg@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org >>>>> On Tue, 24 Aug 2004 11:08:14 -0400, >>>>> Ted Lemon said: > However, let's consider your scenario a little more closely. You > acquire some information from the DHCP server. Subsequently, for some > reason, it becomes impossible for the server to respond to the client. > I have a couple of observations about this. First, the time at which > it becomes impossible for the server to respond is not the same as the > time at which the client attempts to refresh its configuration > information. The two events are unrelated. Okay, I concur on this. I also see that the scenario might differ based on whether the client moves to a new link or it stays in the same link. Instead of making further responses point by point, I'll try to summarize major points throughout the thread, and propose what I personally would envision based on the points (if you feel this approach is unfair, please say so). I'll also call the new option "refresh timer option" in the followings since that's the closest notion which we now seem to agree on. The case of moving clients is probably too difficult to provide a complete solution, but it would be helpful some considerations along with the this new option. Now assuming a still client (i.e., a client that doesn't move), we seem to be close to the consensus. - when the refresh timer expires, the client resends a new Information-request message. (it can do so earlier than the expiration time based on its local policy) - if the client gets a response, it (MUST) replace the old information with the new one. This also means if the response contains an empty set of some particular information, the client should stop using the old information. (BTW, there are two types of an "empty set". The first one is a response that contains the corresponding DHCPv6 option, e.g., DNS recursive name server option, with an empty list. The second one is a response that doesn't contain the DHCPv6 option. It seems to me it makes sense to regard both types as "an empty set"). - if the client cannot get a response, it (SHOULD?) continue using the old information because of the reason Ted provided. So, what I would expect in this document is as follows: - we basically concentrate on the case of a still client and explicitly say so in the document. - then we describe the detailed behavior for that type of clients as shown above (of course, based on a consensus in the wg). - we also provide some considerations on moving clients (in an appendix?), which would be something like this: + we assume we can detect the movement (or simply say it's beyond the scope of this work). I think we can simply refer to the beginning of Section 18.1.2 of RFC3315 if necessary. + when the client detects the movement, it should start contacting the DHCP server immediately, regardless of the remaining time of the refresh timer. In this case, how the client deals with the old information is up to the client based on its local policy (there can be so many valid scenarios as we've seen in the discussion). This should particularly apply when the client receives an "empty set" for some information or when the client cannot get any responses at all. However, if the client gets a non empty set of new information, it SHOULD(?) replace the old information with the new one. 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-bounces@ietf.org Tue Aug 31 12:56:03 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04649; Tue, 31 Aug 2004 12:56:03 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2BaZ-0001f1-UP; Tue, 31 Aug 2004 12:34:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2B9N-0007fL-EI for dhcwg@megatron.ietf.org; Tue, 31 Aug 2004 12:06:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28464 for ; Tue, 31 Aug 2004 12:06:23 -0400 (EDT) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C2BBL-0006uZ-Mz for dhcwg@ietf.org; Tue, 31 Aug 2004 12:08:30 -0400 Received: from ocean.jinmei.org (unknown [2001:200:0:8002:7516:52ec:cfc0:15e1]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 59CCC1525D; Wed, 1 Sep 2004 01:06:21 +0900 (JST) Date: Wed, 01 Sep 2004 01:06:20 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: "Bernie Volz" Subject: Re: [dhcwg] behavior on lifetime expiration (Re: commentson draft-ietf-dhc-lifetime-01.txt) In-Reply-To: <001601c48a40$8a411e80$6401a8c0@amer.cisco.com> References: <001601c48a40$8a411e80$6401a8c0@amer.cisco.com> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: dhcwg@ietf.org, "'Ted Lemon'" X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org >>>>> On Tue, 24 Aug 2004 21:12:07 -0400, >>>>> "Bernie Volz" said: > You'd prefer IPv4 based information over IPv6? No, in that example, I assumed a dual-stack host. > And DHCPv4, if Inform was used, doesn't have *ANY* time to expire the > information - so I don't think you'd want to use this information in > preference to DHCPv6 information with a time? I think I would, since in this case I'd regard the "expired" DHCPv6 information as less reliable than DHCPv4 information without any expiration time. But I won't stick to this point any more as I (perhaps implicitly) said in my response to Ted. Let's just throw away this mostly-imaginary scenario. 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-bounces@ietf.org Tue Aug 31 13:06:32 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05441; Tue, 31 Aug 2004 13:06:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2Bo8-0007NQ-Nx; Tue, 31 Aug 2004 12:48:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2Ba0-0001Kh-A7 for dhcwg@megatron.ietf.org; Tue, 31 Aug 2004 12:33:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01556 for ; Tue, 31 Aug 2004 12:33:53 -0400 (EDT) Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C2Bc0-0007vF-5m for dhcwg@ietf.org; Tue, 31 Aug 2004 12:36:01 -0400 Received: from [10.0.2.8] (neubayern.net [66.93.162.100]) by toccata.fugue.com (Postfix) with ESMTP id 352F01B2273 for ; Tue, 31 Aug 2004 11:32:17 -0500 (CDT) Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: <20040831120208.GM2203@sverresborg.uninett.no> References: <000e01c486b3$66af02b0$6401a8c0@amer.cisco.com> <6493.1093586912@munnari.OZ.AU> <20040831120208.GM2203@sverresborg.uninett.no> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <8789608F-FB6B-11D8-8C0B-000D93C4B69A@fugue.com> Content-Transfer-Encoding: 7bit From: Ted Lemon Subject: Re: [dhcwg] comments on draft-ietf-dhc-lifetime-01.txt Date: Tue, 31 Aug 2004 09:33:46 -0700 To: dhcwg@ietf.org X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7bit X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 7bit On Aug 31, 2004, at 5:02 AM, Stig Venaas wrote: > I don't know what people think, I have no strong feelings myself, but > we could relax things a bit perhaps. But there is some added complexity > and it isn't essential. It could also be extended later if necessary. > > We could tweak the spec to allow what you say, if there's agreement on > that. But most of all, I want to come to some conclusion really soon. I think using the IRT option in a context where there is a lifetime already doesn't make sense, and should not be allowed. I don't mean the client should drop the packet if it gets both - just that the option has no meaning in the context of a stateful DHCP message. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Aug 31 13:07:23 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05603; Tue, 31 Aug 2004 13:07:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2BzV-00024l-Fz; Tue, 31 Aug 2004 13:00:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2Bd7-0003UM-Hp for dhcwg@megatron.ietf.org; Tue, 31 Aug 2004 12:37:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02154 for ; Tue, 31 Aug 2004 12:37:07 -0400 (EDT) Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C2Bf5-00086W-EE for dhcwg@ietf.org; Tue, 31 Aug 2004 12:39:14 -0400 Received: from [10.0.2.8] (neubayern.net [66.93.162.100]) by toccata.fugue.com (Postfix) with ESMTP id D48201B22C8 for ; Tue, 31 Aug 2004 11:35:28 -0500 (CDT) Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: <20040831120208.GM2203@sverresborg.uninett.no> References: <000e01c486b3$66af02b0$6401a8c0@amer.cisco.com> <6493.1093586912@munnari.OZ.AU> <20040831120208.GM2203@sverresborg.uninett.no> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Ted Lemon Subject: Re: [dhcwg] dhc-lifetime-01: dropping omitted options Date: Tue, 31 Aug 2004 09:36:58 -0700 To: dhcwg@ietf.org X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7bit X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 7bit On Aug 31, 2004, at 5:02 AM, Stig Venaas wrote: > I did not say any about what should happen if some config data is > removed from one client update to the next. Do you really want that > in? I'm not sure I do, since as also some others agreed to, it's a > more generic problem. If I were to write text, I would say that it > should indeed be removed. I think we need to collect some experience on this, and that we should update the RFC later when we have more information. For now, we should not say what to do. I can easily think of a byzantine set of specifications for how to do this, but I'm not sure they're either necessary or correct. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Aug 31 13:17:16 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06441; Tue, 31 Aug 2004 13:17:15 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2C0w-0002Wc-2N; Tue, 31 Aug 2004 13:01:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2Blr-0006gn-QX for dhcwg@megatron.ietf.org; Tue, 31 Aug 2004 12:46:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03778 for ; Tue, 31 Aug 2004 12:46:09 -0400 (EDT) Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C2Bns-00008A-Lm for dhcwg@ietf.org; Tue, 31 Aug 2004 12:48:17 -0400 Received: from [10.0.2.8] (neubayern.net [66.93.162.100]) by toccata.fugue.com (Postfix) with ESMTP id B443A1B22C5 for ; Tue, 31 Aug 2004 11:44:38 -0500 (CDT) Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: <20040831121401.GN2203@sverresborg.uninett.no> References: <20040825151559.GJ5677@sverresborg.uninett.no> <200408270854.10485.jdq@lucent.com> <20040831121401.GN2203@sverresborg.uninett.no> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <419E9784-FB6D-11D8-8C0B-000D93C4B69A@fugue.com> Content-Transfer-Encoding: 7bit From: Ted Lemon Subject: Re: [dhcwg] dhc-lifetime-02: minimum value Date: Tue, 31 Aug 2004 09:46:07 -0700 To: dhcwg@ietf.org X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7bit X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 7bit On Aug 31, 2004, at 5:14 AM, Stig Venaas wrote: > I agree sort of. For the protocol, I like the idea of totally ignoring > option with invalid value though, which means using the default. The > server implementation should perhaps give the administrator a warning, > or send 600 rather than the configured value. > > We could also do what you suggest though. Other opinions? There are cases where if any low value for this option is sent out over and over again by the server, it will cause operational problems. But this isn't something we can easily prevent without being too restrictive, and I think you have to be really well-placed on a network (i.e., on the DHCP server's network) to get much amplification out of a DoS attack based on this. In fact, when I think of how to come up with such a DoS attack, it seems like it would actually be very difficult. So I think the real risk here is that the server administrator will configure a too-low value, so I think the right way to address this is to say that servers SHOULD warn the server administrator through an appropriate mechanism if the administrator tries to configure a too-low value for this option. I think if you try to specify this on the protocol level, you're just making needless trouble for yourself, and not getting any benefit from it. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Aug 31 13:22:39 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07009; Tue, 31 Aug 2004 13:22:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2C1v-0002c7-AD; Tue, 31 Aug 2004 13:02:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2Bnt-0007DC-SQ for dhcwg@megatron.ietf.org; Tue, 31 Aug 2004 12:48:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04056 for ; Tue, 31 Aug 2004 12:48:15 -0400 (EDT) Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C2Bpt-0000EK-TW for dhcwg@ietf.org; Tue, 31 Aug 2004 12:50:23 -0400 Received: from [10.0.2.8] (neubayern.net [66.93.162.100]) by toccata.fugue.com (Postfix) with ESMTP id B60A81B242B for ; Tue, 31 Aug 2004 11:46:43 -0500 (CDT) Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: References: <20040803033357.GA20506@sverresborg.uninett.no> <6C20AA0D-F5DF-11D8-8541-000A95D9C74C@nominum.com> Content-Type: text/plain; charset=ISO-2022-JP; format=flowed Message-Id: <8C0D764C-FB6D-11D8-8C0B-000D93C4B69A@nominum.com> Content-Transfer-Encoding: 7bit From: Ted Lemon Subject: Re: [dhcwg] behavior on lifetime expiration (Re: comments on draft-ietf-dhc-lifetime-01.txt) Date: Tue, 31 Aug 2004 09:48:12 -0700 To: dhcwg@ietf.org X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d62ab47271805379d7172ee693a45db Content-Transfer-Encoding: 7bit X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 7bit On Aug 31, 2004, at 9:01 AM, JINMEI Tatuya / $B?@L@C#:H(B wrote: > So, what I would expect in this document is as follows: What you've proposed sounds good to me! _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Aug 31 21:39:20 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22046; Tue, 31 Aug 2004 21:39:20 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2Jyn-0007dv-NN; Tue, 31 Aug 2004 21:32:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2JuI-0006mC-ER for dhcwg@megatron.ietf.org; Tue, 31 Aug 2004 21:27:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21413 for ; Tue, 31 Aug 2004 21:27:25 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C2JwN-00056n-4o for dhcwg@ietf.org; Tue, 31 Aug 2004 21:29:36 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 31 Aug 2004 21:26:53 -0400 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i811QpUu020159; Tue, 31 Aug 2004 21:26:51 -0400 (EDT) Received: from volzw2k (che-vpn-cluster-2-207.cisco.com [10.86.242.207]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id ALF64703; Tue, 31 Aug 2004 21:26:49 -0400 (EDT) From: "Bernie Volz" To: "'Stig Venaas'" , "'Joe Quanaim'" Subject: RE: [dhcwg] Attempt at text for draft-ietf-dhc-lifetime-02 Date: Tue, 31 Aug 2004 21:26:50 -0400 Organization: Cisco Message-ID: <000001c48fc2$c1a09310$6401a8c0@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.5709 In-Reply-To: <20040831121401.GN2203@sverresborg.uninett.no> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4939.300 X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 7bit Stig: I agree with Ted (in response to your message) that the server SHOULD warn if the time is below the minimum. I don't agree with you that the client should just ignore the option if the value is below the minimum - it should use the minimum. I'd follow the convention used in RFC 3315 to declare 0xffffffff as infinity. 0 isn't special - though as it is below the minimum, the minimum would be used. - Bernie > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] > On Behalf Of Stig Venaas > Sent: Tuesday, August 31, 2004 8:14 AM > To: Joe Quanaim > Cc: dhcwg@ietf.org > Subject: Re: [dhcwg] Attempt at text for draft-ietf-dhc-lifetime-02 > > > On Fri, Aug 27, 2004 at 08:54:09AM -0400, Joe Quanaim wrote: > > > > Stig Venaas wrote: > > > | A client MUST also use the default refresh time > IRT_DEFAULT if it > > > | receives the option with value less than 600. > > > > > > Do you agree with a minimum like this? It should make it > harder to > > > do bad things, and I don't see a use for <10 minutes. If > <600, would > > > you rather use 600 than IRT_DEFAULT? > > > > I think a minimum is a good idea, but it probably should > not be reset > > to 24 > > hours. That's probably not what an admin intended by > setting the value that > > low. > > I agree sort of. For the protocol, I like the idea of totally > ignoring option with invalid value though, which means using > the default. The server implementation should perhaps give > the administrator a warning, or send 600 rather than the > configured value. > > We could also do what you suggest though. Other opinions? > > > Also, are 0 or 0xffffffff a special case like elsewhere in > dhcpv6? I > > am not > > sure it's necessary; I am just bringing up the point. > > I think it infinity could potentially be useful, but > 0xffffffff is in practice infinity anyway. > > If we leave it out now, we can still add it later if we want. > > Stig > > _______________________________________________ > 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-bounces@ietf.org Tue Aug 31 22:00:44 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA23257; Tue, 31 Aug 2004 22:00:44 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2KA8-0001lt-LL; Tue, 31 Aug 2004 21:43:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2K5h-0000dv-8I; Tue, 31 Aug 2004 21:39:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22035; Tue, 31 Aug 2004 21:39:11 -0400 (EDT) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C2K7m-0005HL-33; Tue, 31 Aug 2004 21:41:23 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-5.cisco.com with ESMTP; 31 Aug 2004 18:32:18 -0700 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i811Vqb7004788; Tue, 31 Aug 2004 18:31:53 -0700 (PDT) Received: from volzw2k (che-vpn-cluster-2-207.cisco.com [10.86.242.207]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id ALF64861; Tue, 31 Aug 2004 21:31:51 -0400 (EDT) From: "Bernie Volz" To: "'Keshava'" , , Subject: RE: [dhcwg] dhcp6 verndor class option Date: Tue, 31 Aug 2004 21:31:50 -0400 Organization: Cisco Message-ID: <000101c48fc3$748d79c0$6401a8c0@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.5709 In-Reply-To: <001f01c48c3f$86a44f80$1604120a@keshavaak> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4939.300 X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: quoted-printable Cc: maoshx@huawei.com X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: quoted-printable If there's relay specific information that could be used by a server (or other relay), there is no reason the relay can't include this in its Relay-Forw message (and the server return information in the = Relay-Reply). Note that Appendix A, Appearance of Options in Message Types, indicates = that these are valid: Status Rap. User Vendor Vendor Inter. Recon. Recon. Code Comm. Class Class Spec. ID Msg. Accept R-forw. * * * * R-repl. * * * * - Bernie -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf = Of Keshava Sent: Friday, August 27, 2004 10:10 AM To: dhcwg@ietf.org; ipv6@ietf.org Cc: keshavaak@huawei.com; maoshx@huawei.com Subject: [dhcwg] dhcp6 verndor class option Hi, Can you please clarify in he RFC 3315 (DHCP6)=20 "Appearance of Options in Message Types" section mentions that the = dhcp6 relay should support=20 vendor class option. =20 But in the message processing in the "Section 22.16 Vendor Class = Option" does not mention any=20 thing about this for relay . It only mentions about how the client should process this. Can some one please clarify this what should be done for dhcp6 = relay ? regards, keshava _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg