From dhcwg-bounces@ietf.org Mon Apr 02 02:39:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYGB5-0008Ft-DE; Mon, 02 Apr 2007 02:38:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYGB4-0008Fk-2u for dhcwg@ietf.org; Mon, 02 Apr 2007 02:38:06 -0400 Received: from zns001-0m9004.yokogawa.co.jp ([203.174.79.162]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYGB2-0003VW-Fs for dhcwg@ietf.org; Mon, 02 Apr 2007 02:38:06 -0400 Received: from zns001-0m9004.yokogawa.co.jp (localhost [127.0.0.1]) by zns001-0m9004.yokogawa.co.jp (8.12.10+Sun/8.12.10) with ESMTP id l326c373013043 for ; Mon, 2 Apr 2007 15:38:03 +0900 (JST) Received: from EXCHANGE03.jp.ykgw.net (zex001-0m9003.jp.ykgw.net [10.0.11.23]) by zns001-0m9004.yokogawa.co.jp (8.12.10+Sun/8.12.10) with ESMTP id l326c3AU013040 for ; Mon, 2 Apr 2007 15:38:03 +0900 (JST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 2 Apr 2007 15:38:03 +0900 Message-ID: <0260031F55435342859BFB2CCA6773D81B898A3D@EXCHANGE03.jp.ykgw.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Reminder] The Registration of the 9th TAHI IPv6 Interoperability Test Event has been opened Thread-Index: Acd08XaTy3WC1lgdRViADBIInEj7Mg== From: To: X-Spam-Score: 0.2 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Subject: [dhcwg] [Reminder] The Registration of the 9th TAHI IPv6 Interoperability Test Event has been opened X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org Hello all, This is a reminder for the 9th TAHI IPv6 Interoperability Test Event. TAHI Project is planning to hold the 9th TAHI IPv6 Interoperability Test Event at 14th - 18th May, 2007. You can make a registration on=20 http://www.tahi.org/inop/9thinterop.html And you can also get the detailed information about the event. We are looking forward see you at the 9th TAHI event! Thanks, ...Hideshi _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Apr 10 12:38:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbJMF-0004iF-3p; Tue, 10 Apr 2007 12:38:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbJME-0004iA-Ah for dhcwg@ietf.org; Tue, 10 Apr 2007 12:38:14 -0400 Received: from goliath.isc.org ([2001:4f8:3:bb::72]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbJMA-00085Z-T1 for dhcwg@ietf.org; Tue, 10 Apr 2007 12:38:14 -0400 Received: by goliath.isc.org (Postfix, from userid 10200) id C30825A6C9; Tue, 10 Apr 2007 09:37:43 -0700 (PDT) Date: Tue, 10 Apr 2007 09:37:43 -0700 From: "David W. Hankins" To: dhcwg@ietf.org Message-ID: <20070410163743.GC13084@isc.org> Mime-Version: 1.0 User-Agent: Mutt/1.5.9i X-Spam-Score: -2.3 (--) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Subject: [dhcwg] DHCPv4, 576 bytes, MMS option, blah blah blah. X-BeenThere: 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="===============1297132385==" Errors-To: dhcwg-bounces@ietf.org --===============1297132385== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="CdrF4e02JqNVZeln" Content-Disposition: inline --CdrF4e02JqNVZeln Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Every now and then, http://marc.info/?l=3Ddhcp-users&m=3D117580433414142&w=3D2 we see a client packet that is 604 bytes in length, but pads nearly all those bytes to zero. This isn't the only odd thing we see... The '576 byte minimum size' and 'maximum message size' should be very core, easy to understand tenets of basic DHCPv4 operation...but we keep seeing varying (and incompatible) interpretations. Is DHCPv4 going to need a 'bis' document to progress in its standards track? Can we revive Barr Hibbs' document? I think he got stuck on some issues on which the WG couldn't agree, and lack of review. If we defined a 'relay<->server' message size negotiation (a feature I think DHCPv4 lacks), could protocol clarifications for the client also 'tag along', or is that too weird? I suspect a clarifying document on its own would more or less go unnoticed. --=20 David W. Hankins "If you don't do it right the first time, Software Engineer you'll just have to do it again." Internet Systems Consortium, Inc. -- Jack T. Hankins --CdrF4e02JqNVZeln Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFGG71XcXeLeWu2vmoRAh5DAKC2F4+C0Gw4HA9M1qoGkG16S1cA9gCgiPZD b3B64kBUaH5YQSEoyDwv/kE= =j6/g -----END PGP SIGNATURE----- --CdrF4e02JqNVZeln-- --===============1297132385== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --===============1297132385==-- From dhcwg-bounces@ietf.org Wed Apr 11 03:44:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbXUM-00021U-Vh; Wed, 11 Apr 2007 03:43:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbXUL-00021H-RR for dhcwg@ietf.org; Wed, 11 Apr 2007 03:43:33 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbXUF-0003pr-Au for dhcwg@ietf.org; Wed, 11 Apr 2007 03:43:33 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 11 Apr 2007 03:43:26 -0400 X-IronPort-AV: i="4.14,393,1170651600"; d="scan'208"; a="57324364:sNHT47607912" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l3B7hOsv001218 for ; Wed, 11 Apr 2007 03:43:24 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l3B7hOGd027028 for ; Wed, 11 Apr 2007 07:43:24 GMT Received: from xmb-rtp-211.amer.cisco.com ([64.102.31.118]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Apr 2007 03:43:24 -0400 Received: from 10.86.242.136 ([10.86.242.136]) by xmb-rtp-211.amer.cisco.com ([64.102.31.118]) via Exchange Front-End Server email.cisco.com ([64.102.31.21]) with Microsoft Exchange Server HTTP-DAV ; Wed, 11 Apr 2007 07:43:24 +0000 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Wed, 11 Apr 2007 01:25:38 -0400 Subject: Re: [dhcwg] draft-droms-dhc-container-opt-00.txt From: Ralph Droms To: Thomas Herbst , Message-ID: Thread-Topic: [dhcwg] draft-droms-dhc-container-opt-00.txt Thread-Index: Acd7+daNFRHSaeftEduNngARJOT6eg== In-Reply-To: <7.0.1.0.2.20070328164713.037a3548@cisco.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 11 Apr 2007 07:43:24.0506 (UTC) FILETIME=[15C5EBA0:01C77C0D] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2176; t=1176277404; x=1177141404; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rdroms@cisco.com; z=From:=20Ralph=20Droms=20 |Subject:=20Re=3A=20[dhcwg]=20draft-droms-dhc-container-opt-00.txt |Sender:=20 |To:=20Thomas=20Herbst=20,=20; bh=10X19e8uDpxxS3kUlV+ou7wQoehUv8HA/mGJsdgVrC4=; b=FoeKAR5JoIAjcQwxkdw1luWhnsqf+zrImTK/bPu8pdKd/4yY4QZPD7368MI2QyXoTAsV07oA 3mH3bxLsLm0F4Q0cJmPFJT9bSP+Q/3VijjpMB7grEFdIyMAQrUcVnfaF; Authentication-Results: rtp-dkim-1; header.From=rdroms@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 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: , Errors-To: dhcwg-bounces@ietf.org Tom - I understand your concern. I think there is at least one mechanism already in place to mitigate the problem. The CPE includes the Parameter Request List option (55) in its DHCPDISCOVER and DHCPREQUEST messages. The RG server includes only those options requested by the CPE in its DHCPOFFER and DHCPACK messages. While this behavior is defined in RFC 2131 and RFC 2132, it should probably be made explicit in the container option spec. There is another issue regarding the policy of overriding option values from the container option with option values configured directly in the RG DHCP server. The container option spec should likely be extended with text to the effect of "The DHCP server in the RG MAY use locally configured option values instead of option values received in the container option" - Ralph On 3/28/07 7:57 PM, "Thomas Herbst" wrote: > I've been thinking about this draft since the WG meeting > last week and time has not made it smell any better. > > The principal purported benefit of the proposal is it's > major problem - the unlimited extensibility enables the > SP to pass any DHCP option to the clients with the RG > not having any visibility to apply policy. > > In the case that the RG is provided as part of a SP service, > it can be rationally argued that the SP can inflict > any parameters they choose on their customer. In the case > where the RG is consumer owned, they should get the opportunity > to apply policy to the parameters the SP is attempting to foist > upon them. Should the SP have a list of specific parameters > they would like to be passed to set top boxes or other devices > behind the RG, they can provide that list to the RG vendor > for propagation. Not planning the parameters needed for your > service is not an excuse to have a standards codified, protocol > based blank check for the future. > > This is not a "policy detail", this is the whole issue with the > container approach. > > tom > > _______________________________________________ > 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 Apr 11 17:22:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbkGb-0001sI-Nc; Wed, 11 Apr 2007 17:22:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbkGZ-0001sA-I3 for dhcwg@ietf.org; Wed, 11 Apr 2007 17:22:11 -0400 Received: from ug-out-1314.google.com ([66.249.92.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbkGV-0006r6-8L for dhcwg@ietf.org; Wed, 11 Apr 2007 17:22:11 -0400 Received: by ug-out-1314.google.com with SMTP id 72so180309ugd for ; Wed, 11 Apr 2007 14:22:06 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:disposition-notification-to:date:from:user-agent:mime-version:to:subject:x-enigmail-version:content-type:content-transfer-encoding; b=RauMX316LAS/z/s3IeuSSpcMqvi1WEsf67eoSvnu1sXDRdkleMfGN06Rx4iMS/d1mf5OHOuP3pjskngqIrJY+kpFKYOvilhI86U9pd2VQM2qgB+jA3zvkCEO1SdprztU7uabgklqnySjO6UKDSRdsuieNF7BQn7lBHlTb33Pd/U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:disposition-notification-to:date:from:user-agent:mime-version:to:subject:x-enigmail-version:content-type:content-transfer-encoding; b=i/Xrcw4gLnRypqJG6fya9smjjSh0iIPzWHzzFjmaFn+51HQR0vTbMw/07AdSAWiV2g9ofdFDWN1gXc/VRlJrgAbGHTUirLzDo3o6DO6MbK6lix2UytJpHvPM4sWTRjfN58CwAF0myDMNC53/MZwqZXusi+wQqDvJLW4/NRbzp+U= Received: by 10.67.24.13 with SMTP id b13mr705037ugj.1176326526227; Wed, 11 Apr 2007 14:22:06 -0700 (PDT) Received: from ?192.168.1.100? ( [81.82.67.113]) by mx.google.com with ESMTP id 28sm1984346ugc.2007.04.11.14.22.04; Wed, 11 Apr 2007 14:22:04 -0700 (PDT) Message-ID: <461D517B.7090004@gmail.com> Date: Wed, 11 Apr 2007 23:22:03 +0200 From: Bert Verhaeghe User-Agent: Thunderbird 1.5.0.10 (X11/20070306) MIME-Version: 1.0 To: dhcwg@ietf.org X-Enigmail-Version: 0.94.3.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Subject: [dhcwg] dhcp network problem X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi all, I have the follwing problem. For a company a DHCP server is residing in the network of the headquarter. This server should give IP addresses to clients on the network of the headquarter as well as to clients on the networks of the branch offices. Clients in the branch offices their DHCP broadcast requests, are relayed through CISCO swithes to the headquarter network with the help of IP Helper. Now this is where the problem arises. How can be determined which IP address should be given to a client? For instance the following network topology : headquarter 10.10.11.0/24 branch office °1 10.10.12.0/24 branch office °2 10.10.13.0/25 When a representative is in the network of the headquarter most of the time, a fixed lease could be given based on the MAC of his laptop so that the laptop receives an IP in the 10.10.11.0 network is given. But what if the representative often travels around between the different offices? How can be determined which network the representative's laptop resides in? If the representative resides in the second branch office, the laptop should receive an IP in the 10.10.13.0 network, but how can this be realized? And is this possible with the ISC dhcp server? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFGHVF6I3J78Ly/XgYRAqXWAJ46ZOLNuw/2jYOm5ofgLU0t7Ej24wCfZg+3 UgafQkWGt+I+O1tDaMiBxXk= =HknV -----END PGP SIGNATURE----- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Apr 11 23:49:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbqJd-0007Ad-Hw; Wed, 11 Apr 2007 23:49:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbqJc-0007AW-DF for dhcwg@ietf.org; Wed, 11 Apr 2007 23:49:44 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbqJc-0006ya-3W for dhcwg@ietf.org; Wed, 11 Apr 2007 23:49:44 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 11 Apr 2007 23:49:44 -0400 X-IronPort-AV: i="4.14,399,1170651600"; d="scan'208"; a="118296812:sNHT58725192" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l3C3nhAB006046; Wed, 11 Apr 2007 23:49:43 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l3C3ndlG020178; Thu, 12 Apr 2007 03:49:43 GMT Received: from xmb-rtp-20a.amer.cisco.com ([64.102.31.15]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Apr 2007 23:49:39 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [dhcwg] dhcp network problem Date: Wed, 11 Apr 2007 23:49:37 -0400 Message-ID: <8E296595B6471A4689555D5D725EBB2103C527AD@xmb-rtp-20a.amer.cisco.com> In-Reply-To: <461D517B.7090004@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dhcwg] dhcp network problem Thread-Index: Acd8f9A7vIF1Ta7JTYqO8is9Q/FMEgANYbIw From: "Bernie Volz \(volz\)" To: "Bert Verhaeghe" , X-OriginalArrivalTime: 12 Apr 2007 03:49:39.0381 (UTC) FILETIME=[988F6E50:01C77CB5] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2335; t=1176349783; x=1177213783; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=volz@cisco.com; z=From:=20=22Bernie=20Volz=20\(volz\)=22=20 |Subject:=20RE=3A=20[dhcwg]=20dhcp=20network=20problem |Sender:=20 |To:=20=22Bert=20Verhaeghe=22=20, =20; bh=a3x9YQtatkeQ3OUMqwikdQrkcpQkv8ncsv21obWhikI=; b=o1stV1OJw6WTTMjoefjEWDm6Msr4xtnMOKBJT61BgR8LPwWnBJ0XEBjRmWp7rmOF6LHQhIBa PrBBLUw6nZspKaB+1N4FXSGMp3Rfdh8PNNP3+Xz5+G0FQdN9O2ePZOgU; Authentication-Results: rtp-dkim-1; header.From=volz@cisco.com; dkim=pass (s ig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe 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: , Errors-To: dhcwg-bounces@ietf.org This is usually handled without issue as "relayed through CISCO swithes = to the headquarter network with the help of IP Helper." means that the giaddr should be set accordingly and the = DHCP server should thus know where the clients are. For example, the switch should set giaddr to a 10.10.12.0/24 address = when clients connected to that network broadcast DHCP requests. You should contact your DHCP server software vendor for additional help. - Bernie -----Original Message----- From: Bert Verhaeghe [mailto:bert.verhaeghe@gmail.com]=20 Sent: Wednesday, April 11, 2007 5:22 PM To: dhcwg@ietf.org Subject: [dhcwg] dhcp network problem -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi all, I have the follwing problem. For a company a DHCP server is residing in the network of the headquarter. This server should give IP addresses to clients on the network of the headquarter as well as to clients on the networks of the branch offices. Clients in the branch offices their DHCP broadcast requests, are relayed through CISCO swithes to the headquarter network with the help of IP Helper. Now this is where the problem arises. How can be determined which IP address should be given to a client? For instance the following network topology : headquarter 10.10.11.0/24 branch office =B01 10.10.12.0/24 branch office =B02 10.10.13.0/25 When a representative is in the network of the headquarter most of the time, a fixed lease could be given based on the MAC of his laptop so that the laptop receives an IP in the 10.10.11.0 network is given. But what if the representative often travels around between the different offices? How can be determined which network the representative's laptop resides in? If the representative resides in the second branch office, the laptop should receive an IP in the 10.10.13.0 network, but how can this be realized? And is this possible with the ISC dhcp server? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFGHVF6I3J78Ly/XgYRAqXWAJ46ZOLNuw/2jYOm5ofgLU0t7Ej24wCfZg+3 UgafQkWGt+I+O1tDaMiBxXk=3D =3DHknV -----END PGP SIGNATURE----- _______________________________________________ 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 Apr 12 04:38:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hbuos-00029z-NU; Thu, 12 Apr 2007 04:38:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hbuor-000265-85 for dhcwg@ietf.org; Thu, 12 Apr 2007 04:38:17 -0400 Received: from ug-out-1314.google.com ([66.249.92.169]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hbuoo-0005Uu-N8 for dhcwg@ietf.org; Thu, 12 Apr 2007 04:38:17 -0400 Received: by ug-out-1314.google.com with SMTP id 72so241744ugd for ; Thu, 12 Apr 2007 01:38:14 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:subject:x-priority:x-enigmail-version:content-type:content-transfer-encoding; b=WyOgttmGjRS3GldXS9Ww5FJxs/0hD314Qdmz4g6wjRLw3+qnbh2wN6udZ16jcB+aXTkeZps/OJqT/7VmrXm79sSFtgGt4gBaaW8ibX0yxd3IJjbIlr2Cud+MQ/UXmplKPRlNDJwDEMrqAHNyl9GuUvBmMe7wUWQBcJoD855dQtA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:subject:x-priority:x-enigmail-version:content-type:content-transfer-encoding; b=hS6Zdcjd5QjaGYVfQYXImnN50n2qLGetNRK8yyF3M117tE86hhgDsBGCq2Kx41b/QmHUYfqx382EWDSzFaenOkKHEieBnXbdsrvnuGJ5sW4sVXzKaFdVtF2agdrgy6PVcY7TOON2XCqFW1JXxhjAofcLDV6eMX+rISkOYgIF24I= Received: by 10.67.22.14 with SMTP id z14mr1070535ugi.1176367093977; Thu, 12 Apr 2007 01:38:13 -0700 (PDT) Received: from ?10.1.31.197? ( [81.244.244.138]) by mx.google.com with ESMTP id c25sm954865ika.2007.04.12.01.38.11; Thu, 12 Apr 2007 01:38:12 -0700 (PDT) Message-ID: <461DFE01.6080904@gmail.com> Date: Thu, 12 Apr 2007 11:38:09 +0200 From: Bert Verhaeghe User-Agent: Thunderbird 1.5.0.10 (X11/20070306) MIME-Version: 1.0 To: dhcwg@ietf.org X-Priority: 2 (High) X-Enigmail-Version: 0.94.3.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Subject: [dhcwg] dhcp fixed lease problem X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi all, is it possible to define a fixed lease for the same MAC in multiple subnets? I included a sample configuration file and a scenario below, but when testing (dhcpd3 -t) I get the following error : > bert@laptop11:~$ sudo /usr/sbin/dhcpd3 -t Internet Systems > Consortium DHCP Server V3.0.4 Copyright 2004-2006 Internet Systems > Consortium. All rights reserved. For info, please visit > http://www.isc.org/sw/dhcp/ /etc/dhcp3/dhcpd.conf line 148: host > laptop01: already exists } ^ /etc/dhcp3/dhcpd.conf line 158: host > laptop02: already exists } ^ Configuration file errors encountered > -- exiting Scenario : When the person owning laptop is in the NY network, the IP 10.10.1.102 should be assigned, but when he's in the LA network he should get the 10.10.2.101 IP. Can this be accomplished using the ISC DHCP v3 server? Thanks in advance, Bert Verhaeghe Sample configuration file : ddns-update-style none; option domain-name "example.org"; option domain-name-servers ns1.example.org, ns2.example.org; default-lease-time 600; max-lease-time 7200; authoritative; shared-network example { # example NY network subnet 10.10.1.0 netmask 255.255.255.0 { option routers ny.example.org; host fixedHost01 { hardware ethernet 00:00:00:00:00:01; fixed-address 10.10.1.101; } host laptop01 { hardware ethernet 00:00:00:00:00:02; fixed-address 10.10.1.102; } host laptop02 { hardware ethernet 00:00:00:00:00:03; fixed-address 10.10.1.103; } } # example LA network subnet 10.10.2.0 netmask 255.255.255.0 { option routers la.example.org; host laptop01 { hardware ethernet 00:00:00:00:00:02; fixed-address 10.10.2.101; } } } -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFGHf4BI3J78Ly/XgYRAjWUAJ47G5PRhbiF8kzrYUR9+ZWKiX2aXACgpCZx cAmle+DHjEIdBGmaixh//Bw= =CKWD -----END PGP SIGNATURE----- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Thu Apr 12 09:29:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbzMt-0005Ot-Ay; Thu, 12 Apr 2007 09:29:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbzMs-0005Ok-9c for dhcwg@ietf.org; Thu, 12 Apr 2007 09:29:42 -0400 Received: from h216-18-16-189.gtcust.grouptelecom.net ([216.18.16.189] helo=zeus.incognito.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbzMr-0000N9-1I for dhcwg@ietf.org; Thu, 12 Apr 2007 09:29:42 -0400 Content-class: urn:content-classes:message Subject: RE: [dhcwg] dhcp fixed lease problem MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Thu, 12 Apr 2007 06:29:39 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: <403B5316AD7A254C9024875BAE481D4E80FA73@zeus.incognito.com> In-Reply-To: <461DFE01.6080904@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dhcwg] dhcp fixed lease problem Thread-Index: Acd83fgcdNx+74OOSvONz3UHfMlWVwAJ/JyQ References: <461DFE01.6080904@gmail.com> From: "Andre Kostur" To: "Bert Verhaeghe" , X-Spam-Score: 0.1 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 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: , Errors-To: dhcwg-bounces@ietf.org > -----Original Message----- > From: Bert Verhaeghe [mailto:bert.verhaeghe@gmail.com]=20 > Sent: Thursday, April 12, 2007 2:38 AM > To: dhcwg@ietf.org > Subject: [dhcwg] dhcp fixed lease problem > > is it possible to define a fixed lease for the same MAC in=20 > multiple subnets? I included a sample configuration file and=20 > a scenario below, but when testing (dhcpd3 -t) I get the=20 > following error : Bert, you're asking about how to configure a specific implementation of DHCP. The dhcpwg mailing list is for discussing how the DHCP protocol (both v4 and v6) itself works. Not how to configure a specific implementation. For that, you need to contact your vendor. >From a protocol perspective, there's nothing prohibiting a particular implementation from allowing this behaviour. I know that our (Incognito's) DHCP server will allow you to do this. I'd be surprised if the other vendors didn't allow it. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Thu Apr 12 17:38:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hc70J-0002lX-NL; Thu, 12 Apr 2007 17:38:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hc70I-0002lS-Tn for dhcwg@ietf.org; Thu, 12 Apr 2007 17:38:54 -0400 Received: from goliath.isc.org ([2001:4f8:3:bb::72]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hc70H-000216-CI for dhcwg@ietf.org; Thu, 12 Apr 2007 17:38:54 -0400 Received: by goliath.isc.org (Postfix, from userid 10200) id 91A575A6CA; Thu, 12 Apr 2007 14:38:39 -0700 (PDT) Date: Thu, 12 Apr 2007 14:38:39 -0700 From: "David W. Hankins" To: Bert Verhaeghe Subject: Re: [dhcwg] dhcp fixed lease problem Message-ID: <20070412213839.GE18633@isc.org> References: <461DFE01.6080904@gmail.com> Mime-Version: 1.0 In-Reply-To: <461DFE01.6080904@gmail.com> User-Agent: Mutt/1.5.9i X-Spam-Score: -2.8 (--) 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: , Content-Type: multipart/mixed; boundary="===============0679722097==" Errors-To: dhcwg-bounces@ietf.org --===============0679722097== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="UHN/qo2QbUvPLonB" Content-Disposition: inline --UHN/qo2QbUvPLonB Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Apr 12, 2007 at 11:38:09AM +0200, Bert Verhaeghe wrote: > is it possible to define a fixed lease for the same MAC in multiple > subnets? I included a sample configuration file and a scenario below, > but when testing (dhcpd3 -t) I get the following error : Bert, this looks like ISC DHCP 3.x config syntax and questions. That's not an appropriate topic for the IETF DHC WG mailing list. This question is appropriate for dhcp-users@isc.org, you can subscribe here: http://www.isc.org/sw/dhcp/dhcp-lists.php But so long as I'm transmitting, the answer to your question is in 'man dhcpd.conf', The fixed=E2=80=90address declaration fixed=E2=80=90address address [, address ... ]; The fixed=E2=80=90address declaration is used to assign one or more f= ixed IP addresses to a client. It should only appear in a host declaration. If more than one address is supplied, then when the client boots, it will be assigned the address that corresponds to the network on which it is booting. If none of the addresses in the fixed=E2=80=90= address statement are valid for the network to which the client is con= =E2=80=90 nected, that client will not match the host declaration containing that fixed=E2=80=90address declaration. Each address in the fixed= =E2=80=90address declaration should be either an IP address or a domain name that resolves to one or more IP addresses. If you're still confused, ask on dhcp-users to help us improve that documentation. --=20 David W. Hankins "If you don't do it right the first time, Software Engineer you'll just have to do it again." Internet Systems Consortium, Inc. -- Jack T. Hankins --UHN/qo2QbUvPLonB Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFGHqbfcXeLeWu2vmoRAt3JAKCopOqVMCgSaW9nVxWLIWTIZtxlNQCfYLnB UWDWKwafPJBavz1pcYUL4e8= =P3R8 -----END PGP SIGNATURE----- --UHN/qo2QbUvPLonB-- --===============0679722097== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --===============0679722097==-- From dhcwg-bounces@ietf.org Sun Apr 15 20:30:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdF6u-0007Ms-Iv; Sun, 15 Apr 2007 20:30:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdF6t-0007Mm-Sj for dhcwg@ietf.org; Sun, 15 Apr 2007 20:30:23 -0400 Received: from zns001-0m9001.yokogawa.co.jp ([203.174.79.138]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdF6r-0006DY-Aw for dhcwg@ietf.org; Sun, 15 Apr 2007 20:30:23 -0400 Received: from zns001-0m9001.yokogawa.co.jp (localhost [127.0.0.1]) by zns001-0m9001.yokogawa.co.jp (8.12.10+Sun/8.12.10) with ESMTP id l3G0UKgs001927 for ; Mon, 16 Apr 2007 09:30:20 +0900 (JST) Received: from EXCHANGE03.jp.ykgw.net (zex001-0m9003.jp.ykgw.net [10.0.11.23]) by zns001-0m9001.yokogawa.co.jp (8.12.10+Sun/8.12.10) with ESMTP id l3G0UJtS001921 for ; Mon, 16 Apr 2007 09:30:19 +0900 (JST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 16 Apr 2007 09:30:14 +0900 Message-ID: <0260031F55435342859BFB2CCA6773D81B898A7E@EXCHANGE03.jp.ykgw.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Reminder] The 9th TAHI IPv6 Interoperability Test Event !! Thread-Index: Acd/vmTaaQmK4YFLRdWlEZr3G4CTWw== From: To: X-Spam-Score: 0.2 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Subject: [dhcwg] [Reminder] The 9th TAHI IPv6 Interoperability Test Event !! X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org Dear all, This is a reminder for the 9th TAHI IPv6 Interoperability Test Event. As you know, TAHI Project is planning to hold the 9th TAHI IPv6 Interoperability Test Event at 14th - 18th May, 2007. You can make a registration on=20 http://www.tahi.org/inop/9thinterop.html And you can also get the detailed information about the event. The registration deadline is at 17:00 on Friday, 27th Apr. Please make a registration as soon as possible, if you are planning to participate to the event. We are looking forward to see you at the 9th TAHI event! Thanks, _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Sun Apr 15 20:53:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdFTZ-0007AR-Ri; Sun, 15 Apr 2007 20:53:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdFTY-00077L-Fw for dhcwg@ietf.org; Sun, 15 Apr 2007 20:53:48 -0400 Received: from zns001-0m9002.yokogawa.co.jp ([203.174.79.139]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdFTW-00031z-Rq for dhcwg@ietf.org; Sun, 15 Apr 2007 20:53:48 -0400 Received: from zns001-0m9002.yokogawa.co.jp (localhost [127.0.0.1]) by zns001-0m9002.yokogawa.co.jp (8.12.10+Sun/8.12.10) with ESMTP id l3G0rjve023780 for ; Mon, 16 Apr 2007 09:53:45 +0900 (JST) Received: from EXCHANGE03.jp.ykgw.net (zex001-0m9003.jp.ykgw.net [10.0.11.23]) by zns001-0m9002.yokogawa.co.jp (8.12.10+Sun/8.12.10) with ESMTP id l3G0rjPm023777 for ; Mon, 16 Apr 2007 09:53:45 +0900 (JST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [dhcwg] [Reminder] The 9th TAHI IPv6 Interoperability Test Event !! Date: Mon, 16 Apr 2007 09:53:45 +0900 Message-ID: <0260031F55435342859BFB2CCA6773D81B898A85@EXCHANGE03.jp.ykgw.net> In-Reply-To: <0260031F55435342859BFB2CCA6773D81B898A7E@EXCHANGE03.jp.ykgw.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dhcwg] [Reminder] The 9th TAHI IPv6 Interoperability Test Event !! Thread-Index: Acd/vmTaaQmK4YFLRdWlEZr3G4CTWwAAz7PQ From: To: X-Spam-Score: 0.2 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org Dear all, I forgot to tell you the important thing. The Early registration discount will be closed today!! at 17:00 JST 16th Apr. Thanks, > -----Original Message----- > From: Enokihara, Hideshi (Hideshi.Enokihara@jp.yokogawa.com)=20 > Sent: Monday, April 16, 2007 9:30 AM > To: dhcwg@ietf.org > Subject: [dhcwg] [Reminder] The 9th TAHI IPv6=20 > Interoperability Test Event !! >=20 > Dear all, >=20 > This is a reminder for the 9th TAHI IPv6 Interoperability Test Event. >=20 > As you know, TAHI Project is planning to hold the 9th TAHI=20 > IPv6 Interoperability Test Event at 14th - 18th May, 2007. > You can make a registration on=20 > http://www.tahi.org/inop/9thinterop.html >=20 > And you can also get the detailed information about the event. >=20 > The registration deadline is at 17:00 on Friday, 27th Apr. > Please make a registration as soon as possible, if you are=20 > planning to participate to the event. >=20 > We are looking forward to see you at the 9th TAHI event! >=20 > Thanks, >=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 Mon Apr 16 14:32:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdW0F-0008Fh-RQ; Mon, 16 Apr 2007 14:32:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdW0D-0008DG-Cf; Mon, 16 Apr 2007 14:32:37 -0400 Received: from nit.isi.edu ([128.9.160.116]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdW0C-0004ea-0m; Mon, 16 Apr 2007 14:32:37 -0400 Received: from nit.isi.edu (loopback [127.0.0.1]) by nit.isi.edu (8.12.11.20060308/8.12.11) with ESMTP id l3GIWZRb025381; Mon, 16 Apr 2007 11:32:35 -0700 Received: (from apache@localhost) by nit.isi.edu (8.12.11.20060308/8.12.11/Submit) id l3GIWZ4g025380; Mon, 16 Apr 2007 11:32:35 -0700 Date: Mon, 16 Apr 2007 11:32:35 -0700 Message-Id: <200704161832.l3GIWZ4g025380@nit.isi.edu> To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org X-Spam-Score: -14.8 (--------------) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: dhcwg@ietf.org, rfc-editor@rfc-editor.org Subject: [dhcwg] RFC 4833 on Timezone Options for 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: , Errors-To: dhcwg-bounces@ietf.org A new Request for Comments is now available in online RFC libraries. RFC 4833 Title: Timezone Options for DHCP Author: E. Lear, P. Eggert Status: Standards Track Date: April 2007 Mailbox: lear@cisco.com, eggert@cs.ucla.edu Pages: 10 Characters: 19573 Updates: RFC2132 See-Also: I-D Tag: draft-ietf-dhc-timezone-option-05.txt URL: http://www.rfc-editor.org/rfc/rfc4833.txt Two common ways to communicate timezone information are POSIX 1003.1 timezone strings and timezone database names. This memo specifies DHCP options for each of those methods. The DHCPv4 time offset option is deprecated. [STANDARDS TRACK] This document is a product of the Dynamic Host Configuration Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements.Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. The RFC Editor Team USC/Information Sciences Institute ... _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Apr 17 15:50:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdthE-0002R5-9d; Tue, 17 Apr 2007 15:50:36 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdthB-0002OV-2t; Tue, 17 Apr 2007 15:50:33 -0400 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HdthA-0004By-P5; Tue, 17 Apr 2007 15:50:33 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id A7D142ACD7; Tue, 17 Apr 2007 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Hdtgg-0001LY-D5; Tue, 17 Apr 2007 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 17 Apr 2007 15:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: dhcwg@ietf.org Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-vpn-option-06.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: , 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 : Virtual Subnet Selection Option Author(s) : R. Johnson, et al. Filename : draft-ietf-dhc-vpn-option-06.txt Pages : 12 Date : 2007-4-17 This memo defines a new DHCP option for passing Virtual Subnet Selection (VSS) information between the DHCP client and the DHCP server. It is intended for use primarily by DHCP proxy clients in situations where VSS information needs to be passed to the DHCP server for proper address allocation to take place. The option number currently in use is TBD. This memo documents the current usage of the option in agreement with [7], which declares that any pre-existing usages of option numbers in the range 128 - 223 should be documented and the working group will try to officially assign those numbers to those options. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-vpn-option-06.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-vpn-option-06.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-vpn-option-06.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: <2007-4-17125622.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-vpn-option-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-vpn-option-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-4-17125622.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --NextPart-- From dhcwg-bounces@ietf.org Tue Apr 17 20:29:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hdy2y-0000RD-GW; Tue, 17 Apr 2007 20:29:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hdy2x-0000R5-En for dhcwg@ietf.org; Tue, 17 Apr 2007 20:29:19 -0400 Received: from ns.64translator.com ([202.214.123.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hdy2v-00059w-UA for dhcwg@ietf.org; Tue, 17 Apr 2007 20:29:19 -0400 Received: from bahamas.64translator.com (bahamas.64translator.com [10.21.32.3]) by ns.64translator.com (8.13.6/8.13.6) with ESMTP id l3HFHjrs058351 for ; Wed, 18 Apr 2007 00:17:50 +0900 (JST) (envelope-from Hideshi.Enokihara@jp.yokogawa.com) Received: from thinkpad.64translator.com (dhcp225.64translator.com [10.21.32.225]) by bahamas.64translator.com (8.13.1/8.13.1) with SMTP id l3I0RnjX034090 for ; Wed, 18 Apr 2007 09:27:49 +0900 (JST) (envelope-from Hideshi.Enokihara@jp.yokogawa.com) Date: Wed, 18 Apr 2007 09:27:17 +0900 From: Hideshi Enokihara To: dhcwg@ietf.org Message-Id: <20070418092717.0347b870.Hideshi.Enokihara@jp.yokogawa.com> Organization: Yokogawa Electric Corporation X-Mailer: Sylpheed version 2.0.0 (GTK+ 2.6.9; i386-portbld-freebsd6.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.8 required=5.0 tests=ALL_TRUSTED autolearn=failed version=3.0.1 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on bahamas.64translator.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Subject: [dhcwg] [9th TAHI Test Event] Registration System Failure X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org All, We would like to apologize for an error in the online registration system yesterday that resulted in registration being unable to be completed for the period of 17:15 - 20:22 JST. The error took place in the process of changing the registration rates from the early registration rates to the standard rates after yesterday's deadline. We apologize for the inconvenience caused and would ask that anyone who was unable to register during this time period to contact us. We will then asist you in processing your registration at the advance rates. Sincerely, 9th TAHI Registration Desk c/o Maki Ikegami, e-side, inc. email: 9thregister@tahi.org Fax: 81-3-3585-8162 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Apr 18 18:50:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeIyT-0000FA-Hd; Wed, 18 Apr 2007 18:50:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeIyQ-0000Ef-T2; Wed, 18 Apr 2007 18:50:02 -0400 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeIyQ-0006VI-K3; Wed, 18 Apr 2007 18:50:02 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 82A01329D9; Wed, 18 Apr 2007 22:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HeIyQ-00038j-DU; Wed, 18 Apr 2007 18:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 18 Apr 2007 18:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: dhcwg@ietf.org Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-pxelinux-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: , 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 : PXELINUX Use of 'Site Local' Option Space Author(s) : D. Hankins Filename : draft-ietf-dhc-pxelinux-01.txt Pages : 13 Date : 2007-4-18 This document is in response to RFC3942 [4], and describes the use by PXELINUX of some DHCP Option Codes [1] numbering from 208-211. These codes were designated 'Site Local' [2] prior to this action, and are redefined by RFC3942 as available for allocation as standard DHCP Options. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-pxelinux-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-pxelinux-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-pxelinux-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: <2007-4-18155959.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-pxelinux-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-pxelinux-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-4-18155959.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --NextPart-- From dhcwg-bounces@ietf.org Wed Apr 18 19:13:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeJLF-0007YE-L4; Wed, 18 Apr 2007 19:13:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeJLE-0007Y9-1a for dhcwg@ietf.org; Wed, 18 Apr 2007 19:13:36 -0400 Received: from goliath.isc.org ([2001:4f8:3:bb::72]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeJLD-0000VV-G0 for dhcwg@ietf.org; Wed, 18 Apr 2007 19:13:35 -0400 Received: by goliath.isc.org (Postfix, from userid 10200) id 306317D2D; Wed, 18 Apr 2007 16:13:21 -0700 (PDT) Date: Wed, 18 Apr 2007 16:13:21 -0700 From: "David W. Hankins" To: dhcwg@ietf.org Subject: Re: [dhcwg] I-D ACTION:draft-ietf-dhc-pxelinux-01.txt Message-ID: <20070418231320.GK12255@isc.org> References: Mime-Version: 1.0 In-Reply-To: User-Agent: Mutt/1.5.9i X-Spam-Score: -2.8 (--) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 X-BeenThere: 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="===============1346093271==" Errors-To: dhcwg-bounces@ietf.org --===============1346093271== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="vJguvTgX93MxBIIe" Content-Disposition: inline --vJguvTgX93MxBIIe Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Apr 18, 2007 at 06:50:02PM -0400, Internet-Drafts@ietf.org wrote: > Filename : draft-ietf-dhc-pxelinux-01.txt In this revision, A) Move to Informational status (as per discussion closing last attempt at last-call). B) Some nits; renamed "PXELINUX in a Nutshell" section to "Introduction", separated Normative and Informative references. These are both cosmetic. Since there are no major changes, I expect to ask for a last call after a week or so. Sorry this practical no-op is a year in coming. I've been busy. --=20 David W. Hankins "If you don't do it right the first time, Software Engineer you'll just have to do it again." Internet Systems Consortium, Inc. -- Jack T. Hankins --vJguvTgX93MxBIIe Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFGJqYQcXeLeWu2vmoRAoEpAJ9BltvUaLovFdFCvTErDdS9WYGOKwCdGxMi vwsS2yuDMA2Oxr2sauqP3Fk= =S63v -----END PGP SIGNATURE----- --vJguvTgX93MxBIIe-- --===============1346093271== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --===============1346093271==-- From dhcwg-bounces@ietf.org Thu Apr 19 10:03:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeXE9-0002AD-41; Thu, 19 Apr 2007 10:03:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeXE7-00029v-MM for dhcwg@ietf.org; Thu, 19 Apr 2007 10:03:11 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeXE6-0006FF-DB for dhcwg@ietf.org; Thu, 19 Apr 2007 10:03:11 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 19 Apr 2007 10:03:11 -0400 X-IronPort-AV: i="4.14,427,1170651600"; d="scan'208"; a="118945475:sNHT42529428" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l3JE3Avs023225 for ; Thu, 19 Apr 2007 10:03:10 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l3JE39Gf027754 for ; Thu, 19 Apr 2007 14:03:10 GMT Received: from xmb-rtp-20a.amer.cisco.com ([64.102.31.15]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Apr 2007 10:02:57 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 19 Apr 2007 10:02:57 -0400 Message-ID: <8E296595B6471A4689555D5D725EBB2103D9C937@xmb-rtp-20a.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RFC 3942 Status Report - new draft draft-volz-dhc-3942-status-00.txt Thread-Index: AceCi28EQriRw6GJRoqvSGJ2ItAvpw== From: "Bernie Volz \(volz\)" To: X-OriginalArrivalTime: 19 Apr 2007 14:02:57.0695 (UTC) FILETIME=[6EF4CAF0:01C7828B] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=529; t=1176991390; x=1177855390; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=volz@cisco.com; z=From:=20=22Bernie=20Volz=20\(volz\)=22=20 |Subject:=20RFC=203942=20Status=20Report=20-=20new=20draft=20draft-volz-d hc-3942-status-00.txt |Sender:=20 |To:=20; bh=IH3ZrOG9L0HchJRsxDf8StYSF3KW38BVmSHslSCDFC4=; b=row4cXz43pLAQDj8NhLopT3qKbWyHFIA4a1gBAt4MdMZiEwZW8FwVTDPT7j53qg99RuL93+M tM9cDZAmtvOqOwT0+NWDUkeTBHbS91QOvvtx4YMs6C7DuEviVegi+eK6; Authentication-Results: rtp-dkim-1; header.From=volz@cisco.com; dkim=pass (s ig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Subject: [dhcwg] RFC 3942 Status Report - new draft draft-volz-dhc-3942-status-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: , Errors-To: dhcwg-bounces@ietf.org Folks: I have just submitted draft-volz-dhc-3942-status-00.txt for publication (available at ftp://ftp-eng.cisco.com/volz/draft-volz-dhc-3942-status-00.txt until published by the IETF). This draft documents the current status of and recommendations for the RFC 3942 (Reclassifying DHCPv4 Options) work based on the presentation I gave at the Prague DHC WG meeting (see http://www3.ietf.org/proceedings/07mar/slides/dhc-5.pdf).=20 This document was requested by the DHC WG chairs at the Prague meeting. - Bernie _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri Apr 20 11:35:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hev9C-00017e-Q9; Fri, 20 Apr 2007 11:35:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hev9C-00017Z-7T for dhcwg@ietf.org; Fri, 20 Apr 2007 11:35:42 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hev9B-0001ba-Jp for dhcwg@ietf.org; Fri, 20 Apr 2007 11:35:42 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 20 Apr 2007 11:35:41 -0400 X-IronPort-AV: i="4.14,433,1170651600"; d="scan'208"; a="119063622:sNHT90044880" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l3KFZfXv006379; Fri, 20 Apr 2007 11:35:41 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l3KFZKHF014889; Fri, 20 Apr 2007 15:35:41 GMT Received: from xmb-rtp-211.amer.cisco.com ([64.102.31.118]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 20 Apr 2007 11:35:28 -0400 Received: from 161.44.65.204 ([161.44.65.204]) by xmb-rtp-211.amer.cisco.com ([64.102.31.118]) via Exchange Front-End Server email.cisco.com ([64.102.31.38]) with Microsoft Exchange Server HTTP-DAV ; Fri, 20 Apr 2007 15:35:27 +0000 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Fri, 20 Apr 2007 11:35:26 -0400 From: Ralph Droms To: DHC WG Message-ID: Thread-Topic: Minutes fro IETF 68 dhc WG meeting Thread-Index: AceDYYRqwvxy/u9UEduYXwARJOT6eg== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 20 Apr 2007 15:35:28.0380 (UTC) FILETIME=[85D5DBC0:01C78361] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=10269; t=1177083341; x=1177947341; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rdroms@cisco.com; z=From:=20Ralph=20Droms=20 |Subject:=20Minutes=20fro=20IETF=2068=20dhc=20WG=20meeting |Sender:=20 |To:=20DHC=20WG=20; bh=n5g/H0TJ43eV+Fmq1lmfCUjzPKgsl2DW1h0h/ujzx3E=; b=BFGaaoUOvr6FyzYWhWCDA2w18zFf/M+Snti4ykRvuwkKDxSJ482huxfe2l346P9uprN/aRPB ceHMR9lx9qlyE1Q2mD7zrLOftWQSujYCpyVylq7RSqsgNQYKkPE5JLFL; Authentication-Results: rtp-dkim-2; header.From=rdroms@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 1.5 (+) X-Scan-Signature: a069a8e8835d39ce36e425c148267a7b Cc: Subject: [dhcwg] Minutes fro IETF 68 dhc WG meeting X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org We've submitted the WG minutes, which are available at http://www3.ietf.org/proceedings/07mar/minutes/dhc.txt and are copied below. The minutes can be revised within the next few days. Please review the minutes and respond to the chairs or to the dhc WG mailing list with additions, corrections or other comments. - Stig and Ralph dhc WG chairs ===== DHC WG - IETF 67 0900-1130 2007-03-21 (Wed) MEETING MINUTES -------------------------- The chairs appreciate the minutes taken by Shane Kerr and the jabber scribe, Mark Andrews. These minutes are based on their input. Administrivia The chairs opened the meeting with agenda bashing, circulation of blue sheets and identification of scribes. Draft last call and adoption announcements The chairs gave a status update on WG documents and work items. * Submitted to IESG draft-ietf-dhc-server-override draft-ietf-dhc-relay-agent-flags draft-ietf-dhc-dhcpv6-opt-dnsdomain draft-ietf-dhc-dhcvp6-leasequery * In or through WG last call draft-ietf-dhc-dhcpv6-ero (ready to submit to IESG) draft-ietf-dhc-dhcpv6-reconfigure-rebind (revision required) Authors to submit revision based on last call comments; then requires new WG last call draft-ietf-dhc-subnet-alloc (insufficient response) Need to determine WG consensus for standards track or informational; then requires new WG last call * Ready for WG last call draft-ietf-dhc-pxelinux (will start WG last call next week) draft-ietf-dhc-vpn-option (pending review of final comments) Reclassifying DHCPv4 Options - RFC 3942 Bernie Volz gave an update on the process to reclassify DHCPv4 options as specified in RFC 3942. In May, 2006, IANA moved all options that were not announced as "in use" to "Available". Reports were received on the following option codes: 128-135: PXE (only formal submission received; other uses reported anecdotally) 150: TFTP server addresses documented in draft-raj-dhc-tftp-addr-option; no documents received for two other reported uses 175-177: Uses reported but no documents received 208-211: PXELinux options; documented in draft-ietf-dhc-pxelinux 220: Subnet allocation; documented in draft-ietf-dhc-subnet-alloc 221: Subnet selection; documented in draft-ietf-dhc-agent-vpn-id Bernie proposed assigning option codes 128-135, 150, 208-211 and 220-221 as "Tentatively Assigned", and reclassifying 175-177 as ""Available". Bernie will write an I-D summarizing progress on RFC 3942 progress for WG review and approval before requesting the changes from IANA. Report from DHCPv6 interoperability test event Alain Durand reported on an interoperability test event sponsored by Comcast, which was held the week before the IETF meeting. The primary objectives were to test interoperability and test some specific deployment scenarios. Participating were: 7 vendors, 14 participants (one remote), 13 implementations (5 clients, 5 servers, 3 relays). Alain will publish an I-D with a summary of the test results (subject to NDA constraints). The WG chairs will set up issues tracker for issues identified in Alain's I-D DHCPv6 RAAN Option, draft-ietf-dhc-dhcpv6-agentopt-delegate-02.txt Work on the DOCSIS 3.0 specification revealed a problem with DHCPv6 prefix delegation: if the PD delegating router is not on the same link as the requesting router (implying a relay agent), how can routes to the delegated prefix be injected into the routing infrastructure. Bernie Volz described the DHCPv6 RAAN option, which allows the DHCP server to inform the router (which provides the relay agent function) on the same link ("first hop router") with the requesting router about delegated prefixes; that router can then advertise the new prefix in the appropriate routing protocols. The WG discussed some of the requirements. Bernie Volz pointed out that the first hop router needs information from both the server and from the requesting router (Release/Decline for the latter source). Ted Lemon suggested validating RAs from the requesting router; Ralph Droms responded that in some deployments the requesting routers will not be configured to issue RAs. Alain Durand asked about recovery of state generated by the RAAN option; Bernie responded that state recovery is a separate issue, addressed, for example, by leasequery. The draft for this option did not pass dhc WG call. Issues raised during the last call include: - Requires use of sequence numbering for reliability - Release/Decline Reply may be lost so relay agent may not get RAAN information and does not know to remove routes Ted said that the only case we are worried about losing data is Release/Decline, which could be solved by a new message from the server direct to the relay. Ralph pointed out that Ted's suggestion would represent a new paradigm for DHCP communication: server to relay. Ted said another advantage would be to obviate the need for message numbering to provide reliable delivery to the relay agent. - General dislike of idea of piggybacking Dave Hankins said he thinks there will be lots of use cases outside of this. The SRSN feels like a "slippery slope" in complexity. Bernie suggested that reliable server to relay reliable communication means the SRSN option is unnecessary. Fred Templin said server-relay communication could solve the problem of clients that disappear and require state change in the relay agent. The chairs will start further discussion of requirements and solutions on dhc WG mailing list Container Option for Server Configuration, draft-droms-dhc-container-opt-00.txt Ralph Droms described a DHCP "container" option, through which a DHCP server can pass specific options to a DHCP server, for forwarding to specific clients. The use case is STB CPEs in a subscriber network, which use the subscriber DHCP server. The SP DHCP server may have some specific options, such as addresses of servers for the STB, that need to be delivered to the STB. There was insufficient support to take on this proposal as a WG work item. Ralph will revise I-D based on mailing list discussion; WG to be asked to consider I-D as dhc WG work item DHCPv6 Vendor-specific Message, draft-volz-dhc-dhcpv6-vendor-message-00.txt Bernie Volz presented this proposal, which defines vendor-specific DHCP message codes, similar to vendor-specific options, for experimentation and development. Ted Lemon and Thomas Narten were opposed to the proposal as a mechanism for promoting non-interoperability. Bernie responded that we've had trouble with open "site-specific" codes, and gave server-server protocols and the RAAN server-relay messages as use cases. There was insufficient support to take on this proposal as a WG work item. The WG chairs will start further discussion on dhc WG mailing list Principles of Internet Host Configuration, draft-aboba-ip-config-00.txt Dave Thaler gave an informational presentation about this draft; no action required by dhc WG. Authentication Extensions for the DHCP, draft-pruss-dhcp-auth-dsl-00.txt Ric Pruss presented this proposal as a way to use DHCP for user authentication. The problem space is the transition by DSL providers from PPP to IP. The PPP session semantics must be now provided as "IP session", but there is no single "IP session" protocol. Relay agent information option contents is sometimes used for this purpose today, but it is not always sufficient. Proposal option 1 uses no new DHCP messages but requires a second DHCPDISCOVER message (for a total of six messages). Proposal option 2 defines new DHCP messages that integrate authentication as a separate mechanism within the usual DHCP message exchange. Ted Lemon asked why RFC 3118 is not sufficient. Ric responded that RFC 3118 requires pre-distribution of keys. Ralph pointed out that, while draft-pruss-dhcp-auth-dsl uses pre-distributed subscriber passwords, those passwords are different from RFC 3118 keys and not immediately usable with RFC 3118. Also, in the abstract, RFC 3118 is a way of securing DHCP messages, not of authenticating user identity. Ted asked why the change to the state machine was necessary. Ric replied that the user identity must be authenticated before an IP address can be assigned. Also, there may be intermediate devices in the path which will learn the address and only activate it on DHCPACK. Hannes Tschoefinig said that inserting EAP into DHCP violates the EAP applicability statement. Ted said that changing the DHCP state machine is hard and the 4-way handshake should be enough. Mark Townsley said that one goal is to authenticate the user identity before giving any information in a DHCPOFFER. Ted asked if that information is sensitive? Ric responded no, but its hard to predict how the user will be authenticated to give correct information. Ralph pointed out that this proposal is predicated on the assumption that user authentication should be accomplished in DHCP. In fact, the user authentication architecture needs to be agreed upon first. If user authentication goes into DHCP, then the dhc WG can design the protocol to meet the architecture requirements. Jari Arkko said that the first step is agreeing that DHCP protocol is right place for this. That discussion needs more people than in this room, like DSL community. He will talk to chairs and post something on the list. Ric will get concrete requirements from DSL Forum. The chairs will announce a discussion of the user authentication issues on the int-area mailing list. The Internet ADs and the chairs will decide how to have the user authentication architecture discussion. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Apr 24 08:00:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgJgw-0002Sz-Uj; Tue, 24 Apr 2007 08:00:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgJgv-0002SJ-Ve for dhcwg@ietf.org; Tue, 24 Apr 2007 08:00:18 -0400 Received: from zns001-0m9002.yokogawa.co.jp ([203.174.79.139]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgJgs-0000V0-Q6 for dhcwg@ietf.org; Tue, 24 Apr 2007 08:00:16 -0400 Received: from zns001-0m9002.yokogawa.co.jp (localhost [127.0.0.1]) by zns001-0m9002.yokogawa.co.jp (8.12.10+Sun/8.12.10) with ESMTP id l3OC0Dve021602 for ; Tue, 24 Apr 2007 21:00:13 +0900 (JST) Received: from EXCHANGE03.jp.ykgw.net (zex001-0m9003.jp.ykgw.net [10.0.11.23]) by zns001-0m9002.yokogawa.co.jp (8.12.10+Sun/8.12.10) with ESMTP id l3OC0DPm021586 for ; Tue, 24 Apr 2007 21:00:13 +0900 (JST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 24 Apr 2007 21:00:08 +0900 Message-ID: <0260031F55435342859BFB2CCA6773D81B898ABF@EXCHANGE03.jp.ykgw.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Remainder] TAHI Event Registration will be closed !! Thread-Index: AceGaBqqBOiUojtGSumFLJr52c8MIg== From: To: X-Spam-Score: 0.2 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Subject: [dhcwg] [Remainder] TAHI Event Registration will be closed !! X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org Dear all, This is a remainder. The Registration for TAHI Interoperability Test Event will be closed on 27th Apr (17P.M. JST). If you are planning to participate to the Event, please make a registration as soon as possible. =20 You can make a registration on http://www.tahi.org/inop/9thinterop.html Summary information of the event. - Venue: Nippon Convention Center (Makuhari Messe), Chiba, Japan. - Date: May 14 - May 18, 2007 - Registration & Information: http://www.tahi.org/inop/9thinterop.html We are looking forward to see you at 9th TAHI evnet! Best regards, ------------------- Hideshi Enokihara _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Apr 24 19:49:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgUkB-00023w-Vt; Tue, 24 Apr 2007 19:48:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgUkA-00023r-Uw for dhcwg@ietf.org; Tue, 24 Apr 2007 19:48:22 -0400 Received: from goliath.isc.org ([2001:4f8:3:bb::72]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgUk9-0001Kb-VK for dhcwg@ietf.org; Tue, 24 Apr 2007 19:48:22 -0400 Received: by goliath.isc.org (Postfix, from userid 10200) id 016D87D2D; Tue, 24 Apr 2007 16:48:06 -0700 (PDT) Date: Tue, 24 Apr 2007 16:48:06 -0700 From: "David W. Hankins" To: dhcwg@ietf.org Message-ID: <20070424234806.GM8898@isc.org> Mime-Version: 1.0 User-Agent: Mutt/1.5.9i X-Spam-Score: -2.8 (--) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Subject: [dhcwg] draft-dhankins-dhcp-option-guidelines-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: , Content-Type: multipart/mixed; boundary="===============0575328216==" Errors-To: dhcwg-bounces@ietf.org --===============0575328216== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="eNMatiwYGLtwo1cJ" Content-Disposition: inline --eNMatiwYGLtwo1cJ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable http://www.ietf.org/internet-drafts/draft-dhankins-dhcp-option-guidelines-0= 0.txt At IETF 67 (San Diego), I gave a presentation on an informative document I called 'Atomic DHCP'. This was, more or less, an examination, and definition of terms of a DHCP software implementation written by Ted Lemon ("ISC DHCP"). I mostly intended to ultimately provide input for a document written by someone far more clever than I that might explore the conclusions of "how to write an adoptable option" more fully. What I heard at that IETF was that the reasons we have for certain advice to DHCP option draft writers is less important than the things we might wish to tell them, and at least a couple of people thought it might be a good idea for me to take a stab at such a document. So as discussed, I've pared down (possibly by not enough, I see now at least two paragraphs that should have gone) and moved the 'Atomic DHCP' explanation to an appendix, and brought the "lessons learned" =66rom the old document into the forefront and completed them. I'd still like to see other appendices for other implementations, or if other implementations are willing to say that they understand the definition to be sufficiently similar to their own, we could generalize the language and make it non-ISC specific ("At least two implementations solved this by..."). At this point, the document is essentially complete so far as I know, which means that any good advice to draft writers you can think of for any section of the document would be great feedback. --=20 David W. Hankins "If you don't do it right the first time, Software Engineer you'll just have to do it again." Internet Systems Consortium, Inc. -- Jack T. Hankins --eNMatiwYGLtwo1cJ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFGLpc2cXeLeWu2vmoRAvnxAKCcp0wxaUC3kw7fS7pxXw8jxsAaQACfT8K7 a2Fj1Eay5WfBkRotPjNkHqU= =Egy7 -----END PGP SIGNATURE----- --eNMatiwYGLtwo1cJ-- --===============0575328216== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --===============0575328216==-- From dhcwg-bounces@ietf.org Wed Apr 25 00:07:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgYmi-0003Y6-Ou; Wed, 25 Apr 2007 00:07:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgYmh-0003Y0-5J for dhcwg@ietf.org; Wed, 25 Apr 2007 00:07:15 -0400 Received: from tyholt.uninett.no ([2001:700:1::eecb]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgYmg-0007oM-Kx for dhcwg@ietf.org; Wed, 25 Apr 2007 00:07:15 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by tyholt.uninett.no (Postfix) with ESMTP id 280B4B5AD9; Wed, 25 Apr 2007 06:07:13 +0200 (CEST) Received: from tyholt.uninett.no ([127.0.0.1]) by localhost (tyholt.uninett.no [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 16772-02-9; Wed, 25 Apr 2007 06:07:12 +0200 (CEST) Received: from [IPv6?2001?da8?b8?0?213?2ff?fe0e?7215] (unknown [IPv6:2001:da8:b8:0:213:2ff:fe0e:7215]) by tyholt.uninett.no (Postfix) with ESMTP id 5FC69B5AD8; Wed, 25 Apr 2007 06:07:12 +0200 (CEST) Message-ID: <462F1F75.7040104@uninett.no> Date: Wed, 25 Apr 2007 11:29:25 +0200 From: Stig Venaas User-Agent: Mozilla Thunderbird 1.0.7 (X11/20060616) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "David W. Hankins" Subject: Re: [dhcwg] draft-dhankins-dhcp-option-guidelines-00 References: <20070424234806.GM8898@isc.org> In-Reply-To: <20070424234806.GM8898@isc.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at uninett.no X-Spam-Score: -2.7 (--) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: dhcwg@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org David W. Hankins wrote: [...] > At this point, the document is essentially complete so far as I > know, which means that any good advice to draft writers you can > think of for any section of the document would be great feedback. Thanks for writing this, I think it is a very useful document. Some further guidelines should perhaps be added. One might be to discuss why option size is a big issue and suggest that people make options consume a minimal amount of space (e.g. not put XML into dhc, but rather a URL to a document...). Perhaps also suggest that new options should in general be requested by the client and only returned by server upon request? I think we should put all the general considerations for designing new options into this document so that people specifying new options do it right. The syntax is not the only consideration. 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 Wed Apr 25 06:42:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hgex6-0007k5-LM; Wed, 25 Apr 2007 06:42:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hgex5-0007hz-B1 for dhcwg@ietf.org; Wed, 25 Apr 2007 06:42:23 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hgex4-0001fP-2K for dhcwg@ietf.org; Wed, 25 Apr 2007 06:42:23 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 25 Apr 2007 06:42:22 -0400 X-IronPort-AV: i="4.14,450,1170651600"; d="scan'208"; a="119436184:sNHT54720040" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l3PAgLwn013326 for ; Wed, 25 Apr 2007 06:42:21 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l3PAgLlG015430 for ; Wed, 25 Apr 2007 10:42:21 GMT Received: from xmb-rtp-211.amer.cisco.com ([64.102.31.118]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Apr 2007 06:42:21 -0400 Received: from 10.86.242.224 ([10.86.242.224]) by xmb-rtp-211.amer.cisco.com ([64.102.31.118]) via Exchange Front-End Server email.cisco.com ([64.102.31.38]) with Microsoft Exchange Server HTTP-DAV ; Wed, 25 Apr 2007 10:42:21 +0000 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Tue, 24 Apr 2007 20:01:15 -0400 From: Ralph Droms To: DHC WG Message-ID: Thread-Topic: Changes to IANA Protocol Number Assignment Services web page Thread-Index: AceB5TnEeFViU+3YEduYXwARJOT6egE5523v In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 25 Apr 2007 10:42:21.0439 (UTC) FILETIME=[674460F0:01C78726] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1560; t=1177497741; x=1178361741; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rdroms@cisco.com; z=From:=20Ralph=20Droms=20 |Subject:=20FW=3A=20Changes=20to=20IANA=20Protocol=20Number=20Assignment= 20Services=20web=20page |Sender:=20 |To:=20DHC=20WG=20; bh=f+OT6PiKsv48SFg4twJRg55ZXsDidzMGZO4q0diUVWY=; b=OSYLSs00t9yp5T1jcgSfQ5xg64o2+M6JUE+hTHfADWw3AchCTo6ano+PtpXQC5jyR1klcNcl 1j9YDV5aiclb+TQSye2ttHNFKxA/fXJfcdJK/qHEKKctGf44w0ky0Pql; Authentication-Results: rtp-dkim-2; header.From=rdroms@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.2 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Subject: [dhcwg] FW: Changes to IANA Protocol Number Assignment Services web page X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org I've sent in the following request for changes to DHCP/BOOTP information at iana.org. Please respond if you have any comments. - Ralph ------ Forwarded Message From: Ralph Droms Date: Wed, 18 Apr 2007 14:13:12 -0400 To: Cc: , Jari Arkko , "Mark Townsley (townsley)" Conversation: Changes to IANA Protocol Number Assignment Services web page Subject: Changes to IANA Protocol Number Assignment Services web page I have some changes to request in the IANA Protocol Number Assignment Services web pages, http://www.iana.org/numbers.html Most of the entries under the topic heading "Bootstrap Protocol (BOOTP) and Dynamic Host Configuration Protocol" are actually specific to DHCP and BOOTP is almost an historic protocol at this point. I suggest renaming this heading to "Dynamic Host Configuration Protocol (DHCP) and Bootstrap Protocol (BOOTP)" and moving it to replace the heading "Dynamic Host Configuration Protocol (DHCP)" All of the notes in the directory http://www.iana.org/assignments/bootp-dhcp-extensions/ have been deprecated by RFC 3942. These notes and the directory should be removed. There are references to this directory in two places; these links should also be removed: Bootstrap Protocol (BOOTP) and Dynamic Host Configuration Protocol BOOTP and DHCP Extensions Dynamic Host Configuration Protocol (DHCP) Extensions - Ralph Droms co-chair, dhc WG ------ End of Forwarded Message _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Apr 25 15:16:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hgmyu-0004fv-Jx; Wed, 25 Apr 2007 15:16:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hgmyt-0004fo-SV for dhcwg@ietf.org; Wed, 25 Apr 2007 15:16:47 -0400 Received: from goliath.isc.org ([2001:4f8:3:bb::72]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hgmyt-0004mR-GE for dhcwg@ietf.org; Wed, 25 Apr 2007 15:16:47 -0400 Received: by goliath.isc.org (Postfix, from userid 10200) id 80F227D2D; Wed, 25 Apr 2007 12:16:32 -0700 (PDT) Date: Wed, 25 Apr 2007 12:16:32 -0700 From: "David W. Hankins" To: dhcwg@ietf.org Subject: Re: [dhcwg] draft-dhankins-dhcp-option-guidelines-00 Message-ID: <20070425191632.GC30775@isc.org> References: <20070424234806.GM8898@isc.org> <462F1F75.7040104@uninett.no> Mime-Version: 1.0 In-Reply-To: <462F1F75.7040104@uninett.no> User-Agent: Mutt/1.5.9i X-Spam-Score: -2.8 (--) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 X-BeenThere: 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="===============1970787504==" Errors-To: dhcwg-bounces@ietf.org --===============1970787504== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="R3G7APHDIzY6R/pk" Content-Disposition: inline --R3G7APHDIzY6R/pk Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Apr 25, 2007 at 11:29:25AM +0200, Stig Venaas wrote: > Thanks for writing this, I think it is a very useful document. Some > further guidelines should perhaps be added. One might be to discuss > why option size is a big issue and suggest that people make options > consume a minimal amount of space (e.g. not put XML into dhc, but > rather a URL to a document...). Perhaps also suggest that new options > should in general be requested by the client and only returned by > server upon request? Excellent points, I'll write something up on these two. > I think we should put all the general considerations for designing > new options into this document so that people specifying new options > do it right. The syntax is not the only consideration. I agree (syntax is just what my universe revolves around). I'd love more ideas to increase the laundry list. There has also recently been lively exchange on ietf@, and one thing that came up was about guidelines for when using DHCP at all was a good or bad idea. I suspect some abstract language to those ends should be included as well, so I've added that to my list. And thanks for the (prompt!) feedback, Stig. --=20 David W. Hankins "If you don't do it right the first time, Software Engineer you'll just have to do it again." Internet Systems Consortium, Inc. -- Jack T. Hankins --R3G7APHDIzY6R/pk Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFGL6kQcXeLeWu2vmoRAl03AKCSV2JmsmqvvLnM6k0G6SvmToq6ggCffiaR KSXlAOe/0FLr2drL0wBEvcw= =+Yza -----END PGP SIGNATURE----- --R3G7APHDIzY6R/pk-- --===============1970787504== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --===============1970787504==-- From dhcwg-bounces@ietf.org Wed Apr 25 17:15:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hgope-0008NX-NT; Wed, 25 Apr 2007 17:15:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hgopd-0008NR-6j for dhcwg@ietf.org; Wed, 25 Apr 2007 17:15:21 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hgopb-0008Bs-VX for dhcwg@ietf.org; Wed, 25 Apr 2007 17:15:21 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 25 Apr 2007 17:15:19 -0400 X-IronPort-AV: i="4.14,451,1170651600"; d="scan'208"; a="119504895:sNHT68238754" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l3PLFJMq030713 for ; Wed, 25 Apr 2007 17:15:19 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l3PLFBli029542 for ; Wed, 25 Apr 2007 21:15:19 GMT Received: from xmb-rtp-211.amer.cisco.com ([64.102.31.118]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Apr 2007 17:14:28 -0400 Received: from 10.86.242.207 ([10.86.242.207]) by xmb-rtp-211.amer.cisco.com ([64.102.31.118]) via Exchange Front-End Server email.cisco.com ([64.102.31.21]) with Microsoft Exchange Server HTTP-DAV ; Wed, 25 Apr 2007 21:14:28 +0000 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Wed, 25 Apr 2007 17:14:23 -0400 From: Ralph Droms To: DHC WG Message-ID: Thread-Topic: Identifying DHCP issues in Internet Drafts Thread-Index: AceHfrJH8QHBpPNxEduifwARJOT6eg== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 25 Apr 2007 21:14:28.0312 (UTC) FILETIME=[B571ED80:01C7877E] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=853; t=1177535719; x=1178399719; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rdroms@cisco.com; z=From:=20Ralph=20Droms=20 |Subject:=20Identifying=20DHCP=20issues=20in=20Internet=20Drafts |Sender:=20 |To:=20DHC=20WG=20; bh=Lub2lCQJOGgIBPw970lLo0zTaZavvq6Y3oisixsRP7o=; b=WVoF1CI1IfM2UKTxqLHEUclpRQev/+7Bw3U/ADCU5Dh0VgyO3nlzYTIPU+kJp0zJ8EPkFvvL VpoKq9F8nwUNKRQL+Pv58DftKDEfdmcQgbYQuF2FZ1gKxuW0lL57nkuD; Authentication-Results: rtp-dkim-2; header.From=rdroms@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Subject: [dhcwg] Identifying DHCP issues in Internet Drafts X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org Stig and I need to find some volunteers for a one-time review of Internet Drafts. We're trying to identify drafts that have DHCP-related issues that may require dhc WG collaboration. We'd like to identify these issues as early as possible, before the drafts get out of their WGs. There are roughly 90 drafts in other WGs that were found in a search for "DHCP". I imagine most of those drafts simply mention DHCP. What we're looking for is drafts that will need a new DHCP option, some other extension to the DHCP specifications, or might be proposing to use DHCP in a way that needs to be dicussed by the dhc WG. Stig and I want to find 8 or 9 volunteers who would each be willing to review about 10 drafts. Please respond to if you'd be willing to help us out with this project. Thanks... - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri Apr 27 08:44:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhPoE-0007Uf-G4; Fri, 27 Apr 2007 08:44:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhPoD-0007UX-3R; Fri, 27 Apr 2007 08:44:21 -0400 Received: from david.siemens.de ([192.35.17.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhPoB-0003Zc-Ea; Fri, 27 Apr 2007 08:44:21 -0400 Received: from mail1.siemens.de (localhost [127.0.0.1]) by david.siemens.de (8.12.6/8.12.6) with ESMTP id l3RCiGPU032218; Fri, 27 Apr 2007 14:44:16 +0200 Received: from mchp7wta.ww002.siemens.net (mchp7wta.ww002.siemens.net [139.25.131.193]) by mail1.siemens.de (8.12.6/8.12.6) with ESMTP id l3RCiGA3009166; Fri, 27 Apr 2007 14:44:16 +0200 Received: from MCHP7R6A.ww002.siemens.net ([139.25.131.164]) by mchp7wta.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Apr 2007 14:44:15 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 27 Apr 2007 14:44:14 +0200 Message-ID: <8F6CBC7005099442AECDB784C9E9D7E701A9411A@MCHP7R6A.ww002.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Review of "DHCP-based LoST Discovery Procedure" Thread-Index: AceIycMQ48+woUGsSQ+kRyeItjGung== From: "Tschofenig, Hannes" To: X-OriginalArrivalTime: 27 Apr 2007 12:44:16.0009 (UTC) FILETIME=[C3EAAF90:01C788C9] X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: Marc Linsner , ECRIT Subject: [dhcwg] Review of "DHCP-based LoST Discovery Procedure" X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org Hi all,=20 In the ECRIT working group we have discovered the need to define a discovery mechanism based on DHCP for LoST servers. Please find the document here: http://www.ietf.org/internet-drafts/draft-ietf-ecrit-dhc-lost-discovery- 01.txt We would appreciate the review of this document.=20 Ciao Hannes PS: Marc has contacted the DHC chairs when we did the WGLC in ECRIT already but I couldn't find the message anymore. Hence, I just want to make sure that the document receives adequate review.=20 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri Apr 27 10:52:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhRjJ-0006rE-BC; Fri, 27 Apr 2007 10:47:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhRjE-0006bd-Jk; Fri, 27 Apr 2007 10:47:20 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhRbo-0006Zd-Fm; Fri, 27 Apr 2007 10:39:41 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 27 Apr 2007 10:39:40 -0400 X-IronPort-AV: i="4.14,462,1170651600"; d="scan'208"; a="119671502:sNHT48858892" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l3REdeEw003113; Fri, 27 Apr 2007 10:39:40 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l3REdTHH005194; Fri, 27 Apr 2007 14:39:40 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Apr 2007 10:39:03 -0400 Received: from [10.86.241.100] ([10.86.241.100]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Apr 2007 10:39:03 -0400 Message-ID: <46320B05.2040807@cisco.com> Date: Fri, 27 Apr 2007 10:39:01 -0400 From: Mark Stapp User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: "Tschofenig, Hannes" Subject: Re: [dhcwg] Review of "DHCP-based LoST Discovery Procedure" References: <8F6CBC7005099442AECDB784C9E9D7E701A9411A@MCHP7R6A.ww002.siemens.net> In-Reply-To: <8F6CBC7005099442AECDB784C9E9D7E701A9411A@MCHP7R6A.ww002.siemens.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Apr 2007 14:39:03.0215 (UTC) FILETIME=[CD02EBF0:01C788D9] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1875; t=1177684780; x=1178548780; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mjs@cisco.com; z=From:=20Mark=20Stapp=20 |Subject:=20Re=3A=20[dhcwg]=20Review=20of=20=22DHCP-based=20LoST=20Discov ery=20Procedure=22 |Sender:=20 |To:=20=22Tschofenig,=20Hannes=22=20; bh=eOfoX+MwCIAnddgFgD4B7PJ38xDh3afgFQMPgC2Fvcg=; b=YssLOTXT2G3n4eNf43nUC5P/+icZjZ5LZVpT6npWoW05t6SjuVcLeES08cTgOCbFXOyHLG1P ddXCWwnyFwIfso5NfwQh2Ejsk3woZryLkvBiAdbUFzLRkOrzVMEklo0V; Authentication-Results: rtp-dkim-1; header.From=mjs@cisco.com; dkim=pass (si g from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: dhcwg@ietf.org, Marc Linsner , ECRIT X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org Hannes, Marc, just a couple of comments: section 3: do you think it's better to spell this out, or would it be better to just reference DNS encoding? section 4: there's a v4 analogue to the v6 "Option Request Option": the "Parameter Request List" option. you mention the v6 option in section 5, but don't mention the v4 option here. section 7: you're using the mnemonic OPTION_LOST for both the v4 and v6 option codes. would it be clearer to use OPTION_V6_LOST or something like that? section 10: I think the RFC3396 ref should be 'normative', since you're making it mandatory. I think you should include 1034 in the 'normative' section, since there's no way for the client to use the info in the option without it. the 'LoST' protocol draft is in the 'normative' section, but I don't think it's needed there. you're just specifying options that point a client at a server: you're not requiring any LoST behavior in this draft, so I think the LoST reference could be informative. the draft doesn't appear to reference 3319 or 3361, but they are included in the 'informative' section? Thanks, Mark Tschofenig, Hannes wrote: > Hi all, > > In the ECRIT working group we have discovered the need to define a > discovery mechanism based on DHCP for LoST servers. Please find the > document here: > http://www.ietf.org/internet-drafts/draft-ietf-ecrit-dhc-lost-discovery- > 01.txt > > We would appreciate the review of this document. > > Ciao > Hannes > > PS: Marc has contacted the DHC chairs when we did the WGLC in ECRIT > already but I couldn't find the message anymore. Hence, I just want to > make sure that the document receives adequate review. > > > _______________________________________________ > 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 Apr 27 12:12:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhT3q-00066m-35; Fri, 27 Apr 2007 12:12:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhT3p-00066e-4S; Fri, 27 Apr 2007 12:12:41 -0400 Received: from goliath.isc.org ([2001:4f8:3:bb::72]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhT3o-0006Nb-Hs; Fri, 27 Apr 2007 12:12:41 -0400 Received: by goliath.isc.org (Postfix, from userid 10200) id 5F2CB5A6CA; Fri, 27 Apr 2007 09:12:24 -0700 (PDT) Date: Fri, 27 Apr 2007 09:12:24 -0700 From: "David W. Hankins" To: dhcwg@ietf.org Subject: Re: [dhcwg] Review of "DHCP-based LoST Discovery Procedure" Message-ID: <20070427161224.GA15198@isc.org> References: <8F6CBC7005099442AECDB784C9E9D7E701A9411A@MCHP7R6A.ww002.siemens.net> <46320B05.2040807@cisco.com> Mime-Version: 1.0 In-Reply-To: <46320B05.2040807@cisco.com> User-Agent: Mutt/1.5.9i X-Spam-Score: -2.8 (--) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Cc: ECRIT X-BeenThere: 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="===============0931310547==" Errors-To: dhcwg-bounces@ietf.org --===============0931310547== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="4Ckj6UjgE2iN1+kY" Content-Disposition: inline --4Ckj6UjgE2iN1+kY Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Apr 27, 2007 at 10:39:01AM -0400, Mark Stapp wrote: > section 3: do you think it's better to spell this out, or would it be=20 > better to just reference DNS encoding? We just had a document returned to the DHC WG from the IESG due to recursive references, which also condemned RFC3315's RFC1035 reference as being too vague, I think? I remember Ralph said a new document that described "dhcp wire format for domain names" without any normative recursive references would come into existence, so I'm just wondering if that can be used here directly. > section 7: you're using the mnemonic OPTION_LOST for both the v4 and v6= =20 > option codes. would it be clearer to use OPTION_V6_LOST or something=20 > like that? I'd actually lean towards dropping the symbolic name on the DHCPv4 option definition, placing just the code in the appropriate field. This is more consistent across DHCPv4 option definitions, as none of them to my memory have included a symbolic name. More to the point, the IANA registry uses the OPTION_ symbolic names in DHCPv6, whereas in DHCPv4 the 'Name' column appears to look like the section title for each option definition ("NIS Servers"). My own comments; Only a single domain name MUST be present in the DHCPv4 option. This reads weird to me. That is, although it uses normative MUST, the word 'Only' in my english dialect leads me into a weird corner where it's saying "1 is the minimum number of domain names allowed." I think the author meant the option should only include one domain name. I suggest: This option contains a single doamin name, and as such MUST contain precisely one root label. Possibly also (but this is getting a bit verbose): Clients SHOULD stop processing the option at the first root label, ignoring any trailing data. Which is different from "asserting an error" and discarding the packet or similar. For DHCPv4 only: If the length of the domain name exceeds the maximum permissible within a single option (i.e., 254 octets), then the domain name MUST be represented in the DHCP message as specified in [RFC3396]. 254? 255. In DHCPv4 it's quite a bit more complicated than that, since the option also might not fit in the options field even if it is less than 255 octets in length...in which case option overloading comes into play. I would probably drop this paragraph entirely since the largest legal option is already described as being 255 octets in length, and that's how many octets you can describe with the 8-bit length field. Although that's a bit surprising to people who don't know about option overloading (RFC2132 I think), that even options smaller than 255 might appear multiple times and have to be fragmented. This is a core protocol feature however, so if someone is already "doing" DHCPv4, then they either support this generally for all options or not. --=20 David W. Hankins "If you don't do it right the first time, Software Engineer you'll just have to do it again." Internet Systems Consortium, Inc. -- Jack T. Hankins --4Ckj6UjgE2iN1+kY Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFGMiDocXeLeWu2vmoRAmDIAJ9EaP4euxGHpjyeszinXqdVlr1PBwCeOhRH fWO8m2qBeGtlMuqpWM3D+8Q= =huNr -----END PGP SIGNATURE----- --4Ckj6UjgE2iN1+kY-- --===============0931310547== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --===============0931310547==-- From dhcwg-bounces@ietf.org Sun Apr 29 20:45:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiK1S-0006ZR-LG; Sun, 29 Apr 2007 20:45:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiK1R-0006ZM-CK for dhcwg@ietf.org; Sun, 29 Apr 2007 20:45:45 -0400 Received: from mailout2.samsung.com ([203.254.224.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HiK1P-0002MG-Vh for dhcwg@ietf.org; Sun, 29 Apr 2007 20:45:45 -0400 Received: from ep_ms7_bk (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0JHA005EYCS58Y@mailout2.samsung.com> for dhcwg@ietf.org; Mon, 30 Apr 2007 09:45:42 +0900 (KST) Received: from ep_spt01 (ms7.samsung.com [203.254.225.101]) by ms7.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0JHA004QMCS5IB@ms7.samsung.com> for dhcwg@ietf.org; Mon, 30 Apr 2007 09:45:41 +0900 (KST) Content-return: prohibited Date: Mon, 30 Apr 2007 00:45:41 +0000 (GMT) From: =?euc-kr?B?wvfH9r/t?= To: dhcwg@ietf.org Message-id: <9879592.51401177893941446.JavaMail.weblogic@ep_ml19> MIME-version: 1.0 MIME-version: 1.0 X-Priority: 3 Msgkey: 20070430004541444@hyunwook.cha X-MTR: 20070430004541444@hyunwook.cha X-EPLocale: ko_KR.euc-kr X-EPWebmail-Msg-Type: personal X-EPWebmail-Reply-Demand: 0 X-EPApproval-Locale: X-Spam-Score: 2.1 (++) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Subject: [dhcwg] A question about processing a RENEW message from a client in DHCPv6. X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: hyunwook.cha@samsung.com List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0946637981==" Errors-To: dhcwg-bounces@ietf.org --===============0946637981== Content-return: prohibited Content-type: text/plain; charset=euc-kr Content-transfer-encoding: base64 DQpEZWFyLCBhbGwuDQoNCkkgYW0gbm93IGRldmVsb3BpbmcgREhDUHY2IGNsaWVudCBhbmQgc2Vy dmVyIGluIG91ciBwcm9kdWN0Lg0KSSBoYXZlIGEgcXVlc3Rpb24gcmVhZGluZyBzb3VyY2UgY29k ZSBvZiBhIG9wZW4gc291cmNlIHBhY2thZ2UgIldpZGUgREhDUHY2Ii4NCkluIHRoaXMgc29mdHdh cmUsIGl0IGRvZXMgdXBkYXRlIHVwZGF0ZV90aW1lIG9mIGJpbmRpbmcgYXNzaWduZWQgdG8gY2xp ZW50IHdpdGhvdXQgY2hlY2tpbmcgaWYgYWxsIGFzc2luZ2VkIHN0YXRlZnVsIGFkZHJlc3NlcyBm b3Igc2FtZSBJQSBhcmUgaW5jbHVkZWQgaW4gUkVORVcgbWVzc2FnZSBmcm9tIGNsaWVudC4gDQpJ ZiBzZXJ2ZXIgYXNzaWduZWQgdHdvIGFkZHJlc3NlcyB0byBJQSByZXF1ZXN0ZWQgYnkgY2xpZW50 IGFuZCBjbGllbnQgc2VuZCBSRU5FVyBtZXNzYWdlIGZvciBvbmx5IG9uZSBhZGRyZXNzLCB3aGF0 IGlzIGNvcnJlY3QgYmVoYXZpb3Igb2Ygc2VydmVyPw0KUmlnaHQgYmVmb3JlLCBJIGNoZWNrZWQg REhDUHY2IGNvbmZvcm1hbmNlIHRlc3RzdWl0IGRvY3VtZW50IGJ5IHRoZSBUQUhJLiBCdXQgSSBk byBub3QgZmluZCBleGFjdCBhbnN3ZXIuIA0KDQpJbiBteSBvcGluaW9uLCBzZXZlcmFsIGNob2lj ZXMgYXJlIHBvc3NpYmxlLiANCi0gU2VydmVyIHJlamVjdHMgUkVORVcgbWVzc2FnZS4NCi0gU2Vy dmVyIHJlbGVhc2VzIGxlYXNlIGZvciBvbWl0dGVkIGFkZHJlc3MgaW4gUkVORVcgbWVzc2FnZSBh bmQgcmVmcmVzaGVzIHVwZGF0ZV90aW1lIG9mIGJpbmRpbmcgaW5jbHVkaW5nIG9ubHkgdGhlIGFk ZHJlc3MgaW4gUkVORVcgbWVzc2FnZSBmcm9tIGNsaWVudC4gU2VydmVyIG1heSBpbmNsdWRlIElB X05BIGFkZHJlc3Mgb3B0aW9uIGZvciB0aGUgcmVsZWFzZWQgYWRkcmVzcyB3aXRoIGxpZmV0aW1l cyBzZXQgdG8gemVyby4NCi0gU2VydmVyIGtlZXBzIGxlYXNlIGZvciBvbWl0dGVkIGFkZHJlc3Mg aW4gUkVORVcgbWVzc2FnZSBkdXJpbmcgaXRzIHZhbGlkIGxpZmUgdGltZSBhbmQgcmVmcmVzaGVz IHVwZGF0ZV90aW1lIG9mIGJpbmRpbmcgaW5jbHVkaW5nIG9ubHkgdGhlIGFkZHJlc3MgaW4gUkVO RVcgbWVzc2FnZSBmcm9tIGNsaWVudC4NCg0KQW55IGFkdmljZWVzIGFuZCBjb21tZW50cyBhcmUg d2VsY29tZWQuDQoNClRoYW5rIHlvdSBpbiBhZHZhbmNlLiANCg0KSm9zZXBoIEh5dW5Xb29rIENo YQ0KDQoiRm9yIHlvdSwgTyBHb2QsIHRlc3RlZCB1czsgeW91IHJlZmluZWQgdXMgbGlrZSBzaWx2 ZXIuIg0KDQpTb2Z0d2FyZSBFbmdpbmVlciANCkRldmVsb3BtZW50IFBhcnQgMS4gSS9JbmZyYSAg DQpOZXR3b3JrIFN5c3RlbSBEaXZpc2lvbiANClRlbCAwMzEtMjc5LTM4MDQgIE1vYmlsZSAwMTAt MzAyNC0zODA0 --===============0946637981== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --===============0946637981==-- From dhcwg-bounces@ietf.org Sun Apr 29 20:58:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiKE0-00038F-Rs; Sun, 29 Apr 2007 20:58:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiKDy-00038A-Vp for dhcwg@ietf.org; Sun, 29 Apr 2007 20:58:42 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HiKDx-00060o-Mv for dhcwg@ietf.org; Sun, 29 Apr 2007 20:58:42 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 29 Apr 2007 20:58:42 -0400 X-IronPort-AV: i="4.14,467,1170651600"; d="scan'208"; a="119842169:sNHT57941284" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l3U0wfgO009442; Sun, 29 Apr 2007 20:58:41 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l3U0wcGd018371; Mon, 30 Apr 2007 00:58:40 GMT Received: from xmb-rtp-20a.amer.cisco.com ([64.102.31.15]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 29 Apr 2007 20:58:38 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: quoted-printable Subject: RE: [dhcwg] A question about processing a RENEW message from a clientin DHCPv6. Date: Sun, 29 Apr 2007 20:58:31 -0400 Message-ID: <8E296595B6471A4689555D5D725EBB2103EAB271@xmb-rtp-20a.amer.cisco.com> In-Reply-To: <9879592.51401177893941446.JavaMail.weblogic@ep_ml19> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dhcwg] A question about processing a RENEW message from a clientin DHCPv6. Thread-Index: AceKwPF5R96M1HMST+2DXSlkA+1ULAAAWZHg From: "Bernie Volz \(volz\)" To: , X-OriginalArrivalTime: 30 Apr 2007 00:58:38.0332 (UTC) FILETIME=[AFEF1BC0:01C78AC2] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2057; t=1177894721; x=1178758721; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=volz@cisco.com; z=From:=20=22Bernie=20Volz=20\(volz\)=22=20 |Subject:=20RE=3A=20[dhcwg]=20A=20question=20about=20processing=20a=20REN EW=20message=20from=20a=20clientin=20DHCPv6. |Sender:=20 |To:=20,=20; bh=ley6oA2RE4xb8fDTLZmTkX0Cja2wImD+QyFNCBnlNIU=; b=jNTdxgIhKrgQ2LMNpVPrSL1a8UW/xenbQw/pOCzI54uAOQXiwFinBuakzjO47sa32qHG+0mJ AhJUl9rAHQ5JwNWjkLUcFYFdY5tr3OzWU97vWJNKWqPwICHG+OAzAy7G; Authentication-Results: rtp-dkim-2; header.From=volz@cisco.com; dkim=pass (s ig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 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: , Errors-To: dhcwg-bounces@ietf.org How about the server includes the address as if it was in the Renew? If a client sends just a Renew with anIA option but without any IAADDR = options, why wouldn't you just renew all addresses for the binding (IA_* = and IAID) and include them in the Reply? (Of course, addresses that = can't be renewed would be sent with whatever remaining lifetimes they = have.) - Bernie=20 -----Original Message----- From: =C2=F7=C7=F6=BF=ED [mailto:hyunwook.cha@samsung.com]=20 Sent: Sunday, April 29, 2007 8:46 PM To: dhcwg@ietf.org Subject: [dhcwg] A question about processing a RENEW message from a = clientin DHCPv6. Dear, all. I am now developing DHCPv6 client and server in our product. I have a question reading source code of a open source package "Wide = DHCPv6". In this software, it does update update_time of binding assigned to = client without checking if all assinged stateful addresses for same IA = are included in RENEW message from client.=20 If server assigned two addresses to IA requested by client and client = send RENEW message for only one address, what is correct behavior of = server? Right before, I checked DHCPv6 conformance testsuit document by the = TAHI. But I do not find exact answer.=20 In my opinion, several choices are possible.=20 - Server rejects RENEW message. - Server releases lease for omitted address in RENEW message and = refreshes update_time of binding including only the address in RENEW = message from client. Server may include IA_NA address option for the = released address with lifetimes set to zero. - Server keeps lease for omitted address in RENEW message during its = valid life time and refreshes update_time of binding including only the = address in RENEW message from client. Any advicees and comments are welcomed. Thank you in advance.=20 Joseph HyunWook Cha "For you, O God, tested us; you refined us like silver." Software Engineer=20 Development Part 1. I/Infra =20 Network System Division=20 Tel 031-279-3804 Mobile 010-3024-3804 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Sun Apr 29 22:10:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiLLm-00061A-P1; Sun, 29 Apr 2007 22:10:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiLLl-0005zS-8W for dhcwg@ietf.org; Sun, 29 Apr 2007 22:10:49 -0400 Received: from mailout1.samsung.com ([203.254.224.24]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HiLLk-0000gx-JV for dhcwg@ietf.org; Sun, 29 Apr 2007 22:10:49 -0400 Received: from ep_ms7_bk (mailout1.samsung.com [203.254.224.24]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0JHA001JVGPYUR@mailout1.samsung.com> for dhcwg@ietf.org; Mon, 30 Apr 2007 11:10:46 +0900 (KST) Received: from ep_spt02 (ms7.samsung.com [203.254.225.101]) by ms7.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0JHA00KP7GPYPT@ms7.samsung.com> for dhcwg@ietf.org; Mon, 30 Apr 2007 11:10:46 +0900 (KST) Content-return: prohibited Date: Mon, 30 Apr 2007 02:10:46 +0000 (GMT) From: =?euc-kr?B?wvfH9r/t?= Subject: Fwd: RE: [dhcwg] A question about processing a RENEW message from a clientin DHCPv6. To: "Bernie Volz (volz)" , "dhcwg@ietf.org" Message-id: <13816756.73221177899046443.JavaMail.weblogic@ep_ml19> MIME-version: 1.0 MIME-version: 1.0 X-Priority: 3 Msgkey: 20070430021046442@hyunwook.cha X-MTR: 20070430021046442@hyunwook.cha X-EPLocale: ko_KR.euc-kr X-EPWebmail-Msg-Type: personal X-EPWebmail-Reply-Demand: 0 X-EPApproval-Locale: X-Spam-Score: 2.1 (++) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: hyunwook.cha@samsung.com List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0518070687==" Errors-To: dhcwg-bounces@ietf.org --===============0518070687== Content-return: prohibited Content-type: text/plain; charset=euc-kr Content-transfer-encoding: base64 RGVhciwgQmVybmllLg0KDQpUaGFuayB5b3UgZm9yIHlvdXIgY29tbWVudC4NCllvdSBtZWFuIHRo YXQgY2xpbmV0IGRvIG5vdCBoYXZlIHRvIGluY2x1ZGUgYWxsIGFkZHJlc3NlcyBtYXBwZWQgdG8g SUFfTkEgaW4gUkVORVcgdG8gZXh0ZW5kIGxpZmV0aW1lIG9mIElBX05BIGJpbmRpbmcgaW4gc2Vy dmVyLiANCg0KQWNjb3JkaW5nIHRvIFJGQzMzMTUgMTguMS4zLiBDcmVhdGlvbiBhbmQgVHJhbnNt aXNzaW9uIG9mIFJlbmV3IE1lc3NhZ2VzLCANCg0KICAiQXQgdGltZSBUMSBmb3IgYW4gSUEsIHRo ZSBjbGllbnQgaW5pdGlhdGVzIGEgUmVuZXcvUmVwbHkgbWVzc2FnZQ0KICAgZXhjaGFuZ2UgdG8g ZXh0ZW5kIHRoZSBsaWZldGltZXMgb24gYW55IGFkZHJlc3NlcyBpbiB0aGUgSUEuICBUaGUNCiAg IGNsaWVudCBpbmNsdWRlcyBhbiBJQSBvcHRpb24gd2l0aCBhbGwgYWRkcmVzc2VzIGN1cnJlbnRs eSBhc3NpZ25lZCB0bw0KICAgdGhlIElBIGluIGl0cyBSZW5ldyBtZXNzYWdlLiAiDQoNCkkgY2Fu IG5vdCBhZ3JlZSB3aXRoIHlvdS4gDQoNCklmIGNsaWVudCBkZXRlcm1pbmVzIHRvIHVzZSBvbmx5 IG9uZSBvZiBhZGRyZXNzZXMgcHJvdmlkZWQgYnkgc2VydmVyIG9yIGtub3dzIHRoYXQgYW55IGFk ZHJlc3MgaXMgbm90IG9uLWxpbmsgZnJvbSBSQSwgaXQgd2lsbCBub3Qgc2VuZCBSRU5FVyBtZXNz YWdlIGluY2x1ZGluZyBhbGwgYWRkcmVzc2VzIGFzc29jaWF0ZWQgdG8gSUFfTkEgaW4gc2VydmVy LiBGb3IgdGhpcyBjYXNlLCBzZXJ2ZXIgc2hvdWxkIG5vdCByZWZyZXNoIGFsbCBhZGRyZXNzZXMg aW4gdGhlIElBIGJ1dCBqdXN0IGFkZHJlc2VzIGluIFJFTkVXLg0KDQpJIGhhdmUgb25seSBsaXR0 bGUga25vd2xlZGdlIGFib3V0IERIQ1B2Ni4gSWYgSSBhbSB3cm9uZywgcGxlYXNlIGNvcnJlY3Qg bWUuIA0KDQpSZWdhcmRzLA0KDQpKb3NlcGggSHl1bldvb2sgQ2hhDQoNCiJGb3IgeW91LCBPIEdv ZCwgdGVzdGVkIHVzOyB5b3UgcmVmaW5lZCB1cyBsaWtlIHNpbHZlci4iDQoNClNvZnR3YXJlIEVu Z2luZWVyIA0KRGV2ZWxvcG1lbnQgUGFydCAxLiBJL0luZnJhICANCk5ldHdvcmsgU3lzdGVtIERp dmlzaW9uIA0KVGVsIDAzMS0yNzktMzgwNCAgTW9iaWxlIDAxMC0zMDI0LTM4MDQNCg0KLS0tLS0t LSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tLS0NClNlbmRlciA6IEJlcm5pZSBWb2x6ICh2b2x6KTx2 b2x6QGNpc2NvLmNvbT4gDQpEYXRlICAgOiAyMDA3LTA0LTMwIDA5OjU4DQpUaXRsZSAgOiBSRTog W2RoY3dnXSBBIHF1ZXN0aW9uIGFib3V0IHByb2Nlc3NpbmcgYSBSRU5FVyBtZXNzYWdlIGZyb20g YQ0KIGNsaWVudGluIERIQ1B2Ni4NCg0KSG93IGFib3V0IHRoZSBzZXJ2ZXIgaW5jbHVkZXMgdGhl IGFkZHJlc3MgYXMgaWYgaXQgd2FzIGluIHRoZSBSZW5ldz8NCg0KSWYgYSBjbGllbnQgc2VuZHMg anVzdCBhIFJlbmV3IHdpdGggYW5JQSBvcHRpb24gYnV0IHdpdGhvdXQgYW55IElBQUREUiBvcHRp b25zLCB3aHkgd291bGRuJ3QgeW91IGp1c3QgcmVuZXcgYWxsIGFkZHJlc3NlcyBmb3IgdGhlIGJp bmRpbmcgKElBXyogYW5kIElBSUQpIGFuZCBpbmNsdWRlIHRoZW0gaW4gdGhlIFJlcGx5PyAoT2Yg Y291cnNlLCBhZGRyZXNzZXMgdGhhdCBjYW4ndCBiZSByZW5ld2VkIHdvdWxkIGJlIHNlbnQgd2l0 aCB3aGF0ZXZlciByZW1haW5pbmcgbGlmZXRpbWVzIHRoZXkgaGF2ZS4pDQoNCi0gQmVybmllIA0K DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogwvfH9r/tIFttYWlsdG86aHl1bndv b2suY2hhQHNhbXN1bmcuY29tXSANClNlbnQ6IFN1bmRheSwgQXByaWwgMjksIDIwMDcgODo0NiBQ TQ0KVG86IGRoY3dnQGlldGYub3JnDQpTdWJqZWN0OiBbZGhjd2ddIEEgcXVlc3Rpb24gYWJvdXQg cHJvY2Vzc2luZyBhIFJFTkVXIG1lc3NhZ2UgZnJvbSBhIGNsaWVudGluIERIQ1B2Ni4NCg0KDQpE ZWFyLCBhbGwuDQoNCkkgYW0gbm93IGRldmVsb3BpbmcgREhDUHY2IGNsaWVudCBhbmQgc2VydmVy IGluIG91ciBwcm9kdWN0Lg0KSSBoYXZlIGEgcXVlc3Rpb24gcmVhZGluZyBzb3VyY2UgY29kZSBv ZiBhIG9wZW4gc291cmNlIHBhY2thZ2UgIldpZGUgREhDUHY2Ii4NCkluIHRoaXMgc29mdHdhcmUs IGl0IGRvZXMgdXBkYXRlIHVwZGF0ZV90aW1lIG9mIGJpbmRpbmcgYXNzaWduZWQgdG8gY2xpZW50 IHdpdGhvdXQgY2hlY2tpbmcgaWYgYWxsIGFzc2luZ2VkIHN0YXRlZnVsIGFkZHJlc3NlcyBmb3Ig c2FtZSBJQSBhcmUgaW5jbHVkZWQgaW4gUkVORVcgbWVzc2FnZSBmcm9tIGNsaWVudC4gDQpJZiBz ZXJ2ZXIgYXNzaWduZWQgdHdvIGFkZHJlc3NlcyB0byBJQSByZXF1ZXN0ZWQgYnkgY2xpZW50IGFu ZCBjbGllbnQgc2VuZCBSRU5FVyBtZXNzYWdlIGZvciBvbmx5IG9uZSBhZGRyZXNzLCB3aGF0IGlz IGNvcnJlY3QgYmVoYXZpb3Igb2Ygc2VydmVyPw0KUmlnaHQgYmVmb3JlLCBJIGNoZWNrZWQgREhD UHY2IGNvbmZvcm1hbmNlIHRlc3RzdWl0IGRvY3VtZW50IGJ5IHRoZSBUQUhJLiBCdXQgSSBkbyBu b3QgZmluZCBleGFjdCBhbnN3ZXIuIA0KDQpJbiBteSBvcGluaW9uLCBzZXZlcmFsIGNob2ljZXMg YXJlIHBvc3NpYmxlLiANCi0gU2VydmVyIHJlamVjdHMgUkVORVcgbWVzc2FnZS4NCi0gU2VydmVy IHJlbGVhc2VzIGxlYXNlIGZvciBvbWl0dGVkIGFkZHJlc3MgaW4gUkVORVcgbWVzc2FnZSBhbmQg cmVmcmVzaGVzIHVwZGF0ZV90aW1lIG9mIGJpbmRpbmcgaW5jbHVkaW5nIG9ubHkgdGhlIGFkZHJl c3MgaW4gUkVORVcgbWVzc2FnZSBmcm9tIGNsaWVudC4gU2VydmVyIG1heSBpbmNsdWRlIElBX05B IGFkZHJlc3Mgb3B0aW9uIGZvciB0aGUgcmVsZWFzZWQgYWRkcmVzcyB3aXRoIGxpZmV0aW1lcyBz ZXQgdG8gemVyby4NCi0gU2VydmVyIGtlZXBzIGxlYXNlIGZvciBvbWl0dGVkIGFkZHJlc3MgaW4g UkVORVcgbWVzc2FnZSBkdXJpbmcgaXRzIHZhbGlkIGxpZmUgdGltZSBhbmQgcmVmcmVzaGVzIHVw ZGF0ZV90aW1lIG9mIGJpbmRpbmcgaW5jbHVkaW5nIG9ubHkgdGhlIGFkZHJlc3MgaW4gUkVORVcg bWVzc2FnZSBmcm9tIGNsaWVudC4NCg0KQW55IGFkdmljZWVzIGFuZCBjb21tZW50cyBhcmUgd2Vs Y29tZWQuDQoNClRoYW5rIHlvdSBpbiBhZHZhbmNlLiANCg0KSm9zZXBoIEh5dW5Xb29rIENoYQ0K DQoiRm9yIHlvdSwgTyBHb2QsIHRlc3RlZCB1czsgeW91IHJlZmluZWQgdXMgbGlrZSBzaWx2ZXIu Ig0KDQpTb2Z0d2FyZSBFbmdpbmVlciANCkRldmVsb3BtZW50IFBhcnQgMS4gSS9JbmZyYSAgDQpO ZXR3b3JrIFN5c3RlbSBEaXZpc2lvbiANClRlbCAwMzEtMjc5LTM4MDQgIE1vYmlsZSAwMTAtMzAy NC0zODA0DQoNCg0KDQoNCg== --===============0518070687== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --===============0518070687==-- From dhcwg-bounces@ietf.org Sun Apr 29 22:26:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiLb0-0006k5-KG; Sun, 29 Apr 2007 22:26:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiLaz-0006jx-O4 for dhcwg@ietf.org; Sun, 29 Apr 2007 22:26:33 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HiLaz-0005ir-BM for dhcwg@ietf.org; Sun, 29 Apr 2007 22:26:33 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 29 Apr 2007 22:26:31 -0400 X-IronPort-AV: i="4.14,467,1170651600"; d="scan'208"; a="119844958:sNHT72348860" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l3U2QVGq026888; Sun, 29 Apr 2007 22:26:31 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l3U2QQlG021446; Mon, 30 Apr 2007 02:26:26 GMT Received: from xmb-rtp-20a.amer.cisco.com ([64.102.31.15]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 29 Apr 2007 22:26:26 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: quoted-printable Subject: RE: RE: [dhcwg] A question about processing a RENEW message from a clientin DHCPv6. Date: Sun, 29 Apr 2007 22:26:18 -0400 Message-ID: <8E296595B6471A4689555D5D725EBB2103EAB289@xmb-rtp-20a.amer.cisco.com> In-Reply-To: <13816756.73221177899046443.JavaMail.weblogic@ep_ml19> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RE: [dhcwg] A question about processing a RENEW message from a clientin DHCPv6. Thread-Index: AceKzMn5maSVqi7hRly1Rg2RCKr2pQAALXVg From: "Bernie Volz \(volz\)" To: , X-OriginalArrivalTime: 30 Apr 2007 02:26:26.0045 (UTC) FILETIME=[F3BC52D0:01C78ACE] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4843; t=1177899991; x=1178763991; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=volz@cisco.com; z=From:=20=22Bernie=20Volz=20\(volz\)=22=20 |Subject:=20RE=3A=20RE=3A=20[dhcwg]=20A=20question=20about=20processing=2 0a=20RENEW=20message=20from=20a=20clientin=20DHCPv6. |Sender:=20 |To:=20,=20; bh=oVFWrQXoQqabyvdoL+EAiek5VSFi8P7DO/P34GW6Ddo=; b=BAnyvG3sJ1lzO3mG1/LEE5vjSSyGXx2YOXwfTRMfTSp4kyWMaKXbjsvODBZLmQKW9Ax+jsCh yxZctthQMCY2ckntZN/A8jLIf/pn9tbsgYKDxbYcLTRYQwyqb5Wf7qCy; Authentication-Results: rtp-dkim-2; header.From=volz@cisco.com; dkim=pass (s ig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 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: , Errors-To: dhcwg-bounces@ietf.org Obviously the server sent these addresses to the client previously in a = Reply. Otherwise, why it would it have them? And, the server still has the leases (ie, we assume the valid lifetime = has not expired). And if there are no server policies that conflict with = them being used and renewed, what's wrong with the server renewing them = and sending them to the client? The worst is that the client will ignore them like it did previously. = Or, if the client have previously RELEASED or DECLINED them, it should = do so now and perhaps those messages will get to the server (the client = is not required to keep retrying RELEASE and DECLINE messages so it = could be that the previous attempt failed to reach the server); which is = a plus as then the server knows that the client doesn't want to use = those leases or can't use them because of conflicts. Note also that the RFC 3315 langague you quoted does not include a MUST. = And, also note the language in 18.1.8. Receipt of Reply Messages which = clearly indicates that a server may return additional addresses for a = Request, Renew, or Rebind. - Bernie -----Original Message----- From: =C2=F7=C7=F6=BF=ED [mailto:hyunwook.cha@samsung.com]=20 Sent: Sunday, April 29, 2007 10:11 PM To: Bernie Volz (volz); dhcwg@ietf.org Subject: Fwd: RE: [dhcwg] A question about processing a RENEW message = from a clientin DHCPv6. Dear, Bernie. Thank you for your comment. You mean that clinet do not have to include all addresses mapped to = IA_NA in RENEW to extend lifetime of IA_NA binding in server.=20 According to RFC3315 18.1.3. Creation and Transmission of Renew = Messages,=20 "At time T1 for an IA, the client initiates a Renew/Reply message exchange to extend the lifetimes on any addresses in the IA. The client includes an IA option with all addresses currently assigned to the IA in its Renew message. " I can not agree with you.=20 If client determines to use only one of addresses provided by server or = knows that any address is not on-link from RA, it will not send RENEW = message including all addresses associated to IA_NA in server. For this = case, server should not refresh all addresses in the IA but just = addreses in RENEW. I have only little knowledge about DHCPv6. If I am wrong, please correct = me.=20 Regards, Joseph HyunWook Cha "For you, O God, tested us; you refined us like silver." Software Engineer=20 Development Part 1. I/Infra =20 Network System Division=20 Tel 031-279-3804 Mobile 010-3024-3804 ------- Original Message ------- Sender : Bernie Volz (volz)=20 Date : 2007-04-30 09:58 Title : RE: [dhcwg] A question about processing a RENEW message from a clientin DHCPv6. How about the server includes the address as if it was in the Renew? If a client sends just a Renew with anIA option but without any IAADDR = options, why wouldn't you just renew all addresses for the binding (IA_* = and IAID) and include them in the Reply? (Of course, addresses that = can't be renewed would be sent with whatever remaining lifetimes they = have.) - Bernie=20 -----Original Message----- From: =C2=F7=C7=F6=BF=ED [mailto:hyunwook.cha@samsung.com]=20 Sent: Sunday, April 29, 2007 8:46 PM To: dhcwg@ietf.org Subject: [dhcwg] A question about processing a RENEW message from a = clientin DHCPv6. Dear, all. I am now developing DHCPv6 client and server in our product. I have a question reading source code of a open source package "Wide = DHCPv6". In this software, it does update update_time of binding assigned to = client without checking if all assinged stateful addresses for same IA = are included in RENEW message from client.=20 If server assigned two addresses to IA requested by client and client = send RENEW message for only one address, what is correct behavior of = server? Right before, I checked DHCPv6 conformance testsuit document by the = TAHI. But I do not find exact answer.=20 In my opinion, several choices are possible.=20 - Server rejects RENEW message. - Server releases lease for omitted address in RENEW message and = refreshes update_time of binding including only the address in RENEW = message from client. Server may include IA_NA address option for the = released address with lifetimes set to zero. - Server keeps lease for omitted address in RENEW message during its = valid life time and refreshes update_time of binding including only the = address in RENEW message from client. Any advicees and comments are welcomed. Thank you in advance.=20 Joseph HyunWook Cha "For you, O God, tested us; you refined us like silver." Software Engineer=20 Development Part 1. I/Infra =20 Network System Division=20 Tel 031-279-3804 Mobile 010-3024-3804 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon Apr 30 00:14:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiNHa-0001jK-E6; Mon, 30 Apr 2007 00:14:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiNHZ-0001jA-8Z for dhcwg@ietf.org; Mon, 30 Apr 2007 00:14:37 -0400 Received: from mail128.messagelabs.com ([216.82.250.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HiNHX-0008Gn-QR for dhcwg@ietf.org; Mon, 30 Apr 2007 00:14:37 -0400 X-VirusChecked: Checked X-Env-Sender: Q4997C@motorola.com X-Msg-Ref: server-4.tower-128.messagelabs.com!1177906466!16276151!1 X-StarScan-Version: 5.5.10.7.1; banners=-,-,- X-Originating-IP: [129.188.136.9] Received: (qmail 28277 invoked from network); 30 Apr 2007 04:14:26 -0000 Received: from ftpbox.mot.com (HELO ftpbox.mot.com) (129.188.136.9) by server-4.tower-128.messagelabs.com with SMTP; 30 Apr 2007 04:14:26 -0000 Received: from az33exr01.mot.com ([10.64.251.231]) by ftpbox.mot.com (8.12.11/Motorola) with ESMTP id l3U4EPtY027099 for ; Sun, 29 Apr 2007 23:14:26 -0500 (CDT) Received: from az10vts01 (az10vts01.mot.com [10.64.251.242]) by az33exr01.mot.com (8.13.1/Vontu) with SMTP id l3U4EPmf007751 for ; Sun, 29 Apr 2007 23:14:25 -0500 (CDT) Received: from ZMY16EXM66.ds.mot.com (zmy16exm66.ap.mot.com [10.179.4.26]) by az33exr01.mot.com (8.13.1/8.13.0) with ESMTP id l3U4ENTn007739 for ; Sun, 29 Apr 2007 23:14:24 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: [dhcwg] A question about dimensioning DHCP Server Date: Mon, 30 Apr 2007 12:13:13 +0800 Message-ID: <750BBC72E178114F9DC4872EBFF29A5B0415B2B4@ZMY16EXM66.ds.mot.com> In-Reply-To: <9879592.51401177893941446.JavaMail.weblogic@ep_ml19> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dhcwg] A question about dimensioning DHCP Server Thread-Index: AceKwPBpvsR7I46VSJKUqwpkC2pAkwAG9yAg From: "Aggarwal Vivek-Q4997C" To: X-Vontu: Pass X-Spam-Score: 0.2 (/) X-Scan-Signature: e178fd6cb61ffb6940cd878e7fea8606 X-BeenThere: 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="===============1513263850==" Errors-To: dhcwg-bounces@ietf.org This is a multi-part message in MIME format. --===============1513263850== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C78ADE.06995B89" This is a multi-part message in MIME format. ------_=_NextPart_001_01C78ADE.06995B89 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello All =20 I have some questions regarding the dimensioning of DHCP server =20 Can anyone please respond my below question? =20 1. What are the dimensioning criteria for DHCP Server? =20 2. How many subscribers the Sun 8000 Modular Blade Sever Chassis with about 150 Gb of Hardisk can handle? =20 3. How can we configure DHCP Servers to work in Load Balancing Scenario? =20 Looking forward for a early reply =20 Rgds Vivek Aggarwal Motorola India Network Engineer Bangalore,India M- +919945505704 ------_=_NextPart_001_01C78ADE.06995B89 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello All

 

I have some questions regarding = the dimensioning of DHCP server

 

Can anyone please respond my = below question?

 

1.       What are the dimensioning criteria for DHCP = Server?

 

2.       How many subscribers the Sun 8000 Modular Blade = Sever Chassis with about 150 Gb of Hardisk can handle?

 

3.       How can we configure DHCP Servers to work in Load = Balancing Scenario?

 

Looking forward for a early = reply

 

Rgds

Vivek = Aggarwal

Motorola India

Network = Engineer

Bangalore,India<= /font>

M- = +919945505704

------_=_NextPart_001_01C78ADE.06995B89-- --===============1513263850== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --===============1513263850==-- From dhcwg-bounces@ietf.org Mon Apr 30 00:17:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiNK2-0003NV-OO; Mon, 30 Apr 2007 00:17:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiNK1-0003NQ-ST for dhcwg@ietf.org; Mon, 30 Apr 2007 00:17:09 -0400 Received: from mailout1.samsung.com ([203.254.224.24]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HiNK1-0000Ki-4q for dhcwg@ietf.org; Mon, 30 Apr 2007 00:17:09 -0400 Received: from ep_ms7_bk (mailout1.samsung.com [203.254.224.24]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0JHA0059TMJKUR@mailout1.samsung.com> for dhcwg@ietf.org; Mon, 30 Apr 2007 13:16:32 +0900 (KST) Received: from ep_spt02 (ms7.samsung.com [203.254.225.101]) by ms7.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0JHA00F03MJJLD@ms7.samsung.com> for dhcwg@ietf.org; Mon, 30 Apr 2007 13:16:32 +0900 (KST) Content-return: prohibited Date: Mon, 30 Apr 2007 04:16:32 +0000 (GMT) From: =?euc-kr?B?wvfH9r/t?= Subject: Re: RE: RE: [dhcwg] A question about processing a RENEW message from a clientin DHCPv6. To: "Bernie Volz (volz)" Message-id: <8089192.68821177906590686.JavaMail.weblogic@ep_ml29> MIME-version: 1.0 MIME-version: 1.0 X-Priority: 3 Msgkey: 20070430041630684@hyunwook.cha X-MTR: 20070430041630684@hyunwook.cha X-EPLocale: ko_KR.euc-kr X-EPWebmail-Msg-Type: personal X-EPWebmail-Reply-Demand: 0 X-EPApproval-Locale: X-Spam-Score: 2.1 (++) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Cc: "dhcwg@ietf.org" X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: hyunwook.cha@samsung.com List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0990312331==" Errors-To: dhcwg-bounces@ietf.org --===============0990312331== Content-return: prohibited Content-type: text/plain; charset=euc-kr Content-transfer-encoding: base64 DQpEZWFyLCBCZXJuaWUuDQoNClRoYW5rIHlvdSBzbyBtdWNoIGZvciB5b3VyIGtpbmQgY2xhcmlm aWNhdGlvbi4NCkkgYWxzbyBoYXZlIG9uZSBtb3JlIHF1ZXN0aW9uLiANCk15IGFzc3VtcHRpb24g aXMgdGhhdCBhZGRyZXNzIEEocHJlZmVycmVkIGxpZmV0aW1lID0gMTAwcyksIGFkZHJlc3MgQiAo cHJlZmVycmVkIGxpZmV0aW1lPSAxMDBzKSBhcmUgYXNzaWduZWQgdG8gdGhlIGNsaWVudC4NClNv LCBUMSwgVDIgaW4gUkVQTFkgbWVzc2FnZSBhcmUgNTBzLCA4MHMgcmVwZWN0aXZlbHkuDQpGb3Ig YW55IHJlYXNvbiwgdGhlIGNsaWVudCB3YW50cyB0byByZW5ldyBvbmx5IGFkZHJlc3MgQSBhbmQg c2VuZHMgUkVORVcgaW5jbHVkaW5nIElBX0FkZHIgb3B0aW9uIGZvciBvbmx5IGFkZHJlc3MgQSBh ZnRlciA1MCBzZWNvbmRzLg0KV2hlbiBzZXJ2ZXIgcmVjZWl2ZXMgUkVORVcsIGl0IHJlZnJlc2hl cyBsaWZldGltZSBvZiBhZGRyZXNzIEEsIFRoZW4sIGFkZHJlc3MgQiBoYXMgNTAgc2Vjb25kcyBs ZWZ0IGFzIHByZWZlcnJlZCBsaWZldGltZS4gDQpUaGVuLCBzZXJ2ZXIgc2VuZCBSRVBMWSB3aXRo IElBX05BIG9waW9uIGluY2x1ZGluZyBJQV9BZGRyIG9wdGlvbnMgZm9yIGFkZHJlc3MgQSBhbmQg Qi4gQXQgdGhpcyB0aW1lLCBUMSwgVDIgdmFsdWVzIGFyZSAyNXMsIDQwcy4gDQpBcyBiZWZvcmUs IGNsaWVudCBzZW5kIFJFTkVXIGZvciBvbmx5IGFkZHJlc3MgQSBhZnRlciAyNSBzZWNvbmRzLiBU aGVuLCBzZXJ2ZXIgcmVmcmVzaGVzIGxpZmV0aW1lIG9mIGFkZHJlc3MgQS4gU28sIGFkZHJlc3Mg QiBoYXMgMjUgc2Vjb25kcyBsZWZ0IGFzIHByZWZlcnJlZCBsaWZldGltZS4gSW4gdGhpcyB3YXks IGl0IHNlZW1zIHRoYXQgbWFueSBpdGVyYXRpb25zIGFyZSBwb3NzaWJsZSwgc28gUkVORVcvUkVQ TFkgZXhjaGFuZ2VzIGNhbiBoYXBwZW4gdmVyeSBmcmVxdWVudGx5LCB3aGljaCBpcyBub3QgZGVz aXJhYmxlLiANCg0KSWYgSSBtaXN1bmRlcnN0b29kLCBwbGVhc2UgY29ycmVjdCBtZS4NCg0KVGhh bmsgeW91IGluIGFkdmFuY2UuDQoNCg0KDQoNCkpvc2VwaCBIeXVuV29vayBDaGENCg0KIkZvciB5 b3UsIE8gR29kLCB0ZXN0ZWQgdXM7IHlvdSByZWZpbmVkIHVzIGxpa2Ugc2lsdmVyLiINCg0KU29m dHdhcmUgRW5naW5lZXIgDQpEZXZlbG9wbWVudCBQYXJ0IDEuIEkvSW5mcmEgIA0KTmV0d29yayBT eXN0ZW0gRGl2aXNpb24gDQpUZWwgMDMxLTI3OS0zODA0ICBNb2JpbGUgMDEwLTMwMjQtMzgwNA0K DQotLS0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0tLQ0KU2VuZGVyIDogQmVybmllIFZvbHog KHZvbHopPHZvbHpAY2lzY28uY29tPiANCkRhdGUgICA6IDIwMDctMDQtMzAgMTE6MjYNClRpdGxl ICA6IFJFOiBSRTogW2RoY3dnXSBBIHF1ZXN0aW9uIGFib3V0IHByb2Nlc3NpbmcgYSBSRU5FVyBt ZXNzYWdlIGZyb20gYQ0KIGNsaWVudGluIERIQ1B2Ni4NCg0KT2J2aW91c2x5IHRoZSBzZXJ2ZXIg c2VudCB0aGVzZSBhZGRyZXNzZXMgdG8gdGhlIGNsaWVudCBwcmV2aW91c2x5IGluIGEgUmVwbHku IE90aGVyd2lzZSwgd2h5IGl0IHdvdWxkIGl0IGhhdmUgdGhlbT8NCg0KQW5kLCB0aGUgc2VydmVy IHN0aWxsIGhhcyB0aGUgbGVhc2VzIChpZSwgd2UgYXNzdW1lIHRoZSB2YWxpZCBsaWZldGltZSBo YXMgbm90IGV4cGlyZWQpLiBBbmQgaWYgdGhlcmUgYXJlIG5vIHNlcnZlciBwb2xpY2llcyB0aGF0 IGNvbmZsaWN0IHdpdGggdGhlbSBiZWluZyB1c2VkIGFuZCByZW5ld2VkLCB3aGF0J3Mgd3Jvbmcg d2l0aCB0aGUgc2VydmVyIHJlbmV3aW5nIHRoZW0gYW5kIHNlbmRpbmcgdGhlbSB0byB0aGUgY2xp ZW50Pw0KDQpUaGUgd29yc3QgaXMgdGhhdCB0aGUgY2xpZW50IHdpbGwgaWdub3JlIHRoZW0gbGlr ZSBpdCBkaWQgcHJldmlvdXNseS4gT3IsIGlmIHRoZSBjbGllbnQgaGF2ZSBwcmV2aW91c2x5IFJF TEVBU0VEIG9yIERFQ0xJTkVEIHRoZW0sIGl0IHNob3VsZCBkbyBzbyBub3cgYW5kIHBlcmhhcHMg dGhvc2UgbWVzc2FnZXMgd2lsbCBnZXQgdG8gdGhlIHNlcnZlciAodGhlIGNsaWVudCBpcyBub3Qg cmVxdWlyZWQgdG8ga2VlcCByZXRyeWluZyBSRUxFQVNFIGFuZCBERUNMSU5FIG1lc3NhZ2VzIHNv IGl0IGNvdWxkIGJlIHRoYXQgdGhlIHByZXZpb3VzIGF0dGVtcHQgZmFpbGVkIHRvIHJlYWNoIHRo ZSBzZXJ2ZXIpOyB3aGljaCBpcyBhIHBsdXMgYXMgdGhlbiB0aGUgc2VydmVyIGtub3dzIHRoYXQg dGhlIGNsaWVudCBkb2Vzbid0IHdhbnQgdG8gdXNlIHRob3NlIGxlYXNlcyBvciBjYW4ndCB1c2Ug dGhlbSBiZWNhdXNlIG9mIGNvbmZsaWN0cy4NCg0KTm90ZSBhbHNvIHRoYXQgdGhlIFJGQyAzMzE1 IGxhbmdhZ3VlIHlvdSBxdW90ZWQgZG9lcyBub3QgaW5jbHVkZSBhIE1VU1QuIEFuZCwgYWxzbyBu b3RlIHRoZSBsYW5ndWFnZSBpbiAxOC4xLjguIFJlY2VpcHQgb2YgUmVwbHkgTWVzc2FnZXMgd2hp Y2ggY2xlYXJseSBpbmRpY2F0ZXMgdGhhdCBhIHNlcnZlciBtYXkgcmV0dXJuIGFkZGl0aW9uYWwg YWRkcmVzc2VzIGZvciBhIFJlcXVlc3QsIFJlbmV3LCBvciBSZWJpbmQuDQoNCi0gQmVybmllDQoN Ci0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiDC98f2v+0gW21haWx0bzpoeXVud29v ay5jaGFAc2Ftc3VuZy5jb21dIA0KU2VudDogU3VuZGF5LCBBcHJpbCAyOSwgMjAwNyAxMDoxMSBQ TQ0KVG86IEJlcm5pZSBWb2x6ICh2b2x6KTsgZGhjd2dAaWV0Zi5vcmcNClN1YmplY3Q6IEZ3ZDog UkU6IFtkaGN3Z10gQSBxdWVzdGlvbiBhYm91dCBwcm9jZXNzaW5nIGEgUkVORVcgbWVzc2FnZSBm cm9tIGEgY2xpZW50aW4gREhDUHY2Lg0KDQpEZWFyLCBCZXJuaWUuDQoNClRoYW5rIHlvdSBmb3Ig eW91ciBjb21tZW50Lg0KWW91IG1lYW4gdGhhdCBjbGluZXQgZG8gbm90IGhhdmUgdG8gaW5jbHVk ZSBhbGwgYWRkcmVzc2VzIG1hcHBlZCB0byBJQV9OQSBpbiBSRU5FVyB0byBleHRlbmQgbGlmZXRp bWUgb2YgSUFfTkEgYmluZGluZyBpbiBzZXJ2ZXIuIA0KDQpBY2NvcmRpbmcgdG8gUkZDMzMxNSAx OC4xLjMuIENyZWF0aW9uIGFuZCBUcmFuc21pc3Npb24gb2YgUmVuZXcgTWVzc2FnZXMsIA0KDQog ICJBdCB0aW1lIFQxIGZvciBhbiBJQSwgdGhlIGNsaWVudCBpbml0aWF0ZXMgYSBSZW5ldy9SZXBs eSBtZXNzYWdlDQogICBleGNoYW5nZSB0byBleHRlbmQgdGhlIGxpZmV0aW1lcyBvbiBhbnkgYWRk cmVzc2VzIGluIHRoZSBJQS4gIFRoZQ0KICAgY2xpZW50IGluY2x1ZGVzIGFuIElBIG9wdGlvbiB3 aXRoIGFsbCBhZGRyZXNzZXMgY3VycmVudGx5IGFzc2lnbmVkIHRvDQogICB0aGUgSUEgaW4gaXRz IFJlbmV3IG1lc3NhZ2UuICINCg0KSSBjYW4gbm90IGFncmVlIHdpdGggeW91LiANCg0KSWYgY2xp ZW50IGRldGVybWluZXMgdG8gdXNlIG9ubHkgb25lIG9mIGFkZHJlc3NlcyBwcm92aWRlZCBieSBz ZXJ2ZXIgb3Iga25vd3MgdGhhdCBhbnkgYWRkcmVzcyBpcyBub3Qgb24tbGluayBmcm9tIFJBLCBp dCB3aWxsIG5vdCBzZW5kIFJFTkVXIG1lc3NhZ2UgaW5jbHVkaW5nIGFsbCBhZGRyZXNzZXMgYXNz b2NpYXRlZCB0byBJQV9OQSBpbiBzZXJ2ZXIuIEZvciB0aGlzIGNhc2UsIHNlcnZlciBzaG91bGQg bm90IHJlZnJlc2ggYWxsIGFkZHJlc3NlcyBpbiB0aGUgSUEgYnV0IGp1c3QgYWRkcmVzZXMgaW4g UkVORVcuDQoNCkkgaGF2ZSBvbmx5IGxpdHRsZSBrbm93bGVkZ2UgYWJvdXQgREhDUHY2LiBJZiBJ IGFtIHdyb25nLCBwbGVhc2UgY29ycmVjdCBtZS4gDQoNClJlZ2FyZHMsDQoNCkpvc2VwaCBIeXVu V29vayBDaGENCg0KIkZvciB5b3UsIE8gR29kLCB0ZXN0ZWQgdXM7IHlvdSByZWZpbmVkIHVzIGxp a2Ugc2lsdmVyLiINCg0KU29mdHdhcmUgRW5naW5lZXIgDQpEZXZlbG9wbWVudCBQYXJ0IDEuIEkv SW5mcmEgIA0KTmV0d29yayBTeXN0ZW0gRGl2aXNpb24gDQpUZWwgMDMxLTI3OS0zODA0ICBNb2Jp bGUgMDEwLTMwMjQtMzgwNA0KDQotLS0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0tLQ0KU2Vu ZGVyIDogQmVybmllIFZvbHogKHZvbHopPHZvbHpAY2lzY28uY29tPiANCkRhdGUgICA6IDIwMDct MDQtMzAgMDk6NTgNClRpdGxlICA6IFJFOiBbZGhjd2ddIEEgcXVlc3Rpb24gYWJvdXQgcHJvY2Vz c2luZyBhIFJFTkVXIG1lc3NhZ2UgZnJvbSBhDQogY2xpZW50aW4gREhDUHY2Lg0KDQpIb3cgYWJv dXQgdGhlIHNlcnZlciBpbmNsdWRlcyB0aGUgYWRkcmVzcyBhcyBpZiBpdCB3YXMgaW4gdGhlIFJl bmV3Pw0KDQpJZiBhIGNsaWVudCBzZW5kcyBqdXN0IGEgUmVuZXcgd2l0aCBhbklBIG9wdGlvbiBi dXQgd2l0aG91dCBhbnkgSUFBRERSIG9wdGlvbnMsIHdoeSB3b3VsZG4ndCB5b3UganVzdCByZW5l dyBhbGwgYWRkcmVzc2VzIGZvciB0aGUgYmluZGluZyAoSUFfKiBhbmQgSUFJRCkgYW5kIGluY2x1 ZGUgdGhlbSBpbiB0aGUgUmVwbHk/IChPZiBjb3Vyc2UsIGFkZHJlc3NlcyB0aGF0IGNhbid0IGJl IHJlbmV3ZWQgd291bGQgYmUgc2VudCB3aXRoIHdoYXRldmVyIHJlbWFpbmluZyBsaWZldGltZXMg dGhleSBoYXZlLikNCg0KLSBCZXJuaWUgDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpG cm9tOiDC98f2v+0gW21haWx0bzpoeXVud29vay5jaGFAc2Ftc3VuZy5jb21dIA0KU2VudDogU3Vu ZGF5LCBBcHJpbCAyOSwgMjAwNyA4OjQ2IFBNDQpUbzogZGhjd2dAaWV0Zi5vcmcNClN1YmplY3Q6 IFtkaGN3Z10gQSBxdWVzdGlvbiBhYm91dCBwcm9jZXNzaW5nIGEgUkVORVcgbWVzc2FnZSBmcm9t IGEgY2xpZW50aW4gREhDUHY2Lg0KDQoNCkRlYXIsIGFsbC4NCg0KSSBhbSBub3cgZGV2ZWxvcGlu ZyBESENQdjYgY2xpZW50IGFuZCBzZXJ2ZXIgaW4gb3VyIHByb2R1Y3QuDQpJIGhhdmUgYSBxdWVz dGlvbiByZWFkaW5nIHNvdXJjZSBjb2RlIG9mIGEgb3BlbiBzb3VyY2UgcGFja2FnZSAiV2lkZSBE SENQdjYiLg0KSW4gdGhpcyBzb2Z0d2FyZSwgaXQgZG9lcyB1cGRhdGUgdXBkYXRlX3RpbWUgb2Yg YmluZGluZyBhc3NpZ25lZCB0byBjbGllbnQgd2l0aG91dCBjaGVja2luZyBpZiBhbGwgYXNzaW5n ZWQgc3RhdGVmdWwgYWRkcmVzc2VzIGZvciBzYW1lIElBIGFyZSBpbmNsdWRlZCBpbiBSRU5FVyBt ZXNzYWdlIGZyb20gY2xpZW50LiANCklmIHNlcnZlciBhc3NpZ25lZCB0d28gYWRkcmVzc2VzIHRv IElBIHJlcXVlc3RlZCBieSBjbGllbnQgYW5kIGNsaWVudCBzZW5kIFJFTkVXIG1lc3NhZ2UgZm9y IG9ubHkgb25lIGFkZHJlc3MsIHdoYXQgaXMgY29ycmVjdCBiZWhhdmlvciBvZiBzZXJ2ZXI/DQpS aWdodCBiZWZvcmUsIEkgY2hlY2tlZCBESENQdjYgY29uZm9ybWFuY2UgdGVzdHN1aXQgZG9jdW1l bnQgYnkgdGhlIFRBSEkuIEJ1dCBJIGRvIG5vdCBmaW5kIGV4YWN0IGFuc3dlci4gDQoNCkluIG15 IG9waW5pb24sIHNldmVyYWwgY2hvaWNlcyBhcmUgcG9zc2libGUuIA0KLSBTZXJ2ZXIgcmVqZWN0 cyBSRU5FVyBtZXNzYWdlLg0KLSBTZXJ2ZXIgcmVsZWFzZXMgbGVhc2UgZm9yIG9taXR0ZWQgYWRk cmVzcyBpbiBSRU5FVyBtZXNzYWdlIGFuZCByZWZyZXNoZXMgdXBkYXRlX3RpbWUgb2YgYmluZGlu ZyBpbmNsdWRpbmcgb25seSB0aGUgYWRkcmVzcyBpbiBSRU5FVyBtZXNzYWdlIGZyb20gY2xpZW50 LiBTZXJ2ZXIgbWF5IGluY2x1ZGUgSUFfTkEgYWRkcmVzcyBvcHRpb24gZm9yIHRoZSByZWxlYXNl ZCBhZGRyZXNzIHdpdGggbGlmZXRpbWVzIHNldCB0byB6ZXJvLg0KLSBTZXJ2ZXIga2VlcHMgbGVh c2UgZm9yIG9taXR0ZWQgYWRkcmVzcyBpbiBSRU5FVyBtZXNzYWdlIGR1cmluZyBpdHMgdmFsaWQg bGlmZSB0aW1lIGFuZCByZWZyZXNoZXMgdXBkYXRlX3RpbWUgb2YgYmluZGluZyBpbmNsdWRpbmcg b25seSB0aGUgYWRkcmVzcyBpbiBSRU5FVyBtZXNzYWdlIGZyb20gY2xpZW50Lg0KDQpBbnkgYWR2 aWNlZXMgYW5kIGNvbW1lbnRzIGFyZSB3ZWxjb21lZC4NCg0KVGhhbmsgeW91IGluIGFkdmFuY2Uu IA0KDQpKb3NlcGggSHl1bldvb2sgQ2hhDQoNCiJGb3IgeW91LCBPIEdvZCwgdGVzdGVkIHVzOyB5 b3UgcmVmaW5lZCB1cyBsaWtlIHNpbHZlci4iDQoNClNvZnR3YXJlIEVuZ2luZWVyIA0KRGV2ZWxv cG1lbnQgUGFydCAxLiBJL0luZnJhICANCk5ldHdvcmsgU3lzdGVtIERpdmlzaW9uIA0KVGVsIDAz MS0yNzktMzgwNCAgTW9iaWxlIDAxMC0zMDI0LTM4MDQNCg0KDQoNCg0KDQoNCg0K --===============0990312331== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --===============0990312331==-- From dhcwg-bounces@ietf.org Mon Apr 30 02:12:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiP7X-00032M-57; Mon, 30 Apr 2007 02:12:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiP7V-00032B-D1 for dhcwg@ietf.org; Mon, 30 Apr 2007 02:12:21 -0400 Received: from mail153.messagelabs.com ([216.82.253.51]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HiP7U-0007e5-12 for dhcwg@ietf.org; Mon, 30 Apr 2007 02:12:21 -0400 X-VirusChecked: Checked X-Env-Sender: Q4997C@motorola.com X-Msg-Ref: server-6.tower-153.messagelabs.com!1177913538!1778188!1 X-StarScan-Version: 5.5.10.7.1; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 19402 invoked from network); 30 Apr 2007 06:12:18 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-6.tower-153.messagelabs.com with SMTP; 30 Apr 2007 06:12:18 -0000 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l3U6CIoe029584 for ; Sun, 29 Apr 2007 23:12:18 -0700 (MST) Received: from il06vts01.mot.com (il06vts01.mot.com [129.188.137.141]) by il06exr03.mot.com (8.13.1/Vontu) with SMTP id l3U6CIk6015348 for ; Mon, 30 Apr 2007 01:12:18 -0500 (CDT) Received: from ZMY16EXM66.ds.mot.com (zmy16exm66.ap.mot.com [10.179.4.26]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id l3U6CG9L015318 for ; Mon, 30 Apr 2007 01:12:17 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 30 Apr 2007 14:10:29 +0800 Message-ID: <750BBC72E178114F9DC4872EBFF29A5B0415B33B@ZMY16EXM66.ds.mot.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Dimensioning of DHCP Server Thread-Index: AceK7kDcpWhNB+f7RB6uk4y56Ey8nw== From: "Aggarwal Vivek-Q4997C" To: X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 Subject: [dhcwg] Dimensioning of DHCP Server X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0444553921==" Errors-To: dhcwg-bounces@ietf.org This is a multi-part message in MIME format. --===============0444553921== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C78AEE.8019A8C2" This is a multi-part message in MIME format. ------_=_NextPart_001_01C78AEE.8019A8C2 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello All =20 Can anyone please tell me that what should be the Hardware of DHCP Sever for 10 k subscribers in terms of CPU, Memory and RAM =20 We are planning to use sun 8000 Modular Blade Server Chassis. If anyone can tell what should be th size of hardisk for handling 10 K subs =20 Rgds Vivek Aggarwal +919945505704 ------_=_NextPart_001_01C78AEE.8019A8C2 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello All

 

Can anyone please tell me that what should be the = Hardware of DHCP Sever for 10 k subscribers in terms of CPU, Memory and = RAM

 

We are planning to use sun 8000 Modular Blade Server = Chassis. If anyone can tell what should be th size of hardisk for handling 10 K = subs

 

Rgds

Vivek Aggarwal

+919945505704

------_=_NextPart_001_01C78AEE.8019A8C2-- --===============0444553921== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --===============0444553921==-- From dhcwg-bounces@ietf.org Mon Apr 30 02:57:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiPp1-0000I0-3I; Mon, 30 Apr 2007 02:57:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiPoz-0000HP-95 for dhcwg@ietf.org; Mon, 30 Apr 2007 02:57:17 -0400 Received: from mail153.messagelabs.com ([216.82.253.51]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HiPoy-0000sH-FT for dhcwg@ietf.org; Mon, 30 Apr 2007 02:57:17 -0400 X-VirusChecked: Checked X-Env-Sender: Q4997C@motorola.com X-Msg-Ref: server-2.tower-153.messagelabs.com!1177916234!4506354!1 X-StarScan-Version: 5.5.10.7.1; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 17615 invoked from network); 30 Apr 2007 06:57:14 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-2.tower-153.messagelabs.com with SMTP; 30 Apr 2007 06:57:14 -0000 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l3U6vEi2008979 for ; Sun, 29 Apr 2007 23:57:14 -0700 (MST) Received: from il06vts03.mot.com (il06vts03.mot.com [129.188.137.143]) by il06exr04.mot.com (8.13.1/Vontu) with SMTP id l3U6vEpv018061 for ; Mon, 30 Apr 2007 01:57:14 -0500 (CDT) Received: from ZMY16EXM66.ds.mot.com (zmy16exm66.ap.mot.com [10.179.4.26]) by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id l3U6vCOG018049 for ; Mon, 30 Apr 2007 01:57:13 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [dhcwg] A question about dimensioning DHCP Server Date: Mon, 30 Apr 2007 14:56:29 +0800 Message-ID: <750BBC72E178114F9DC4872EBFF29A5B0415B38C@ZMY16EXM66.ds.mot.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dhcwg] A question about dimensioning DHCP Server Thread-Index: AceKwPBpvsR7I46VSJKUqwpkC2pAkwAG9yAgAAODPkAAAkTCEA== From: "Aggarwal Vivek-Q4997C" To: , "Ram O V Vishnu-A14676" X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: c3d1fcc6feccbcc611b6c309986f05f7 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: , Content-Type: multipart/mixed; boundary="===============1610379322==" Errors-To: dhcwg-bounces@ietf.org This is a multi-part message in MIME format. --===============1610379322== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C78AF4.C700616B" This is a multi-part message in MIME format. ------_=_NextPart_001_01C78AF4.C700616B Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi First of all thanks for lightening reply =20 Yaa we are using ISC Server, so is it possible to have Load balancing scenario? =20 Secondly my main concern is for 10 K subscribers what hardware ( Hardisk + RAM) I should use for DHCP Servers? =20 Rgds Vivek Aggarwal =20 ________________________________ From: Ram O V Vishnu-A14676=20 Sent: Monday, April 30, 2007 11:46 AM To: Aggarwal Vivek-Q4997C Subject: RE: [dhcwg] A question about dimensioning DHCP Server =20 Vivek, =20 I work for the IPTG team in MIEL. I have some answers based on my work with HSDPA & WiBB system last year. =20 Regards, Vishnu. Motorola +91 9844178052 [] General [*] Motorola Internal Use Only -----Original Message----- From: Aggarwal Vivek-Q4997C=20 Sent: Monday, April 30, 2007 9:43 AM To: dhcwg@ietf.org Subject: [dhcwg] A question about dimensioning DHCP Server Hello All =20 I have some questions regarding the dimensioning of DHCP server =20 Can anyone please respond my below question? =20 1. What are the dimensioning criteria for DHCP Server?=20 >> Total number of DHCP requests that the Server is able to handle in a sec. >> number of successful renewals. >> address reallocations. >> size of the address pool >> delay : including the time to check for availability of network address. >> time to read or write configuration database. >> security issues. =20 2. How many subscribers the Sun 8000 Modular Blade Sever Chassis with about 150 Gb of Hardisk can handle?=20 >> you mean - how many simulaneous active leases? or active + non-active subscribers? Basically - is the question on hard-disk space consumption or RAM space?=20 =20 3. How can we configure DHCP Servers to work in Load Balancing Scenario?=20 >> depends on the DHCP server which you are using. Are using ISC server?=20 =20 Looking forward for a early reply =20 Rgds Vivek Aggarwal Motorola India Network Engineer Bangalore,India M- +919945505704 ------_=_NextPart_001_01C78AF4.C700616B Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message

Hi

First of all thanks for lightening = reply

 

Yaa we are using ISC Server, so is = it possible to have Load balancing scenario?

 

Secondly my main concern is for 10 = K subscribers what hardware ( Hardisk + RAM) I should use for DHCP = Servers?

 

Rgds

Vivek = Aggarwal

 

From: Ram O = V Vishnu-A14676
Sent: Monday, April 30, = 2007 11:46 AM
To: Aggarwal = Vivek-Q4997C
Subject: RE: [dhcwg] A = question about dimensioning DHCP Server

 

Vivek,

 

I work for the IPTG team in = MIEL.

I have some answers based on my = work with HSDPA & WiBB system last year.

 

Regards,
Vishnu.

Motorola
+91 9844178052
[] General
[*] Motorola Internal Use Only

-----Original = Message-----
From: Aggarwal = Vivek-Q4997C
Sent: Monday, April 30, = 2007 9:43 AM
To: dhcwg@ietf.org
Subject: [dhcwg] A = question about dimensioning DHCP Server

Hello All

 

I have some questions regarding = the dimensioning of DHCP server

 

Can anyone please respond my = below question?

 

1.       What are = the dimensioning criteria for DHCP Server? 

>>  Total number of DHCP requests that the = Server is able to handle in a sec.

>> number of successful = renewals.

>> address = reallocations.

>> size of the address = pool

>> delay : including the time to check for = availability of network address.

>> time to read or write configuration = database.

>> security issues.

 

2.       How many = subscribers the Sun 8000 Modular Blade Sever Chassis with about 150 Gb of Hardisk = can handle? 

>> you mean - how many simulaneous active leases? or = active + non-active subscribers? Basically - is the question on hard-disk space consumption or RAM space? 

 

3.       How can we = configure DHCP Servers to work in Load Balancing Scenario? 

>> depends on the DHCP server which you = are using. Are using ISC server? 

 

Looking forward for a early = reply

 

Rgds

Vivek = Aggarwal

Motorola India

Network = Engineer

Bangalore= ,India

M- = +919945505704

------_=_NextPart_001_01C78AF4.C700616B-- --===============1610379322== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --===============1610379322==-- From dhcwg-bounces@ietf.org Mon Apr 30 09:09:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiVdR-0002gJ-PO; Mon, 30 Apr 2007 09:09:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiVdQ-0002gE-QS for dhcwg@ietf.org; Mon, 30 Apr 2007 09:09:44 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HiVdQ-0002Fi-Dx for dhcwg@ietf.org; Mon, 30 Apr 2007 09:09:44 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 30 Apr 2007 09:09:44 -0400 X-IronPort-AV: i="4.14,471,1170651600"; d="scan'208"; a="58995345:sNHT89036672" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l3UD9ikW021691; Mon, 30 Apr 2007 09:09:44 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l3UCxZlk003741; Mon, 30 Apr 2007 13:09:39 GMT Received: from xmb-rtp-20a.amer.cisco.com ([64.102.31.15]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Apr 2007 09:09:26 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: quoted-printable Subject: RE: RE: RE: [dhcwg] A question about processing a RENEW message from a clientin DHCPv6. Date: Mon, 30 Apr 2007 09:09:31 -0400 Message-ID: <8E296595B6471A4689555D5D725EBB2103EAB31A@xmb-rtp-20a.amer.cisco.com> In-Reply-To: <8089192.68821177906590686.JavaMail.weblogic@ep_ml29> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RE: RE: [dhcwg] A question about processing a RENEW message from a clientin DHCPv6. Thread-Index: AceK5rFvNs0YiQLHRlWeqz5x8166uQAQakFg From: "Bernie Volz \(volz\)" To: X-OriginalArrivalTime: 30 Apr 2007 13:09:26.0912 (UTC) FILETIME=[C7B97000:01C78B28] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=6964; t=1177938584; x=1178802584; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=volz@cisco.com; z=From:=20=22Bernie=20Volz=20\(volz\)=22=20 |Subject:=20RE=3A=20RE=3A=20RE=3A=20[dhcwg]=20A=20question=20about=20proc essing=20a=20RENEW=20message=20from=20a=20clientin=20DHCPv6. |Sender:=20 |To:=20; bh=rXE2zqnvchSEbh9olD5eFHfqrLI3EAeqSRUXX5Ah9HM=; b=eWDSR7Ck3tL86TTl/gmhB0oG4vaATVbhP8N9bUMPgdAcVAjhQ3YBSooXiyYLWkq54NNrNrIA JNz+5YXsG1SIvWBMdZSIf7Vq2fsMWC69M7n7XFM3h0c2cbLPTaOOrd4A; Authentication-Results: rtp-dkim-1; header.From=volz@cisco.com; dkim=pass (s ig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: f2984bf50fb52a9e56055f779793d783 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: , Errors-To: dhcwg-bounces@ietf.org That's precisely why I would renew the lifetimes of address B even if = the client didn't request it (provided of course that your server's = policy allows it). The client and server are supposed to treat all of the addresses in a = binding (IA_* and IAID) as a group, not individually, in most = transactions. - Bernie=20 -----Original Message----- From: =C2=F7=C7=F6=BF=ED [mailto:hyunwook.cha@samsung.com]=20 Sent: Monday, April 30, 2007 12:17 AM To: Bernie Volz (volz) Cc: dhcwg@ietf.org Subject: Re: RE: RE: [dhcwg] A question about processing a RENEW message = from a clientin DHCPv6. Dear, Bernie. Thank you so much for your kind clarification. I also have one more question.=20 My assumption is that address A(preferred lifetime =3D 100s), address B = (preferred lifetime=3D 100s) are assigned to the client. So, T1, T2 in REPLY message are 50s, 80s repectively. For any reason, the client wants to renew only address A and sends RENEW = including IA_Addr option for only address A after 50 seconds. When server receives RENEW, it refreshes lifetime of address A, Then, = address B has 50 seconds left as preferred lifetime.=20 Then, server send REPLY with IA_NA opion including IA_Addr options for = address A and B. At this time, T1, T2 values are 25s, 40s.=20 As before, client send RENEW for only address A after 25 seconds. Then, = server refreshes lifetime of address A. So, address B has 25 seconds = left as preferred lifetime. In this way, it seems that many iterations = are possible, so RENEW/REPLY exchanges can happen very frequently, which = is not desirable.=20 If I misunderstood, please correct me. Thank you in advance. Joseph HyunWook Cha "For you, O God, tested us; you refined us like silver." Software Engineer=20 Development Part 1. I/Infra =20 Network System Division=20 Tel 031-279-3804 Mobile 010-3024-3804 ------- Original Message ------- Sender : Bernie Volz (volz)=20 Date : 2007-04-30 11:26 Title : RE: RE: [dhcwg] A question about processing a RENEW message = from a clientin DHCPv6. Obviously the server sent these addresses to the client previously in a = Reply. Otherwise, why it would it have them? And, the server still has the leases (ie, we assume the valid lifetime = has not expired). And if there are no server policies that conflict with = them being used and renewed, what's wrong with the server renewing them = and sending them to the client? The worst is that the client will ignore them like it did previously. = Or, if the client have previously RELEASED or DECLINED them, it should = do so now and perhaps those messages will get to the server (the client = is not required to keep retrying RELEASE and DECLINE messages so it = could be that the previous attempt failed to reach the server); which is = a plus as then the server knows that the client doesn't want to use = those leases or can't use them because of conflicts. Note also that the RFC 3315 langague you quoted does not include a MUST. = And, also note the language in 18.1.8. Receipt of Reply Messages which = clearly indicates that a server may return additional addresses for a = Request, Renew, or Rebind. - Bernie -----Original Message----- From: =C2=F7=C7=F6=BF=ED [mailto:hyunwook.cha@samsung.com]=20 Sent: Sunday, April 29, 2007 10:11 PM To: Bernie Volz (volz); dhcwg@ietf.org Subject: Fwd: RE: [dhcwg] A question about processing a RENEW message = from a clientin DHCPv6. Dear, Bernie. Thank you for your comment. You mean that clinet do not have to include all addresses mapped to = IA_NA in RENEW to extend lifetime of IA_NA binding in server.=20 According to RFC3315 18.1.3. Creation and Transmission of Renew = Messages,=20 "At time T1 for an IA, the client initiates a Renew/Reply message exchange to extend the lifetimes on any addresses in the IA. The client includes an IA option with all addresses currently assigned to the IA in its Renew message. " I can not agree with you.=20 If client determines to use only one of addresses provided by server or = knows that any address is not on-link from RA, it will not send RENEW = message including all addresses associated to IA_NA in server. For this = case, server should not refresh all addresses in the IA but just = addreses in RENEW. I have only little knowledge about DHCPv6. If I am wrong, please correct = me.=20 Regards, Joseph HyunWook Cha "For you, O God, tested us; you refined us like silver." Software Engineer=20 Development Part 1. I/Infra =20 Network System Division=20 Tel 031-279-3804 Mobile 010-3024-3804 ------- Original Message ------- Sender : Bernie Volz (volz)=20 Date : 2007-04-30 09:58 Title : RE: [dhcwg] A question about processing a RENEW message from a clientin DHCPv6. How about the server includes the address as if it was in the Renew? If a client sends just a Renew with anIA option but without any IAADDR = options, why wouldn't you just renew all addresses for the binding (IA_* = and IAID) and include them in the Reply? (Of course, addresses that = can't be renewed would be sent with whatever remaining lifetimes they = have.) - Bernie=20 -----Original Message----- From: =C2=F7=C7=F6=BF=ED [mailto:hyunwook.cha@samsung.com]=20 Sent: Sunday, April 29, 2007 8:46 PM To: dhcwg@ietf.org Subject: [dhcwg] A question about processing a RENEW message from a = clientin DHCPv6. Dear, all. I am now developing DHCPv6 client and server in our product. I have a question reading source code of a open source package "Wide = DHCPv6". In this software, it does update update_time of binding assigned to = client without checking if all assinged stateful addresses for same IA = are included in RENEW message from client.=20 If server assigned two addresses to IA requested by client and client = send RENEW message for only one address, what is correct behavior of = server? Right before, I checked DHCPv6 conformance testsuit document by the = TAHI. But I do not find exact answer.=20 In my opinion, several choices are possible.=20 - Server rejects RENEW message. - Server releases lease for omitted address in RENEW message and = refreshes update_time of binding including only the address in RENEW = message from client. Server may include IA_NA address option for the = released address with lifetimes set to zero. - Server keeps lease for omitted address in RENEW message during its = valid life time and refreshes update_time of binding including only the = address in RENEW message from client. Any advicees and comments are welcomed. Thank you in advance.=20 Joseph HyunWook Cha "For you, O God, tested us; you refined us like silver." Software Engineer=20 Development Part 1. I/Infra =20 Network System Division=20 Tel 031-279-3804 Mobile 010-3024-3804 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon Apr 30 11:07:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiXTm-00013Q-1o; Mon, 30 Apr 2007 11:07:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiXTl-00013L-Bk for dhcwg@ietf.org; Mon, 30 Apr 2007 11:07:53 -0400 Received: from the.hankinsfamily.info ([204.152.186.148] helo=hankinsfamily.info) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HiXTj-0006Jn-VM for dhcwg@ietf.org; Mon, 30 Apr 2007 11:07:53 -0400 Received: from navarre.mercenary.net (c-76-102-106-124.hsd1.ca.comcast.net [76.102.106.124]) (authenticated bits=0) by hankinsfamily.info (8.13.8/8.13.8) with ESMTP id l3UF7oBg000418 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 30 Apr 2007 08:07:50 -0700 Received: by navarre.mercenary.net (Postfix, from userid 1000) id 1AA9C19F22; Mon, 30 Apr 2007 08:28:23 -0700 (PDT) Date: Mon, 30 Apr 2007 08:28:23 -0700 From: "David W. Hankins" To: Aggarwal Vivek-Q4997C Subject: Re: [dhcwg] Dimensioning of DHCP Server Message-ID: <20070430152822.GB5276@isc.org> References: <750BBC72E178114F9DC4872EBFF29A5B0415B33B@ZMY16EXM66.ds.mot.com> Mime-Version: 1.0 In-Reply-To: <750BBC72E178114F9DC4872EBFF29A5B0415B33B@ZMY16EXM66.ds.mot.com> User-Agent: Mutt/1.5.9i X-Spam-Score: 0.1 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 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="===============0693574026==" Errors-To: dhcwg-bounces@ietf.org --===============0693574026== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="A6N2fC+uXW/VQSAv" Content-Disposition: inline --A6N2fC+uXW/VQSAv Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Apr 30, 2007 at 02:10:29PM +0800, Aggarwal Vivek-Q4997C wrote: > Can anyone please tell me that what should be the Hardware of DHCP Sever > for 10 k subscribers in terms of CPU, Memory and RAM The DHC WG mailing list isn't an appropriate place to ask that question. You've reached a group of people who talk about protocol improvements or clarifications/changes. If your DHCP software vendor has a mailing list, or lists an email or telephone contact (such as a support line), that would be a better place to ask. To get you a head start down that road, one of the things your vendor is going to want to hear is what lease times you will be giving to subscribers. This governs a (usually) major source of DHCP packet activity; renewals. Best of luck. --=20 David W. Hankins "If you don't do it right the first time, Software Engineer you'll just have to do it again." Internet Systems Consortium, Inc. -- Jack T. Hankins --A6N2fC+uXW/VQSAv Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFGNgsWcXeLeWu2vmoRAkuzAJ9txhMevFPnyAAjW593pt94H3eRHQCeKfOW VdH8+WSG9SPrD8RXGoaUvqs= =J2cn -----END PGP SIGNATURE----- --A6N2fC+uXW/VQSAv-- --===============0693574026== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --===============0693574026==-- From dhcwg-bounces@ietf.org Mon Apr 30 11:18:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiXdh-00073J-9D; Mon, 30 Apr 2007 11:18:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiXdg-0006yN-Dh for dhcwg@ietf.org; Mon, 30 Apr 2007 11:18:08 -0400 Received: from web84102.mail.mud.yahoo.com ([68.142.206.189]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HiXde-0007p3-VU for dhcwg@ietf.org; Mon, 30 Apr 2007 11:18:08 -0400 Received: (qmail 22945 invoked by uid 60001); 30 Apr 2007 15:18:06 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=YceFPxpfceuX40zvEjIJ34wHW4cYGzP76NC7jG1xqJ9HBJMz3KbcJzsUZZscerAjJChfQoCBar8xQpbFDO7ZmhSzqM/EY/vOZfrPvzSTHv8Gxm3bK5QKZnJt2p5voUzFMuYa30XhQw82ta7kWNOgpj7Sfw3BjC1AeJ7FpF2xb34=; X-YMail-OSG: 1O_AEoQVM1nmz43HWZi1dFIVClkF7ZSkXrGc4Ce_aWxcI37dWEPfoRLbbSz4CnmcPxaUultHJNou57PxFGT9bjZHKJM8QhvP4_l6HrkEqNNoBbEOIU4- Received: from [206.16.17.212] by web84102.mail.mud.yahoo.com via HTTP; Mon, 30 Apr 2007 08:18:06 PDT X-Mailer: YahooMailRC/478 YahooMailWebService/0.7.41.10 Date: Mon, 30 Apr 2007 08:18:06 -0700 (PDT) From: Behcet Sarikaya Subject: Re: [dhcwg] Identifying DHCP issues in Internet Drafts To: Ralph Droms MIME-Version: 1.0 Message-ID: <88254.22080.qm@web84102.mail.mud.yahoo.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: DHC WG X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Behcet Sarikaya List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2047021796==" Errors-To: dhcwg-bounces@ietf.org --===============2047021796== Content-Type: multipart/alternative; boundary="0-1763961502-1177946286=:22080" --0-1763961502-1177946286=:22080 Content-Type: text/plain; charset=ascii Hi Ralph, Yes, I think our draft: http://tools.ietf.org/wg/16ng/draft-sarikaya-16ng-prefix-delegation-01.txt is one of them. I don't know if it was among 90 drafts you identified. Appreciate your review. Regards, Behcet ----- Original Message ---- From: Ralph Droms To: DHC WG Sent: Wednesday, April 25, 2007 4:14:23 PM Subject: [dhcwg] Identifying DHCP issues in Internet Drafts Stig and I need to find some volunteers for a one-time review of Internet Drafts. We're trying to identify drafts that have DHCP-related issues that may require dhc WG collaboration. We'd like to identify these issues as early as possible, before the drafts get out of their WGs. There are roughly 90 drafts in other WGs that were found in a search for "DHCP". I imagine most of those drafts simply mention DHCP. What we're looking for is drafts that will need a new DHCP option, some other extension to the DHCP specifications, or might be proposing to use DHCP in a way that needs to be dicussed by the dhc WG. Stig and I want to find 8 or 9 volunteers who would each be willing to review about 10 drafts. Please respond to if you'd be willing to help us out with this project. Thanks... - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --0-1763961502-1177946286=:22080 Content-Type: text/html; charset=ascii
Hi Ralph,
  Yes, I think our draft:
is one of them. I don't know if it was among 90 drafts you identified.
 
Appreciate your review.
 
Regards,
 
Behcet

----- Original Message ----
From: Ralph Droms <rdroms@cisco.com>
To: DHC WG <dhcwg@ietf.org>
Sent: Wednesday, April 25, 2007 4:14:23 PM
Subject: [dhcwg] Identifying DHCP issues in Internet Drafts

Stig and I need to find some volunteers for a one-time review of Internet
Drafts.  We're trying to identify drafts that have DHCP-related issues that
may require dhc WG collaboration.  We'd like to identify these issues as
early as possible, before the drafts get out of their WGs.

There are roughly 90 drafts in other WGs that were found in a search for
"DHCP".  I imagine most of those drafts simply mention DHCP.  What we're
looking for is drafts that will need a new DHCP option, some other extension
to the DHCP specifications, or might be proposing to use DHCP in a way that
needs to be dicussed by the dhc WG.

Stig and I want to find 8 or 9 volunteers who would each be willing to
review about 10 drafts.  Please respond to <dhc-chairs@tools.ietf.org> if
you'd be willing to help us out with this project.

Thanks...

- Ralph


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

--0-1763961502-1177946286=:22080-- --===============2047021796== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --===============2047021796==-- From dhcwg-bounces@ietf.org Mon Apr 30 11:34:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiXtP-0006na-78; Mon, 30 Apr 2007 11:34:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiXtN-0006nV-Vb for dhcwg@ietf.org; Mon, 30 Apr 2007 11:34:21 -0400 Received: from the.hankinsfamily.info ([204.152.186.148] helo=hankinsfamily.info) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HiXtN-0001Dx-JQ for dhcwg@ietf.org; Mon, 30 Apr 2007 11:34:21 -0400 Received: from navarre.mercenary.net (c-76-102-106-124.hsd1.ca.comcast.net [76.102.106.124]) (authenticated bits=0) by hankinsfamily.info (8.13.8/8.13.8) with ESMTP id l3UFYKJb000609 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 30 Apr 2007 08:34:20 -0700 Received: by navarre.mercenary.net (Postfix, from userid 1000) id 7EA1D19F22; Mon, 30 Apr 2007 08:54:53 -0700 (PDT) Date: Mon, 30 Apr 2007 08:54:53 -0700 From: "David W. Hankins" To: dhcwg@ietf.org Subject: Re: RE: [dhcwg] A question about processing a RENEW message from a clientin DHCPv6. Message-ID: <20070430155453.GD5276@isc.org> References: <13816756.73221177899046443.JavaMail.weblogic@ep_ml19> <8E296595B6471A4689555D5D725EBB2103EAB289@xmb-rtp-20a.amer.cisco.com> Mime-Version: 1.0 In-Reply-To: <8E296595B6471A4689555D5D725EBB2103EAB289@xmb-rtp-20a.amer.cisco.com> User-Agent: Mutt/1.5.9i X-Spam-Score: 0.1 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: hyunwook.cha@samsung.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: , Content-Type: multipart/mixed; boundary="===============1490080666==" Errors-To: dhcwg-bounces@ietf.org --===============1490080666== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Ycz6tD7Th1CMF4v7" Content-Disposition: inline --Ycz6tD7Th1CMF4v7 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Apr 29, 2007 at 10:26:18PM -0400, Bernie Volz (volz) wrote: > And, the server still has the leases (ie, we assume the valid lifetime ha= s not expired). And if there are no server policies that conflict with them= being used and renewed, what's wrong with the server renewing them and sen= ding them to the client? >=20 > The worst is that the client will ignore them like it did previously. If we get into a situation where the DHCP server is sending addresses the client is ignoring, then DDNS updates get a lot less reliable. > Note also that the RFC 3315 langague you quoted does not include a MUST. = And, also note the language in 18.1.8. Receipt of Reply Messages which clea= rly indicates that a server may return additional addresses for a Request, = Renew, or Rebind. I don't like this answer. If a client releases an address it "doesn't want" for whatever reason, then the server will offer more addresses in the next exchange which it probably "doesn't want" either. This quickly looks like an infinite loop. The real answer I think is that a client has no choice in the matter, and "MUST" bind and keep all addresses the server gives. So if you want a client to move off an address, that decision can only be made at the server. > -----Original Message----- > From: =EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD [mailto:hyun= wook.cha@samsung.com]=20 > Sent: Sunday, April 29, 2007 10:11 PM > To: Bernie Volz (volz); dhcwg@ietf.org > Subject: Fwd: RE: [dhcwg] A question about processing a RENEW message fro= m a clientin DHCPv6. >=20 > If client determines to use only one of addresses provided by server or k= nows that any address is not on-link from RA, I think it would be a mistake not to use an address that is given by the server and is not covered by a prefix announcement in any RA. It's been stipulated that there may exist networks in which there are no routers, at least no route advertisements, and where link-local addresses may be insufficient. If the DHCP server is renewing invalid addresses, then that is a misconfiguration. --=20 David W. Hankins "If you don't do it right the first time, Software Engineer you'll just have to do it again." Internet Systems Consortium, Inc. -- Jack T. Hankins --Ycz6tD7Th1CMF4v7 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFGNhFNcXeLeWu2vmoRAlLTAJ0SppbV7fiddopVufwh9DNBq7QumQCfdHRH UMWJSZzlN9ioKZQcRoeVgVk= =olv5 -----END PGP SIGNATURE----- --Ycz6tD7Th1CMF4v7-- --===============1490080666== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --===============1490080666==-- From dhcwg-bounces@ietf.org Mon Apr 30 11:37:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiXw2-0007zo-1b; Mon, 30 Apr 2007 11:37:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiXw0-0007zj-F3 for dhcwg@ietf.org; Mon, 30 Apr 2007 11:37:04 -0400 Received: from the.hankinsfamily.info ([204.152.186.148] helo=hankinsfamily.info) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HiXvy-0001SJ-3K for dhcwg@ietf.org; Mon, 30 Apr 2007 11:37:04 -0400 Received: from navarre.mercenary.net (c-76-102-106-124.hsd1.ca.comcast.net [76.102.106.124]) (authenticated bits=0) by hankinsfamily.info (8.13.8/8.13.8) with ESMTP id l3UFb1lk000633 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 30 Apr 2007 08:37:01 -0700 Received: by navarre.mercenary.net (Postfix, from userid 1000) id 5F56EDFE9; Mon, 30 Apr 2007 08:57:34 -0700 (PDT) Date: Mon, 30 Apr 2007 08:57:34 -0700 From: "David W. Hankins" To: Aggarwal Vivek-Q4997C Subject: Re: [dhcwg] A question about dimensioning DHCP Server Message-ID: <20070430155734.GE5276@isc.org> References: <750BBC72E178114F9DC4872EBFF29A5B0415B38C@ZMY16EXM66.ds.mot.com> Mime-Version: 1.0 In-Reply-To: <750BBC72E178114F9DC4872EBFF29A5B0415B38C@ZMY16EXM66.ds.mot.com> User-Agent: Mutt/1.5.9i X-Spam-Score: 0.1 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: dhcwg@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1076856830==" Errors-To: dhcwg-bounces@ietf.org --===============1076856830== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="HnQK338I3UIa/qiP" Content-Disposition: inline --HnQK338I3UIa/qiP Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Apr 30, 2007 at 02:56:29PM +0800, Aggarwal Vivek-Q4997C wrote: > Yaa we are using ISC Server, so is it possible to have Load balancing > scenario? Yes. Please ask these questions on dhcp-users@isc.org. http://www.isc.org/sw/dhcp/dhcp-lists.php --=20 David W. Hankins "If you don't do it right the first time, Software Engineer you'll just have to do it again." Internet Systems Consortium, Inc. -- Jack T. Hankins --HnQK338I3UIa/qiP Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFGNhHucXeLeWu2vmoRAhI5AJ4wB5anSJ7ZgEluQgwwPn5Gq/Hp2gCdHEl7 VoAqXuSeBxOLOto12E2K5K0= =ycgB -----END PGP SIGNATURE----- --HnQK338I3UIa/qiP-- --===============1076856830== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --===============1076856830==-- From dhcwg-bounces@ietf.org Mon Apr 30 11:37:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiXw8-00089D-9z; Mon, 30 Apr 2007 11:37:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiXw7-000897-8M for dhcwg@ietf.org; Mon, 30 Apr 2007 11:37:11 -0400 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HiXw3-0001ST-Va for dhcwg@ietf.org; Mon, 30 Apr 2007 11:37:11 -0400 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id E75C119868F; Mon, 30 Apr 2007 18:37:06 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id DE79219868C; Mon, 30 Apr 2007 18:36:53 +0300 (EEST) Message-ID: <46360D14.8010404@piuha.net> Date: Mon, 30 Apr 2007 18:36:52 +0300 From: Jari Arkko User-Agent: Thunderbird 1.5.0.10 (X11/20070306) MIME-Version: 1.0 To: Mark Stapp References: <200703071423.l27ENvSI026953@cichlid> <45F5C1A8.6090208@cisco.com> <200703131251.l2DCphXs003398@cichlid.raleigh.ibm.com> In-Reply-To: <200703131251.l2DCphXs003398@cichlid.raleigh.ibm.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Cc: Thomas Narten , Dhcwg , dhc-chairs@tools.ietf.org Subject: [dhcwg] Status of draft-ietf-dhc-relay-agent-flags-02.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: , Errors-To: dhcwg-bounces@ietf.org I have made my AD review of this specification. I saw no issues, but I would the authors to prepare a new version in response to Thomas Narten's comments before we go to IETF Last Call. Jari _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon Apr 30 11:56:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiYEV-0002Ih-Jj; Mon, 30 Apr 2007 11:56:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiYEU-0002GR-Ew for dhcwg@ietf.org; Mon, 30 Apr 2007 11:56:10 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HiYET-0004AS-65 for dhcwg@ietf.org; Mon, 30 Apr 2007 11:56:10 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 30 Apr 2007 11:56:09 -0400 X-IronPort-AV: i="4.14,471,1170651600"; d="scan'208"; a="59014804:sNHT46052076" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l3UFu8N7003499; Mon, 30 Apr 2007 11:56:08 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l3UFu8lG026315; Mon, 30 Apr 2007 15:56:08 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Apr 2007 11:56:08 -0400 Received: from [161.44.112.167] ([161.44.112.167]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Apr 2007 11:56:07 -0400 Message-ID: <46361197.7030405@cisco.com> Date: Mon, 30 Apr 2007 11:56:07 -0400 From: Mark Stapp User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Jari Arkko References: <200703071423.l27ENvSI026953@cichlid> <45F5C1A8.6090208@cisco.com> <200703131251.l2DCphXs003398@cichlid.raleigh.ibm.com> <46360D14.8010404@piuha.net> In-Reply-To: <46360D14.8010404@piuha.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 Apr 2007 15:56:07.0754 (UTC) FILETIME=[10B0D2A0:01C78B40] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=373; t=1177948568; x=1178812568; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mjs@cisco.com; z=From:=20Mark=20Stapp=20 |Subject:=20Re=3A=20Status=20of=20draft-ietf-dhc-relay-agent-flags-02.txt |Sender:=20 |To:=20Jari=20Arkko=20; bh=i8OPKqSmD/Uib1CD8GE0AwHApo+4n47r2x5JAxMkt9E=; b=E/H5RIR+FX+V4KhZSXY0wXrX//rZMWvya9sS5TLTNEcR/gglbIMUFrTm8iexjasspPAUhCBF sKshhoMZrSFEPy6gGiEtiq7inCelw20jsDvDJd/wrliDh1V2G0gHxxfJ; Authentication-Results: rtp-dkim-2; header.From=mjs@cisco.com; dkim=pass (si g from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: Thomas Narten , Dhcwg , dhc-chairs@tools.ietf.org Subject: [dhcwg] Re: Status of draft-ietf-dhc-relay-agent-flags-02.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: , Errors-To: dhcwg-bounces@ietf.org Jari, I've prepared a revised draft - just checking with the other authors to confirm they're ok with the changes. Thanks, Mark Jari Arkko wrote: > I have made my AD review of this specification. I saw > no issues, but I would the authors to prepare a new > version in response to Thomas Narten's comments > before we go to IETF Last Call. > > Jari > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon Apr 30 12:28:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiYjW-0005Y0-3C; Mon, 30 Apr 2007 12:28:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiYjV-0005Xv-5F for dhcwg@ietf.org; Mon, 30 Apr 2007 12:28:13 -0400 Received: from the.hankinsfamily.info ([204.152.186.148] helo=hankinsfamily.info) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HiYjS-0000jU-Ox for dhcwg@ietf.org; Mon, 30 Apr 2007 12:28:13 -0400 Received: from navarre.mercenary.net (c-76-102-106-124.hsd1.ca.comcast.net [76.102.106.124]) (authenticated bits=0) by hankinsfamily.info (8.13.8/8.13.8) with ESMTP id l3UGS7WP000891 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 30 Apr 2007 09:28:07 -0700 Received: by navarre.mercenary.net (Postfix, from userid 1000) id 5635319F22; Mon, 30 Apr 2007 09:48:41 -0700 (PDT) Date: Mon, 30 Apr 2007 09:48:41 -0700 From: "David W. Hankins" To: Thomas Narten Subject: Re: [dhcwg] Review of draft-ietf-dhc-relay-agent-flags-02.txt Message-ID: <20070430164841.GF5276@isc.org> References: <200703071423.l27ENvSI026953@cichlid> <45F5C1A8.6090208@cisco.com> <200703131244.l2DCiOl5000429@cichlid.raleigh.ibm.com> Mime-Version: 1.0 In-Reply-To: <200703131244.l2DCiOl5000429@cichlid.raleigh.ibm.com> User-Agent: Mutt/1.5.9i X-Spam-Score: 0.1 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da 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="===============0823444029==" Errors-To: dhcwg-bounces@ietf.org --===============0823444029== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="K/NRh952CO+2tg14" Content-Disposition: inline --K/NRh952CO+2tg14 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Mar 13, 2007 at 06:44:24AM -0600, Thomas Narten wrote: > I think they (and the IETF as a whole, as I don't think the IETF LC > has happened) will probably be able to evaluate it better with the > extra sentence (btw, what will it be?). "Such as determining which server in a cluster will respond to the client." Would be my pick. Simplest one. > Well, for one thing, the above text makes its sound like a protocol > violation to implement the spec, but choose not to send the option > (e.g., even if configured to do so for some reason). That seems a bit > strong to me. There is a compatibility matrix here. If both the SRSN and the flags option are present, then a server might choose to support the SRSN and copy its contents to the server-identifier option. If the SRSN is present, and the flags option isn't, then they might refuse to copy the contents over, which preserves the detection of RENEWING vs REBINDING even if the result is all RENEWs fail (due to filters or topology). If the flags option itself is present on its own, that's possibly useless...unless more flags are defined. So it depends what "compatibility" means. The middle scenario will "work" in all cases. In the scenario where SRSN is trying to bridge a unicast network gap, it will force clients to rebind rather than renew...their unicasts to the server will fail. Certainly, it will still work, but is that compatible? If we said yes, does this mean that any solution that sends clients through INIT to retain network connectivity is also compatible? --=20 David W. Hankins "If you don't do it right the first time, Software Engineer you'll just have to do it again." Internet Systems Consortium, Inc. -- Jack T. Hankins --K/NRh952CO+2tg14 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFGNh3pcXeLeWu2vmoRApsWAJ9qxgQqox37CT3Kz3wVZ1r9T9e8EgCgqKhV uIrXjwIAfHh7h8QZst9NA3c= =97Gi -----END PGP SIGNATURE----- --K/NRh952CO+2tg14-- --===============0823444029== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --===============0823444029==-- From dhcwg-bounces@ietf.org Mon Apr 30 12:40:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiYvq-0003Wy-3d; Mon, 30 Apr 2007 12:40:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiYvo-0003WK-Sc for dhcwg@ietf.org; Mon, 30 Apr 2007 12:40:56 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HiYvo-0002J3-GJ for dhcwg@ietf.org; Mon, 30 Apr 2007 12:40:56 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 30 Apr 2007 12:40:56 -0400 X-IronPort-AV: i="4.14,471,1170651600"; d="scan'208"; a="119895082:sNHT48817172" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l3UGeucM031737; Mon, 30 Apr 2007 12:40:56 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l3UGecHB022475; Mon, 30 Apr 2007 16:40:56 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Apr 2007 12:40:54 -0400 Received: from [161.44.65.228] ([161.44.65.228]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Apr 2007 12:40:54 -0400 Message-ID: <46361C14.7080104@cisco.com> Date: Mon, 30 Apr 2007 12:40:52 -0400 From: Mark Stapp User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: "David W. Hankins" Subject: Re: [dhcwg] Review of draft-ietf-dhc-relay-agent-flags-02.txt References: <200703071423.l27ENvSI026953@cichlid> <45F5C1A8.6090208@cisco.com> <200703131244.l2DCiOl5000429@cichlid.raleigh.ibm.com> <20070430164841.GF5276@isc.org> In-Reply-To: <20070430164841.GF5276@isc.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 Apr 2007 16:40:54.0143 (UTC) FILETIME=[51E740F0:01C78B46] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2193; t=1177951256; x=1178815256; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mjs@cisco.com; z=From:=20Mark=20Stapp=20 |Subject:=20Re=3A=20[dhcwg]=20Review=20of=20draft-ietf-dhc-relay-agent-fl ags-02.txt |Sender:=20 |To:=20=22David=20W.=20Hankins=22=20; bh=32B4F/Tuo3Sp9s3Ar+/EOBL24zZYTMoOUnghKVGb2hs=; b=UA37exAgx342DwlcQokfqMETjKVcds2IORtQb5rD4PTBNqcV0K600i2THN0P9N1hag5t/Mw0 UyAA2CDa80vW4kAx3AJWD7iXx5lYalot0R1Cmk0JxkoUIkQ7SOxK/Fe0; Authentication-Results: rtp-dkim-1; header.From=mjs@cisco.com; dkim=pass (si g from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: Thomas Narten , 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: , Errors-To: dhcwg-bounces@ietf.org David, unless I read Thomas's emails wrong, he wasn't really trying to point out some subtle state-machine issue. he was just talking about a MUST terminology issue that he'd like clarified. I think it's just a text change ... coming soon ... -- Mark David W. Hankins wrote: > On Tue, Mar 13, 2007 at 06:44:24AM -0600, Thomas Narten wrote: >> I think they (and the IETF as a whole, as I don't think the IETF LC >> has happened) will probably be able to evaluate it better with the >> extra sentence (btw, what will it be?). > > "Such as determining which server in a cluster will respond to the > client." > > Would be my pick. Simplest one. > >> Well, for one thing, the above text makes its sound like a protocol >> violation to implement the spec, but choose not to send the option >> (e.g., even if configured to do so for some reason). That seems a bit >> strong to me. > > There is a compatibility matrix here. > > If both the SRSN and the flags option are present, then a server > might choose to support the SRSN and copy its contents to the > server-identifier option. > > If the SRSN is present, and the flags option isn't, then they > might refuse to copy the contents over, which preserves the > detection of RENEWING vs REBINDING even if the result is all > RENEWs fail (due to filters or topology). > > If the flags option itself is present on its own, that's possibly > useless...unless more flags are defined. > > > So it depends what "compatibility" means. The middle scenario > will "work" in all cases. In the scenario where SRSN is trying > to bridge a unicast network gap, it will force clients to rebind > rather than renew...their unicasts to the server will fail. > > Certainly, it will still work, but is that compatible? > > If we said yes, does this mean that any solution that sends > clients through INIT to retain network connectivity is also > compatible? > > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 Mon Apr 30 21:30:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HihBp-0003pI-Ni; Mon, 30 Apr 2007 21:30:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HihBo-0003p3-ML for dhcwg@ietf.org; Mon, 30 Apr 2007 21:30:00 -0400 Received: from mailout1.samsung.com ([203.254.224.24]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HihBo-0001QN-1E for dhcwg@ietf.org; Mon, 30 Apr 2007 21:30:00 -0400 Received: from ep_ms7_bk (mailout1.samsung.com [203.254.224.24]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0JHC00I4X9HY6L@mailout1.samsung.com> for dhcwg@ietf.org; Tue, 01 May 2007 10:29:58 +0900 (KST) Received: from ep_spt02 (ms7.samsung.com [203.254.225.101]) by ms7.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0JHC002UV9HYVB@ms7.samsung.com> for dhcwg@ietf.org; Tue, 01 May 2007 10:29:58 +0900 (KST) Content-return: prohibited Date: Tue, 01 May 2007 01:29:58 +0000 (GMT) From: HYUN WOOK CHA Subject: Re: Re: RE: [dhcwg] A question about processing a RENEW message from a clientin DHCPv6. To: "David W. Hankins" Message-id: <18902513.118161177982998203.JavaMail.weblogic@ep_ml26> MIME-version: 1.0 MIME-version: 1.0 X-Priority: 3 Msgkey: 20070501012958202@hyunwook.cha X-MTR: 20070501012958202@hyunwook.cha X-EPLocale: ko_KR.utf-8 X-EPWebmail-Msg-Type: personal X-EPWebmail-Reply-Demand: 0 X-EPApproval-Locale: X-Spam-Score: 2.0 (++) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: "dhcwg@ietf.org" X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: hyunwook.cha@samsung.com List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1001472233==" Errors-To: dhcwg-bounces@ietf.org --===============1001472233== Content-return: prohibited Content-type: text/plain; charset=utf-8 Content-transfer-encoding: base64 DQpEZWFyLCBNci4gSGFua2lucy4NCg0KVGhhbmsgeW91IGZvciB5b3VyIGNsYXJpZmljYXRpb25z Lg0KDQpBY2NvcmRpbmcgdG8geW91ciBvcGluaW9uLCBpZiBhIGNsaWVudCBNVVNUIHJlbmV3IGFs bCBhZGRyZXNzZXMgd2hpY2ggYXJlIG5vdCByZWxlYXNlZCBvciBkZWNsaW5lZCwgTXVzdCBzZXJ2 ZXIgY2hlY2sgdGhhdCBSRU5FVyBtZXNzYWdlIGZyb20gY2xpZW50IGluY2x1ZGUgYWxsIGFkZHJl c3NlcyBhc3NvY2lhdGVkIHdpdGggdGhlIElBIGFuZCBkaXNjYXJkIHRoZSBSRU5FVyBtZXNzYWdl IHdpdGggbWlzc2luZyBhZGRyZXNzIG9wdGlvbj8NCkkgdGhpbmsgdGhhdCBpZiBhbGwgcHJldmlv dXMgREVDTElORSBvciBSRUxFQVNFIG1lc3NhZ2VzIGZhaWxlZCB0byBkZWxpdmVyIHRvIHRoZSBz ZXJ2ZXIsIGZvbGxvd2luZyBSRU5FVyBtZXNzYWdlcyBhcmUgZGlzY2FyZGVkIGJ5IHRoZSBzZXJ2 ZXIuIA0KSW4gbXkgb3BpbmlvbiwgdGhlIGZvbGxvd2luZyBjYW4gYmUgYW5vdGhlciBvcHRpb24u DQpXaGVuIHNlcnZlciByZWNlaXZlcyBhIFJFTkVXIG1lc3NhZ2Ugd2hpY2ggZG9lcyBub3QgaW5j bHVkZSBhbGwgYWRkcmVzc2VzIGFzc2lnbmVkIHRvIHRoZSBjbGllbnQgYnkgaXQsIGl0IGNvbnNp ZGVycyB0aGF0IHRoZSBjbGllbnQgdXNlcyBvbmx5IGFkZHJlc3NlcyBpbmNsdWRlZCBpbiB0aGUg UkVORVcgbWVzc2FnZSwgYW5kIHJlZnVzZXMob3IgaWdub3JlKSBvciByZWxlYXNlcyBvdGhlciBh ZGRyZXNzZXMuIFRoZW4sIHNlcnZlciByZWxlYXNlcyB0aG9zZSBhZGRyZXNzIGZyb20gSUEgYmlu ZGluZyBpbW1laWRhdGVseSBvciBrZWVwIGR1cmluZyBvbmx5IHRoZWlyIGxpZmV0aW1lcyB3aXRo b3V0IHJlZnJlc2hpbmcuIEFuZCBSRVBMWSBtZXNzYWdlIHRoYXQgc2VydmVyIHNlbmRzIGluY2x1 ZGVzIG9ubHkgcmVmcmVzaGVkIGFkZHJlc3NlcyBhbmQgYWRkaXRpb25hbCBuZXcgYWRkcmVzc2Vz IGlmIGFueS4gDQoNClJlZ2FyZHMsIA0KDQoNCg0KSm9zZXBoIEh5dW5Xb29rIENoYQ0KDQoiRm9y IHlvdSwgTyBHb2QsIHRlc3RlZCB1czsgeW91IHJlZmluZWQgdXMgbGlrZSBzaWx2ZXIuIg0KDQpT b2Z0d2FyZSBFbmdpbmVlciANCkRldmVsb3BtZW50IFBhcnQgMS4gSS9JbmZyYSAgDQpOZXR3b3Jr IFN5c3RlbSBEaXZpc2lvbiANClRlbCAwMzEtMjc5LTM4MDQgIE1vYmlsZSAwMTAtMzAyNC0zODA0 DQoNCi0tLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLS0tDQpTZW5kZXIgOiBEYXZpZCBXLiBI YW5raW5zPERhdmlkX0hhbmtpbnNAaXNjLm9yZz4gDQpEYXRlICAgOiAyMDA3LTA1LTAxIDAwOjU0 DQpUaXRsZSAgOiBSZTogUkU6IFtkaGN3Z10gQSBxdWVzdGlvbiBhYm91dCBwcm9jZXNzaW5nIGEg UkVORVcgbWVzc2FnZSBmcm9tIGENCiBjbGllbnRpbiBESENQdjYuDQoNCk9uIFN1biwgQXByIDI5 LCAyMDA3IGF0IDEwOjI2OjE4UE0gLTA0MDAsIEJlcm5pZSBWb2x6ICh2b2x6KSB3cm90ZToNCj4g QW5kLCB0aGUgc2VydmVyIHN0aWxsIGhhcyB0aGUgbGVhc2VzIChpZSwgd2UgYXNzdW1lIHRoZSB2 YWxpZCBsaWZldGltZSBoYXMgbm90IGV4cGlyZWQpLiBBbmQgaWYgdGhlcmUgYXJlIG5vIHNlcnZl ciBwb2xpY2llcyB0aGF0IGNvbmZsaWN0IHdpdGggdGhlbSBiZWluZyB1c2VkIGFuZCByZW5ld2Vk LCB3aGF0J3Mgd3Jvbmcgd2l0aCB0aGUgc2VydmVyIHJlbmV3aW5nIHRoZW0gYW5kIHNlbmRpbmcg dGhlbSB0byB0aGUgY2xpZW50Pw0KPiANCj4gVGhlIHdvcnN0IGlzIHRoYXQgdGhlIGNsaWVudCB3 aWxsIGlnbm9yZSB0aGVtIGxpa2UgaXQgZGlkIHByZXZpb3VzbHkuDQoNCklmIHdlIGdldCBpbnRv IGEgc2l0dWF0aW9uIHdoZXJlIHRoZSBESENQIHNlcnZlciBpcyBzZW5kaW5nIGFkZHJlc3Nlcw0K dGhlIGNsaWVudCBpcyBpZ25vcmluZywgdGhlbiBERE5TIHVwZGF0ZXMgZ2V0IGEgbG90IGxlc3Mg cmVsaWFibGUuDQoNCj4gTm90ZSBhbHNvIHRoYXQgdGhlIFJGQyAzMzE1IGxhbmdhZ3VlIHlvdSBx dW90ZWQgZG9lcyBub3QgaW5jbHVkZSBhIE1VU1QuIEFuZCwgYWxzbyBub3RlIHRoZSBsYW5ndWFn ZSBpbiAxOC4xLjguIFJlY2VpcHQgb2YgUmVwbHkgTWVzc2FnZXMgd2hpY2ggY2xlYXJseSBpbmRp Y2F0ZXMgdGhhdCBhIHNlcnZlciBtYXkgcmV0dXJuIGFkZGl0aW9uYWwgYWRkcmVzc2VzIGZvciBh IFJlcXVlc3QsIFJlbmV3LCBvciBSZWJpbmQuDQoNCkkgZG9uJ3QgbGlrZSB0aGlzIGFuc3dlci4g IElmIGEgY2xpZW50IHJlbGVhc2VzIGFuIGFkZHJlc3MgaXQNCiJkb2Vzbid0IHdhbnQiIGZvciB3 aGF0ZXZlciByZWFzb24sIHRoZW4gdGhlIHNlcnZlciB3aWxsIG9mZmVyDQptb3JlIGFkZHJlc3Nl cyBpbiB0aGUgbmV4dCBleGNoYW5nZSB3aGljaCBpdCBwcm9iYWJseSAiZG9lc24ndA0Kd2FudCIg ZWl0aGVyLg0KDQpUaGlzIHF1aWNrbHkgbG9va3MgbGlrZSBhbiBpbmZpbml0ZSBsb29wLg0KDQpU aGUgcmVhbCBhbnN3ZXIgSSB0aGluayBpcyB0aGF0IGEgY2xpZW50IGhhcyBubyBjaG9pY2UgaW4g dGhlIG1hdHRlciwNCmFuZCAiTVVTVCIgYmluZCBhbmQga2VlcCBhbGwgYWRkcmVzc2VzIHRoZSBz ZXJ2ZXIgZ2l2ZXMuDQoNClNvIGlmIHlvdSB3YW50IGEgY2xpZW50IHRvIG1vdmUgb2ZmIGFuIGFk ZHJlc3MsIHRoYXQgZGVjaXNpb24gY2FuIG9ubHkNCmJlIG1hZGUgYXQgdGhlIHNlcnZlci4NCg0K DQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IO+/ve+/ve+/ve+/ve+/ve+/ vSBbbWFpbHRvOmh5dW53b29rLmNoYUBzYW1zdW5nLmNvbV0gDQo+IFNlbnQ6IFN1bmRheSwgQXBy aWwgMjksIDIwMDcgMTA6MTEgUE0NCj4gVG86IEJlcm5pZSBWb2x6ICh2b2x6KTsgZGhjd2dAaWV0 Zi5vcmcNCj4gU3ViamVjdDogRndkOiBSRTogW2RoY3dnXSBBIHF1ZXN0aW9uIGFib3V0IHByb2Nl c3NpbmcgYSBSRU5FVyBtZXNzYWdlIGZyb20gYSBjbGllbnRpbiBESENQdjYuDQo+IA0KPiBJZiBj bGllbnQgZGV0ZXJtaW5lcyB0byB1c2Ugb25seSBvbmUgb2YgYWRkcmVzc2VzIHByb3ZpZGVkIGJ5 IHNlcnZlciBvciBrbm93cyB0aGF0IGFueSBhZGRyZXNzIGlzIG5vdCBvbi1saW5rIGZyb20gUkEs DQoNCkkgdGhpbmsgaXQgd291bGQgYmUgYSBtaXN0YWtlIG5vdCB0byB1c2UgYW4gYWRkcmVzcyB0 aGF0IGlzIGdpdmVuDQpieSB0aGUgc2VydmVyIGFuZCBpcyBub3QgY292ZXJlZCBieSBhIHByZWZp eCBhbm5vdW5jZW1lbnQgaW4gYW55IFJBLg0KDQpJdCdzIGJlZW4gc3RpcHVsYXRlZCB0aGF0IHRo ZXJlIG1heSBleGlzdCBuZXR3b3JrcyBpbiB3aGljaCB0aGVyZSBhcmUNCm5vIHJvdXRlcnMsIGF0 IGxlYXN0IG5vIHJvdXRlIGFkdmVydGlzZW1lbnRzLCBhbmQgd2hlcmUgbGluay1sb2NhbA0KYWRk cmVzc2VzIG1heSBiZSBpbnN1ZmZpY2llbnQuDQoNCklmIHRoZSBESENQIHNlcnZlciBpcyByZW5l d2luZyBpbnZhbGlkIGFkZHJlc3NlcywgdGhlbiB0aGF0IGlzIGENCm1pc2NvbmZpZ3VyYXRpb24u DQoNCi0tIA0KRGF2aWQgVy4gSGFua2lucwkiSWYgeW91IGRvbid0IGRvIGl0IHJpZ2h0IHRoZSBm aXJzdCB0aW1lLA0KU29mdHdhcmUgRW5naW5lZXIJCXlvdSdsbCBqdXN0IGhhdmUgdG8gZG8gaXQg YWdhaW4uIg0KSW50ZXJuZXQgU3lzdGVtcyBDb25zb3J0aXVtLCBJbmMuCS0tIEphY2sgVC4gSGFu a2lucw0KDQoNCg== --===============1001472233== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --===============1001472233==-- From dhcwg-bounces@ietf.org Mon Apr 30 23:19:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hiitk-0002ra-6n; Mon, 30 Apr 2007 23:19:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hiiti-0002rU-Vb for dhcwg@ietf.org; Mon, 30 Apr 2007 23:19:26 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hiiti-0006zt-LW for dhcwg@ietf.org; Mon, 30 Apr 2007 23:19:26 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 30 Apr 2007 23:19:26 -0400 X-IronPort-AV: i="4.14,472,1170651600"; d="scan'208"; a="119947725:sNHT60647806" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l413JQEK020735; Mon, 30 Apr 2007 23:19:26 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l413JLlI014796; Tue, 1 May 2007 03:19:21 GMT Received: from xmb-rtp-20a.amer.cisco.com ([64.102.31.15]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Apr 2007 23:19:21 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: RE: [dhcwg] A question about processing a RENEW message from aclientin DHCPv6. Date: Mon, 30 Apr 2007 23:19:20 -0400 Message-ID: <8E296595B6471A4689555D5D725EBB2103EAB7B9@xmb-rtp-20a.amer.cisco.com> In-Reply-To: <20070430155453.GD5276@isc.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RE: [dhcwg] A question about processing a RENEW message from aclientin DHCPv6. Thread-Index: AceLPRESDdypBb4kT72m34mcnqLniAAYhkTw From: "Bernie Volz \(volz\)" To: "David W. Hankins" , X-OriginalArrivalTime: 01 May 2007 03:19:21.0727 (UTC) FILETIME=[8300B0F0:01C78B9F] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2987; t=1177989566; x=1178853566; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=volz@cisco.com; z=From:=20=22Bernie=20Volz=20\(volz\)=22=20 |Subject:=20RE=3A=20RE=3A=20[dhcwg]=20A=20question=20about=20processing=2 0a=20RENEW=20message=20from=20aclientin=20DHCPv6. |Sender:=20 |To:=20=22David=20W.=20Hankins=22=20, =20; bh=RxllukMdQFACU59JALmaoZprVJKgyj9rOvUyrf1fjhw=; b=YC8wMtt3dLeQXkEsfYq5DfeHd1Z+3dMEedjAV+64yy7zt8LoCTj3njmclIeB2mPb8wV2Fpqb T8iLcGAX2ckNQojWHeZEg8cO+zkZIxwyU9zU5AmThlCCr0OeZUcHz4nb; Authentication-Results: rtp-dkim-1; header.From=volz@cisco.com; dkim=pass (s ig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: hyunwook.cha@samsung.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: , Errors-To: dhcwg-bounces@ietf.org David: I think we end up being in agreement? I certainly am not recommending clients ignore addresses or don't follow the rules in sending all of them when renewing. The question that was asked though is what should a server do if that does happen. My answer is that the server should "pretend" that the client sent them all. >This quickly looks like an infinite loop. Huh? Only when the client would RENEW or REBIND would it get more. - Bernie=20 -----Original Message----- From: David W. Hankins [mailto:David_Hankins@isc.org]=20 Sent: Monday, April 30, 2007 11:55 AM To: dhcwg@ietf.org Cc: hyunwook.cha@samsung.com Subject: Re: RE: [dhcwg] A question about processing a RENEW message from aclientin DHCPv6. On Sun, Apr 29, 2007 at 10:26:18PM -0400, Bernie Volz (volz) wrote: > And, the server still has the leases (ie, we assume the valid lifetime has not expired). And if there are no server policies that conflict with them being used and renewed, what's wrong with the server renewing them and sending them to the client? >=20 > The worst is that the client will ignore them like it did previously. If we get into a situation where the DHCP server is sending addresses the client is ignoring, then DDNS updates get a lot less reliable. > Note also that the RFC 3315 langague you quoted does not include a MUST. And, also note the language in 18.1.8. Receipt of Reply Messages which clearly indicates that a server may return additional addresses for a Request, Renew, or Rebind. I don't like this answer. If a client releases an address it "doesn't want" for whatever reason, then the server will offer more addresses in the next exchange which it probably "doesn't want" either. This quickly looks like an infinite loop. The real answer I think is that a client has no choice in the matter, and "MUST" bind and keep all addresses the server gives. So if you want a client to move off an address, that decision can only be made at the server. > -----Original Message----- > From: [mailto:hyunwook.cha@samsung.com]=20 > Sent: Sunday, April 29, 2007 10:11 PM > To: Bernie Volz (volz); dhcwg@ietf.org > Subject: Fwd: RE: [dhcwg] A question about processing a RENEW message from a clientin DHCPv6. >=20 > If client determines to use only one of addresses provided by server or knows that any address is not on-link from RA, I think it would be a mistake not to use an address that is given by the server and is not covered by a prefix announcement in any RA. It's been stipulated that there may exist networks in which there are no routers, at least no route advertisements, and where link-local addresses may be insufficient. If the DHCP server is renewing invalid addresses, then that is a misconfiguration. --=20 David W. Hankins "If you don't do it right the first time, Software Engineer you'll just have to do it again." Internet Systems Consortium, Inc. -- Jack T. Hankins _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg