From mailman-bounces@ietf.org Thu Jul 1 08:08: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 IAA18375 for ; Thu, 1 Jul 2004 08:08: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 1Bfxod-0008Om-05 for dhc-archive@lists.ietf.org; Thu, 01 Jul 2004 05:25:11 -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: Thu, 01 Jul 2004 05:06:45 -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 Thu Jul 1 12: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 MAA13813; Thu, 1 Jul 2004 12: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 1Bg3oS-0007kh-DL; Thu, 01 Jul 2004 11:49:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bg37r-0004sO-6d for dhcwg@megatron.ietf.org; Thu, 01 Jul 2004 11:05:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08000 for ; Thu, 1 Jul 2004 11:05:21 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bg37q-00001l-7q for dhcwg@ietf.org; Thu, 01 Jul 2004 11:05:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bg36t-0007Rv-00 for dhcwg@ietf.org; Thu, 01 Jul 2004 11:04:23 -0400 Received: from zrtps06s.nortelnetworks.com ([47.140.48.50]) by ietf-mx with esmtp (Exim 4.12) id 1Bg35v-0006hQ-00 for dhcwg@ietf.org; Thu, 01 Jul 2004 11:03:23 -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 i61F1l206891; Thu, 1 Jul 2004 11:01:47 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 1 Jul 2004 11:01:48 -0400 Message-ID: <591B780D9676844E8A704B5B013FFE92017BBC57@zrc2hxm1.corp.nortel.com> From: "Kuntal Chowdhury" To: dhcwg@ietf.org Date: Thu, 1 Jul 2004 11:01:36 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Cc: "'Parviz Yegani \(pyegani@cisco.com\)'" , "Lila Madour \(QA/EMC\)" Subject: [dhcwg] new ID submitted 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, We submitted a draft defining Broadcast and Multicast Service Controller IPv6 address and domain name options. The draft is available at: http://www.ietf.org/internet-drafts/draft-chowdhury-dhc-bcmcv6-option-00.txt The abstract is as follows: Abstract This document defines new options for Broadcast and Multicast Service controller discovery in an IP network. Broadcast and Multicast service over 3G wireless networks are being developed at the time of writing this document. Users of this service interact with a controller in the network to derive informations that are required to receive broadcast service. Dynamic Host Configuration Protocol can be used to configure the controller IPv6 addresses in the user's devices. This document defines the related options and option codes. We appreciate your review and comment on the proposed options. Regards, Kuntal _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri Jul 2 01:28:19 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 BAA23247; Fri, 2 Jul 2004 01:28: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 1BgGWG-0002Jh-Lx; Fri, 02 Jul 2004 01:23:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BgGPt-0008I7-IG for dhcwg@megatron.ietf.org; Fri, 02 Jul 2004 01:16:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22935 for ; Fri, 2 Jul 2004 01:16:52 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BgGPr-0006DD-9k for dhcwg@ietf.org; Fri, 02 Jul 2004 01:16:51 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BgGOs-0005ss-00 for dhcwg@ietf.org; Fri, 02 Jul 2004 01:15:51 -0400 Received: from zmamail05.zma.compaq.com ([161.114.64.105]) by ietf-mx with esmtp (Exim 4.12) id 1BgGNp-0005H3-00 for dhcwg@ietf.org; Fri, 02 Jul 2004 01:14:45 -0400 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 75C5F6A4B; Fri, 2 Jul 2004 01:14:43 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0); Fri, 2 Jul 2004 01:14:43 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 2 Jul 2004 01:14:44 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B067CCDE4@tayexc13.americas.cpqcorp.net> Thread-Topic: WG Action: RECHARTER: Dynamic Host Configuration (dhc) Thread-Index: AcRfgBtivC3wvBiPSEOhhs+Gnn3FRwAcuZOw From: "Bound, Jim" To: X-OriginalArrivalTime: 02 Jul 2004 05:14:43.0387 (UTC) FILETIME=[7BEA70B0:01C45FF3] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Cc: Ralph Droms Subject: [dhcwg] RE: WG Action: RECHARTER: Dynamic Host Configuration (dhc) 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 =20 > * Assess the requirements for a dual-stack host to use DHCP=20 > to obtain configuration settings for both IPv4 and IPv6.=20 > Hosts that include implementations of both IPv4 and IPv6=20 > ("dual-stack hosts") may use DHCP to obtain configuration=20 > settings (including assigned addresses) for both IPv4 and=20 > IPv6. The DHCPv4 and DHCPv6 specifications (RFC 2131, RFC=20 > 2132, RFC 3315 and subsequent RFCs) do not explicitly explain=20 > how a dual-stack host uses DHCP to obtain configuration=20 > settings for both IP stacks. The DHC WG will evaluate=20 > solutions for configuration of dual-stack hosts through DHCP=20 > and select a solution that will be developed and published by the WG. Could I get more clarity on exactly what this means above and objective? What problem is the paragraph trying to solve? It seems obvious to me? Fine with the rest of the charter. Only responding to WG. Thanks /jim _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri Jul 2 04:58: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 EAA17657; Fri, 2 Jul 2004 04:58: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 1BgJkm-0006J1-9w; Fri, 02 Jul 2004 04:50:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BgJbW-0003K0-KV for dhcwg@megatron.ietf.org; Fri, 02 Jul 2004 04:41:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA15336 for ; Fri, 2 Jul 2004 04:41:04 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BgJbU-0000YM-Db for dhcwg@ietf.org; Fri, 02 Jul 2004 04:41:04 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BgJaY-0000D0-00 for dhcwg@ietf.org; Fri, 02 Jul 2004 04:40:07 -0400 Received: from raven.ecs.soton.ac.uk ([152.78.70.1]) by ietf-mx with esmtp (Exim 4.12) id 1BgJZl-0007eT-00 for dhcwg@ietf.org; Fri, 02 Jul 2004 04:39:17 -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 i628dInG029879 for ; Fri, 2 Jul 2004 09:39:18 +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 JAA07482 for ; Fri, 2 Jul 2004 09:39:13 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id i628dDB22831 for dhcwg@ietf.org; Fri, 2 Jul 2004 09:39:13 +0100 Date: Fri, 2 Jul 2004 09:39:13 +0100 From: Tim Chown To: dhcwg@ietf.org Subject: Re: [dhcwg] RE: WG Action: RECHARTER: Dynamic Host Configuration (dhc) Message-ID: <20040702083913.GG21847@login.ecs.soton.ac.uk> Mail-Followup-To: dhcwg@ietf.org References: <9C422444DE99BC46B3AD3C6EAFC9711B067CCDE4@tayexc13.americas.cpqcorp.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B067CCDE4@tayexc13.americas.cpqcorp.net> 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-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 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 Jim, The work is encapsulated in: http://www.ietf.org/internet-drafts/draft-chown-dhc-dual-stack-00.txt Stig and I are preparing an update this week based on WG input posted a couple of months back. Christian is just chaning jobs so probably won't be active in this iteration. Any other input is welcome. Tim On Fri, Jul 02, 2004 at 01:14:44AM -0400, Bound, Jim wrote: > > > * Assess the requirements for a dual-stack host to use DHCP > > to obtain configuration settings for both IPv4 and IPv6. > > Hosts that include implementations of both IPv4 and IPv6 > > ("dual-stack hosts") may use DHCP to obtain configuration > > settings (including assigned addresses) for both IPv4 and > > IPv6. The DHCPv4 and DHCPv6 specifications (RFC 2131, RFC > > 2132, RFC 3315 and subsequent RFCs) do not explicitly explain > > how a dual-stack host uses DHCP to obtain configuration > > settings for both IP stacks. The DHC WG will evaluate > > solutions for configuration of dual-stack hosts through DHCP > > and select a solution that will be developed and published by the WG. > > Could I get more clarity on exactly what this means above and objective? > > What problem is the paragraph trying to solve? > > It seems obvious to me? > > Fine with the rest of the charter. > > Only responding to WG. > > Thanks > /jim > > _______________________________________________ > 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 Fri Jul 2 05: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 FAA20085; Fri, 2 Jul 2004 05: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 1BgK8H-0005qw-TG; Fri, 02 Jul 2004 05:14:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BgJvR-0002OI-DS for dhcwg@megatron.ietf.org; Fri, 02 Jul 2004 05:01:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18594 for ; Fri, 2 Jul 2004 05:01:38 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BgJvP-0006yK-52 for dhcwg@ietf.org; Fri, 02 Jul 2004 05:01:39 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BgJtt-0006SA-00 for dhcwg@ietf.org; Fri, 02 Jul 2004 05:00:06 -0400 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx with esmtp (Exim 4.12) id 1BgJqH-0005Bu-00 for dhcwg@ietf.org; Fri, 02 Jul 2004 04:56:21 -0400 Received: from [10.1.1.109] (marseille.netlab.nec.de [195.37.70.15]) by kyoto.netlab.nec.de (Postfix) with ESMTP id CD53A1BAC4D; Fri, 2 Jul 2004 10:55:49 +0200 (CEST) Date: Fri, 02 Jul 2004 10:55:30 +0200 From: Martin Stiemerling To: strates Subject: Re: [dhcwg] [Question]DHCPv6 implementations Message-ID: <1FB04E6CA48B65C25E1E4DC1@[10.1.1.109]> In-Reply-To: <1489.040621@mail.ru> References: <1489.040621@mail.ru> X-Mailer: Mulberry/3.1.5 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 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 Hi, NEC has an implementation that is complete and test against various different other implementations. Unfortunately it is not open source. The Linux one at sourceforge seem to be quite stable and useful. Hope that helps. Martin NEC Europe Ltd. -- Network Laboratories Stiemerling@netlab.nec.de PGP Key at: http://www.stiemerling.org/stiemerling_nec.gpg IPv4: http://www.ccrle.nec.de --On Montag, 21. Juni 2004 2:08 Uhr +0400 strates wrote: | I tried to learn what are nowdays available DHCPv6 client/server | implementations. | Using the search engines I could only find | - KAME implementation for *BSDs: stateless DHCPv6, and they are not going | to improve it | - Widespread linux-related http://dhcpv6.sourceforge.net implementation | - Some traces of proprietary CISCO IOS and NEC implementations | (http://www.dhcpv6.org/ with only relay agent available for public) | - USAGI implementation which leads to a project which claimed himself | 'dead'(http://www.linux-ipv6.org/links.html -> | http://www.hycomat.co.uk/dhcp/) | - Signs of some Linux implementation (there is some gentoo related | stuff, config files in google). | - DHCPv6 support in HP-UX | | It is quite strange for me, that only a few incomplete | implementations are present (yes, stateless IPv6 autoconfiguration | fulfils a lot of work instead of DHCPv6, and many people seem to be | satisfied with s-less autoconfiguration and router prefix | advertisement, but still...) | Later I found www.dfn.de/uploaded/DHCPv6.pdf and I understood that | it seems there are really only a few implementations. | Could anybody advertise anything in addition to the list above? | Thanks beforehand | | | | _______________________________________________ | 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 Fri Jul 2 11:11: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 LAA12434; Fri, 2 Jul 2004 11:11: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 1BgPM1-00030h-Hh; Fri, 02 Jul 2004 10:49:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BgPBE-0007w5-5t for dhcwg@megatron.ietf.org; Fri, 02 Jul 2004 10:38:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09309 for ; Fri, 2 Jul 2004 10:38:17 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BgPBD-0000Kw-Dz for dhcwg@ietf.org; Fri, 02 Jul 2004 10:38:19 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BgPAB-00000p-00 for dhcwg@ietf.org; Fri, 02 Jul 2004 10:37:16 -0400 Received: from e5.ny.us.ibm.com ([32.97.182.105]) by ietf-mx with esmtp (Exim 4.12) id 1BgP9G-0007D3-00 for dhcwg@ietf.org; Fri, 02 Jul 2004 10:36:18 -0400 Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e5.ny.us.ibm.com (8.12.10/8.12.2) with ESMTP id i62EZjDk453410; Fri, 2 Jul 2004 10:35:46 -0400 Received: from rotala.raleigh.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i62EaaV0018754; Fri, 2 Jul 2004 10:36:36 -0400 Received: from rotala.raleigh.ibm.com (localhost.localdomain [127.0.0.1]) by rotala.raleigh.ibm.com (8.12.8/8.12.5) with ESMTP id i62EaJc2022890; Fri, 2 Jul 2004 10:36:19 -0400 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.12.8/8.12.8/Submit) with ESMTP id i62EaIAk022886; Fri, 2 Jul 2004 10:36:19 -0400 Message-Id: <200407021436.i62EaIAk022886@rotala.raleigh.ibm.com> To: Stig Venaas Subject: Re: [dhcwg] Lifetime option (draft-ietf-dhc-lifetime-00.txt) In-Reply-To: Message from Stig.Venaas@uninett.no of "Tue, 29 Jun 2004 13:14:25 +0200." <20040629111425.GA14068@sverresborg.uninett.no> Date: Fri, 02 Jul 2004 10:36:18 -0400 From: Thomas Narten X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 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 Personally, I think that if one is trying to contact a DHC server, and none respond, there should be a generic algorithm used for retries. I.e., the case for this option should not be any different (for say) the case where one first boots, and no DHC server responds, or when one fails to renew an address after an address expires. I.e., isn't there already a generic retranmission with backoff and some upper limit? Why not just do the same? Is there a need for multiple different algorithms? Thomas _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Jul 6 09:58: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 JAA15437; Tue, 6 Jul 2004 09:58: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 1Bhpg2-0007tN-BJ; Tue, 06 Jul 2004 09:08:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BhpCd-0003Jz-TG for dhcwg@megatron.ietf.org; Tue, 06 Jul 2004 08:37:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10574 for ; Tue, 6 Jul 2004 08:37:33 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BhpCY-0006FI-3z for dhcwg@ietf.org; Tue, 06 Jul 2004 08:37:34 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BhpBd-0005un-00 for dhcwg@ietf.org; Tue, 06 Jul 2004 08:36:37 -0400 Received: from tama5.ecl.ntt.co.jp ([129.60.39.102]) by ietf-mx with esmtp (Exim 4.12) id 1BhpB3-0005Zp-00 for dhcwg@ietf.org; Tue, 06 Jul 2004 08:36:01 -0400 Received: from vcs3.rdh.ecl.ntt.co.jp (vcs3.rdh.ecl.ntt.co.jp [129.60.39.110]) by tama5.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id i66CZxhf026753 for ; Tue, 6 Jul 2004 21:35:59 +0900 (JST) Received: from mfs3.rdh.ecl.ntt.co.jp (localhost [127.0.0.1]) by vcs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id i66CZwUh016977 for ; Tue, 6 Jul 2004 21:35:58 +0900 (JST) Received: from mfs3.rdh.ecl.ntt.co.jp (localhost [127.0.0.1]) by mfs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id i66CZwWS015658 for ; Tue, 6 Jul 2004 21:35:58 +0900 (JST) Received: from nttmail3.ecl.ntt.co.jp ([129.60.39.100]) by mfs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id i66CZvi8015653 for ; Tue, 6 Jul 2004 21:35:57 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (eclscan3.m.ecl.ntt.co.jp [129.60.5.69]) by nttmail3.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id i66CZvd8006279 for ; Tue, 6 Jul 2004 21:35:57 +0900 (JST) Received: from ime.m.ecl.ntt.co.jp (localhost [127.0.0.1]) by eclscan3.m.ecl.ntt.co.jp (8.9.3p2/3.7W) with ESMTP id VAA20256 for ; Tue, 6 Jul 2004 21:35:56 +0900 (JST) Received: from lab.ntt.co.jp by ime.m.ecl.ntt.co.jp (8.9.3p2/3.7W) with ESMTP id VAA28548 for ; Tue, 6 Jul 2004 21:35:56 +0900 (JST) Message-ID: <40EA9D5B.1060308@lab.ntt.co.jp> Date: Tue, 06 Jul 2004 21:38:51 +0900 From: Mayumi Yanagiya User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja MIME-Version: 1.0 To: dhcwg@ietf.org Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [dhcwg] identifier for key selection 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 Hello, I have some question about DHCP authentication. 1. Which identifier does DHCP server use to select a key for client? In 21.4.5, it is specified that the server selects a key for client, based on the "client’s DUID" and key selection policies. But in 21.4.1, it seems that the "DHCP realm" is used to identify authentication key. Which identifier does the server use? 2. Can we use user identifier, such as NAI, as DUID? In section 9, it is specified that DHCP servers use DUID to identify “clients”. Does the “clients” mean only hardware such as NIC? Regards, -Mayumi _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Jul 6 10:27:19 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 KAA18899; Tue, 6 Jul 2004 10:27: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 1BhqWS-0006KQ-QQ; Tue, 06 Jul 2004 10:02:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BhphV-00088G-0j for dhcwg@megatron.ietf.org; Tue, 06 Jul 2004 09:09:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12388 for ; Tue, 6 Jul 2004 09:09:26 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BhphP-0001nT-7Z for dhcwg@ietf.org; Tue, 06 Jul 2004 09:09:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BhpgT-0001Tg-00 for dhcwg@ietf.org; Tue, 06 Jul 2004 09:08:30 -0400 Received: from tyholt.uninett.no ([158.38.60.10]) by ietf-mx with esmtp (Exim 4.12) id 1Bhpg0-00018p-00 for dhcwg@ietf.org; Tue, 06 Jul 2004 09:08:00 -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 i66D7MDW007795; Tue, 6 Jul 2004 15:07:22 +0200 Received: (from venaas@localhost) by sverresborg.uninett.no (8.12.8/8.12.8/Submit) id i66D7HLD009252; Tue, 6 Jul 2004 15:07:17 +0200 X-Authentication-Warning: sverresborg.uninett.no: venaas set sender to Stig.Venaas@uninett.no using -f Date: Tue, 6 Jul 2004 15:07:17 +0200 From: Stig Venaas To: Thomas Narten Subject: Re: [dhcwg] Lifetime option (draft-ietf-dhc-lifetime-00.txt) Message-ID: <20040706130717.GA8927@sverresborg.uninett.no> References: <20040629111425.GA14068@sverresborg.uninett.no> <200407021436.i62EaIAk022886@rotala.raleigh.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200407021436.i62EaIAk022886@rotala.raleigh.ibm.com> User-Agent: Mutt/1.4.1i X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 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, Jul 02, 2004 at 10:36:18AM -0400, Thomas Narten wrote: > Personally, I think that if one is trying to contact a DHC server, and > none respond, there should be a generic algorithm used for > retries. I.e., the case for this option should not be any different > (for say) the case where one first boots, and no DHC server responds, > or when one fails to renew an address after an address expires. > > I.e., isn't there already a generic retranmission with backoff and > some upper limit? Why not just do the same? Is there a need for > multiple different algorithms? You're right. I've looked more carefully at RFC 3315, and the obvious thing is to follow the same rules. It specifies how a client should send messages (including backoff) and we're after all not changing the DHCP protocol. I suggest the following text for the next version: 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]. Then it can make the DHCP request to update the configuration. The message MUST be created and transmitted according to [RFC 3315]. E.g. 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]. Any other comments on the draft are welcome. I'm hoping the next version may be the final one, I don't think there's much more that can be said about this simple option... Stig _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Jul 6 15: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 PAA17985; Tue, 6 Jul 2004 15: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 1BhvNE-0001AV-Rg; Tue, 06 Jul 2004 15:13:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bhus7-0003ub-3S for dhcwg@megatron.ietf.org; Tue, 06 Jul 2004 14:40:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11035 for ; Tue, 6 Jul 2004 14:40:44 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bhus0-0005yr-Tj for dhcwg@ietf.org; Tue, 06 Jul 2004 14:40:45 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bhuqv-0005aG-00 for dhcwg@ietf.org; Tue, 06 Jul 2004 14:39:37 -0400 Received: from zrtps0kn.nortelnetworks.com ([47.140.192.55]) by ietf-mx with esmtp (Exim 4.12) id 1Bhupm-0004t2-00 for dhcwg@ietf.org; Tue, 06 Jul 2004 14:38:26 -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 i66IbQh17937; Tue, 6 Jul 2004 14:37:26 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 6 Jul 2004 14:37:26 -0400 Message-ID: <591B780D9676844E8A704B5B013FFE920189FE69@zrc2hxm1.corp.nortel.com> From: "Kuntal Chowdhury" To: dhcwg@ietf.org Date: Tue, 6 Jul 2004 14:37:17 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Cc: "'Parviz Yegani \(pyegani@cisco.com\)'" , "Lila Madour \(QA/EMC\)" Subject: [dhcwg] new ID on Broadcast Multicast controller IPv4 address options 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, We submitted a draft defining Broadcast and Multicast Service Controller IPv4 address and domain name options. The draft is available at: http://www.ietf.org/internet-drafts/draft-chowdhury-dhc-bcmcv4-option-00.txt The abstract is as follows: Abstract This document defines new options for Broadcast and Multicast Service controller discovery in an IP network. Broadcast service is being developed for 3G wireless networks. Users of the service interact with a controller in the network to derive informations that are required to receive broadcast service. Dynamic Host Configuration Protocol can be used to configure the controller IPv4 addresses or fully qualified domain names in the user's devices. This document defines the related options and option codes. We appreciate your review and comment on the proposed options. Regards, Kuntal _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Jul 7 07:24: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 HAA11857; Wed, 7 Jul 2004 07:24: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 1Bi9sl-0001z9-Dh; Wed, 07 Jul 2004 06:42:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bi9E8-0001WD-2v for dhcwg@megatron.ietf.org; Wed, 07 Jul 2004 06:00:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07891 for ; Wed, 7 Jul 2004 06:00:24 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bi9E0-00050j-MY for dhcwg@ietf.org; Wed, 07 Jul 2004 06:00:24 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bi9D2-0004fi-00 for dhcwg@ietf.org; Wed, 07 Jul 2004 05:59:25 -0400 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 1Bi9CW-0004KY-00 for dhcwg@ietf.org; Wed, 07 Jul 2004 05:58:52 -0400 Received: from ocean.jinmei.org (unknown [3ffe:501:100f:1048:200:39ff:fed7:e2e4]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id B364B1525D; Wed, 7 Jul 2004 18:58:52 +0900 (JST) Date: Wed, 07 Jul 2004 18:58:51 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Ralph Droms Subject: Re: [dhcwg] *DRAFT* Agenda for dhc WG meeting in San Diego In-Reply-To: <4.3.2.7.2.20040621184653.020ffcd8@flask.cisco.com> References: <4.3.2.7.2.20040621184653.020ffcd8@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-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 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, 21 Jun 2004 18:48:44 -0400, >>>>> Ralph Droms said: > Below is the draft scheduled time and agenda for the dhc WG meeting in San > Diego. Let me know if you have additional items for the agenda. Does it make sense to discuss (possible) clarifications on the authentication mechanism of DHCPv6 (RFC3315)? I raised some questions the other day (*), and, according to the succeeding messages, there seem to be some issues that need further discussion. But I'm not sure if my questions are valid in the first place since I've not seen any responses from the RFC3315 authors. If this is worth a discussion, I'll try to find time to make a very short draft summarizing the issues, and will ask for a short slot in the meeting. (*) http://www1.ietf.org/mail-archive/web/dhcwg/current/msg03645.html 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 Jul 7 09: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 JAA19911; Wed, 7 Jul 2004 09: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 1BiCNr-0004Cp-BW; Wed, 07 Jul 2004 09: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 1BiByP-0006LZ-Rh for dhcwg@megatron.ietf.org; Wed, 07 Jul 2004 08:56:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16701 for ; Wed, 7 Jul 2004 08:56:22 -0400 (EDT) From: babatke@ra.rockwell.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BiByK-0004Q5-7j for dhcwg@ietf.org; Wed, 07 Jul 2004 08:56:24 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BiBxK-00043O-00 for dhcwg@ietf.org; Wed, 07 Jul 2004 08:55:22 -0400 Received: from mkedef1.rockwellautomation.com ([208.22.104.18] helo=raclesmtp01.ra.rockwell.com) by ietf-mx with esmtp (Exim 4.12) id 1BiBwE-0003Nb-00 for dhcwg@ietf.org; Wed, 07 Jul 2004 08:54:14 -0400 To: dhcwg@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.10 March 22, 2002 Message-ID: Date: Wed, 7 Jul 2004 08:54:10 -0400 X-MIMETrack: Serialize by Router on RACleSMTP01/Cleveland/RA/Rockwell(Release 5.0.11 |July 24, 2002) at 07/07/2004 08:54:14 AM, Serialize complete at 07/07/2004 08:54:14 AM X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=HTML_MESSAGE,NO_REAL_NAME autolearn=no version=2.60 Subject: [dhcwg] Gratuitous ARP in DHCP vs. IPv4 ACD Draft 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="===============0774237263==" Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org This is a multipart message in MIME format. --===============0774237263== Content-Type: multipart/alternative; boundary="=_alternative 0046D5F285256ECA_=" This is a multipart message in MIME format. --=_alternative 0046D5F285256ECA_= Content-Type: text/plain; charset="us-ascii" RFC 2131, in section 4.4.1 says that "The client SHOULD broadcast an ARP reply to announce the client's new IP address ..." This is the so-called 'gratuitous ARP'. The Internet Draft for IPv4 Address Conflict Detection (http://files.stuartcheshire.org/draft-cheshire-ipv4-acd-00.txt) refers to this as an "ARP announcement" and defines it as an ARP request rather than a reply. This definition is also in other Zeroconf drafts. In products I have looked at (with BSD-derived stacks) it seems that the gratuitous ARP is sent as a request (except when it is sent by the DHCP client). Is there a need for consistency across the various mechanisms? (DHCP client, IPv4 ACD, IPv4 Link Local, etc.)? Brian Batke Rockwell Automation --=_alternative 0046D5F285256ECA_= Content-Type: text/html; charset="us-ascii"
RFC 2131, in section 4.4.1 says that "The client SHOULD broadcast an ARP reply to announce the client's new IP address ..."

This is the so-called 'gratuitous ARP'.

The Internet Draft for IPv4 Address Conflict Detection (http://files.stuartcheshire.org/draft-cheshire-ipv4-acd-00.txt) refers to this as an "ARP announcement" and defines it as an ARP request rather than a reply.  This definition is also in other Zeroconf drafts.

In products I have looked at (with BSD-derived stacks) it seems that the gratuitous ARP is sent as a request  (except when it is sent by the DHCP client).


Is there a need for consistency across the various mechanisms?  (DHCP client, IPv4 ACD, IPv4 Link Local, etc.)?

Brian Batke
Rockwell Automation --=_alternative 0046D5F285256ECA_=-- --===============0774237263== 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 --===============0774237263==-- From dhcwg-bounces@ietf.org Wed Jul 7 14: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 OAA04744; Wed, 7 Jul 2004 14:01: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 1BiG6z-0006Kt-LZ; Wed, 07 Jul 2004 13:21:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BiFSQ-0004Ko-TU for dhcwg@megatron.ietf.org; Wed, 07 Jul 2004 12:39:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29422 for ; Wed, 7 Jul 2004 12:39:34 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BiFSK-00022Q-TM for dhcwg@ietf.org; Wed, 07 Jul 2004 12:39:37 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BiFRO-0001j5-00 for dhcwg@ietf.org; Wed, 07 Jul 2004 12:38:39 -0400 Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx with esmtp (Exim 4.12) id 1BiFQS-0001QS-00 for dhcwg@ietf.org; Wed, 07 Jul 2004 12:37:41 -0400 Received: from [10.0.2.3] (neubayern.net [66.93.162.100]) by toccata.fugue.com (Postfix) with ESMTP id 3971D1B209C; Wed, 7 Jul 2004 11:31:00 -0500 (CDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: Ted Lemon Subject: Re: [dhcwg] Gratuitous ARP in DHCP vs. IPv4 ACD Draft Date: Wed, 7 Jul 2004 09:37:35 -0700 To: babatke@ra.rockwell.com X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 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 Jul 7, 2004, at 5:54 AM, babatke@ra.rockwell.com wrote: > The Internet Draft for IPv4 Address Conflict Detection=20 > (http://files.stuartcheshire.org/draft-cheshire-ipv4-acd-00.txt)=20 > refers to this as an "ARP announcement" and defines it as an ARP=20 > request rather than a reply. =A0This definition is also in other=20 > Zeroconf drafts. > > In products I have looked at (with BSD-derived stacks) it seems that=20= > the gratuitous ARP is sent as a request =A0(except when it is sent by=20= > the DHCP client). > > > Is there a need for consistency across the various mechanisms? =A0(DHCP=20= > client, IPv4 ACD, IPv4 Link Local, etc.)? I think it's worth having a standard that says what the right thing to=20= do is. Stuart's draft seemed like a good candidate, but did not get=20 widespread support from the DHC working group, if I remember correctly.=20= There was also some question as to whether it was even on-topic for=20= the working group, since it actually changes the semantics of ARP=20 somewhat. I would personally like to see the idea carried further, but haven't=20 seen nor heard from Stuart in a while, so I don't know what's going to=20= happen with it. :'/ _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Jul 7 16:16: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 QAA15078; Wed, 7 Jul 2004 16:16: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 1BiIL1-0006ag-Rt; Wed, 07 Jul 2004 15:44:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BiHpj-0000ZK-LM for dhcwg@megatron.ietf.org; Wed, 07 Jul 2004 15:11:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09559 for ; Wed, 7 Jul 2004 15:11:48 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BiHpd-0006iO-Cw for dhcwg@ietf.org; Wed, 07 Jul 2004 15:11:49 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BiHot-0006O3-00 for dhcwg@ietf.org; Wed, 07 Jul 2004 15:11:04 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx with esmtp (Exim 4.12) id 1BiHny-0005ym-00 for dhcwg@ietf.org; Wed, 07 Jul 2004 15:10:06 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 07 Jul 2004 15:18:43 -0400 X-BrightmailFiltered: true Received: from jschnizl-w2k.cisco.com (rtp-vpn2-15.cisco.com [10.82.240.15]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i67J9YaH007221; Wed, 7 Jul 2004 15:09:34 -0400 (EDT) Message-Id: <4.3.2.7.2.20040707150440.02dbf6f8@wells.cisco.com> X-Sender: jschnizl@wells.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 07 Jul 2004 15:10:30 -0400 To: babatke@ra.rockwell.com From: John Schnizlein Subject: Re: [dhcwg] Gratuitous ARP in DHCP vs. IPv4 ACD Draft In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 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 Just before the section of the RFC you quoted is the part that recommends that the client issue an ARP request to discover if the address is already in use. This part seems most like the conflict detection part of ZeroConf. The part you quoted is there for the case when there is no other host with the address in question, but there might have been previously. That is why the (other host's) ARP caches are cleared. The combination of both the request and the reply, which is clearer from the longer context of the text, first checks for a duplicate address, then provides other hosts a cache update for the host newly using the address. The broader context of the specification quoted here for convenience: The client SHOULD perform a check on the suggested address to ensure that the address is not already in use. For example, if the client is on a network that supports ARP, the client may issue an ARP request for the suggested request. When broadcasting an ARP request for the suggested address, the client must fill in its own hardware address as the sender's hardware address, and 0 as the sender's IP address, to avoid confusing ARP caches in other hosts on the same subnet. If the network address appears to be in use, the client MUST send a DHCPDECLINE message to the server. The client SHOULD broadcast an ARP reply to announce the client's new IP address and clear any outdated ARP cache entries in hosts on the client's subnet. John At 08:54 AM 7/7/2004, babatke@ra.rockwell.com wrote: >RFC 2131, in section 4.4.1 says that "The client SHOULD broadcast an ARP reply to announce the client's new IP address ..." > >This is the so-called 'gratuitous ARP'. > >The Internet Draft for IPv4 Address Conflict Detection (http://files.stuartcheshire.org/draft-cheshire-ipv4-acd-00.txt) refers to this as an "ARP announcement" and defines it as an ARP request rather than a reply. This definition is also in other Zeroconf drafts. > >In products I have looked at (with BSD-derived stacks) it seems that the gratuitous ARP is sent as a request (except when it is sent by the DHCP client). > > >Is there a need for consistency across the various mechanisms? (DHCP client, IPv4 ACD, IPv4 Link Local, etc.)? > >Brian Batke >Rockwell Automation >_______________________________________________ >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 Jul 7 17:53: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 RAA19435; Wed, 7 Jul 2004 17:53: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 1BiJA3-0003PL-5Y; Wed, 07 Jul 2004 16:36:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BiIWh-0001bX-RD for dhcwg@megatron.ietf.org; Wed, 07 Jul 2004 15:56:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14098 for ; Wed, 7 Jul 2004 15:56:12 -0400 (EDT) From: babatke@ra.rockwell.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BiIWb-0006eb-Ku for dhcwg@ietf.org; Wed, 07 Jul 2004 15:56:13 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BiIV5-0006Ej-00 for dhcwg@ietf.org; Wed, 07 Jul 2004 15:54:40 -0400 Received: from mkedef1.rockwellautomation.com ([208.22.104.18] helo=raclesmtp01.ra.rockwell.com) by ietf-mx with esmtp (Exim 4.12) id 1BiIU2-0005bs-00 for dhcwg@ietf.org; Wed, 07 Jul 2004 15:53:34 -0400 To: dhcwg@ietf.org Subject: Re: [dhcwg] Gratuitous ARP in DHCP vs. IPv4 ACD Draft MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.10 March 22, 2002 Message-ID: Date: Wed, 7 Jul 2004 15:53:31 -0400 X-MIMETrack: Serialize by Router on RACleSMTP01/Cleveland/RA/Rockwell(Release 5.0.11 |July 24, 2002) at 07/07/2004 03:53:34 PM, Serialize complete at 07/07/2004 03:53:34 PM X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.7 required=5.0 tests=AWL,HTML_30_40,HTML_MESSAGE, NO_REAL_NAME autolearn=no version=2.60 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="===============1553194016==" Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org This is a multipart message in MIME format. --===============1553194016== Content-Type: multipart/alternative; boundary="=_alternative 006D3A4585256ECA_=" This is a multipart message in MIME format. --=_alternative 006D3A4585256ECA_= Content-Type: text/plain; charset="us-ascii" > Just before the section of the RFC you quoted > is the part that recommends that the client issue > an ARP request to discover if the address is already > in use. This part seems most like the > conflict detection part of ZeroConf. Yes, this is the ARP "probe" that is more formalized in the IPv4 ACD document. > The part you quoted is there for the case when there > is no other host with the address in question, but there > might have been previously. That is why the (other host's) > ARP caches are cleared. The IPv4 ACD document calls this an ARP "announcement". And the behavior is the same -- after probing for an address and finding no conflict, you issue an ARP request for your own address, which causes ARP caches to be updated. (except the DHCP RFC says reply not request ... hence my question). > The combination of both the request and the reply, > which is clearer from the longer context of the text, > first checks for a duplicate address, then provides other > hosts a cache update for the host newly using the address. Which is what the IPv4 ACD mechanism does ... but in a more well-defined way, and it also includes 'ongoing conflict detection and defense". Brian --=_alternative 006D3A4585256ECA_= Content-Type: text/html; charset="us-ascii"
> Just before the section of the RFC you quoted
> is the part that recommends that the client issue
> an ARP request to discover if the address is already
> in use. This part seems most like the
> conflict detection part of ZeroConf.

Yes, this is the ARP "probe" that is more formalized
in the IPv4 ACD document.


> The part you quoted is there for the case when there
> is no other host with the address in question, but there
> might have been previously. That is why the (other host's)
> ARP caches are cleared.

The IPv4 ACD document calls this an ARP "announcement".
And the behavior is the same -- after probing for an
address and finding no conflict, you issue an ARP
request for your own address, which causes ARP
caches to be updated. (except the DHCP RFC
says reply not request ... hence my question).


> The combination of both the request and the reply,
> which is clearer from the longer context of the text,
> first checks for a duplicate address, then provides other
> hosts a cache update for the host newly using the address.

Which is what the IPv4 ACD mechanism does ... but in a more
well-defined way, and it also includes 'ongoing conflict
detection and defense".

Brian
--=_alternative 006D3A4585256ECA_=-- --===============1553194016== 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 --===============1553194016==-- From dhcwg-bounces@ietf.org Wed Jul 7 18:30:19 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 SAA23128; Wed, 7 Jul 2004 18:30: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 1BiJYU-00012a-Ct; Wed, 07 Jul 2004 17:02:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BfH08-0007tJ-9p for dhcwg@megatron.ietf.org; Tue, 29 Jun 2004 07:42:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13013 for ; Tue, 29 Jun 2004 07:42:11 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BfH07-0005y5-O5 for dhcwg@ietf.org; Tue, 29 Jun 2004 07:42:11 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BfGzC-0005fe-00 for dhcwg@ietf.org; Tue, 29 Jun 2004 07:41:15 -0400 Received: from ints.mail.pike.ru ([195.9.45.194]) by ietf-mx with esmtp (Exim 4.12) id 1BfGyc-0005N6-00 for dhcwg@ietf.org; Tue, 29 Jun 2004 07:40:38 -0400 Received: (qmail 23564 invoked from network); 29 Jun 2004 12:01:47 -0000 Received: from stratess.ints.pike (HELO strates) (195.9.37.191) by ints.mail.pike.ru with SMTP; 29 Jun 2004 12:01:47 -0000 Date: Tue, 29 Jun 2004 15:40:30 +0400 From: strates X-Mailer: The Bat! (v1.36) S/N F29DEE5D / Educational X-Priority: 3 (Normal) Message-ID: <0653.040629@mail.ru> To: dhcwg@ietf.org Subject: Re[2]: [dhcwg] [Question]DHCPv6 implementations In-reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=Windows-1251 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=3.2 required=5.0 tests=FORGED_MUA_THEBAT autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id HAA13013 X-Mailman-Approved-At: Wed, 07 Jul 2004 17:02:11 -0400 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: strates 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 Subj: KAME DHCPv6 implementation, clarification Re : JINMEI, Tatuya, Date: Fri, 25 Jun 2004 11:39:26 +0900 ---------------------------------------------------------- >> - KAME implementation for *BSDs: stateless DHCPv6, and they are not go= ing >> to improve it > Just checking: what do you mean by "not going to improve it"? We > (KAME) are actually seriously maintaining the implementation, > including bug fixes and supporting new features. In fact, we've I didn't phrase my though clear enough. My apologies. New features are added, indeed http://orange.kame.net/dev/cvsweb2.cgi/kame/kame/kame/dhcp6/ > Perhaps you simply meant we do not have a plan to implement address > allocation by DHCPv6. In that sense you're correct, though I'd not > say "not going to improve it" meaning luck of a plan for one part of ... Yes, it is what I meant. --=20 =D0=E5=E1=F0=E8=EA=EE=E2 =CA=EE=ED=F1=F2=E0=ED=F2=E8=ED strates@mail.ru -- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Jul 7 18:31: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 SAA23568; Wed, 7 Jul 2004 18:31: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 1BiJaB-0001Ot-RO; Wed, 07 Jul 2004 17:03:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BfKhn-0003wG-5u for dhcwg@megatron.ietf.org; Tue, 29 Jun 2004 11:39:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27014 for ; Tue, 29 Jun 2004 11:39:29 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BfKhm-0006nc-C9 for dhcwg@ietf.org; Tue, 29 Jun 2004 11:39:30 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BfKgt-0006RO-00 for dhcwg@ietf.org; Tue, 29 Jun 2004 11:38:35 -0400 Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx with esmtp (Exim 4.12) id 1BfKg2-00065n-00 for dhcwg@ietf.org; Tue, 29 Jun 2004 11:37:42 -0400 Received: from [10.0.2.3] (neubayern.net [66.93.162.100]) by toccata.fugue.com (Postfix) with ESMTP id 4CCA61B22D2; Tue, 29 Jun 2004 10:32:24 -0500 (CDT) In-Reply-To: <20040629111425.GA14068@sverresborg.uninett.no> References: <20040629111425.GA14068@sverresborg.uninett.no> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <3FF3BFEC-C9E2-11D8-B868-000A95D9C74C@fugue.com> Content-Transfer-Encoding: 7bit From: Ted Lemon Subject: Re: [dhcwg] Lifetime option (draft-ietf-dhc-lifetime-00.txt) Date: Tue, 29 Jun 2004 08:37:38 -0700 To: Stig Venaas X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 07 Jul 2004 17:03:57 -0400 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 Jun 29, 2004, at 4:14 AM, Stig Venaas wrote: > I think it might be better to retry. The retry interval could be a > function of the lifetime. The reason I didn't in the current version, > is that I was worried what would happen if someone sent a forged reply > with say a lifetime of 1s. > > What do you think? Should there be some retry? What should the > function be? I think it's reasonable to retry. I don't think that forgetting the lifetime if one is not heard in a subsequent reply is a good idea, because it's likely to lead clients into a stagnant state where they never recheck. You can do a perfectly good DoS attack that way as well. I think it would be fair to say that a lifetime of zero should be discarded, and perhaps the previous lifetime, if any, should be retained in that case. As for what happens if the client gets a lifetime of 1s, I don't know. You could add a really hairy protocol for managing timeouts, but I'm not sure it's worth it. For example, you could say that if we had a lifetime of n, then if we subsequently get a lifetime that is less than n/2, we will ignore it. Or we will use a lifetime of n/2. But of course then you have to go down the path of considering all the possible legitimate reasons why the lifetime might drop precipitously, and make sure that if the prefix changes you forget the old lifetime, and like that, and I think it just gets too hairy. I think creating a situation where you get significant amplification from a DoS attack based on short lifetimes would be pretty challenging. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Jul 7 18:34: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 SAA24083; Wed, 7 Jul 2004 18:34: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 1BiJaC-0001P3-6W; Wed, 07 Jul 2004 17:04:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bfl3J-0008L1-2L; Wed, 30 Jun 2004 15:47:29 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10072; Wed, 30 Jun 2004 15:47:26 -0400 (EDT) Message-Id: <200406301947.PAA10072@ietf.org> From: The IESG To: IETF-Announce: ; Date: Wed, 30 Jun 2004 15:47:26 -0400 X-Mailman-Approved-At: Wed, 07 Jul 2004 17:03:57 -0400 Cc: dhcwg@ietf.org, Ralph Droms Subject: [dhcwg] WG Action: RECHARTER: Dynamic Host Configuration (dhc) 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 charter of the Dynamic Host Configuration (dhc) working group in the Internet Area of the IETF has been updated. For additional information, please contact the Area Directors or the working group Chairs. Dynamic Host Configuration (dhc) ================================ Current Status: Active Working Group Chair(s): Ralph Droms Internet Area Directors: Thomas Narten Margaret Wasserman Internet Area Advisor: Margaret Wasserman Mailing Lists: General Discussion: dhcwg@ietf.org To Subscribe: http://www.ietf.org/mailman/.istinfo/dhcwg Archive: http://www.ietf.org/mail-archive/web/dhcwg/index.html The dhc working group (DHC WG) has developed DHCP for automated allocation, configuration and management of IP addresses and TCP/IP protocol stack parameters. DHCPv4 is currently a "Draft Standard" and is documented in RFC 2131 and RFC 2132. DHCPv6 is currently a "Proposed Standard" and is documented in RFC 3315. Subsequent RFCs document additional options and other enhancements to the specifications. The DHC WG is responsible for reviewing (and sometimes developing) DHCP options or other extensions (for both IPv4 and IPv6). The DHC WG is expected to review all proposed extensions to DHCP to ensure that they are consistent with the DHCP specification and other option formats, that they do not duplicate existing mechanisms, etc. The DHC WG will not (generally) be responsible for evaluating the semantic content of proposed options. The DHC WG will not adopt new proposals for extensions to DHCP as working group documents without first coordinating with other relevant working groups and determining who has the responsibility for reviewing the semantic content of an option. The DHC WG has the following main objectives: * Address security in DHCP o Develop and document security requirements for DHCP. RFC 3118 defines current security mechanisms for DHCPv4. Unfortunately, RFC 3118 has neither been implemented nor deployed to date. Specific issues to be considered include: - Improved key management and scalability - Security for messages passed between relay agents and servers - Threats of DoS attacks through DHCPFORCERENEW - The increased usage of DHC on unsecured (e.g., wireless) and public LANs - The need for clients to be able to authenticate servers, without simultaneously requiring client authentication by the server. o Develop and document a roadmap of any new documents or protocols needed to meet the security requirements for DHCP * Write an analysis of the DHCP specification, including RFC 2131, RFC 2132 and other RFCs defining additional options, which identifies ambiguities, contradictory specifications and other obstacles to development of interoperable implementations. Recommend a process for resolving identified problems and incorporating the resolutions into the DHCP specification. * Assess the requirements for a dual-stack host to use DHCP to obtain configuration settings for both IPv4 and IPv6. Hosts that include implementations of both IPv4 and IPv6 ("dual-stack hosts") may use DHCP to obtain configuration settings (including assigned addresses) for both IPv4 and IPv6. The DHCPv4 and DHCPv6 specifications (RFC 2131, RFC 2132, RFC 3315 and subsequent RFCs) do not explicitly explain how a dual-stack host uses DHCP to obtain configuration settings for both IP stacks. The DHC WG will evaluate solutions for configuration of dual-stack hosts through DHCP and select a solution that will be developed and published by the WG. * Assess the requirements for informing DHCPv6 clients of changes in configuration information. The DHCPv6 specification in RFC 3315 includes a mechanism through which clients can obtain other configuration information without obtaining an address or addresses. This mechanisms is sometimes called "stateless DHCPv6" and is specified in RFC 3736. RFC 3315 includes no provision for notifying DHCPv6 clients using stateless DHCPv6 of changes in the configuration information supplied to the client or any recommendations as to when a client should obtain possibly updated information. The DHC WG will evaluate solutions for informing DHCPv6 clients of changes in configuration information and select a solution that will be developed and published by the WG. Goals and Milestones: Done Submit "DHCP Options for Internet Storage Name Service" to IESG (draft-ietf-dhc-isnsoption) Done Submit "DNS Configuration options for DHCPv6" to IESG (draft-ietf-dhc-dhcpv6-opt-dnsconfig) Done Submit "NIS Configuration Options for DHCPv6" to IESG (draft-ietf-dhc-dhcpv6-opt-nisconfig) Done Submit "IPv6 Prefix Options for DHCPv6" to IESG (draft-ietf-dhc-dhcpv6-opt-prefix-delegation) Done Submit "Simple Network Time Protocol Configuration Option for DHCPv6" to IESG (draft-ietf-dhc-dhcpv6-opt-sntp) Jul04 Submit "Detection of Network Attachment (DNA) in IPv4" to IESG (draft-ietf-dhc-dna-ipv4) Jul04 Resolve IPR issues around "Rapid Commit Option for DHCPv4" Aug04 Publish report on dual-stack issues in DHCP (draft-ietf-dhc-dual-stack) Aug04 Publish report on requirements for renumbering using stateless DHCPv6 (draft-ietf-dhc-stateless-dhcpv6-renumbering) Sep04 Submit "Lifetime Option for DHCPv6" to IESG (draft-ietf-dhc-lifetime) Sep04 DHCPv4 authentication design team report completed, "Dynamic Host Configuration Protocol for IPv4 (DHCPv4) Threat Analysis" Sep04 DHCPv4 specification review report completed Sep04 Submit "DHCP Failover Protocol" to IESG (draft-ietf-dhc-failover) Sep04 Submit "Rapid Commit Option for DHCPv4" to IESG (draft-ietf-dhc-rapid-commit-opt) Dec04 Submit DDNS/DHCP documents to IESG Dec04 Submit "Node-Specific Client Identifiers for DHCPv4" to IESG (draft-ietf-dhc-3315id-for-v4) _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Jul 7 18:36: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 SAA24367; Wed, 7 Jul 2004 18:36: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 1BiJaC-0001PR-I2; Wed, 07 Jul 2004 17:04:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bg3yE-0006SZ-CR for dhcwg@megatron.ietf.org; Thu, 01 Jul 2004 11:59:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13238 for ; Thu, 1 Jul 2004 11:59:28 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bg3yD-0005CQ-IA for dhcwg@ietf.org; Thu, 01 Jul 2004 11:59:29 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bg3xI-0004pa-00 for dhcwg@ietf.org; Thu, 01 Jul 2004 11:58:33 -0400 Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx with esmtp (Exim 4.12) id 1Bg3wn-0004Rw-00 for dhcwg@ietf.org; Thu, 01 Jul 2004 11:58:01 -0400 Received: from [10.0.2.3] (neubayern.net [66.93.162.100]) by toccata.fugue.com (Postfix) with ESMTP id 577AA1B22B8 for ; Thu, 1 Jul 2004 10:52:23 -0500 (CDT) Mime-Version: 1.0 (Apple Message framework v618) In-Reply-To: <200406301947.PAA10072@ietf.org> References: <200406301947.PAA10072@ietf.org> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <6B598B81-CB77-11D8-B868-000A95D9C74C@fugue.com> Content-Transfer-Encoding: 7bit From: Ted Lemon Date: Thu, 1 Jul 2004 08:57:56 -0700 To: dhcwg@ietf.org X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 07 Jul 2004 17:03:57 -0400 Subject: [dhcwg] Re: WG Action: RECHARTER: Dynamic Host Configuration (dhc) 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 Jun 30, 2004, at 12:47 PM, The IESG wrote: > Dec04 Submit "Node-Specific Client Identifiers for DHCPv4" to IESG > (draft-ietf-dhc-3315id-for-v4) December seems like a long time to wait to finish this one up. Any idea why it's so late on the list of milestones? _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Jul 7 18:40: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 SAA25001; Wed, 7 Jul 2004 18:40: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 1BiJaC-0001Pc-RU; Wed, 07 Jul 2004 17:04:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BgII7-00082P-80 for dhcwg@megatron.ietf.org; Fri, 02 Jul 2004 03:16:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11925 for ; Fri, 2 Jul 2004 03:16:57 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BgII5-0001sj-1f for dhcwg@ietf.org; Fri, 02 Jul 2004 03:16:57 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BgIH5-0001Xe-00 for dhcwg@ietf.org; Fri, 02 Jul 2004 03:15:56 -0400 Received: from [216.27.12.130] (helo=trinityconvergence.com) by ietf-mx with esmtp (Exim 4.12) id 1BgIG8-0000tq-00 for dhcwg@ietf.org; Fri, 02 Jul 2004 03:14:56 -0400 From: "The IESG" To: , "IMB Recipient 1" Date: Fri, 2 Jul 2004 03:14:27 -0400 Message-ID: <007f01c46004$35c69940$050010ac@Trinity.local> Precedence: list Status: U X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=2.0 required=5.0 tests=NEW_DOMAIN_EXTENSIONS autolearn=no version=2.60 X-Mailman-Approved-At: Wed, 07 Jul 2004 17:03:57 -0400 Cc: dhcwg@ietf.org, Ralph Droms Subject: [dhcwg] WG Action: RECHARTER: Dynamic Host Configuration (dhc) X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 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 charter of the Dynamic Host Configuration (dhc) working group in the Internet Area of the IETF has been updated. For additional information, please contact the Area Directors or the working group Chairs. Dynamic Host Configuration (dhc) ================================ Current Status: Active Working Group Chair(s): Ralph Droms Internet Area Directors: Thomas Narten Margaret Wasserman Internet Area Advisor: Margaret Wasserman Mailing Lists: General Discussion: dhcwg@ietf.org To Subscribe: http://www.ietf.org/mailman/.istinfo/dhcwg Archive: http://www.ietf.org/mail-archive/web/dhcwg/index.html The dhc working group (DHC WG) has developed DHCP for automated allocation, configuration and management of IP addresses and TCP/IP protocol stack parameters. DHCPv4 is currently a "Draft Standard" and is documented in RFC 2131 and RFC 2132. DHCPv6 is currently a "Proposed Standard" and is documented in RFC 3315. Subsequent RFCs document additional options and other enhancements to the specifications. The DHC WG is responsible for reviewing (and sometimes developing) DHCP options or other extensions (for both IPv4 and IPv6). The DHC WG is expected to review all proposed extensions to DHCP to ensure that they are consistent with the DHCP specification and other option formats, that they do not duplicate existing mechanisms, etc. The DHC WG will not (generally) be responsible for evaluating the semantic content of proposed options. The DHC WG will not adopt new proposals for extensions to DHCP as working group documents without first coordinating with other relevant working groups and determining who has the responsibility for reviewing the semantic content of an option. The DHC WG has the following main objectives: * Address security in DHCP o Develop and document security requirements for DHCP. RFC 3118 defines current security mechanisms for DHCPv4. Unfortunately, RFC 3118 has neither been implemented nor deployed to date. Specific issues to be considered include: - Improved key management and scalability - Security for messages passed between relay agents and servers - Threats of DoS attacks through DHCPFORCERENEW - The increased usage of DHC on unsecured (e.g., wireless) and public LANs - The need for clients to be able to authenticate servers, without simultaneously requiring client authentication by the server. o Develop and document a roadmap of any new documents or protocols needed to meet the security requirements for DHCP * Write an analysis of the DHCP specification, including RFC 2131, RFC 2132 and other RFCs defining additional options, which identifies ambiguities, contradictory specifications and other obstacles to development of interoperable implementations. Recommend a process for resolving identified problems and incorporating the resolutions into the DHCP specification. * Assess the requirements for a dual-stack host to use DHCP to obtain configuration settings for both IPv4 and IPv6. Hosts that include implementations of both IPv4 and IPv6 ("dual-stack hosts") may use DHCP to obtain configuration settings (including assigned addresses) for both IPv4 and IPv6. The DHCPv4 and DHCPv6 specifications (RFC 2131, RFC 2132, RFC 3315 and subsequent RFCs) do not explicitly explain how a dual-stack host uses DHCP to obtain configuration settings for both IP stacks. The DHC WG will evaluate solutions for configuration of dual-stack hosts through DHCP and select a solution that will be developed and published by the WG. * Assess the requirements for informing DHCPv6 clients of changes in configuration information. The DHCPv6 specification in RFC 3315 includes a mechanism through which clients can obtain other configuration information without obtaining an address or addresses. This mechanisms is sometimes called "stateless DHCPv6" and is specified in RFC 3736. RFC 3315 includes no provision for notifying DHCPv6 clients using stateless DHCPv6 of changes in the configuration information supplied to the client or any recommendations as to when a client should obtain possibly updated information. The DHC WG will evaluate solutions for informing DHCPv6 clients of changes in configuration information and select a solution that will be developed and published by the WG. Goals and Milestones: Done Submit "DHCP Options for Internet Storage Name Service" to IESG (draft-ietf-dhc-isnsoption) Done Submit "DNS Configuration options for DHCPv6" to IESG (draft-ietf-dhc-dhcpv6-opt-dnsconfig) Done Submit "NIS Configuration Options for DHCPv6" to IESG (draft-ietf-dhc-dhcpv6-opt-nisconfig) Done Submit "IPv6 Prefix Options for DHCPv6" to IESG (draft-ietf-dhc-dhcpv6-opt-prefix-delegation) Done Submit "Simple Network Time Protocol Configuration Option for DHCPv6" to IESG (draft-ietf-dhc-dhcpv6-opt-sntp) Jul04 Submit "Detection of Network Attachment (DNA) in IPv4" to IESG (draft-ietf-dhc-dna-ipv4) Jul04 Resolve IPR issues around "Rapid Commit Option for DHCPv4" Aug04 Publish report on dual-stack issues in DHCP (draft-ietf-dhc-dual-stack) Aug04 Publish report on requirements for renumbering using stateless DHCPv6 (draft-ietf-dhc-stateless-dhcpv6-renumbering) Sep04 Submit "Lifetime Option for DHCPv6" to IESG (draft-ietf-dhc-lifetime) Sep04 DHCPv4 authentication design team report completed, "Dynamic Host Configuration Protocol for IPv4 (DHCPv4) Threat Analysis" Sep04 DHCPv4 specification review report completed Sep04 Submit "DHCP Failover Protocol" to IESG (draft-ietf-dhc-failover) Sep04 Submit "Rapid Commit Option for DHCPv4" to IESG (draft-ietf-dhc-rapid-commit-opt) Dec04 Submit DDNS/DHCP documents to IESG Dec04 Submit "Node-Specific Client Identifiers for DHCPv4" to IESG (draft-ietf-dhc-3315id-for-v4) _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Jul 7 21:01: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 VAA01671; Wed, 7 Jul 2004 21:01: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 1BiLEE-0003zq-Tr; Wed, 07 Jul 2004 18: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 1BiK53-0006ke-Lx for dhcwg@megatron.ietf.org; Wed, 07 Jul 2004 17:35:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18741 for ; Wed, 7 Jul 2004 17:35:45 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BiK4x-0007dz-Cn for dhcwg@ietf.org; Wed, 07 Jul 2004 17:35:47 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BiK46-0007L8-00 for dhcwg@ietf.org; Wed, 07 Jul 2004 17:34:54 -0400 Received: from moutvdom.kundenserver.de ([212.227.126.249] helo=moutvdomng.kundenserver.de) by ietf-mx with esmtp (Exim 4.12) id 1BiK3K-00072h-00 for dhcwg@ietf.org; Wed, 07 Jul 2004 17:34:06 -0400 Received: from [212.227.126.221] (helo=mrvdomng.kundenserver.de) by moutvdomng.kundenserver.de with esmtp (Exim 3.35 #1) id 1BiK1E-00042Z-00; Wed, 07 Jul 2004 23:31:56 +0200 Received: from [217.235.101.87] (helo=celeron1000w2k) by mrvdomng.kundenserver.de with esmtp (Exim 3.35 #1) id 1BiK1E-0002VR-00; Wed, 07 Jul 2004 23:31:56 +0200 From: "Hans-Hermann Krost" To: "John Schnizlein" , Subject: AW: [dhcwg] Gratuitous ARP in DHCP vs. IPv4 ACD Draft Date: Wed, 7 Jul 2004 23:34:51 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <4.3.2.7.2.20040707150440.02dbf6f8@wells.cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 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 Now I am confused, my knowledge is that, an update in the ARP cache is only be done by an ARP request. This tells us RFC 826. So the gratuitous ARP, which is a ARP request with special parameters, will be used to 1. detect a already used IP address and 2. to update the ARP cache of the hosts/routers on the client's subnet Hans-Hermann -----Ursprungliche Nachricht----- Von: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org]Im Auftrag von John Schnizlein Gesendet: Mittwoch, 7. Juli 2004 21:11 An: babatke@ra.rockwell.com Cc: dhcwg@ietf.org Betreff: Re: [dhcwg] Gratuitous ARP in DHCP vs. IPv4 ACD Draft Just before the section of the RFC you quoted is the part that recommends that the client issue an ARP request to discover if the address is already in use. This part seems most like the conflict detection part of ZeroConf. The part you quoted is there for the case when there is no other host with the address in question, but there might have been previously. That is why the (other host's) ARP caches are cleared. The combination of both the request and the reply, which is clearer from the longer context of the text, first checks for a duplicate address, then provides other hosts a cache update for the host newly using the address. The broader context of the specification quoted here for convenience: The client SHOULD perform a check on the suggested address to ensure that the address is not already in use. For example, if the client is on a network that supports ARP, the client may issue an ARP request for the suggested request. When broadcasting an ARP request for the suggested address, the client must fill in its own hardware address as the sender's hardware address, and 0 as the sender's IP address, to avoid confusing ARP caches in other hosts on the same subnet. If the network address appears to be in use, the client MUST send a DHCPDECLINE message to the server. The client SHOULD broadcast an ARP reply to announce the client's new IP address and clear any outdated ARP cache entries in hosts on the client's subnet. John At 08:54 AM 7/7/2004, babatke@ra.rockwell.com wrote: >RFC 2131, in section 4.4.1 says that "The client SHOULD broadcast an ARP reply to announce the client's new IP address ..." > >This is the so-called 'gratuitous ARP'. > >The Internet Draft for IPv4 Address Conflict Detection (http://files.stuartcheshire.org/draft-cheshire-ipv4-acd-00.txt) refers to this as an "ARP announcement" and defines it as an ARP request rather than a reply. This definition is also in other Zeroconf drafts. > >In products I have looked at (with BSD-derived stacks) it seems that the gratuitous ARP is sent as a request (except when it is sent by the DHCP client). > > >Is there a need for consistency across the various mechanisms? (DHCP client, IPv4 ACD, IPv4 Link Local, etc.)? > >Brian Batke >Rockwell Automation >_______________________________________________ >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 Jul 7 22:17: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 WAA05773; Wed, 7 Jul 2004 22:17: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 1BiMiX-0000XJ-J2; Wed, 07 Jul 2004 20:24:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BiL7r-0002Ku-TG for dhcwg@megatron.ietf.org; Wed, 07 Jul 2004 18:42:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25099 for ; Wed, 7 Jul 2004 18:42:43 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BiL7l-00072Y-FX for dhcwg@ietf.org; Wed, 07 Jul 2004 18:42:45 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BiL6n-0006go-00 for dhcwg@ietf.org; Wed, 07 Jul 2004 18:41:46 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx with esmtp (Exim 4.12) id 1BiL5i-00064D-00 for dhcwg@ietf.org; Wed, 07 Jul 2004 18:40:38 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 07 Jul 2004 18:49:16 -0400 X-BrightmailFiltered: true Received: from jschnizl-w2k.cisco.com (rtp-vpn2-15.cisco.com [10.82.240.15]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i67MdwaJ010097; Wed, 7 Jul 2004 18:40:06 -0400 (EDT) Message-Id: <4.3.2.7.2.20040707181321.026cdec0@wells.cisco.com> X-Sender: jschnizl@wells.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 07 Jul 2004 18:40:59 -0400 To: "Hans-Hermann Krost" From: John Schnizlein Subject: Re: AW: [dhcwg] Gratuitous ARP in DHCP vs. IPv4 ACD Draft In-Reply-To: References: <4.3.2.7.2.20040707150440.02dbf6f8@wells.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Cc: dhcwg@ietf.org, babatke@ra.rockwell.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 Sorry for the confusion. ARP is unfortunately a constant source of it. First, regarding "update in the ARP cache is only be done by an ARP request" note that RFC 826 explicitly does not discriminate between request or reply messages before updating its table: " When an address resolution packet is received, the receiving Ethernet module gives the packet to the Address Resolution module which goes through an algorithm similar to the following. Negative conditionals indicate an end of processing and a discarding of the packet. ?Do I have the hardware type in ar$hrd? Yes: (almost definitely) [optionally check the hardware length ar$hln] ?Do I speak the protocol in ar$pro? Yes: [optionally check the protocol length ar$pln] Merge_flag := false If the pair is already in my translation table, update the sender hardware address field of the entry with the new information in the packet and set Merge_flag to true. ?Am I the target protocol address? Yes: If Merge_flag is false, add the triplet to the translation table. ?Is the opcode ares_op$REQUEST? (NOW look at the opcode!!) Yes: Swap hardware and protocol fields, putting the local hardware and protocol addresses in the sender fields. Set the ar$op field to ares_op$REPLY Send the packet to the (new) target hardware address on the same hardware on which the request was received. Notice that the triplet is merged into the table before the opcode is looked at. This is on the assumption that communication is bidirectional; if A has some reason to talk to B, then B will " This fact, and an implementation wrinkle, led to the common practice that ARP processes usually "glean" IP-to-MAC mappings even when they are not party to the request. The implementation wrinkle is that many host protocol stacks send replies to the broadcast hardware address rather than unicast to the requester's MAC address. The operational fact (despite the clear specification above) that replies are broadcast led to the recommendation that the DHCP client complete the request-reply of as-practiced ARP to update (possibly "gleaned") ARP entries in the other hosts on the subnet. I have never understood what the special terminology of "gratuitous ARP" meant, and suspect its meaning morphed over time. The DHCP specification was intended to facilitate communication, given the practices encoded in host protocol stacks at the time. Now, we should either continue to respect this tradition of making things work (despite traditional loose implementation) or fix ARP. If we were to fix ARP now, in the age of ethernet switches rather than the physical broadcast of fat, yellow ethernet cables, I would focus the fix on the behavior of switches to accommodate existing hosts. The reason is that it is not nice to break the host that has been working for years without any upgrade to its legacy stack. The worst action of the IETF would be to break existing implementations in pursuit of new protocol ideas. John At 05:34 PM 7/7/2004, Hans-Hermann Krost wrote: >Now I am confused, > >my knowledge is that, an update in the ARP cache is only be done by an ARP >request. This tells us RFC 826. > >So the gratuitous ARP, which is a ARP request with special parameters, will >be used to >1. detect a already used IP address and >2. to update the ARP cache of the hosts/routers on the client's subnet > >Hans-Hermann > >von John Schnizlein > >Just before the section of the RFC you quoted is the part that >recommends that the client issue an ARP request to discover if >the address is already in use. This part seems most like the >conflict detection part of ZeroConf. > >The part you quoted is there for the case when there is no other >host with the address in question, but there might have been >previously. That is why the (other host's) ARP caches are >cleared. > >The combination of both the request and the reply, which is >clearer from the longer context of the text, first checks for >a duplicate address, then provides other hosts a cache update >for the host newly using the address. > >The broader context of the specification quoted here for >convenience: > > The client SHOULD perform a > check on the suggested address to ensure that the address is not > already in use. For example, if the client is on a network that > supports ARP, the client may issue an ARP request for the suggested > request. When broadcasting an ARP request for the suggested address, > the client must fill in its own hardware address as the sender's > hardware address, and 0 as the sender's IP address, to avoid > confusing ARP caches in other hosts on the same subnet. If the > network address appears to be in use, the client MUST send a > DHCPDECLINE message to the server. The client SHOULD broadcast an ARP > reply to announce the client's new IP address and clear any outdated > ARP cache entries in hosts on the client's subnet. > >John > >At 08:54 AM 7/7/2004, babatke@ra.rockwell.com wrote: > >>RFC 2131, in section 4.4.1 says that "The client SHOULD broadcast an ARP >reply to announce the client's new IP address ..." >> >>This is the so-called 'gratuitous ARP'. >> >>The Internet Draft for IPv4 Address Conflict Detection >(http://files.stuartcheshire.org/draft-cheshire-ipv4-acd-00.txt) refers to >this as an "ARP announcement" and defines it as an ARP request rather than a >reply. This definition is also in other Zeroconf drafts. >> >>In products I have looked at (with BSD-derived stacks) it seems that the >gratuitous ARP is sent as a request (except when it is sent by the DHCP >client). >> >> >>Is there a need for consistency across the various mechanisms? (DHCP >client, IPv4 ACD, IPv4 Link Local, etc.)? >> >>Brian Batke >>Rockwell Automation _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Jul 7 23:29: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 XAA08704; Wed, 7 Jul 2004 23:29: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 1BiNwN-0007rd-MV; Wed, 07 Jul 2004 21:43:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BiLph-0004oi-JK for dhcwg@megatron.ietf.org; Wed, 07 Jul 2004 19:28:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27596 for ; Wed, 7 Jul 2004 19:28:00 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BiLpb-0006GX-2d for dhcwg@ietf.org; Wed, 07 Jul 2004 19:28:03 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BiLop-0005vn-00 for dhcwg@ietf.org; Wed, 07 Jul 2004 19:27:16 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx with esmtp (Exim 4.12) id 1BiLnq-0005Qj-00 for dhcwg@ietf.org; Wed, 07 Jul 2004 19:26:14 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 07 Jul 2004 19:25:00 -0400 X-BrightmailFiltered: true Received: from jschnizl-w2k.cisco.com (rtp-vpn2-15.cisco.com [10.82.240.15]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i67NPeaJ014426; Wed, 7 Jul 2004 19:25:42 -0400 (EDT) Message-Id: <4.3.2.7.2.20040707185643.02e003a0@wells.cisco.com> X-Sender: jschnizl@wells.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 07 Jul 2004 19:11:02 -0400 To: babatke@ra.rockwell.com From: John Schnizlein Subject: Re: [dhcwg] Gratuitous ARP in DHCP vs. IPv4 ACD Draft In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 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 guess I am missing the value of formality that distinguishes between the "probe" ARP-request and the "announce" ARP-request. The DHCP specification of an ARP-request followed by an ARP-reply always made sense to me. "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. John At 03:53 PM 7/7/2004, babatke@ra.rockwell.com wrote: >> Just before the section of the RFC you quoted >> is the part that recommends that the client issue >> an ARP request to discover if the address is already >> in use. This part seems most like the >> conflict detection part of ZeroConf. > >Yes, this is the ARP "probe" that is more formalized >in the IPv4 ACD document. > >> The part you quoted is there for the case when there >> is no other host with the address in question, but there >> might have been previously. That is why the (other host's) >> ARP caches are cleared. > >The IPv4 ACD document calls this an ARP "announcement". >And the behavior is the same -- after probing for an >address and finding no conflict, you issue an ARP >request for your own address, which causes ARP >caches to be updated. (except the DHCP RFC >says reply not request ... hence my question). > >> The combination of both the request and the reply, >> which is clearer from the longer context of the text, >> first checks for a duplicate address, then provides other >> hosts a cache update for the host newly using the address. > >Which is what the IPv4 ACD mechanism does ... but in a more >well-defined way, and it also includes 'ongoing conflict >detection and defense". _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Thu Jul 8 01:57: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 BAA15592; Thu, 8 Jul 2004 01: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 1BiQtR-0002BS-OY; Thu, 08 Jul 2004 00:52:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BiPgy-0007Q6-P8 for dhcwg@megatron.ietf.org; Wed, 07 Jul 2004 23:35:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA08996 for ; Wed, 7 Jul 2004 23:35:16 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BiPgs-0007kM-0b for dhcwg@ietf.org; Wed, 07 Jul 2004 23:35:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BiPfn-0007Q0-00 for dhcwg@ietf.org; Wed, 07 Jul 2004 23:34:12 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BiPfN-00076A-00 for dhcwg@ietf.org; Wed, 07 Jul 2004 23:33:45 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 07 Jul 2004 20:39:36 +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 i683XC4N013959; Wed, 7 Jul 2004 20:33:13 -0700 (PDT) Received: from volzw2k (rtp-vpn2-158.cisco.com [10.82.240.158]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AJZ00193; Wed, 7 Jul 2004 23:33:11 -0400 (EDT) From: "Bernie Volz" To: "'Hans-Hermann Krost'" , "'John Schnizlein'" , Subject: RE: [dhcwg] Gratuitous ARP in DHCP vs. IPv4 ACD Draft Date: Wed, 7 Jul 2004 23:34:16 -0400 Organization: Cisco Message-ID: <001601c4649c$721aa0c0$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: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4939.300 Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 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 Hans: You are not correct. See RFC 826: ?Do I have the hardware type in ar$hrd? Yes: (almost definitely) [optionally check the hardware length ar$hln] ?Do I speak the protocol in ar$pro? Yes: [optionally check the protocol length ar$pln] Merge_flag :=3D false If the pair is already in my translation table, update the sender hardware address field of the entry with the new information in the packet and set Merge_flag to true.=20 ?Am I the target protocol address? Yes: If Merge_flag is false, add the triplet to the translation table. ?Is the opcode ares_op$REQUEST? (NOW look at the opcode!!) The cache will be updated for *EITHER* a request or reply because the = opcode isn't checked until much later. So, either a REQUEST or REPLY will work. However, the REQUEST sent = during the probe is not a normal REQUEST as it is sent with "0 as the sender's = IP address". So, that's why the REPLY is needed (and why send a REQUEST = when the host isn't looking for any information). - Bernie > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org]=20 > On Behalf Of Hans-Hermann Krost > Sent: Wednesday, July 07, 2004 5:35 PM > To: John Schnizlein; babatke@ra.rockwell.com > Cc: dhcwg@ietf.org > Subject: AW: [dhcwg] Gratuitous ARP in DHCP vs. IPv4 ACD Draft >=20 >=20 > Now I am confused, >=20 > my knowledge is that, an update in the ARP cache is only be=20 > done by an ARP request. This tells us RFC 826. >=20 > So the gratuitous ARP, which is a ARP request with special=20 > parameters, will be used to 1. detect a already used IP=20 > address and 2. to update the ARP cache of the hosts/routers=20 > on the client's subnet >=20 > Hans-Hermann >=20 >=20 >=20 > -----Ursprungliche Nachricht----- > Von: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org]Im=20 > Auftrag von John Schnizlein > Gesendet: Mittwoch, 7. Juli 2004 21:11 > An: babatke@ra.rockwell.com > Cc: dhcwg@ietf.org > Betreff: Re: [dhcwg] Gratuitous ARP in DHCP vs. IPv4 ACD Draft >=20 >=20 > Just before the section of the RFC you quoted is the part=20 > that recommends that the client issue an ARP request to=20 > discover if the address is already in use. This part seems=20 > most like the conflict detection part of ZeroConf. >=20 > The part you quoted is there for the case when there is no=20 > other host with the address in question, but there might have=20 > been previously. That is why the (other host's) ARP caches=20 > are cleared. >=20 > The combination of both the request and the reply, which is=20 > clearer from the longer context of the text, first checks for=20 > a duplicate address, then provides other hosts a cache update=20 > for the host newly using the address. >=20 > The broader context of the specification quoted here for > convenience: >=20 > The client SHOULD perform a > check on the suggested address to ensure that the address is not > already in use. For example, if the client is on a network that > supports ARP, the client may issue an ARP request for the suggested > request. When broadcasting an ARP request for the=20 > suggested address, > the client must fill in its own hardware address as the sender's > hardware address, and 0 as the sender's IP address, to avoid > confusing ARP caches in other hosts on the same subnet. If the > network address appears to be in use, the client MUST send a > DHCPDECLINE message to the server. The client SHOULD=20 > broadcast an ARP > reply to announce the client's new IP address and clear=20 > any outdated > ARP cache entries in hosts on the client's subnet. >=20 > John >=20 > At 08:54 AM 7/7/2004, babatke@ra.rockwell.com wrote: >=20 > >RFC 2131, in section 4.4.1 says that "The client SHOULD broadcast an=20 > >ARP > reply to announce the client's new IP address ..." > > > >This is the so-called 'gratuitous ARP'. > > > >The Internet Draft for IPv4 Address Conflict Detection > (http://files.stuartcheshire.org/draft-cheshire-ipv4-acd-00.tx t) refers to this as an "ARP announcement" and defines it as an ARP = request rather than a reply. This definition is also in other Zeroconf drafts. > >In products I have looked at (with BSD-derived stacks) it seems that=20 >the gratuitous ARP is sent as a request (except when it is sent by the DHCP client). > > >Is there a need for consistency across the various mechanisms? (DHCP client, IPv4 ACD, IPv4 Link Local, etc.)? > >Brian Batke >Rockwell Automation _______________________________________________ >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 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Thu Jul 8 02: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 CAA17585; Thu, 8 Jul 2004 02:01: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 1BiQvA-0002fS-Jq; Thu, 08 Jul 2004 00:54:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BiPpU-0001Iz-76 for dhcwg@megatron.ietf.org; Wed, 07 Jul 2004 23:44:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA09528 for ; Wed, 7 Jul 2004 23:44:03 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BiPpN-00030s-6s for dhcwg@ietf.org; Wed, 07 Jul 2004 23:44:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BiPoW-0002hn-00 for dhcwg@ietf.org; Wed, 07 Jul 2004 23:43:13 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BiPo2-0002Ns-00 for dhcwg@ietf.org; Wed, 07 Jul 2004 23:42:42 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 07 Jul 2004 20:48:33 +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 i683g9Sc002407; Wed, 7 Jul 2004 20:42:10 -0700 (PDT) Received: from volzw2k (rtp-vpn2-158.cisco.com [10.82.240.158]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AJZ00418; Wed, 7 Jul 2004 23:42:07 -0400 (EDT) From: "Bernie Volz" To: "'Mayumi Yanagiya'" , Subject: RE: [dhcwg] identifier for key selection Date: Wed, 7 Jul 2004 23:43:15 -0400 Organization: Cisco Message-ID: <001701c4649d$b3b4a520$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: <40EA9D5B.1060308@lab.ntt.co.jp> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4939.300 Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 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: Regarding the first question: As defined in RFC 3315: DHCP realm A name used to identify the DHCP administrative domain from which a DHCP authentication key was selected. So, both the realm and the client's DUID would be used to obtain the = key. If the received realm doesn't match the server's or one of the server's, = the server needn't bother looking for a key? Instead, it might send its realm to the client in an Advertise? Regarding the second, where do you want to put this identifier? The = Client Identifier must be a DUID that follows one of the formats given in the document. New formats could be defined. The Client Identifier is = supposed to represent the client (hardware), not the user (though often there is = only one user for each client). There's also the possibility of defining new options to carry user, subscriber, etc information similar to what has = been done for DHCPv4 (see the various Relay Agent suboptions). - Bernie > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org]=20 > On Behalf Of Mayumi Yanagiya > Sent: Tuesday, July 06, 2004 8:39 AM > To: dhcwg@ietf.org > Subject: [dhcwg] identifier for key selection >=20 >=20 > Hello, >=20 > I have some question about DHCP authentication. >=20 > 1. Which identifier does DHCP server use to select a key for client? > In 21.4.5, it is specified that the server selects a key for client, > based on the "client's DUID" and key selection policies. > But in 21.4.1, it seems that the "DHCP realm" is used to identify > authentication key. > Which identifier does the server use? >=20 > 2. Can we use user identifier, such as NAI, as DUID? > In section 9, it is specified that DHCP servers use DUID to > identify "clients". > Does the "clients" mean only hardware such as NIC? >=20 > Regards, > -Mayumi >=20 >=20 >=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 Thu Jul 8 08:37: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 IAA17447; Thu, 8 Jul 2004 08:37: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 1BiXS1-0007qS-43; Thu, 08 Jul 2004 07:52:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BiWyv-0005xk-Sk for dhcwg@megatron.ietf.org; Thu, 08 Jul 2004 07:22:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14011 for ; Thu, 8 Jul 2004 07:22:19 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BiWyq-0000cU-ES for dhcwg@ietf.org; Thu, 08 Jul 2004 07:22:20 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BiWxr-0000Ij-00 for dhcwg@ietf.org; Thu, 08 Jul 2004 07:21:20 -0400 Received: from tama5.ecl.ntt.co.jp ([129.60.39.102]) by ietf-mx with esmtp (Exim 4.12) id 1BiWwm-0007YF-00 for dhcwg@ietf.org; Thu, 08 Jul 2004 07:20:12 -0400 Received: from vcs3.rdh.ecl.ntt.co.jp (vcs3.rdh.ecl.ntt.co.jp [129.60.39.110]) by tama5.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id i68BK5fr024382; Thu, 8 Jul 2004 20:20:05 +0900 (JST) Received: from mfs3.rdh.ecl.ntt.co.jp (localhost [127.0.0.1]) by vcs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id i68BK50O025893; Thu, 8 Jul 2004 20:20:05 +0900 (JST) Received: from mfs3.rdh.ecl.ntt.co.jp (localhost [127.0.0.1]) by mfs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id i68BK467000953; Thu, 8 Jul 2004 20:20:04 +0900 (JST) Received: from nttmail3.ecl.ntt.co.jp ([129.60.39.100]) by mfs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id i68BK46V000950; Thu, 8 Jul 2004 20:20:04 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (eclscan3.m.ecl.ntt.co.jp [129.60.5.69]) by nttmail3.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id i68BK4aX007194; Thu, 8 Jul 2004 20:20:04 +0900 (JST) Received: from ime.m.ecl.ntt.co.jp (localhost [127.0.0.1]) by eclscan3.m.ecl.ntt.co.jp (8.9.3p2/3.7W) with ESMTP id UAA22805; Thu, 8 Jul 2004 20:20:03 +0900 (JST) Received: from lab.ntt.co.jp by ime.m.ecl.ntt.co.jp (8.9.3p2/3.7W) with ESMTP id UAA13100; Thu, 8 Jul 2004 20:20:02 +0900 (JST) Message-ID: <40ED2E92.5070108@lab.ntt.co.jp> Date: Thu, 08 Jul 2004 20:22:58 +0900 From: Mayumi Yanagiya User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja MIME-Version: 1.0 To: Bernie Volz , dhcwg@ietf.org Subject: Re: [dhcwg] identifier for key selection References: <001701c4649d$b3b4a520$6401a8c0@amer.cisco.com> In-Reply-To: <001701c4649d$b3b4a520$6401a8c0@amer.cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by tama5.ecl.ntt.co.jp id i68BK5fr024382 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 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 Hello Bernie, Thank you for your comments. Bernie Volz wrote: > Hi: >=20 > Regarding the first question: >=20 > As defined in RFC 3315: >=20 > DHCP realm A name used to identify the DHCP > administrative domain from which a DHCP > authentication key was selected. >=20 > So, both the realm and the client's DUID would be used to obtain the ke= y. If > the received realm doesn't match the server's or one of the server's, t= he > server needn't bother looking for a key? >=20 > Instead, it might send its realm to the client in an Advertise? I see. > Regarding the second, where do you want to put this identifier? The Cli= ent > Identifier must be a DUID that follows one of the formats given in the > document. New formats could be defined. The Client Identifier is suppos= ed to > represent the client (hardware), not the user (though often there is on= ly > one user for each client). There's also the possibility of defining new > options to carry user, subscriber, etc information similar to what has = been > done for DHCPv4 (see the various Relay Agent suboptions). I want to authenticate not hardware but user. Because, when we authenticate user, users are allowed to change hardware=20 without reporting the change to administrator. I think that it is very=20 convenience for user and administrator.So I=92m looking for an identifier= =20 that I can use as user identifier. When I use suboption such as subscriber-ID specified in draft-ietf-dhc-subscriber-id-06.txt,can I use the suboption to select=20 the client's key? Thanks, --Mayumi _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Thu Jul 8 10:05: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 KAA22502; Thu, 8 Jul 2004 10:05: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 1BiYk0-0006yg-8X; Thu, 08 Jul 2004 09:15:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BiY2n-0002GF-Dy for dhcwg@megatron.ietf.org; Thu, 08 Jul 2004 08:30:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16977 for ; Thu, 8 Jul 2004 08:30:22 -0400 (EDT) From: babatke@ra.rockwell.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BiY2h-0006IE-Lt for dhcwg@ietf.org; Thu, 08 Jul 2004 08:30:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BiY0V-0005Va-00 for dhcwg@ietf.org; Thu, 08 Jul 2004 08:28:08 -0400 Received: from mkedef1.rockwellautomation.com ([208.22.104.18] helo=raclesmtp01.ra.rockwell.com) by ietf-mx with esmtp (Exim 4.12) id 1BiXyr-0004j5-00 for dhcwg@ietf.org; Thu, 08 Jul 2004 08:26:25 -0400 To: John Schnizlein Subject: Re: [dhcwg] Gratuitous ARP in DHCP vs. IPv4 ACD Draft MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.10 March 22, 2002 Message-ID: Date: Thu, 8 Jul 2004 08:26:11 -0400 X-MIMETrack: Serialize by Router on RACleSMTP01/Cleveland/RA/Rockwell(Release 5.0.11 |July 24, 2002) at 07/08/2004 08:26:24 AM, Serialize complete at 07/08/2004 08:26:24 AM X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.7 required=5.0 tests=AWL,HTML_20_30,HTML_MESSAGE, NO_REAL_NAME autolearn=no version=2.60 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: , Content-Type: multipart/mixed; boundary="===============1266130667==" Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org This is a multipart message in MIME format. --===============1266130667== Content-Type: multipart/alternative; boundary="=_alternative 004445E685256ECB_=" This is a multipart message in MIME format. --=_alternative 004445E685256ECB_= Content-Type: text/plain; charset="us-ascii" > I guess I am missing the value of formality that > distinguishes between the "probe" ARP-request and the > "announce" ARP-request. The DHCP specification of an > ARP-request followed by an ARP-reply always made sense > to me. Not trying to turn this into a discussion/critique of the IPv4 ACD mechanism ... but the ARP "probe" is an ARP request with the sender IP address set to all 0, so that other hosts' ARP caches aren't affected. The "announce" message then has the sender IP filled in (and so, when sent after the probing finds no conflict, results in ARP caches being updated). > "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. Again ... don't want to critique the ACD mechanism, but it's not really much overhead to do ongoing detection. You just have to recognize that another host has issued an ARP with your address. To give this some DHCP context ... in the industrial application space (which is where I work), it is a very real possibility to have a mixed network, where some devices get addresses via DHCP, and some have addresses manually configured (e.g., if the device doesn't support DHCP). And in an industrial control application, address conflicts can be a serious problem. Therefore, even devices who obtain their addresses via a DHCP server need to be able to detect address conflicts and take an action that is appropriate for the application. Stuart Cheshire's mechanism seems to make sense. Brian Batke Rockwell Automation --=_alternative 004445E685256ECB_= Content-Type: text/html; charset="us-ascii"
> I guess I am missing the value of formality that
> distinguishes between the "probe" ARP-request and the
> "announce" ARP-request. The DHCP specification of an
> ARP-request followed by an ARP-reply always made sense
> to me.

Not trying to turn this into a discussion/critique of
the IPv4 ACD mechanism ... but the ARP "probe" is an ARP
request with the sender IP address set to all 0, so that
other hosts' ARP caches aren't affected.  The "announce"
message then has the sender IP filled in (and so, when sent
after the probing finds no conflict, results in ARP
caches being updated).


> "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.

Again ... don't want to critique the ACD mechanism, but it's not
really much overhead to do ongoing detection.  You just have to
recognize that another host has issued an ARP with your address.

To give this some DHCP context ... in the industrial application
space (which is where I work), it is a very real possibility
to have a mixed network, where some devices get addresses via DHCP,
and some have addresses manually configured (e.g., if the device
doesn't support DHCP).

And in an industrial control application, address conflicts can
be a serious problem.  Therefore, even devices who obtain their
addresses via a DHCP server need to be able to detect address
conflicts and take an action that is appropriate for the
application.   Stuart Cheshire's mechanism seems to make sense.

Brian Batke
Rockwell Automation
--=_alternative 004445E685256ECB_=-- --===============1266130667== 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 --===============1266130667==-- From dhcwg-bounces@ietf.org Thu Jul 8 11:06: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 LAA28985; Thu, 8 Jul 2004 11:06: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 1BiZz8-0003GE-Ja; Thu, 08 Jul 2004 10:34:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BiZBZ-0007QL-Hy for dhcwg@megatron.ietf.org; Thu, 08 Jul 2004 09:43:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21263 for ; Thu, 8 Jul 2004 09:43:30 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BiZBT-0005ir-Su for dhcwg@ietf.org; Thu, 08 Jul 2004 09:43:31 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BiZAY-0005OQ-00 for dhcwg@ietf.org; Thu, 08 Jul 2004 09:42:34 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BiZ9W-0004lg-00 for dhcwg@ietf.org; Thu, 08 Jul 2004 09:41:30 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-1.cisco.com with ESMTP; 08 Jul 2004 06:42:06 -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 i68Deu4N023549; Thu, 8 Jul 2004 06:40:56 -0700 (PDT) Received: from volzw2k (rtp-vpn2-158.cisco.com [10.82.240.158]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AJZ20184; Thu, 8 Jul 2004 09:40:54 -0400 (EDT) From: "Bernie Volz" To: "'Mayumi Yanagiya'" , Subject: RE: [dhcwg] identifier for key selection Date: Thu, 8 Jul 2004 09:42:00 -0400 Organization: Cisco Message-ID: <002501c464f1$58cccfd0$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: <40ED2E92.5070108@lab.ntt.co.jp> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4939.300 Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 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 >I want to authenticate not hardware but user. Well, DHCP is the Dynamic Host Configuration Protocol. In many cases when DHCP starts there is no user (yet), or DHCP is being used by systems that are multi-user. But, I understand your desire to do this. And, there's always the ability to define additional authentication protocols. - Bernie > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] > On Behalf Of Mayumi Yanagiya > Sent: Thursday, July 08, 2004 7:23 AM > To: Bernie Volz; dhcwg@ietf.org > Subject: Re: [dhcwg] identifier for key selection > > > Hello Bernie, > > Thank you for your comments. > > Bernie Volz wrote: > > > Hi: > > > > Regarding the first question: > > > > As defined in RFC 3315: > > > > DHCP realm A name used to identify the DHCP > > administrative domain from > which a DHCP > > authentication key was selected. > > > > So, both the realm and the client's DUID would be used to > obtain the > > key. If the received realm doesn't match the server's or one of the > > server's, the server needn't bother looking for a key? > > > > Instead, it might send its realm to the client in an Advertise? > > I see. > > > Regarding the second, where do you want to put this identifier? The > > Client Identifier must be a DUID that follows one of the > formats given > > in the document. New formats could be defined. The Client > Identifier > > is supposed to represent the client (hardware), not the > user (though > > often there is only one user for each client). There's also the > > possibility of defining new options to carry user, subscriber, etc > > information similar to what has been done for DHCPv4 (see > the various > > Relay Agent suboptions). > > I want to authenticate not hardware but user. > Because, when we authenticate user, users are allowed to > change hardware > without reporting the change to administrator. I think that > it is very > convenience for user and administrator.So I'm looking for an > identifier > that I can use as user identifier. > > When I use suboption such as subscriber-ID specified in > draft-ietf-dhc-subscriber-id-06.txt,can I use the suboption to select > the client's key? > > > Thanks, > --Mayumi > > > > > _______________________________________________ > 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 Jul 8 16:13: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 QAA25186; Thu, 8 Jul 2004 16:13: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 1BibIj-0008N1-Vo; Thu, 08 Jul 2004 11:59:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BiZ10-0003eI-Ag for dhcwg@megatron.ietf.org; Thu, 08 Jul 2004 09:32:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20870 for ; Thu, 8 Jul 2004 09:32:35 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BiZ0u-000273-Lp for dhcwg@ietf.org; Thu, 08 Jul 2004 09:32:36 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BiYzr-0001nN-00 for dhcwg@ietf.org; Thu, 08 Jul 2004 09:31:32 -0400 Received: from maileu.alliedtelesyn.com ([81.116.95.49] helo=alliedtelesyn.com) by ietf-mx with esmtp (Exim 4.12) id 1BiYzN-0001Tu-00 for dhcwg@ietf.org; Thu, 08 Jul 2004 09:31:01 -0400 Received: from svr-mila-e2k1.eu.alliedtelesyn.com ([10.17.39.17] RDNS failed) by alliedtelesyn.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 8 Jul 2004 15:25:19 +0200 Received: from svr-mila-fs3.eu.alliedtelesyn.com ([10.17.90.11]) by svr-mila-e2k1.eu.alliedtelesyn.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 8 Jul 2004 15:30:28 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 8 Jul 2004 15:30:28 +0200 Message-ID: Thread-Topic: DHCP OFFER/VALIDATION Thread-Index: AcRk71uf14fqy8D8TtGKWFM+JXzRFQ== From: "Boffelli, Lorenzo" To: X-OriginalArrivalTime: 08 Jul 2004 13:30:29.0014 (UTC) FILETIME=[BC2B6B60:01C464EF] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_30_40,HTML_MESSAGE, LINES_OF_YELLING,LINES_OF_YELLING_2,SUBJ_ALL_CAPS autolearn=no version=2.60 X-Mailman-Approved-At: Thu, 08 Jul 2004 11:59:08 -0400 Cc: "Paradiso, Francesco" Subject: [dhcwg] DHCP OFFER/VALIDATION 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="===============1533312703==" Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org This is a multi-part message in MIME format. --===============1533312703== content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C464EF.BC0E9957" This is a multi-part message in MIME format. ------_=_NextPart_001_01C464EF.BC0E9957 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, When a client receive a OFFER ACK message it must check the transaction = ID. Why the field chaddr must not be validate? I have a case in which two different clients generate the same = transaction ID. OK I am very unluky but this has happen. Both the clients accepts the OFFERs and the ACKs sent in broadcast and = get the same IP address. If the clients would check the chaddr before accepting a message this = would not be occured. There are some unknow (to me) side effects created by a clients that = execs this check of the chaddr field? Thank you Lorenzo Lorenzo Boffelli ------------------------------------------=20 Integration Test Group Leader=20 Allied Telesis Multimedia S.r.l. P.zza Tirana 24/4B - 20147 Milano MI - Italy Office +39 02 41411237 (ext. 37) Fax +39 02 41411261=20 ------_=_NextPart_001_01C464EF.BC0E9957 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable DHCP OFFER/VALIDATION

Hello,
When a client receive a OFFER ACK = message it must check the transaction ID.
Why the field chaddr must not be = validate?

I have a case in which two different = clients generate the same transaction ID. OK I am very unluky but this = has happen.
Both the clients accepts the OFFERs = and the ACKs sent in broadcast and get the same IP address.
If the clients would check the chaddr = before accepting a message this would not be occured.

There are some unknow (to me) side = effects created by a clients that execs this check of the chaddr = field?
Thank you
Lorenzo

Lorenzo Boffelli
------------------------------------------
Integration Test Group Leader

Allied Telesis Multimedia = S.r.l.
P.zza Tirana 24/4B - 20147 Milano MI - Italy

Office +39 02 41411237 (ext. 37)
Fax +39 02 41411261

------_=_NextPart_001_01C464EF.BC0E9957-- --===============1533312703== 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 --===============1533312703==-- From dhcwg-bounces@ietf.org Thu Jul 8 20:00: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 UAA15494; Thu, 8 Jul 2004 20:00: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 1Bii77-0005EH-QJ; Thu, 08 Jul 2004 19:15:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bifyu-0006dq-VQ for dhcwg@megatron.ietf.org; Thu, 08 Jul 2004 16:59:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28049 for ; Thu, 8 Jul 2004 16:58:53 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bifyo-0005RX-Kf for dhcwg@ietf.org; Thu, 08 Jul 2004 16:58:54 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bifxs-000550-00 for dhcwg@ietf.org; Thu, 08 Jul 2004 16:57:57 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1Bifx8-0004Z8-00 for dhcwg@ietf.org; Thu, 08 Jul 2004 16:57:10 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 08 Jul 2004 13:05:36 +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 i68Jx64N002997 for ; Thu, 8 Jul 2004 12:59:07 -0700 (PDT) Received: from rdroms-w2k01.cisco.com ([161.44.65.119]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AJZ55592; Thu, 8 Jul 2004 15:59:05 -0400 (EDT) Message-Id: <4.3.2.7.2.20040708155658.0290b6f8@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 08 Jul 2004 15:59:03 -0400 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [dhcwg] *DRAFT* Agenda for 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 Below is the draft scheduled time and agenda for the dhc WG meeting in San Diego. NOTE THAT THE MEETING DAY HAS CHANGED TO WEDNESDAY!! Let me know if you have additional items for the agenda. - Ralph ----- WEDNESDAY, August 4, 2004 0900-1130 Morning Sessions APP marid MTA Authorization Records in DNS WG INT dhc Dynamic Host Configuration WG OPS mboned MBONE Deployment WG * RTG pce Path Computation Element BOF SEC pkix Public Key Infrastructure WG TSV rddp Remote Direct Data Placement WG TSV sip Session Initiation Protocol WG ----- DHC WG agenda - IETF 60 0900 Wed 2004-08-04 (tentative) (Last revised 07/08/2004 03:45 PM) ---------------------------------- Administrivia Ralph Droms 05 minutes Agenda bashing DNS zone suffix option for DHCPv6 Renxiang Yan 10 minutes Accept as dhc WG work item? DHCPv4 Options for Broadcast and Multicast Control Servers K. Chowdhury 10 minutes Accept as dhc WG work item? DHCPv6 Options for Broadcast and Multicast Control Servers K. Chowdhury 10 minutes Accept as dhc WG work item? DHCP Option for Configuring IPv6-over-IPv4 Tunnels S. Daniel Park 10 minutes Accept as dhc WG work item? Configured Tunnel End-Point Configuration using DHCPv4 S. Daniel Park 10 minutes Accept as dhc WG work item? DHCP Option for Home Agent Discovery in MIPv6 Heejin Jang 10 minutes Accept as dhc WG work item? IPv6 multicast address assignment with DHCPv6 Jerome Durand 20 minutes Technical discussion Renumbering Requirements for Stateless DHCPv6 15 minutes Ready for WG last call? Lifetime Option for DHCPv6 15 minutes Ready for WG last call (depending on status of 'Renumbering Requirements')? IPv4 and IPv6 Dual-Stack Issues for DHCPv6 30 minutes Ready for WG last call? ----------- 145 minutes _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri Jul 9 02:55: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 CAA06896; Fri, 9 Jul 2004 02:55: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 1Biot5-0002D5-CN; Fri, 09 Jul 2004 02:29:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BioTa-0008LP-DS for dhcwg@megatron.ietf.org; Fri, 09 Jul 2004 02:03:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23503 for ; Fri, 9 Jul 2004 02:03:07 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BioTT-0007Mk-4T for dhcwg@ietf.org; Fri, 09 Jul 2004 02:03:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BioSS-00073l-00 for dhcwg@ietf.org; Fri, 09 Jul 2004 02:02:05 -0400 Received: from tyholt.uninett.no ([158.38.60.10]) by ietf-mx with esmtp (Exim 4.12) id 1BioRX-0006Qo-00 for dhcwg@ietf.org; Fri, 09 Jul 2004 02:01:07 -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 i6960RDW023427; Fri, 9 Jul 2004 08:00:27 +0200 Received: (from venaas@localhost) by sverresborg.uninett.no (8.12.8/8.12.8/Submit) id i6960OLl017846; Fri, 9 Jul 2004 08:00:24 +0200 X-Authentication-Warning: sverresborg.uninett.no: venaas set sender to Stig.Venaas@uninett.no using -f Date: Fri, 9 Jul 2004 08:00:24 +0200 From: Stig Venaas To: Ralph Droms Subject: Re: [dhcwg] *DRAFT* Agenda for dhc WG meeting in San Diego Message-ID: <20040709060024.GA17832@sverresborg.uninett.no> References: <4.3.2.7.2.20040708155658.0290b6f8@flask.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4.3.2.7.2.20040708155658.0290b6f8@flask.cisco.com> User-Agent: Mutt/1.4.1i X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 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 Thu, Jul 08, 2004 at 03:59:03PM -0400, Ralph Droms wrote: > Below is the draft scheduled time and agenda for the dhc WG meeting in San > Diego. NOTE THAT THE MEETING DAY HAS CHANGED TO WEDNESDAY!! Let me know if > you have additional items for the agenda. > > - Ralph > > ----- > WEDNESDAY, August 4, 2004 > 0900-1130 Morning Sessions > APP marid MTA Authorization Records in DNS WG > INT dhc Dynamic Host Configuration WG > OPS mboned MBONE Deployment WG * > RTG pce Path Computation Element BOF > SEC pkix Public Key Infrastructure WG > TSV rddp Remote Direct Data Placement WG > TSV sip Session Initiation Protocol WG There's a major problem here. This clashes with the mboned meeting and Jerome Durand is supposed to talk about his draft on IPv6 multicast address assignment with DHCPv6 in both meetings! I, and I suspect a few others, would also like to go to both meetings. Stig _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri Jul 9 04:10: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 EAA10152; Fri, 9 Jul 2004 04:10: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 1Bipw5-0005vC-AY; Fri, 09 Jul 2004 03:36:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BipZM-0001t6-6T for dhcwg@megatron.ietf.org; Fri, 09 Jul 2004 03:13:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07610 for ; Fri, 9 Jul 2004 03:13:09 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BipZE-0006L1-Uw for dhcwg@ietf.org; Fri, 09 Jul 2004 03:13:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BipYH-00062h-00 for dhcwg@ietf.org; Fri, 09 Jul 2004 03:12:10 -0400 Received: from raven.ecs.soton.ac.uk ([152.78.70.1]) by ietf-mx with esmtp (Exim 4.12) id 1BipXL-0005id-00 for dhcwg@ietf.org; Fri, 09 Jul 2004 03:11:11 -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 i697BCnE005127 for ; Fri, 9 Jul 2004 08:11:12 +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 IAA23835 for ; Fri, 9 Jul 2004 08:11:07 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id i697B7f05101 for dhcwg@ietf.org; Fri, 9 Jul 2004 08:11:07 +0100 Date: Fri, 9 Jul 2004 08:11:07 +0100 From: Tim Chown To: dhcwg@ietf.org Subject: Re: [dhcwg] *DRAFT* Agenda for dhc WG meeting in San Diego Message-ID: <20040709071107.GC4320@login.ecs.soton.ac.uk> Mail-Followup-To: dhcwg@ietf.org References: <4.3.2.7.2.20040708155658.0290b6f8@flask.cisco.com> <20040709060024.GA17832@sverresborg.uninett.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040709060024.GA17832@sverresborg.uninett.no> 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-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 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, Jul 09, 2004 at 08:00:24AM +0200, Stig Venaas wrote: > > ----- > > WEDNESDAY, August 4, 2004 > > 0900-1130 Morning Sessions > > APP marid MTA Authorization Records in DNS WG > > INT dhc Dynamic Host Configuration WG > > OPS mboned MBONE Deployment WG * > > RTG pce Path Computation Element BOF > > SEC pkix Public Key Infrastructure WG > > TSV rddp Remote Direct Data Placement WG > > TSV sip Session Initiation Protocol WG > > There's a major problem here. This clashes with the mboned meeting > and Jerome Durand is supposed to talk about his draft on IPv6 multicast > address assignment with DHCPv6 in both meetings! > > I, and I suspect a few others, would also like to go to both meetings. I certainly second that... Tim _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri Jul 9 06:04: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 GAA14734; Fri, 9 Jul 2004 06:04: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 1Birpg-0000cm-3g; Fri, 09 Jul 2004 05:38:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BircC-0006ae-Lg for dhcwg@megatron.ietf.org; Fri, 09 Jul 2004 05:24:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13274 for ; Fri, 9 Jul 2004 05:24:13 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Birc5-0000H7-9B for dhcwg@ietf.org; Fri, 09 Jul 2004 05:24:13 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Birb6-0007mR-00 for dhcwg@ietf.org; Fri, 09 Jul 2004 05:23:12 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx with esmtp (Exim 4.12) id 1Bira6-0007CX-00 for dhcwg@ietf.org; Fri, 09 Jul 2004 05:22:10 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 09 Jul 2004 05:24:33 -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 i699LdN9016397; Fri, 9 Jul 2004 05:21:39 -0400 (EDT) Received: from insbu-view1.cisco.com (insbu-view1.cisco.com [171.71.160.12]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AJZ88942; Fri, 9 Jul 2004 05:21:38 -0400 (EDT) Date: Fri, 9 Jul 2004 02:21:38 -0700 (PDT) From: Ralph Droms To: Stig Venaas Subject: Re: [dhcwg] *DRAFT* Agenda for dhc WG meeting in San Diego In-Reply-To: <20040709060024.GA17832@sverresborg.uninett.no> Message-ID: References: <4.3.2.7.2.20040708155658.0290b6f8@flask.cisco.com> <20040709060024.GA17832@sverresborg.uninett.no> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 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'll see if I can find us another time slot. Would Tue AM be OK: TUESDAY, August 3, 2004 0900-1130 Morning Sessions APP simple SIP for Instant Messaging and Presence Leveraging Extensions WG INT eap Extensible Authentication Protocol WG IRTF dtnrg Delay-tolerant Networking Research Group OPS psamp Packet Sampling WG RTG ccamp Common Control and Measurement Plane WG TSV avt Audio/Video Transport WG * TSV nfsv4 Network File System Version 4 WG - Ralph On Fri, 9 Jul 2004, Stig Venaas wrote: > On Thu, Jul 08, 2004 at 03:59:03PM -0400, Ralph Droms wrote: > > Below is the draft scheduled time and agenda for the dhc WG meeting in San > > Diego. NOTE THAT THE MEETING DAY HAS CHANGED TO WEDNESDAY!! Let me know if > > you have additional items for the agenda. > > > > - Ralph > > > > ----- > > WEDNESDAY, August 4, 2004 > > 0900-1130 Morning Sessions > > APP marid MTA Authorization Records in DNS WG > > INT dhc Dynamic Host Configuration WG > > OPS mboned MBONE Deployment WG * > > RTG pce Path Computation Element BOF > > SEC pkix Public Key Infrastructure WG > > TSV rddp Remote Direct Data Placement WG > > TSV sip Session Initiation Protocol WG > > There's a major problem here. This clashes with the mboned meeting > and Jerome Durand is supposed to talk about his draft on IPv6 multicast > address assignment with DHCPv6 in both meetings! > > I, and I suspect a few others, would also like to go to both meetings. > > 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 Fri Jul 9 06:35:19 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 GAA16264; Fri, 9 Jul 2004 06:35: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 1BisFs-00050O-Db; Fri, 09 Jul 2004 06:05:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BirzS-0002AI-Ke for dhcwg@megatron.ietf.org; Fri, 09 Jul 2004 05:48:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14131 for ; Fri, 9 Jul 2004 05:48:14 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BirzL-0007VJ-By for dhcwg@ietf.org; Fri, 09 Jul 2004 05:48:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BiryM-0007DM-00 for dhcwg@ietf.org; Fri, 09 Jul 2004 05:47:15 -0400 Received: from tama5.ecl.ntt.co.jp ([129.60.39.102]) by ietf-mx with esmtp (Exim 4.12) id 1BirxR-0006ue-00 for dhcwg@ietf.org; Fri, 09 Jul 2004 05:46:17 -0400 Received: from vcs3.rdh.ecl.ntt.co.jp (vcs3.rdh.ecl.ntt.co.jp [129.60.39.110]) by tama5.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id i699kBvX027510; Fri, 9 Jul 2004 18:46:11 +0900 (JST) Received: from mfs3.rdh.ecl.ntt.co.jp (localhost [127.0.0.1]) by vcs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id i699kAWf012906; Fri, 9 Jul 2004 18:46:10 +0900 (JST) Received: from mfs3.rdh.ecl.ntt.co.jp (localhost [127.0.0.1]) by mfs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id i699kAhI001001; Fri, 9 Jul 2004 18:46:10 +0900 (JST) Received: from nttmail3.ecl.ntt.co.jp ([129.60.39.100]) by mfs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id i699k9BL000998; Fri, 9 Jul 2004 18:46:09 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (eclscan3.m.ecl.ntt.co.jp [129.60.5.69]) by nttmail3.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id i699k9jr018549; Fri, 9 Jul 2004 18:46:09 +0900 (JST) Received: from ime.m.ecl.ntt.co.jp (localhost [127.0.0.1]) by eclscan3.m.ecl.ntt.co.jp (8.9.3p2/3.7W) with ESMTP id SAA04414; Fri, 9 Jul 2004 18:46:09 +0900 (JST) Received: from lab.ntt.co.jp by ime.m.ecl.ntt.co.jp (8.9.3p2/3.7W) with ESMTP id SAA14997; Fri, 9 Jul 2004 18:46:08 +0900 (JST) Message-ID: <40EE6A11.8060803@lab.ntt.co.jp> Date: Fri, 09 Jul 2004 18:49:05 +0900 From: Mayumi Yanagiya User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja MIME-Version: 1.0 To: Bernie Volz Subject: Re: [dhcwg] identifier for key selection References: <002501c464f1$58cccfd0$6401a8c0@amer.cisco.com> In-Reply-To: <002501c464f1$58cccfd0$6401a8c0@amer.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 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 Hi, Thanks for your comments. I try to make a problem statements draft. Regards, --Mayumi >>I want to authenticate not hardware but user. > > > Well, DHCP is the Dynamic Host Configuration Protocol. In many cases when > DHCP starts there is no user (yet), or DHCP is being used by systems that > are multi-user. But, I understand your desire to do this. And, there's > always the ability to define additional authentication protocols. > > - Bernie > > >>-----Original Message----- >>From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] >>On Behalf Of Mayumi Yanagiya >>Sent: Thursday, July 08, 2004 7:23 AM >>To: Bernie Volz; dhcwg@ietf.org >>Subject: Re: [dhcwg] identifier for key selection >> >> >>Hello Bernie, >> >>Thank you for your comments. >> >>Bernie Volz wrote: >> >> >>>Hi: >>> >>>Regarding the first question: >>> >>>As defined in RFC 3315: >>> >>> DHCP realm A name used to identify the DHCP >>> administrative domain from >> >>which a DHCP >> >>> authentication key was selected. >>> >>>So, both the realm and the client's DUID would be used to >> >>obtain the >> >>>key. If the received realm doesn't match the server's or one of the >>>server's, the server needn't bother looking for a key? >>> >>>Instead, it might send its realm to the client in an Advertise? >> >>I see. >> >> >>>Regarding the second, where do you want to put this identifier? The >>>Client Identifier must be a DUID that follows one of the >> >>formats given >> >>>in the document. New formats could be defined. The Client >> >>Identifier >> >>>is supposed to represent the client (hardware), not the >> >>user (though >> >>>often there is only one user for each client). There's also the >>>possibility of defining new options to carry user, subscriber, etc >>>information similar to what has been done for DHCPv4 (see >> >>the various >> >>>Relay Agent suboptions). >> >>I want to authenticate not hardware but user. >>Because, when we authenticate user, users are allowed to >>change hardware >>without reporting the change to administrator. I think that >>it is very >>convenience for user and administrator.So I'm looking for an >>identifier >>that I can use as user identifier. >> >>When I use suboption such as subscriber-ID specified in >>draft-ietf-dhc-subscriber-id-06.txt,can I use the suboption to select >>the client's key? >> >> >>Thanks, >>--Mayumi >> >> >> >> >>_______________________________________________ >>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 > -- *++++++++++++++++++++++++++++++++++++++++++ NTT Network Service Systems Laboratories Mayumi Yanagiya tel: +81 422 59 6783 fax: +81 422 37 7688 E-mail: yanagiya.mayumi@lab.ntt.co.jp +++++++++++++++++++++++++++++++++++++++++++* _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri Jul 9 07:09: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 HAA17720; Fri, 9 Jul 2004 07:09: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 1Bisiq-0002ic-QU; Fri, 09 Jul 2004 06:35:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BisMr-00067Y-Jh for dhcwg@megatron.ietf.org; Fri, 09 Jul 2004 06:12:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15021 for ; Fri, 9 Jul 2004 06:12:25 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BisMk-0006uY-6a for dhcwg@ietf.org; Fri, 09 Jul 2004 06:12:26 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BisLm-0006cJ-00 for dhcwg@ietf.org; Fri, 09 Jul 2004 06:11:27 -0400 Received: from tyholt.uninett.no ([158.38.60.10]) by ietf-mx with esmtp (Exim 4.12) id 1BisLK-0006KB-00 for dhcwg@ietf.org; Fri, 09 Jul 2004 06:10: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 i69AAFDW013701; Fri, 9 Jul 2004 12:10:15 +0200 Received: (from venaas@localhost) by sverresborg.uninett.no (8.12.8/8.12.8/Submit) id i69AAFIk018389; Fri, 9 Jul 2004 12:10:15 +0200 X-Authentication-Warning: sverresborg.uninett.no: venaas set sender to Stig.Venaas@uninett.no using -f Date: Fri, 9 Jul 2004 12:10:15 +0200 From: Stig Venaas To: Ralph Droms Subject: Re: [dhcwg] *DRAFT* Agenda for dhc WG meeting in San Diego Message-ID: <20040709101015.GA18299@sverresborg.uninett.no> References: <4.3.2.7.2.20040708155658.0290b6f8@flask.cisco.com> <20040709060024.GA17832@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-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 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, Jul 09, 2004 at 02:21:38AM -0700, Ralph Droms wrote: > I'll see if I can find us another time slot. Would Tue AM be OK: > > TUESDAY, August 3, 2004 > 0900-1130 Morning Sessions > APP simple SIP for Instant Messaging and Presence Leveraging Extensions WG > INT eap Extensible Authentication Protocol WG > IRTF dtnrg Delay-tolerant Networking Research Group > OPS psamp Packet Sampling WG > RTG ccamp Common Control and Measurement Plane WG > TSV avt Audio/Video Transport WG * > TSV nfsv4 Network File System Version 4 WG Yes, that's fine, at least for me. Stig _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri Jul 9 10:42: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 KAA03132; Fri, 9 Jul 2004 10:42: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 1Biw70-0003OG-9O; Fri, 09 Jul 2004 10:12:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BivfA-0003YF-HZ for dhcwg@megatron.ietf.org; Fri, 09 Jul 2004 09:43:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27199 for ; Fri, 9 Jul 2004 09:43:33 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bivf4-0001R8-Mo for dhcwg@ietf.org; Fri, 09 Jul 2004 09:43:34 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bive9-000198-00 for dhcwg@ietf.org; Fri, 09 Jul 2004 09:42:38 -0400 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 1Bivdd-0000qc-00 for dhcwg@ietf.org; Fri, 09 Jul 2004 09:42:06 -0400 Received: from ocean.jinmei.org (unknown [2001:200:0:8002:adbf:fe5a:f394:422f]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 753AE15272; Fri, 9 Jul 2004 22:42:03 +0900 (JST) Date: Fri, 09 Jul 2004 22:42:01 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Ralph Droms Subject: Re: [dhcwg] *DRAFT* Agenda for dhc WG meeting in San Diego In-Reply-To: <4.3.2.7.2.20040708155658.0290b6f8@flask.cisco.com> References: <4.3.2.7.2.20040708155658.0290b6f8@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: multipart/mixed; boundary="Multipart_Fri_Jul__9_22:42:01_2004-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 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 --Multipart_Fri_Jul__9_22:42:01_2004-1 Content-Type: text/plain; charset=US-ASCII >>>>> On Thu, 08 Jul 2004 15:59:03 -0400, >>>>> Ralph Droms said: > Below is the draft scheduled time and agenda for the dhc WG meeting in San > Diego. NOTE THAT THE MEETING DAY HAS CHANGED TO WEDNESDAY!! Let me know if > you have additional items for the agenda. As I asked the other day, I'm wondering if we can discuss DHCPv6 authentication issues in San Diego (attached below). I'm almost done on writing a short internet-draft discussing the issues. Regardless of whether the request is accepted, I'll submit it before the initial cut-off date on July 12th. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp --Multipart_Fri_Jul__9_22:42:01_2004-1 Content-Type: message/rfc822 Return-Path: X-Mail-Format-Warning: Bad RFC2822 header formatting in >From jinmei Wed Jul 7 20:28:35 2004 Return-Path: X-Original-To: jinmei@shuttle.wide.toshiba.co.jp Delivered-To: jinmei@shuttle.wide.toshiba.co.jp Received: from shuttle.wide.toshiba.co.jp [202.249.10.124] by localhost with POP3 (fetchmail-6.2.4) for jinmei@localhost (single-drop); Wed, 07 Jul 2004 20:56:27 +0900 (JST) Received: from tsbgw.wide.toshiba.co.jp (tsbgw.wide.toshiba.co.jp [3ffe:501:100f:0:220:edff:fe2b:92c]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 8C4A21525D for ; Wed, 7 Jul 2004 20:28:35 +0900 (JST) Received: from maltese.wide.toshiba.co.jp (maltese.wide.toshiba.co.jp [202.249.10.99]) by tsbgw.wide.toshiba.co.jp (Postfix) with ESMTP id 4DBDB33338; Wed, 7 Jul 2004 20:28:35 +0900 (JST) Received: from isl.rdc.toshiba.co.jp (spiffy.isl.rdc.toshiba.co.jp [133.196.10.10]) by maltese.wide.toshiba.co.jp (8.9.1/8.9.1) with ESMTP id UAA25222; Wed, 7 Jul 2004 20:28:35 +0900 (JST) Received: from mx.toshiba.co.jp (mx1.toshiba.co.jp [133.199.160.215]) by isl.rdc.toshiba.co.jp (8.11.7/8.11.6/1.4) with ESMTP id i67BSYn10387; Wed, 7 Jul 2004 20:28:34 +0900 (JST) Received: from tsb-sgw2.toshiba.co.jp by toshiba.co.jp id UAA03162; Wed, 7 Jul 2004 20:28:34 +0900 (JST) Received: from inet-tsb5.toshiba.co.jp by tsb-sgw2.toshiba.co.jp with ESMTP id i67BSX1a013956; Wed, 7 Jul 2004 20:28:33 +0900 (JST) Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by inet-tsb5.toshiba.co.jp with ESMTP id i67BSVrB006415; Wed, 7 Jul 2004 20:28:31 +0900 (JST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bi9sl-0001z9-MS; Wed, 07 Jul 2004 06:42:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bi9E8-0001WD-2v for dhcwg@megatron.ietf.org; Wed, 07 Jul 2004 06:00:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07891 for ; Wed, 7 Jul 2004 06:00:24 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bi9E0-00050j-MY for dhcwg@ietf.org; Wed, 07 Jul 2004 06:00:24 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bi9D2-0004fi-00 for dhcwg@ietf.org; Wed, 07 Jul 2004 05:59:25 -0400 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 1Bi9CW-0004KY-00 for dhcwg@ietf.org; Wed, 07 Jul 2004 05:58:52 -0400 Received: from ocean.jinmei.org (unknown [3ffe:501:100f:1048:200:39ff:fed7:e2e4]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id B364B1525D; Wed, 7 Jul 2004 18:58:52 +0900 (JST) Date: Wed, 07 Jul 2004 18:58:51 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Ralph Droms Subject: Re: [dhcwg] *DRAFT* Agenda for dhc WG meeting in San Diego In-Reply-To: <4.3.2.7.2.20040621184653.020ffcd8@flask.cisco.com> References: <4.3.2.7.2.20040621184653.020ffcd8@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 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 X-UIDL: L]A!!W36"!gT^"!~Uh"! X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on ocean.jinmei.org X-Spam-Status: No, hits=-1.9 required=5.0 tests=AWL autolearn=no version=2.63 >>>>> On Mon, 21 Jun 2004 18:48:44 -0400, >>>>> Ralph Droms said: > Below is the draft scheduled time and agenda for the dhc WG meeting in San > Diego. Let me know if you have additional items for the agenda. Does it make sense to discuss (possible) clarifications on the authentication mechanism of DHCPv6 (RFC3315)? I raised some questions the other day (*), and, according to the succeeding messages, there seem to be some issues that need further discussion. But I'm not sure if my questions are valid in the first place since I've not seen any responses from the RFC3315 authors. If this is worth a discussion, I'll try to find time to make a very short draft summarizing the issues, and will ask for a short slot in the meeting. (*) http://www1.ietf.org/mail-archive/web/dhcwg/current/msg03645.html 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 --Multipart_Fri_Jul__9_22:42:01_2004-1 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 --Multipart_Fri_Jul__9_22:42:01_2004-1-- From dhcwg-bounces@ietf.org Fri Jul 9 12:12: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 MAA07849; Fri, 9 Jul 2004 12:12: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 1Bixcs-0001TK-7x; Fri, 09 Jul 2004 11: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 1BixGo-0006Ss-He for dhcwg@megatron.ietf.org; Fri, 09 Jul 2004 11:26:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05540 for ; Fri, 9 Jul 2004 11:26:30 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BixGi-0002ou-HE for dhcwg@ietf.org; Fri, 09 Jul 2004 11:26:32 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BixFl-0002Vm-00 for dhcwg@ietf.org; Fri, 09 Jul 2004 11:25:34 -0400 Received: from raven.ecs.soton.ac.uk ([152.78.70.1]) by ietf-mx with esmtp (Exim 4.12) id 1BixEu-0002CG-00 for dhcwg@ietf.org; Fri, 09 Jul 2004 11:24: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 i69FOdnE018633 for ; Fri, 9 Jul 2004 16:24:39 +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 QAA19804 for ; Fri, 9 Jul 2004 16:24:37 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id i69FOba17751 for dhcwg@ietf.org; Fri, 9 Jul 2004 16:24:37 +0100 Date: Fri, 9 Jul 2004 16:24:37 +0100 From: Tim Chown To: dhcwg@ietf.org Subject: Re: [dhcwg] *DRAFT* Agenda for dhc WG meeting in San Diego Message-ID: <20040709152437.GJ16829@login.ecs.soton.ac.uk> Mail-Followup-To: dhcwg@ietf.org References: <4.3.2.7.2.20040708155658.0290b6f8@flask.cisco.com> <20040709060024.GA17832@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-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 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 That would be nice Ralph, but I guess whatever you suggest someone's interests will cross. mboned and dhc just happen to be two warm topics in IPv6 at the moment. Tim On Fri, Jul 09, 2004 at 02:21:38AM -0700, Ralph Droms wrote: > I'll see if I can find us another time slot. Would Tue AM be OK: > > TUESDAY, August 3, 2004 > 0900-1130 Morning Sessions > APP simple SIP for Instant Messaging and Presence Leveraging Extensions WG > INT eap Extensible Authentication Protocol WG > IRTF dtnrg Delay-tolerant Networking Research Group > OPS psamp Packet Sampling WG > RTG ccamp Common Control and Measurement Plane WG > TSV avt Audio/Video Transport WG * > TSV nfsv4 Network File System Version 4 WG > > - Ralph > > On Fri, 9 Jul 2004, Stig Venaas wrote: > > > On Thu, Jul 08, 2004 at 03:59:03PM -0400, Ralph Droms wrote: > > > Below is the draft scheduled time and agenda for the dhc WG meeting in San > > > Diego. NOTE THAT THE MEETING DAY HAS CHANGED TO WEDNESDAY!! Let me know if > > > you have additional items for the agenda. > > > > > > - Ralph > > > > > > ----- > > > WEDNESDAY, August 4, 2004 > > > 0900-1130 Morning Sessions > > > APP marid MTA Authorization Records in DNS WG > > > INT dhc Dynamic Host Configuration WG > > > OPS mboned MBONE Deployment WG * > > > RTG pce Path Computation Element BOF > > > SEC pkix Public Key Infrastructure WG > > > TSV rddp Remote Direct Data Placement WG > > > TSV sip Session Initiation Protocol WG > > > > There's a major problem here. This clashes with the mboned meeting > > and Jerome Durand is supposed to talk about his draft on IPv6 multicast > > address assignment with DHCPv6 in both meetings! > > > > I, and I suspect a few others, would also like to go to both meetings. > > > > 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 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri Jul 9 12:24: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 MAA08565; Fri, 9 Jul 2004 12:24: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 1BixjU-0002uK-Mr; Fri, 09 Jul 2004 11:56:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BixHp-0006cF-FK; Fri, 09 Jul 2004 11:27:41 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05607; Fri, 9 Jul 2004 11:27:38 -0400 (EDT) Message-Id: <200407091527.LAA05607@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Fri, 09 Jul 2004 11:27:38 -0400 Cc: dhcwg@ietf.org Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-agentopt-radius-07.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 : RADIUS Attributes Sub-option for the DHCP Relay Agent Information Option Author(s) : R. Droms, J. Schnizlein Filename : draft-ietf-dhc-agentopt-radius-07.txt Pages : 9 Date : 2004-7-8 A NAS (network access server) may choose to authenticate the identity of a device before granting that device access to the network. The IEEE 802.1X protocol is an example of a mechanism for providing authenticated layer 2 network access. A network element using RADIUS as an authentication authority will receive attributes from a RADIUS server that may be used by a DHCP server in the selection of configuration parameters to be delivered to the device through its DHCP client. The RADIUS Attributes sub-option enables a network element to pass along attributes for the user of a device received during RADIUS authentication to a DHCP server. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-agentopt-radius-07.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-agentopt-radius-07.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-agentopt-radius-07.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-7-9115136.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-agentopt-radius-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-agentopt-radius-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-7-9115136.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 Fri Jul 9 16: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 QAA28976; Fri, 9 Jul 2004 16: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 1Bj1gC-0001RB-Oq; Fri, 09 Jul 2004 16:09:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bj00a-0000Bt-3x for dhcwg@megatron.ietf.org; Fri, 09 Jul 2004 14:22:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17363 for ; Fri, 9 Jul 2004 14:21:57 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bj00T-0001Mb-Va for dhcwg@ietf.org; Fri, 09 Jul 2004 14:21:58 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bizzl-00010n-00 for dhcwg@ietf.org; Fri, 09 Jul 2004 14:21:14 -0400 Received: from mail.thingmagic.com ([207.31.248.245] helo=thingmagic.com) by ietf-mx with esmtp (Exim 4.12) id 1Bizya-0000Sl-00 for dhcwg@ietf.org; Fri, 09 Jul 2004 14:20:00 -0400 Received: from [207.31.248.169] (account margaret HELO [10.0.0.41]) by thingmagic.com (CommuniGate Pro SMTP 4.1.8) with ESMTP-TLS id 108255; Fri, 09 Jul 2004 14:17:36 -0400 Mime-Version: 1.0 X-Sender: margaret@mail.thingmagic.com Message-Id: In-Reply-To: References: <4.3.2.7.2.20040708155658.0290b6f8@flask.cisco.com> <20040709060024.GA17832@sverresborg.uninett.no> Date: Fri, 9 Jul 2004 14:17:57 -0400 To: Ralph Droms , Stig Venaas From: Margaret Wasserman Subject: Re: [dhcwg] *DRAFT* Agenda for dhc WG meeting in San Diego Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 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 Hi Ralph, Tuesday AM wouldn't work for me, as I am the responsible AD for both DHCP and EAP. Margaret At 2:21 AM -0700 7/9/04, Ralph Droms wrote: >I'll see if I can find us another time slot. Would Tue AM be OK: > >TUESDAY, August 3, 2004 >0900-1130 Morning Sessions >APP simple SIP for Instant Messaging and Presence Leveraging >Extensions WG >INT eap Extensible Authentication Protocol WG >IRTF dtnrg Delay-tolerant Networking Research Group >OPS psamp Packet Sampling WG >RTG ccamp Common Control and Measurement Plane WG >TSV avt Audio/Video Transport WG * >TSV nfsv4 Network File System Version 4 WG > >- Ralph > >On Fri, 9 Jul 2004, Stig Venaas wrote: > >> On Thu, Jul 08, 2004 at 03:59:03PM -0400, Ralph Droms wrote: >> > Below is the draft scheduled time and agenda for the dhc WG meeting in San >> > Diego. NOTE THAT THE MEETING DAY HAS CHANGED TO WEDNESDAY!! >>Let me know if >> > you have additional items for the agenda. >> > >> > - Ralph >> > >> > ----- >> > WEDNESDAY, August 4, 2004 >> > 0900-1130 Morning Sessions >> > APP marid MTA Authorization Records in DNS WG >> > INT dhc Dynamic Host Configuration WG >> > OPS mboned MBONE Deployment WG * >> > RTG pce Path Computation Element BOF >> > SEC pkix Public Key Infrastructure WG >> > TSV rddp Remote Direct Data Placement WG >> > TSV sip Session Initiation Protocol WG >> >> There's a major problem here. This clashes with the mboned meeting >> and Jerome Durand is supposed to talk about his draft on IPv6 multicast >> address assignment with DHCPv6 in both meetings! >> >> I, and I suspect a few others, would also like to go to both meetings. >> >> 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 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri Jul 9 16:46: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 QAA29008; Fri, 9 Jul 2004 16:46: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 1Bj1ge-0001k0-GK; Fri, 09 Jul 2004 16:09:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bj08E-0001B6-F0 for dhcwg@megatron.ietf.org; Fri, 09 Jul 2004 14:29:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17989 for ; Fri, 9 Jul 2004 14:29:51 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bj088-0004Lo-Cj for dhcwg@ietf.org; Fri, 09 Jul 2004 14:29:52 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bj07N-00040W-00 for dhcwg@ietf.org; Fri, 09 Jul 2004 14:29:06 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1Bj06P-0003K8-00 for dhcwg@ietf.org; Fri, 09 Jul 2004 14:28:05 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 09 Jul 2004 11:27:02 -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 i69IRTt3014533; Fri, 9 Jul 2004 11:27:33 -0700 (PDT) Received: from rdroms-w2k01.cisco.com ([161.44.65.119]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AKA23561; Fri, 9 Jul 2004 14:27:28 -0400 (EDT) Message-Id: <4.3.2.7.2.20040709142659.029a9de8@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 09 Jul 2004 14:27:26 -0400 To: Margaret Wasserman From: Ralph Droms Subject: Re: [dhcwg] *DRAFT* Agenda for dhc WG meeting in San Diego In-Reply-To: References: <4.3.2.7.2.20040708155658.0290b6f8@flask.cisco.com> <20040709060024.GA17832@sverresborg.uninett.no> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Cc: dhcwg@ietf.org, 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 Any chance we can swap the DHC and EAP slots? - Ralph At 02:17 PM 7/9/2004 -0400, Margaret Wasserman wrote: >Hi Ralph, > >Tuesday AM wouldn't work for me, as I am the responsible AD for both DHCP >and EAP. > >Margaret > >At 2:21 AM -0700 7/9/04, Ralph Droms wrote: >>I'll see if I can find us another time slot. Would Tue AM be OK: >> >>TUESDAY, August 3, 2004 >>0900-1130 Morning Sessions >>APP simple SIP for Instant Messaging and Presence Leveraging >>Extensions WG >>INT eap Extensible Authentication Protocol WG >>IRTF dtnrg Delay-tolerant Networking Research Group >>OPS psamp Packet Sampling WG >>RTG ccamp Common Control and Measurement Plane WG >>TSV avt Audio/Video Transport WG * >>TSV nfsv4 Network File System Version 4 WG >> >>- Ralph >> >>On Fri, 9 Jul 2004, Stig Venaas wrote: >> >>> On Thu, Jul 08, 2004 at 03:59:03PM -0400, Ralph Droms wrote: >>> > Below is the draft scheduled time and agenda for the dhc WG meeting >>> in San >>> > Diego. NOTE THAT THE MEETING DAY HAS CHANGED TO WEDNESDAY!! Let me >>> know if >>> > you have additional items for the agenda. >>> > >>> > - Ralph >>> > >>> > ----- >>> > WEDNESDAY, August 4, 2004 >>> > 0900-1130 Morning Sessions >>> > APP marid MTA Authorization Records in DNS WG >>> > INT dhc Dynamic Host Configuration WG >>> > OPS mboned MBONE Deployment WG * >>> > RTG pce Path Computation Element BOF >>> > SEC pkix Public Key Infrastructure WG >>> > TSV rddp Remote Direct Data Placement WG >>> > TSV sip Session Initiation Protocol WG >>> >>> There's a major problem here. This clashes with the mboned meeting >>> and Jerome Durand is supposed to talk about his draft on IPv6 multicast >>> address assignment with DHCPv6 in both meetings! >>> >>> I, and I suspect a few others, would also like to go to both meetings. >>> >>> 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 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri Jul 9 16:54: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 QAA29517; Fri, 9 Jul 2004 16:54: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 1Bj1hU-0002f9-KK; Fri, 09 Jul 2004 16:10:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bj0dM-0006xw-MO for dhcwg@megatron.ietf.org; Fri, 09 Jul 2004 15:02:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20130 for ; Fri, 9 Jul 2004 15:02:01 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bj0dG-0007VU-ES for dhcwg@ietf.org; Fri, 09 Jul 2004 15:02:02 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bj0ad-0006Q3-00 for dhcwg@ietf.org; Fri, 09 Jul 2004 14:59:20 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Bj0YB-0005Mk-01 for dhcwg@ietf.org; Fri, 09 Jul 2004 14:56:47 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by mx2.foretec.com with esmtp (Exim 4.24) id 1Bj04u-0007NQ-Fi for dhcwg@ietf.org; Fri, 09 Jul 2004 14:26:32 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-5.cisco.com with ESMTP; 09 Jul 2004 11:26:16 -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 i69IPvSc022613 for ; Fri, 9 Jul 2004 11:25:58 -0700 (PDT) Received: from rdroms-w2k01.cisco.com ([161.44.65.119]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AKA23455; Fri, 9 Jul 2004 14:25:56 -0400 (EDT) Message-Id: <4.3.2.7.2.20040709141502.029e32e0@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 09 Jul 2004 14:25:19 -0400 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [dhcwg] *DRAFT* Agenda for dhc WG meeting in San Diego (Last revised 07/09/2004 02:03 PM) 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 DHC WG agenda - IETF 60 0900 Wed 2004-08-04 (tentative) (Last revised 07/09/2004 02:03 PM) ---------------------------------- Administrivia Ralph Droms 05 minutes Agenda bashing 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? IPv6 multicast address assignment with DHCPv6 Jerome Durand 20 minutes Technical discussion Renumbering Requirements for Stateless DHCPv6 15 minutes Ready for WG last call? Lifetime Option for DHCPv6 15 minutes Ready for WG last call (depending on status of 'Renumbering Requirements')? IPv4 and IPv6 Dual-Stack Issues for DHCPv6 30 minutes Ready for WG last call? Issues in DHCPv6 authentication Jinmei Tatuya 15 minutes Technical discussion ----------- 140 minutes _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri Jul 9 23:53: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 XAA02523; Fri, 9 Jul 2004 23:53: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 1Bj8CX-0004mj-0L; Fri, 09 Jul 2004 23:06:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bj6qW-00015H-ID for dhcwg@megatron.ietf.org; Fri, 09 Jul 2004 21:40:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21739 for ; Fri, 9 Jul 2004 21:40:01 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bj6qP-0003Z2-Tq for dhcwg@ietf.org; Fri, 09 Jul 2004 21:40:02 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bj6pV-0003Du-00 for dhcwg@ietf.org; Fri, 09 Jul 2004 21:39:06 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1Bj6ob-0002Wc-00 for dhcwg@ietf.org; Fri, 09 Jul 2004 21:38:09 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 09 Jul 2004 18:25:42 +0000 X-BrightmailFiltered: true Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i6A1On4N003236 for ; Fri, 9 Jul 2004 18:24:49 -0700 (PDT) Received: from [10.32.254.178] ([10.32.254.178]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with SMTP id AVF80247; Fri, 9 Jul 2004 18:23:38 -0700 (PDT) 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: Richard Johnson Date: Fri, 9 Jul 2004 18:24:46 -0700 X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [dhcwg] Question re. interpretation of option 33 destination addr 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 have a question about the interpretation of the destination address in option 33. Looking at RFC2132, it's not really clear how this address should be interpreted. Since we now have a "classless static route" option, it seems clear that option 33 was a "classfull static route" option. That being the case, it seems clear that given a destination address of "10.1.1.0", the subnet mask which should go along with this would be the classfull mask of 255.0.0.0. Fine. But given a destination address of "10.1.1.0" (and an assumed mask of 255.0.0.0), is this a host route? It would seem so. But is that what was intended? Or, instead, should the client system AND the destination address with the classfull mask in order to produce a subnet route (in this case "10.0.0.0/8")? My first thoughts would be that in order to keep as much flexibility as possible, the destination address should NOT be AND'ed with the classfull mask and if the destination address happens to have bits set in the "host" portion of the address, then it should assumed that this is a "host route". If a "subnet route" were intended, then bits would not have been set in the "host" portion of the address. The real question, however, is how is this currently handled and what is the expectation? /raj _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Sat Jul 10 01:54: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 BAA10063; Sat, 10 Jul 2004 01:54: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 1BjAfY-0005ha-Np; Sat, 10 Jul 2004 01:45:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BjAdc-0005TP-Oy for dhcwg@megatron.ietf.org; Sat, 10 Jul 2004 01:43:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA09641 for ; Sat, 10 Jul 2004 01:43:03 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BjAda-0000PL-LS for dhcwg@ietf.org; Sat, 10 Jul 2004 01:43:02 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BjAcr-00006a-00 for dhcwg@ietf.org; Sat, 10 Jul 2004 01:42:17 -0400 Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx with esmtp (Exim 4.12) id 1BjAcD-0007aV-00 for dhcwg@ietf.org; Sat, 10 Jul 2004 01:41:37 -0400 Received: from [10.0.2.3] (neubayern.net [66.93.162.100]) by toccata.fugue.com (Postfix) with ESMTP id 20C081B200D; Sat, 10 Jul 2004 00:34:32 -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] Question re. interpretation of option 33 destination addr Date: Fri, 9 Jul 2004 22:41:34 -0700 To: Richard Johnson X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 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 think the real answer to this question is that the reason we trashed option 33 is precisely that there is no sensible way to answer the question you have asked. Sure, you could try to impute some subnet mask on an obviously invalid network destination, but you really couldn't do it safely. For example, is 10.0.2.0 a /24 or a /23? Do we impute subnet masks on octet boundaries, or on bit boundaries? So I think the right answer is to just use the classless static routes option if you want to have network destination addresses that are not consistent with classed routing. I think this is why option 33 is so infrequently used - it just doesn't work. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon Jul 12 00:36: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 AAA29745; Mon, 12 Jul 2004 00:36: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 1BjsVf-0000Pe-0Q; Mon, 12 Jul 2004 00:33:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BjsS1-0008WV-A5 for dhcwg@megatron.ietf.org; Mon, 12 Jul 2004 00:30:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29551 for ; Mon, 12 Jul 2004 00:29:58 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BjsRz-0003kw-Df for dhcwg@ietf.org; Mon, 12 Jul 2004 00:29:59 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BjsR5-0003bR-00 for dhcwg@ietf.org; Mon, 12 Jul 2004 00:29:04 -0400 Received: from mailout1.samsung.com ([203.254.224.24]) by ietf-mx with esmtp (Exim 4.12) id 1BjsQi-0003Rn-00; Mon, 12 Jul 2004 00:28:41 -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 <0I0Q007KR1QTDK@mailout1.samsung.com>; Mon, 12 Jul 2004 13:28:05 +0900 (KST) Received: from ep_ms3_bk (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 <0I0Q00JV41NUV1@mailout1.samsung.com>; Mon, 12 Jul 2004 13:26:18 +0900 (KST) Received: from ep_spt02 (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 <0I0Q0065V1NUWR@ms3.samsung.com>; Mon, 12 Jul 2004 13:26:18 +0900 (KST) Content-return: prohibited Date: Mon, 12 Jul 2004 04:26:29 +0000 (GMT) From: PARK SOO HONG X-Sender: =?euc-kr?B?U2Ftc3VuZyBFbGVjdHJvbmljc6HnTW9iaQ==?= =?euc-kr?B?bGUgUGxhdGZvcm0gTGFioedFbmdpbmVlcg==?= To: ipv6@ietf.org, dhcwg@ietf.org, soohong.park@samsung.com Message-id: <6308016.1089606369894.JavaMail.weblogic@ep_app44> MIME-version: 1.0 Content-type: text/plain; charset=euc-kr Content-transfer-encoding: 7BIT X-Priority: 3 Msgkey: 20040712042609889@soohong.park X-MTR: 20040712042609889@soohong.park X-EPLocale: en_US.euc-kr X-EPWebmail-Msg-Type: personal X-EPWebmail-Reply-Demand: 0 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.3 required=5.0 tests=AWL,PRIORITY_NO_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Subject: [dhcwg] [New I-D Announcement] Consideration M&O Flags of IPv6 RA 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 7BIT Hi, as described in subject line, I and several guys including the editor of RFC2462bis made a proposal about concern as a new I-D which will be available in the IETF server soon. Before publication, you can touch with below link. http://home.megapass.co.kr/~natpp00/draft-daniel-ipv6-ra-mo-flags-00.txt.txt Your comments are highly welcome. I do CC as DHC WG because it is tighly related to this field. Regards Daniel (Soohong Daniel Park) Mobile Platform Laboratory. SAMSUNG Electronics _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon Jul 12 05:15: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 FAA24557; Mon, 12 Jul 2004 05:15: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 1Bjwow-0000Uu-Kb; Mon, 12 Jul 2004 05:09:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BjwnD-0000IQ-9w for dhcwg@megatron.ietf.org; Mon, 12 Jul 2004 05:08:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24315 for ; Mon, 12 Jul 2004 05:08:08 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BjwnB-000665-2B for dhcwg@ietf.org; Mon, 12 Jul 2004 05:08:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BjwmJ-0005vF-00 for dhcwg@ietf.org; Mon, 12 Jul 2004 05:07:16 -0400 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 1BjwlS-0005kD-00 for dhcwg@ietf.org; Mon, 12 Jul 2004 05:06:22 -0400 Received: from ocean.jinmei.org (unknown [2001:200:0:8002:7d0e:97bf:bedf:bfd7]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 2B7A415263 for ; Mon, 12 Jul 2004 18:06:23 +0900 (JST) Date: Mon, 12 Jul 2004 18:06:21 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: dhcwg@ietf.org Subject: A new draft on DHCPv6 authentication (Re: [dhcwg] *DRAFT* Agenda for dhc WG meeting in San Diego) In-Reply-To: References: <4.3.2.7.2.20040708155658.0290b6f8@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-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 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, 09 Jul 2004 22:42:01 +0900, >>>>> JINMEI Tatuya said: >> Below is the draft scheduled time and agenda for the dhc WG meeting in San >> Diego. NOTE THAT THE MEETING DAY HAS CHANGED TO WEDNESDAY!! Let me know if >> you have additional items for the agenda. > As I asked the other day, I'm wondering if we can discuss DHCPv6 > authentication issues in San Diego (attached below). > I'm almost done on writing a short internet-draft discussing the > issues. Regardless of whether the request is accepted, I'll submit it > before the initial cut-off date on July 12th. I just submitted the draft. It will eventually appear at the I-D archive, but I expect several days before the official announcement since it's a heavily busy season. For now, a copy of the submitted draft is available the following URL: http://www.jinmei.org/draft-jinmei-dhc-dhcpv6-clarify-auth-00.txt Any comments/suggestions/questions are welcome. Thanks, 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 Jul 12 08:32: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 IAA03493; Mon, 12 Jul 2004 08:32: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 1Bjzmz-0008PV-TO; Mon, 12 Jul 2004 08:20:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BjzcZ-00073X-KP for dhcwg@megatron.ietf.org; Mon, 12 Jul 2004 08:09:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02009 for ; Mon, 12 Jul 2004 08:09:22 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BjzcZ-0002W0-7b for dhcwg@ietf.org; Mon, 12 Jul 2004 08:09:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bjzbl-0002Kl-00 for dhcwg@ietf.org; Mon, 12 Jul 2004 08:08:34 -0400 Received: from maileu.alliedtelesyn.com ([81.116.95.49] helo=alliedtelesyn.com) by ietf-mx with esmtp (Exim 4.12) id 1Bjzav-0001vr-00 for dhcwg@ietf.org; Mon, 12 Jul 2004 08:07:41 -0400 Received: from svr-mila-e2k1.eu.alliedtelesyn.com ([10.17.39.17] RDNS failed) by alliedtelesyn.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 12 Jul 2004 14:01:38 +0200 Received: from svr-mila-fs3.eu.alliedtelesyn.com ([10.17.90.11]) by svr-mila-e2k1.eu.alliedtelesyn.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 12 Jul 2004 14:06:53 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 12 Jul 2004 14:06:53 +0200 Message-ID: Thread-Topic: DHCP : transaction ID issue. Thread-Index: AcRoCLhq3fhmLzqrQr+LwvcTTIZQLw== From: "Paradiso, Francesco" To: X-OriginalArrivalTime: 12 Jul 2004 12:06:53.0787 (UTC) FILETIME=[B88382B0:01C46808] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL,HTML_40_50,HTML_MESSAGE autolearn=no version=2.60 Subject: [dhcwg] DHCP : transaction ID issue. 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="===============2085942161==" Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org This is a multi-part message in MIME format. --===============2085942161== content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C46808.B873600B" This is a multi-part message in MIME format. ------_=_NextPart_001_01C46808.B873600B Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, When a client receive a OFFER ACK message it must check the transaction = ID. Why the field chaddr must not be validate? I have a case in which two different clients generate the same = transaction ID. OK I am very unluky but this has happen. Both the clients accepts the OFFERs and the ACKs sent in broadcast and = get the same IP address. If the clients would check the chaddr before accepting a message this = would not be occured. There are some unknow (to me) side effects created by a clients that = execs this check of the chaddr field? Thanks in advance. Best Regards. Francesco Francesco Paradiso > ------------------------------------ Integration Test Engineer Allied Telesis Multimedia S.r.l. P.zza Tirana 24/4B - 20147 Milano MI - Italy Office +39 02 414112908 Fax +39 02 41411260 ------_=_NextPart_001_01C46808.B873600B Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable DHCP : transaction ID issue.

Hello,
When a client receive a OFFER ACK = message it must check the transaction ID.
Why the field chaddr must not be = validate?

I have a case in which two different = clients generate the same transaction ID. OK I am very unluky but this = has happen.
Both the clients accepts the OFFERs = and the ACKs sent in broadcast and get the same IP address.
If the clients would check the chaddr = before accepting a message this would not be occured.

There are some unknow (to me) side = effects created by a clients that execs this check of the chaddr = field?


Thanks in advance.
Best Regards.

Francesco


Francesco = Paradiso
------------------------------------
Integration Test = Engineer

Allied Telesis = Multimedia S.r.l.
P.zza Tirana 24/4B - = 20147 Milano MI  - Italy

Office   =        +39 02 414112908
Fax      =        +39 02 41411260


------_=_NextPart_001_01C46808.B873600B-- --===============2085942161== 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 --===============2085942161==-- From dhcwg-bounces@ietf.org Mon Jul 12 21:27: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 VAA09337; Mon, 12 Jul 2004 21:27: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 1BkArg-0002S1-Jw; Mon, 12 Jul 2004 20:09:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bk8L3-0000hA-17 for dhcwg@megatron.ietf.org; Mon, 12 Jul 2004 17:27:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16887 for ; Mon, 12 Jul 2004 17:27:50 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bk8L1-0004ZN-Oo for dhcwg@ietf.org; Mon, 12 Jul 2004 17:27:51 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bk8K0-0004EU-00 for dhcwg@ietf.org; Mon, 12 Jul 2004 17:26:49 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1Bk8Iw-0003bt-00 for dhcwg@ietf.org; Mon, 12 Jul 2004 17:25:43 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 12 Jul 2004 14:26:38 +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 i6CLP5Sc020226 for ; Mon, 12 Jul 2004 14:25:06 -0700 (PDT) Received: from rdroms-w2k01.cisco.com ([161.44.65.119]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AKB56758; Mon, 12 Jul 2004 17:25:04 -0400 (EDT) Message-Id: <4.3.2.7.2.20040712172352.02a40008@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 12 Jul 2004 17:25:02 -0400 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [dhcwg] dhc WG status report 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 dhc WG Status Report 2004-03-08 to 2004-07-12 ------------------------ The rechartering of the dhc WG has been completed and the new charter is available on the dhc WG web page (ietf.org/html.charters/dhc-charter.html). Some milestones for existing work have been updated. The chair will be asking document authors for more milestones. IPR issues: ----------- Samsung has published a new IPR statement about draft-ietf-dhc-rapid-commit-opt. The affected draft will now be reconsidered for WG last call. The IETF Executive Director has written to PacketFront asking for clarification of the IPR notice that was published by PacketFront referring to draft-ietf-dhc-subscriber-id-00 and draft-ietf-dhc-server-override-00. The chair has written to PacketFront asking if PacketFront would be willing to change the terms in its IPR notice for draft-ietf-dhc-subscriber-id-00 to a zero-cost royalty license. PacketFront has not responded to either request. RFCs published: --------------- RFC 3736, Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6 Documents approved and in RFC Editor queue: ------------------------------------------- NIS Configuration Options for DHCPv6 draft-ietf-dhc-dhcpv6-opt-nisconfig-05 Documents approved and announcement sent: ----------------------------------------- Vendor-Identifying Vendor Options for DHCPv4 draft-ietf-dhc-vendor-03 Reclassifying DHCPv4 Options draft-ietf-dhc-reclassify-options-01 Documents accepted as dhc WG work items: ---------------------------------------- IPv4 and IPv6 Dual-Stack Issues for DHCPv6 draft-ietf-dhc-dual-stack-00 Lifetime Option for DHCPv6 draft-ietf-dhc-lifetime-00.txt Renumbering Requirements for Stateless DHCPv6 draft-ietf-dhc-stateless-dhcpv6-renumbering-00 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon Jul 12 21:28: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 VAA09571; Mon, 12 Jul 2004 21:28: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 1BkAsn-0002yH-PA; Mon, 12 Jul 2004 20:10:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bk8UI-0002Tz-LJ for dhcwg@megatron.ietf.org; Mon, 12 Jul 2004 17:37:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17706 for ; Mon, 12 Jul 2004 17:37:23 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bk8UH-0007Tk-CC for dhcwg@ietf.org; Mon, 12 Jul 2004 17:37:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bk8Sy-00078f-00 for dhcwg@ietf.org; Mon, 12 Jul 2004 17:36:05 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1Bk8SK-0006nS-00 for dhcwg@ietf.org; Mon, 12 Jul 2004 17:35:24 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 12 Jul 2004 14:34:59 -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 i6CLYrt1012832 for ; Mon, 12 Jul 2004 14:34:53 -0700 (PDT) Received: from rdroms-w2k01.cisco.com ([161.44.65.119]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AKB57553; Mon, 12 Jul 2004 17:34:52 -0400 (EDT) Message-Id: <4.3.2.7.2.20040712173122.02a3dbe0@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 12 Jul 2004 17:34:49 -0400 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [dhcwg] dhc WG last call on draft-ietf-dhc-proxyserver-opt-00 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 WG last call on "DHCP Option for Proxy Server Configuration" . The last call will conclude at 1700 EDT, 2004-07-30. 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 From dhcwg-bounces@ietf.org Mon Jul 12 21:36: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 VAA10749; Mon, 12 Jul 2004 21:36: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 1BkAwQ-0005xO-EK; Mon, 12 Jul 2004 20:14:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bk9KP-0003bQ-2E for dhcwg@megatron.ietf.org; Mon, 12 Jul 2004 18:31:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24644 for ; Mon, 12 Jul 2004 18:31:13 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bk9KN-0000Br-GR for dhcwg@ietf.org; Mon, 12 Jul 2004 18:31:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bk9I6-0007CQ-00 for dhcwg@ietf.org; Mon, 12 Jul 2004 18:28:55 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Bk9Fq-0006V7-00 for dhcwg@ietf.org; Mon, 12 Jul 2004 18:26:34 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by mx2.foretec.com with esmtp (Exim 4.24) id 1Bk90t-0000hX-L0 for dhcwg@ietf.org; Mon, 12 Jul 2004 18:11:07 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 12 Jul 2004 18:14:03 -0400 X-BrightmailFiltered: true Received: from jschnizl-w2k.cisco.com (rtp-vpn3-850.cisco.com [10.82.219.86]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i6CMAVaH026950 for ; Mon, 12 Jul 2004 18:10:32 -0400 (EDT) Message-Id: <4.3.2.7.2.20040712180958.0254dda8@wells.cisco.com> X-Sender: jschnizl@wells.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 12 Jul 2004 18:11:39 -0400 To: dhcwg@ietf.org From: John Schnizlein In-Reply-To: <200407121933.PAA04352@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Subject: [dhcwg] Re: [Geopriv] I-D ACTION:draft-ietf-geopriv-dhcp-civil-03.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 At 03:33 PM 7/12/2004, Internet-Drafts@ietf.org wrote: >A New Internet-Draft is available from the on-line Internet-Drafts directories. >This draft is a work item of the Geographic Location/Privacy Working Group of the IETF. > > Title : Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for Civic Addresses > Author(s) : H. Schulzrinne > Filename : draft-ietf-geopriv-dhcp-civil-03.txt > Pages : 18 > Date : 2004-7-12 > >This document specifies a Dynamic Host Configuration Protocol (DHCPv4 >and DHCPv6) option for the civic (country, community and street) >location of the client or the DHCP server. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-geopriv-dhcp-civil-03.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-geopriv-dhcp-civil-03.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-geopriv-dhcp-civil-03.txt". >... >_______________________________________________ >Geopriv mailing list >Geopriv@ietf.org >https://www1.ietf.org/mailman/listinfo/geopriv _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Jul 13 06:16: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 GAA28581; Tue, 13 Jul 2004 06:16: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 1BkKCj-0004FF-Sq; Tue, 13 Jul 2004 06:08:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BkK6H-0002GN-9y for dhcwg@megatron.ietf.org; Tue, 13 Jul 2004 06:01:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27390 for ; Tue, 13 Jul 2004 06:01:22 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BkK6E-0005pZ-VM for dhcwg@ietf.org; Tue, 13 Jul 2004 06:01:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BkK5L-0005Wu-00 for dhcwg@ietf.org; Tue, 13 Jul 2004 06:00:28 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BkK4L-0004wh-00 for dhcwg@ietf.org; Tue, 13 Jul 2004 05:59:25 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-1.cisco.com with ESMTP; 13 Jul 2004 02:59:43 -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 i6D9wr36023121 for ; Tue, 13 Jul 2004 02:58:54 -0700 (PDT) Received: from rdroms-w2k01.cisco.com (che-vpn-cluster-2-77.cisco.com [10.86.242.77]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AKB82335; Tue, 13 Jul 2004 05:57:41 -0400 (EDT) Message-Id: <4.3.2.7.2.20040713055429.00c56448@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 13 Jul 2004 05:55:02 -0400 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [dhcwg] dhc WG last call on draft-ietf-dhc-rapid-commit-opt-05 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 WG last call on "Rapid Commit Option for DHCPv4" . The last call will conclude at 1700 EDT, 2004-07-30. 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. "Rapid Commit Option for DHCPv4" defines a new DHCPv4 option, modeled on the DHCPv6 Rapid Commit option, for obtaining IP address and configuration information using a 2-message exchange rather than the usual 4-message exchange, expediting client configuration. . This draft is available as http://www.ietf.org/internet-drafts/draft-ietf-dhc-rapid-commit-opt-05.txt - Ralph Droms _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Jul 13 06:19: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 GAA28721; Tue, 13 Jul 2004 06:19: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 1BkKCz-0004H0-Gr; Tue, 13 Jul 2004 06:08:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BkK8F-0002fo-E1 for dhcwg@megatron.ietf.org; Tue, 13 Jul 2004 06:03:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27478 for ; Tue, 13 Jul 2004 06:03:24 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BkK8D-0006Rm-2q for dhcwg@ietf.org; Tue, 13 Jul 2004 06:03:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BkK7H-000698-00 for dhcwg@ietf.org; Tue, 13 Jul 2004 06:02:27 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BkK6P-0005Yn-00 for dhcwg@ietf.org; Tue, 13 Jul 2004 06:01:33 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-1.cisco.com with ESMTP; 13 Jul 2004 03:01:52 -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 i6DA13ZU016283 for ; Tue, 13 Jul 2004 03:01:03 -0700 (PDT) Received: from rdroms-w2k01.cisco.com (che-vpn-cluster-2-77.cisco.com [10.86.242.77]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AKB82416; Tue, 13 Jul 2004 06:01:02 -0400 (EDT) Message-Id: <4.3.2.7.2.20040713055938.02c1de60@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 13 Jul 2004 06:00:14 -0400 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [dhcwg] dhc WG last call on draft-ietf-dhc-v4-threat-analysis-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 This message announces a WG last call on "Dynamic Host Configuration Protocol for IPv4 (DHCPv4) Threat Analysis" . The last call will conclude at (insert date here). 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 From dhcwg-bounces@ietf.org Tue Jul 13 08:01: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 IAA03665; Tue, 13 Jul 2004 08:01: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 1BkLtt-0005aR-Ez; Tue, 13 Jul 2004 07:56:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BkLse-0005Gh-7u for dhcwg@megatron.ietf.org; Tue, 13 Jul 2004 07:55:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03375 for ; Tue, 13 Jul 2004 07:55:27 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BkLsd-0000p5-Of for dhcwg@ietf.org; Tue, 13 Jul 2004 07:55:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BkLrj-0000XP-00 for dhcwg@ietf.org; Tue, 13 Jul 2004 07:54:32 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx with esmtp (Exim 4.12) id 1BkLr5-0000Dm-00 for dhcwg@ietf.org; Tue, 13 Jul 2004 07:53:51 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 13 Jul 2004 07:53:33 -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 i6DBrIaG000431; Tue, 13 Jul 2004 07:53:19 -0400 (EDT) Received: from volzw2k (che-vpn-cluster-2-47.cisco.com [10.86.242.47]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AKB85494; Tue, 13 Jul 2004 07:53:17 -0400 (EDT) From: "Bernie Volz" To: "'Ralph Droms'" , Subject: RE: [dhcwg] dhc WG last call on draft-ietf-dhc-rapid-commit-opt-05 Date: Tue, 13 Jul 2004 07:53:17 -0400 Organization: Cisco Message-ID: <001401c468cf$fcb11840$0bfe7044@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 In-Reply-To: <4.3.2.7.2.20040713055429.00c56448@flask.cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4939.300 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 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 support moving this document forward (but why wouldn't I as one of the authors). Please do note that there is an IPR claim against this draft, but before = you flame, please see http://www.ietf.org/ietf/IPR/samsung-ipr-draft-ietf-dhc-rapid-commit-opt.= txt . (And, I had nothing to do with this IPR claim.) - Bernie > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org]=20 > On Behalf Of Ralph Droms > Sent: Tuesday, July 13, 2004 5:55 AM > To: dhcwg@ietf.org > Subject: [dhcwg] dhc WG last call on=20 > draft-ietf-dhc-rapid-commit-opt-05 >=20 >=20 > This message announces a WG last call on "Rapid Commit Option=20 > for DHCPv4" . The last=20 > call will conclude at 1700 EDT, 2004-07-30. >=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 > "Rapid Commit Option for DHCPv4" defines a new DHCPv4 option,=20 > modeled on the DHCPv6 Rapid Commit option, for obtaining IP=20 > address and configuration information using a 2-message=20 > exchange rather than the usual 4-message exchange, expediting=20 > client configuration. . This draft is available as=20 http://www.ietf.org/internet-drafts/draft-ietf-dhc-rapid-commit-opt-05.tx= t - Ralph Droms=20 _______________________________________________ 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 Jul 13 10:30: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 KAA14517; Tue, 13 Jul 2004 10:30: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 1BkODa-0005H1-1O; Tue, 13 Jul 2004 10:25:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BkO2I-0000vh-1A for dhcwg@megatron.ietf.org; Tue, 13 Jul 2004 10:13:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12934 for ; Tue, 13 Jul 2004 10:13:32 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BkO2G-0003yp-VY for dhcwg@ietf.org; Tue, 13 Jul 2004 10:13:33 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BkO1N-0003g0-00 for dhcwg@ietf.org; Tue, 13 Jul 2004 10:12:38 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BkO0R-00032G-00; Tue, 13 Jul 2004 10:11:40 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 13 Jul 2004 07:12:42 +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 i6DEB3jX023777; Tue, 13 Jul 2004 07:11:07 -0700 (PDT) Received: from rdroms-w2k01.cisco.com ([161.44.65.119]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AKB93978; Tue, 13 Jul 2004 10:11:02 -0400 (EDT) Message-Id: <4.3.2.7.2.20040713101002.02b1d168@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 13 Jul 2004 10:10:56 -0400 To: agenda@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Cc: dhcwg@ietf.org Subject: [dhcwg] *DRAFT* agenda for 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 DHC WG agenda - IETF 60 0900 Wed 2004-08-04 (tentative) (Last revised 07/13/2004 10:08 AM) ---------------------------------- Administrivia Ralph Droms 05 minutes Agenda bashing 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? Renumbering Requirements for Stateless DHCPv6 Tim Chown 15 minutes Ready for WG last call? Lifetime Option for DHCPv6 Stig Venass 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 ----------- 140 minutes _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Jul 13 12:49: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 MAA23741; Tue, 13 Jul 2004 12:49: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 1BkQDw-0003q7-2N; Tue, 13 Jul 2004 12:33:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BkQ6P-0001dx-95 for dhcwg@megatron.ietf.org; Tue, 13 Jul 2004 12:25:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21837 for ; Tue, 13 Jul 2004 12:25:54 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BkQ6O-00005c-8G for dhcwg@ietf.org; Tue, 13 Jul 2004 12:25:56 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BkQ5T-0007Wv-00 for dhcwg@ietf.org; Tue, 13 Jul 2004 12:24:59 -0400 Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx with esmtp (Exim 4.12) id 1BkQ4o-0007CF-00 for dhcwg@ietf.org; Tue, 13 Jul 2004 12:24:18 -0400 Received: from [10.0.2.3] (neubayern.net [66.93.162.100]) by toccata.fugue.com (Postfix) with ESMTP id 47E8A1B25E0; Tue, 13 Jul 2004 11:16:36 -0500 (CDT) In-Reply-To: <001401c468cf$fcb11840$0bfe7044@amer.cisco.com> References: <001401c468cf$fcb11840$0bfe7044@amer.cisco.com> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <13E2863E-D4E9-11D8-86FA-000A95D9C74C@nominum.com> Content-Transfer-Encoding: 7bit From: Ted Lemon Subject: Re: [dhcwg] dhc WG last call on draft-ietf-dhc-rapid-commit-opt-05 Date: Tue, 13 Jul 2004 09:24:13 -0700 To: "Bernie Volz" X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 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 Jul 13, 2004, at 4:53 AM, Bernie Volz wrote: > Please do note that there is an IPR claim against this draft, but > before you > flame, please see > http://www.ietf.org/ietf/IPR/samsung-ipr-draft-ietf-dhc-rapid-commit- > opt.txt > . (And, I had nothing to do with this IPR claim.) The Samsung IPR statement allows for royalty-free use, which is what I've been agitating for. I'm not sure why Samsung would think they had some kind of IPR on this draft, but since they've formally stated that they're not going to try to make people pay to use it, I don't see any point in arguing about it. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Jul 13 14:56: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 OAA03615; Tue, 13 Jul 2004 14:56: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 1BkSLr-0004E6-IS; Tue, 13 Jul 2004 14:50:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BkSEn-00021g-5y for dhcwg@megatron.ietf.org; Tue, 13 Jul 2004 14:42:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02961 for ; Tue, 13 Jul 2004 14:42:43 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BkSEl-00012H-SY for dhcwg@ietf.org; Tue, 13 Jul 2004 14:42:43 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BkSDo-0000ha-00 for dhcwg@ietf.org; Tue, 13 Jul 2004 14:41:44 -0400 Received: from ftp.relicore.com ([4.36.57.198]) by ietf-mx with esmtp (Exim 4.12) id 1BkSCw-00004S-00 for dhcwg@ietf.org; Tue, 13 Jul 2004 14:40:51 -0400 Received: from STEVEPC ([192.168.0.222]) by ftp.relicore.com (8.12.9/8.12.9) with SMTP id i6DIFTAZ022697; Tue, 13 Jul 2004 14:15:29 -0400 (EDT) From: "Steve Gonczi" To: "Bernie Volz" Subject: RE: [dhcwg] dhc WG last call on draft-ietf-dhc-rapid-commit-opt-05 Date: Tue, 13 Jul 2004 14:40:12 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 In-Reply-To: <001401c468cf$fcb11840$0bfe7044@amer.cisco.com> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 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 Kudos to Samsung for the new IPR statement... How do the authors feel about the following tweak to the protocol: When the Rapid commit client decides to accept an address sent via a Rapid Commit ack, it should send out a DHCPREQUEST (perhaps with the rapid commit option), similar to the classic DHC protocol. The sole purpose of this message is to notify any servers that offered addresses to release those addresses not selected. IMHO this is inexpensive to do, and solves the address tie-up issue. Cheers, Steve Gonczi _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Jul 13 22:51: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 WAA02467; Tue, 13 Jul 2004 22:51: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 1BkVP5-0000tf-7o; Tue, 13 Jul 2004 18:05:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BkTje-0007Hs-0m for dhcwg@megatron.ietf.org; Tue, 13 Jul 2004 16:18:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12121 for ; Tue, 13 Jul 2004 16:18:39 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BkTjc-0002ch-P4 for dhcwg@ietf.org; Tue, 13 Jul 2004 16:18:40 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BkTfY-0001Q9-00 for dhcwg@ietf.org; Tue, 13 Jul 2004 16:14:29 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx with esmtp (Exim 4.12) id 1BkTaq-0007jh-00 for dhcwg@ietf.org; Tue, 13 Jul 2004 16:09:36 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 13 Jul 2004 16:09:23 -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 i6DK93N9004866; Tue, 13 Jul 2004 16:09:03 -0400 (EDT) Received: from volzw2k ([161.44.65.208]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AKC26500; Tue, 13 Jul 2004 16:09:03 -0400 (EDT) From: "Bernie Volz" To: "'Steve Gonczi'" Subject: RE: [dhcwg] dhc WG last call on draft-ietf-dhc-rapid-commit-opt-05 Date: Tue, 13 Jul 2004 16:09:03 -0400 Organization: Cisco Message-ID: <001c01c46915$3ea50b90$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: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4939.300 Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 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 If you want to do something like this, just set the lease time to a small value - the client will then renew. This works just as well - it gets the client the address quickly and recovers unused addresses relatively quickly (most servers will hold offerred addresses for several minutes to allow a client to request the address, so this isn't much different). - Bernie > -----Original Message----- > From: Steve Gonczi [mailto:steve@relicore.com] > Sent: Tuesday, July 13, 2004 2:40 PM > To: Bernie Volz > Cc: dhcwg@ietf.org > Subject: RE: [dhcwg] dhc WG last call on > draft-ietf-dhc-rapid-commit-opt-05 > > > Kudos to Samsung for the new IPR statement... > > How do the authors feel about the following tweak > to the protocol: > > When the Rapid commit client decides to accept an address > sent via a Rapid Commit ack, it should send out a DHCPREQUEST > (perhaps with the rapid commit option), > similar to the classic DHC protocol. > > The sole purpose of this message is to notify any servers that > offered addresses to release those addresses not selected. > > IMHO this is inexpensive to do, and solves the address > tie-up issue. > > Cheers, > > Steve Gonczi > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Jul 13 23:48: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 XAA08815; Tue, 13 Jul 2004 23:48: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 1BkZpZ-0002cG-SL; Tue, 13 Jul 2004 22:49:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BkVJC-0004hu-OV for dhcwg@megatron.ietf.org; Tue, 13 Jul 2004 17:59:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25138 for ; Tue, 13 Jul 2004 17:59:28 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BkVJB-00045T-C3 for dhcwg@ietf.org; Tue, 13 Jul 2004 17:59:29 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BkVH2-0003ET-00 for dhcwg@ietf.org; Tue, 13 Jul 2004 17:57:16 -0400 Received: from mailout3.samsung.com ([203.254.224.33]) by ietf-mx with esmtp (Exim 4.12) id 1BkVEG-0002Qs-00 for dhcwg@ietf.org; Tue, 13 Jul 2004 17:54:24 -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 <0I0T00J018TT2V@mailout3.samsung.com> for dhcwg@ietf.org; Wed, 14 Jul 2004 06:53:53 +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 <0I0T00F658TSLT@mailout3.samsung.com> for dhcwg@ietf.org; Wed, 14 Jul 2004 06:53:53 +0900 (KST) Received: from ep_spt02 (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 <0I0T009E78TSB3@ms3.samsung.com> for dhcwg@ietf.org; Wed, 14 Jul 2004 06:53:52 +0900 (KST) Content-return: prohibited Date: Tue, 13 Jul 2004 21:54:05 +0000 (GMT) From: PARK SOO HONG Subject: Re: RE: [dhcwg] dhc WG last call on draft-ietf-dhc-rapid-commit-opt-05 X-Sender: =?windows-1252?B?U2Ftc3VuZyBFbGVjdHJvbmljcz9Nb2Jp?= =?windows-1252?B?bGUgUGxhdGZvcm0gTGFiP0VuZ2luZWVy?= To: Steve Gonczi , soohong.park@samsung.com Message-id: <0I0T009E88TSB3@ms3.samsung.com> MIME-version: 1.0 X-Priority: 3 Msgkey: 20040713215352010@soohong.park X-MTR: 20040713215352010@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-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.5 required=5.0 tests=AWL,HTML_40_50,HTML_MESSAGE, MIME_HTML_ONLY,PRIORITY_NO_NAME autolearn=no version=2.60 Cc: "dhcwg@ietf.org " , Bernie Volz 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="===============0891614217==" Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org --===============0891614217== Content-return: prohibited Content-type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7BIT Samsung Enterprise Portal mySingle

Hi Steve, thanks your comments and see my comment inline

 

>When the Rapid commit client decides to accept an address
>sent via a Rapid Commit ack, it should send out a DHCPREQUEST
>(perhaps with the rapid commit option), 
>similar to the classic DHC protocol. 

 

I'd keep the original sentence since to sync the operation of DHCPv6,

also make sure this option is for *RAPID COMMIT*.

 

 

 

Regards

 

Daniel (Soohong Daniel Park)

Mobile Platform Laboratory. SAMSUNG Electronics


--===============0891614217== 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 --===============0891614217==-- From dhcwg-bounces@ietf.org Wed Jul 14 00: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 AAA09814; Wed, 14 Jul 2004 00: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 1BkaHw-00055W-Gg; Tue, 13 Jul 2004 23:18:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BkWzz-0007YB-Bs for dhcwg@megatron.ietf.org; Tue, 13 Jul 2004 19:47:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09922 for ; Tue, 13 Jul 2004 19:47:41 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BkWzv-0000tL-H6 for dhcwg@ietf.org; Tue, 13 Jul 2004 19:47:43 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BkWuN-0007DB-00 for dhcwg@ietf.org; Tue, 13 Jul 2004 19:42:01 -0400 Received: from ftp.relicore.com ([4.36.57.198]) by ietf-mx with esmtp (Exim 4.12) id 1BkWnq-0005U5-00 for dhcwg@ietf.org; Tue, 13 Jul 2004 19:35:14 -0400 Received: from STEVEPC ([192.168.0.222]) by ftp.relicore.com (8.12.9/8.12.9) with SMTP id i6DNA1AZ023293; Tue, 13 Jul 2004 19:10:01 -0400 (EDT) From: "Steve Gonczi" To: Subject: RE: RE: [dhcwg] dhc WG last call on draft-ietf-dhc-rapid-commit-opt-05 Date: Tue, 13 Jul 2004 19:34:44 -0400 Message-ID: MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 In-Reply-To: <0I0T009E88TSB3@ms3.samsung.com> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,HTML_50_60, HTML_FONTCOLOR_BLUE,HTML_MESSAGE autolearn=no version=2.60 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: , Content-Type: multipart/mixed; boundary="===============0672991952==" Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org This is a multi-part message in MIME format. --===============0672991952== Content-Type: multipart/alternative; boundary="----=_NextPart_000_00C4_01C46910.732F2800" This is a multi-part message in MIME format. ------=_NextPart_000_00C4_01C46910.732F2800 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit Samsung Enterprise Portal mySingleHi Daniel, I have to admit I am not entirely clear on what you meant, although I suspect you disagree with my suggestion. Let me try to make my case: For the cost of sending out one extra message by the Rapid Commit client (which BTW does not cause any significant delay) you could eliminate the entire 3.2 section from your protocol. To recap: 1) The "no multiple servers" restriction 2) or "must have enough addresses" restriction 3) or "use short lease times" restriction Why would you not want to do this? /sG -----Original Message----- From: PARK SOO HONG [mailto:soohong.park@samsung.com] Sent: Tuesday, July 13, 2004 5:54 PM To: Steve Gonczi; soohong.park@samsung.com Cc: Bernie Volz; dhcwg@ietf.org Subject: Re: RE: [dhcwg] dhc WG last call on draft-ietf-dhc-rapid-commit-opt-05 Hi Steve, thanks your comments and see my comment inline >When the Rapid commit client decides to accept an address >sent via a Rapid Commit ack, it should send out a DHCPREQUEST >(perhaps with the rapid commit option), >similar to the classic DHC protocol. I'd keep the original sentence since to sync the operation of DHCPv6, also make sure this option is for *RAPID COMMIT*. Regards Daniel (Soohong Daniel Park) Mobile Platform Laboratory. SAMSUNG Electronics ------=_NextPart_000_00C4_01C46910.732F2800 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Samsung Enterprise Portal mySingle
Hi=20 Daniel,
 
I have=20 to admit I am not entirely clear on what you meant,
although I suspect you disagree = with my=20 suggestion.
 
Let me=20 try to make my case:
 
For=20 the cost of sending out one extra message by the Rapid=20 Commit
client=20 (which BTW does not cause any significant delay)
you=20 could eliminate the entire 3.2 section from your=20 protocol.
 
To=20 recap:
 
1)  The "no multiple servers"=20 restriction
2)  or "must have enough addresses" = restriction
3)  or "use short lease times"=20 restriction
 
Why=20 would you not want to do this?
 
 
/sG
-----Original Message-----
From: PARK SOO HONG=20 [mailto:soohong.park@samsung.com]
Sent: Tuesday, July 13, = 2004 5:54=20 PM
To: Steve Gonczi; soohong.park@samsung.com
Cc: = Bernie=20 Volz; dhcwg@ietf.org
Subject: Re: RE: [dhcwg] dhc WG last = call on=20 draft-ietf-dhc-rapid-commit-opt-05

Hi Steve, thanks your comments and see my comment inline=20

 

=

>When the Rapid commit client decides = ;to accept an address=20 =
>sent via a Rapid Commit ack, it&nbs= p;should send out a DHCPREQUEST=20 =
>(perhaps with the rapid commit option),&= nbsp;=20 =
>similar to the classic DHC protocol.&nbs= p;=20

 

I'd keep the original sentence since to sync the operation of=20 DHCPv6,

also make sure this option is for *RAPID COMMIT*.

 

 

 

Regards

 

Daniel (Soohong Daniel Park)

Mobile Platform Laboratory. SAMSUNG=20 Electronics


------=_NextPart_000_00C4_01C46910.732F2800-- --===============0672991952== 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 --===============0672991952==-- From dhcwg-bounces@ietf.org Wed Jul 14 00:30: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 AAA14055; Wed, 14 Jul 2004 00:30: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 1BkbJk-0000Au-Um; Wed, 14 Jul 2004 00:24:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BkbAF-0001Mq-75 for dhcwg@megatron.ietf.org; Wed, 14 Jul 2004 00:14:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA11422 for ; Wed, 14 Jul 2004 00:14:36 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BkbAD-0003Ms-7o for dhcwg@ietf.org; Wed, 14 Jul 2004 00:14:37 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BkaZ2-0004kE-00 for dhcwg@ietf.org; Tue, 13 Jul 2004 23:36:14 -0400 Received: from [210.22.146.172] (helo=asbmx.sbell.com.cn) by ietf-mx with esmtp (Exim 4.12) id 1Bka1T-0007FK-00 for dhcwg@ietf.org; Tue, 13 Jul 2004 23:01:37 -0400 Received: from asbwebshld.sbell.com.cn (asbwebshld [172.24.208.38]) by asbmx.sbell.com.cn (8.12.10+Sun/8.12.3) with SMTP id i6E2udMK017966 for ; Wed, 14 Jul 2004 10:56:42 +0800 (CST) Received: FROM bellnet-mail4.sbell.com.cn BY asbwebshld.sbell.com.cn ; Wed Jul 14 11:00:46 2004 +0800 Received: from BELLNET-MAIL3.sbell.com.cn ([172.24.208.23]) by bellnet-mail4.sbell.com.cn with Microsoft SMTPSVC(5.0.2195.6713); Wed, 14 Jul 2004 11:00:46 +0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Date: Wed, 14 Jul 2004 11:00:45 +0800 Message-ID: <8634B809B90D6E4AACA4AB0562A1F07205ED76@bellnet-mail3.sbell.com.cn> Thread-Index: AcRpTsar2Adupie/SwKT86ndO464gA== From: "CTO YAN Renxiang" To: X-OriginalArrivalTime: 14 Jul 2004 03:00:46.0253 (UTC) FILETIME=[C25E1DD0:01C4694E] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Cc: dhcwg@ietf.org 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 Content-Transfer-Encoding: quoted-printable Hi, Bernie, I don't think domain name search list option defined in RFC3646 can = transfer the DNS zone suffix which is used by host to update the FQDN without any = modification. In section4 of RFC3646, it states: "The Domain Search List option specifies the domain search list the = client is to use when resolving hostnames with DNS." The initial purpose of domain search list option is hostname resolving, = not domain name update. Furthermore, the domain name listed in the Domain Search List = option can be different from the DNS zone suffix the client needed to update its = domain name. Even if Domain Search List option can be used in domain name update, we = have to define a mechanism to choose a correct domain name from domain search = list. To sum up, two choices exist to make it possible for IPv6 client to = dynamically update its domain name: 1. define another option to transfer DNS zone suffix to client, which = enables the client generates its FQDN, as defined in = http://www.ietf.org/internet-drafts/draft-yan-dhc-dhcpv6-opt-dnszone-00.t= xt. 2. define a mechanism to choose a domain name as DNS zone suffix from = domain search list, and use it to generate and update client's FQDN -Renxiang P.S. In order to foster a discussion on this topic, I am CCing this = mail to DHC list, I would be appreciated any value comments from experts in the list. -----=D4=AD=CA=BC=D3=CA=BC=FE----- =B7=A2=BC=FE=C8=CB: Bernie Volz [mailto:volz@cisco.com] =B7=A2=CB=CD=CA=B1=BC=E4: 2004=C4=EA7=D4=C213=C8=D5 10:38 =CA=D5=BC=FE=C8=CB: CTO YAN Renxiang =D6=F7=CC=E2: RE: about your draft The Client FQDN option sends the fully qualified domain name. There is = no indication of which is the host portion and which is the domain name. In general, this really isn't that useful. In DHCPv6, we already have the domain name search list option (see http://www.ietf.org/rfc/rfc3646.txt). This is generally much more useful than just the "domain name" and, in DHCPv4 it is generally the domain = name that is used as the default domain search list. So, if a client receives the Client FQDN option with a fully qualified domain name, it can figure out the host name portion by using the domain search list, if it really cares. Or, it can do DNS lookups. - Bernie > -----Original Message----- > From: CTO YAN Renxiang [mailto:Renxiang.Yan@alcatel-sbell.com.cn] > Sent: Monday, July 12, 2004 8:38 PM > To: Bernie Volz > Subject: re: about your draft > > > Hi, Bernie, > > In DHCPv4, the domain name is tranferred using option 15 > (domain name) defined in 2132. However, DHCPv6 does not > defined such an option. How does your draft implement? could > you explain in a bit detail? > > regards, > -renxiang > > -----=D4=AD=CA=BC=D3=CA=BC=FE----- > =B7=A2=BC=FE=C8=CB: Bernie Volz [mailto:volz@cisco.com] > =B7=A2=CB=CD=CA=B1=BC=E4: 2004=C4=EA7=D4=C212=C8=D5 21:28 > =CA=D5=BC=FE=C8=CB: CTO YAN Renxiang > =D6=F7=CC=E2: RE: about your draft > > > Hi: > > The draft should appear at the IETF web site shortly. > Sometimes the announcement preceeds the upload to the web/ftp > site(s), so give it a day or two and it should appear. > > The option is modeled after the DHCPv4 Client FQDN option. > > - Bernie > > > -----Original Message----- > > From: CTO YAN Renxiang [mailto:Renxiang.Yan@alcatel-sbell.com.cn] > > Sent: Sunday, July 11, 2004 11:35 PM > > To: volz@cisco.com > > Subject: about your draft > > > > > > Hi Bernie, > > > > I found you will make presentation on 60th IETF meeting about > > the DHCP FQDN option. I can't find the draft "The DHCPv6 > > Client FQDN Option" on website. Could you send me > > the link? > > > > I wrote a draft "DNS zone suffix option for DHCPv6" to allow > > DHCPv6 server transfer the DNS zone suffix to DHCPv6 client. > > I wonder there will be close relationship between our drafts, > > so could you tell me how to tranfer the DNS suffix in your draft? > > > > Thank you! > > > > regards, > > -Renxiang > > > cn=20 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Jul 14 00:44: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 AAA17092; Wed, 14 Jul 2004 00:44: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 1BkbY5-0000gE-Ny; Wed, 14 Jul 2004 00:39:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BkbTO-0005uR-Vn for dhcwg@megatron.ietf.org; Wed, 14 Jul 2004 00:34:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA14880 for ; Wed, 14 Jul 2004 00:34:23 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BkbTN-0006tq-09 for dhcwg@ietf.org; Wed, 14 Jul 2004 00:34:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bkauh-0000b7-00 for dhcwg@ietf.org; Tue, 13 Jul 2004 23:58:37 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BkaJP-0001u4-00 for dhcwg@ietf.org; Tue, 13 Jul 2004 23:20:03 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 13 Jul 2004 20:21:13 +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 i6E3J96i003229; Tue, 13 Jul 2004 20:19:31 -0700 (PDT) Received: from volzw2k (che-vpn-cluster-2-109.cisco.com [10.86.242.109]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AKC51266; Tue, 13 Jul 2004 23:19:07 -0400 (EDT) From: "Bernie Volz" To: "'CTO YAN Renxiang'" Date: Tue, 13 Jul 2004 23:19:07 -0400 Organization: Cisco Message-ID: <001101c46951$52f19cd0$4bfeba44@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.5709 In-Reply-To: <8634B809B90D6E4AACA4AB0562A1F07205ED76@bellnet-mail3.sbell.com.cn> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4939.300 Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Cc: dhcwg@ietf.org Subject: [dhcwg] RE: Client FQDN 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 Why? The DHCP server will return the fully qualified domain name for each = address to the client (if appropriate). With this and if you know the how to = reach a DNS server, you can find out where the zone cut is. Ask for NS RRs with = the fully qualified domain name; if that doesn't return any, remove the = first component (ie, for a.b.test.com, remove a) and try the resulting domain = ... Keep going until you find the NS records or you run out of domain names. = If you find NS records, try the updates to the one or more servers. Nothing more needed. Now, agreed, that if the DHCP server doesn't return the Client FQDN = option for a address, then the DHCP client will need something for it to use. = And, lacking anything else, using the DNS search list probably isn't that bad = an idea. - Bernie > -----Original Message----- > From: CTO YAN Renxiang [mailto:Renxiang.Yan@alcatel-sbell.com.cn]=20 > Sent: Tuesday, July 13, 2004 11:01 PM > To: volz@cisco.com > Cc: dhcwg@ietf.org > Subject:=20 >=20 >=20 > Hi, Bernie, >=20 > I don't think domain name search list option defined in=20 > RFC3646 can transfer the DNS zone suffix which is used by=20 > host to update the FQDN without any modification. >=20 > In section4 of RFC3646, it states: > "The Domain Search List option specifies the domain search=20 > list the client is to use when resolving hostnames with DNS." >=20 > The initial purpose of domain search list option is hostname=20 > resolving, not domain name update. Furthermore, the domain=20 > name listed in the Domain Search List option can be different=20 > from the DNS zone suffix the client needed to update its domain name. >=20 > Even if Domain Search List option can be used in domain name=20 > update, we have to define a mechanism to choose a correct=20 > domain name from domain search list. >=20 > To sum up, two choices exist to make it possible for IPv6=20 > client to dynamically update its domain name: 1. define=20 > another option to transfer DNS zone suffix to client, which=20 > enables the client generates its FQDN, as defined in=20 > http://www.ietf.org/internet-drafts/draft-yan-dhc-dhcpv6-opt-d > nszone-00.txt. > 2. define a mechanism to choose a domain name as DNS zone=20 > suffix from domain search list, and use it to generate and=20 > update client's FQDN >=20 > -Renxiang >=20 > P.S. In order to foster a discussion on this topic, I am=20 > CCing this mail to DHC list, I would be appreciated any=20 > value comments from experts in the list. >=20 >=20 > -----=D4=AD=CA=BC=D3=CA=BC=FE----- > =B7=A2=BC=FE=C8=CB: Bernie Volz [mailto:volz@cisco.com] > =B7=A2=CB=CD=CA=B1=BC=E4: 2004=C4=EA7=D4=C213=C8=D5 10:38 > =CA=D5=BC=FE=C8=CB: CTO YAN Renxiang > =D6=F7=CC=E2: RE: about your draft >=20 >=20 > The Client FQDN option sends the fully qualified domain name.=20 > There is no indication of which is the host portion and which=20 > is the domain name. In general, this really isn't that useful. >=20 > In DHCPv6, we already have the domain name search list option=20 > (see http://www.ietf.org/rfc/rfc3646.txt). This is generally=20 > much more useful than just the "domain name" and, in DHCPv4=20 > it is generally the domain name that is used as the default=20 > domain search list. >=20 > So, if a client receives the Client FQDN option with a fully=20 > qualified domain name, it can figure out the host name=20 > portion by using the domain search list, if it really cares.=20 > Or, it can do DNS lookups. >=20 > - Bernie >=20 > > -----Original Message----- > > From: CTO YAN Renxiang [mailto:Renxiang.Yan@alcatel-sbell.com.cn] > > Sent: Monday, July 12, 2004 8:38 PM > > To: Bernie Volz > > Subject: re: about your draft > > > > > > Hi, Bernie, > > > > In DHCPv4, the domain name is tranferred using option 15=20 > (domain name)=20 > > defined in 2132. However, DHCPv6 does not defined such an=20 > option. How=20 > > does your draft implement? could you explain in a bit detail? > > > > regards, > > -renxiang > > > > -----=D4=AD=CA=BC=D3=CA=BC=FE----- > > =B7=A2=BC=FE=C8=CB: Bernie Volz [mailto:volz@cisco.com] > > =B7=A2=CB=CD=CA=B1=BC=E4: 2004=C4=EA7=D4=C212=C8=D5 21:28 > > =CA=D5=BC=FE=C8=CB: CTO YAN Renxiang > > =D6=F7=CC=E2: RE: about your draft > > > > > > Hi: > > > > The draft should appear at the IETF web site shortly. Sometimes the=20 > > announcement preceeds the upload to the web/ftp site(s), so=20 > give it a=20 > > day or two and it should appear. > > > > The option is modeled after the DHCPv4 Client FQDN option. > > > > - Bernie > > > > > -----Original Message----- > > > From: CTO YAN Renxiang [mailto:Renxiang.Yan@alcatel-sbell.com.cn] > > > Sent: Sunday, July 11, 2004 11:35 PM > > > To: volz@cisco.com > > > Subject: about your draft > > > > > > > > > Hi Bernie, > > > > > > I found you will make presentation on 60th IETF meeting about the=20 > > > DHCP FQDN option. I can't find the draft "The DHCPv6 Client FQDN=20 > > > Option" on website. Could you send me the link? > > > > > > I wrote a draft "DNS zone suffix option for DHCPv6" to=20 > allow DHCPv6=20 > > > server transfer the DNS zone suffix to DHCPv6 client. I=20 > wonder there=20 > > > will be close relationship between our drafts, so could=20 > you tell me=20 > > > how to tranfer the DNS suffix in your draft? > > > > > > Thank you! > > > > > > regards, > > > -Renxiang > > > > > cn >=20 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Jul 14 08:35: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 IAA12250; Wed, 14 Jul 2004 08: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 1Bkins-0004Xi-By; Wed, 14 Jul 2004 08:24:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bkij9-0002hH-W0 for dhcwg@megatron.ietf.org; Wed, 14 Jul 2004 08:19:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11750 for ; Wed, 14 Jul 2004 08:19:10 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bkij9-0005W2-I0 for dhcwg@ietf.org; Wed, 14 Jul 2004 08:19:11 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BkiiL-0005D6-00 for dhcwg@ietf.org; Wed, 14 Jul 2004 08:18:22 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx with esmtp (Exim 4.12) id 1Bkiht-0004tc-00 for dhcwg@ietf.org; Wed, 14 Jul 2004 08:17:53 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 14 Jul 2004 08:17:24 -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 i6ECHKaG011597; Wed, 14 Jul 2004 08:17:20 -0400 (EDT) Received: from volzw2k (che-vpn-cluster-2-109.cisco.com [10.86.242.109]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AKC64675; Wed, 14 Jul 2004 08:17:18 -0400 (EDT) From: "Bernie Volz" To: "'Steve Gonczi'" , Subject: RE: RE: [dhcwg] dhc WG last call on draft-ietf-dhc-rapid-commit-opt-05 Date: Wed, 14 Jul 2004 08:17:18 -0400 Organization: Cisco Message-ID: <000c01c4699c$81c34810$4bfeba44@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: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4939.300 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,HTML_40_50, HTML_FONTCOLOR_BLUE,HTML_MESSAGE autolearn=no version=2.60 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: , Content-Type: multipart/mixed; boundary="===============1038720786==" Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org This is a multi-part message in MIME format. --===============1038720786== Content-Type: multipart/alternative; boundary="----=_NextPart_000_000D_01C4697A.FAB1A810" This is a multi-part message in MIME format. ------=_NextPart_000_000D_01C4697A.FAB1A810 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit This likely isn't as a cut and dry as you assume. Does the DHCPREQUEST get retransmitted until it is ACKed? What happens if it isn't ACKed? What happens if it is NAK? - Bernie -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Steve Gonczi Sent: Tuesday, July 13, 2004 7:35 PM To: soohong.park@samsung.com Cc: dhcwg@ietf.org Subject: RE: RE: [dhcwg] dhc WG last call on draft-ietf-dhc-rapid-commit-opt-05 Hi Daniel, I have to admit I am not entirely clear on what you meant, although I suspect you disagree with my suggestion. Let me try to make my case: For the cost of sending out one extra message by the Rapid Commit client (which BTW does not cause any significant delay) you could eliminate the entire 3.2 section from your protocol. To recap: 1) The "no multiple servers" restriction 2) or "must have enough addresses" restriction 3) or "use short lease times" restriction Why would you not want to do this? /sG -----Original Message----- From: PARK SOO HONG [mailto:soohong.park@samsung.com] Sent: Tuesday, July 13, 2004 5:54 PM To: Steve Gonczi; soohong.park@samsung.com Cc: Bernie Volz; dhcwg@ietf.org Subject: Re: RE: [dhcwg] dhc WG last call on draft-ietf-dhc-rapid-commit-opt-05 Hi Steve, thanks your comments and see my comment inline >When the Rapid commit client decides to accept an address >sent via a Rapid Commit ack, it should send out a DHCPREQUEST >(perhaps with the rapid commit option), >similar to the classic DHC protocol. I'd keep the original sentence since to sync the operation of DHCPv6, also make sure this option is for *RAPID COMMIT*. Regards Daniel (Soohong Daniel Park) Mobile Platform Laboratory. SAMSUNG Electronics ------=_NextPart_000_000D_01C4697A.FAB1A810 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
This=20 likely isn't as a cut and dry as you assume. Does the DHCPREQUEST get=20 retransmitted until it is ACKed? What happens if it isn't ACKed? What = happens if=20 it is NAK?
 
-=20 Bernie
-----Original Message-----
From:=20 dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of = Steve Gonczi
Sent: Tuesday, July 13, 2004 7:35 = PM
To:=20 soohong.park@samsung.com
Cc: = dhcwg@ietf.org
Subject: RE:=20 RE: [dhcwg] dhc WG last call on=20 draft-ietf-dhc-rapid-commit-opt-05

Hi=20 Daniel,
 
I=20 have to admit I am not entirely clear on what you meant, =
although I suspect you disagree = with my=20 suggestion.
 
Let=20 me try to make my case:
 
For=20 the cost of sending out one extra message by the Rapid=20 Commit
client (which BTW does not cause any = significant=20 delay)
you=20 could eliminate the entire 3.2 section from your=20 protocol.
 
To=20 recap:
 
1)  The "no multiple servers"=20 restriction
2)  or "must have enough = addresses"=20 restriction
3)  or "use short lease times"=20 restriction
 
Why=20 would you not want to do this?
 
 
/sG
-----Original Message-----
From: PARK SOO HONG=20 [mailto:soohong.park@samsung.com]
Sent: Tuesday, July 13, = 2004=20 5:54 PM
To: Steve Gonczi; = soohong.park@samsung.com
Cc:=20 Bernie Volz; dhcwg@ietf.org
Subject: Re: RE: [dhcwg] dhc = WG last=20 call on draft-ietf-dhc-rapid-commit-opt-05

Hi Steve, thanks your comments and see my comment inline=20

 

=

>When the Rapid commit client decides = ;to accept an address=20 =
>sent via a Rapid Commit ack, it&nbs= p;should send out a DHCPREQUEST=20 =
>(perhaps with the rapid commit option),&= nbsp;=20 =
>similar to the classic DHC protocol.&nbs= p;=20

 

I'd keep the original sentence since to sync the operation = of=20 DHCPv6,

also make sure this option is for *RAPID COMMIT*.

 

 

 

Regards

 

Daniel (Soohong Daniel Park)

Mobile Platform Laboratory. SAMSUNG=20 Electronics


------=_NextPart_000_000D_01C4697A.FAB1A810-- --===============1038720786== 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 --===============1038720786==-- From dhcwg-bounces@ietf.org Wed Jul 14 09:15: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 JAA14921; Wed, 14 Jul 2004 09:15: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 1BkjVx-0000pL-Dr; Wed, 14 Jul 2004 09:09:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BkjRC-0007CB-EX for dhcwg@megatron.ietf.org; Wed, 14 Jul 2004 09:04:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14027 for ; Wed, 14 Jul 2004 09:04:40 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BkjRB-0005ET-S8 for dhcwg@ietf.org; Wed, 14 Jul 2004 09:04:41 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BkjQ6-0004sg-00 for dhcwg@ietf.org; Wed, 14 Jul 2004 09:03:35 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1BkjPY-0004Tz-00 for dhcwg@ietf.org; Wed, 14 Jul 2004 09:03:01 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-5.cisco.com with ESMTP; 14 Jul 2004 06:03:42 -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 i6ED2Me8027019; Wed, 14 Jul 2004 06:02:23 -0700 (PDT) Received: from mjs-xp.cisco.com ([161.44.65.118]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AKC66653; Wed, 14 Jul 2004 09:02:21 -0400 (EDT) Message-Id: <4.3.2.7.2.20040714085855.01d19710@goblet.cisco.com> X-Sender: mjs@goblet.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 14 Jul 2004 09:02:00 -0400 To: "Bernie Volz" From: Mark Stapp Subject: RE: RE: [dhcwg] dhc WG last call on draft-ietf-dhc-rapid-commit-opt-05 In-Reply-To: <000c01c4699c$81c34810$4bfeba44@amer.cisco.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.2 required=5.0 tests=AWL,OPT_HEADER autolearn=no version=2.60 Cc: dhcwg@ietf.org, soohong.park@samsung.com, "'Steve Gonczi'" 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 Bernie. It's true that sending the extra 'REQUEST' is inexpensive, but it's just another unreliable UDP packet. I don't think that the suggested extra step provides enough benefit to be worth including. -- Mark At 08:17 AM 7/14/2004 -0400, Bernie Volz wrote: >This likely isn't as a cut and dry as you assume. Does the DHCPREQUEST get >retransmitted until it is ACKed? What happens if it isn't ACKed? What >happens if it is NAK? > >- Bernie >-----Original Message----- >From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of >Steve Gonczi >Sent: Tuesday, July 13, 2004 7:35 PM >To: soohong.park@samsung.com >Cc: dhcwg@ietf.org >Subject: RE: RE: [dhcwg] dhc WG last call on >draft-ietf-dhc-rapid-commit-opt-05 > >Hi Daniel, > >I have to admit I am not entirely clear on what you meant, >although I suspect you disagree with my suggestion. > >Let me try to make my case: > >For the cost of sending out one extra message by the Rapid Commit >client (which BTW does not cause any significant delay) >you could eliminate the entire 3.2 section from your protocol. > >To recap: > >1) The "no multiple servers" restriction >2) or "must have enough addresses" restriction >3) or "use short lease times" restriction > >Why would you not want to do this? > > >/sG >-----Original Message----- >From: PARK SOO HONG [mailto:soohong.park@samsung.com] >Sent: Tuesday, July 13, 2004 5:54 PM >To: Steve Gonczi; soohong.park@samsung.com >Cc: Bernie Volz; dhcwg@ietf.org >Subject: Re: RE: [dhcwg] dhc WG last call on >draft-ietf-dhc-rapid-commit-opt-05 > >Hi Steve, thanks your comments and see my comment inline > > > > >When the Rapid commit client decides to accept an address > >sent via a Rapid Commit ack, it should send out a DHCPREQUEST > >(perhaps with the rapid commit option), > >similar to the classic DHC protocol. > > > >I'd keep the original sentence since to sync the operation of DHCPv6, > >also make sure this option is for *RAPID COMMIT*. > > > > > > > >Regards > > > >Daniel (Soohong Daniel Park) > >Mobile Platform Laboratory. SAMSUNG Electronics > >_______________________________________________ >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 Jul 14 11:36: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 LAA24353; Wed, 14 Jul 2004 11:36: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 1BkljS-0006EM-N3; Wed, 14 Jul 2004 11:31:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BkleS-0005ek-4w for dhcwg@megatron.ietf.org; Wed, 14 Jul 2004 11:26:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24030 for ; Wed, 14 Jul 2004 11:26:26 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BkleO-00072J-A6 for dhcwg@ietf.org; Wed, 14 Jul 2004 11:26:28 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BkldU-0006iv-00 for dhcwg@ietf.org; Wed, 14 Jul 2004 11:25:32 -0400 Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx with esmtp (Exim 4.12) id 1Bklcf-0006OW-00 for dhcwg@ietf.org; Wed, 14 Jul 2004 11:24:42 -0400 Received: from [10.0.2.3] (neubayern.net [66.93.162.100]) by toccata.fugue.com (Postfix) with ESMTP id 730751B202C for ; Wed, 14 Jul 2004 10:16:50 -0500 (CDT) Mime-Version: 1.0 (Apple Message framework v618) In-Reply-To: <001101c46951$52f19cd0$4bfeba44@amer.cisco.com> References: <001101c46951$52f19cd0$4bfeba44@amer.cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Ted Lemon Subject: Re: [dhcwg] RE: Client FQDN Date: Wed, 14 Jul 2004 08:24:37 -0700 To: dhcwg@ietf.org X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 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 Given that this is in last call, I'm going to weigh in here too. I think that Bernie's solution to the problem Mr. Yan brings up is the right one. It requires no change to the draft, and more importantly, it provides a reliable mechanism, whereas, as Mark points out, the DHCPREQUEST message isn't reliable, and might get an unwished-for answer. So please let's advance the draft is, without the proposed change. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Jul 14 15:30: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 PAA09847; Wed, 14 Jul 2004 15:30: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 1BkpHq-0002nd-CJ; Wed, 14 Jul 2004 15:19:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BkpFu-00023e-N3 for dhcwg@megatron.ietf.org; Wed, 14 Jul 2004 15:17:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08636 for ; Wed, 14 Jul 2004 15:17:24 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BkpFt-0004FL-AR for dhcwg@ietf.org; Wed, 14 Jul 2004 15:17:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BkpEu-0003uJ-00 for dhcwg@ietf.org; Wed, 14 Jul 2004 15:16:25 -0400 Received: from ftp.relicore.com ([4.36.57.198]) by ietf-mx with esmtp (Exim 4.12) id 1BkpDv-0003JI-00 for dhcwg@ietf.org; Wed, 14 Jul 2004 15:15:23 -0400 Received: from STEVEPC ([192.168.0.222]) by ftp.relicore.com (8.12.9/8.12.9) with SMTP id i6EIo7Ab025042; Wed, 14 Jul 2004 14:50:07 -0400 (EDT) From: "Steve Gonczi" To: "Ted Lemon" Subject: RE: [dhcwg] dhc WG last call on draft-ietf-dhc-rapid-commit-opt-05 Date: Wed, 14 Jul 2004 15:14:52 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 In-Reply-To: <12FE9EE1-D54D-11D8-86FA-000A95D9C74C@fugue.com> Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ftp.relicore.com id i6EIo7Ab025042 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 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 What complexity are you talking about? How is this different from plain DHCP? Any server that could see the initial rapid commit DHCPDISCOVER will also be able to see the DHCPREQUEST. /sG -----Original Message----- From: Ted Lemon [mailto:mellon@fugue.com] Sent: Wednesday, July 14, 2004 12:20 AM To: Steve Gonczi Subject: Re: [dhcwg] dhc WG last call on draft-ietf-dhc-rapid-commit-opt-05 On Jul 13, 2004, at 4:34 PM, Steve Gonczi wrote: > For the cost of sending out one extra message by the Rapid Commit > client (which BTW does not cause any significant delay) > you could eliminate the entire 3.2 section=A0from your protocol. What Bernie was talking about was just making the initial DHCPACK have a very short lease time. Subsequent DHCPACKs could have a longer lease time. This accomplishes the same purpose that you're talking about, without the added complexity of requiring all servers to see the DHCPREQUEST you're proposing to add to the exchange. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Jul 14 15:33: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 PAA10282; Wed, 14 Jul 2004 15:33: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 1BkpI9-0002t2-My; Wed, 14 Jul 2004 15: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 1BkpFx-00024h-4b for dhcwg@megatron.ietf.org; Wed, 14 Jul 2004 15:17:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08649 for ; Wed, 14 Jul 2004 15:17:27 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BkpFv-0004Fb-UM for dhcwg@ietf.org; Wed, 14 Jul 2004 15:17:28 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BkpEz-0003uw-00 for dhcwg@ietf.org; Wed, 14 Jul 2004 15:16:30 -0400 Received: from ftp.relicore.com ([4.36.57.198]) by ietf-mx with esmtp (Exim 4.12) id 1BkpE1-0003JK-00 for dhcwg@ietf.org; Wed, 14 Jul 2004 15:15:29 -0400 Received: from STEVEPC ([192.168.0.222]) by ftp.relicore.com (8.12.9/8.12.9) with SMTP id i6EIo7AZ025042; Wed, 14 Jul 2004 14:50:07 -0400 (EDT) From: "Steve Gonczi" To: "Bernie Volz" Subject: RE: RE: [dhcwg] dhc WG last call on draft-ietf-dhc-rapid-commit-opt-05 Date: Wed, 14 Jul 2004 15:14:52 -0400 Message-ID: MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 In-Reply-To: <000c01c4699c$81c34810$4bfeba44@amer.cisco.com> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL,HTML_50_60, HTML_FONTCOLOR_BLUE,HTML_MESSAGE autolearn=no version=2.60 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: , Content-Type: multipart/mixed; boundary="===============1305774646==" Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org This is a multi-part message in MIME format. --===============1305774646== Content-Type: multipart/alternative; boundary="----=_NextPart_000_00EA_01C469B5.4FC600F0" This is a multi-part message in MIME format. ------=_NextPart_000_00EA_01C469B5.4FC600F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit MessageWould not get retransmitted, and I did not propose an ACK/ NAK. Merely a best effort DHCPREQUEST, to give any server that committed and address (but was not selected by the client) a chance to clean up. This DHCPREQUEST is not intended for the server that offered the accepted ( and committed) address. That server does not need to do anything further. BTW this is exactly how plain DHCP works today. Any server that did offer an address, and sees the DHCPREQUEST for a different address, just releases the address and there is no further action required. Neither does DHCP provide any assurance that any (not selected) server does see the DHCPREQUEST. regards, /sG -----Original Message----- From: Bernie Volz [mailto:volz@cisco.com] Sent: Wednesday, July 14, 2004 8:17 AM To: 'Steve Gonczi'; soohong.park@samsung.com Cc: dhcwg@ietf.org Subject: RE: RE: [dhcwg] dhc WG last call on draft-ietf-dhc-rapid-commit-opt-05 This likely isn't as a cut and dry as you assume. Does the DHCPREQUEST get retransmitted until it is ACKed? What happens if it isn't ACKed? What happens if it is NAK? - Berni ------=_NextPart_000_00EA_01C469B5.4FC600F0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Would=20 not get retransmitted,  and I did not propose
an ACK/ NAK.
 
Merely=20 a best effort DHCPREQUEST,  to give any server
that=20 committed and address (but was not selected by the = client)
a=20 chance to clean up.
 
This=20 DHCPREQUEST is not intended for the server that = offered
the=20 accepted ( and committed) address.
 
That=20 server does not need to do anything = further.
 
BTW=20 this is exactly how plain DHCP works today.
Any=20 server that did offer an address, and sees the = DHCPREQUEST
for a=20 different address, just releases  the address and there is no=20 further
action=20 required. Neither does DHCP provide any assurance = that
any=20 (not selected) server does see the DHCPREQUEST.
 
 
 
regards,
 
/sG
 
-----Original Message-----
From: Bernie Volz=20 [mailto:volz@cisco.com]
Sent: Wednesday, July 14, 2004 8:17=20 AM
To: 'Steve Gonczi'; = soohong.park@samsung.com
Cc:=20 dhcwg@ietf.org
Subject: RE: RE: [dhcwg] dhc WG last call on=20 draft-ietf-dhc-rapid-commit-opt-05

This=20 likely isn't as a cut and dry as you assume. Does the DHCPREQUEST get=20 retransmitted until it is ACKed? What happens if it isn't ACKed? What = happens=20 if it is NAK?
 
-=20 Berni
------=_NextPart_000_00EA_01C469B5.4FC600F0-- --===============1305774646== 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 --===============1305774646==-- From dhcwg-bounces@ietf.org Wed Jul 14 16:03: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 QAA12890; Wed, 14 Jul 2004 16:03: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 1BkpWD-0006JT-9F; Wed, 14 Jul 2004 15:34:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BkpJv-0003bK-5u; Wed, 14 Jul 2004 15:21:35 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09152; Wed, 14 Jul 2004 15:21:33 -0400 (EDT) Message-Id: <200407141921.PAA09152@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, 14 Jul 2004 15:21:32 -0400 Cc: dhcwg@ietf.org Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-auth-suboption-04.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, et al. Filename : draft-ietf-dhc-auth-suboption-04.txt Pages : 15 Date : 2004-7-14 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-04.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-04.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-04.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-7-14153853.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-auth-suboption-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-auth-suboption-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-7-14153853.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 Jul 14 16:05: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 QAA13288; Wed, 14 Jul 2004 16:05: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 1BkpWF-0006KR-Vs; Wed, 14 Jul 2004 15:34:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BkpKO-0003hZ-0x; Wed, 14 Jul 2004 15:22:04 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09199; Wed, 14 Jul 2004 15:22:02 -0400 (EDT) Message-Id: <200407141922.PAA09199@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, 14 Jul 2004 15:22:02 -0400 Cc: dhcwg@ietf.org Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-isnsoption-12.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 IPv4 DHCP Options for the Internet Storage Name Service Author(s) : C. Monia, et al. Filename : draft-ietf-dhc-isnsoption-12.txt Pages : 14 Date : 2004-7-14 This document describes the DHCP option to allow Internet Storage Name Service (iSNS) clients to automatically discover the location of the iSNS server through the use of DHCP for IPv4. iSNS provides discovery and management capabilities for Internet SCSI (iSCSI) and Internet Fibre Channel Protocol (iFCP) storage devices in an enterprise-scale IP storage network. iSNS provides intelligent storage management services comparable to those found in Fibre Channel networks, allowing a commodity IP network to function in a similar capacity as a storage area network. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-isnsoption-12.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-isnsoption-12.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-isnsoption-12.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-7-14153912.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-isnsoption-12.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-isnsoption-12.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-7-14153912.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 Thu Jul 15 00:38:19 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 AAA07676; Thu, 15 Jul 2004 00:38: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 1BkxuJ-000809-Pw; Thu, 15 Jul 2004 00:31:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bkxpe-0006ts-9z for dhcwg@megatron.ietf.org; Thu, 15 Jul 2004 00:26:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA07190 for ; Thu, 15 Jul 2004 00:26:51 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bkxpc-0006rL-AK for dhcwg@ietf.org; Thu, 15 Jul 2004 00:26:52 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bkxoc-0006YC-00 for dhcwg@ietf.org; Thu, 15 Jul 2004 00:25:51 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1Bkxo6-0006Dy-00 for dhcwg@ietf.org; Thu, 15 Jul 2004 00:25:18 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-5.cisco.com with ESMTP; 14 Jul 2004 21:26:15 -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 i6F4OkRo002913; Wed, 14 Jul 2004 21:24:47 -0700 (PDT) Received: from volzw2k (che-vpn-cluster-2-208.cisco.com [10.86.242.208]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AKD30449; Thu, 15 Jul 2004 00:24:45 -0400 (EDT) From: "Bernie Volz" To: "'Steve Gonczi'" Subject: RE: RE: [dhcwg] dhc WG last call on draft-ietf-dhc-rapid-commit-opt-05 Date: Thu, 15 Jul 2004 00:24:44 -0400 Organization: Cisco Message-ID: <000501c46a23$a85fd970$18fc7044@amer.cisco.com> MIME-Version: 1.0 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-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL,HTML_50_60, HTML_FONTCOLOR_BLUE,HTML_MESSAGE autolearn=no version=2.60 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: , Content-Type: multipart/mixed; boundary="===============2064973252==" Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org This is a multi-part message in MIME format. --===============2064973252== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0006_01C46A02.215146B0" This is a multi-part message in MIME format. ------=_NextPart_000_0006_01C46A02.215146B0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable >Would not get retransmitted, and I did not propose=20 >an ACK/ NAK.=20 =20 Well, you didn't propose the ACK/NAK but the server will send that back = in response to DHCPREQUEST. Or, are you also suggesting that more is = changed to include the "Rapid Commit" in the DHCPREQUEST such that the server knows = not to send the ACK (or NAK)? =20 Again, if you want to do this use short lease times for the Rapid Commit = and give the client a full length lease when it renews. =20 - Bernie -----Original Message----- From: Steve Gonczi [mailto:steve@relicore.com]=20 Sent: Wednesday, July 14, 2004 3:15 PM To: Bernie Volz Cc: dhcwg@ietf.org Subject: RE: RE: [dhcwg] dhc WG last call on draft-ietf-dhc-rapid-commit-opt-05 Would not get retransmitted, and I did not propose=20 an ACK/ NAK.=20 =20 Merely a best effort DHCPREQUEST, to give any server that committed and address (but was not selected by the client) a chance to clean up. =20 This DHCPREQUEST is not intended for the server that offered the accepted ( and committed) address.=20 =20 That server does not need to do anything further. =20 BTW this is exactly how plain DHCP works today. Any server that did offer an address, and sees the DHCPREQUEST for a different address, just releases the address and there is no = further action required. Neither does DHCP provide any assurance that any (not selected) server does see the DHCPREQUEST. =20 =20 =20 regards, =20 /sG =20 -----Original Message----- From: Bernie Volz [mailto:volz@cisco.com] Sent: Wednesday, July 14, 2004 8:17 AM To: 'Steve Gonczi'; soohong.park@samsung.com Cc: dhcwg@ietf.org Subject: RE: RE: [dhcwg] dhc WG last call on draft-ietf-dhc-rapid-commit-opt-05 This likely isn't as a cut and dry as you assume. Does the DHCPREQUEST = get retransmitted until it is ACKed? What happens if it isn't ACKed? What happens if it is NAK?=20 =20 - Berni ------=_NextPart_000_0006_01C46A02.215146B0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
>Would not get=20 retransmitted,  and I did not propose =
>an ACK/ NAK.=20
 
Well,=20 you didn't propose the ACK/NAK but the server will send that back in = response to=20 DHCPREQUEST. Or, are you also suggesting that more is changed to include = the=20 "Rapid Commit" in the DHCPREQUEST such that the server knows not to send = the ACK=20 (or NAK)?
 
Again,=20 if you want to do this use short lease times for the Rapid Commit and = give the=20 client a full length lease when it renews.
 
-=20 Bernie
-----Original Message-----
From: = Steve Gonczi=20 [mailto:steve@relicore.com]
Sent: Wednesday, July 14, 2004 = 3:15=20 PM
To: Bernie Volz
Cc: = dhcwg@ietf.org
Subject:=20 RE: RE: [dhcwg] dhc WG last call on=20 draft-ietf-dhc-rapid-commit-opt-05

Would not get retransmitted,  and I = did not=20 propose
an ACK/ NAK.
 
Merely a best effort DHCPREQUEST,  to = give any=20 server
that=20 committed and address (but was not selected by the = client)
a=20 chance to clean up.
 
This=20 DHCPREQUEST is not intended for the server that = offered
the=20 accepted ( and committed) address.
 
That=20 server does not need to do anything = further.
 
BTW=20 this is exactly how plain DHCP works today.
Any=20 server that did offer an address, and sees the = DHCPREQUEST
for=20 a different address, just releases  the address and there is = no=20 further
action required. Neither does DHCP provide = any=20 assurance that
any=20 (not selected) server does see the DHCPREQUEST.
 
 
 
regards,
 
/sG
 
-----Original Message-----
From: Bernie Volz=20 [mailto:volz@cisco.com]
Sent: Wednesday, July 14, 2004 = 8:17=20 AM
To: 'Steve Gonczi'; = soohong.park@samsung.com
Cc:=20 dhcwg@ietf.org
Subject: RE: RE: [dhcwg] dhc WG last call = on=20 draft-ietf-dhc-rapid-commit-opt-05

This likely isn't as a cut and dry as you assume. Does the=20 DHCPREQUEST get retransmitted until it is ACKed? What happens if it = isn't=20 ACKed? What happens if it is NAK?
 
-=20 Berni
------=_NextPart_000_0006_01C46A02.215146B0-- --===============2064973252== 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 --===============2064973252==-- From dhcwg-bounces@ietf.org Thu Jul 15 06:59: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 GAA10702; Thu, 15 Jul 2004 06:59: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 1Bl3tR-0000GN-Dh; Thu, 15 Jul 2004 06:55:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BkqyS-0001vx-3J for dhcwg@megatron.ietf.org; Wed, 14 Jul 2004 17:07:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21186 for ; Wed, 14 Jul 2004 17:07:29 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BkqyQ-0003mZ-Q3 for dhcwg@ietf.org; Wed, 14 Jul 2004 17:07:30 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BkqoM-0001Xb-00 for dhcwg@ietf.org; Wed, 14 Jul 2004 16:57:07 -0400 Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx with esmtp (Exim 4.12) id 1BkqeM-00076F-00 for dhcwg@ietf.org; Wed, 14 Jul 2004 16:46:46 -0400 Received: from [10.0.2.3] (neubayern.net [66.93.162.100]) by toccata.fugue.com (Postfix) with ESMTP id 3614A1B2DD0; Wed, 14 Jul 2004 15:38:49 -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] dhc WG last call on draft-ietf-dhc-rapid-commit-opt-05 Date: Wed, 14 Jul 2004 13:46:38 -0700 To: "Steve Gonczi" X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 15 Jul 2004 06:55:11 -0400 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 Jul 14, 2004, at 12:14 PM, Steve Gonczi wrote: > What complexity are you talking about? > How is this different from plain DHCP? The complexity is that now you have to specify how the DHCPREQUEST is done. This is a substantial change to the draft. And what you get for it is something about as reliable as a DHCPRELEASE - a best effort notification. Finally, you say that this isn't any different than how DHCP works normally - you claim that most DHCP servers listen for the DHCPREQUEST and, when it is for a different server identifier, do something with that. However, this doesn't match my experience - it's expensive to do anything with the DHCPREQUEST, and I am not aware of any servers that do it. Perhaps the Cisco server does - I don't know. There's no real benefit to it, because the DHCPOFFER doesn't represent a promise, so you can reclaim an offered lease at any time until you send a DHCPACK in response to the DHCPREQUEST. So in order to gain any benefit from this, the average server is probably going to require a whole additional code path in addition to the rapid commit code path. Whereas, if you just have the server give out a short lease on initial lease assignment for rapid commit DHCPDISCOVERs, then the lease expires quickly and is available for reallocation if the client doesn't renew. This accomplishes the same thing you're trying to accomplish, but is much cheaper to implement and is completely reliable. It's also more flexible, because a site that follows the single-server model doesn't have to do it, so only sites that want rapid commit with multiple servers have to pay a penalty for the additional functionality. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Thu Jul 15 13:47: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 NAA08170; Thu, 15 Jul 2004 13:47: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 1BlA7a-0003Fo-Aw; Thu, 15 Jul 2004 13:34:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bl9uH-0004mT-Hy for dhcwg@megatron.ietf.org; Thu, 15 Jul 2004 13:20:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05311 for ; Thu, 15 Jul 2004 13:20:26 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bl9uG-0002uP-FT for dhcwg@ietf.org; Thu, 15 Jul 2004 13:20:28 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bl9tN-0002Z8-00 for dhcwg@ietf.org; Thu, 15 Jul 2004 13:19:33 -0400 Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx with esmtp (Exim 4.12) id 1Bl9sW-0002Ee-00 for dhcwg@ietf.org; Thu, 15 Jul 2004 13:18:40 -0400 Received: from esunmail ([129.147.156.34]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i6FHIeil013900 for ; Thu, 15 Jul 2004 11:18:40 -0600 (MDT) Received: from fe7 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0I0W003M0LF3WW@edgemail1.Central.Sun.COM> for dhcwg@ietf.org; Thu, 15 Jul 2004 11:18:40 -0600 (MDT) Received: from [129.148.174.191] by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0I0W00KABLEY3N@mail.sun.net> for dhcwg@ietf.org; Thu, 15 Jul 2004 11:18:39 -0600 (MDT) Date: Thu, 15 Jul 2004 13:18:26 -0400 From: Dave Miner Subject: Re: [dhcwg] dhc WG last call on draft-ietf-dhc-rapid-commit-opt-05 In-reply-to: To: Ted Lemon Message-id: <40F6BC62.8090708@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla Thunderbird 0.7+ (X11/20040617) References: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Cc: dhcwg@ietf.org, Steve Gonczi 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 Ted Lemon wrote: ... > > Finally, you say that this isn't any different than how DHCP works > normally - you claim that most DHCP servers listen for the DHCPREQUEST > and, when it is for a different server identifier, do something with > that. However, this doesn't match my experience - it's expensive to do > anything with the DHCPREQUEST, and I am not aware of any servers that do > it. Perhaps the Cisco server does - I don't know. As a point of information, the Solaris DHCP server does exactly this, and has for as long as we've been shipping it. Dave _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Thu Jul 15 14:50: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 OAA13127; Thu, 15 Jul 2004 14:50: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 1BlBA9-0008DP-HC; Thu, 15 Jul 2004 14: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 1BlB5o-0007Of-Mg for dhcwg@megatron.ietf.org; Thu, 15 Jul 2004 14:36:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11818 for ; Thu, 15 Jul 2004 14:36:26 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BlB5n-00058a-9g for dhcwg@ietf.org; Thu, 15 Jul 2004 14:36:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BlB4r-0004l5-00 for dhcwg@ietf.org; Thu, 15 Jul 2004 14:35:30 -0400 Received: from ftp.relicore.com ([4.36.57.198]) by ietf-mx with esmtp (Exim 4.12) id 1BlB3p-00044p-00 for dhcwg@ietf.org; Thu, 15 Jul 2004 14:34:25 -0400 Received: from STEVEPC ([192.168.0.222]) by ftp.relicore.com (8.12.9/8.12.9) with SMTP id i6FI74AZ013340; Thu, 15 Jul 2004 14:07:04 -0400 (EDT) From: "Steve Gonczi" To: "Bernie Volz" Subject: RE: RE: [dhcwg] dhc WG last call on draft-ietf-dhc-rapid-commit-opt-05 Date: Thu, 15 Jul 2004 14:31:50 -0400 Message-ID: MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 In-Reply-To: <000501c46a23$a85fd970$18fc7044@amer.cisco.com> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL,HTML_50_60, HTML_FONTCOLOR_BLUE,HTML_MESSAGE autolearn=no version=2.60 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: , Content-Type: multipart/mixed; boundary="===============1652102067==" Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org This is a multi-part message in MIME format. --===============1652102067== Content-Type: multipart/alternative; boundary="----=_NextPart_000_012C_01C46A78.7792B6A0" This is a multi-part message in MIME format. ------=_NextPart_000_012C_01C46A78.7792B6A0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit MessageHi Bernie, My thinking was exactly as you outline it below. (the DHCPREQUEST would have the rapid commit option...) In any case, the point is moot, as I have come around to seeing the beauty of using initial short leases. I presume that the intent is to get the client IP-enabled as fast as possible, whilst the cost of the almost immediate renewal is not relevant. I did post a note of supporting the advancement of this draft as-is. /sG -----Original Message----- From: Bernie Volz [mailto:volz@cisco.com] Sent: Thursday, July 15, 2004 12:25 AM To: 'Steve Gonczi' Cc: dhcwg@ietf.org Subject: RE: RE: [dhcwg] dhc WG last call on draft-ietf-dhc-rapid-commit-opt-05 >Would not get retransmitted, and I did not propose >an ACK/ NAK. Well, you didn't propose the ACK/NAK but the server will send that back in response to DHCPREQUEST. Or, are you also suggesting that more is changed to include the "Rapid Commit" in the DHCPREQUEST such that the server knows not to send the ACK (or NAK)? Again, if you want to do this use short lease times for the Rapid Commit and give the client a full length lease when it renews. - Bernie ------=_NextPart_000_012C_01C46A78.7792B6A0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Hi=20 Bernie,
 
My=20 thinking was exactly as you outline it below. (the DHCPREQUEST=20
would have the rapid commit option...)
 
In any=20 case, the point is moot, as I have come around to=20 seeing
the=20 beauty of using initial short leases.
 
I=20 presume that the intent is to get the client IP-enabled as fast as=20 possible,
whilst=20 the cost of the almost immediate renewal is not = relevant.
 
I did=20 post a note of supporting the advancement of this draft=20 as-is.
 
/sG
 
 
-----Original Message-----
From: Bernie Volz=20 [mailto:volz@cisco.com]
Sent: Thursday, July 15, 2004 12:25=20 AM
To: 'Steve Gonczi'
Cc:=20 dhcwg@ietf.org
Subject: RE: RE: [dhcwg] dhc WG last call on=20 draft-ietf-dhc-rapid-commit-opt-05

>Would not get=20 retransmitted,  and I did not propose =
>an ACK/ NAK.=20
 
Well, you didn't propose the ACK/NAK but the server will send = that back=20 in response to DHCPREQUEST. Or, are you also suggesting that more is = changed=20 to include the "Rapid Commit" in the DHCPREQUEST such that the server = knows=20 not to send the ACK (or NAK)?
 
Again, if you want to do this use short lease times for the = Rapid=20 Commit and give the client a full length lease when it=20 renews.
 
-=20 Bernie
------=_NextPart_000_012C_01C46A78.7792B6A0-- --===============1652102067== 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 --===============1652102067==-- From dhcwg-bounces@ietf.org Thu Jul 15 15:48: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 PAA18648; Thu, 15 Jul 2004 15:48: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 1BlBtD-0006ck-6w; Thu, 15 Jul 2004 15:27:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BlBn5-0004rV-Nu; Thu, 15 Jul 2004 15:21:11 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16183; Thu, 15 Jul 2004 15:21:09 -0400 (EDT) Message-Id: <200407151921.PAA16183@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Thu, 15 Jul 2004 15:21:09 -0400 Cc: dhcwg@ietf.org Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-proxyserver-opt-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 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Title : DHCP Option for Proxy Server Configuration Author(s) : S. Balasubramanian, et al. Filename : draft-ietf-dhc-proxyserver-opt-01.txt Pages : 9 Date : 2004-7-15 This document defines a new Dynamic Host Configuration Protocol (DHCP) option, which 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 Server provides controlled and efficient access to the Internet by access control mechanism for different types of user requests and caching frequently accessed information (Web pages and possibly files that might have been downloaded using FTP and other protocols). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-proxyserver-opt-01.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-proxyserver-opt-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dhc-proxyserver-opt-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-7-15151822.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-proxyserver-opt-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-proxyserver-opt-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-7-15151822.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 Thu Jul 15 21:43: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 VAA25889; Thu, 15 Jul 2004 21:43: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 1BlHhf-0000Yk-OH; Thu, 15 Jul 2004 21:39:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BlAV6-0004lL-TB for dhcwg@megatron.ietf.org; Thu, 15 Jul 2004 13:58:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09189 for ; Thu, 15 Jul 2004 13:58:31 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BlAV5-0000cr-Gi for dhcwg@ietf.org; Thu, 15 Jul 2004 13:58:31 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BlAUL-0000Ie-00 for dhcwg@ietf.org; Thu, 15 Jul 2004 13:57:45 -0400 Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx with esmtp (Exim 4.12) id 1BlATX-0007lu-00 for dhcwg@ietf.org; Thu, 15 Jul 2004 13:56:55 -0400 Received: from [10.0.2.3] (neubayern.net [66.93.162.100]) by toccata.fugue.com (Postfix) with ESMTP id 2A0081B2127; Thu, 15 Jul 2004 12:48:53 -0500 (CDT) In-Reply-To: <40F6BC62.8090708@sun.com> References: <40F6BC62.8090708@sun.com> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <58F4E2DE-D688-11D8-BA2F-000A95D9C74C@fugue.com> Content-Transfer-Encoding: 7bit From: Ted Lemon Subject: Re: [dhcwg] dhc WG last call on draft-ietf-dhc-rapid-commit-opt-05 Date: Thu, 15 Jul 2004 10:56:50 -0700 To: Dave Miner X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 15 Jul 2004 21:39:57 -0400 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 Jul 15, 2004, at 10:18 AM, Dave Miner wrote: > As a point of information, the Solaris DHCP server does exactly this, > and has for as long as we've been shipping it. Oh, right, that makes sense. Cool! It doesn't change my opinion about rapid commit, though - handling the DHCPREQUEST unquestionably adds work. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri Jul 16 04:46: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 EAA15595; Fri, 16 Jul 2004 04:46: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 1BlOFd-0001Mm-Cz; Fri, 16 Jul 2004 04:39:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BlOCI-00011a-CX for dhcwg@megatron.ietf.org; Fri, 16 Jul 2004 04:36:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA15127 for ; Fri, 16 Jul 2004 04:36:00 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BlOCF-0006Y5-US for dhcwg@ietf.org; Fri, 16 Jul 2004 04:36:00 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BlOBQ-0006BB-00 for dhcwg@ietf.org; Fri, 16 Jul 2004 04:35:09 -0400 Received: from [210.22.146.172] (helo=asbmx.sbell.com.cn) by ietf-mx with esmtp (Exim 4.12) id 1BlOAW-0005Sc-00 for dhcwg@ietf.org; Fri, 16 Jul 2004 04:34:24 -0400 Received: from asbwebshld.sbell.com.cn (asbwebshld [172.24.208.38]) by asbmx.sbell.com.cn (8.12.10+Sun/8.12.3) with SMTP id i6G8SlMK009596 for ; Fri, 16 Jul 2004 16:28:59 +0800 (CST) Received: FROM bellnet-mail4.sbell.com.cn BY asbwebshld.sbell.com.cn ; Fri Jul 16 16:32:44 2004 +0800 Received: from BELLNET-MAIL3.sbell.com.cn ([172.24.208.23]) by bellnet-mail4.sbell.com.cn with Microsoft SMTPSVC(5.0.2195.6713); Fri, 16 Jul 2004 16:32:43 +0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Subject: [dhcwg] RE: Client FQDN Date: Fri, 16 Jul 2004 16:32:43 +0800 Message-ID: <8634B809B90D6E4AACA4AB0562A1F07205ED78@bellnet-mail3.sbell.com.cn> Thread-Topic: [dhcwg] RE: Client FQDN Thread-Index: AcRpYKYuYGi6kjnWTLe8zc/EKkUbAwBp/06w From: "CTO YAN Renxiang" To: "Bernie Volz" , X-OriginalArrivalTime: 16 Jul 2004 08:32:43.0860 (UTC) FILETIME=[77034140:01C46B0F] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 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 > Why? >=20 > The DHCP server will return the fully qualified domain name for each = address > to the client (if appropriate). With this and if you know the how to = reach a > DNS server, you can find out where the zone cut is. Ask for NS RRs = with the > fully qualified domain name; if that doesn't return any, remove the = first > component (ie, for a.b.test.com, remove a) and try the resulting = domain ... > Keep going until you find the NS records or you run out of domain = names. If > you find NS records, try the updates to the one or more servers. You meaned DNS zone suffix is transferred impliclitly in FQDN, and in = the case that client has no knowledge of the DNS zone suffix, the FQDN option = will be used only in this way: client sends hostname to DHCP server, and then DHCP = server returns the FQDN to client, right? =20 > Nothing more needed. Suppose an IPv6 access network, every home network is deployed with a = home gateway. The home gateway will get an IPv6 prefix using DHCPv6 server, while in = home network,=20 it may use stateless address configuration. In this case, if IPv6 device = in home network wants to register domain name in the DNS server, it has to get a DNS zone = suffix and does the=20 registration itself. DNS zone suffix can be transferred to home gateway = using DNS zone suffix option. IPv6 device gets the suffix using RA or stateless dhcp = server embedded in=20 home gateway.=20 -Renxiang > Now, agreed, that if the DHCP server doesn't return the Client FQDN = option > for a address, then the DHCP client will need something for it to use. = And, > lacking anything else, using the DNS search list probably isn't that = bad an > idea. >=20 > - Bernie >=20 > > -----Original Message----- > > From: CTO YAN Renxiang [mailto:Renxiang.Yan@alcatel-sbell.com.cn]=20 > > Sent: Tuesday, July 13, 2004 11:01 PM > > To: volz@cisco.com > > Cc: dhcwg@ietf.org > > Subject:=20 > >=20 > >=20 > > Hi, Bernie, > >=20 > > I don't think domain name search list option defined in=20 > > RFC3646 can transfer the DNS zone suffix which is used by=20 > > host to update the FQDN without any modification. > >=20 > > In section4 of RFC3646, it states: > > "The Domain Search List option specifies the domain search=20 > > list the client is to use when resolving hostnames with DNS." > >=20 > > The initial purpose of domain search list option is hostname=20 > > resolving, not domain name update. Furthermore, the domain=20 > > name listed in the Domain Search List option can be different=20 > > from the DNS zone suffix the client needed to update its=20 > domain name. > >=20 > > Even if Domain Search List option can be used in domain name=20 > > update, we have to define a mechanism to choose a correct=20 > > domain name from domain search list. > >=20 > > To sum up, two choices exist to make it possible for IPv6=20 > > client to dynamically update its domain name: 1. define=20 > > another option to transfer DNS zone suffix to client, which=20 > > enables the client generates its FQDN, as defined in=20 > > http://www.ietf.org/internet-drafts/draft-yan-dhc-dhcpv6-opt-d > > nszone-00.txt. > > 2. define a mechanism to choose a domain name as DNS zone=20 > > suffix from domain search list, and use it to generate and=20 > > update client's FQDN > >=20 > > -Renxiang > >=20 > > P.S. In order to foster a discussion on this topic, I am=20 > > CCing this mail to DHC list, I would be appreciated any=20 > > value comments from experts in the list. > >=20 > >=20 > > -----=D4=AD=CA=BC=D3=CA=BC=FE----- > > =B7=A2=BC=FE=C8=CB: Bernie Volz [mailto:volz@cisco.com] > > =B7=A2=CB=CD=CA=B1=BC=E4: 2004=C4=EA7=D4=C213=C8=D5 10:38 > > =CA=D5=BC=FE=C8=CB: CTO YAN Renxiang > > =D6=F7=CC=E2: RE: about your draft > >=20 > >=20 > > The Client FQDN option sends the fully qualified domain name.=20 > > There is no indication of which is the host portion and which=20 > > is the domain name. In general, this really isn't that useful. > >=20 > > In DHCPv6, we already have the domain name search list option=20 > > (see http://www.ietf.org/rfc/rfc3646.txt). This is generally=20 > > much more useful than just the "domain name" and, in DHCPv4=20 > > it is generally the domain name that is used as the default=20 > > domain search list. > >=20 > > So, if a client receives the Client FQDN option with a fully=20 > > qualified domain name, it can figure out the host name=20 > > portion by using the domain search list, if it really cares.=20 > > Or, it can do DNS lookups. > >=20 > > - Bernie > >=20 > > > -----Original Message----- > > > From: CTO YAN Renxiang [mailto:Renxiang.Yan@alcatel-sbell.com.cn] > > > Sent: Monday, July 12, 2004 8:38 PM > > > To: Bernie Volz > > > Subject: re: about your draft > > > > > > > > > Hi, Bernie, > > > > > > In DHCPv4, the domain name is tranferred using option 15=20 > > (domain name)=20 > > > defined in 2132. However, DHCPv6 does not defined such an=20 > > option. How=20 > > > does your draft implement? could you explain in a bit detail? > > > > > > regards, > > > -renxiang > > > > > > -----=D4=AD=CA=BC=D3=CA=BC=FE----- > > > =B7=A2=BC=FE=C8=CB: Bernie Volz [mailto:volz@cisco.com] > > > =B7=A2=CB=CD=CA=B1=BC=E4: 2004=C4=EA7=D4=C212=C8=D5 21:28 > > > =CA=D5=BC=FE=C8=CB: CTO YAN Renxiang > > > =D6=F7=CC=E2: RE: about your draft > > > > > > > > > Hi: > > > > > > The draft should appear at the IETF web site shortly.=20 > Sometimes the=20 > > > announcement preceeds the upload to the web/ftp site(s), so=20 > > give it a=20 > > > day or two and it should appear. > > > > > > The option is modeled after the DHCPv4 Client FQDN option. > > > > > > - Bernie > > > > > > > -----Original Message----- > > > > From: CTO YAN Renxiang=20 > [mailto:Renxiang.Yan@alcatel-sbell.com.cn] > > > > Sent: Sunday, July 11, 2004 11:35 PM > > > > To: volz@cisco.com > > > > Subject: about your draft > > > > > > > > > > > > Hi Bernie, > > > > > > > > I found you will make presentation on 60th IETF meeting=20 > about the=20 > > > > DHCP FQDN option. I can't find the draft "The DHCPv6=20 > Client FQDN=20 > > > > Option" on website. Could you send me the link? > > > > > > > > I wrote a draft "DNS zone suffix option for DHCPv6" to=20 > > allow DHCPv6=20 > > > > server transfer the DNS zone suffix to DHCPv6 client. I=20 > > wonder there=20 > > > > will be close relationship between our drafts, so could=20 > > you tell me=20 > > > > how to tranfer the DNS suffix in your draft? > > > > > > > > Thank you! > > > > > > > > regards, > > > > -Renxiang > > > > > > > cn > >=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 Fri Jul 16 14:03: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 OAA19920; Fri, 16 Jul 2004 14:03: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 1BlWzO-0006GY-38; Fri, 16 Jul 2004 13:59:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BlWwS-0005ot-5T for dhcwg@megatron.ietf.org; Fri, 16 Jul 2004 13:56:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19416 for ; Fri, 16 Jul 2004 13:56:15 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BlWwP-0003w1-5W for dhcwg@ietf.org; Fri, 16 Jul 2004 13:56:13 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BlWvS-0003c8-00 for dhcwg@ietf.org; Fri, 16 Jul 2004 13:55:15 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1BlWub-0002yt-00; Fri, 16 Jul 2004 13:54:21 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-5.cisco.com with ESMTP; 16 Jul 2004 10:55:38 -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 i6GHrmAL015834; Fri, 16 Jul 2004 10:53:50 -0700 (PDT) Received: from rdroms-w2k01.cisco.com (che-vpn-cluster-1-82.cisco.com [10.86.240.82]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AKE40418; Fri, 16 Jul 2004 13:53:47 -0400 (EDT) Message-Id: <4.3.2.7.2.20040716135249.02955fb8@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 16 Jul 2004 13:53:45 -0400 To: agenda@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Cc: dhcwg@ietf.org Subject: [dhcwg] Revised agenda - note dhc WG now meeting on Tue 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 DHC WG agenda - IETF 60 0900 Tue 2004-08-03 (tentative) (Last revised 07/16/2004 01:45 PM) ---------------------------------- Administrivia Ralph Droms 05 minutes Agenda bashing 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? 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 ----------- 140 minutes _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri Jul 16 22:16: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 WAA28125; Fri, 16 Jul 2004 22:16: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 1Blef5-00088b-BE; Fri, 16 Jul 2004 22: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 1Bleav-0007Tu-Pp for dhcwg@megatron.ietf.org; Fri, 16 Jul 2004 22:06:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA27784 for ; Fri, 16 Jul 2004 22:06:32 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bleas-0006Ms-2H for dhcwg@ietf.org; Fri, 16 Jul 2004 22:06:30 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BleZv-00064i-00 for dhcwg@ietf.org; Fri, 16 Jul 2004 22:05:32 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BleZh-0005mK-00 for dhcwg@ietf.org; Fri, 16 Jul 2004 22:05:17 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 16 Jul 2004 19:05:44 -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 i6H24lSV006588 for ; Fri, 16 Jul 2004 19:04:48 -0700 (PDT) Received: from volzw2k (che-vpn-cluster-2-75.cisco.com [10.86.242.75]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AKE69227; Fri, 16 Jul 2004 22:04:47 -0400 (EDT) From: "Bernie Volz" To: Date: Fri, 16 Jul 2004 22:04:47 -0400 Organization: Cisco Message-ID: <004f01c46ba2$6f822290$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 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4939.300 Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Subject: [dhcwg] Updated and New Drafts - DHCPv4 Client FQDN, DDNS Conflict Resolution, DHCID RR, and DHCPv6 Client FQDN 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: I've submitted four drafts - one is new (and currently an individual submission) and the other three are revisions of existing drafts (though = not originally authored by me). The new draft was submitted before the -00 cutoff and should be = announced shortly. It can be found at http://www.metrocast.net/~volz/draft-volz-dhc-dhcpv6-fqdn-00.txt and describes a Client FQDN option for DHCPv6. The revised drafts are listed below with highlights of the changes; = these should appear shortly (they were submitted earlier today and it may take = a week before they appear). 1. http://www.metrocast.net/~volz/draft-ietf-dhc-fqdn-option-07.txt Changes to this draft were: - Reworked abstract and introduction based on review comments from Ralph Droms while writing the DHCPv6 FQDN draft. - Removed text that referenced the ddns conflict resolution draft and = added a new section (7) that provides an informational reference to the = resolution draft. - Updated boilerplate, dates, draft number, and cross referenced draft = dates in references. - Fixed a few spelling, wording, and formatting errors. - Reworked references. 2. http://www.metrocast.net/~volz/draft-ietf-dhc-ddns-resolution-07.txt Changes to this draft were: - Reworked section 6.3. The previous draft had an invalid section = reference (in [subsection xxx].) and I felt that the subsections where a bit = confusing so I reworked the steps. - Updated boilerplate, dates, draft number, and cross referenced draft = dates in references. - Fixed a few spelling, wording, and formatting errors. - Reworked references slightly. 3. http://www.metrocast.net/~volz/draft-ietf-dnsext-dhcid-rr-08.txt Changes to this draft were: - Updated DHCPv6 reference to RFC 3315 and also added references to = 3315ID Draft for DUID. - Reworked table in section 3.3, type codes. - Updated boilerplate, dates, draft number, and cross referenced draft = dates in references. - Fixed a few spelling, wording, and formatting errors. - Bernie _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon Jul 19 16:24: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 QAA22500; Mon, 19 Jul 2004 16:24: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 1BmeL0-0003v1-3l; Mon, 19 Jul 2004 16:02:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bmdhy-0001H8-Lr; Mon, 19 Jul 2004 15:21:54 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18110; Mon, 19 Jul 2004 15:21:52 -0400 (EDT) Message-Id: <200407191921.PAA18110@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Mon, 19 Jul 2004 15:21:52 -0400 Cc: dhcwg@ietf.org Subject: [dhcwg] I-D ACTION: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 --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 : Lifetime Option for DHCPv6 Author(s) : S. Venaas, T. Chown Filename : draft-ietf-dhc-lifetime-01.txt Pages : 6 Date : 2004-7-19 This document describes an option for specifying a lifetime for other DHCPv6 configuration options. It's mainly intended for the stateless DHCPv6, but also useful when there are no addresses or other entities with lifetimes that can tell the client when to contact the DHCP server to update its configuration. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-lifetime-01.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-lifetime-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dhc-lifetime-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-7-19152232.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-lifetime-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-lifetime-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-7-19152232.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 Tue Jul 20 10:43: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 KAA24912; Tue, 20 Jul 2004 10:43: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 1Bmvh3-0003vN-JY; Tue, 20 Jul 2004 10:34:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BmvX3-0000zC-4J for dhcwg@megatron.ietf.org; Tue, 20 Jul 2004 10:23: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 KAA23286 for ; Tue, 20 Jul 2004 10:23:46 -0400 (EDT) Received: from sinfonix.rz.tu-clausthal.de ([139.174.2.33]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BmvX8-0000nY-85 for dhcwg@ietf.org; Tue, 20 Jul 2004 10:23:58 -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 QAA24940 for ; Tue, 20 Jul 2004 16:23:41 +0200 (MET DST) From: Christian Strauf To: dhcwg@ietf.org Content-Type: text/plain Organization: Rechenzentrum TU Clausthal Message-Id: <1090333421.11056.266.camel@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Tue, 20 Jul 2004 16:23:41 +0200 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Content-Transfer-Encoding: 7bit Subject: [dhcwg] Comments on draft-jinmei-dhc-dhcpv6-clarify-auth-00 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 Jinmei-san, here are my first comments on the I-D. My overall impression of the I-D is very good, it seems to include all the issues raised on the DHC-ML. All comments I have are mostly minor things like language and typos, not essential problems with the contents. I like the comment that you make in para 2.1 about not having a real "session" in stateless which is essentially a contradiction to "stateless" on one hand but on the other hand one obviously needs to strictly separate sessions that concern content transmitted via DHCP and sessions that concern the transmission itself. I think that your proposed rephrasing of Section 21.4.4.4 incorporates that nicely. I paragraph 4. you write: "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 but does not have authentication information when necessary." 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): "A reasonable interpretation of the phrase is as follows: a DHCPv6 message is called unauthenticated if it fails the validation test described in Section 21.4.2, if it does not contain an authentication option, or if it includes an authentication option without the necessary authentication information." I also like para 5.1. very much, especially the choice of highlighted keywords is very good. I second the idea of proposing a default policy of discarding non-authenticated messages. Minor typos: 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 para 3.: -3. What If Reply Is Detected +3. What If Replay Is Detected para 5.: -Apparently this contradicts with the requirement in Section 21.4.2. +Apparently this contradicts the requirement in Section 21.4.2. para 5.1.: -Accepting an non-authenticated +Accepting a non-authenticated Thank you for writing this I-D up, it summarises important DHCP authentication issues raised on the ML very well and gives the reader a good idea where there're gaps in the standard and where clarifications should be made. Additionally I think that this I-D is a good basis for any future BCP document regarding DHCPv6 deployments where authentication mechanisms are used. Cheers, Christian _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Jul 20 11:21: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 LAA27438; Tue, 20 Jul 2004 11:21: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 1BmwAa-0004e2-9L; Tue, 20 Jul 2004 11:04:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bmw3H-0002QU-Km for dhcwg@megatron.ietf.org; Tue, 20 Jul 2004 10:57: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 KAA25869 for ; Tue, 20 Jul 2004 10:57:05 -0400 (EDT) Received: from tyholt.uninett.no ([158.38.60.10]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bmw3G-0001HW-BO for dhcwg@ietf.org; Tue, 20 Jul 2004 10:57:17 -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 i6KEtNV0024308; Tue, 20 Jul 2004 16:55:43 +0200 Received: (from venaas@localhost) by sverresborg.uninett.no (8.12.8/8.12.8/Submit) id i6KEt8Rn030467; Tue, 20 Jul 2004 16:55:08 +0200 X-Authentication-Warning: sverresborg.uninett.no: venaas set sender to Stig.Venaas@uninett.no using -f Date: Tue, 20 Jul 2004 16:55:08 +0200 From: Stig Venaas To: Christian Strauf Subject: Re: [dhcwg] Comments on draft-jinmei-dhc-dhcpv6-clarify-auth-00 Message-ID: <20040720145508.GL29655@sverresborg.uninett.no> References: <1090333421.11056.266.camel@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1090333421.11056.266.camel@localhost> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 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 One concern I have is regarding per-client state on the server. I would like to avoid that if possible. In 2.1 in the draft it's suggested for 21.4.5.x that: The server MUST record the identifier of the key selected for the client so that it can validate further Information-request messages from the client if the client reuses the same key for the future exchanges. I must confess I haven't looked much at DHCP authentication, but I think it's nice to prevent per-client state for "stateless" (RFC3736) DHCP servers if possible. Wouldn't it be possible to pass some sort of key id to the client, which the client can include in future exchanges? The server could perhaps have a fixed mapping between key id's and keys, and based on the id, the server knows which key to use. I'm not sure if you see what I mean, but my idea is if possible to keep the necessary state in the clients rather than the servers. Might this be possible? Or would there be security problems? Using assymetric crypto one could easily have just one fixed key for all messages sent by the client. But I guess that might make the server vulnerable to DoS attacks. For stateless I think it's generally enough to authenticate the DHCP server. In most cases I don't think it's important to guard against replay, or to authenticate the client. That could perhaps simplify the security mechanism. It's relatively easy to guard against replay anyway though. Stig _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Jul 20 12:38: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 MAA03461; Tue, 20 Jul 2004 12:38: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 1BmxT3-00057V-6s; Tue, 20 Jul 2004 12:27:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bmx3e-0004qR-D7 for dhcwg@megatron.ietf.org; Tue, 20 Jul 2004 12:01: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 MAA00640 for ; Tue, 20 Jul 2004 12:01:31 -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 1Bmx3n-0002NN-Is for dhcwg@ietf.org; Tue, 20 Jul 2004 12:01:45 -0400 Received: from i2km98-ukbr.domain1.systemhost.net ([193.113.197.85]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 20 Jul 2004 17:01:28 +0100 Received: from i2km41-ukdy.domain1.systemhost.net ([193.113.30.29]) by i2km98-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Tue, 20 Jul 2004 17:01:24 +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 Date: Tue, 20 Jul 2004 17:01:24 +0100 Message-ID: <0AAF93247C75E3408638B965DEE11A7008D5DB86@i2km41-ukdy.domain1.systemhost.net> Thread-Topic: test - please ignore Thread-Index: AcRuctvMijvtZhrRRSazCA2Oit9f7Q== To: X-OriginalArrivalTime: 20 Jul 2004 16:01:24.0394 (UTC) FILETIME=[CE8DC0A0:01C46E72] X-Spam-Score: 0.3 (/) X-Scan-Signature: bb8eae9af85e4fcfe76f325e38493bf4 Content-Transfer-Encoding: quoted-printable Subject: [dhcwg] test - please ignore 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 test _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Jul 20 16:46: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 QAA00008; Tue, 20 Jul 2004 16:46: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 1Bn0w1-0004vm-UI; Tue, 20 Jul 2004 16:09:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bn0Yc-0007dW-2D; Tue, 20 Jul 2004 15:45:46 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20960; Tue, 20 Jul 2004 15:45:44 -0400 (EDT) Message-Id: <200407201945.PAA20960@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Tue, 20 Jul 2004 15:45:43 -0400 Cc: dhcwg@ietf.org Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-stateless-dhcpv6-renumbering-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 --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 : Renumbering Requirements for Stateless DHCPv6 Author(s) : T. Chown, et al. Filename : draft-ietf-dhc-stateless-dhcpv6-renumbering-01.txt Pages : 8 Date : 2004-7-20 IPv6 hosts using Stateless Address Autoconfiguration are able to automatically configure their IPv6 address and default router settings. However, further settings are not available. If such hosts wish to automatically configure their DNS, NTP or other specific settings the stateless variant of the Dynamic Host Configuration Protocol for IPv6 (DHCPv6) could be used. This combination of Stateless Address Autoconfiguration and stateless DHCPv6 could be used quite commonly in IPv6 networks. However, hosts using such a combination currently have no means by which to be informed of changes in stateless DHCPv6 option settings, e.g. the addition of a new NTP server address, changes in DNS search paths, or full site renumbering. This document is presented as a problem statement from which a solution should be proposed in a subsequent document. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-stateless-dhcpv6-renumbering-01.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-stateless-dhcpv6-renumbering-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dhc-stateless-dhcpv6-renumbering-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-7-20155305.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-stateless-dhcpv6-renumbering-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-stateless-dhcpv6-renumbering-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-7-20155305.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 Tue Jul 20 16:52: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 QAA00744; Tue, 20 Jul 2004 16:52: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 1Bn0w6-0004xM-4e; Tue, 20 Jul 2004 16:10:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bn0Z7-0007eU-DA; Tue, 20 Jul 2004 15:46:17 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20998; Tue, 20 Jul 2004 15:46:15 -0400 (EDT) Message-Id: <200407201946.PAA20998@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Tue, 20 Jul 2004 15:46:15 -0400 Cc: dhcwg@ietf.org Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-ddns-resolution-07.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 : Resolution of DNS Name Conflicts Among DHCP Clients Author(s) : M. Stapp, B. Volz Filename : draft-ietf-dhc-ddns-resolution-07.txt Pages : 13 Date : 2004-7-20 DHCP provides a powerful mechanism for IP host configuration. However, the configuration capability provided by DHCP does not include updating DNS, and specifically updating the name to address and address to name mappings maintained in the DNS. This document describes techniques for the resolution of DNS name conflicts among DHCP clients. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-ddns-resolution-07.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-ddns-resolution-07.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-ddns-resolution-07.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-7-20155310.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-ddns-resolution-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-ddns-resolution-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-7-20155310.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 Tue Jul 20 16:56: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 QAA01279; Tue, 20 Jul 2004 16:56: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 1Bn0wA-0004xv-8p; Tue, 20 Jul 2004 16:10:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bn0Za-0007mD-Vu; Tue, 20 Jul 2004 15:46:47 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21053; Tue, 20 Jul 2004 15:46:44 -0400 (EDT) Message-Id: <200407201946.PAA21053@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Tue, 20 Jul 2004 15:46:44 -0400 Cc: dhcwg@ietf.org Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-fqdn-option-07.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 DHCP Client FQDN Option Author(s) : M. Stapp, et al. Filename : draft-ietf-dhc-fqdn-option-07.txt Pages : 15 Date : 2004-7-20 This document specifies a DHCP for IPv4, DHCPv4, option which can be used to exchange information about a DHCPv4 client's fully-qualified domain name and about responsibility for updating the DNS RR related to the client's address assignment. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-fqdn-option-07.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-fqdn-option-07.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-fqdn-option-07.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-7-20155316.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-fqdn-option-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-fqdn-option-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-7-20155316.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 Tue Jul 20 23: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 XAA09407; Tue, 20 Jul 2004 23: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 1Bn6yz-0004VD-1T; Tue, 20 Jul 2004 22:37:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bn4GZ-00038F-US for dhcwg@megatron.ietf.org; Tue, 20 Jul 2004 19:43: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 TAA02588 for ; Tue, 20 Jul 2004 19:43:20 -0400 (EDT) Received: from mailout2.samsung.com ([203.254.224.25]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bn4Gn-0000hH-0v for dhcwg@ietf.org; Tue, 20 Jul 2004 19:43:38 -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 <0I1600005CJ7VU@mailout2.samsung.com> for dhcwg@ietf.org; Wed, 21 Jul 2004 08:42:43 +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 <0I1600FYECJ3WH@mailout2.samsung.com> for dhcwg@ietf.org; Wed, 21 Jul 2004 08:42:39 +0900 (KST) Received: from LocalHost ([168.219.202.103]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0I1600I6BCIYX4@mmp1.samsung.com> for dhcwg@ietf.org; Wed, 21 Jul 2004 08:42:39 +0900 (KST) Date: Wed, 21 Jul 2004 08:43:31 +0900 From: Soohong Daniel Park To: Dhcwg Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) 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: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7BIT Subject: [dhcwg] FW: Updated IPv6 WG Agenda (M&O Flags of RA) 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 DHC folks. This draft will appear at IPv6 WG meeting in San Diego. I believe comments received by DHC will be very useful to enforce this work. All comments are highly welcome. > > * M&O Flags in RA's Park 5 minutes > > - draft-daniel-ipv6-ra-mo-flags-00.txt > > - Goal: Raise awareness of work > > http://www.ietf.org/internet-drafts/draft-daniel-ipv6-ra-mo-flags-00.txt Regards. - Daniel (Soohong Daniel Park) - Mobile Platform Lab. Samsung Electronics. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Jul 20 23:08: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 XAA09589; Tue, 20 Jul 2004 23:08: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 1Bn74V-0006uy-FQ; Tue, 20 Jul 2004 22:43:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bn4lw-0005XG-GC; Tue, 20 Jul 2004 20:15: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 UAA08474; Tue, 20 Jul 2004 20:15:46 -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 1Bn4mA-0002Lx-Fb; Tue, 20 Jul 2004 20:16:03 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 20 Jul 2004 17:18:17 +0000 X-BrightmailFiltered: true Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i6L0FEIV004463; Tue, 20 Jul 2004 17:15:14 -0700 (PDT) Received: from [10.32.254.178] ([10.32.254.178]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with SMTP id AVM72215; Tue, 20 Jul 2004 17:14:02 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <083CF40C-DAAB-11D8-B13B-000A9568B702@cisco.com> Content-Transfer-Encoding: 7bit From: Richard Johnson Date: Tue, 20 Jul 2004 17:15:11 -0700 To: internet-drafts@ietf.org X-Mailer: Apple Mail (2.618) X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org Subject: [dhcwg] New Server-ID-Override draft 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 would like to submit the updated Internet draft: draft-ietf-dhc-server-id-override-02.txt I understand that this submission is too late to get into the list of drafts for the upcoming IETF conference in San Diego. I meant to get it submitted before now but things came up and I didn't make it. I just want to get it submitted anyway so it will be announced as soon as possible. The draft may be found at: ftp://ftpeng.cisco.com/raj/draft-ietf-dhc-server-override-02.txt /raj _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Jul 20 23:08: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 XAA09665; Tue, 20 Jul 2004 23:08: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 1Bn74W-0006vx-7f; Tue, 20 Jul 2004 22:43:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bn4lz-0005e1-O5; Tue, 20 Jul 2004 20:15: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 UAA08486; Tue, 20 Jul 2004 20:15:49 -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 1Bn4mB-0002M7-Gi; Tue, 20 Jul 2004 20:16:06 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 20 Jul 2004 17:18:18 +0000 X-BrightmailFiltered: true Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i6L0F48g002774; Tue, 20 Jul 2004 17:15:15 -0700 (PDT) Received: from [10.32.254.178] ([10.32.254.178]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with SMTP id AVM72207; Tue, 20 Jul 2004 17:13:53 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <02658CB6-DAAB-11D8-B13B-000A9568B702@cisco.com> Content-Transfer-Encoding: 7bit From: Richard Johnson Date: Tue, 20 Jul 2004 17:15:02 -0700 To: internet-drafts@ietf.org X-Mailer: Apple Mail (2.618) X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org Subject: [dhcwg] New Subnet Allocation Option draft 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 would like to submit the updated Internet draft: draft-ietf-dhc-subnet-alloc-01.txt I understand that this submission is too late to get into the list of drafts for the upcoming IETF conference in San Diego. I meant to get it submitted before now but things came up and I didn't make it. I just want to get it submitted anyway so it will be announced as soon as possible. The draft may be found at: ftp://ftpeng.cisco.com/raj/draft-ietf-dhc-subnet-alloc-01.txt /raj _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Jul 20 23:10: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 XAA09879; Tue, 20 Jul 2004 23:10: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 1Bn75h-0008GJ-Ix; Tue, 20 Jul 2004 22:44:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bn4vz-0001KN-9y; Tue, 20 Jul 2004 20:26: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 UAA10552; Tue, 20 Jul 2004 20:26:09 -0400 (EDT) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bn4wE-0002xq-3k; Tue, 20 Jul 2004 20:26:26 -0400 X-BrightmailFiltered: true Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i6L0F9Nv026408; Tue, 20 Jul 2004 17:15:09 -0700 (PDT) Received: from [10.32.254.178] ([10.32.254.178]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with SMTP id AVM72211; Tue, 20 Jul 2004 17:13:58 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <05BFE01E-DAAB-11D8-B13B-000A9568B702@cisco.com> Content-Transfer-Encoding: 7bit From: Richard Johnson Date: Tue, 20 Jul 2004 17:15:07 -0700 To: internet-drafts@ietf.org X-Mailer: Apple Mail (2.618) X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org Subject: [dhcwg] New VPN Option draft 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 would like to submit the updated Internet draft: draft-ietf-dhc-vpn-option-04.txt I understand that this submission is too late to get into the list of drafts for the upcoming IETF conference in San Diego. I meant to get it submitted before now but things came up and I didn't make it. I just want to get it submitted anyway so it will be announced as soon as possible. The draft may be found at: ftp://ftpeng.cisco.com/raj/draft-ietf-dhc-vpn-option-04.txt /raj _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Jul 20 23:18: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 XAA10830; Tue, 20 Jul 2004 23:18: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 1Bn7CH-0002V2-PO; Tue, 20 Jul 2004 22:51:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bn6YF-00026x-G1 for dhcwg@megatron.ietf.org; Tue, 20 Jul 2004 22:09: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 WAA29225 for ; Tue, 20 Jul 2004 22:09:45 -0400 (EDT) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bn6YS-00081k-G1 for dhcwg@ietf.org; Tue, 20 Jul 2004 22:10:03 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 20 Jul 2004 22:14:09 -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 i6L29AGZ027475 for ; Tue, 20 Jul 2004 22:09:11 -0400 (EDT) Received: from volzw2k (che-vpn-cluster-1-184.cisco.com [10.86.240.184]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AKG56322; Tue, 20 Jul 2004 22:09:09 -0400 (EDT) From: "Bernie Volz" To: Date: Tue, 20 Jul 2004 22:09:07 -0400 Organization: Cisco Message-ID: <000701c46ec7$b4728d90$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 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4939.300 X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: 7bit Subject: [dhcwg] New 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 The DHCPv6 Client FQDN option draft has been posted, see http://www.ietf.org/internet-drafts/draft-volz-dhc-dhcpv6-fqdn-00.txt. I hope this can become a DHC Working Group item. Abstract This document specifies a new DHCP for IPv6, DHCPv6, option which can be used to exchange information about a DHCPv6 client's fully-qualified domain name and about responsibility for updating DNS RRs related to the client's address assignments. Best regards, - Bernie Volz _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Jul 21 00:42: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 AAA17024; Wed, 21 Jul 2004 00:42: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 1Bn8ta-0007Tu-MP; Wed, 21 Jul 2004 00:39:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bn8iS-0008AL-IN for dhcwg@megatron.ietf.org; Wed, 21 Jul 2004 00:28:28 -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 AAA16202 for ; Wed, 21 Jul 2004 00:28:25 -0400 (EDT) Received: from mailout2.samsung.com ([203.254.224.25]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bn8ii-0004EN-8L for dhcwg@ietf.org; Wed, 21 Jul 2004 00:28:45 -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 <0I1600E01PQIHZ@mailout2.samsung.com> for dhcwg@ietf.org; Wed, 21 Jul 2004 13:27:54 +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 <0I16000Z5PQINP@mailout2.samsung.com> for dhcwg@ietf.org; Wed, 21 Jul 2004 13:27:54 +0900 (KST) Received: from LocalHost ([168.219.202.103]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0I16003AFPQH4V@mmp2.samsung.com> for dhcwg@ietf.org; Wed, 21 Jul 2004 13:27:53 +0900 (KST) Date: Wed, 21 Jul 2004 13:28:51 +0900 From: Soohong Daniel Park To: Dhcwg Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Content-type: text/plain; charset=ks_c_5601-1987 Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7BIT Subject: [dhcwg] [I-D Announcement] DHCP for configuring IPv6-over-IPv4 Tunnels 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 This draft was presented at Seoul meeting, after then V6OPS WG did a "request for comment" on this draft following the meeting consensus. Consequently, I received several comments and I willl appear it at this meeting. Also we are about to implement this protocol and I can show the result of this implementation as well. Filename is http://www.ietf.org/internet-drafts/draft-daniel-dhc-ipv6in4-opt-04.txt If failed to touch above link, please click below individual link. http://home.megapass.co.kr/~natpp00/draft-daniel-dhc-ipv6in4-opt-04.txt I hope this draft will be an working group item at this meeting. All comments are highly welcome. Regards. - Daniel (Soohong Daniel Park) - Mobile Platform Lab. Samsung Electronics. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Jul 21 16:25: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 QAA24106; Wed, 21 Jul 2004 16:25: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 1BnMxi-0006bd-7F; Wed, 21 Jul 2004 15:41:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BnMmp-0002fs-3N; Wed, 21 Jul 2004 15:29:55 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16161; Wed, 21 Jul 2004 15:29:53 -0400 (EDT) Message-Id: <200407211929.PAA16161@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, 21 Jul 2004 15:29:52 -0400 Cc: dhcwg@ietf.org Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-dna-ipv4-08.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 : Detection of Network Attachment (DNA) in IPv4 Author(s) : B. Aboba Filename : draft-ietf-dhc-dna-ipv4-08.txt Pages : 16 Date : 2004-7-21 The time required to detect movement (or lack of movement) between subnets, and to obtain (or continue to use) a valid IPv4 address may be significant as a fraction of the total delay in moving between points of attachment. This document synthesizes experience garnered over the years in the deployment of hosts supporting ARP, DHCP and Link-Local IPv4 addresses. A procedure is specified for detection of network attachment in order to better accommodate mobile hosts. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-dna-ipv4-08.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-dna-ipv4-08.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dhc-dna-ipv4-08.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-7-21152605.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-dna-ipv4-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-dna-ipv4-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-7-21152605.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 Jul 21 16:28: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 QAA24682; Wed, 21 Jul 2004 16:28: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 1BnMxo-0006fE-1h; Wed, 21 Jul 2004 15: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 1BnMnA-0002jv-0w; Wed, 21 Jul 2004 15:30:16 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16203; Wed, 21 Jul 2004 15:30:13 -0400 (EDT) Message-Id: <200407211930.PAA16203@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, 21 Jul 2004 15:30:13 -0400 Cc: dhcwg@ietf.org Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-dual-stack-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 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Title : DHCP: IPv4 and IPv6 Dual-Stack Issues Author(s) : T. Chown, et al. Filename : draft-ietf-dhc-dual-stack-01.txt Pages : 12 Date : 2004-7-21 A node may have support for communications using IPv4 and/or IPv6 protocols. Such a node may wish to obtain IPv4 and/or IPv6 configuration settings via the Dynamic Host Configuration Protocol (DHCP). The original version of DHCP [1] designed for IPv4 has now been complemented by a new DHCPv6 [4] for IPv6. This document describes issues identified with dual IP version DHCP interactions, the most important aspect of which is how to handle potential problems in clients processing configuration information received from DHCPv4 and DHCPv6 servers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-dual-stack-01.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-dual-stack-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dhc-dual-stack-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-7-21152610.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-dual-stack-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-dual-stack-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-7-21152610.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 Jul 21 16:32: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 QAA25415; Wed, 21 Jul 2004 16:32: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 1BnMxu-0006ii-5Y; Wed, 21 Jul 2004 15:41:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BnMnc-00034a-EH; Wed, 21 Jul 2004 15:30:44 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16252; Wed, 21 Jul 2004 15:30:42 -0400 (EDT) Message-Id: <200407211930.PAA16252@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, 21 Jul 2004 15:30:42 -0400 Cc: dhcwg@ietf.org Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-3315id-for-v4-03.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 : Node-Specific Client Identifiers for DHCPv4 Author(s) : T. Lemon, B. Sommerfeld Filename : draft-ietf-dhc-3315id-for-v4-03.txt Pages : 8 Date : 2004-7-21 This document specifies the format that is to be used for encoding DHCPv4 [RFC2131 and RFC2132] client identifiers, so that those identifiers will be interchangeable with identifiers used in the DHCPv6 protocol [RFC3315]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-3315id-for-v4-03.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-3315id-for-v4-03.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-3315id-for-v4-03.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-7-21152615.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-3315id-for-v4-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-3315id-for-v4-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-7-21152615.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 Thu Jul 22 05:04: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 FAA01966; Thu, 22 Jul 2004 05:04: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 1BnZTa-0000CQ-72; Thu, 22 Jul 2004 05:02:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BnZSB-0008Kk-TS; Thu, 22 Jul 2004 05: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 FAA01799; Thu, 22 Jul 2004 05:01:25 -0400 (EDT) Received: from [200.45.191.180] (helo=smtp-mx-03.ti.local) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BnZSi-0005v4-Ef; Thu, 22 Jul 2004 05:02:00 -0400 Received: from mail pickup service by smtp-mx-03.ti.local with Microsoft SMTPSVC; Thu, 22 Jul 2004 06:00:40 -0300 Received: from qsmtp-mx-03.arnet.com.ar ([200.45.191.166]) by smtp-mx-03.ti.local with Microsoft SMTPSVC(5.0.2195.6713); Tue, 20 Jul 2004 18:02:13 -0300 Received: (qmail 2711 invoked from network); 20 Jul 2004 20:52:43 -0000 Received: from unknown (HELO megatron.ietf.org) (132.151.6.71) by host191166.arnet.net.ar with SMTP; 20 Jul 2004 20:52:42 -0000 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bn0wA-0004xV-1x; Tue, 20 Jul 2004 16:10:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bn0Z7-0007eU-DA; Tue, 20 Jul 2004 15:46:17 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20998; Tue, 20 Jul 2004 15:46:15 -0400 (EDT) Message-Id: <200407201946.PAA20998@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Tue, 20 Jul 2004 15:46:15 -0400 X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.5 Precedence: list X-OriginalArrivalTime: 20 Jul 2004 21:02:13.0134 (UTC) FILETIME=[D470EAE0:01C46E9C] X-Spam-Score: 0.4 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Cc: dhcwg@ietf.org Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-ddns-resolution-07.txt X-BeenThere: dhcwg@ietf.org Reply-To: internet-drafts@ietf.org 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 : Resolution of DNS Name Conflicts Among DHCP Clients Author(s) : M. Stapp, B. Volz Filename : draft-ietf-dhc-ddns-resolution-07.txt Pages : 13 Date : 2004-7-20 DHCP provides a powerful mechanism for IP host configuration. However, the configuration capability provided by DHCP does not include updating DNS, and specifically updating the name to address and address to name mappings maintained in the DNS. This document describes techniques for the resolution of DNS name conflicts among DHCP clients. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-ddns-resolution-07.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-ddns-resolution-07.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-ddns-resolution-07.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-7-20155310.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-ddns-resolution-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-ddns-resolution-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-7-20155310.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 Content-Transfer-Encoding: 7bit _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --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 Fri Jul 23 07:00: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 HAA10241; Fri, 23 Jul 2004 07:00: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 1BnxiK-0002XS-Qy; Fri, 23 Jul 2004 06:55:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BnxcL-0000P4-FQ; Fri, 23 Jul 2004 06:49: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 GAA09320; Fri, 23 Jul 2004 06:49:30 -0400 (EDT) Received: from [200.45.191.180] (helo=mail-fe-02) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bnxd3-0003Ad-Oz; Fri, 23 Jul 2004 06:50:20 -0400 Received: from mail pickup service by mail-fe-02 with Microsoft SMTPSVC; Fri, 23 Jul 2004 07:48:07 -0300 Received: from qsmtp-mx-03.arnet.com.ar ([200.45.191.166]) by mail-fe-02 with Microsoft SMTPSVC(5.0.2195.6713); Tue, 20 Jul 2004 18:32:35 -0300 Received: from unknown (HELO megatron.ietf.org) (132.151.6.71) by host191166.arnet.net.ar with SMTP; 20 Jul 2004 21:30:05 -0000 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bn0wD-0004y0-DB; Tue, 20 Jul 2004 16:10:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bn0Za-0007mD-Vu; Tue, 20 Jul 2004 15:46:47 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21053; Tue, 20 Jul 2004 15:46:44 -0400 (EDT) Message-Id: <200407201946.PAA21053@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Tue, 20 Jul 2004 15:46:44 -0400 X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.5 Precedence: list X-OriginalArrivalTime: 20 Jul 2004 21:32:35.0617 (UTC) FILETIME=[12B9C110:01C46EA1] X-Spam-Score: 0.4 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Cc: dhcwg@ietf.org Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-fqdn-option-07.txt X-BeenThere: dhcwg@ietf.org Reply-To: internet-drafts@ietf.org 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 DHCP Client FQDN Option Author(s) : M. Stapp, et al. Filename : draft-ietf-dhc-fqdn-option-07.txt Pages : 15 Date : 2004-7-20 This document specifies a DHCP for IPv4, DHCPv4, option which can be used to exchange information about a DHCPv4 client's fully-qualified domain name and about responsibility for updating the DNS RR related to the client's address assignment. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-fqdn-option-07.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-fqdn-option-07.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-fqdn-option-07.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-7-20155316.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-fqdn-option-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-fqdn-option-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-7-20155316.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 Content-Transfer-Encoding: 7bit _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --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 Fri Jul 23 08:07: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 IAA15383; Fri, 23 Jul 2004 08:07: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 1Bnyhu-000316-1V; Fri, 23 Jul 2004 07:59:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bnye8-0001OX-D8; Fri, 23 Jul 2004 07:55:28 -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 HAA14546; Fri, 23 Jul 2004 07:55:27 -0400 (EDT) Received: from [200.45.191.180] (helo=smtp-mx-01.ti.local) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bnyet-0004XX-F0; Fri, 23 Jul 2004 07:56:15 -0400 Received: from MSG-BE-02.ti.local ([192.168.220.105]) by smtp-mx-01.ti.local with Microsoft SMTPSVC(5.0.2195.6713); Fri, 23 Jul 2004 08:53:43 -0300 Received: from mail pickup service by MSG-BE-02.ti.local with Microsoft SMTPSVC; Fri, 23 Jul 2004 08:53:33 -0300 Received: from smtp-mx-01.ti.local ([192.168.220.20]) by MSG-BE-02.ti.local with Microsoft SMTPSVC(5.0.2195.6713); Thu, 22 Jul 2004 00:04:10 -0300 Received: from qsmtp-mx-03.arnet.com.ar ([200.45.191.166]) by smtp-mx-01.ti.local with Microsoft SMTPSVC(5.0.2195.6713); Wed, 21 Jul 2004 17:28:06 -0300 Received: from unknown (HELO megatron.ietf.org) (132.151.6.71) by host191166.arnet.net.ar with SMTP; 21 Jul 2004 20:25:32 -0000 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BnMxn-0006d3-0n; Wed, 21 Jul 2004 15:41:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BnMmp-0002fs-3N; Wed, 21 Jul 2004 15:29:55 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16161; Wed, 21 Jul 2004 15:29:53 -0400 (EDT) Message-Id: <200407211929.PAA16161@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, 21 Jul 2004 15:29:52 -0400 X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.5 Precedence: list X-OriginalArrivalTime: 21 Jul 2004 20:28:06.0796 (UTC) FILETIME=[3B2444C0:01C46F61] X-Spam-Score: 0.4 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Cc: dhcwg@ietf.org Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-dna-ipv4-08.txt X-BeenThere: dhcwg@ietf.org Reply-To: internet-drafts@ietf.org 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 : Detection of Network Attachment (DNA) in IPv4 Author(s) : B. Aboba Filename : draft-ietf-dhc-dna-ipv4-08.txt Pages : 16 Date : 2004-7-21 The time required to detect movement (or lack of movement) between subnets, and to obtain (or continue to use) a valid IPv4 address may be significant as a fraction of the total delay in moving between points of attachment. This document synthesizes experience garnered over the years in the deployment of hosts supporting ARP, DHCP and Link-Local IPv4 addresses. A procedure is specified for detection of network attachment in order to better accommodate mobile hosts. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-dna-ipv4-08.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-dna-ipv4-08.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dhc-dna-ipv4-08.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-7-21152605.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-dna-ipv4-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-dna-ipv4-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-7-21152605.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 Content-Transfer-Encoding: 7bit _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --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 Fri Jul 23 08:42: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 IAA18238; Fri, 23 Jul 2004 08:42: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 1BnzLQ-0002dl-2i; Fri, 23 Jul 2004 08:40:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BnzHh-0001Dg-PB; Fri, 23 Jul 2004 08:36: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 IAA17829; Fri, 23 Jul 2004 08:36:20 -0400 (EDT) Received: from [200.45.191.180] (helo=smtp-mx-04.ti.local) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BnzIR-0005VZ-NC; Fri, 23 Jul 2004 08:37:09 -0400 Received: from mail pickup service by smtp-mx-04.ti.local with Microsoft SMTPSVC; Fri, 23 Jul 2004 09:35:27 -0300 Received: from qsmtp-mx-05.arnet.com.ar ([200.45.191.168]) by smtp-mx-04.ti.local with Microsoft SMTPSVC(5.0.2195.6713); Tue, 20 Jul 2004 17:51:07 -0300 Received: from unknown (HELO megatron.ietf.org) (132.151.6.71) by host191168.arnet.net.ar with SMTP; 20 Jul 2004 20:48:34 -0000 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bn0w5-0004wM-KF; Tue, 20 Jul 2004 16:10:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bn0Yc-0007dW-2D; Tue, 20 Jul 2004 15:45:46 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20960; Tue, 20 Jul 2004 15:45:44 -0400 (EDT) Message-Id: <200407201945.PAA20960@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Tue, 20 Jul 2004 15:45:43 -0400 X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.5 Precedence: list X-OriginalArrivalTime: 20 Jul 2004 20:51:07.0997 (UTC) FILETIME=[47FD10D0:01C46E9B] X-Spam-Score: 0.4 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Cc: dhcwg@ietf.org Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-stateless-dhcpv6-renumbering-01.txt X-BeenThere: dhcwg@ietf.org Reply-To: internet-drafts@ietf.org 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 : Renumbering Requirements for Stateless DHCPv6 Author(s) : T. Chown, et al. Filename : draft-ietf-dhc-stateless-dhcpv6-renumbering-01.txt Pages : 8 Date : 2004-7-20 IPv6 hosts using Stateless Address Autoconfiguration are able to automatically configure their IPv6 address and default router settings. However, further settings are not available. If such hosts wish to automatically configure their DNS, NTP or other specific settings the stateless variant of the Dynamic Host Configuration Protocol for IPv6 (DHCPv6) could be used. This combination of Stateless Address Autoconfiguration and stateless DHCPv6 could be used quite commonly in IPv6 networks. However, hosts using such a combination currently have no means by which to be informed of changes in stateless DHCPv6 option settings, e.g. the addition of a new NTP server address, changes in DNS search paths, or full site renumbering. This document is presented as a problem statement from which a solution should be proposed in a subsequent document. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-stateless-dhcpv6-renumbering-01.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-stateless-dhcpv6-renumbering-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dhc-stateless-dhcpv6-renumbering-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-7-20155305.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-stateless-dhcpv6-renumbering-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-stateless-dhcpv6-renumbering-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-7-20155305.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 Content-Transfer-Encoding: 7bit _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --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 Fri Jul 23 10:39: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 KAA28196; Fri, 23 Jul 2004 10:39: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 1Bo19s-0007aC-U5; Fri, 23 Jul 2004 10:36:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BmZWp-0002Cj-U5 for dhcwg@megatron.ietf.org; Mon, 19 Jul 2004 10:54:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23698 for ; Mon, 19 Jul 2004 10:54:05 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BmZWp-00023q-1e for dhcwg@ietf.org; Mon, 19 Jul 2004 10:54:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BmZVx-0001o0-00 for dhcwg@ietf.org; Mon, 19 Jul 2004 10:53:13 -0400 Received: from mail.orionfoodsys.com ([12.13.126.36] helo=SVRSCAN01.orionfoodsys.com) by ietf-mx with esmtp (Exim 4.12) id 1BmZUz-0001Jl-00 for dhcwg@ietf.org; Mon, 19 Jul 2004 10:52:13 -0400 Received: by fsd-orion001 with Internet Mail Service (5.5.2653.19) id <399JJFFP>; Mon, 19 Jul 2004 09:51:41 -0500 Message-ID: <87F5107CDCC4D611B8FA0002A543CACE046349C1@fsd-orion001> From: Nicholas Claus To: "'dhcwg@ietf.org'" Date: Mon, 19 Jul 2004 09:51:32 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=HTML_50_60,HTML_MESSAGE autolearn=no version=2.60 X-Mailman-Approved-At: Fri, 23 Jul 2004 10:36:22 -0400 Subject: [dhcwg] 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: , Content-Type: multipart/mixed; boundary="===============1211047325==" 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. --===============1211047325== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C46D9F.E1D3B634" 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_01C46D9F.E1D3B634 Content-Type: text/plain We are currently running NT 4.0 server environment with windows XP pro clients that use DHCP internally. We are experiencing problems with laptop users (xp pro and win2000) that either RAS in or VPN with DHCP doubling up or even tripling up on one IP address. This in turn knocks the other user/users off requiring them to reboot their PC to reaquire their IP address. Any ideas on why this may be happening? My work around has been to change the users to static until this is resolved. TIA Nick ------_=_NextPart_001_01C46D9F.E1D3B634 Content-Type: text/html Content-Transfer-Encoding: quoted-printable

We are currently running NT 4.0 server environment = with windows XP pro clients that use DHCP internally. We are experiencing = problems with laptop users (xp pro and win2000) that either RAS in or VPN with = DHCP doubling up or even tripling up on one IP address. This in turn knocks = the other user/users off requiring them to reboot their PC to reaquire = their IP address. Any ideas on why this may be happening? My work around has = been to change the users to static until this is resolved. =

 

TIA

Nick

------_=_NextPart_001_01C46D9F.E1D3B634-- --===============1211047325== 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 --===============1211047325==-- From dhcwg-bounces@ietf.org Fri Jul 23 10:44: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 KAA28711; Fri, 23 Jul 2004 10:44: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 1Bo1B4-0007tM-8b; Fri, 23 Jul 2004 10:37:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BnNNj-0000mw-7D for dhcwg@megatron.ietf.org; Wed, 21 Jul 2004 16:08: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 QAA20676 for ; Wed, 21 Jul 2004 16:08:00 -0400 (EDT) Received: from h-66-167-171-107.sttnwaho.covad.net ([66.167.171.107] helo=internaut.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BnNO7-0000Nt-EJ for dhcwg@ietf.org; Wed, 21 Jul 2004 16:08:29 -0400 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i6LK5GO26993 for ; Wed, 21 Jul 2004 13:05:16 -0700 Date: Wed, 21 Jul 2004 13:05:15 -0700 (PDT) From: Bernard Aboba To: dhcwg@ietf.org In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 X-Mailman-Approved-At: Fri, 23 Jul 2004 10:37:37 -0400 Subject: [dhcwg] Proposed Resolution to DNA Issue 20: Most Likely Point of Attachment 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 text of DNA Issue 20: Most Likely Point of Attachment, is enclosed below. The proposed resolution is as follows: Add the following definitions to the terminology section: Point of Attachment: A location within the network, where a host may be connected. This attachment point can be characterized by its address prefix and next hop routing information. Most Likely Point of Attachment (MLPA): The point of attachment heuristically determined by the host to be most likely, based on hints from the network. Use the abbreviation "MLPA" throughout the document. This change is included in the DNA-08 draft: http://www.ietf.org/internet-drafts/draft-ietf-dhc-dna-ipv4-08.txt For DNA Issue Status, see: http://www.drizzle.com/~aboba/DNA/dnaissues.html --------------------------------------------------------------------- Issue 20: Most Likely Point of Attachment Submitter name: Ralph Droms Submitter email address: rdroms@cisco.com Date first submitted: 10/16/2003 Reference: http://www1.ietf.org/mail-archive/web/dhcwg/current/msg02473.html Document: DNA-03 Comment type: E Priority: 1 Section: 1.2 Rationale/Explanation of issue: The phrase '"most likely" point of attachment' is used throughout the document but is never defined. Other, similar phrases are occasionally used, such as '"most likely" network' in the fourth paragraph of section 2.3. Requested change: Add a definition for '"most likely" point of attachment' to the terminology section. Define an acronym MLPA for the phrase. Use the acronym throughout the document. Note that, as much as I dislike the proliferation of acronyms in IETF documents, in this case I think an acronym, suitably defined in the Terminology section, would add clarity. [Greg Daley] In DNA BoF, we're obviously interested in having common terminology across the set of techniques (v4/v6) to detect network attachment. There's currently some work in the BoF on getting terminology worked out. So that we don't slow anything down in DHC-WG, maybe we can help contribute to the terms here, and clone them into DNA. Does that sound reasonable? In this case, is it sufficient to define the most likely point of attachment, or do we also need to define "point of attachment"? I myself am clear what a point of attachment is. Is the meaning unambiguous to others, or would it simplify the definition of the MLPA to have a definition of the point of attachment? Here are some initial attempts at both options: -- Most Likely Point of Attachment (MLPA): The IP subnet and router combination the host is most likely to be connected to the network through. This is heuristically determined by the host itself by hints from the network. -- Alternatively: -- Point of Attachment: A location within the network, where a host may be connected. This attachment point can be characterized by its address prefix and next hop routing information. Most Likely Point of Attachment (MLPA): The point of attachment heuristically determined by the host to be most likely, based on hints from the network. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri Jul 23 10:48: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 KAA29009; Fri, 23 Jul 2004 10:48: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 1Bo1B4-0007tR-J4; Fri, 23 Jul 2004 10:37:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BnNQT-0001zN-Kh for dhcwg@megatron.ietf.org; Wed, 21 Jul 2004 16:10: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 QAA21128 for ; Wed, 21 Jul 2004 16:10:51 -0400 (EDT) Received: from h-66-167-171-107.sttnwaho.covad.net ([66.167.171.107] helo=internaut.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BnNQt-0000XD-10 for dhcwg@ietf.org; Wed, 21 Jul 2004 16:11:19 -0400 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i6LK8Bn27138 for ; Wed, 21 Jul 2004 13:08:11 -0700 Date: Wed, 21 Jul 2004 13:08:11 -0700 (PDT) From: Bernard Aboba 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: f66b12316365a3fe519e75911daf28a8 X-Mailman-Approved-At: Fri, 23 Jul 2004 10:37:37 -0400 Subject: [dhcwg] Proposed Resolution to DNA Issue 21: Review of DNA-07 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 text of DNA Issue 21: Review of DNA-07 is enclosed below. The proposed resolution is as follows: Change Section 1 to the following: "The time required to detect movement (or lack of movement) between subnets, and to obtain (or continue to use) a valid IPv4 address may be significant as a fraction of the total delay in moving between points of attachment. As a result, optimizing detection of network attachment is important for mobile hosts. This document synthesizes experience in the deployment of hosts supporting ARP [RFC826], DHCP [RFC2131], and Link-Local IPv4 addresses [IPv4LL], specifying a procedure to be performed for IPv4 detection of network attachment. The procedure consists of three phases: determination of the Most Likely Point of Attachment (MLPA), reachability testing, and IPv4 address acquisition." Add the following sentence to Section 2.3: "If the host supports the Rapid Commit Option [RAPID], it is possible that the exchange can be shortened from a 4-message exchange to a 2-message exchange." Add the following Informative reference: [RAPID] Park, S., Kim, P., and B. Volz, "Rapid Commit Option for DHCPv4", Internet draft (work in progress), draft-ietf-dhc-rapid-commit-opt-05.txt, June 2004. This change has been included in DNA-08: http://www.drizzle.com/~aboba/DNA/draft-ietf-dhc-dna-ipv4-08.txt Issue status is available at: http://www.drizzle.com/~aboba/DNA/dnaissues.html --------------------------------------------------------------- Issue 21: Review of DNA-07 Submitter name: Soohong Daniel Park Submitter email address: soohong.park@samsung.com Date first submitted: 6/23/2004 Reference: http://www1.ietf.org/mail-archive/web/dhcwg/current/msg03663.html Document: DNA-07 Comment type: T Priority: S Section: Various Rationale/Explanation of issue: My comments are as below; [1] Category is correct as PS ? I think BCP would be better. [2] 1. Introduction, >This document concerns the interaction of mechanisms used by IPv4 >protocol stacks. Network attachment detection and its interaction >with interface configuration is considered elsewhere, for example in >Neighbor Discovery for IPv6 [RFC2461], IPv6 Stateless Address >Autoconfiguration [RFC2462] and Mobility Support in IPv6 [MIPv6]. I am not sure why this draft refers rfc2461,2462 and even MIPv6. This draft is strictly bound to IPv4 especially DHCPv4 and IPv4LL and something like that, so I think we don't need to refer IPv6 protocol. [3] 2.3 IPv4 Address Acquisition To obtain its IPv4 address quickly, Rapid Commit option of DHCPv4 can be used for optimizing detection of network attachment on mobile hosts. With my experience, it's stable and fast than current mechanism, thus if feasible, you can indicate this utility at this section. http://www.ietf.org/internet-drafts/draft-ietf-dhc-rapid-commit-opt-03.txt (I updated and published it as 04 version yesterday) For reference, I cite a result of comparison between them. (It was tested on both wired and wireless though testbed was so simple) =========================================== Item Mean value Standard deviation =========================================== Time delay (sec.) Existing 0.051269 0.002349 New 0.001541 0.001213 =========================================== Packet loss (packet) Existing 417.04 53.10322 New 366.02 32.55092 =========================================== _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri Jul 23 10:48: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 KAA29117; Fri, 23 Jul 2004 10:48: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 1Bo1B4-0007tW-UN; Fri, 23 Jul 2004 10:37:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BnNUD-0004hu-OI for dhcwg@megatron.ietf.org; Wed, 21 Jul 2004 16:14: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 QAA21846 for ; Wed, 21 Jul 2004 16:14:43 -0400 (EDT) Received: from h-66-167-171-107.sttnwaho.covad.net ([66.167.171.107] helo=internaut.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BnNUc-0000lE-S5 for dhcwg@ietf.org; Wed, 21 Jul 2004 16:15:11 -0400 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i6LKC3R27333 for ; Wed, 21 Jul 2004 13:12:03 -0700 Date: Wed, 21 Jul 2004 13:12:03 -0700 (PDT) From: Bernard Aboba 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: 14582b0692e7f70ce7111d04db3781c8 X-Mailman-Approved-At: Fri, 23 Jul 2004 10:37:37 -0400 Subject: [dhcwg] Proposed Resolution of DNA Issue 19: Review of DNA-07 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 text of DNA Issue 19: Review of DNA-07 is enclosed below. The proposed resolution is as follows: In Section 2, delete: "[c] Treatment of link-down indications. On disconnection from a network, there is no need to take action until the host is reconnected, since it is typically not possible for a host to communicate until it has obtained connectivity. Therefore, contrary to [RFC2131] Section 3.7, no action need be taken on network disconnection." In Section 2.2, change [a]-[d] to the following: [a] The host does not have a valid routable IPv4 address on the "most likely" point of attachment. In this case, it is not possible to confirm that the host has a valid routable IPv4 address, so that the reachability test is unnecessary. [b] The host does not have information on the default gateway(s) for the "most likely" point of attachment. In this case, it is not possible to carry out the reachability test. [c] Reliable hints are unavailable. Since confirming failure of the reachability test requires a timeout, mistakes are costly. In the absence of reliable hints, a host SHOULD instead send a DHCPREQUEST from the INIT-REBOOT state, as described in [RFC2131], Section 3.2 and 4.3.2. Where reliable hints are unavailable, this will on average complete more quickly than the reachability test. [d] If secure detection of network attachment is required. The reachability test utilizes ARP which is insecure, whereas DHCP can be secured via DHCP authentication, described in [RFC3118]. See Section 5 for details. These changes are included in DNA-08: http://www.drizzle.com/~aboba/DNA/draft-ietf-dhc-dna-ipv4-08.txt Issue Status is available at: http://www.drizzle.com/~aboba/DNA/dnaissues.html ----------------------------------------------------------------- Issue 19: Review of DNA-07 Submitter: Jim Busse Submitter email address: jimbusse@pacbell.net Date first submitted: June 5, 2004 Reference: Document: DNAv4-07 Comment type: T Priority: S Section: Various Rationale/Explanation of issue: The DNA sentence "On disconnection from a network, there is no need to take action until the host is reconnected" does not reflect the state of Windows communications stacks in numerous products. In fact, action is required so applications' various function calls don't hang and sometimes blue screen the client. As a test, take a win98 SE client, open IE and go to a page that takes a long time to load. During the load, disconnect the Ethernet cable, and hit the refresh button 8-10 times. You'll BSOD. Regarding the reachability section 2.2, it's unclear whether the items a,b,c,d are "and'ed" or "or'ed" for truth. Or, it may take a and c for truth, or b for truth, for example--it's just not clear. I did a truth table based on the standard, and one of my engineers did a truth table after reading the document, and both were different. The other item regarding reachability: you of course have much more experience than I, but we have found the case where gateways are unreachable for one reason or another (sometimes for lengthy periods of time), but the proxy server is reachable, and it looks to the user like a gateway is there--who knows the difference? So for a client with fixed IP configuration, when the gateway goes down, the reachability test will fail, a link-local address will be assigned, and the next instance of the browser won't be able to reach the proxy server. The gateway will come back up, but a DHCP address won't be assigned because the client started with a fixed IP configuration but now has a link-local address assigned. The link-local address isn't DHCP assigned, and Windows won't release it.or renew it. The only way we found to get Windows to dump the LL address was to stop and restart the interface with the registry set to the correct values for the restart. This of course trashes all pending transactions and can be harmful to some applications. Like IE--you need to close it and re-open it. That was the purpose of my original question, and your response was correct--just the fact that you can't reach it now doesn't mean you should assign and use a new address. So the implementers of the standard will be confused: just when *should* you assign and use a new address? (rhetorical question). _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon Jul 26 04:09: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 EAA07857; Mon, 26 Jul 2004 04:09: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 1Bp0SF-0003Jj-SE; Mon, 26 Jul 2004 04:03:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bp0Nf-0002q1-Mm for dhcwg@megatron.ietf.org; Mon, 26 Jul 2004 03:58: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 DAA07369 for ; Mon, 26 Jul 2004 03:58:41 -0400 (EDT) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bp0P0-0001Ze-M8 for dhcwg@ietf.org; Mon, 26 Jul 2004 04:00:08 -0400 Received: from ocean.jinmei.org (unknown [3ffe:501:100f:1048:7d91:64be:e17:f09d]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id EE91C15273; Mon, 26 Jul 2004 16:58:39 +0900 (JST) Date: Mon, 26 Jul 2004 16:58:40 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Christian Strauf Subject: Re: [dhcwg] Comments on draft-jinmei-dhc-dhcpv6-clarify-auth-00 In-Reply-To: <1090333421.11056.266.camel@localhost> References: <1090333421.11056.266.camel@localhost> 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: f4c2cf0bccc868e4cc88dace71fb3f44 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 Hello, Thanks for your positive feedback, and sorry for the delayed response. >>>>> On Tue, 20 Jul 2004 16:23:41 +0200, >>>>> Christian Strauf said: > I paragraph 4. you write: > "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 but does not have > authentication information when necessary." > 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): > "A reasonable interpretation of the phrase is as follows: a DHCPv6 > message is called unauthenticated if it fails the validation test > described in Section 21.4.2, if it does not contain an authentication > option, or if it includes an authentication option without the necessary > authentication information." OK. I've modified the local source of the draft with the suggested change. > Minor typos: > 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 > para 3.: > -3. What If Reply Is Detected > +3. What If Replay Is Detected > para 5.: > -Apparently this contradicts with the requirement in Section > 21.4.2. > +Apparently this contradicts the requirement in Section 21.4.2. > para 5.1.: > -Accepting an non-authenticated > +Accepting a non-authenticated Thanks, fixed in the local source. (The second and fourth typos should already be fixed in the published version of the draft. I guess your comments are for a preliminary version available at my web page.) 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 Jul 26 05:15: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 FAA10278; Mon, 26 Jul 2004 05:15: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 1Bp1Yf-0004iM-EA; Mon, 26 Jul 2004 05:14:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bp1VJ-0004Dz-P1 for dhcwg@megatron.ietf.org; Mon, 26 Jul 2004 05:10: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 FAA10160 for ; Mon, 26 Jul 2004 05:10:39 -0400 (EDT) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bp1Wc-0002YP-OA for dhcwg@ietf.org; Mon, 26 Jul 2004 05:12:06 -0400 Received: from ocean.jinmei.org (unknown [3ffe:501:100f:1048:7d91:64be:e17:f09d]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 471731525D; Mon, 26 Jul 2004 18:10:35 +0900 (JST) Date: Mon, 26 Jul 2004 18:10:35 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Stig Venaas Subject: Re: [dhcwg] Comments on draft-jinmei-dhc-dhcpv6-clarify-auth-00 In-Reply-To: <20040720145508.GL29655@sverresborg.uninett.no> References: <1090333421.11056.266.camel@localhost> <20040720145508.GL29655@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: 244a2fd369eaf00ce6820a760a3de2e8 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, 20 Jul 2004 16:55:08 +0200, >>>>> Stig Venaas said: > The server MUST record the identifier of the key selected for the > client so that it can validate further Information-request > messages from the client if the client reuses the same key for the > future exchanges. > I must confess I haven't looked much at DHCP authentication, but I think > it's nice to prevent per-client state for "stateless" (RFC3736) DHCP > servers if possible. > Wouldn't it be possible to pass some sort of key id to the client, > which the client can include in future exchanges? The server could > perhaps have a fixed mapping between key id's and keys, and based > on the id, the server knows which key to use. I'm not sure if you > see what I mean, but my idea is if possible to keep the necessary > state in the clients rather than the servers. Might this be > possible? Or would there be security problems? This might be implementation-dependent, but I guess it will work if we do not have to worry about replay attacks; it is obvious we need per-client/server state to implement replay detection. > Using assymetric crypto one could easily have just one fixed key > for all messages sent by the client. But I guess that might make > the server vulnerable to DoS attacks. I'm not sure why you mention the asymmetric crypto case, but the current authentication mechanism defined for DHCPv6 does not use asymmetric crypto. > For stateless I think it's generally enough to authenticate the DHCP > server. In most cases I don't think it's important to guard against > replay, or to authenticate the client. That could perhaps simplify > the security mechanism. It's relatively easy to guard against replay > anyway though. On the one hand, I see and tend to agree that it's nice to prevent per-client state for "stateless" DHCP. On the other hand, we should be very careful when we are going to justify something that could introduce weaker security. While the current main usage for stateless DHCP is client independent, the specification leaves the possibility for per-client configuration (otherwise, we could have prohibited including the client identifier option in Information-request in the first place). Regarding replay attacks, the client might want to minimize the possibility of receiving a replayed reply to Information-request that contains a very small lifetime in the lifetime option. Perhaps a possible compromise would be something like this: - loosen the "MUST record the per-client state" to SHOULD - allow (using MAY) the server to not record the state when replay attacks can be ignored and it is acceptable that Information-request is always non-authenticated What do you think? 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 Jul 27 05:39: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 FAA00726; Tue, 27 Jul 2004 05:39: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 1BpOMT-0007ty-97; Tue, 27 Jul 2004 05:35:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BpOJU-0007b1-TK for dhcwg@megatron.ietf.org; Tue, 27 Jul 2004 05:32: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 FAA00311 for ; Tue, 27 Jul 2004 05:31:58 -0400 (EDT) Received: from eins.siemens.at ([193.81.246.11]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BpOL4-0003sO-GC for dhcwg@ietf.org; Tue, 27 Jul 2004 05:33:38 -0400 Received: from vies1k7x.sie.siemens.at (forix [10.1.140.2]) by eins.siemens.at (8.12.9/8.12.8) with ESMTP id i6R9VREP028661 for ; Tue, 27 Jul 2004 11:31:27 +0200 Received: from vies141a.sie.siemens.at (vies1kbx.sie.siemens.at [158.226.135.174]) by vies1k7x.sie.siemens.at (8.12.10/8.12.1) with ESMTP id i6R9VQnW004787 for ; Tue, 27 Jul 2004 11:31:26 +0200 Received: by vies141a.sie.siemens.at with Internet Mail Service (5.5.2653.19) id ; Tue, 27 Jul 2004 11:33:07 +0200 Message-ID: <4D50D5110555D5119F270800062B41650532ABE4@viee10pa.erd.siemens.at> From: Grubmair Peter To: "DHCPV6_WG (E-mail)" Date: Tue, 27 Jul 2004 11:31:41 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Subject: [dhcwg] Stateless DHCPv6 and Elapsed time 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 RFC3315 (DHCPv6), chapter 2.9 says a clinet MUST include elapsed time option, whereas RFC3736(stateless DHCPv6) chapter 5.4 says a client may implement elapsed time option. Is it correct, if in a statelss DHCP client elapsed time option is not sent in Information request ? Best regards Peter _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Jul 28 13:13: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 NAA18018; Wed, 28 Jul 2004 13:13: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 1Bprpc-0005XR-6M; Wed, 28 Jul 2004 13: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 1Bprkl-0004Zq-AS for dhcwg@megatron.ietf.org; Wed, 28 Jul 2004 12:58: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 MAA15844 for ; Wed, 28 Jul 2004 12:58:04 -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 1Bprmb-0002GI-3V for dhcwg@ietf.org; Wed, 28 Jul 2004 13:00:02 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 28 Jul 2004 10:02:06 +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 i6SGvVCv026132; Wed, 28 Jul 2004 09:57:31 -0700 (PDT) Received: from volzw2k ([161.44.65.208]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AKL39775; Wed, 28 Jul 2004 12:57:29 -0400 (EDT) From: "Bernie Volz" To: "'Grubmair Peter'" , "'DHCPV6_WG \(E-mail\)'" Subject: RE: [dhcwg] Stateless DHCPv6 and Elapsed time option ? Date: Wed, 28 Jul 2004 12:57:28 -0400 Organization: Cisco Message-ID: <000001c474c3$f7f52760$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: <4D50D5110555D5119F270800062B41650532ABE4@viee10pa.erd.siemens.at> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4939.300 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca 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: You mean section 22.9 in RFC 3315. And, yes this does seem to be a contradiction. However, it is just a "may", not a MAY, in RFC 3736 = (section 5.4) whereas it is a MUST in RFC 3315 section 22.9. I also believe that = RFC 3315 overrides anything stated in RFC 3736, as 3736 is just trying to explain the stateless subset of 3315. As there is little harm in sending the option, send it. If you're implementing a server, don't discard a client request just because it doesn't include this option - the option is not that fundamental to = server operation (those fundamental requirements are given in Sectin 15 of = 3315).=20 In many ways, this option is likely not that important for stateless as there is very little work a server needs to perform, so it would usually always respond. One could envision stateful servers where one is a = "primary" and another is a "backup" and the backup might only respond if the = elapsed time has reached some threshold for messages in which there was no = server identifier option? - Bernie > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org]=20 > On Behalf Of Grubmair Peter > Sent: Tuesday, July 27, 2004 5:32 AM > To: DHCPV6_WG (E-mail) > Subject: [dhcwg] Stateless DHCPv6 and Elapsed time option ? >=20 >=20 > RFC3315 (DHCPv6), chapter 2.9 says > a clinet MUST include elapsed time option, > whereas RFC3736(stateless DHCPv6) chapter 5.4 > says a client may implement elapsed time option. > Is it correct, if in a statelss DHCP client > elapsed time option is not sent in Information request ? > Best regards > Peter=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 Fri Jul 30 10:02: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 KAA06567; Fri, 30 Jul 2004 10:02: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 1BqXki-0008AN-9o; Fri, 30 Jul 2004 09:48:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BqXjw-0007ac-EX for dhcwg@megatron.ietf.org; Fri, 30 Jul 2004 09: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 GAA28057 for ; Fri, 30 Jul 2004 06:23:58 -0400 (EDT) Received: from tokyo.netlab.nec.de ([195.37.70.2]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BqUaf-00058a-MI for dhcwg@ietf.org; Fri, 30 Jul 2004 06:26:19 -0400 Received: from venus.office (venus.office [10.1.1.11]) by tokyo.netlab.nec.de (Postfix) with ESMTP id 99ADF2C90D for ; Fri, 30 Jul 2004 12:23:27 +0200 (CEST) Received: from netlab.nec.de (neptune.office [10.1.1.83]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 1702B10612 for ; Fri, 30 Jul 2004 12:23:23 +0200 (CEST) Message-ID: <410A219B.30209@netlab.nec.de> Date: Fri, 30 Jul 2004 12:23:23 +0200 From: Cristian Cadar User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: dhcwg@ietf.org References: <40D2C202.3020003@isode.com> In-Reply-To: <40D2C202.3020003@isode.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7bit Subject: [dhcwg] Comments on draft-cadar-dhc-dhcpv6-opt-email-00.txt/draft-cadar-dhc-opt-imap-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 Hello, Since I am dealing with email configuration issues I found out that there is no DHCPv4 option for IMAP defined and no SMTP, IMAP and POP3 options for DHCPv6 available yet. In order to have them fixed I submitted two drafts to the IETF: ftp://ftp.ccrle.nec.de/pub/internet-drafts/draft-cadar-dhc-dhcpv6-opt-email-00.txt ftp://ftp.ccrle.nec.de/pub/internet-drafts/draft-cadar-dhc-opt-imap-00.txt May I ask you for your comments and possibly to put the drafts on the DHC working list? Thank you, Cristian _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri Jul 30 12:50: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 MAA18731; Fri, 30 Jul 2004 12:50: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 1BqaVL-0003AN-Ld; Fri, 30 Jul 2004 12:45:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BqaJe-00076H-FO for dhcwg@megatron.ietf.org; Fri, 30 Jul 2004 12:33: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 MAA17681 for ; Fri, 30 Jul 2004 12:33:02 -0400 (EDT) Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BqaLt-0002Jm-83 for dhcwg@ietf.org; Fri, 30 Jul 2004 12:35:26 -0400 Received: from [10.0.2.3] (neubayern.net [66.93.162.100]) by toccata.fugue.com (Postfix) with ESMTP id 8B0761B2010; Fri, 30 Jul 2004 11:32:53 -0500 (CDT) In-Reply-To: <410A219B.30209@netlab.nec.de> References: <40D2C202.3020003@isode.com> <410A219B.30209@netlab.nec.de> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <1BB48944-E246-11D8-9B9F-000A95D9C74C@fugue.com> Content-Transfer-Encoding: 7bit From: Ted Lemon Subject: Re: [dhcwg] Comments on draft-cadar-dhc-dhcpv6-opt-email-00.txt/draft-cadar-dhc-opt-imap-00.txt Date: Fri, 30 Jul 2004 09:32:54 -0700 To: Cristian Cadar X-Mailer: Apple Mail (2.618) 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 I guess my first question about this is why? Why would you want a client to trust the DHCP server to tell you what IMAP server to contact? What if you wind up talking to a rogue server, or roam to a different network? These don't seem like things that are location-dependent - they seem like things that you want to configure on the client and not change as the client moves around. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg