From dhcwg-admin@ietf.org Mon Oct 1 14:44:51 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26575; Mon, 1 Oct 2001 14:44:51 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA08847; Mon, 1 Oct 2001 14:43:58 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA08827 for ; Mon, 1 Oct 2001 14:43:57 -0400 (EDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26538 for ; Mon, 1 Oct 2001 14:43:51 -0400 (EDT) Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id OAA12437; Mon, 1 Oct 2001 14:43:37 -0400 (EDT) Message-Id: <200110011843.OAA12437@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Thomas Narten cc: Keith Moore , dhcwg@ietf.org In-reply-to: Your message of "Fri, 28 Sep 2001 14:34:51 EDT." <200109281834.OAA25641@rotala.raleigh.ibm.com> Date: Mon, 01 Oct 2001 14:43:37 -0400 Subject: [dhcwg] Re: Last Call: DHCP Domain Search Option to Proposed Standard Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org > Finally, what do you propose? I.e., "send text" :-) Would it suffice > to add some language stating that in the case of this option, it > should not override a manually configured search list? yes, that would suffice. (should not should probably be in caps) thanks. Keith _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Oct 3 07:15:40 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07492; Wed, 3 Oct 2001 07:15:40 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA26627; Wed, 3 Oct 2001 07:12:23 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA26601 for ; Wed, 3 Oct 2001 07:12:21 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07137; Wed, 3 Oct 2001 07:12:18 -0400 (EDT) Message-Id: <200110031112.HAA07137@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: dhcwg@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 03 Oct 2001 07:12:18 -0400 Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-agentoptions-device-class-03.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@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 : Addition of Device Class to Agent Options Author(s) : D. Jones, R. Woundy Filename : draft-ietf-dhc-agentoptions-device-class-03.txt Pages : 5 Date : 02-Oct-01 This document proposes a new sub-option to the DHCP Relay Information Agent Option. This new sub-option is for use with DOCSIS cable modems and describes a 'device class' to which the cable modem belongs. The cable modem signals its device class information to the Relay Agent using DOCSIS signalling, and the Relay Agent forwards the device class information to the DHCP Server which can then make a policy decision based on it. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-agentoptions-device-class-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dhc-agentoptions-device-class-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dhc-agentoptions-device-class-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20011002120701.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-agentoptions-device-class-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-agentoptions-device-class-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20011002120701.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Oct 3 12:34:25 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20842; Wed, 3 Oct 2001 12:34:24 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA08663; Wed, 3 Oct 2001 12:33:12 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA18303 for ; Wed, 3 Oct 2001 02:15:31 -0400 (EDT) Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27293 for ; Wed, 3 Oct 2001 02:15:28 -0400 (EDT) Received: from gateway.nrsa.gov.in ([202.54.32.161]) by mail.bucknell.edu (8.11.6/8.11.6) with ESMTP id f936FPi12625; Wed, 3 Oct 2001 02:15:28 -0400 (EDT) Received: by gateway.nrsa.gov.in; (8.8.8/1.3/10May95) id LAA114487; Wed, 3 Oct 2001 11:48:28 +0300 (EAT) Message-ID: <3BBAADC9.2E1CD52@nrsa.gov.in> Date: Wed, 03 Oct 2001 11:48:49 +0530 From: Feedback X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: listserv@bucknell.edu, dhcp-v4@bucknell.edu Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [dhcwg] DHCP Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 7bit Hi, We have installed two years back DHCP on Digital Unix 4.0D. It was functioning normally. But for the last two/three days it is not functioning normally. Following error is coming "received on address 192.168.255.255 Starting txn 1002089438 on Wednesday October 03 11:40 from (ip_address,port#)=(0.0.0.0,68) to=(???,0) received on interface tu0 xid=0x8d419d62 secs=21721 flags=0000 DHCPrequest(selecting) " after this dhcp server will not function. pl. help _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sun Oct 7 01:00:58 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA05366; Sun, 7 Oct 2001 01:00:58 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA09305; Sun, 7 Oct 2001 00:57:56 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA09274 for ; Sun, 7 Oct 2001 00:57:54 -0400 (EDT) Received: from harumscarum.mr.itd.umich.edu (harumscarum.mr.itd.umich.edu [141.211.125.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05348 for ; Sun, 7 Oct 2001 00:57:52 -0400 (EDT) Received: from win2kserver (nic-131-c193-59.mw.mediaone.net [24.131.193.59]) by harumscarum.mr.itd.umich.edu (8.9.3/3.3s) with SMTP id AAA04511 for ; Sun, 7 Oct 2001 00:57:54 -0400 (EDT) Message-ID: <002901c14ef4$d4c3c0f0$3bc18318@OLYMPUS.local> From: "Ty Hiither" To: Date: Sun, 7 Oct 2001 00:56:35 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0026_01C14ECA.EA0AC820" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Subject: [dhcwg] help Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0026_01C14ECA.EA0AC820 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I just set up a win2k advanced server. I keep having problems with = computers joining the domain. I think the problem lies with DHCP. = First off, when I try to use the winipcfg or ipconfig on the clients = they always say they dont' have an IP. When I try to release and renew = the adapters it always errors out saying it can't renew. This seems to = be intermittant. I just have to keep restarting over and over and = eventually it may pick it up. It also doesn't show the dhcp leases in = the lease list like it does on the server at work. I don't know how to = test this to see if it's doing what it should be doing... any ideas? = This happens with both windows 98 and 2000 clients. It just doesn't = seem to pick up ip addresses and this is on all the clients. Ty ------=_NextPart_000_0026_01C14ECA.EA0AC820 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I just set up a win2k advanced = server.  I keep=20 having problems with computers joining the domain.  I think the = problem=20 lies with DHCP.  First off, when I try to use the winipcfg or = ipconfig on=20 the clients they always say they dont' have an IP.  When I try to = release=20 and renew the adapters it always errors out saying it can't renew.  = This=20 seems to be intermittant.  I just have to keep restarting over and = over and=20 eventually it may pick it up.  It also doesn't show the dhcp leases = in the=20 lease list like it does on the server at work.  I don't know how to = test=20 this to see if it's doing what it should be doing... any ideas?  = This=20 happens with both windows 98 and 2000 clients.  It just doesn't = seem to=20 pick up ip addresses and this is on all the clients.
 
Ty
------=_NextPart_000_0026_01C14ECA.EA0AC820-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sun Oct 7 02:08:32 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA17189; Sun, 7 Oct 2001 02:08:32 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA17579; Sun, 7 Oct 2001 02:07:40 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA17551 for ; Sun, 7 Oct 2001 02:07:38 -0400 (EDT) Received: from internaut.com ([64.38.134.99]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA17153 for ; Sun, 7 Oct 2001 02:07:35 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id WAA48956; Sat, 6 Oct 2001 22:58:39 -0700 (PDT) (envelope-from aboba@internaut.com) Date: Sat, 6 Oct 2001 22:58:39 -0700 (PDT) From: Bernard Aboba To: Ty Hiither cc: dhcwg@ietf.org Subject: Re: [dhcwg] help In-Reply-To: <002901c14ef4$d4c3c0f0$3bc18318@OLYMPUS.local> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org You haven't authorized the DHCP server within the Active Directory domain. As a result, the service isn't started. On Sun, 7 Oct 2001, Ty Hiither wrote: > I just set up a win2k advanced server. I keep having problems with computers joining the domain. I think the problem lies with DHCP. First off, when I try to use the winipcfg or ipconfig on the clients they always say they dont' have an IP. When I try to release and renew the adapters it always errors out saying it can't renew. This seems to be intermittant. I just have to keep restarting over and over and eventually it may pick it up. It also doesn't show the dhcp leases in the lease list like it does on the server at work. I don't know how to test this to see if it's doing what it should be doing... any ideas? This happens with both windows 98 and 2000 clients. It just doesn't seem to pick up ip addresses and this is on all the clients. > > Ty > _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Oct 8 13:08:57 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26392; Mon, 8 Oct 2001 13:08:57 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA11411; Mon, 8 Oct 2001 13:07:33 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA10686 for ; Mon, 8 Oct 2001 12:57:36 -0400 (EDT) Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26061 for ; Mon, 8 Oct 2001 12:57:31 -0400 (EDT) Received: from bbvapanama.local (mail.bbvapanama.com [206.128.112.115]) by mail.bucknell.edu (8.11.6/8.11.6) with ESMTP id f98GvRi01543 for ; Mon, 8 Oct 2001 12:57:28 -0400 (EDT) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Date: Mon, 8 Oct 2001 11:57:07 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 Message-ID: <433AF103EAD2A44990DC643E912E3E4A03BF2D@iscariote.bbvapanama.local> Thread-Topic: Static IP vs Dynamic IP on Servers Thread-Index: AcFQGkMj43KcsqUxRHGTHA12M/pbhA== From: =?utf-8?Q?Roberto_M=C3=A9ndez_Echevers?= To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by optimus.ietf.org id MAA10687 Subject: [dhcwg] Static IP vs Dynamic IP on Servers Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 8bit Hi... I have a conflicting opinion with a co-worker... What would be the advantages or disadvantages of having a server get it's IP from a DHCP server or assigning a static IP to it?... Thanks... _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Oct 8 15:59:33 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00066; Mon, 8 Oct 2001 15:59:32 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA16326; Mon, 8 Oct 2001 15:58:53 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA16298 for ; Mon, 8 Oct 2001 15:58:52 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00026; Mon, 8 Oct 2001 15:58:50 -0400 (EDT) Message-Id: <200110081958.PAA00026@ietf.org> To: IETF-Announce: ; Cc: dhcwg@ietf.org From: The IESG Reply-to: iesg@ietf.org Date: Mon, 08 Oct 2001 15:58:50 -0400 Subject: [dhcwg] Last Call: Addition of Device Class to Agent Options to Proposed Standard Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org The IESG has received a request from the Dynamic Host Configuration Working Group to consider Addition of Device Class to Agent Options as a Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by October 22, 2001. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-dhc-agentoptions-device-class-03.txt _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Oct 8 19:56:16 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04288; Mon, 8 Oct 2001 19:56:15 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA21823; Mon, 8 Oct 2001 19:55:36 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA21803 for ; Mon, 8 Oct 2001 19:55:35 -0400 (EDT) Received: from inet-vrs-04.redmond.corp.microsoft.com (mail4.microsoft.com [131.107.3.122]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA04279 for ; Mon, 8 Oct 2001 19:55:33 -0400 (EDT) Received: from 157.54.1.52 by inet-vrs-04.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 08 Oct 2001 16:55:06 -0700 Received: from red-msg-12.redmond.corp.microsoft.com ([157.54.2.26]) by inet-imc-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 8 Oct 2001 16:55:05 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.5739.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" Date: Mon, 8 Oct 2001 16:55:05 -0700 Message-ID: <905568611548FF439A27CB4F41D273E9CAD17C@red-msg-12.redmond.corp.microsoft.com> Thread-Topic: Defining failover scenario Thread-Index: AcFQVKY/nVPp8FogTgC02r3GEEMYnA== From: "Drew Baron" To: X-OriginalArrivalTime: 08 Oct 2001 23:55:05.0698 (UTC) FILETIME=[A7469420:01C15054] Subject: [dhcwg] Defining failover scenario Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org This is a multi-part message in MIME format. --------------InterScan_NT_MIME_Boundary Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C15054.A701E76C" ------_=_NextPart_001_01C15054.A701E76C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The failover draft lists the following as a challenging scenario: 3.4.2. Network partition where DHCP servers can't communicate but each can talk to clients: "First, due to a network failure, the primary and secondary servers cannot communicate. As well, some of the DHCP clients must be able to com- municate with the primary server, and some of the clients must now only be able to communicate with the secondary server." The phrase 'some of the clients' is tripping me up. I'm struggling to envision the scenario needed to end up in this state. Can anyone provide a concrete example of an environment that this could occur in? How do I end up with clients that are on the same segment that cannot reach both servers? =20 Thanks, -Drew Baron =20 =20 ------_=_NextPart_001_01C15054.A701E76C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
The=20 failover draft  <draft-ietf-dhc-failover-09.txt> lists = the=20 following as a challenging scenario:
3.4.2.  Network partition = where DHCP=20 servers can't communicate but each
can talk to clients:
"First, due to a network failure, the = primary=20 and secondary servers cannot
   communicate.  As = well, some=20 of the DHCP clients must be able to com-
   municate with = the=20 primary server, and some of the clients must now
   only = be able=20 to communicate with the secondary server."
The=20 phrase 'some of the clients' is tripping me up.  = I'm struggling to = envision the=20 scenario needed to end up in this state.  Can anyone provide a = concrete=20 example of an environment that this could occur in?  How do I end = up with=20 clients that are on the same segment that cannot reach both=20 servers?
 
Thanks,
-Drew=20 Baron
 
 
=00 ------_=_NextPart_001_01C15054.A701E76C-- --------------InterScan_NT_MIME_Boundary-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Oct 8 22:00:37 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA06626; Mon, 8 Oct 2001 22:00:37 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA24235; Mon, 8 Oct 2001 21:59:12 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA24210 for ; Mon, 8 Oct 2001 21:59:06 -0400 (EDT) Received: from imr2.ericy.com (imr2.ericy.com [12.34.240.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA06590 for ; Mon, 8 Oct 2001 21:59:03 -0400 (EDT) Received: from mr6.exu.ericsson.se (mr6att.ericy.com [138.85.92.14]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id f991wb011562 for ; Mon, 8 Oct 2001 20:58:37 -0500 (CDT) Received: from eamrcnt749 (eamrcnt749.exu.ericsson.se [138.85.133.47]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with SMTP id f991wba25111 for ; Mon, 8 Oct 2001 20:58:37 -0500 (CDT) Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt749 ; Mon Oct 08 20:58:37 2001 -0500 Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id <4CP9RF5T>; Mon, 8 Oct 2001 20:58:36 -0500 Message-ID: <66F66129A77AD411B76200508B65AC697B3730@eambunt705.ena-east.ericsson.se> From: "Bernie Volz (EUD)" To: "'Drew Baron'" , dhcwg@ietf.org Subject: RE: [dhcwg] Defining failover scenario Date: Mon, 8 Oct 2001 20:58:35 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C15065.E7B71960" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C15065.E7B71960 Content-Type: text/plain; charset="iso-8859-1" Simple ... on a LAN place a DHCP server at each end. Place clients between the servers. Cut the cable somewhere in the middle. Now, some of the clients can talk with one server, some can talk with the other. The servers can't talk with each other (nor can all clients). In today's switch environments, this can happen if you have two switches and have a DHCP server connected to each and some clients connected to each. Cut the cable between the two switches. -----Original Message----- From: Drew Baron [mailto:drewba@microsoft.com] Sent: Monday, October 08, 2001 7:55 PM To: dhcwg@ietf.org Subject: [dhcwg] Defining failover scenario The failover draft lists the following as a challenging scenario: 3.4.2. Network partition where DHCP servers can't communicate but each can talk to clients: "First, due to a network failure, the primary and secondary servers cannot communicate. As well, some of the DHCP clients must be able to com- municate with the primary server, and some of the clients must now only be able to communicate with the secondary server." The phrase 'some of the clients' is tripping me up. I'm struggling to envision the scenario needed to end up in this state. Can anyone provide a concrete example of an environment that this could occur in? How do I end up with clients that are on the same segment that cannot reach both servers? Thanks, -Drew Baron ------_=_NextPart_001_01C15065.E7B71960 Content-Type: text/html; charset="iso-8859-1" Message
Simple ... on a LAN place a DHCP server at each end. Place clients between the servers. Cut the cable somewhere in the middle. Now, some of the clients can talk with one server, some can talk with the other. The servers can't talk with each other (nor can all clients).
 
In today's switch environments, this can happen if you have two switches and have a DHCP server connected to each and some clients connected to each. Cut the cable between the two switches.
-----Original Message-----
From: Drew Baron [mailto:drewba@microsoft.com]
Sent: Monday, October 08, 2001 7:55 PM
To: dhcwg@ietf.org
Subject: [dhcwg] Defining failover scenario

The failover draft  <draft-ietf-dhc-failover-09.txt> lists the following as a challenging scenario:
3.4.2.  Network partition where DHCP servers can't communicate but each
can talk to clients:
"First, due to a network failure, the primary and secondary servers cannot
   communicate.  As well, some of the DHCP clients must be able to com-
   municate with the primary server, and some of the clients must now
   only be able to communicate with the secondary server."
The phrase 'some of the clients' is tripping me up.  I'm struggling to envision the scenario needed to end up in this state.  Can anyone provide a concrete example of an environment that this could occur in?  How do I end up with clients that are on the same segment that cannot reach both servers?
 
Thanks,
-Drew Baron
 
 
------_=_NextPart_001_01C15065.E7B71960-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Oct 8 22:17:32 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA06852; Mon, 8 Oct 2001 22:17:32 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA24854; Mon, 8 Oct 2001 22:16:04 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA24830 for ; Mon, 8 Oct 2001 22:16:03 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA06836 for ; Mon, 8 Oct 2001 22:15:59 -0400 (EDT) Received: from green.bisbee.fugue.com (1Cust164.tnt8.nyc3.da.uu.net [63.27.34.164]) by toccata.fugue.com (8.11.3/8.6.11) with ESMTP id f992FXv21046; Mon, 8 Oct 2001 19:15:33 -0700 (PDT) Received: from green.bisbee.fugue.com (localhost [127.0.0.1]) by green.bisbee.fugue.com (8.10.2/8.6.11) with ESMTP id f992G4216242; Mon, 8 Oct 2001 22:16:04 -0400 (EDT) Message-Id: <200110090216.f992G4216242@green.bisbee.fugue.com> To: "Drew Baron" cc: dhcwg@ietf.org Subject: Re: [dhcwg] Defining failover scenario In-Reply-To: Your message of "Mon, 08 Oct 2001 16:55:05 PDT." <905568611548FF439A27CB4F41D273E9CAD17C@red-msg-12.redmond.corp.microsoft.com> Date: Mon, 08 Oct 2001 22:16:04 -0400 From: Ted Lemon Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org > How do I end up with clients that are on the same segment that cannot > reach both servers? Two routers on different sides of a failed bridge. _MelloN_ _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Oct 9 07:56:30 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28311; Tue, 9 Oct 2001 07:56:30 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA16172; Tue, 9 Oct 2001 07:54:41 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA16147 for ; Tue, 9 Oct 2001 07:54:39 -0400 (EDT) Received: from hotmail.com (f267.law14.hotmail.com [64.4.20.142]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28258 for ; Tue, 9 Oct 2001 07:54:34 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 9 Oct 2001 04:54:07 -0700 Received: from 192.18.17.3 by lw14fd.law14.hotmail.msn.com with HTTP; Tue, 09 Oct 2001 11:54:07 GMT X-Originating-IP: [192.18.17.3] From: "venkat devarajan" To: dhcwg@ietf.org Date: Tue, 09 Oct 2001 17:24:07 +0530 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 09 Oct 2001 11:54:07.0688 (UTC) FILETIME=[19E7D480:01C150B9] Subject: [dhcwg] doubt regarding DHCPREQUEST Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Hi , I am Venkat working in Sun Microsystems. I have a doubt regarding the DHCPREQUEST message broadcast. Doubt: Why is a DHCPREQUEST for Address Reuse or an lease time extension broadcast to all other servers ? could it not be sent to that dhcp server alone that provided the client with the ip adrress ? Regards, Venkat _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Oct 9 09:37:44 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02528; Tue, 9 Oct 2001 09:37:44 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA20558; Tue, 9 Oct 2001 09:36:39 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA20532 for ; Tue, 9 Oct 2001 09:36:37 -0400 (EDT) Received: from imr2.ericy.com (imr2.ericy.com [12.34.240.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02464 for ; Tue, 9 Oct 2001 09:36:30 -0400 (EDT) Received: from mr7.exu.ericsson.se (mr7att.ericy.com [138.85.92.15]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id f99Da5026920 for ; Tue, 9 Oct 2001 08:36:05 -0500 (CDT) Received: from eamrcnt747.exu.ericsson.se (eamrcnt747.exu.ericsson.se [138.85.133.37]) by mr7.exu.ericsson.se (8.11.3/8.11.3) with SMTP id f99Da5407327 for ; Tue, 9 Oct 2001 08:36:05 -0500 (CDT) Received: FROM eamrcnt760.exu.ericsson.se BY eamrcnt747.exu.ericsson.se ; Tue Oct 09 08:36:04 2001 -0500 Received: by eamrcnt760.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id <4CQDHZGC>; Tue, 9 Oct 2001 08:36:04 -0500 Message-ID: <66F66129A77AD411B76200508B65AC697B3732@eambunt705.ena-east.ericsson.se> From: "Bernie Volz (EUD)" To: "'venkat devarajan'" , dhcwg@ietf.org Subject: RE: [dhcwg] doubt regarding DHCPREQUEST Date: Tue, 9 Oct 2001 08:36:04 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C150C7.57923C40" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C150C7.57923C40 Content-Type: text/plain; charset="iso-8859-1" The client may well not have an address of sufficient scope it can use to communicate with the server. If the server and client are on the same link, then sure the link local address could be used (and in this case the server could send the client the unicast option in the Advertise). However, if the server is off-link, then the client can't communicate with the server directly. Also, if you have multiple relays, won't it be useful to be able to use the one that is up in case one fails? Also, remember that IPv6 uses a lot of multicasting (no broadcasting) and hence only those systems that are playing a DHCP role will receive these packets. So, the cost of multicasting them is not very high. - Bernie Volz -----Original Message----- From: venkat devarajan [mailto:venkat026@hotmail.com] Sent: Tuesday, October 09, 2001 7:54 AM To: dhcwg@ietf.org Subject: [dhcwg] doubt regarding DHCPREQUEST Hi , I am Venkat working in Sun Microsystems. I have a doubt regarding the DHCPREQUEST message broadcast. Doubt: Why is a DHCPREQUEST for Address Reuse or an lease time extension broadcast to all other servers ? could it not be sent to that dhcp server alone that provided the client with the ip adrress ? Regards, Venkat _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg ------_=_NextPart_001_01C150C7.57923C40 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] doubt regarding DHCPREQUEST

The client may well not have an address of sufficient = scope it can use to communicate with the server.

If the server and client are on the same link, then = sure the link local address could be used (and in this case the server = could send the client the unicast option in the Advertise).

However, if the server is off-link, then the client = can't communicate with the server directly. Also, if you have multiple = relays, won't it be useful to be able to use the one that is up in case = one fails?

Also, remember that IPv6 uses a lot of multicasting = (no broadcasting) and hence only those systems that are playing a DHCP = role will receive these packets. So, the cost of multicasting them is = not very high.

- Bernie Volz

-----Original Message-----
From: venkat devarajan [mailto:venkat026@hotmail.com]<= /FONT>
Sent: Tuesday, October 09, 2001 7:54 AM
To: dhcwg@ietf.org
Subject: [dhcwg] doubt regarding DHCPREQUEST


Hi ,
I am Venkat working in Sun Microsystems.
I have a doubt regarding the DHCPREQUEST message = broadcast.

Doubt:
Why is a DHCPREQUEST for Address Reuse or an lease = time extension broadcast
to all other servers ? could it not be sent to that = dhcp server alone that
provided the client with the ip adrress ?

Regards,
Venkat

_______________________________________________________________= __
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp


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

------_=_NextPart_001_01C150C7.57923C40-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Oct 9 12:25:35 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07185; Tue, 9 Oct 2001 12:25:35 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA27767; Tue, 9 Oct 2001 12:23:27 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA27740 for ; Tue, 9 Oct 2001 12:23:25 -0400 (EDT) Received: from hotmail.com (f71.law14.hotmail.com [64.4.21.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07152 for ; Tue, 9 Oct 2001 12:23:19 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 9 Oct 2001 09:22:50 -0700 Received: from 192.18.17.3 by lw14fd.law14.hotmail.msn.com with HTTP; Tue, 09 Oct 2001 16:22:50 GMT X-Originating-IP: [192.18.17.3] From: "venkat devarajan" To: dhcwg@ietf.org Subject: RE: [dhcwg] doubt regarding DHCPREQUEST Date: Tue, 09 Oct 2001 21:52:50 +0530 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 09 Oct 2001 16:22:50.0887 (UTC) FILETIME=[A414C170:01C150DE] Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Hi does the client not know the server's IpAddress when getting a DHCPACK /DHCPOFFER ? i am referring to the 'siaddr' field in the dhcp packet structure . Regrads, Venkat >From: "Bernie Volz (EUD)" >To: "'venkat devarajan'" , dhcwg@ietf.org >Subject: RE: [dhcwg] doubt regarding DHCPREQUEST >Date: Tue, 9 Oct 2001 08:36:04 -0500 > >The client may well not have an address of sufficient scope it can use to >communicate with the server. > >If the server and client are on the same link, then sure the link local >address could be used (and in this case the server could send the client >the unicast option in the Advertise). > >However, if the server is off-link, then the client can't communicate with >the server directly. Also, if you have multiple relays, won't it be useful >to be able to use the one that is up in case one fails? > >Also, remember that IPv6 uses a lot of multicasting (no broadcasting) and >hence only those systems that are playing a DHCP role will receive these >packets. So, the cost of multicasting them is not very high. > >- Bernie Volz > >-----Original Message----- >From: venkat devarajan [mailto:venkat026@hotmail.com] >Sent: Tuesday, October 09, 2001 7:54 AM >To: dhcwg@ietf.org >Subject: [dhcwg] doubt regarding DHCPREQUEST > > >Hi , >I am Venkat working in Sun Microsystems. >I have a doubt regarding the DHCPREQUEST message broadcast. > >Doubt: >Why is a DHCPREQUEST for Address Reuse or an lease time extension broadcast >to all other servers ? could it not be sent to that dhcp server alone that >provided the client with the ip adrress ? > >Regards, >Venkat > >_________________________________________________________________ >Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp > > >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >http://www1.ietf.org/mailman/listinfo/dhcwg _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Oct 9 12:51:44 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07991; Tue, 9 Oct 2001 12:51:44 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA28923; Tue, 9 Oct 2001 12:51:13 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA28898 for ; Tue, 9 Oct 2001 12:51:11 -0400 (EDT) Received: from imr2.ericy.com (imr2.ericy.com [12.34.240.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07984 for ; Tue, 9 Oct 2001 12:51:07 -0400 (EDT) Received: from mr6.exu.ericsson.se (mr6att.ericy.com [138.85.92.14]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id f99GoZ023304 for ; Tue, 9 Oct 2001 11:50:35 -0500 (CDT) Received: from eamrcnt747.exu.ericsson.se (eamrcnt747.exu.ericsson.se [138.85.133.37]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with SMTP id f99GoZe04257 for ; Tue, 9 Oct 2001 11:50:35 -0500 (CDT) Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt747.exu.ericsson.se ; Tue Oct 09 11:50:35 2001 -0500 Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id <4CP9SJCC>; Tue, 9 Oct 2001 11:50:35 -0500 Message-ID: <66F66129A77AD411B76200508B65AC697B373C@eambunt705.ena-east.ericsson.se> From: "Bernie Volz (EUD)" To: "'venkat devarajan'" , dhcwg@ietf.org Subject: RE: [dhcwg] doubt regarding DHCPREQUEST Date: Tue, 9 Oct 2001 11:50:32 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C150E2.8293A670" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C150E2.8293A670 Content-Type: text/plain; charset="iso-8859-1" Actually, I had DHCPv6 on my brain when I responded. You're asking about DHCP for IPv4. When a client doesn't yet have a lease on the address, it must broadcast since it has no valid source address. Also, the broadcast serves to indicate to other servers that they were not selected by the client and can 'release' the address that they temporarily allocated and offered to the client. When a client has an address, the specification says it is unicast (RFC 2131): o DHCPREQUEST generated during RENEWING state: 'server identifier' MUST NOT be filled in, 'requested IP address' option MUST NOT be filled in, 'ciaddr' MUST be filled in with client's IP address. In this situation, the client is completely configured, and is trying to extend its lease. This message will be unicast, so no relay agents will be involved in its transmission. Because 'giaddr' is therefore not filled in, the DHCP server will trust the value in 'ciaddr', and use it when replying to the client. "This message will be unicast". - Bernie -----Original Message----- From: venkat devarajan [mailto:venkat026@hotmail.com] Sent: Tuesday, October 09, 2001 12:23 PM To: dhcwg@ietf.org Subject: RE: [dhcwg] doubt regarding DHCPREQUEST Hi does the client not know the server's IpAddress when getting a DHCPACK /DHCPOFFER ? i am referring to the 'siaddr' field in the dhcp packet structure . Regrads, Venkat >From: "Bernie Volz (EUD)" >To: "'venkat devarajan'" , dhcwg@ietf.org >Subject: RE: [dhcwg] doubt regarding DHCPREQUEST >Date: Tue, 9 Oct 2001 08:36:04 -0500 > >The client may well not have an address of sufficient scope it can use to >communicate with the server. > >If the server and client are on the same link, then sure the link local >address could be used (and in this case the server could send the client >the unicast option in the Advertise). > >However, if the server is off-link, then the client can't communicate with >the server directly. Also, if you have multiple relays, won't it be useful >to be able to use the one that is up in case one fails? > >Also, remember that IPv6 uses a lot of multicasting (no broadcasting) and >hence only those systems that are playing a DHCP role will receive these >packets. So, the cost of multicasting them is not very high. > >- Bernie Volz > >-----Original Message----- >From: venkat devarajan [mailto:venkat026@hotmail.com] >Sent: Tuesday, October 09, 2001 7:54 AM >To: dhcwg@ietf.org >Subject: [dhcwg] doubt regarding DHCPREQUEST > > >Hi , >I am Venkat working in Sun Microsystems. >I have a doubt regarding the DHCPREQUEST message broadcast. > >Doubt: >Why is a DHCPREQUEST for Address Reuse or an lease time extension broadcast >to all other servers ? could it not be sent to that dhcp server alone that >provided the client with the ip adrress ? > >Regards, >Venkat > >_________________________________________________________________ >Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp > > >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >http://www1.ietf.org/mailman/listinfo/dhcwg _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg ------_=_NextPart_001_01C150E2.8293A670 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] doubt regarding DHCPREQUEST

Actually, I had DHCPv6 on my brain when I responded. = You're asking about DHCP for IPv4.

When a client doesn't yet have a lease on the = address, it must broadcast since it has no valid source address. Also, = the broadcast serves to indicate to other servers that they were not = selected by the client and can 'release' the address that they = temporarily allocated and offered to the client.

When a client has an address, the specification says = it is unicast (RFC 2131):

  o DHCPREQUEST generated during RENEWING = state:

      'server identifier' = MUST NOT be filled in, 'requested IP address'
      option MUST NOT be = filled in, 'ciaddr' MUST be filled in with
      client's IP address. = In this situation, the client is completely
      configured, and is = trying to extend its lease. This message will
      be unicast, so no = relay agents will be involved in its
      transmission.  = Because 'giaddr' is therefore not filled in, the
      DHCP server will = trust the value in 'ciaddr', and use it when
      replying to the = client.

"This message will be unicast".

- Bernie

-----Original Message-----
From: venkat devarajan [mailto:venkat026@hotmail.com]<= /FONT>
Sent: Tuesday, October 09, 2001 12:23 PM
To: dhcwg@ietf.org
Subject: RE: [dhcwg] doubt regarding = DHCPREQUEST


Hi
does the client not know the server's IpAddress when = getting a DHCPACK  
/DHCPOFFER ? i am referring to the 'siaddr' field in = the dhcp packet
structure .
Regrads,
Venkat

>From: "Bernie Volz (EUD)" = <Bernie.Volz@am1.ericsson.se>
>To: "'venkat devarajan'" = <venkat026@hotmail.com>, dhcwg@ietf.org
>Subject: RE: [dhcwg] doubt regarding = DHCPREQUEST
>Date: Tue, 9 Oct 2001 08:36:04 -0500
>
>The client may well not have an address of = sufficient scope it can use to
>communicate with the server.
>
>If the server and client are on the same link, = then sure the link local
>address could be used (and in this case the = server could send the client
>the unicast option in the Advertise).
>
>However, if the server is off-link, then the = client can't communicate with
>the server directly. Also, if you have multiple = relays, won't it be useful
>to be able to use the one that is up in case one = fails?
>
>Also, remember that IPv6 uses a lot of = multicasting (no broadcasting) and
>hence only those systems that are playing a DHCP = role will receive these
>packets. So, the cost of multicasting them is = not very high.
>
>- Bernie Volz
>
>-----Original Message-----
>From: venkat devarajan [mailto:venkat026@hotmail.com]<= /FONT>
>Sent: Tuesday, October 09, 2001 7:54 AM
>To: dhcwg@ietf.org
>Subject: [dhcwg] doubt regarding = DHCPREQUEST
>
>
>Hi ,
>I am Venkat working in Sun Microsystems.
>I have a doubt regarding the DHCPREQUEST message = broadcast.
>
>Doubt:
>Why is a DHCPREQUEST for Address Reuse or an = lease time extension broadcast
>to all other servers ? could it not be sent to = that dhcp server alone that
>provided the client with the ip adrress ?
>
>Regards,
>Venkat
>
>___________________________________________________________= ______
>Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp
>
>
>_______________________________________________
>dhcwg mailing list
>dhcwg@ietf.org
>http://www1.ietf.org/mailman/listinfo/dhcwg=


_______________________________________________________________= __
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp


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

------_=_NextPart_001_01C150E2.8293A670-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Oct 9 13:13:25 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08402; Tue, 9 Oct 2001 13:13:25 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA29687; Tue, 9 Oct 2001 13:11:11 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA29657 for ; Tue, 9 Oct 2001 13:11:09 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08326 for ; Tue, 9 Oct 2001 13:11:05 -0400 (EDT) Received: from rdroms-w2k.cisco.com ([161.44.150.36]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id NAA14178; Tue, 9 Oct 2001 13:10:36 -0400 (EDT) Message-Id: <4.3.2.7.2.20011009131020.00bb5f78@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 09 Oct 2001 13:11:59 -0400 To: "venkat devarajan" From: Ralph Droms Subject: Re: [dhcwg] doubt regarding DHCPREQUEST Cc: dhcwg@ietf.org In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org The first DHCPREQUEST, sent at T1, is unicast to the server that provided the IP address to the client. If the client doesn't hear from that server by time T2, the client broadcasts its DHCPREQUEST to find any available server. - Ralph Droms At 05:24 PM 10/9/2001 +0530, venkat devarajan wrote: >Hi , >I am Venkat working in Sun Microsystems. >I have a doubt regarding the DHCPREQUEST message broadcast. > >Doubt: >Why is a DHCPREQUEST for Address Reuse or an lease time extension >broadcast to all other servers ? could it not be sent to that dhcp server >alone that provided the client with the ip adrress ? > >Regards, >Venkat > >_________________________________________________________________ >Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp > > >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >http://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Oct 10 10:44:39 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11480; Wed, 10 Oct 2001 10:44:39 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA17892; Wed, 10 Oct 2001 10:43:16 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA17835 for ; Wed, 10 Oct 2001 10:43:13 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11450 for ; Wed, 10 Oct 2001 10:43:11 -0400 (EDT) Received: from rdroms-w2k.cisco.com (dhcp-161-44-149-111.cisco.com [161.44.149.111]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id KAA24218; Wed, 10 Oct 2001 10:42:39 -0400 (EDT) Message-Id: <4.3.2.7.2.20011010102724.03a67e50@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 10 Oct 2001 10:27:59 -0400 To: "Guja, ArturX" From: Ralph Droms Subject: Re: [dhcwg] Retransmission side Cc: "Dhcwg (E-mail)" In-Reply-To: <413FBB0BA5AED1119122000083234B1A0247B425@alpha.igk.intel.c om> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Yes, your understanding of the retransmission mechanism is correct... - Ralph At 08:51 AM 9/20/2001 +0200, Guja, ArturX wrote: > > Hello, > > > > I've looked hard into the recent discussion on retransmission. > > I would like to get one thing straight, correct me if I'm wrong with this: > > > > If a message from the client to the server is "Lost In Transit", > > the client retransmits. (OK so far :)) > > > > If a message from the server to the client is "LIT", the CLIENT > > retransmits its message. The server notes the repeat and replies > > with the same data as before. The server itself does not check, > > whether the reply reached the client. > > > > (Except for Reconfig-Init, which is a server-initiated exchange, > > so the server retransmits this message until it gets the REQUEST > > from the client.) > > > > I hope I understood your intentions in this matter. > > > > Please, comment. > > > > Artur G. > > (TUG student) > >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >http://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Oct 10 10:44:42 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11478; Wed, 10 Oct 2001 10:44:37 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA17876; Wed, 10 Oct 2001 10:43:15 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA17832 for ; Wed, 10 Oct 2001 10:43:13 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11448 for ; Wed, 10 Oct 2001 10:43:11 -0400 (EDT) Received: from rdroms-w2k.cisco.com (dhcp-161-44-149-111.cisco.com [161.44.149.111]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id KAA24215; Wed, 10 Oct 2001 10:42:38 -0400 (EDT) Message-Id: <4.3.2.7.2.20011010102201.00bbe400@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 10 Oct 2001 10:26:49 -0400 To: "Guja, ArturX" From: Ralph Droms Subject: Re: [dhcwg] Client identification clarification Cc: "Dhcwg (E-mail)" In-Reply-To: <413FBB0BA5AED1119122000083234B1A0247B427@alpha.igk.intel.c om> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org The DUID uniquely identifies a client, but gives no additional information about a client. The DHCPv6 server can make decisions about how to assign addresses based on any other available information: what other options the client has requested, what link the client is attached to, etc. DHCPv4 a "Vendor class identifier" option, through which a client can pass more information to the server. We haven't defined a "Vendor class identifier" for DHCPv6. If there is interest, we can consider adding it to the spec doc. - Ralph At 10:05 AM 9/20/2001 +0200, Guja, ArturX wrote: >Ok, here comes another one :))) > >Questions: >How does the server identify the client? How does it choose >what address to assign to the client? > >How I understood the answers: >The clients sends a DUID option, that's clear (although the >nature of the DUID is still unspecified, let's assume I've got >random numbers or ethernet addresses as DUIDs). Fine. > >A client binding is a tuple. Fine. > >So does it suffice, if a server has an address range, eg: >from 2000:: to 2000::ffff and assigns hose addresses to >all clients requesting them. > >Or should there be some other distinction? What I'm looking >here for is some way to let the administrator manage the >addresses in a better way. > >One thing, though: The server does not know anything else >about the client, apart from the DUID and IAID. Or does it??? > >Thank you all for your help here :))) > >Artur G. > >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >http://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Oct 10 10:45:11 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11555; Wed, 10 Oct 2001 10:45:06 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA18005; Wed, 10 Oct 2001 10:44:21 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA17982 for ; Wed, 10 Oct 2001 10:44:14 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11470 for ; Wed, 10 Oct 2001 10:44:12 -0400 (EDT) Received: from rdroms-w2k.cisco.com (dhcp-161-44-149-111.cisco.com [161.44.149.111]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id KAA24221; Wed, 10 Oct 2001 10:42:39 -0400 (EDT) Message-Id: <4.3.2.7.2.20011010103715.03a6e428@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 10 Oct 2001 10:40:34 -0400 To: Jim Bound From: Ralph Droms Subject: Re: Re[2]: [dhcwg] Overconstraining Cc: Artur Guja , "Dhcwg (E-mail)" In-Reply-To: References: <1141412763.20010922125901@3miasto.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org I've changed the text (section 16.1.1) to allow selection of a less-preferable server. An interim rev of the DHCPv6 spec is now available at http://www.dhcp.org - Ralph At 12:23 PM 9/22/2001 -0400, Jim Bound wrote: >ralph and I got input and it will be clear in the next rev that the client >can go use less preferred advertise if it chooses. making it a SHOULD >would permit implementors to do this. SHOULD means do this unless you >have a really good reason to not do this. > > >/jim > > >On Sat, 22 Sep 2001, Artur Guja wrote: > > > > > JB> If it was a SHOULD would that be fine? I don't think going back to > > JB> solicit in the spec is prudent though? > > > > Of course, going back to SOLICIT is a bit wierd. > > > > But if the client got more than one advertise, > > it chooses the best one. If this one fails, > > it could settle on a less preferable one. > > Of course, it there was only one ADVERTISE, > > or the rest of them were unacceptable, the client > > MUST abort (in my opinion), or else we could get an > > infinite loop of SOLICITs. > > > > Artur > > > > > > >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >http://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Oct 10 17:39:15 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21756; Wed, 10 Oct 2001 17:39:11 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA02313; Wed, 10 Oct 2001 17:38:05 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA02288 for ; Wed, 10 Oct 2001 17:38:03 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21730 for ; Wed, 10 Oct 2001 17:38:01 -0400 (EDT) Received: from rdroms-w2k.cisco.com (rtp-vpn1-182.cisco.com [10.82.224.182]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id RAA22386 for ; Wed, 10 Oct 2001 17:37:33 -0400 (EDT) Message-Id: <4.3.2.7.2.20011010173146.00bb4d80@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 10 Oct 2001 17:36:46 -0400 To: dhcwg@ietf.org From: Ralph Droms Subject: Re: [dhcwg] Interface In-Reply-To: References: <"Your message with ID" <200109210524.f8L5Ovt00458@grosse.bisbee.fugue.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Erik - I was about to make a change to the DHCPv6 spec based on this thread, when I realized I don't understand what the proposed text means. You wrote: MUST send on that interface to ensure that the packet is guaranteed to appear on the correct link (*). If the message appears on the wrong link the agent will be confused. *) This ensures that the packet arrives on the correct link even in the case when a node has multiple interfaces on the same link but has incorrect information about which interfaces connect to which links. Do you mean: The client MUST send the message on an interface that will cause the message to be delivered to the agent through the link to which the interface the client is trying to obtain configuration information for is attached. The client SHOULD send the message through the interface for which the client is trying to obtain configuration information. The client MAY send the message through another interface if the client has multiple interfaces on the same link. - Ralph At 10:26 AM 9/21/2001 +0200, Erik Nordmark wrote: > > > > I don't know what to say, Erik. It feels to me like you are trying > > to open the protocol to breakage in order to be pedantic. What > > matters to me is not the precise wording of RFC2119, but rather > > whether or not the protocol specification we arrive at will result in > > interoperable implementations. > > > > If we turn this particular MUST into a SHOULD, I promise you that > > there will be interoperability problems. I speak on the basis of a > > wealth of personal experience with DHCP client implementations. > >OK - I sense the equivalent of grade inflation here caused by presumed >clueless >implementors. Need to update RFC 2119 with the "REALLY MUST" and "REALLY MUST >NOT" to deal with this :-) :-) > > > I argued with you about the particulars because you gave IEEE802.3ad > > as an example of why we need to change this MUST into a SHOULD, and it > > was not a valid example. So I would really appreciate it if we could > > keep this as a MUST. > >No, I did NOT! Please re-read the email thread. >The reason for changing it (or clarifying the constraint) was >draft-ietf-ipngwg-scoping-arch-02.txt. > >But I haven't read what the actual text says so this might all be a red >herring. I responded to an email which had an explanation which essentially >said (with significant ad-libbing) > MUST send on that interface since otherwise the agent will be > confused. >This statement is incorrect. >But if the statement is instead > MUST send on that interface to ensure that the packet is guaranteed > to appear on the correct link (*). If the message appears on the > wrong > link the agent will be confused. > *) This ensures that the packet arrives on the correct link even > in the case when a node has multiple interfaces on the same link > but has incorrect information about which interfaces connect to > which links. >I think the footnote can be omitted - but it might help future readers to >understand the background. > > Erik > > >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >http://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Oct 10 22:01:28 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25559; Wed, 10 Oct 2001 22:01:28 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA10260; Wed, 10 Oct 2001 22:00:42 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA10233 for ; Wed, 10 Oct 2001 22:00:41 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25547 for ; Wed, 10 Oct 2001 22:00:38 -0400 (EDT) Received: from rdroms-w2k.cisco.com (rtp-vpn1-17.cisco.com [10.82.224.17]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id WAA09658 for ; Wed, 10 Oct 2001 22:00:10 -0400 (EDT) Message-Id: <4.3.2.7.2.20011010215126.00b67ff8@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 10 Oct 2001 22:01:31 -0400 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [dhcwg] Rev of DHCPv6 spec Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org I've finished another rev of the DHCPv6 spec (-20d), which is available at http://www.dhcp.org/dhcpv6.tty I plan to submit this draft of the spec to the IETF for publication on 10/12. The list of issues addressed by this draft is included below; these issues were discussed at the DHC WG meeting in London (8/2001). The -20d draft does not include any changes related to IAs. The changes related to IAs will appear in the next published rev of the draft. - Ralph ===== Issues from London addressed in this draft. * Should addresses in an Advertise message be "real" addresses or "informational"; e.g., just prefixes? WG consensus: addresses in Advertise are the addresses the server will return in a subsequent Reply; client supplies those addresses to server in IA in Request message * Servers will only assign complete addresses and not prefixes (e.g., to be used by the client for stateless autoconfiguration) WG consensus: yes; prefix advertisement is handled through ND * How and when does the client use DAD on addresses in Advertise and Reply messages? WG consensus: Client does DAD on addresses in Reply message and responds with Decline if addresses unacceptable (e.g., already in use) * Advertise message SHOULD include options for all OROs that were included in the Solicit if the server is willing/capable of offering a value for that option WG consensus: yes * Add "NAK" function: If the server finds that the prefix on one or more IP addresses in any IA in the {Request, Confirm, Rebind} message is not a valid prefix for the link to which the client is connected, the server MUST send an NoPrefixMatch status in the IA status field for that IA in the DHCP Reply message. WG consensus: yes; indicate "NAK" through return of "NoPrefixMatch" error code. Add text allowing client to ignore "NoPrefixMatch" from other servers if ACK received from at least one server. * Define DUID to be one of: - Link-layer address plus time - Vendor-assigned unique ID - Link-layer address - IMSI - IMEI WG consensus: yes; based on text submitted by Lemon with extensions from subsequent WG discussion MODIFICATION: drop IMSI, IMEI * Use IPsec for secure agent/server communication WG consensus: yes; add text to draft * Add an "error code" option, to indicate errors not connected with a specific option WG consensus: yes; should allow inclusion of text message * Tighten up language for unicasting Reconfigure-Init; in particular, the server may not have an appropriate address to use to send the message to the client. WG consensus: yes * Reply to a Confirm should be a simple ACK/NAK without changing any values in options WG consensus: Discussion to be taken to mailing list Note: check to make sure there is text in the draft describing behavior if no response is heard to a Confirm FOLLOWUP: Issue was not posted to mailing list. Draft now defines Confirm to be simple ACK/NAK. * Reply to Decline or Release should carry no options WG consensus: yes * Restrict options in Decline or Release to IA with text to allow other options in the future WG consensus: no; this is an overspecification * Server does not respond to Solicit when client wants addresses and server has no addresses WG consensus: Server should be allowed to respond * Include only options specifically mentioned in the text in the DHCPv6 spec; move others to second doc or separate appendix WG consensus: anything we have consensus on stays; anything else gets punted to a separate draft. * Add 'secs' field to fixed header WG consensus: if client retransmits, MUST send option called "milliseconds" * Make the preference field an option WG consensus: yes * Describe message transmission and retransmission in a separate section of the spec and reference that text throughout the remainder of the spec WG consensus: yes * Discard the client unicast or recheck the entire spec for consistency in reference to message transmission WG consensus: yes, authors to fix spec * Remove client link-local address from client message header. Agent can then determine link-local from source (IP header) in client message and insert into agent->server message. Server responds to source from IP header (whether agent or client). WG consensus: Yes _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Oct 10 22:03:06 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25591; Wed, 10 Oct 2001 22:03:06 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA10333; Wed, 10 Oct 2001 22:02:35 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA10314 for ; Wed, 10 Oct 2001 22:02:34 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25588 for ; Wed, 10 Oct 2001 22:02:31 -0400 (EDT) Received: from rdroms-w2k.cisco.com (rtp-vpn1-17.cisco.com [10.82.224.17]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id WAA09784; Wed, 10 Oct 2001 22:02:02 -0400 (EDT) Message-Id: <4.3.2.7.2.20011010220208.00ba5458@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 10 Oct 2001 22:03:24 -0400 To: dhcwg@ietf.org From: Ralph Droms Subject: Re: [dhcwg] Interface Cc: dhcwg@ietf.org In-Reply-To: <4.3.2.7.2.20011010173146.00bb4d80@funnel.cisco.com> References: <"Your message with ID" <200109210524.f8L5Ovt00458@grosse.bisbee.fugue.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org I made changes in the -20d rev of the DHCPv6 spec based on my interpretation of Erik Nordmark's text. If that interpretation turns out to be wrong, I'll fix it... - Ralph At 05:36 PM 10/10/2001 -0400, Ralph Droms wrote: >Erik - I was about to make a change to the DHCPv6 spec based on this >thread, when I realized I don't understand what the proposed text means. > >You wrote: > > MUST send on that interface to ensure that the packet is guaranteed > to appear on the correct link (*). If the message appears on the > wrong > link the agent will be confused. > *) This ensures that the packet arrives on the correct link even > in the case when a node has multiple interfaces on the same link > but has incorrect information about which interfaces connect to > which links. > >Do you mean: > >The client MUST send the message on an interface that will cause >the message to be delivered to the agent through the link to which >the interface the client is trying to obtain configuration >information for is attached. The client SHOULD send the >message through the interface for which the client is trying to >obtain configuration information. The client MAY send the message >through another interface if the client has multiple interfaces >on the same link. > >- Ralph > >At 10:26 AM 9/21/2001 +0200, Erik Nordmark wrote: >> > >> > I don't know what to say, Erik. It feels to me like you are trying >> > to open the protocol to breakage in order to be pedantic. What >> > matters to me is not the precise wording of RFC2119, but rather >> > whether or not the protocol specification we arrive at will result in >> > interoperable implementations. >> > >> > If we turn this particular MUST into a SHOULD, I promise you that >> > there will be interoperability problems. I speak on the basis of a >> > wealth of personal experience with DHCP client implementations. >> >>OK - I sense the equivalent of grade inflation here caused by presumed >>clueless >>implementors. Need to update RFC 2119 with the "REALLY MUST" and "REALLY MUST >>NOT" to deal with this :-) :-) >> >> > I argued with you about the particulars because you gave IEEE802.3ad >> > as an example of why we need to change this MUST into a SHOULD, and it >> > was not a valid example. So I would really appreciate it if we could >> > keep this as a MUST. >> >>No, I did NOT! Please re-read the email thread. >>The reason for changing it (or clarifying the constraint) was >>draft-ietf-ipngwg-scoping-arch-02.txt. >> >>But I haven't read what the actual text says so this might all be a red >>herring. I responded to an email which had an explanation which essentially >>said (with significant ad-libbing) >> MUST send on that interface since otherwise the agent will be >> confused. >>This statement is incorrect. >>But if the statement is instead >> MUST send on that interface to ensure that the packet is guaranteed >> to appear on the correct link (*). If the message appears on the >> wrong >> link the agent will be confused. >> *) This ensures that the packet arrives on the correct link even >> in the case when a node has multiple interfaces on the same link >> but has incorrect information about which interfaces connect to >> which links. >>I think the footnote can be omitted - but it might help future readers to >>understand the background. >> >> Erik >> >> >>_______________________________________________ >>dhcwg mailing list >>dhcwg@ietf.org >>http://www1.ietf.org/mailman/listinfo/dhcwg > > >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >http://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Oct 11 02:22:05 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA10222; Thu, 11 Oct 2001 02:22:05 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA23871; Thu, 11 Oct 2001 02:16:22 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA23843 for ; Thu, 11 Oct 2001 02:16:20 -0400 (EDT) Received: from hotmail.com (f169.law14.hotmail.com [64.4.21.169]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA09881 for ; Thu, 11 Oct 2001 02:16:17 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 10 Oct 2001 23:15:47 -0700 Received: from 192.18.17.3 by lw14fd.law14.hotmail.msn.com with HTTP; Thu, 11 Oct 2001 06:15:47 GMT X-Originating-IP: [192.18.17.3] From: "venkat devarajan" To: dhcwg@ietf.org Date: Thu, 11 Oct 2001 11:45:47 +0530 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 11 Oct 2001 06:15:47.0708 (UTC) FILETIME=[2B0033C0:01C1521C] Subject: [dhcwg] dhcp request Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Hi, I have a little doubt regarding the following .. taken from the rfc 2131 the client sends out a dhcp request for allocation of a previously allocated netwrok address and the rfc says "Servers with knowledge of the client's configuration parameters respond with a DHCPACK message to the client. Servers SHOULD NOT check that the client's network address is already in use; the client may respond to ICMP Echo Request messages at this point." what does it mean when it says the server SHOULD NOT check if the network address is already in use ? how does the server ACK the request for an ip without verifying it ? and how does more than one server respond to this request ? is it not that a particular network address can only be given out by a single server( or even if there is more than one server for increased reliability,will the coherency factors not come into play) ? regards, Venkat _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Oct 11 09:01:00 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15602; Thu, 11 Oct 2001 09:01:00 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA04712; Thu, 11 Oct 2001 08:59:58 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA04686 for ; Thu, 11 Oct 2001 08:59:56 -0400 (EDT) Received: from e31.bld.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15557 for ; Thu, 11 Oct 2001 08:59:53 -0400 (EDT) Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23]) by e31.bld.us.ibm.com (8.9.3/8.9.3) with ESMTP id IAA31480 for ; Thu, 11 Oct 2001 08:57:30 -0400 Received: from d03nm080.boulder.ibm.com (d03nm080.boulder.ibm.com [9.99.140.64]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO v4.98) with ESMTP id f9BCxs0151864 for ; Thu, 11 Oct 2001 06:59:54 -0600 Importance: Normal Subject: [dhcwg] dhcp request To: dhcwg@ietf.org X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "Bob Chambers" Date: Thu, 11 Oct 2001 07:59:10 -0500 X-MIMETrack: Serialize by Router on D03NM080/03/M/IBM(Release 5.0.8 |June 18, 2001) at 10/11/2001 06:59:54 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Client behavior is governed by which of six "states" the client is in at the time a DHCP message is sent. Server responses are governed by the content of the client's message, and the server's awareness of the network at the time. In the instance you describe, the client interface seems to have been previously configured via DHCP. It may or may not have a valid lease, or it may not know if a lease is still valid. This, plus the indication that the DHCPREQUEST message was broadcast could mean that this client interface is in the INIT-REBOOT state, and may or may not respond to an ARP or PING. For this reason, it would not be fruitful for a server to test the address. In the INIT-REBOOT state the DHCPREQUEST message is broadcast, because the client may have been moved to a different area of the network, and could need address assignment from a different server. (The client needs to get a DHCPNAK message from any server in this case). Overall, DHCP makes very efficient use of the number and scope of packets sent between client and server. For example, a client may receive offers from multiple servers in response to a DHCPDISCOVER message it sent. The client broadcasts a DHCPREQUEST message that contains the id of the server it has selected. In this manner, the client accepts one offer and rejects all others with a single packet. I am told that Chapter 3, of the IBM Redbook "Beyond DHCP, Work Your Internetwork with Dynamic IP" contains a good explanation of the client states, and different DHCP messages. You might find this book to be a helpful companion to the RFCs. At one time this book was free at www.redbooks.ibm.com Regards, Bob _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Oct 11 16:26:05 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24488; Thu, 11 Oct 2001 16:26:05 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA20603; Thu, 11 Oct 2001 16:25:03 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA20580 for ; Thu, 11 Oct 2001 16:25:02 -0400 (EDT) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24475 for ; Thu, 11 Oct 2001 16:25:01 -0400 (EDT) Received: from bebop.France.Sun.COM ([129.157.174.15]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA18287; Thu, 11 Oct 2001 14:24:53 -0600 (MDT) Received: from lillen (vpn133-11.EBay.Sun.COM [129.150.133.11]) by bebop.France.Sun.COM (8.10.2+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id f9BKP0q08468; Thu, 11 Oct 2001 22:25:00 +0200 (MET DST) Date: Thu, 11 Oct 2001 22:19:47 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: [dhcwg] Interface To: Ralph Droms Cc: dhcwg@ietf.org In-Reply-To: "Your message with ID" <4.3.2.7.2.20011010173146.00bb4d80@funnel.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org > The client MUST send the message on an interface that will cause > the message to be delivered to the agent through the link to which > the interface the client is trying to obtain configuration > information for is attached. The client SHOULD send the > message through the interface for which the client is trying to > obtain configuration information. The client MAY send the message > through another interface if the client has multiple interfaces > on the same link. Yes, that was what I was trying to say. I think it might make sense to make the last sentence stronger by saying The client MAY send the message through another interface attached to the same link if and only if the client is certain that the two interfaces are attached to the same link. Erik _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Oct 11 16:38:00 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24866; Thu, 11 Oct 2001 16:37:59 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA21188; Thu, 11 Oct 2001 16:37:17 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA21164 for ; Thu, 11 Oct 2001 16:37:16 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24851 for ; Thu, 11 Oct 2001 16:37:11 -0400 (EDT) Received: from green.bisbee.fugue.com (3Cust115.tnt5.nyc3.da.uu.net [63.23.118.115]) by toccata.fugue.com (8.11.3/8.6.11) with ESMTP id f9BKacv28270; Thu, 11 Oct 2001 13:36:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by green.bisbee.fugue.com (8.10.2/8.6.11) with ESMTP id f9BKbII01429; Thu, 11 Oct 2001 16:37:18 -0400 (EDT) Date: Thu, 11 Oct 2001 16:37:18 -0400 Subject: Re: [dhcwg] Interface Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v472) Cc: Ralph Droms , dhcwg@ietf.org To: Erik Nordmark From: Ted Lemon In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.472) Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 7bit > The client MAY send the message > through another interface attached to the same link if and only if the > client > is certain that the two interfaces are attached to the same link. I think this is the right way to express it. _MelloN_ _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Oct 11 16:57:02 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25244; Thu, 11 Oct 2001 16:57:02 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA21541; Thu, 11 Oct 2001 16:56:24 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA21519 for ; Thu, 11 Oct 2001 16:56:22 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25211 for ; Thu, 11 Oct 2001 16:56:21 -0400 (EDT) Received: from rdroms-w2k.cisco.com ([161.44.150.36]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id QAA21997 for ; Thu, 11 Oct 2001 16:55:55 -0400 (EDT) Message-Id: <4.3.2.7.2.20011011164936.04732738@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 11 Oct 2001 16:57:16 -0400 To: dhcwg@ietf.org From: Ralph Droms Subject: Re: [dhcwg] Interface In-Reply-To: References: <"Your message with ID" <4.3.2.7.2.20011010173146.00bb4d80@funnel.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Following up on Erik's comments... So, what I wrote in the -20d rev turns out to be (I did some last minute wordsmithing that [may or may not have] improved the readability: The Confirm message MUST be transmitted on the link that the interface for which configuration information is being obtained is attached to. The client SHOULD send the message through that interface. If the client has multiple interfaces attached to the same link, the client MAY choose to send the message through another interface attached to that link. and (for those messages that might be unicast): If the client multicasts the Request message, the message MUST be transmitted on the link that the interface for which configuration information is being obtained is attached to. The client SHOULD send the message through that interface. If the client has multiple interfaces attached to the same link, the client MAY choose to send the message through another interface attached to that link. I will substitute Erik's suggested replacement for the last sentence: The client MAY send the message through another interface attached to the same link if and only if the client is certain that the two interfaces are attached to the same link. - Ralph At 10:19 PM 10/11/2001 +0200, Erik Nordmark wrote: > > The client MUST send the message on an interface that will cause > > the message to be delivered to the agent through the link to which > > the interface the client is trying to obtain configuration > > information for is attached. The client SHOULD send the > > message through the interface for which the client is trying to > > obtain configuration information. The client MAY send the message > > through another interface if the client has multiple interfaces > > on the same link. > >Yes, that was what I was trying to say. > >I think it might make sense to make the last sentence stronger by >saying > The client MAY send the message > through another interface attached to the same link if and only if the > client > is certain that the two interfaces are attached to the same link. > > Erik _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Oct 12 02:57:11 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA19063; Fri, 12 Oct 2001 02:57:11 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA12668; Fri, 12 Oct 2001 02:54:36 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA12642 for ; Fri, 12 Oct 2001 02:54:34 -0400 (EDT) Received: from ausmtp01.au.ibm.com (ausmtp01.au.ibm.COM [202.135.136.97]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18870 for ; Fri, 12 Oct 2001 02:54:24 -0400 (EDT) From: skodati@in.ibm.com Received: from f02n16e.au.ibm.com by ausmtp01.au.ibm.com (IBM AP 2.0) with ESMTP id f9C6nIH151014; Fri, 12 Oct 2001 16:49:18 +1000 Received: from d73mta01.au.ibm.com (f06n01s [9.185.166.65]) by f02n16e.au.ibm.com (8.11.1m3/NCO v4.97.1) with SMTP id f9C6qa537706; Fri, 12 Oct 2001 16:52:37 +1000 Received: by d73mta01.au.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id CA256AE3.0025DD6A ; Fri, 12 Oct 2001 16:53:35 +1000 X-Lotus-FromDomain: IBMIN@IBMAU To: rdroms@cisco.com, dhcwg@ietf.org cc: bsuparna@in.ibm.com, rsharada@in.ibm.com Message-ID: Date: Fri, 12 Oct 2001 12:18:14 +0530 Subject: Re: [dhcwg] Rev of DHCPv6 spec Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org I would like to get clarification on when does a server send an unicast option, 1. does the server send unicast option whenever the client is on the same link (20.11 is not clear about it) (or) 2. Is it an administrative policy that decides if the client can unicast/multicast of messages. If it is so, is there any example of the scenario where the server would not specify the option despite being on the same link. 3. why is the client required to check if the client and server are on the same link if unicast option is already obtained from the server ( 16.1.1 ) And also, Is it not sufficient to have both client and server to be on the same link to unicast client's message ?, if so what is the server response to client's unicast if it didn't send unicast option to the client and still gets messages unicast'ed to it. -suresh Ralph Droms on 10/11/2001 07:31:31 AM Please respond to Ralph Droms To: dhcwg@ietf.org cc: (bcc: Suresh Kodati/India/IBM) Subject: [dhcwg] Rev of DHCPv6 spec I've finished another rev of the DHCPv6 spec (-20d), which is available at http://www.dhcp.org/dhcpv6.tty I plan to submit this draft of the spec to the IETF for publication on 10/12. The list of issues addressed by this draft is included below; these issues were discussed at the DHC WG meeting in London (8/2001). The -20d draft does not include any changes related to IAs. The changes related to IAs will appear in the next published rev of the draft. - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Oct 12 04:07:32 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20335; Fri, 12 Oct 2001 04:07:31 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA14797; Fri, 12 Oct 2001 04:03:52 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA14776 for ; Fri, 12 Oct 2001 04:03:50 -0400 (EDT) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20327 for ; Fri, 12 Oct 2001 04:03:45 -0400 (EDT) Received: from bebop.France.Sun.COM ([129.157.174.15]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA01248 for ; Fri, 12 Oct 2001 02:03:37 -0600 (MDT) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.10.2+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id f9C83mq17904 for ; Fri, 12 Oct 2001 10:03:48 +0200 (MET DST) Date: Fri, 12 Oct 2001 09:58:42 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark To: dhcwg@ietf.org In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Subject: [dhcwg] Re: draft-ietf-dnsext-dhcid-rr-03.txt (Fwd) Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org >----------------Begin Forwarded Message----------------< Date: Thu, 11 Oct 2001 18:17:06 -0700 From: "Randy Bush" Subject: Re: draft-ietf-dnsext-dhcid-rr-03.txt To: "namedroppers" > Date: Wed, 26 Sep 2001 11:56:35 -0700 > this starts a two week wg last call on draft-ietf-dnsext-dhcid-rr-03.txt > for proposed standard. the wg last call has ended. there seems to have been zero comment on this draft. unless i hear to the contrary, i will assume that no one is sufficiently interssted in adding yarr, and we can let it die. randy to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. >----------------End Forwarded Message----------------< _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Oct 12 06:07:36 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21023; Fri, 12 Oct 2001 06:07:32 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA18251; Fri, 12 Oct 2001 06:05:26 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA18215 for ; Fri, 12 Oct 2001 06:05:24 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20971 for ; Fri, 12 Oct 2001 06:05:18 -0400 (EDT) Received: from rdroms-w2k.cisco.com (rtp-vpn1-65.cisco.com [10.82.224.65]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id GAA04931; Fri, 12 Oct 2001 06:04:48 -0400 (EDT) Message-Id: <4.3.2.7.2.20011012055814.03a64ec8@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 12 Oct 2001 06:06:08 -0400 To: skodati@in.ibm.com From: Ralph Droms Subject: Re: [dhcwg] Rev of DHCPv6 spec Cc: dhcwg@ietf.org, bsuparna@in.ibm.com, rsharada@in.ibm.com In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org 1./2. the unicast option is an administrative policy; 3. I don't see any text in 16.1.1 that requires the client to check that the server is on the same link In response to your last question, the use of unicast isn't dependent on whether the client and server are on the same link. A client could use unicast to deliver DHCP messages to an off-link router. The draft doesn't specify how a server should react to a unicast message received from a client to which the server has not sent a unicast option. I imagine the right thing to do is to allow the server to process such messages. - Ralph At 12:18 PM 10/12/2001 +0530, skodati@in.ibm.com wrote: >I would like to get clarification on when does a server send an unicast >option, >1. does the server send unicast option whenever the client is on the same >link (20.11 is not clear about it) (or) >2. Is it an administrative policy that decides if the client can >unicast/multicast of messages. If it is so, is there any example of the >scenario where the server would not specify the option despite being on the >same link. >3. why is the client required to check if the client and server are on the >same link if unicast option is already obtained from the server ( 16.1.1 ) > >And also, > Is it not sufficient to have both client and server to be on the same link >to unicast client's message ?, if so what is the server response to >client's unicast if it didn't send unicast option to the client and still >gets messages unicast'ed to it. >-suresh > > >Ralph Droms on 10/11/2001 07:31:31 AM > >Please respond to Ralph Droms > >To: dhcwg@ietf.org >cc: (bcc: Suresh Kodati/India/IBM) >Subject: [dhcwg] Rev of DHCPv6 spec > > >I've finished another rev of the DHCPv6 spec (-20d), which is available at >http://www.dhcp.org/dhcpv6.tty I plan to submit this draft of the spec to >the IETF for publication on 10/12. The list of issues addressed by this >draft is included below; these issues were discussed at the DHC WG meeting >in London (8/2001). The -20d draft does not include any changes related to >IAs. The changes related to IAs will appear in the next published rev of >the draft. > >- Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Oct 12 09:33:43 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26583; Fri, 12 Oct 2001 09:33:43 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA25269; Fri, 12 Oct 2001 09:32:28 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA25247 for ; Fri, 12 Oct 2001 09:32:26 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26555 for ; Fri, 12 Oct 2001 09:32:21 -0400 (EDT) Received: from MJS-W2K.cisco.com (dhcp-161-44-149-158.cisco.com [161.44.149.158]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id JAA17459; Fri, 12 Oct 2001 09:31:55 -0400 (EDT) Message-Id: <4.3.2.7.2.20011012091725.01ad4a60@funnel.cisco.com> X-Sender: mjs@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 12 Oct 2001 09:32:56 -0400 To: Randy Bush From: Mark Stapp Cc: namedroppers , dhcwg@ietf.org In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [dhcwg] Re: draft-ietf-dnsext-dhcid-rr-03.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org I wonder whether the lack of objections to this draft might be interpreted another way. The rr is designed for use in networks where dhcp servers and clients are updating A and PTR rrs as dhcp protocol interactions take place. Since the dhcid rr doesn't have any special dns protocol semantic significance, it doesn't raise any contentious issues for the dns server community. It's not surprising, then, if the dns community doesn't have much objection to the new rr. The dhcp community has a dependency on this specification, however, and the use of this rr does have significance for us. Perhaps I've misunderstood the point of the wg last call: I thought it was a way of soliciting suggestions and complaints. I didn't realize that if no one objected, that the draft would die. That doesn't quite make sense to me, actually. In any case, I'm cross-posting this to the dhc working group list in the hope that some of that group's participants will express some support for this dnsext draft. If it dies, however quietly, the dhc group will have to start designing dhcp-dns interaction specifications from scratch. -- Mark At 06:17 PM 10/11/2001 -0700, Randy Bush wrote: > > Date: Wed, 26 Sep 2001 11:56:35 -0700 > > this starts a two week wg last call on draft-ietf-dnsext-dhcid-rr-03.txt > > for proposed standard. > >the wg last call has ended. there seems to have been zero comment on >this draft. unless i hear to the contrary, i will assume that no one >is sufficiently interssted in adding yarr, and we can let it die. > >randy > > >to unsubscribe send a message to namedroppers-request@ops.ietf.org with >the word 'unsubscribe' in a single line as the message text body. _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Oct 12 11:10:49 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00898; Fri, 12 Oct 2001 11:10:48 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA28148; Fri, 12 Oct 2001 11:09:55 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA28075 for ; Fri, 12 Oct 2001 11:09:52 -0400 (EDT) Received: from zrc2s03g.us.nortel.com (h66s122a103n47.user.nortelnetworks.com [47.103.122.66]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00810 for ; Fri, 12 Oct 2001 11:09:45 -0400 (EDT) Received: from smtprch2.nortel.com (erchg0k.us.nortel.com [47.113.64.104]) by zrc2s03g.us.nortel.com (8.9.3+Sun/8.9.1) with ESMTP id KAA15868 for ; Fri, 12 Oct 2001 10:09:21 -0500 (CDT) Received: from zsc4c000.us.nortel.com by smtprch2.nortel.com; Fri, 12 Oct 2001 10:02:18 -0500 Received: by zsc4c000.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 12 Oct 2001 08:08:29 -0700 Message-ID: <4F973E944951D311B6660008C7917CF0068C800A@zsc4c008.us.nortel.com> From: "Mark Llacuna" To: "'Bernie Volz (EUD)'" , "'venkat devarajan'" , dhcwg@ietf.org Subject: RE: [dhcwg] doubt regarding DHCPREQUEST Date: Fri, 12 Oct 2001 08:08:28 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1532F.BF835C70" X-Orig: Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1532F.BF835C70 Content-Type: text/plain; charset="iso-8859-1" :-----Original Message----- :From: Bernie Volz (EUD) [mailto:Bernie.Volz@am1.ericsson.se] :Sent: Tuesday, October 09, 2001 9:51 AM :To: 'venkat devarajan'; dhcwg@ietf.org :Subject: RE: [dhcwg] doubt regarding DHCPREQUEST :Actually, I had DHCPv6 on my brain when I responded. You're asking about DHCP for IPv4. :When a client doesn't yet have a lease on the address, it must broadcast since it has no valid source address. Also, the :broadcast serves to indicate to other servers that they were not selected by the client and can 'release' the address that they :temporarily allocated and offered to the client. :When a client has an address, the specification says it is unicast (RFC 2131): : o DHCPREQUEST generated during RENEWING state: : 'server identifier' MUST NOT be filled in, 'requested IP address' : option MUST NOT be filled in, 'ciaddr' MUST be filled in with : client's IP address. In this situation, the client is completely : configured, and is trying to extend its lease. This message will : be unicast, so no relay agents will be involved in its : transmission. Because 'giaddr' is therefore not filled in, the : DHCP server will trust the value in 'ciaddr', and use it when : replying to the client. :"This message will be unicast". My understanding is that this is the general behavior of a DHCP client. There are, however, special client implementations (proxy clients) that unicast lease renewals to a relay agent and not directly to the DHCP server. Also, I don't think RFC 2131 makes it an absolute requirement that lease renewals (before T2) have to be unicast directly to the server. Therefore, servers should also accommodate lease renewals with the 'giaddr' filled in and respond accordingly, that is, back to the relay agent. I remember there was a thread about this issue a long time ago, but the link I had to that thread no longer exists or may have been already moved. Mark :- Bernie :-----Original Message----- :From: venkat devarajan [mailto:venkat026@hotmail.com] :Sent: Tuesday, October 09, 2001 12:23 PM :To: dhcwg@ietf.org :Subject: RE: [dhcwg] doubt regarding DHCPREQUEST : : :Hi :does the client not know the server's IpAddress when getting a DHCPACK :/DHCPOFFER ? i am referring to the 'siaddr' field in the dhcp packet :structure . :Regrads, :Venkat :>From: "Bernie Volz (EUD)" :>To: "'venkat devarajan'" , dhcwg@ietf.org :>Subject: RE: [dhcwg] doubt regarding DHCPREQUEST :>Date: Tue, 9 Oct 2001 08:36:04 -0500 :> :>The client may well not have an address of sufficient scope it can use to :>communicate with the server. :> :>If the server and client are on the same link, then sure the link local :>address could be used (and in this case the server could send the client :>the unicast option in the Advertise). :> :>However, if the server is off-link, then the client can't communicate with :>the server directly. Also, if you have multiple relays, won't it be useful :>to be able to use the one that is up in case one fails? :> :>Also, remember that IPv6 uses a lot of multicasting (no broadcasting) and :>hence only those systems that are playing a DHCP role will receive these :>packets. So, the cost of multicasting them is not very high. :> :>- Bernie Volz :> :>-----Original Message----- :>From: venkat devarajan [mailto:venkat026@hotmail.com] :>Sent: Tuesday, October 09, 2001 7:54 AM :>To: dhcwg@ietf.org :>Subject: [dhcwg] doubt regarding DHCPREQUEST :> :> :>Hi , :>I am Venkat working in Sun Microsystems. :>I have a doubt regarding the DHCPREQUEST message broadcast. :> :>Doubt: :>Why is a DHCPREQUEST for Address Reuse or an lease time extension broadcast :>to all other servers ? could it not be sent to that dhcp server alone that :>provided the client with the ip adrress ? :> :>Regards, :>Venkat :> :>_________________________________________________________________ :>Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp :> :> :>_______________________________________________ :>dhcwg mailing list :>dhcwg@ietf.org :>http://www1.ietf.org/mailman/listinfo/dhcwg : : :_________________________________________________________________ :Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp : : :_______________________________________________ :dhcwg mailing list :dhcwg@ietf.org :http://www1.ietf.org/mailman/listinfo/dhcwg ------_=_NextPart_001_01C1532F.BF835C70 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] doubt regarding DHCPREQUEST

:-----Original Message-----
:From: Bernie Volz (EUD) [mailto:Bernie.Volz@am1.erics= son.se]
:Sent: Tuesday, October 09, 2001 9:51 AM
:To: 'venkat devarajan'; dhcwg@ietf.org
:Subject: RE: [dhcwg] doubt regarding DHCPREQUEST


:Actually, I had DHCPv6 on my brain when I responded. = You're asking about DHCP for IPv4.
:When a client doesn't yet have a lease on the address, = it must broadcast since it has no valid source address. Also, = the :broadcast serves to indicate to other servers that they = were not selected by the client and can 'release' the address that = they :temporarily allocated and offered to the = client.

:When a client has an address, the specification says it = is unicast (RFC 2131):
:  o DHCPREQUEST generated during RENEWING state: =
:      'server identifier' MUST = NOT be filled in, 'requested IP address'
:      option MUST NOT be filled = in, 'ciaddr' MUST be filled in with
:      client's IP address. In = this situation, the client is completely
:      configured, and is trying = to extend its lease. This message will
:      be unicast, so no relay = agents will be involved in its
:      transmission.  = Because 'giaddr' is therefore not filled in, the
:      DHCP server will trust = the value in 'ciaddr', and use it when
:      replying to the client. =
:"This message will be unicast".

My understanding is that this is the = general behavior of a DHCP client.
There are, however, special client = implementations (proxy clients) that
unicast lease renewals to a relay = agent and not directly to the DHCP
server.

Also, I don't think RFC 2131 makes it = an absolute requirement that
lease renewals (before T2) have to be = unicast directly to the server.
Therefore, servers should also = accommodate lease renewals with the
'giaddr' filled in and respond = accordingly, that is, back to the relay
agent.

I remember there was a thread about = this issue a long time ago, but
the link I had to that thread no = longer exists or may have been already
moved.

Mark


:- Bernie
:-----Original Message-----
:From: venkat devarajan [mailto:venkat026@hotmail.com] =
:Sent: Tuesday, October 09, 2001 12:23 PM
:To: dhcwg@ietf.org
:Subject: RE: [dhcwg] doubt regarding DHCPREQUEST
:
:
:Hi
:does the client not know the server's IpAddress when = getting a DHCPACK  
:/DHCPOFFER ? i am referring to the 'siaddr' field in the = dhcp packet
:structure .
:Regrads,
:Venkat
:>From: "Bernie Volz (EUD)" = <Bernie.Volz@am1.ericsson.se>
:>To: "'venkat devarajan'" = <venkat026@hotmail.com>, dhcwg@ietf.org
:>Subject: RE: [dhcwg] doubt regarding DHCPREQUEST =
:>Date: Tue, 9 Oct 2001 08:36:04 -0500
:>
:>The client may well not have an address of = sufficient scope it can use to
:>communicate with the server.
:>
:>If the server and client are on the same link, then = sure the link local
:>address could be used (and in this case the server = could send the client
:>the unicast option in the Advertise).
:>
:>However, if the server is off-link, then the client = can't communicate with
:>the server directly. Also, if you have multiple = relays, won't it be useful
:>to be able to use the one that is up in case one = fails?
:>
:>Also, remember that IPv6 uses a lot of multicasting = (no broadcasting) and
:>hence only those systems that are playing a DHCP = role will receive these
:>packets. So, the cost of multicasting them is not = very high.
:>
:>- Bernie Volz
:>
:>-----Original Message-----
:>From: venkat devarajan [mailto:venkat026@hotmail.com] =
:>Sent: Tuesday, October 09, 2001 7:54 AM
:>To: dhcwg@ietf.org
:>Subject: [dhcwg] doubt regarding DHCPREQUEST
:>
:>
:>Hi ,
:>I am Venkat working in Sun Microsystems.
:>I have a doubt regarding the DHCPREQUEST message = broadcast.
:>
:>Doubt:
:>Why is a DHCPREQUEST for Address Reuse or an lease = time extension broadcast
:>to all other servers ? could it not be sent to that = dhcp server alone that
:>provided the client with the ip adrress ?
:>
:>Regards,
:>Venkat
:>
:>_____________________________________________________= ____________
:>Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp
:>
:>
:>_______________________________________________ =
:>dhcwg mailing list
:>dhcwg@ietf.org
:>http://www1.ietf.org/mailman/listinfo/dhcwg =
:
:
:_________________________________________________________= ________
:Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp
:
:
:_______________________________________________
:dhcwg mailing list
:dhcwg@ietf.org
:http://www1.ietf.org/mailman/listinfo/dhcwg =

------_=_NextPart_001_01C1532F.BF835C70-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Oct 12 13:04:25 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03595; Fri, 12 Oct 2001 13:04:25 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA02193; Fri, 12 Oct 2001 13:03:14 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA02162 for ; Fri, 12 Oct 2001 13:03:12 -0400 (EDT) Received: from rip.psg.com (exim@rip.psg.com [147.28.0.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03563 for ; Fri, 12 Oct 2001 13:03:07 -0400 (EDT) Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 15s5iH-000OFq-00; Fri, 12 Oct 2001 10:03:09 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Mark Stapp Cc: namedroppers , dhcwg@ietf.org References: <4.3.2.7.2.20011012091725.01ad4a60@funnel.cisco.com> Message-Id: Date: Fri, 12 Oct 2001 10:03:09 -0700 Content-Transfer-Encoding: 7bit Subject: [dhcwg] Re: draft-ietf-dnsext-dhcid-rr-03.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 7bit if folk want it, they should speak up. we don't need a hoard. just a few folk to say "yes, we want this." randy _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Oct 12 13:11:36 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03783; Fri, 12 Oct 2001 13:11:36 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA02364; Fri, 12 Oct 2001 13:10:54 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA02333 for ; Fri, 12 Oct 2001 13:10:52 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03764 for ; Fri, 12 Oct 2001 13:10:47 -0400 (EDT) Received: from rdroms-w2k.cisco.com (rtp-vpn1-224.cisco.com [10.82.224.224]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id NAA19496; Fri, 12 Oct 2001 13:10:19 -0400 (EDT) Message-Id: <4.3.2.7.2.20011012125604.00b93750@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 12 Oct 2001 13:11:40 -0400 To: Randy Bush From: Ralph Droms Subject: Re: [dhcwg] Re: draft-ietf-dnsext-dhcid-rr-03.txt Cc: Mark Stapp , namedroppers , dhcwg@ietf.org In-Reply-To: <4.3.2.7.2.20011012091725.01ad4a60@funnel.cisco.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org I have no objections to draft-ietf-dnsext-dhcid-rr-03.txt and recommend that it be accepted by the WG for submission as a Proposed Standard. This new RR is crucial to the standard mechanism under review in the DHC WG to support the interaction of DHCP and DNS in dynamic updates to DNS. The DHCID RR is of specific interest to the DHCP community, so posting to the DHC WG mailing list is likely to reach the widest audience of interested persons. Randy, now that we know you're looking for positive responses as well comments, the DHC WG will be able to respond to indicate our interest in seeing this draft move forward. - Ralph At 09:32 AM 10/12/2001 -0400, Mark Stapp wrote: >I wonder whether the lack of objections to this draft might be interpreted >another way. The rr is designed for use in networks where dhcp servers and >clients are updating A and PTR rrs as dhcp protocol interactions take >place. Since the dhcid rr doesn't have any special dns protocol semantic >significance, it doesn't raise any contentious issues for the dns server >community. It's not surprising, then, if the dns community doesn't have >much objection to the new rr. > >The dhcp community has a dependency on this specification, however, and >the use of this rr does have significance for us. Perhaps I've >misunderstood the point of the wg last call: I thought it was a way of >soliciting suggestions and complaints. I didn't realize that if no one >objected, that the draft would die. That doesn't quite make sense to me, >actually. In any case, I'm cross-posting this to the dhc working group >list in the hope that some of that group's participants will express some >support for this dnsext draft. If it dies, however quietly, the dhc group >will have to start designing dhcp-dns interaction specifications from scratch. > >-- Mark > >At 06:17 PM 10/11/2001 -0700, Randy Bush wrote: >> > Date: Wed, 26 Sep 2001 11:56:35 -0700 >> > this starts a two week wg last call on draft-ietf-dnsext-dhcid-rr-03.txt >> > for proposed standard. >> >>the wg last call has ended. there seems to have been zero comment on >>this draft. unless i hear to the contrary, i will assume that no one >>is sufficiently interssted in adding yarr, and we can let it die. >> >>randy >> >> >>to unsubscribe send a message to namedroppers-request@ops.ietf.org with >>the word 'unsubscribe' in a single line as the message text body. > > >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >http://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Oct 12 13:17:31 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03965; Fri, 12 Oct 2001 13:17:31 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA02451; Fri, 12 Oct 2001 13:16:33 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA02424 for ; Fri, 12 Oct 2001 13:16:31 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03941 for ; Fri, 12 Oct 2001 13:16:26 -0400 (EDT) Received: from rdroms-w2k.cisco.com (rtp-vpn1-224.cisco.com [10.82.224.224]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id NAA20182 for ; Fri, 12 Oct 2001 13:15:57 -0400 (EDT) Message-Id: <4.3.2.7.2.20011012131216.00b91418@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 12 Oct 2001 13:16:53 -0400 To: dhcwg@ietf.org From: Ralph Droms Subject: Fwd: [dhcwg] Re: draft-ietf-dnsext-dhcid-rr-03.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Just to make sure our opinions about the WG last call on draft-ietf-dnsext-dhcid-rr-03.txt are known, please follow up with comments to the namedroppers@ops.ietf.org mailing list. If you have no objections to the current draft, just send an ACK... - Ralph >Date: Fri, 12 Oct 2001 09:32:56 -0400 >To: Randy Bush >From: Mark Stapp >Subject: [dhcwg] Re: draft-ietf-dnsext-dhcid-rr-03.txt > >I wonder whether the lack of objections to this draft might be interpreted >another way. The rr is designed for use in networks where dhcp servers and >clients are updating A and PTR rrs as dhcp protocol interactions take >place. Since the dhcid rr doesn't have any special dns protocol semantic >significance, it doesn't raise any contentious issues for the dns server >community. It's not surprising, then, if the dns community doesn't have >much objection to the new rr. > >The dhcp community has a dependency on this specification, however, and >the use of this rr does have significance for us. Perhaps I've >misunderstood the point of the wg last call: I thought it was a way of >soliciting suggestions and complaints. I didn't realize that if no one >objected, that the draft would die. That doesn't quite make sense to me, >actually. In any case, I'm cross-posting this to the dhc working group >list in the hope that some of that group's participants will express some >support for this dnsext draft. If it dies, however quietly, the dhc group >will have to start designing dhcp-dns interaction specifications from scratch. > >-- Mark > >At 06:17 PM 10/11/2001 -0700, Randy Bush wrote: >> > Date: Wed, 26 Sep 2001 11:56:35 -0700 >> > this starts a two week wg last call on draft-ietf-dnsext-dhcid-rr-03.txt >> > for proposed standard. >> >>the wg last call has ended. there seems to have been zero comment on >>this draft. unless i hear to the contrary, i will assume that no one >>is sufficiently interssted in adding yarr, and we can let it die. >> >>randy >> >> >>to unsubscribe send a message to namedroppers-request@ops.ietf.org with >>the word 'unsubscribe' in a single line as the message text body. > > >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >http://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Oct 12 13:27:13 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04306; Fri, 12 Oct 2001 13:27:13 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA02603; Fri, 12 Oct 2001 13:25:29 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA02578 for ; Fri, 12 Oct 2001 13:25:28 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04236 for ; Fri, 12 Oct 2001 13:25:23 -0400 (EDT) Received: from green.bisbee.fugue.com (2Cust83.tnt5.nyc3.da.uu.net [63.23.115.211]) by toccata.fugue.com (8.11.3/8.6.11) with ESMTP id f9CHOjv00342; Fri, 12 Oct 2001 10:24:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by green.bisbee.fugue.com (8.10.2/8.6.11) with ESMTP id f9CHPRR00449; Fri, 12 Oct 2001 13:25:27 -0400 (EDT) Date: Fri, 12 Oct 2001 13:25:27 -0400 Subject: Re: [dhcwg] Re: draft-ietf-dnsext-dhcid-rr-03.txt Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v472) Cc: Mark Stapp , namedroppers , dhcwg@ietf.org To: Randy Bush From: Ted Lemon In-Reply-To: Message-Id: <20894808-BF36-11D5-B823-00039317663C@fugue.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.472) Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 7bit > if folk want it, they should speak up. we don't need a hoard. just a > few folk to say "yes, we want this." Folk have flown to IETF in foreign countries specifically for the purpose of saying "yes, we want this." I have done it on several occasions. I know Mark has as well. That is why it was before the working group. You now have three people who have publically stated on namedroppers that they want it, all within a matter of minutes of you unexpectedly proposing to kill it. So please send it along. Thanks! _MelloN_ _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Oct 12 14:02:14 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05250; Fri, 12 Oct 2001 14:02:14 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA04119; Fri, 12 Oct 2001 14:01:32 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA04090 for ; Fri, 12 Oct 2001 14:01:30 -0400 (EDT) Received: from shell.nominum.com (shell.nominum.com [128.177.192.160]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05214 for ; Fri, 12 Oct 2001 14:01:24 -0400 (EDT) Received: from BarrFS9RB01 (shell.nominum.com [128.177.192.160]) by shell.nominum.com (Postfix) with SMTP id 7FC1A3190D; Fri, 12 Oct 2001 11:00:55 -0700 (PDT) Reply-To: From: "Barr Hibbs" To: "namedroppers" Cc: "Dhcwg" Date: Fri, 12 Oct 2001 11:01:02 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Content-Transfer-Encoding: 7bit Subject: [dhcwg] RE: draft-ietf-dnsext-dhcid-rr-03.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 7bit > -----Original Message----- > From: owner-namedroppers@ops.ietf.org > [mailto:owner-namedroppers@ops.ietf.org]On Behalf Of Randy Bush > Sent: Thursday, October 11, 2001 18:17 > the wg last call has ended. there seems to have been zero comment on > this draft. unless i hear to the contrary, i will assume that no one > is sufficiently interested in adding yarr, and we can let it die. > I don't see why "zero comment" is equivalent to "no one is sufficiently interested" but aside from that, this RR type is necessary for a DHCP server to dynamically update a DNS server on behalf of a client that has received an IP address lease from the DHCP server. Do not let this simply slip into oblivion. --Barr _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sat Oct 13 10:12:19 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03636; Sat, 13 Oct 2001 10:12:19 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA09640; Sat, 13 Oct 2001 10:10:30 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA09610 for ; Sat, 13 Oct 2001 10:10:28 -0400 (EDT) Received: from ausmtp01.au.ibm.com (ausmtp01.au.ibm.COM [202.135.136.97]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03623 for ; Sat, 13 Oct 2001 10:10:23 -0400 (EDT) From: skodati@in.ibm.com Received: from f02n15e.au.ibm.com by ausmtp01.au.ibm.com (IBM AP 2.0) with ESMTP id f9DE5HH403452; Sun, 14 Oct 2001 00:05:17 +1000 Received: from d73mta01.au.ibm.com (f06n01s [9.185.166.65]) by f02n15e.au.ibm.com (8.11.1m3/NCO v4.97.1) with SMTP id f9DE8iD184918; Sun, 14 Oct 2001 00:08:44 +1000 Received: by d73mta01.au.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id CA256AE4.004DB0EF ; Sun, 14 Oct 2001 00:08:35 +1000 X-Lotus-FromDomain: IBMIN@IBMAU To: Ralph Droms cc: dhcwg@ietf.org, bsuparna@in.ibm.com, rsharada@in.ibm.com Message-ID: Date: Sat, 13 Oct 2001 12:36:10 +0530 Subject: Re: [dhcwg] Rev of DHCPv6 spec Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Ralph Droms on 10/12/2001 03:36:08 PM Please respond to Ralph Droms To: Suresh Kodati/India/IBM@IBMIN cc: dhcwg@ietf.org, Suparna Bhattacharya/India/IBM@IBMIN, R Sharada/India/IBM@IBMIN Subject: Re: [dhcwg] Rev of DHCPv6 spec >1./2. the unicast option is an administrative policy; >3. I don't see any text in 16.1.1 that requires the >client to check that the server is on the same link I took the case of client and server on the same link as an example for the first condition 16.1.1/16.1.3/16.1.6/16.1.8/ "If the client has a source address that can be used by the server as a return address"). >In response to your last question, the use of unicast >isn't dependent on whether the client and server >are on the same link. A client could use unicast to >deliver DHCP messages to an off-link router. >The draft doesn't specify how a server should react >to a unicast message received from a client to which the >server has not sent a unicast option. I imagine the >right thing to do is to allow the server to process >such messages. If the client can unicast the message without referring to receipt of unicast option from the server, (and since the server doesn't mandate the client to use unicast the messages to the server by sending unicast option), How this option would be useful. Is there any scenario that a client cannot unicast the REQUEST/RENEW/RELEASE/DECLINE even after receipt of unicast option from the server. Isn't it is enough to leave it to the client to choose the unicast/multicast based on the first condition ("If the client has a source address that can be used by the server as a return address"). -Suresh At 12:18 PM 10/12/2001 +0530, skodati@in.ibm.com wrote: >I would like to get clarification on when does a server send an unicast >option, >1. does the server send unicast option whenever the client is on the same >link (20.11 is not clear about it) (or) >2. Is it an administrative policy that decides if the client can >unicast/multicast of messages. If it is so, is there any example of the >scenario where the server would not specify the option despite being on the >same link. >3. why is the client required to check if the client and server are on the >same link if unicast option is already obtained from the server ( 16.1.1 ) > >And also, > Is it not sufficient to have both client and server to be on the same link >to unicast client's message ?, if so what is the server response to >client's unicast if it didn't send unicast option to the client and still >gets messages unicast'ed to it. >-suresh > > >Ralph Droms on 10/11/2001 07:31:31 AM > >Please respond to Ralph Droms > >To: dhcwg@ietf.org >cc: (bcc: Suresh Kodati/India/IBM) >Subject: [dhcwg] Rev of DHCPv6 spec > > >I've finished another rev of the DHCPv6 spec (-20d), which is available at >http://www.dhcp.org/dhcpv6.tty I plan to submit this draft of the spec to >the IETF for publication on 10/12. The list of issues addressed by this >draft is included below; these issues were discussed at the DHC WG meeting >in London (8/2001). The -20d draft does not include any changes related to >IAs. The changes related to IAs will appear in the next published rev of >the draft. > >- Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sun Oct 14 21:58:33 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA04053; Sun, 14 Oct 2001 21:58:33 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA27904; Sun, 14 Oct 2001 21:56:27 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA27880 for ; Sun, 14 Oct 2001 21:56:25 -0400 (EDT) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA04049 for ; Sun, 14 Oct 2001 21:56:21 -0400 (EDT) Received: from mr7.exu.ericsson.se (mr7u3.ericy.com [208.237.135.122]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id f9F1uOY16509 for ; Sun, 14 Oct 2001 20:56:24 -0500 (CDT) Received: from eamrcnt749 (eamrcnt749.exu.ericsson.se [138.85.133.47]) by mr7.exu.ericsson.se (8.11.3/8.11.3) with SMTP id f9F1uO625970 for ; Sun, 14 Oct 2001 20:56:24 -0500 (CDT) Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt749 ; Sun Oct 14 20:56:23 2001 -0500 Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id <4CP97WWZ>; Sun, 14 Oct 2001 20:56:23 -0500 Message-ID: <66F66129A77AD411B76200508B65AC69904A4A@eambunt705.ena-east.ericsson.se> From: "Bernie Volz (EUD)" To: Randy Bush , Mark Stapp Cc: namedroppers , dhcwg@ietf.org Subject: RE: [dhcwg] Re: draft-ietf-dnsext-dhcid-rr-03.txt Date: Sun, 14 Oct 2001 20:55:55 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1551C.8733AAC0" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1551C.8733AAC0 Content-Type: text/plain; charset="iso-8859-1" I too would like to see this draft move forward. - Bernie Volz Ericsson -----Original Message----- From: Ralph Droms [mailto:rdroms@cisco.com] Sent: Friday, October 12, 2001 1:12 PM To: Randy Bush Cc: Mark Stapp; namedroppers; dhcwg@ietf.org Subject: Re: [dhcwg] Re: draft-ietf-dnsext-dhcid-rr-03.txt I have no objections to draft-ietf-dnsext-dhcid-rr-03.txt and recommend that it be accepted by the WG for submission as a Proposed Standard. This new RR is crucial to the standard mechanism under review in the DHC WG to support the interaction of DHCP and DNS in dynamic updates to DNS. The DHCID RR is of specific interest to the DHCP community, so posting to the DHC WG mailing list is likely to reach the widest audience of interested persons. Randy, now that we know you're looking for positive responses as well comments, the DHC WG will be able to respond to indicate our interest in seeing this draft move forward. - Ralph At 09:32 AM 10/12/2001 -0400, Mark Stapp wrote: >I wonder whether the lack of objections to this draft might be interpreted >another way. The rr is designed for use in networks where dhcp servers and >clients are updating A and PTR rrs as dhcp protocol interactions take >place. Since the dhcid rr doesn't have any special dns protocol semantic >significance, it doesn't raise any contentious issues for the dns server >community. It's not surprising, then, if the dns community doesn't have >much objection to the new rr. > >The dhcp community has a dependency on this specification, however, and >the use of this rr does have significance for us. Perhaps I've >misunderstood the point of the wg last call: I thought it was a way of >soliciting suggestions and complaints. I didn't realize that if no one >objected, that the draft would die. That doesn't quite make sense to me, >actually. In any case, I'm cross-posting this to the dhc working group >list in the hope that some of that group's participants will express some >support for this dnsext draft. If it dies, however quietly, the dhc group >will have to start designing dhcp-dns interaction specifications from scratch. > >-- Mark > >At 06:17 PM 10/11/2001 -0700, Randy Bush wrote: >> > Date: Wed, 26 Sep 2001 11:56:35 -0700 >> > this starts a two week wg last call on draft-ietf-dnsext-dhcid-rr-03.txt >> > for proposed standard. >> >>the wg last call has ended. there seems to have been zero comment on >>this draft. unless i hear to the contrary, i will assume that no one >>is sufficiently interssted in adding yarr, and we can let it die. >> >>randy >> >> >>to unsubscribe send a message to namedroppers-request@ops.ietf.org with >>the word 'unsubscribe' in a single line as the message text body. > > >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >http://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg ------_=_NextPart_001_01C1551C.8733AAC0 Content-Type: text/html; charset="iso-8859-1" RE: [dhcwg] Re: draft-ietf-dnsext-dhcid-rr-03.txt

I too would like to see this draft move forward.

- Bernie Volz
  Ericsson

-----Original Message-----
From: Ralph Droms [mailto:rdroms@cisco.com]
Sent: Friday, October 12, 2001 1:12 PM
To: Randy Bush
Cc: Mark Stapp; namedroppers; dhcwg@ietf.org
Subject: Re: [dhcwg] Re: draft-ietf-dnsext-dhcid-rr-03.txt


I have no objections to draft-ietf-dnsext-dhcid-rr-03.txt and
recommend that it be accepted by the WG for submission as
a Proposed Standard.

This new RR is crucial to the standard mechanism under
review in the DHC WG to support the interaction of DHCP
and DNS in dynamic updates to DNS.

The DHCID RR is of specific interest to the DHCP
community, so posting to the DHC WG mailing list is likely
to reach the widest audience of interested persons.  Randy,
now that we know you're looking for positive responses as well
comments, the DHC WG will be able to respond to indicate our
interest in seeing this draft move forward.

- Ralph



At 09:32 AM 10/12/2001 -0400, Mark Stapp wrote:
>I wonder whether the lack of objections to this draft might be interpreted
>another way. The rr is designed for use in networks where dhcp servers and
>clients are updating A and PTR rrs as dhcp protocol interactions take
>place. Since the dhcid rr doesn't have any special dns protocol semantic
>significance, it doesn't raise any contentious issues for the dns server
>community. It's not surprising, then, if the dns community doesn't have
>much objection to the new rr.
>
>The dhcp community has a dependency on this specification, however, and
>the use of this rr does have significance for us. Perhaps I've
>misunderstood the point of the wg last call: I thought it was a way of
>soliciting suggestions and complaints. I didn't realize that if no one
>objected, that the draft would die. That doesn't quite make sense to me,
>actually. In any case, I'm cross-posting this to the dhc working group
>list in the hope that some of that group's participants will express some
>support for this dnsext draft. If it dies, however quietly, the dhc group
>will have to start designing dhcp-dns interaction specifications from scratch.
>
>-- Mark
>
>At 06:17 PM 10/11/2001 -0700, Randy Bush wrote:
>> > Date: Wed, 26 Sep 2001 11:56:35 -0700
>> > this starts a two week wg last call on draft-ietf-dnsext-dhcid-rr-03.txt
>> > for proposed standard.
>>
>>the wg last call has ended.  there seems to have been zero comment on
>>this draft.  unless i hear to the contrary, i will assume that no one
>>is sufficiently interssted in adding yarr, and we can let it die.
>>
>>randy
>>
>>
>>to unsubscribe send a message to namedroppers-request@ops.ietf.org with
>>the word 'unsubscribe' in a single line as the message text body.
>
>
>_______________________________________________
>dhcwg mailing list
>dhcwg@ietf.org
>http://www1.ietf.org/mailman/listinfo/dhcwg


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

------_=_NextPart_001_01C1551C.8733AAC0-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sun Oct 14 22:11:22 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA04208; Sun, 14 Oct 2001 22:11:22 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA28433; Sun, 14 Oct 2001 22:09:30 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA28408 for ; Sun, 14 Oct 2001 22:09:29 -0400 (EDT) Received: from imr2.ericy.com (imr2.ericy.com [12.34.240.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA04163 for ; Sun, 14 Oct 2001 22:09:24 -0400 (EDT) Received: from mr6.exu.ericsson.se (mr6att.ericy.com [138.85.92.14]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id f9F28v002891 for ; Sun, 14 Oct 2001 21:08:57 -0500 (CDT) Received: from eamrcnt747.exu.ericsson.se (eamrcnt747.exu.ericsson.se [138.85.133.37]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with SMTP id f9F28uk07629 for ; Sun, 14 Oct 2001 21:08:56 -0500 (CDT) Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt747.exu.ericsson.se ; Sun Oct 14 21:08:55 2001 -0500 Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id <4CP97W6G>; Sun, 14 Oct 2001 21:08:55 -0500 Message-ID: <66F66129A77AD411B76200508B65AC697B377E@eambunt705.ena-east.ericsson.se> From: "Bernie Volz (EUD)" To: "'skodati@in.ibm.com'" , Ralph Droms Cc: dhcwg@ietf.org, bsuparna@in.ibm.com, rsharada@in.ibm.com Subject: RE: [dhcwg] Rev of DHCPv6 spec Date: Sun, 14 Oct 2001 21:08:53 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1551E.56DC69F0" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1551E.56DC69F0 Content-Type: text/plain; charset="iso-8859-1" The reason for having the SERVER send the unicast option and tell the client that it is OK is to avoid some of the problems that exist today with client renewals that don't go through relay options (such as in cable modem systems). Since the client/server communicate directly (in DHCPv4), the relay can't add the relay-agent options to the client's messages. If this isn't in the -20 draft, perhaps we should add something about it (just so people in the future won't need to ask why). I think that a client MUST NOT unicast a message unless it has received the unicast option from that server. (As Ralph indicated, I'm not sure it is required that a server MUST check that a message was multicast unless it told the client it was OK to use the unicast option; however, a server is free to drop those datagrams if it wishes. Hence, for a client to get service from all servers, it will need to honor the required behavior). - Bernie Volz -----Original Message----- From: skodati@in.ibm.com [mailto:skodati@in.ibm.com] Sent: Saturday, October 13, 2001 3:06 AM To: Ralph Droms Cc: dhcwg@ietf.org; bsuparna@in.ibm.com; rsharada@in.ibm.com Subject: Re: [dhcwg] Rev of DHCPv6 spec Ralph Droms on 10/12/2001 03:36:08 PM Please respond to Ralph Droms To: Suresh Kodati/India/IBM@IBMIN cc: dhcwg@ietf.org, Suparna Bhattacharya/India/IBM@IBMIN, R Sharada/India/IBM@IBMIN Subject: Re: [dhcwg] Rev of DHCPv6 spec >1./2. the unicast option is an administrative policy; >3. I don't see any text in 16.1.1 that requires the >client to check that the server is on the same link I took the case of client and server on the same link as an example for the first condition 16.1.1/16.1.3/16.1.6/16.1.8/ "If the client has a source address that can be used by the server as a return address"). >In response to your last question, the use of unicast >isn't dependent on whether the client and server >are on the same link. A client could use unicast to >deliver DHCP messages to an off-link router. >The draft doesn't specify how a server should react >to a unicast message received from a client to which the >server has not sent a unicast option. I imagine the >right thing to do is to allow the server to process >such messages. If the client can unicast the message without referring to receipt of unicast option from the server, (and since the server doesn't mandate the client to use unicast the messages to the server by sending unicast option), How this option would be useful. Is there any scenario that a client cannot unicast the REQUEST/RENEW/RELEASE/DECLINE even after receipt of unicast option from the server. Isn't it is enough to leave it to the client to choose the unicast/multicast based on the first condition ("If the client has a source address that can be used by the server as a return address"). -Suresh At 12:18 PM 10/12/2001 +0530, skodati@in.ibm.com wrote: >I would like to get clarification on when does a server send an unicast >option, >1. does the server send unicast option whenever the client is on the same >link (20.11 is not clear about it) (or) >2. Is it an administrative policy that decides if the client can >unicast/multicast of messages. If it is so, is there any example of the >scenario where the server would not specify the option despite being on the >same link. >3. why is the client required to check if the client and server are on the >same link if unicast option is already obtained from the server ( 16.1.1 ) > >And also, > Is it not sufficient to have both client and server to be on the same link >to unicast client's message ?, if so what is the server response to >client's unicast if it didn't send unicast option to the client and still >gets messages unicast'ed to it. >-suresh > > >Ralph Droms on 10/11/2001 07:31:31 AM > >Please respond to Ralph Droms > >To: dhcwg@ietf.org >cc: (bcc: Suresh Kodati/India/IBM) >Subject: [dhcwg] Rev of DHCPv6 spec > > >I've finished another rev of the DHCPv6 spec (-20d), which is available at >http://www.dhcp.org/dhcpv6.tty I plan to submit this draft of the spec to >the IETF for publication on 10/12. The list of issues addressed by this >draft is included below; these issues were discussed at the DHC WG meeting >in London (8/2001). The -20d draft does not include any changes related to >IAs. The changes related to IAs will appear in the next published rev of >the draft. > >- Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg ------_=_NextPart_001_01C1551E.56DC69F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] Rev of DHCPv6 spec

The reason for having the SERVER send the unicast = option and tell the client that it is OK is to avoid some of the = problems that exist today with client renewals that don't go through = relay options (such as in cable modem systems). Since the client/server = communicate directly (in DHCPv4), the relay can't add the relay-agent = options to the client's messages. If this isn't in the -20 draft, = perhaps we should add something about it (just so people in the future = won't need to ask why).

I think that a client MUST NOT unicast a message = unless it has received the unicast option from that server. (As Ralph = indicated, I'm not sure it is required that a server MUST check that a = message was multicast unless it told the client it was OK to use the = unicast option; however, a server is free to drop those datagrams if it = wishes. Hence, for a client to get service from all servers, it will = need to honor the required behavior).

- Bernie Volz

-----Original Message-----
From: skodati@in.ibm.com [mailto:skodati@in.ibm.com]=
Sent: Saturday, October 13, 2001 3:06 AM
To: Ralph Droms
Cc: dhcwg@ietf.org; bsuparna@in.ibm.com; = rsharada@in.ibm.com
Subject: Re: [dhcwg] Rev of DHCPv6 spec





Ralph Droms <rdroms@cisco.com> on 10/12/2001 = 03:36:08 PM

Please respond to Ralph Droms = <rdroms@cisco.com>

To:   Suresh Kodati/India/IBM@IBMIN
cc:   dhcwg@ietf.org, Suparna = Bhattacharya/India/IBM@IBMIN, R
      = Sharada/India/IBM@IBMIN
Subject:  Re: [dhcwg] Rev of DHCPv6 spec




>1./2. the unicast option is an administrative = policy;

>3. I don't see any text in 16.1.1 that requires = the
>client to check that the server is on the same = link


I took the case of client and server on the same link = as an example for the
first condition 16.1.1/16.1.3/16.1.6/16.1.8/ = "If the client has a source
address that can be used by the server as a return = address").

>In response to your last question, the use of = unicast
>isn't dependent on whether the client and = server
>are on the same link.  A client could use = unicast to
>deliver DHCP messages to an off-link = router.

>The draft doesn't specify how a server should = react
>to a unicast message received from a client to = which the
>server has not sent a unicast option.  I = imagine the
>right thing to do is to allow the server to = process
>such messages.

If the client can unicast the message without = referring to receipt of
unicast option from the server, (and since the = server doesn't mandate the
client to use unicast the messages to the server by = sending unicast
option), How this option would be useful.

Is there any scenario that a client cannot unicast = the
REQUEST/RENEW/RELEASE/DECLINE even after receipt of = unicast option from the
server.

Isn't it is enough to leave it to the client to = choose the
unicast/multicast based on the first condition = ("If the client has a source
address that can be used by the server as a return = address").

-Suresh


At 12:18 PM 10/12/2001 +0530, skodati@in.ibm.com = wrote:

>I would like to get clarification on when does a = server send an unicast
>option,
>1. does the server send unicast option  = whenever the client is on the same
>link (20.11 is not clear about it) (or)
>2. Is it an administrative policy that decides = if the client can
>unicast/multicast of messages. If it is so, is = there any example of the
>scenario where the server would not specify the = option despite being on
the
>same link.
>3. why is the client required to check if the = client and server are on the
>same link if  unicast option is already = obtained from the server ( 16.1.1
)
>
>And also,
>  Is it not sufficient to have both client = and server to be on the same
link
>to unicast client's message ?, if so what is the = server response to
>client's unicast if it didn't send unicast = option to the client and still
>gets messages unicast'ed to it.
>-suresh
>
>
>Ralph Droms <rdroms@cisco.com> on = 10/11/2001 07:31:31 AM
>
>Please respond to Ralph Droms = <rdroms@cisco.com>
>
>To:   dhcwg@ietf.org
>cc:    (bcc: Suresh = Kodati/India/IBM)
>Subject:  [dhcwg] Rev of DHCPv6 spec
>
>
>I've finished another rev of the DHCPv6 spec = (-20d), which is available at
>http://www.dhcp.org/dhcpv6.tty  I plan to = submit this draft of the spec to
>the IETF for publication on 10/12.  The = list of issues addressed by this
>draft is included below; these issues were = discussed at the DHC WG meeting
>in London (8/2001).  The -20d draft does = not include any changes related
to
>IAs.  The changes related to IAs will = appear in the next published rev of
>the draft.
>
>- Ralph


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




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

------_=_NextPart_001_01C1551E.56DC69F0-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Oct 15 08:33:51 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25601; Mon, 15 Oct 2001 08:33:51 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA21592; Mon, 15 Oct 2001 08:32:12 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA21569 for ; Mon, 15 Oct 2001 08:32:10 -0400 (EDT) Received: from ausmtp01.au.ibm.com (ausmtp01.au.ibm.COM [202.135.136.97]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25581 for ; Mon, 15 Oct 2001 08:32:04 -0400 (EDT) From: skodati@in.ibm.com Received: from f02n15e.au.ibm.com by ausmtp01.au.ibm.com (IBM AP 2.0) with ESMTP id f9FCQuH365180; Mon, 15 Oct 2001 22:26:56 +1000 Received: from d73mta01.au.ibm.com (f06n01s [9.185.166.65]) by f02n15e.au.ibm.com (8.11.1m3/NCO v4.97.1) with SMTP id f9FCUNb125626; Mon, 15 Oct 2001 22:30:24 +1000 Received: by d73mta01.au.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id CA256AE6.0044ADFB ; Mon, 15 Oct 2001 22:30:09 +1000 X-Lotus-FromDomain: IBMIN@IBMAU To: "Bernie Volz (EUD)" , Ralph Droms cc: dhcwg@ietf.org, bsuparna@in.ibm.com, rsharada@in.ibm.com Message-ID: Date: Mon, 15 Oct 2001 18:00:38 +0530 Subject: RE: [dhcwg] Rev of DHCPv6 spec Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Are there any conditions that the server has to check before sending an unicast option, other than scope of the client's address. ( The draft talks about "sufficient scope" only 20.11 in draft 20d). If not, (a) Is there difference between the client verifying its scope to reach the server's address and server verifying the scope of the client address to send the unicast option?. if this is the case may i know what are they. Does the example given by you (cable modem) considers this case?. if yes: what are the other checks that the server has to perform. If answer to (a) is "no difference", why does a client need to receive "unicast option" from the server? instead of checking it at client's side. -suresh >The reason for having the SERVER send the unicast option and tell the client that it is OK is to avoid some of the >problems that exist today with client renewals that don't go through relay options (such as in cable modem >systems). Since the client/server communicate directly (in DHCPv4), the relay can't add the relay-agent options to >the client's messages. If this isn't in the -20 draft, perhaps we should add something about it (just so people in >the future won't need to ask why). > >I think that a client MUST NOT unicast a message unless it has received the unicast option from that server. (As >Ralph indicated, I'm not sure it is required that a server MUST check that a message was multicast unless it told >the client it was OK to use the unicast option; however, a server is free to drop those datagrams if it wishes. >Hence, for a client to get service from all servers, it will need to honor the required behavior). > >- Bernie Volz > >-----Original Message----- >From: skodati@in.ibm.com [mailto:skodati@in.ibm.com] >Sent: Saturday, October 13, 2001 3:06 AM >To: Ralph Droms >Cc: dhcwg@ietf.org; bsuparna@in.ibm.com; rsharada@in.ibm.com >Subject: Re: [dhcwg] Rev of DHCPv6 spec > > > > > >Ralph Droms on 10/12/2001 03:36:08 PM> > >Please respond to Ralph Droms > >To: Suresh Kodati/India/IBM@IBMIN >cc: dhcwg@ietf.org, Suparna Bhattacharya/India/IBM@IBMIN, R > Sharada/India/IBM@IBMIN >Subject: Re: [dhcwg] Rev of DHCPv6 spec > > > > > > >>1./2. the unicast option is an administrative policy; > >>3. I don't see any text in 16.1.1 that requires the >>client to check that the server is on the same link> > > >I took the case of client and server on the same link as an example for the >first condition 16.1.1/16.1.3/16.1.6/16.1.8/ "If the client has a source >address that can be used by the server as a return address"). > >>In response to your last question, the use of unicast >>isn't dependent on whether the client and server >>are on the same link. A client could use unicast to >>deliver DHCP messages to an off-link router. >>The draft doesn't specify how a server should react >>to a unicast message received from a client to which the >>server has not sent a unicast option. I imagine the >>right thing to do is to allow the server to process >>such messages. >If the client can unicast the message without referring to receipt of >unicast option from the server, (and since the server doesn't mandate the >client to use unicast the messages to the server by sending unicast >option), How this option would be useful. > >Is there any scenario that a client cannot unicast the >REQUEST/RENEW/RELEASE/DECLINE even after receipt of unicast option from the >server. >Isn't it is enough to leave it to the client to choose the >unicast/multicast based on the first condition ("If the client has a source >address that can be used by the server as a return address"). -Suresh _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Oct 15 09:59:14 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29127; Mon, 15 Oct 2001 09:59:13 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA23802; Mon, 15 Oct 2001 09:56:50 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA23732 for ; Mon, 15 Oct 2001 09:56:46 -0400 (EDT) Received: from imr2.ericy.com (imr2.ericy.com [12.34.240.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29035 for ; Mon, 15 Oct 2001 09:56:44 -0400 (EDT) Received: from mr6.exu.ericsson.se (mr6att.ericy.com [138.85.92.14]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id f9FDuG010154 for ; Mon, 15 Oct 2001 08:56:16 -0500 (CDT) Received: from eamrcnt749 (eamrcnt749.exu.ericsson.se [138.85.133.47]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with SMTP id f9FDuGi24222 for ; Mon, 15 Oct 2001 08:56:16 -0500 (CDT) Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt749 ; Mon Oct 15 08:56:15 2001 -0500 Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id <4CP98HJH>; Mon, 15 Oct 2001 08:56:14 -0500 Message-ID: <66F66129A77AD411B76200508B65AC697B3780@eambunt705.ena-east.ericsson.se> From: "Bernie Volz (EUD)" To: "'skodati@in.ibm.com'" , Ralph Droms Cc: dhcwg@ietf.org, bsuparna@in.ibm.com, rsharada@in.ibm.com Subject: RE: [dhcwg] Rev of DHCPv6 spec Date: Mon, 15 Oct 2001 08:56:10 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C15581.25531AB0" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C15581.25531AB0 Content-Type: text/plain; charset="iso-8859-1" I don't think the server is responsible for knowning all about the client - it can't. Therefore, the server simply sends the option as a matter of configuration policy (ie, no cable modems involved on those links and hence no reason why client can't unicast). It is up to the client to determine whether it CAN unicast. So, to the server it is a matter of configuration. To the client, it has to make the decision as to whether to unicast to the server. It can make this decision based on: - Receipt of the option from the server - Conditions of its addresses (does it have an address of sufficient scope). For example, if the server is on the same link, it can always unicast (using the link local). If the server is off-link, it can only unicast should it have an address available of sufficient scope (note that some links may have autoconfigured AND managed (DHCP) addresses). I don't understand why this is such a big deal? Please understand that multicasting for DHCPv6 is not like broadcasting. Only those hosts with an interest in that functionality (DHCP relays and servers) need to receive these packets. - Bernie -----Original Message----- From: skodati@in.ibm.com [mailto:skodati@in.ibm.com] Sent: Monday, October 15, 2001 8:31 AM To: Bernie Volz (EUD); Ralph Droms Cc: dhcwg@ietf.org; bsuparna@in.ibm.com; rsharada@in.ibm.com Subject: RE: [dhcwg] Rev of DHCPv6 spec Are there any conditions that the server has to check before sending an unicast option, other than scope of the client's address. ( The draft talks about "sufficient scope" only 20.11 in draft 20d). If not, (a) Is there difference between the client verifying its scope to reach the server's address and server verifying the scope of the client address to send the unicast option?. if this is the case may i know what are they. Does the example given by you (cable modem) considers this case?. if yes: what are the other checks that the server has to perform. If answer to (a) is "no difference", why does a client need to receive "unicast option" from the server? instead of checking it at client's side. -suresh >The reason for having the SERVER send the unicast option and tell the client that it is OK is to avoid some of the >problems that exist today with client renewals that don't go through relay options (such as in cable modem >systems). Since the client/server communicate directly (in DHCPv4), the relay can't add the relay-agent options to >the client's messages. If this isn't in the -20 draft, perhaps we should add something about it (just so people in >the future won't need to ask why). > >I think that a client MUST NOT unicast a message unless it has received the unicast option from that server. (As >Ralph indicated, I'm not sure it is required that a server MUST check that a message was multicast unless it told >the client it was OK to use the unicast option; however, a server is free to drop those datagrams if it wishes. >Hence, for a client to get service from all servers, it will need to honor the required behavior). > >- Bernie Volz > >-----Original Message----- >From: skodati@in.ibm.com [mailto:skodati@in.ibm.com] >Sent: Saturday, October 13, 2001 3:06 AM >To: Ralph Droms >Cc: dhcwg@ietf.org; bsuparna@in.ibm.com; rsharada@in.ibm.com >Subject: Re: [dhcwg] Rev of DHCPv6 spec > > > > > >Ralph Droms on 10/12/2001 03:36:08 PM> > >Please respond to Ralph Droms > >To: Suresh Kodati/India/IBM@IBMIN >cc: dhcwg@ietf.org, Suparna Bhattacharya/India/IBM@IBMIN, R > Sharada/India/IBM@IBMIN >Subject: Re: [dhcwg] Rev of DHCPv6 spec > > > > > > >>1./2. the unicast option is an administrative policy; > >>3. I don't see any text in 16.1.1 that requires the >>client to check that the server is on the same link> > > >I took the case of client and server on the same link as an example for the >first condition 16.1.1/16.1.3/16.1.6/16.1.8/ "If the client has a source >address that can be used by the server as a return address"). > >>In response to your last question, the use of unicast >>isn't dependent on whether the client and server >>are on the same link. A client could use unicast to >>deliver DHCP messages to an off-link router. >>The draft doesn't specify how a server should react >>to a unicast message received from a client to which the >>server has not sent a unicast option. I imagine the >>right thing to do is to allow the server to process >>such messages. >If the client can unicast the message without referring to receipt of >unicast option from the server, (and since the server doesn't mandate the >client to use unicast the messages to the server by sending unicast >option), How this option would be useful. > >Is there any scenario that a client cannot unicast the >REQUEST/RENEW/RELEASE/DECLINE even after receipt of unicast option from the >server. >Isn't it is enough to leave it to the client to choose the >unicast/multicast based on the first condition ("If the client has a source >address that can be used by the server as a return address"). -Suresh ------_=_NextPart_001_01C15581.25531AB0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] Rev of DHCPv6 spec

I don't think the server is responsible for knowning = all about the client - it can't. Therefore, the server simply sends the = option as a matter of configuration policy (ie, no cable modems = involved on those links and hence no reason why client can't unicast). = It is up to the client to determine whether it CAN unicast.

So, to the server it is a matter of = configuration.

To the client, it has to make the decision as to = whether to unicast to the server. It can make this decision based = on:
- Receipt of the option from the server
- Conditions of its addresses (does it have an = address of sufficient scope). For example, if the server is on the same = link, it can always unicast (using the link local). If the server is = off-link, it can only unicast should it have an address available of = sufficient scope (note that some links may have autoconfigured AND = managed (DHCP) addresses).

I don't understand why this is such a big = deal?

Please understand that multicasting for DHCPv6 is not = like broadcasting. Only those hosts with an interest in that = functionality (DHCP relays and servers) need to receive these = packets.

- Bernie

-----Original Message-----
From: skodati@in.ibm.com [mailto:skodati@in.ibm.com]=
Sent: Monday, October 15, 2001 8:31 AM
To: Bernie Volz (EUD); Ralph Droms
Cc: dhcwg@ietf.org; bsuparna@in.ibm.com; = rsharada@in.ibm.com
Subject: RE: [dhcwg] Rev of DHCPv6 spec



Are there any conditions that the server has to check = before sending an
unicast option, other than scope of the client's = address. ( The draft talks
about "sufficient scope" only  20.11 = in draft 20d).
If not,
     (a) Is there difference = between the client verifying its scope to
reach the  server's address and server = verifying the scope of the client
address to send the unicast option?.   if = this is the case may i know what
are they. Does the example given by you (cable = modem) considers this case?.

if yes:
     what are the other checks = that the server has to perform.

If answer to (a) is "no difference", why = does a client need to receive
"unicast option" from the server? instead = of checking it at client's side.
-suresh

>The reason for having the SERVER send the unicast = option and tell the
client that it is OK is to avoid some of the = >problems that exist today
with client renewals that don't go through relay = options (such as in cable
modem >systems). Since the client/server = communicate directly (in DHCPv4),
the relay can't add the relay-agent options to = >the client's messages. If
this isn't in the -20 draft, perhaps we should add = something about it (just
so people in >the future won't need to ask = why).
>
>I think that a client MUST NOT unicast a message = unless it has received
the unicast option from that server. (As >Ralph = indicated, I'm not sure it
is required that a server MUST check that a message = was multicast unless it
told >the client it was OK to use the unicast = option; however, a server is
free to drop those datagrams if it wishes. = >Hence, for a client to get
service from all servers, it will need to honor the = required behavior).
>
>- Bernie Volz
>
>-----Original Message-----
>From: skodati@in.ibm.com [mailto:skodati@in.ibm.com]=
>Sent: Saturday, October 13, 2001 3:06 AM
>To: Ralph Droms
>Cc: dhcwg@ietf.org; bsuparna@in.ibm.com; = rsharada@in.ibm.com
>Subject: Re: [dhcwg] Rev of DHCPv6 spec
>
>
>
>
>
>Ralph Droms <rdroms@cisco.com> on = 10/12/2001 03:36:08 PM>
>
>Please respond to Ralph Droms = <rdroms@cisco.com>
>
>To:   Suresh = Kodati/India/IBM@IBMIN
>cc:   dhcwg@ietf.org, Suparna = Bhattacharya/India/IBM@IBMIN, R
>      = Sharada/India/IBM@IBMIN
>Subject:  Re: [dhcwg] Rev of DHCPv6 = spec
>
>
>
>
>
>
>>1./2. the unicast option is an = administrative policy;
>
>>3. I don't see any text in 16.1.1 that = requires the
>>client to check that the server is on the = same link>
>
>
>I took the case of client and server on the same = link as an example for
the
>first condition 16.1.1/16.1.3/16.1.6/16.1.8/ = "If the client has a source
>address that can be used by the server as a = return address").
>
>>In response to your last question, the use = of unicast
>>isn't dependent on whether the client and = server
>>are on the same link.  A client could = use unicast to
>>deliver DHCP messages to an off-link = router.

>>The draft doesn't specify how a server should = react
>>to a unicast message received from a client = to which the
>>server has not sent a unicast option.  = I imagine the
>>right thing to do is to allow the server to = process
>>such messages.

>If the client can unicast the message without = referring to receipt of
>unicast option from the server, (and since the = server doesn't mandate the
>client to use unicast the messages to the server = by sending unicast
>option), How this option would be useful.
>
>Is there any scenario that a client cannot = unicast the
>REQUEST/RENEW/RELEASE/DECLINE even after receipt = of unicast option from
the
>server.

>Isn't it is enough to leave it to the client to = choose the
>unicast/multicast based on the first condition = ("If the client has a
source
>address that can be used by the server as a = return address").

-Suresh

------_=_NextPart_001_01C15581.25531AB0-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Oct 15 10:46:22 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00986; Mon, 15 Oct 2001 10:46:18 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA25387; Mon, 15 Oct 2001 10:44:43 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA25363 for ; Mon, 15 Oct 2001 10:44:41 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00969 for ; Mon, 15 Oct 2001 10:44:38 -0400 (EDT) Received: from rdroms-w2k.cisco.com (dhcp-161-44-149-111.cisco.com [161.44.149.111]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id KAA16956; Mon, 15 Oct 2001 10:44:05 -0400 (EDT) Message-Id: <4.3.2.7.2.20011015071556.00bbe9e8@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 15 Oct 2001 10:45:23 -0400 To: "Bernie Volz (EUD)" From: Ralph Droms Subject: RE: [dhcwg] Rev of DHCPv6 spec Cc: "'skodati@in.ibm.com'" , dhcwg@ietf.org, bsuparna@in.ibm.com, rsharada@in.ibm.com In-Reply-To: <66F66129A77AD411B76200508B65AC697B377E@eambunt705.ena-east .ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org The relevant text for Request messages in the -20d rev is: If the client has a source address that can be used by the server as a return address and the client has received a Client Unicast option (section 20.11) from the server, the client SHOULD unicast the Request message to the server. Otherwise, the client sends the Request message to the All_DHCP_Agents multicast address. To clarify and emphasize the requirement for multicast, I suggest the following text: If the client has a source address that can be used by the server as a return address and the client has received a Client Unicast option (section 20.11) from the server, the client SHOULD unicast the Request message to the server. Otherwise, the client MUST send the Request message to the All_DHCP_Agents multicast address. DISCUSSION: Use of multicast and relay agents enables the inclusion of relay agent options in all messages sent by the client. The server should enable the use of unicast only when relay agent options will not be used. Is this replacement text sufficiently clear? - Ralph At 09:08 PM 10/14/2001 -0500, Bernie Volz (EUD) wrote: >The reason for having the SERVER send the unicast option and tell the >client that it is OK is to avoid some of the problems that exist today >with client renewals that don't go through relay options (such as in cable >modem systems). Since the client/server communicate directly (in DHCPv4), >the relay can't add the relay-agent options to the client's messages. If >this isn't in the -20 draft, perhaps we should add something about it >(just so people in the future won't need to ask why). > >I think that a client MUST NOT unicast a message unless it has received >the unicast option from that server. (As Ralph indicated, I'm not sure it >is required that a server MUST check that a message was multicast unless >it told the client it was OK to use the unicast option; however, a server >is free to drop those datagrams if it wishes. Hence, for a client to get >service from all servers, it will need to honor the required behavior). > >- Bernie Volz > >-----Original Message----- >From: skodati@in.ibm.com >[mailto:skodati@in.ibm.com] >Sent: Saturday, October 13, 2001 3:06 AM >To: Ralph Droms >Cc: dhcwg@ietf.org; bsuparna@in.ibm.com; rsharada@in.ibm.com >Subject: Re: [dhcwg] Rev of DHCPv6 spec > > > > >Ralph Droms on 10/12/2001 03:36:08 PM > >Please respond to Ralph Droms > >To: Suresh Kodati/India/IBM@IBMIN >cc: dhcwg@ietf.org, Suparna Bhattacharya/India/IBM@IBMIN, R > Sharada/India/IBM@IBMIN >Subject: Re: [dhcwg] Rev of DHCPv6 spec > > > > >1./2. the unicast option is an administrative policy; > > >3. I don't see any text in 16.1.1 that requires the > >client to check that the server is on the same link > >I took the case of client and server on the same link as an example for the >first condition 16.1.1/16.1.3/16.1.6/16.1.8/ "If the client has a source >address that can be used by the server as a return address"). > > >In response to your last question, the use of unicast > >isn't dependent on whether the client and server > >are on the same link. A client could use unicast to > >deliver DHCP messages to an off-link router. > > >The draft doesn't specify how a server should react > >to a unicast message received from a client to which the > >server has not sent a unicast option. I imagine the > >right thing to do is to allow the server to process > >such messages. > >If the client can unicast the message without referring to receipt of >unicast option from the server, (and since the server doesn't mandate the >client to use unicast the messages to the server by sending unicast >option), How this option would be useful. > >Is there any scenario that a client cannot unicast the >REQUEST/RENEW/RELEASE/DECLINE even after receipt of unicast option from the >server. > >Isn't it is enough to leave it to the client to choose the >unicast/multicast based on the first condition ("If the client has a source >address that can be used by the server as a return address"). > >-Suresh > >At 12:18 PM 10/12/2001 +0530, skodati@in.ibm.com wrote: > > >I would like to get clarification on when does a server send an unicast > >option, > >1. does the server send unicast option whenever the client is on the same > >link (20.11 is not clear about it) (or) > >2. Is it an administrative policy that decides if the client can > >unicast/multicast of messages. If it is so, is there any example of the > >scenario where the server would not specify the option despite being on >the > >same link. > >3. why is the client required to check if the client and server are on the > >same link if unicast option is already obtained from the server ( 16.1.1 >) > > > >And also, > > Is it not sufficient to have both client and server to be on the same >link > >to unicast client's message ?, if so what is the server response to > >client's unicast if it didn't send unicast option to the client and still > >gets messages unicast'ed to it. > >-suresh > > > > > >Ralph Droms on 10/11/2001 07:31:31 AM > > > >Please respond to Ralph Droms > > > >To: dhcwg@ietf.org > >cc: (bcc: Suresh Kodati/India/IBM) > >Subject: [dhcwg] Rev of DHCPv6 spec > > > > > >I've finished another rev of the DHCPv6 spec (-20d), which is available at > >http://www.dhcp.org/dhcpv6.tty I plan > to submit this draft of the spec to > >the IETF for publication on 10/12. The list of issues addressed by this > >draft is included below; these issues were discussed at the DHC WG meeting > >in London (8/2001). The -20d draft does not include any changes related >to > >IAs. The changes related to IAs will appear in the next published rev of > >the draft. > > > >- Ralph > >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >http://www1.ietf.org/mailman/listinfo/dhcwg > > > > >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >http://www1.ietf.org/mailman/listinfo/dhcwg > _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Oct 15 11:03:44 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01747; Mon, 15 Oct 2001 11:03:44 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA25772; Mon, 15 Oct 2001 10:59:57 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA25751 for ; Mon, 15 Oct 2001 10:59:55 -0400 (EDT) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01538 for ; Mon, 15 Oct 2001 10:59:53 -0400 (EDT) Received: from mr6.exu.ericsson.se (mr6u3.ericy.com [208.237.135.123]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id f9FExtY00291 for ; Mon, 15 Oct 2001 09:59:55 -0500 (CDT) Received: from eamrcnt749 (eamrcnt749.exu.ericsson.se [138.85.133.47]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with SMTP id f9FExsi02063 for ; Mon, 15 Oct 2001 09:59:54 -0500 (CDT) Received: FROM eamrcnt760.exu.ericsson.se BY eamrcnt749 ; Mon Oct 15 09:59:53 2001 -0500 Received: by eamrcnt760.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id <4CQDTLF9>; Mon, 15 Oct 2001 09:59:53 -0500 Message-ID: <66F66129A77AD411B76200508B65AC697B3783@eambunt705.ena-east.ericsson.se> From: "Bernie Volz (EUD)" To: "'Ralph Droms'" Cc: "'skodati@in.ibm.com'" , dhcwg@ietf.org, bsuparna@in.ibm.com, rsharada@in.ibm.com Subject: RE: [dhcwg] Rev of DHCPv6 spec Date: Mon, 15 Oct 2001 09:59:49 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1558A.09AC2910" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1558A.09AC2910 Content-Type: text/plain; charset="iso-8859-1" Thanks Ralph, this looks good to me. I assume that this text change applies to other unicastable messages (Renew, Decline, Release), though perhaps the discussion section isn't needed everytime. Do we want to state anything about what the server must do (probably in a different section) if a unicasted packet arrives when unicast option wasn't sent to client? Personally, I don't see a need, but perhaps others do? - Bernie -----Original Message----- From: Ralph Droms [mailto:rdroms@cisco.com] Sent: Monday, October 15, 2001 10:45 AM To: Bernie Volz (EUD) Cc: 'skodati@in.ibm.com'; dhcwg@ietf.org; bsuparna@in.ibm.com; rsharada@in.ibm.com Subject: RE: [dhcwg] Rev of DHCPv6 spec The relevant text for Request messages in the -20d rev is: If the client has a source address that can be used by the server as a return address and the client has received a Client Unicast option (section 20.11) from the server, the client SHOULD unicast the Request message to the server. Otherwise, the client sends the Request message to the All_DHCP_Agents multicast address. To clarify and emphasize the requirement for multicast, I suggest the following text: If the client has a source address that can be used by the server as a return address and the client has received a Client Unicast option (section 20.11) from the server, the client SHOULD unicast the Request message to the server. Otherwise, the client MUST send the Request message to the All_DHCP_Agents multicast address. DISCUSSION: Use of multicast and relay agents enables the inclusion of relay agent options in all messages sent by the client. The server should enable the use of unicast only when relay agent options will not be used. Is this replacement text sufficiently clear? - Ralph At 09:08 PM 10/14/2001 -0500, Bernie Volz (EUD) wrote: >The reason for having the SERVER send the unicast option and tell the >client that it is OK is to avoid some of the problems that exist today >with client renewals that don't go through relay options (such as in cable >modem systems). Since the client/server communicate directly (in DHCPv4), >the relay can't add the relay-agent options to the client's messages. If >this isn't in the -20 draft, perhaps we should add something about it >(just so people in the future won't need to ask why). > >I think that a client MUST NOT unicast a message unless it has received >the unicast option from that server. (As Ralph indicated, I'm not sure it >is required that a server MUST check that a message was multicast unless >it told the client it was OK to use the unicast option; however, a server >is free to drop those datagrams if it wishes. Hence, for a client to get >service from all servers, it will need to honor the required behavior). > >- Bernie Volz > >-----Original Message----- >From: skodati@in.ibm.com >[mailto:skodati@in.ibm.com] >Sent: Saturday, October 13, 2001 3:06 AM >To: Ralph Droms >Cc: dhcwg@ietf.org; bsuparna@in.ibm.com; rsharada@in.ibm.com >Subject: Re: [dhcwg] Rev of DHCPv6 spec > > > > >Ralph Droms on 10/12/2001 03:36:08 PM > >Please respond to Ralph Droms > >To: Suresh Kodati/India/IBM@IBMIN >cc: dhcwg@ietf.org, Suparna Bhattacharya/India/IBM@IBMIN, R > Sharada/India/IBM@IBMIN >Subject: Re: [dhcwg] Rev of DHCPv6 spec > > > > >1./2. the unicast option is an administrative policy; > > >3. I don't see any text in 16.1.1 that requires the > >client to check that the server is on the same link > >I took the case of client and server on the same link as an example for the >first condition 16.1.1/16.1.3/16.1.6/16.1.8/ "If the client has a source >address that can be used by the server as a return address"). > > >In response to your last question, the use of unicast > >isn't dependent on whether the client and server > >are on the same link. A client could use unicast to > >deliver DHCP messages to an off-link router. > > >The draft doesn't specify how a server should react > >to a unicast message received from a client to which the > >server has not sent a unicast option. I imagine the > >right thing to do is to allow the server to process > >such messages. > >If the client can unicast the message without referring to receipt of >unicast option from the server, (and since the server doesn't mandate the >client to use unicast the messages to the server by sending unicast >option), How this option would be useful. > >Is there any scenario that a client cannot unicast the >REQUEST/RENEW/RELEASE/DECLINE even after receipt of unicast option from the >server. > >Isn't it is enough to leave it to the client to choose the >unicast/multicast based on the first condition ("If the client has a source >address that can be used by the server as a return address"). > >-Suresh > >At 12:18 PM 10/12/2001 +0530, skodati@in.ibm.com wrote: > > >I would like to get clarification on when does a server send an unicast > >option, > >1. does the server send unicast option whenever the client is on the same > >link (20.11 is not clear about it) (or) > >2. Is it an administrative policy that decides if the client can > >unicast/multicast of messages. If it is so, is there any example of the > >scenario where the server would not specify the option despite being on >the > >same link. > >3. why is the client required to check if the client and server are on the > >same link if unicast option is already obtained from the server ( 16.1.1 >) > > > >And also, > > Is it not sufficient to have both client and server to be on the same >link > >to unicast client's message ?, if so what is the server response to > >client's unicast if it didn't send unicast option to the client and still > >gets messages unicast'ed to it. > >-suresh > > > > > >Ralph Droms on 10/11/2001 07:31:31 AM > > > >Please respond to Ralph Droms > > > >To: dhcwg@ietf.org > >cc: (bcc: Suresh Kodati/India/IBM) > >Subject: [dhcwg] Rev of DHCPv6 spec > > > > > >I've finished another rev of the DHCPv6 spec (-20d), which is available at > >http://www.dhcp.org/dhcpv6.tty I plan > to submit this draft of the spec to > >the IETF for publication on 10/12. The list of issues addressed by this > >draft is included below; these issues were discussed at the DHC WG meeting > >in London (8/2001). The -20d draft does not include any changes related >to > >IAs. The changes related to IAs will appear in the next published rev of > >the draft. > > > >- Ralph > >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >http://www1.ietf.org/mailman/listinfo/dhcwg > > > > >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >http://www1.ietf.org/mailman/listinfo/dhcwg > ------_=_NextPart_001_01C1558A.09AC2910 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] Rev of DHCPv6 spec

Thanks Ralph, this looks good to me. I assume that = this text change applies to other unicastable messages (Renew, Decline, = Release), though perhaps the discussion section isn't needed = everytime.

Do we want to state anything about what the server = must do (probably in a different section) if a unicasted packet arrives = when unicast option wasn't sent to client? Personally, I don't see a = need, but perhaps others do?

- Bernie

-----Original Message-----
From: Ralph Droms [mailto:rdroms@cisco.com]
Sent: Monday, October 15, 2001 10:45 AM
To: Bernie Volz (EUD)
Cc: 'skodati@in.ibm.com'; dhcwg@ietf.org; = bsuparna@in.ibm.com;
rsharada@in.ibm.com
Subject: RE: [dhcwg] Rev of DHCPv6 spec


The relevant text for Request messages in the -20d = rev is:

    If the client has a source address = that can be used by the server
    as a return address and the = client has received a Client Unicast
    option (section 20.11) from the = server, the client SHOULD unicast
    the Request message to the = server.  Otherwise, the client sends
    the Request message to the = All_DHCP_Agents multicast address.

To clarify and emphasize the requirement for = multicast, I suggest the
following text:

    If the client has a source address = that can be used by the server
    as a return address and the = client has received a Client Unicast
    option (section 20.11) from the = server, the client SHOULD unicast
    the Request message to the = server.  Otherwise, the client MUST send
    the Request message to the = All_DHCP_Agents multicast address.

    DISCUSSION:

       Use of multicast = and relay agents enables the inclusion of
       relay agent = options in all messages sent by the client.  The
       server should = enable the use of unicast only when relay
       agent options = will not be used.

Is this replacement text sufficiently clear?

- Ralph


At 09:08 PM 10/14/2001 -0500, Bernie Volz (EUD) = wrote:

>The reason for having the SERVER send the unicast = option and tell the
>client that it is OK is to avoid some of the = problems that exist today
>with client renewals that don't go through relay = options (such as in cable
>modem systems). Since the client/server = communicate directly (in DHCPv4),
>the relay can't add the relay-agent options to = the client's messages. If
>this isn't in the -20 draft, perhaps we should = add something about it
>(just so people in the future won't need to ask = why).
>
>I think that a client MUST NOT unicast a message = unless it has received
>the unicast option from that server. (As Ralph = indicated, I'm not sure it
>is required that a server MUST check that a = message was multicast unless
>it told the client it was OK to use the unicast = option; however, a server
>is free to drop those datagrams if it wishes. = Hence, for a client to get
>service from all servers, it will need to honor = the required behavior).
>
>- Bernie Volz
>
>-----Original Message-----
>From: skodati@in.ibm.com
>[<mailto:skodati@in.ibm.com>mailto:skodati@in.ibm.com]=
>Sent: Saturday, October 13, 2001 3:06 AM
>To: Ralph Droms
>Cc: dhcwg@ietf.org; bsuparna@in.ibm.com; = rsharada@in.ibm.com
>Subject: Re: [dhcwg] Rev of DHCPv6 spec
>
>
>
>
>Ralph Droms <rdroms@cisco.com> on = 10/12/2001 03:36:08 PM
>
>Please respond to Ralph Droms = <rdroms@cisco.com>
>
>To:   Suresh = Kodati/India/IBM@IBMIN
>cc:   dhcwg@ietf.org, Suparna = Bhattacharya/India/IBM@IBMIN, R
>       = Sharada/India/IBM@IBMIN
>Subject:  Re: [dhcwg] Rev of DHCPv6 = spec
>
>
>
> >1./2. the unicast option is an = administrative policy;
>
> >3. I don't see any text in 16.1.1 that = requires the
> >client to check that the server is on the = same link
>
>I took the case of client and server on the same = link as an example for the
>first condition 16.1.1/16.1.3/16.1.6/16.1.8/ = "If the client has a source
>address that can be used by the server as a = return address").
>
> >In response to your last question, the use = of unicast
> >isn't dependent on whether the client and = server
> >are on the same link.  A client could = use unicast to
> >deliver DHCP messages to an off-link = router.
>
> >The draft doesn't specify how a server = should react
> >to a unicast message received from a client = to which the
> >server has not sent a unicast option.  = I imagine the
> >right thing to do is to allow the server to = process
> >such messages.
>
>If the client can unicast the message without = referring to receipt of
>unicast option from the server, (and since the = server doesn't mandate the
>client to use unicast the messages to the server = by sending unicast
>option), How this option would be useful.
>
>Is there any scenario that a client cannot = unicast the
>REQUEST/RENEW/RELEASE/DECLINE even after receipt = of unicast option from the
>server.
>
>Isn't it is enough to leave it to the client to = choose the
>unicast/multicast based on the first condition = ("If the client has a source
>address that can be used by the server as a = return address").
>
>-Suresh
>
>At 12:18 PM 10/12/2001 +0530, skodati@in.ibm.com = wrote:
>
> >I would like to get clarification on when = does a server send an unicast
> >option,
> >1. does the server send unicast = option  whenever the client is on the same
> >link (20.11 is not clear about it) = (or)
> >2. Is it an administrative policy that = decides if the client can
> >unicast/multicast of messages. If it is so, = is there any example of the
> >scenario where the server would not specify = the option despite being on
>the
> >same link.
> >3. why is the client required to check if = the client and server are on the
> >same link if  unicast option is = already obtained from the server ( 16.1.1
>)
> >
> >And also,
> >  Is it not sufficient to have both = client and server to be on the same
>link
> >to unicast client's message ?, if so what = is the server response to
> >client's unicast if it didn't send unicast = option to the client and still
> >gets messages unicast'ed to it.
> >-suresh
> >
> >
> >Ralph Droms <rdroms@cisco.com> on = 10/11/2001 07:31:31 AM
> >
> >Please respond to Ralph Droms = <rdroms@cisco.com>
> >
> >To:   dhcwg@ietf.org
> >cc:    (bcc: Suresh = Kodati/India/IBM)
> >Subject:  [dhcwg] Rev of DHCPv6 = spec
> >
> >
> >I've finished another rev of the DHCPv6 = spec (-20d), which is available at
> ><http://www.dhcp.org/dhcpv6.tty>http://www.dhcp.org/dhcpv6.tty  I plan =
> to submit this draft of the spec to
> >the IETF for publication on 10/12.  = The list of issues addressed by this
> >draft is included below; these issues were = discussed at the DHC WG meeting
> >in London (8/2001).  The -20d draft = does not include any changes related
>to
> >IAs.  The changes related to IAs will = appear in the next published rev of
> >the draft.
> >
> >- Ralph
>
>_______________________________________________
>dhcwg mailing list
>dhcwg@ietf.org
><http://www1.ietf.org/mailman/listinfo/dhcwg>http://www1.ietf.org/mailman/listinfo/dhcwg =
>
>
>
>
>_______________________________________________
>dhcwg mailing list
>dhcwg@ietf.org
><http://www1.ietf.org/mailman/listinfo/dhcwg>http://www1.ietf.org/mailman/listinfo/dhcwg =
>

------_=_NextPart_001_01C1558A.09AC2910-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Oct 15 11:06:02 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01844; Mon, 15 Oct 2001 11:05:57 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA26243; Mon, 15 Oct 2001 11:04:48 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA26174 for ; Mon, 15 Oct 2001 11:04:44 -0400 (EDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01792 for ; Mon, 15 Oct 2001 11:04:42 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f9FF4Ek03562; Mon, 15 Oct 2001 08:04:14 -0700 (PDT) Date: Mon, 15 Oct 2001 11:04:09 -0400 (EDT) From: Ralph Droms To: "Bernie Volz (EUD)" cc: "'skodati@in.ibm.com'" , , , Subject: RE: [dhcwg] Rev of DHCPv6 spec In-Reply-To: <66F66129A77AD411B76200508B65AC697B3783@eambunt705.ena-east.ericsson.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org It probably wouldn't hurt to add a sentence to the effect that a server MAY choose to accept unicast messages from clients to which the server has not sent a unicast option. A server might want to reject those messages because they won't include relay agent options... - Ralph On Mon, 15 Oct 2001, Bernie Volz (EUD) wrote: > Thanks Ralph, this looks good to me. I assume that this text change applies to other unicastable messages (Renew, Decline, Release), though perhaps the discussion section isn't needed everytime. > > Do we want to state anything about what the server must do (probably in a different section) if a unicasted packet arrives when unicast option wasn't sent to client? Personally, I don't see a need, but perhaps others do? > > - Bernie > > -----Original Message----- > From: Ralph Droms [mailto:rdroms@cisco.com] > Sent: Monday, October 15, 2001 10:45 AM > To: Bernie Volz (EUD) > Cc: 'skodati@in.ibm.com'; dhcwg@ietf.org; bsuparna@in.ibm.com; > rsharada@in.ibm.com > Subject: RE: [dhcwg] Rev of DHCPv6 spec > > > The relevant text for Request messages in the -20d rev is: > > If the client has a source address that can be used by the server > as a return address and the client has received a Client Unicast > option (section 20.11) from the server, the client SHOULD unicast > the Request message to the server. Otherwise, the client sends > the Request message to the All_DHCP_Agents multicast address. > > To clarify and emphasize the requirement for multicast, I suggest the > following text: > > If the client has a source address that can be used by the server > as a return address and the client has received a Client Unicast > option (section 20.11) from the server, the client SHOULD unicast > the Request message to the server. Otherwise, the client MUST send > the Request message to the All_DHCP_Agents multicast address. > > DISCUSSION: > > Use of multicast and relay agents enables the inclusion of > relay agent options in all messages sent by the client. The > server should enable the use of unicast only when relay > agent options will not be used. > > Is this replacement text sufficiently clear? > > - Ralph > > > At 09:08 PM 10/14/2001 -0500, Bernie Volz (EUD) wrote: > > >The reason for having the SERVER send the unicast option and tell the > >client that it is OK is to avoid some of the problems that exist today > >with client renewals that don't go through relay options (such as in cable > >modem systems). Since the client/server communicate directly (in DHCPv4), > >the relay can't add the relay-agent options to the client's messages. If > >this isn't in the -20 draft, perhaps we should add something about it > >(just so people in the future won't need to ask why). > > > >I think that a client MUST NOT unicast a message unless it has received > >the unicast option from that server. (As Ralph indicated, I'm not sure it > >is required that a server MUST check that a message was multicast unless > >it told the client it was OK to use the unicast option; however, a server > >is free to drop those datagrams if it wishes. Hence, for a client to get > >service from all servers, it will need to honor the required behavior). > > > >- Bernie Volz > > > >-----Original Message----- > >From: skodati@in.ibm.com > >[mailto:skodati@in.ibm.com] > >Sent: Saturday, October 13, 2001 3:06 AM > >To: Ralph Droms > >Cc: dhcwg@ietf.org; bsuparna@in.ibm.com; rsharada@in.ibm.com > >Subject: Re: [dhcwg] Rev of DHCPv6 spec > > > > > > > > > >Ralph Droms on 10/12/2001 03:36:08 PM > > > >Please respond to Ralph Droms > > > >To: Suresh Kodati/India/IBM@IBMIN > >cc: dhcwg@ietf.org, Suparna Bhattacharya/India/IBM@IBMIN, R > > Sharada/India/IBM@IBMIN > >Subject: Re: [dhcwg] Rev of DHCPv6 spec > > > > > > > > >1./2. the unicast option is an administrative policy; > > > > >3. I don't see any text in 16.1.1 that requires the > > >client to check that the server is on the same link > > > >I took the case of client and server on the same link as an example for the > >first condition 16.1.1/16.1.3/16.1.6/16.1.8/ "If the client has a source > >address that can be used by the server as a return address"). > > > > >In response to your last question, the use of unicast > > >isn't dependent on whether the client and server > > >are on the same link. A client could use unicast to > > >deliver DHCP messages to an off-link router. > > > > >The draft doesn't specify how a server should react > > >to a unicast message received from a client to which the > > >server has not sent a unicast option. I imagine the > > >right thing to do is to allow the server to process > > >such messages. > > > >If the client can unicast the message without referring to receipt of > >unicast option from the server, (and since the server doesn't mandate the > >client to use unicast the messages to the server by sending unicast > >option), How this option would be useful. > > > >Is there any scenario that a client cannot unicast the > >REQUEST/RENEW/RELEASE/DECLINE even after receipt of unicast option from the > >server. > > > >Isn't it is enough to leave it to the client to choose the > >unicast/multicast based on the first condition ("If the client has a source > >address that can be used by the server as a return address"). > > > >-Suresh > > > >At 12:18 PM 10/12/2001 +0530, skodati@in.ibm.com wrote: > > > > >I would like to get clarification on when does a server send an unicast > > >option, > > >1. does the server send unicast option whenever the client is on the same > > >link (20.11 is not clear about it) (or) > > >2. Is it an administrative policy that decides if the client can > > >unicast/multicast of messages. If it is so, is there any example of the > > >scenario where the server would not specify the option despite being on > >the > > >same link. > > >3. why is the client required to check if the client and server are on the > > >same link if unicast option is already obtained from the server ( 16.1.1 > >) > > > > > >And also, > > > Is it not sufficient to have both client and server to be on the same > >link > > >to unicast client's message ?, if so what is the server response to > > >client's unicast if it didn't send unicast option to the client and still > > >gets messages unicast'ed to it. > > >-suresh > > > > > > > > >Ralph Droms on 10/11/2001 07:31:31 AM > > > > > >Please respond to Ralph Droms > > > > > >To: dhcwg@ietf.org > > >cc: (bcc: Suresh Kodati/India/IBM) > > >Subject: [dhcwg] Rev of DHCPv6 spec > > > > > > > > >I've finished another rev of the DHCPv6 spec (-20d), which is available at > > >http://www.dhcp.org/dhcpv6.tty I plan > > to submit this draft of the spec to > > >the IETF for publication on 10/12. The list of issues addressed by this > > >draft is included below; these issues were discussed at the DHC WG meeting > > >in London (8/2001). The -20d draft does not include any changes related > >to > > >IAs. The changes related to IAs will appear in the next published rev of > > >the draft. > > > > > >- Ralph > > > >_______________________________________________ > >dhcwg mailing list > >dhcwg@ietf.org > >http://www1.ietf.org/mailman/listinfo/dhcwg > > > > > > > > > >_______________________________________________ > >dhcwg mailing list > >dhcwg@ietf.org > >http://www1.ietf.org/mailman/listinfo/dhcwg > > > _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Oct 15 12:35:42 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04473; Mon, 15 Oct 2001 12:35:42 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA29282; Mon, 15 Oct 2001 12:34:23 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA29258 for ; Mon, 15 Oct 2001 12:34:21 -0400 (EDT) Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04423 for ; Mon, 15 Oct 2001 12:34:18 -0400 (EDT) Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 15 Oct 2001 09:33:50 -0700 Received: from 157.54.9.108 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 15 Oct 2001 09:33:50 -0700 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-imc-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 15 Oct 2001 09:33:49 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 15 Oct 2001 09:33:46 -0700 Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3541.1); Mon, 15 Oct 2001 09:33:44 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6063.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [dhcwg] Rev of DHCPv6 spec Date: Mon, 15 Oct 2001 09:33:16 -0700 Message-ID: <2E33960095B58E40A4D3345AB9F65EC162B7C6@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Thread-Topic: [dhcwg] Rev of DHCPv6 spec Thread-Index: AcFSAiHfTjjWDtVrR5eOf64b4DkLgADkd+IA From: "Thirumalesh Bhat" To: "Ralph Droms" , X-OriginalArrivalTime: 15 Oct 2001 16:33:44.0528 (UTC) FILETIME=[2828F500:01C15597] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id MAA29259 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 8bit Some comments on the latest draft below: a) Section 10.1 - DUIDs Do we have an upper limit on the DUID length? I thought we had a prior thread regarding DUIDs where it was agreed that the upper limit on DUID length will help the server implementation. b) Section 15.1.2 Creation of Solicit messages: Can the client send a solicit message without an IA. An example would be for a client to check the servers that can provide the options it needs. c) Section 15.1.3 Transmission of Solicit Messages: The draft says "The client sends the Solicit message to the All_Dhcp_Agents" multicast address". How would this work if the DHCP Server is on the same segment as the client? Probably the DHCP server should bind to "ALL_Dhcp_Agents" as well as "All_DHCP_Servers" address. d) Section 15.1.4: Receipt of Advertise Messages: Is there a recommendation on how long a client should wait to collect response from all the responding servers or is this implementation specific? e) Section 15.2.2 - Creation and transmission of Advertise messages: third paragraph: What happens if the client doesn't send an IA - does the server ignore the packet? f) Section 16.1.5 When a client receives AddrUnavail status should it create a new IA? I would think that the client should create a new IA if it receives NoPrefixMatch status back. Not sure the reason for the use of "ConfNoMatch" status - I think the other error codes can pretty much tell the client what to do. Same goes for the error codes "RenwNoMatch", "RebdNoMatch". g) Section 16.2.2 Receipt of confirm messages: "If the server cannot determine if the info in the confirm message is valid or invalid, the server MUST NOT send a reply to the client". This statement is a bit confusing. A server might be able to figure out that the client request is not valid as far as it is confirmed but it cant verify if it is invalid to other servers. May be the server should send its error message anyway and the client should wait for a certain period of time ( as it does for advertise messages ) to check if there is a server that can serve its needs. h) Section 17.1.1 - Creation and transmission of reconfigure-init messages. Has the possibility of sending reconfigure-init to a relay been removed so that the relay can unicast to the clients that it is aware of? i) Section 20.1 - Format of DHCP Options. We should be explicit in saying that the option code and option length are in network byte order. j) I feel that we should also add "Vendor class" and "User class" options to the draft. I can prepare the text for these two options if desired. thx -----Original Message----- From: Ralph Droms [mailto:rdroms@cisco.com] Sent: Wednesday, October 10, 2001 7:02 PM To: dhcwg@ietf.org Subject: [dhcwg] Rev of DHCPv6 spec I've finished another rev of the DHCPv6 spec (-20d), which is available at http://www.dhcp.org/dhcpv6.tty I plan to submit this draft of the spec to the IETF for publication on 10/12. The list of issues addressed by this draft is included below; these issues were discussed at the DHC WG meeting in London (8/2001). The -20d draft does not include any changes related to IAs. The changes related to IAs will appear in the next published rev of the draft. - Ralph ===== Issues from London addressed in this draft. * Should addresses in an Advertise message be "real" addresses or "informational"; e.g., just prefixes? WG consensus: addresses in Advertise are the addresses the server will return in a subsequent Reply; client supplies those addresses to server in IA in Request message * Servers will only assign complete addresses and not prefixes (e.g., to be used by the client for stateless autoconfiguration) WG consensus: yes; prefix advertisement is handled through ND * How and when does the client use DAD on addresses in Advertise and Reply messages? WG consensus: Client does DAD on addresses in Reply message and responds with Decline if addresses unacceptable (e.g., already in use) * Advertise message SHOULD include options for all OROs that were included in the Solicit if the server is willing/capable of offering a value for that option WG consensus: yes * Add "NAK" function: If the server finds that the prefix on one or more IP addresses in any IA in the {Request, Confirm, Rebind} message is not a valid prefix for the link to which the client is connected, the server MUST send an NoPrefixMatch status in the IA status field for that IA in the DHCP Reply message. WG consensus: yes; indicate "NAK" through return of "NoPrefixMatch" error code. Add text allowing client to ignore "NoPrefixMatch" from other servers if ACK received from at least one server. * Define DUID to be one of: - Link-layer address plus time - Vendor-assigned unique ID - Link-layer address - IMSI - IMEI WG consensus: yes; based on text submitted by Lemon with extensions from subsequent WG discussion MODIFICATION: drop IMSI, IMEI * Use IPsec for secure agent/server communication WG consensus: yes; add text to draft * Add an "error code" option, to indicate errors not connected with a specific option WG consensus: yes; should allow inclusion of text message * Tighten up language for unicasting Reconfigure-Init; in particular, the server may not have an appropriate address to use to send the message to the client. WG consensus: yes * Reply to a Confirm should be a simple ACK/NAK without changing any values in options WG consensus: Discussion to be taken to mailing list Note: check to make sure there is text in the draft describing behavior if no response is heard to a Confirm FOLLOWUP: Issue was not posted to mailing list. Draft now defines Confirm to be simple ACK/NAK. * Reply to Decline or Release should carry no options WG consensus: yes * Restrict options in Decline or Release to IA with text to allow other options in the future WG consensus: no; this is an overspecification * Server does not respond to Solicit when client wants addresses and server has no addresses WG consensus: Server should be allowed to respond * Include only options specifically mentioned in the text in the DHCPv6 spec; move others to second doc or separate appendix WG consensus: anything we have consensus on stays; anything else gets punted to a separate draft. * Add 'secs' field to fixed header WG consensus: if client retransmits, MUST send option called "milliseconds" * Make the preference field an option WG consensus: yes * Describe message transmission and retransmission in a separate section of the spec and reference that text throughout the remainder of the spec WG consensus: yes * Discard the client unicast or recheck the entire spec for consistency in reference to message transmission WG consensus: yes, authors to fix spec * Remove client link-local address from client message header. Agent can then determine link-local from source (IP header) in client message and insert into agent->server message. Server responds to source from IP header (whether agent or client). WG consensus: Yes _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Oct 15 13:43:44 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07223; Mon, 15 Oct 2001 13:43:40 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA01244; Mon, 15 Oct 2001 13:39:49 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA01217 for ; Mon, 15 Oct 2001 13:39:47 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07004 for ; Mon, 15 Oct 2001 13:39:46 -0400 (EDT) Received: from rdroms-w2k.cisco.com (dhcp-161-44-149-111.cisco.com [161.44.149.111]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id NAA13391; Mon, 15 Oct 2001 13:35:31 -0400 (EDT) Message-Id: <4.3.2.7.2.20011015131051.03514eb0@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 15 Oct 2001 13:36:46 -0400 To: "Thirumalesh Bhat" From: Ralph Droms Subject: RE: [dhcwg] Rev of DHCPv6 spec Cc: In-Reply-To: <2E33960095B58E40A4D3345AB9F65EC162B7C6@win-msg-01.wingroup .windeploy.ntdev.microsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Thanks for your review and feedback. I haven't sent in the -20 rev to the IETF for publication, so I can still make some changes based on your comments. I'll respond to your comments in line... - Ralph At 09:33 AM 10/15/2001 -0700, Thirumalesh Bhat wrote: >Some comments on the latest draft below: > >a) Section 10.1 - DUIDs > Do we have an upper limit on the DUID length? I thought we had a >prior thread regarding DUIDs where it was agreed that the upper limit on >DUID length will help the server implementation. Yes - I think we put an upper limit of 256 bytes on a DUID. I'll add that restriction to the spec. >b) Section 15.1.2 Creation of Solicit messages: > Can the client send a solicit message without an IA. An example would >be for a client to check the servers that can provide the options it >needs. Yes - I'll make sure that it's clear that a client can send a Solicit without IAs. >c) Section 15.1.3 Transmission of Solicit Messages: >The draft says "The client sends the Solicit message to the >All_Dhcp_Agents" multicast address". How would this work if the DHCP >Server is on the same segment as the client? Probably the DHCP server >should bind to "ALL_Dhcp_Agents" as well as "All_DHCP_Servers" address. Turns out the naming of the of these multicast addresses is potentially confusing; both servers and relay agents are members of the All_DHCP_Agents multicast group: All_DHCP_Agents address: FF02::1:2 This link-scoped multicast address is used by clients to communicate with the on-link agent(s) when they do not know the link-local address(es) for those agents. All agents (servers and relays) are members of this multicast group. >d) Section 15.1.4: Receipt of Advertise Messages: >Is there a recommendation on how long a client should wait to collect >response from all the responding servers or is this implementation >specific? The intention is that SOL_TIMEOUT defines the time during which the client collects responses. If that's not clear, we'll need to fix the text: The client transmits the message according to section 13, using the following parameters: IRT SOL_TIMEOUT MRT SOL_MAX_RT MRC 0 MRD 0 The mechanism in section 13 is modified as follows for use in the transmission of Solicit messages. The message exchange is not terminated by the receipt of an Advertise before SOL_TIMEOUT has elapsed. Rather, the client collects Advertise messages until SOL_TIMEOUT has elapsed. The first RT MUST be selected to be strictly greater than SOL_TIMEOUT by choosing RAND to be strictly greater than 0. A client MUST collect Advertise messages for SOL_TIMEOUT seconds, unless it receives an Advertise message with a preference value of 255. The preference value is carried in the Preference option (section 20.5). Any Solicit that does not include a Preference option is considered to have a preference value of 0. If the client receives an Advertise message with a preference value of 255, then the client MAY act immediately on that Advertise message without waiting for any more additional Advertise messages. >e) Section 15.2.2 - Creation and transmission of Advertise messages: >third paragraph: >What happens if the client doesn't send an IA - does the server ignore >the packet? I guess the answer to this question is related to the answer to your question (b). If a client is allowed to send a Solicit with no IAs, the text in 15.2.2 must be clarified to allow a server to respond with an Advertise with no IAs. The server can't generate IAs for the client; all it can do is fill in IAs supplied by the client. >f) Section 16.1.5 >When a client receives AddrUnavail status should it create a new IA? I >would think that the client should create a new IA if it receives >NoPrefixMatch status back. The client doesn't have to create a new IA; it just has to find a different server that will agree to put addresses in the IA. >Not sure the reason for the use of "ConfNoMatch" status - I think the >other error codes can pretty much tell the client what to do. Same goes >for the error codes "RenwNoMatch", "RebdNoMatch". The "*NoMatch" status codes are the analog of DHCPNAK in DHCPv4; a mechanism through which the server can tell the client that the client needs to recontact the server for new configuration information. >g) Section 16.2.2 Receipt of confirm messages: > >"If the server cannot determine if the info in the confirm message is >valid or invalid, the server MUST NOT send a reply to the client". > >This statement is a bit confusing. A server might be able to figure out >that the client request is not valid as far as it is confirmed but it >cant verify if it is invalid to other servers. > >May be the server should send its error message anyway and the client >should wait for a certain period of time ( as it does for advertise >messages ) to check if there is a server that can serve its needs. The spec presumes that the servers are all configured consistently, so the presumption is the client won't get some ACK and some NAK responses. The text you quote allows for the fact that a server may get a Confirm in which the addresses are appropriate for the link from which the message was received, but the server doesn't have a binding for the client to confirm that the addresses in the IA have been specifically assigned to the client. >h) Section 17.1.1 - Creation and transmission of reconfigure-init >messages. > >Has the possibility of sending reconfigure-init to a relay been removed >so that the relay can unicast to the clients that it is aware of? There is no mechanism through which a relay agent can forward a reconfigure-init to multiple clients. >i) Section 20.1 - Format of DHCP Options. >We should be explicit in saying that the option code and option length >are in network byte order. OK. >j) I feel that we should also add "Vendor class" and "User class" >options to the draft. I can prepare the text for these two options if >desired. OK, I'll accept your offer to write up text for "Vendor class" and "User class". Thanks! _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Oct 15 14:08:25 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08304; Mon, 15 Oct 2001 14:08:25 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA02381; Mon, 15 Oct 2001 14:06:51 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA02307 for ; Mon, 15 Oct 2001 14:06:47 -0400 (EDT) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08251 for ; Mon, 15 Oct 2001 14:06:45 -0400 (EDT) Received: from mr6.exu.ericsson.se (mr6u3.ericy.com [208.237.135.123]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id f9FI6kY02968 for ; Mon, 15 Oct 2001 13:06:46 -0500 (CDT) Received: from eamrcnt747.exu.ericsson.se (eamrcnt747.exu.ericsson.se [138.85.133.37]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with SMTP id f9FI6kG06093 for ; Mon, 15 Oct 2001 13:06:46 -0500 (CDT) Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt747.exu.ericsson.se ; Mon Oct 15 13:06:45 2001 -0500 Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id <4CP9876Q>; Mon, 15 Oct 2001 13:06:45 -0500 Message-ID: <66F66129A77AD411B76200508B65AC697B3788@eambunt705.ena-east.ericsson.se> From: "Bernie Volz (EUD)" To: "'Ralph Droms'" , Thirumalesh Bhat Cc: dhcwg@ietf.org Subject: RE: [dhcwg] Rev of DHCPv6 spec Date: Mon, 15 Oct 2001 13:06:41 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C155A4.24905200" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C155A4.24905200 Content-Type: text/plain; charset="iso-8859-1" Ralph: Some other changes you might think about making (I'm still in the process of reviewing the draft): 1. Section 10 (DUIDs). I think it is important to state that the server should treat the entire DUID as an opaque value and use it only in comparing DUIDs with each other - the server should not take apart the DUID or restrict the DUID types to the values specified as future documents may define new types. 2. The example in 10.3 is broken. There are only 7 octets before "example.com", not the required 8. 3. In section 20.2, I thought we were going to drop the "DUID len" field from the option as it wasn't required (DUID len is option-len - 2 (for the DUID type)). 4. In section 7.5, some of the timings are a bit short. I haven't investigated this in detail yet, but when one considers the speed of dial-up links and round trip times, I'm just a bit concerned that 250 msecs is a bit short. 5. In 9.2, you might want to indicate that the link-prefix and client-return-address fields are copied from the Relay-forward. 6. Section 15.1.1 (Use of XID Field) should probably be moved to apply globally not just to "Client Behavior" unter "DHCP Server Solicitation"? 7. In Section 15.1.3, the destination port number is not specified. - Bernie -----Original Message----- From: Ralph Droms [mailto:rdroms@cisco.com] Sent: Monday, October 15, 2001 1:37 PM To: Thirumalesh Bhat Cc: dhcwg@ietf.org Subject: RE: [dhcwg] Rev of DHCPv6 spec Thanks for your review and feedback. I haven't sent in the -20 rev to the IETF for publication, so I can still make some changes based on your comments. I'll respond to your comments in line... - Ralph At 09:33 AM 10/15/2001 -0700, Thirumalesh Bhat wrote: >Some comments on the latest draft below: > >a) Section 10.1 - DUIDs > Do we have an upper limit on the DUID length? I thought we had a >prior thread regarding DUIDs where it was agreed that the upper limit on >DUID length will help the server implementation. Yes - I think we put an upper limit of 256 bytes on a DUID. I'll add that restriction to the spec. >b) Section 15.1.2 Creation of Solicit messages: > Can the client send a solicit message without an IA. An example would >be for a client to check the servers that can provide the options it >needs. Yes - I'll make sure that it's clear that a client can send a Solicit without IAs. >c) Section 15.1.3 Transmission of Solicit Messages: >The draft says "The client sends the Solicit message to the >All_Dhcp_Agents" multicast address". How would this work if the DHCP >Server is on the same segment as the client? Probably the DHCP server >should bind to "ALL_Dhcp_Agents" as well as "All_DHCP_Servers" address. Turns out the naming of the of these multicast addresses is potentially confusing; both servers and relay agents are members of the All_DHCP_Agents multicast group: All_DHCP_Agents address: FF02::1:2 This link-scoped multicast address is used by clients to communicate with the on-link agent(s) when they do not know the link-local address(es) for those agents. All agents (servers and relays) are members of this multicast group. >d) Section 15.1.4: Receipt of Advertise Messages: >Is there a recommendation on how long a client should wait to collect >response from all the responding servers or is this implementation >specific? The intention is that SOL_TIMEOUT defines the time during which the client collects responses. If that's not clear, we'll need to fix the text: The client transmits the message according to section 13, using the following parameters: IRT SOL_TIMEOUT MRT SOL_MAX_RT MRC 0 MRD 0 The mechanism in section 13 is modified as follows for use in the transmission of Solicit messages. The message exchange is not terminated by the receipt of an Advertise before SOL_TIMEOUT has elapsed. Rather, the client collects Advertise messages until SOL_TIMEOUT has elapsed. The first RT MUST be selected to be strictly greater than SOL_TIMEOUT by choosing RAND to be strictly greater than 0. A client MUST collect Advertise messages for SOL_TIMEOUT seconds, unless it receives an Advertise message with a preference value of 255. The preference value is carried in the Preference option (section 20.5). Any Solicit that does not include a Preference option is considered to have a preference value of 0. If the client receives an Advertise message with a preference value of 255, then the client MAY act immediately on that Advertise message without waiting for any more additional Advertise messages. >e) Section 15.2.2 - Creation and transmission of Advertise messages: >third paragraph: >What happens if the client doesn't send an IA - does the server ignore >the packet? I guess the answer to this question is related to the answer to your question (b). If a client is allowed to send a Solicit with no IAs, the text in 15.2.2 must be clarified to allow a server to respond with an Advertise with no IAs. The server can't generate IAs for the client; all it can do is fill in IAs supplied by the client. >f) Section 16.1.5 >When a client receives AddrUnavail status should it create a new IA? I >would think that the client should create a new IA if it receives >NoPrefixMatch status back. The client doesn't have to create a new IA; it just has to find a different server that will agree to put addresses in the IA. >Not sure the reason for the use of "ConfNoMatch" status - I think the >other error codes can pretty much tell the client what to do. Same goes >for the error codes "RenwNoMatch", "RebdNoMatch". The "*NoMatch" status codes are the analog of DHCPNAK in DHCPv4; a mechanism through which the server can tell the client that the client needs to recontact the server for new configuration information. >g) Section 16.2.2 Receipt of confirm messages: > >"If the server cannot determine if the info in the confirm message is >valid or invalid, the server MUST NOT send a reply to the client". > >This statement is a bit confusing. A server might be able to figure out >that the client request is not valid as far as it is confirmed but it >cant verify if it is invalid to other servers. > >May be the server should send its error message anyway and the client >should wait for a certain period of time ( as it does for advertise >messages ) to check if there is a server that can serve its needs. The spec presumes that the servers are all configured consistently, so the presumption is the client won't get some ACK and some NAK responses. The text you quote allows for the fact that a server may get a Confirm in which the addresses are appropriate for the link from which the message was received, but the server doesn't have a binding for the client to confirm that the addresses in the IA have been specifically assigned to the client. >h) Section 17.1.1 - Creation and transmission of reconfigure-init >messages. > >Has the possibility of sending reconfigure-init to a relay been removed >so that the relay can unicast to the clients that it is aware of? There is no mechanism through which a relay agent can forward a reconfigure-init to multiple clients. >i) Section 20.1 - Format of DHCP Options. >We should be explicit in saying that the option code and option length >are in network byte order. OK. >j) I feel that we should also add "Vendor class" and "User class" >options to the draft. I can prepare the text for these two options if >desired. OK, I'll accept your offer to write up text for "Vendor class" and "User class". Thanks! _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg ------_=_NextPart_001_01C155A4.24905200 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] Rev of DHCPv6 spec

Ralph:

Some other changes you might think about making (I'm = still in the process of reviewing the draft):

1. Section 10 (DUIDs). I think it is important to = state that the server should treat the entire DUID as an opaque value = and use it only in comparing DUIDs with each other - the server should = not take apart the DUID or restrict the DUID types to the values = specified as future documents may define new types.

2. The example in 10.3 is broken. There are only 7 = octets before "example.com", not the required 8.

3. In section 20.2, I thought we were going to drop = the "DUID len" field from the option as it wasn't required = (DUID len is option-len - 2 (for the DUID type)).

4. In section 7.5, some of the timings are a bit = short. I haven't investigated this in detail yet, but when one = considers the speed of dial-up links and round trip times, I'm just a = bit concerned that 250 msecs is a bit short.

5. In 9.2, you might want to indicate that the = link-prefix and client-return-address fields are copied from the = Relay-forward.

6. Section 15.1.1 (Use of XID Field) should probably = be moved to apply globally not just to "Client Behavior" = unter "DHCP Server Solicitation"?

7. In Section 15.1.3, the destination port number is = not specified.

- Bernie

-----Original Message-----
From: Ralph Droms [mailto:rdroms@cisco.com]
Sent: Monday, October 15, 2001 1:37 PM
To: Thirumalesh Bhat
Cc: dhcwg@ietf.org
Subject: RE: [dhcwg] Rev of DHCPv6 spec


Thanks for your review and feedback.  I haven't = sent in the -20 rev to the
IETF for publication, so I can still make some = changes based on your
comments.  I'll respond to your comments in = line...

- Ralph

At 09:33 AM 10/15/2001 -0700, Thirumalesh Bhat = wrote:
>Some comments on the latest draft below:
>
>a) Section 10.1 - DUIDs
>         = Do we have an upper limit on the DUID length? I thought we had a
>prior thread regarding DUIDs where it was agreed = that the upper limit on
>DUID length will help the server = implementation.

Yes - I think we put an upper limit of 256 bytes on a = DUID.  I'll add that
restriction to the spec.

>b) Section 15.1.2 Creation of Solicit = messages:
>    Can the client send a solicit = message without an IA. An example would
>be for a client to check the servers that can = provide the options it
>needs.

Yes - I'll make sure that it's clear that a client = can send a Solicit
without IAs.

>c) Section 15.1.3 Transmission of Solicit = Messages:
>The draft says "The client sends the = Solicit message to the
>All_Dhcp_Agents" multicast address". = How would this work if the DHCP
>Server is on the same segment as the client? = Probably the DHCP server
>should bind to "ALL_Dhcp_Agents" as = well as "All_DHCP_Servers" address.

Turns out the naming of the of these multicast = addresses is potentially
confusing; both servers and relay agents are members = of the
All_DHCP_Agents multicast group:

       All_DHCP_Agents = address:  FF02::1:2 This link-scoped multicast
          &nb= sp;       address is used by clients to = communicate with the
          &nb= sp;       on-link agent(s) when they do = not know the link-local
          &nb= sp;       address(es) for those = agents.  All agents (servers and
          &nb= sp;       relays) are members of this = multicast group.


>d) Section 15.1.4: Receipt of Advertise = Messages:
>Is there a recommendation on how long a client = should wait to collect
>response from all the responding servers or is = this implementation
>specific?

The intention is that SOL_TIMEOUT defines the time = during which the
client collects responses.  If that's not = clear, we'll need to fix
the text:

    The client transmits the message = according to section 13, using the
    following parameters:

       IRT   = SOL_TIMEOUT

       MRT   = SOL_MAX_RT

       MRC   = 0

       MRD   = 0

    The mechanism in section 13 is = modified as follows for use in the
    transmission of Solicit = messages.  The message exchange is not
    terminated by the receipt of an = Advertise before SOL_TIMEOUT has
    elapsed.  Rather, the client = collects Advertise messages until
    SOL_TIMEOUT has elapsed.  = The first RT MUST be selected to be
    strictly greater than SOL_TIMEOUT = by choosing RAND to be strictly
    greater than 0.

    A client MUST collect Advertise = messages for SOL_TIMEOUT seconds,
    unless it receives an Advertise = message with a preference value
    of 255.  The preference = value is carried in the Preference option
    (section  20.5).  Any = Solicit that does not include a Preference
    option is considered to have a = preference value of 0.  If the client
    receives an Advertise message = with a preference value of 255, then
    the client MAY act immediately on = that Advertise message without
    waiting for any more additional = Advertise messages.

>e) Section 15.2.2 - Creation and transmission of = Advertise messages:
>third paragraph:
>What happens if the client doesn't send an IA - = does the server ignore
>the packet?

I guess the answer to this question is related to the = answer to your
question (b).  If a client is allowed to send a = Solicit with no IAs,
the text in 15.2.2 must be clarified to allow a = server to respond with
an Advertise with no IAs.  The server can't = generate IAs for the client;
all it can do is fill in IAs supplied by the = client.

>f) Section 16.1.5
>When a client receives AddrUnavail status should = it create a new IA? I
>would think that the client should create a new = IA if it receives
>NoPrefixMatch status back.

The client doesn't have to create a new IA; it just = has to find a different
server that will agree to put addresses in the = IA.

>Not sure the reason for the use of = "ConfNoMatch" status - I think the
>other error codes can pretty much tell the = client what to do. Same goes
>for the error codes "RenwNoMatch", = "RebdNoMatch".

The "*NoMatch" status codes are the analog = of DHCPNAK in DHCPv4;
a mechanism through which the server can tell the = client that
the client needs to recontact the server for new = configuration
information.

>g) Section 16.2.2 Receipt of confirm = messages:
>
>"If the server cannot determine if the info = in the confirm message is
>valid or invalid, the server MUST NOT send a = reply to the client".
>
>This statement is a bit confusing. A server = might be able to figure out
>that the client request is not valid as far as = it is confirmed but it
>cant verify if it is invalid to other = servers.
>
>May be the server should send its error message = anyway and the client
>should wait for a certain period of time ( as it = does for advertise
>messages ) to check if there is a server that = can serve its needs.

The spec presumes that the servers are all configured = consistently,
so the presumption is the client won't get some ACK = and some NAK
responses.  The text you quote allows for the = fact that a server
may get a Confirm in which the addresses are = appropriate for the
link from which the message was received, but the = server doesn't
have a binding for the client to confirm that the = addresses in
the IA have been specifically assigned to the = client.

>h) Section 17.1.1 - Creation and transmission of = reconfigure-init
>messages.
>
>Has the possibility of sending reconfigure-init = to a relay been removed
>so that the relay can unicast to the clients = that it is aware of?

There is no mechanism through which a relay agent can = forward a
reconfigure-init to multiple clients.

>i) Section 20.1 - Format of DHCP Options.
>We should be explicit in saying that the option = code and option length
>are in network byte order.

OK.

>j) I feel that we should also add "Vendor = class" and "User class"
>options to the draft. I can prepare the text for = these two options if
>desired.

OK, I'll accept your offer to write up text for = "Vendor class" and
"User class".  Thanks!



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

------_=_NextPart_001_01C155A4.24905200-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Oct 15 14:32:04 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08964; Mon, 15 Oct 2001 14:32:04 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA03116; Mon, 15 Oct 2001 14:30:50 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA03089 for ; Mon, 15 Oct 2001 14:30:49 -0400 (EDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08934 for ; Mon, 15 Oct 2001 14:30:46 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f9FIUGk23989; Mon, 15 Oct 2001 11:30:16 -0700 (PDT) Date: Mon, 15 Oct 2001 14:30:11 -0400 (EDT) From: Ralph Droms To: "Bernie Volz (EUD)" cc: Thirumalesh Bhat , Subject: RE: [dhcwg] Rev of DHCPv6 spec In-Reply-To: <66F66129A77AD411B76200508B65AC697B3788@eambunt705.ena-east.ericsson.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org OK - thanks, Bernie. I'll make these changes, as well. - Ralph On Mon, 15 Oct 2001, Bernie Volz (EUD) wrote: > Ralph: > > Some other changes you might think about making (I'm still in the process of reviewing the draft): > > 1. Section 10 (DUIDs). I think it is important to state that the server should treat the entire DUID as an opaque value and use it only in comparing DUIDs with each other - the server should not take apart the DUID or restrict the DUID types to the values specified as future documents may define new types. > > 2. The example in 10.3 is broken. There are only 7 octets before "example.com", not the required 8. > > 3. In section 20.2, I thought we were going to drop the "DUID len" field from the option as it wasn't required (DUID len is option-len - 2 (for the DUID type)). > > 4. In section 7.5, some of the timings are a bit short. I haven't investigated this in detail yet, but when one considers the speed of dial-up links and round trip times, I'm just a bit concerned that 250 msecs is a bit short. > > 5. In 9.2, you might want to indicate that the link-prefix and client-return-address fields are copied from the Relay-forward. > > 6. Section 15.1.1 (Use of XID Field) should probably be moved to apply globally not just to "Client Behavior" unter "DHCP Server Solicitation"? > > 7. In Section 15.1.3, the destination port number is not specified. > > - Bernie > > -----Original Message----- > From: Ralph Droms [mailto:rdroms@cisco.com] > Sent: Monday, October 15, 2001 1:37 PM > To: Thirumalesh Bhat > Cc: dhcwg@ietf.org > Subject: RE: [dhcwg] Rev of DHCPv6 spec > > > Thanks for your review and feedback. I haven't sent in the -20 rev to the > IETF for publication, so I can still make some changes based on your > comments. I'll respond to your comments in line... > > - Ralph > > At 09:33 AM 10/15/2001 -0700, Thirumalesh Bhat wrote: > >Some comments on the latest draft below: > > > >a) Section 10.1 - DUIDs > > Do we have an upper limit on the DUID length? I thought we had a > >prior thread regarding DUIDs where it was agreed that the upper limit on > >DUID length will help the server implementation. > > Yes - I think we put an upper limit of 256 bytes on a DUID. I'll add that > restriction to the spec. > > >b) Section 15.1.2 Creation of Solicit messages: > > Can the client send a solicit message without an IA. An example would > >be for a client to check the servers that can provide the options it > >needs. > > Yes - I'll make sure that it's clear that a client can send a Solicit > without IAs. > > >c) Section 15.1.3 Transmission of Solicit Messages: > >The draft says "The client sends the Solicit message to the > >All_Dhcp_Agents" multicast address". How would this work if the DHCP > >Server is on the same segment as the client? Probably the DHCP server > >should bind to "ALL_Dhcp_Agents" as well as "All_DHCP_Servers" address. > > Turns out the naming of the of these multicast addresses is potentially > confusing; both servers and relay agents are members of the > All_DHCP_Agents multicast group: > > All_DHCP_Agents address: FF02::1:2 This link-scoped multicast > address is used by clients to communicate with the > on-link agent(s) when they do not know the link-local > address(es) for those agents. All agents (servers and > relays) are members of this multicast group. > > > >d) Section 15.1.4: Receipt of Advertise Messages: > >Is there a recommendation on how long a client should wait to collect > >response from all the responding servers or is this implementation > >specific? > > The intention is that SOL_TIMEOUT defines the time during which the > client collects responses. If that's not clear, we'll need to fix > the text: > > The client transmits the message according to section 13, using the > following parameters: > > IRT SOL_TIMEOUT > > MRT SOL_MAX_RT > > MRC 0 > > MRD 0 > > The mechanism in section 13 is modified as follows for use in the > transmission of Solicit messages. The message exchange is not > terminated by the receipt of an Advertise before SOL_TIMEOUT has > elapsed. Rather, the client collects Advertise messages until > SOL_TIMEOUT has elapsed. The first RT MUST be selected to be > strictly greater than SOL_TIMEOUT by choosing RAND to be strictly > greater than 0. > > A client MUST collect Advertise messages for SOL_TIMEOUT seconds, > unless it receives an Advertise message with a preference value > of 255. The preference value is carried in the Preference option > (section 20.5). Any Solicit that does not include a Preference > option is considered to have a preference value of 0. If the client > receives an Advertise message with a preference value of 255, then > the client MAY act immediately on that Advertise message without > waiting for any more additional Advertise messages. > > >e) Section 15.2.2 - Creation and transmission of Advertise messages: > >third paragraph: > >What happens if the client doesn't send an IA - does the server ignore > >the packet? > > I guess the answer to this question is related to the answer to your > question (b). If a client is allowed to send a Solicit with no IAs, > the text in 15.2.2 must be clarified to allow a server to respond with > an Advertise with no IAs. The server can't generate IAs for the client; > all it can do is fill in IAs supplied by the client. > > >f) Section 16.1.5 > >When a client receives AddrUnavail status should it create a new IA? I > >would think that the client should create a new IA if it receives > >NoPrefixMatch status back. > > The client doesn't have to create a new IA; it just has to find a different > server that will agree to put addresses in the IA. > > >Not sure the reason for the use of "ConfNoMatch" status - I think the > >other error codes can pretty much tell the client what to do. Same goes > >for the error codes "RenwNoMatch", "RebdNoMatch". > > The "*NoMatch" status codes are the analog of DHCPNAK in DHCPv4; > a mechanism through which the server can tell the client that > the client needs to recontact the server for new configuration > information. > > >g) Section 16.2.2 Receipt of confirm messages: > > > >"If the server cannot determine if the info in the confirm message is > >valid or invalid, the server MUST NOT send a reply to the client". > > > >This statement is a bit confusing. A server might be able to figure out > >that the client request is not valid as far as it is confirmed but it > >cant verify if it is invalid to other servers. > > > >May be the server should send its error message anyway and the client > >should wait for a certain period of time ( as it does for advertise > >messages ) to check if there is a server that can serve its needs. > > The spec presumes that the servers are all configured consistently, > so the presumption is the client won't get some ACK and some NAK > responses. The text you quote allows for the fact that a server > may get a Confirm in which the addresses are appropriate for the > link from which the message was received, but the server doesn't > have a binding for the client to confirm that the addresses in > the IA have been specifically assigned to the client. > > >h) Section 17.1.1 - Creation and transmission of reconfigure-init > >messages. > > > >Has the possibility of sending reconfigure-init to a relay been removed > >so that the relay can unicast to the clients that it is aware of? > > There is no mechanism through which a relay agent can forward a > reconfigure-init to multiple clients. > > >i) Section 20.1 - Format of DHCP Options. > >We should be explicit in saying that the option code and option length > >are in network byte order. > > OK. > > >j) I feel that we should also add "Vendor class" and "User class" > >options to the draft. I can prepare the text for these two options if > >desired. > > OK, I'll accept your offer to write up text for "Vendor class" and > "User class". Thanks! > > > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > http://www1.ietf.org/mailman/listinfo/dhcwg > _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Oct 15 14:59:21 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09526; Mon, 15 Oct 2001 14:59:16 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA03558; Mon, 15 Oct 2001 14:57:59 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA03538 for ; Mon, 15 Oct 2001 14:57:56 -0400 (EDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09508 for ; Mon, 15 Oct 2001 14:57:55 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f9FIvKk16119; Mon, 15 Oct 2001 11:57:21 -0700 (PDT) Date: Mon, 15 Oct 2001 14:57:16 -0400 (EDT) From: Ralph Droms To: "Bernie Volz (EUD)" cc: Thirumalesh Bhat , Subject: RE: [dhcwg] Rev of DHCPv6 spec In-Reply-To: <66F66129A77AD411B76200508B65AC697B3788@eambunt705.ena-east.ericsson.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Comments in line. - Ralph On Mon, 15 Oct 2001, Bernie Volz (EUD) wrote: > Ralph: > > Some other changes you might think about making (I'm still in the process of reviewing the draft): > > 1. Section 10 (DUIDs). I think it is important to state that the server should treat the entire DUID as an opaque value and use it only in comparing DUIDs with each other - the server should not take apart the DUID or restrict the DUID types to the values specified as future documents may define new types. Fixed. > 2. The example in 10.3 is broken. There are only 7 octets before "example.com", not the required 8. Fixed. > 3. In section 20.2, I thought we were going to drop the "DUID len" field from the option as it wasn't required (DUID len is option-len - 2 (for the DUID type)). I neglected to remove the 'len' field; it's gone, now... > 4. In section 7.5, some of the timings are a bit short. I haven't investigated this in detail yet, but when one considers the speed of dial-up links and round trip times, I'm just a bit concerned that 250 msecs is a bit short. I'll leave those times alone until I get specific new values... > 5. In 9.2, you might want to indicate that the link-prefix and client-return-address fields are copied from the Relay-forward. That action is specified in 16.2.7. Your comment alerted me to a different goof - I neglected to replace "relay-address" with "link-prefix" in section 12 and 16.2.7. > 6. Section 15.1.1 (Use of XID Field) should probably be moved to apply globally not just to "Client Behavior" unter "DHCP Server Solicitation"? Fixed. > 7. In Section 15.1.3, the destination port number is not specified. That's intentional; the destination port is specified for all client messages in section 7.2. > > - Bernie > > -----Original Message----- > From: Ralph Droms [mailto:rdroms@cisco.com] > Sent: Monday, October 15, 2001 1:37 PM > To: Thirumalesh Bhat > Cc: dhcwg@ietf.org > Subject: RE: [dhcwg] Rev of DHCPv6 spec > > > Thanks for your review and feedback. I haven't sent in the -20 rev to the > IETF for publication, so I can still make some changes based on your > comments. I'll respond to your comments in line... > > - Ralph > > At 09:33 AM 10/15/2001 -0700, Thirumalesh Bhat wrote: > >Some comments on the latest draft below: > > > >a) Section 10.1 - DUIDs > > Do we have an upper limit on the DUID length? I thought we had a > >prior thread regarding DUIDs where it was agreed that the upper limit on > >DUID length will help the server implementation. > > Yes - I think we put an upper limit of 256 bytes on a DUID. I'll add that > restriction to the spec. > > >b) Section 15.1.2 Creation of Solicit messages: > > Can the client send a solicit message without an IA. An example would > >be for a client to check the servers that can provide the options it > >needs. > > Yes - I'll make sure that it's clear that a client can send a Solicit > without IAs. > > >c) Section 15.1.3 Transmission of Solicit Messages: > >The draft says "The client sends the Solicit message to the > >All_Dhcp_Agents" multicast address". How would this work if the DHCP > >Server is on the same segment as the client? Probably the DHCP server > >should bind to "ALL_Dhcp_Agents" as well as "All_DHCP_Servers" address. > > Turns out the naming of the of these multicast addresses is potentially > confusing; both servers and relay agents are members of the > All_DHCP_Agents multicast group: > > All_DHCP_Agents address: FF02::1:2 This link-scoped multicast > address is used by clients to communicate with the > on-link agent(s) when they do not know the link-local > address(es) for those agents. All agents (servers and > relays) are members of this multicast group. > > > >d) Section 15.1.4: Receipt of Advertise Messages: > >Is there a recommendation on how long a client should wait to collect > >response from all the responding servers or is this implementation > >specific? > > The intention is that SOL_TIMEOUT defines the time during which the > client collects responses. If that's not clear, we'll need to fix > the text: > > The client transmits the message according to section 13, using the > following parameters: > > IRT SOL_TIMEOUT > > MRT SOL_MAX_RT > > MRC 0 > > MRD 0 > > The mechanism in section 13 is modified as follows for use in the > transmission of Solicit messages. The message exchange is not > terminated by the receipt of an Advertise before SOL_TIMEOUT has > elapsed. Rather, the client collects Advertise messages until > SOL_TIMEOUT has elapsed. The first RT MUST be selected to be > strictly greater than SOL_TIMEOUT by choosing RAND to be strictly > greater than 0. > > A client MUST collect Advertise messages for SOL_TIMEOUT seconds, > unless it receives an Advertise message with a preference value > of 255. The preference value is carried in the Preference option > (section 20.5). Any Solicit that does not include a Preference > option is considered to have a preference value of 0. If the client > receives an Advertise message with a preference value of 255, then > the client MAY act immediately on that Advertise message without > waiting for any more additional Advertise messages. > > >e) Section 15.2.2 - Creation and transmission of Advertise messages: > >third paragraph: > >What happens if the client doesn't send an IA - does the server ignore > >the packet? > > I guess the answer to this question is related to the answer to your > question (b). If a client is allowed to send a Solicit with no IAs, > the text in 15.2.2 must be clarified to allow a server to respond with > an Advertise with no IAs. The server can't generate IAs for the client; > all it can do is fill in IAs supplied by the client. > > >f) Section 16.1.5 > >When a client receives AddrUnavail status should it create a new IA? I > >would think that the client should create a new IA if it receives > >NoPrefixMatch status back. > > The client doesn't have to create a new IA; it just has to find a different > server that will agree to put addresses in the IA. > > >Not sure the reason for the use of "ConfNoMatch" status - I think the > >other error codes can pretty much tell the client what to do. Same goes > >for the error codes "RenwNoMatch", "RebdNoMatch". > > The "*NoMatch" status codes are the analog of DHCPNAK in DHCPv4; > a mechanism through which the server can tell the client that > the client needs to recontact the server for new configuration > information. > > >g) Section 16.2.2 Receipt of confirm messages: > > > >"If the server cannot determine if the info in the confirm message is > >valid or invalid, the server MUST NOT send a reply to the client". > > > >This statement is a bit confusing. A server might be able to figure out > >that the client request is not valid as far as it is confirmed but it > >cant verify if it is invalid to other servers. > > > >May be the server should send its error message anyway and the client > >should wait for a certain period of time ( as it does for advertise > >messages ) to check if there is a server that can serve its needs. > > The spec presumes that the servers are all configured consistently, > so the presumption is the client won't get some ACK and some NAK > responses. The text you quote allows for the fact that a server > may get a Confirm in which the addresses are appropriate for the > link from which the message was received, but the server doesn't > have a binding for the client to confirm that the addresses in > the IA have been specifically assigned to the client. > > >h) Section 17.1.1 - Creation and transmission of reconfigure-init > >messages. > > > >Has the possibility of sending reconfigure-init to a relay been removed > >so that the relay can unicast to the clients that it is aware of? > > There is no mechanism through which a relay agent can forward a > reconfigure-init to multiple clients. > > >i) Section 20.1 - Format of DHCP Options. > >We should be explicit in saying that the option code and option length > >are in network byte order. > > OK. > > >j) I feel that we should also add "Vendor class" and "User class" > >options to the draft. I can prepare the text for these two options if > >desired. > > OK, I'll accept your offer to write up text for "Vendor class" and > "User class". Thanks! > > > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > http://www1.ietf.org/mailman/listinfo/dhcwg > _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Oct 15 15:03:20 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09669; Mon, 15 Oct 2001 15:03:19 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA03969; Mon, 15 Oct 2001 15:02:26 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA03942 for ; Mon, 15 Oct 2001 15:02:24 -0400 (EDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09656 for ; Mon, 15 Oct 2001 15:02:23 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f9FJ1wk20379 for ; Mon, 15 Oct 2001 12:01:58 -0700 (PDT) Date: Mon, 15 Oct 2001 15:01:53 -0400 (EDT) From: Ralph Droms To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [dhcwg] -20e rev of DHCPv6 spec Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org I've posted a -20e rev to www.dhcp.org, with changes based on recent input from the mailing list... - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Oct 15 21:59:35 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17775; Mon, 15 Oct 2001 21:59:35 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA13110; Mon, 15 Oct 2001 21:54:00 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA13084 for ; Mon, 15 Oct 2001 21:53:59 -0400 (EDT) Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.125]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17728 for ; Mon, 15 Oct 2001 21:53:56 -0400 (EDT) Received: from inet-vrs-01.redmond.corp.microsoft.com ([157.54.8.27]) by mail1.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 15 Oct 2001 18:53:26 -0700 Received: from 157.54.9.108 by inet-vrs-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 15 Oct 2001 18:53:26 -0700 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-imc-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 15 Oct 2001 18:53:26 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 15 Oct 2001 18:53:25 -0700 Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(5.0.2195.3651); Mon, 15 Oct 2001 18:52:57 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6063.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [dhcwg] -20e rev of DHCPv6 spec Date: Mon, 15 Oct 2001 18:52:56 -0700 Message-ID: <2E33960095B58E40A4D3345AB9F65EC102940257@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Thread-Topic: [dhcwg] -20e rev of DHCPv6 spec Thread-Index: AcFVtajl5N+d5xfNRpi5780kcKyvUQAL2f1w From: "Thirumalesh Bhat" To: "Ralph Droms" , X-OriginalArrivalTime: 16 Oct 2001 01:52:57.0268 (UTC) FILETIME=[4726C740:01C155E5] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id VAA13085 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 8bit The text for the user and vendor class options is attached below for review: User Class Option 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OPTION_USER_CLASS | option-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | user class data | | . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ option-code TBD option-len Variable; If n user classes are carried by the option, the length of the option option-len = sum of each of the user class lengths + 2*n. option-data The user classes carried by the client. This option is used by the client to optionally identify itself as representing a user or application. The DHCP server uses the user class information to allocate addresses from a specific pool or select a specific configuration option. The user class option may contain one or more instances of user class data. Each instance of the user class data is formatted as follows: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+ | user class1 len | user1 class data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+ The user class length is two octets long and specifies the length of the opaque user class data in network byte order. Servers may interpret the meanings of multiple class specifications in an implementation dependent or configuration dependent manner, and so the use of multiple classes by a DHCP client should be based on the specific server implementation and configuration which will be used to process that User class option. Servers not equipped to interpret the user class information sent by a client MUST ignore it (although it may be reported). Vendor Class Option 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OPTION_VENDOR_CLASS | option-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | option-data | | . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ option-code TBD option-len Variable option-data The information is an opaque object of option-len octets, presumably interpreted by vendor-specific code on the clients and servers This option is used by clients and servers to exchange vendor- specific information. The definition of this information is vendor specific. The vendor is indicated in the vendor class identifier option. Servers not equipped to interpret the vendor-specific information sent by a client MUST ignore it (although it may be reported). Clients which do not receive desired vendor-specific information SHOULD make an attempt to operate without it, although they may do so(and announce they are doing so) in a degraded mode. If a vendor potentially encodes more than one item of information in this option, then the vendor SHOULD encode the option using "Encapsulated vendor-specific options" as described below: The Encapsulated vendor-specific options field SHOULD be encoded as a sequence of code/length/value fields of identical syntax to the DHCP options field. When encapsulated vendor-specific extensions are used, each of the encapsulated options is formatted as follows. 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | opt code | opt len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | option-data | | . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ References [1] Stump, G., Droms, R., Y.Gu, R.Vyaghrapuri, A. Demirtjis, B. Beser, J. Privat "The User Class Option For DHCP", RFC 3004, November 2000. [2] S. Alexander and R. Droms. DHCP Options and BOOTP Vendor Extensions. Request for Comments (Draft Standard) 2132, Internet Engineering Task Force, March 1997. -----Original Message----- From: Ralph Droms [mailto:rdroms@cisco.com] Sent: Monday, October 15, 2001 12:02 PM To: dhcwg@ietf.org Subject: [dhcwg] -20e rev of DHCPv6 spec I've posted a -20e rev to www.dhcp.org, with changes based on recent input from the mailing list... - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Oct 15 22:05:38 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17863; Mon, 15 Oct 2001 22:05:38 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA13496; Mon, 15 Oct 2001 22:00:30 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA13460 for ; Mon, 15 Oct 2001 22:00:28 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17820 for ; Mon, 15 Oct 2001 22:00:25 -0400 (EDT) Received: from green.bisbee.fugue.com (user-2ivfjsl.dialup.mindspring.com [165.247.207.149]) by toccata.fugue.com (8.11.3/8.6.11) with ESMTP id f9G1xIv06883; Mon, 15 Oct 2001 18:59:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by green.bisbee.fugue.com (8.10.2/8.6.11) with ESMTP id f9G20D100709; Mon, 15 Oct 2001 19:00:13 -0700 (PDT) Date: Mon, 15 Oct 2001 19:00:13 -0700 Subject: Re: [dhcwg] Rev of DHCPv6 spec Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v472) Cc: "Bernie Volz (EUD)" , "'skodati@in.ibm.com'" , , , To: Ralph Droms From: Ted Lemon In-Reply-To: Message-Id: <893C8420-C1D9-11D5-AB61-00039317663C@fugue.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.472) Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 7bit > It probably wouldn't hurt to add a sentence to the effect that a server > MAY choose to accept unicast messages from clients to which the server has > not sent a unicast option. A server might want to reject those messages > because they won't include relay agent options... That sounds like a good plan. _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Oct 16 15:14:54 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16390; Tue, 16 Oct 2001 15:14:54 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA19380; Tue, 16 Oct 2001 15:11:43 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA19354 for ; Tue, 16 Oct 2001 15:11:41 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16179 for ; Tue, 16 Oct 2001 15:11:36 -0400 (EDT) Received: from rdroms-w2k.cisco.com ([161.44.150.41]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id PAA26821 for ; Tue, 16 Oct 2001 15:11:08 -0400 (EDT) Message-Id: <4.3.2.7.2.20011016151128.034cfe20@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 16 Oct 2001 15:12:27 -0400 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [dhcwg] Submission of -20 rev of DHCPv6 spec Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org I've submitted draft-ietf-dhc-dhcpv6-20.txt for publication. It's also available at www.dhcp.org The next rev will be published as soon as we finish the text for IAs... - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Oct 16 17:28:36 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21207; Tue, 16 Oct 2001 17:28:36 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA23857; Tue, 16 Oct 2001 17:23:31 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA23836 for ; Tue, 16 Oct 2001 17:23:30 -0400 (EDT) Received: from imr2.ericy.com (imr2.ericy.com [12.34.240.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21147 for ; Tue, 16 Oct 2001 17:23:27 -0400 (EDT) Received: from mr7.exu.ericsson.se (mr7att.ericy.com [138.85.92.15]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id f9GLN1014370 for ; Tue, 16 Oct 2001 16:23:01 -0500 (CDT) Received: from eamrcnt747.exu.ericsson.se (eamrcnt747.exu.ericsson.se [138.85.133.37]) by mr7.exu.ericsson.se (8.11.3/8.11.3) with SMTP id f9GLN1121140 for ; Tue, 16 Oct 2001 16:23:01 -0500 (CDT) Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt747.exu.ericsson.se ; Tue Oct 16 16:23:00 2001 -0500 Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id <4CP0AV7Y>; Tue, 16 Oct 2001 16:23:00 -0500 Message-ID: <66F66129A77AD411B76200508B65AC697B379D@eambunt705.ena-east.ericsson.se> From: "Bernie Volz (EUD)" To: "'Thirumalesh Bhat'" , Ralph Droms , dhcwg@ietf.org Subject: RE: [dhcwg] -20e rev of DHCPv6 spec Date: Tue, 16 Oct 2001 16:22:57 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C15688.B9D8F8F0" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C15688.B9D8F8F0 Content-Type: text/plain; charset="iso-8859-1" We don't have a vendor class identifier option specified for DHCPv6: "The vendor is indicated in the vendor class identifier option. " So, that option will be required as well. I would assume we'd just take the existing DHCPv4 option (see RFC 2132, section 9.13) changing it to be in the 16-bit option format? - Bernie -----Original Message----- From: Thirumalesh Bhat [mailto:thirub@windows.microsoft.com] Sent: Monday, October 15, 2001 9:53 PM To: Ralph Droms; dhcwg@ietf.org Subject: RE: [dhcwg] -20e rev of DHCPv6 spec The text for the user and vendor class options is attached below for review: User Class Option 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OPTION_USER_CLASS | option-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | user class data | | . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ option-code TBD option-len Variable; If n user classes are carried by the option, the length of the option option-len = sum of each of the user class lengths + 2*n. option-data The user classes carried by the client. This option is used by the client to optionally identify itself as representing a user or application. The DHCP server uses the user class information to allocate addresses from a specific pool or select a specific configuration option. The user class option may contain one or more instances of user class data. Each instance of the user class data is formatted as follows: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+ | user class1 len | user1 class data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+ The user class length is two octets long and specifies the length of the opaque user class data in network byte order. Servers may interpret the meanings of multiple class specifications in an implementation dependent or configuration dependent manner, and so the use of multiple classes by a DHCP client should be based on the specific server implementation and configuration which will be used to process that User class option. Servers not equipped to interpret the user class information sent by a client MUST ignore it (although it may be reported). Vendor Class Option 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OPTION_VENDOR_CLASS | option-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | option-data | | . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ option-code TBD option-len Variable option-data The information is an opaque object of option-len octets, presumably interpreted by vendor-specific code on the clients and servers This option is used by clients and servers to exchange vendor- specific information. The definition of this information is vendor specific. The vendor is indicated in the vendor class identifier option. Servers not equipped to interpret the vendor-specific information sent by a client MUST ignore it (although it may be reported). Clients which do not receive desired vendor-specific information SHOULD make an attempt to operate without it, although they may do so(and announce they are doing so) in a degraded mode. If a vendor potentially encodes more than one item of information in this option, then the vendor SHOULD encode the option using "Encapsulated vendor-specific options" as described below: The Encapsulated vendor-specific options field SHOULD be encoded as a sequence of code/length/value fields of identical syntax to the DHCP options field. When encapsulated vendor-specific extensions are used, each of the encapsulated options is formatted as follows. 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | opt code | opt len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | option-data | | . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ References [1] Stump, G., Droms, R., Y.Gu, R.Vyaghrapuri, A. Demirtjis, B. Beser, J. Privat "The User Class Option For DHCP", RFC 3004, November 2000. [2] S. Alexander and R. Droms. DHCP Options and BOOTP Vendor Extensions. Request for Comments (Draft Standard) 2132, Internet Engineering Task Force, March 1997. -----Original Message----- From: Ralph Droms [mailto:rdroms@cisco.com] Sent: Monday, October 15, 2001 12:02 PM To: dhcwg@ietf.org Subject: [dhcwg] -20e rev of DHCPv6 spec I've posted a -20e rev to www.dhcp.org, with changes based on recent input from the mailing list... - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg ------_=_NextPart_001_01C15688.B9D8F8F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] -20e rev of DHCPv6 spec

We don't have a vendor class identifier option = specified for DHCPv6:

        "The = vendor is indicated in the vendor class identifier option. = "

So, that option will be required as well.

I would assume we'd just take the existing DHCPv4 = option (see RFC 2132,
section 9.13) changing it to be in the 16-bit option = format?

- Bernie

-----Original Message-----
From: Thirumalesh Bhat [mailto:thirub@windows.micro= soft.com]
Sent: Monday, October 15, 2001 9:53 PM
To: Ralph Droms; dhcwg@ietf.org
Subject: RE: [dhcwg] -20e rev of DHCPv6 spec


The text for the user and vendor class options is = attached below for
review:

User Class Option

        0 1 2 3 4 = 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
     = |       = OPTION_USER_CLASS       = |           = option-len          = |
     = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
     |  =             =            user class = data
|
     = |            = ;            = ;     . . = .           &nbs= p;           &nbs= p;     |
     = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=

option-code   TBD

option-len    Variable; If n user = classes are carried by the option, the
length of the option option-len =3D sum of each of = the user class lengths
+ 2*n.

option-data   The user classes carried by = the client.

This option is used by the client to optionally = identify itself as
representing a user or application. The DHCP server = uses the user class
information to allocate addresses from a specific = pool or select a
specific configuration option.

       =20
The user class option may contain one or more = instances of user class
data. Each instance of the user class data is = formatted as follows:

     = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+=
     = |       user class1 = len         = |           user1 = class data    |
     = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+=


The user class length is two octets long and = specifies the length of the
opaque user class data in network byte order. =

Servers may interpret the meanings of multiple class = specifications in
an implementation dependent or configuration = dependent manner, and so
the use of multiple classes by a DHCP client should = be based on the
specific server implementation and configuration = which will be used to
process that User class option. Servers not equipped = to interpret the
user class information sent by a client MUST ignore = it (although it may
be reported).


Vendor Class Option

      0 1 2 3 4 5 6 7 8 9 0 = 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
     = |      = OPTION_VENDOR_CLASS      = |           = option-len          = |
     = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
     = |            = ;            = ;  = option-data          &= nbsp;           &= nbsp;   |
     = |            = ;            = ;     . . = .           &nbs= p;           &nbs= p;     |
     = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=

option-code   TBD

option-len    Variable

option-data   The information is an opaque = object of option-len octets,
presumably interpreted by vendor-specific code on = the clients and
servers

This option is used by clients and servers to = exchange vendor- specific
information. The definition of this information is = vendor specific.
The vendor is indicated in the vendor class = identifier option. Servers
not equipped to interpret the vendor-specific = information sent by a
client MUST ignore it (although it may be reported). = Clients which do
not receive desired vendor-specific information = SHOULD make an attempt
to operate without it, although they may do so(and = announce they are
doing so) in a degraded mode.

If a vendor potentially encodes more than one item of = information in
this option, then the vendor SHOULD encode the = option using
"Encapsulated vendor-specific options" as = described below:

The Encapsulated vendor-specific options field SHOULD = be encoded as a
sequence of code/length/value fields of identical = syntax to the DHCP
options field.

When encapsulated vendor-specific extensions are = used, each of the
encapsulated options is formatted as follows.

      0 1 2 3 4 5 6 7 8 9 0 = 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
     = |       opt = code           &n= bsp;    = |            = ;      opt len      = |
     = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
     = |            = ;            = ;  = option-data          &= nbsp;           &= nbsp;   |
     = |            = ;            = ;     . . = .           &nbs= p;           &nbs= p;     |
     = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=


References

   [1] Stump, G., Droms, R., Y.Gu, = R.Vyaghrapuri, A. Demirtjis, B.
Beser, J. Privat "The User Class Option For = DHCP", RFC 3004, November
2000.
   [2] S. Alexander and R. Droms.  = DHCP Options and BOOTP Vendor
Extensions.  Request for Comments (Draft = Standard) 2132, Internet
Engineering Task Force, March 1997.


-----Original Message-----
From: Ralph Droms [mailto:rdroms@cisco.com]
Sent: Monday, October 15, 2001 12:02 PM
To: dhcwg@ietf.org
Subject: [dhcwg] -20e rev of DHCPv6 spec


I've posted a -20e rev to www.dhcp.org, with changes = based on recent
input from the mailing list...

- Ralph




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

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

------_=_NextPart_001_01C15688.B9D8F8F0-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Oct 16 18:10:42 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21806; Tue, 16 Oct 2001 18:10:42 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA25242; Tue, 16 Oct 2001 18:09:28 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA25165 for ; Tue, 16 Oct 2001 18:09:23 -0400 (EDT) Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21773 for ; Tue, 16 Oct 2001 18:09:18 -0400 (EDT) Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 16 Oct 2001 15:08:51 -0700 Received: from 157.54.9.108 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 16 Oct 2001 15:08:51 -0700 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-imc-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 16 Oct 2001 15:08:50 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 16 Oct 2001 15:08:50 -0700 Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3541.1); Tue, 16 Oct 2001 15:08:21 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6063.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" Subject: RE: [dhcwg] -20e rev of DHCPv6 spec Date: Tue, 16 Oct 2001 15:08:20 -0700 Message-ID: <2E33960095B58E40A4D3345AB9F65EC102940271@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Thread-Topic: [dhcwg] -20e rev of DHCPv6 spec Thread-Index: AcFWiMa1F8+crCM3RSqa6jyhU5/RXgABfp2g From: "Thirumalesh Bhat" To: "Bernie Volz (EUD)" , "Ralph Droms" , X-OriginalArrivalTime: 16 Oct 2001 22:08:21.0121 (UTC) FILETIME=[1127AF10:01C1568F] Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org This is a multi-part message in MIME format. --------------InterScan_NT_MIME_Boundary Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1568F.10EB3056" ------_=_NextPart_001_01C1568F.10EB3056 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks for your comments. You are right - we are just porting the V4 options to V6. I will change the wording to indicate that the vendor is indicated by the client to the server and the server replies with the encapsulated options. =20 thx -----Original Message----- From: Bernie Volz (EUD) [mailto:Bernie.Volz@am1.ericsson.se]=20 Sent: Tuesday, October 16, 2001 2:23 PM To: Thirumalesh Bhat; Ralph Droms; dhcwg@ietf.org Subject: RE: [dhcwg] -20e rev of DHCPv6 spec =09 =09 We don't have a vendor class identifier option specified for DHCPv6:=20 "The vendor is indicated in the vendor class identifier option. "=20 So, that option will be required as well.=20 I would assume we'd just take the existing DHCPv4 option (see RFC 2132,=20 section 9.13) changing it to be in the 16-bit option format?=20 - Bernie=20 -----Original Message-----=20 From: Thirumalesh Bhat [mailto:thirub@windows.microsoft.com]=20 Sent: Monday, October 15, 2001 9:53 PM=20 To: Ralph Droms; dhcwg@ietf.org=20 Subject: RE: [dhcwg] -20e rev of DHCPv6 spec=20 The text for the user and vendor class options is attached below for=20 review:=20 User Class Option=20 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1=20 =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | OPTION_USER_CLASS | option-len |=20 =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | user class data=20 |=20 | . . . |=20 =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 option-code TBD=20 option-len Variable; If n user classes are carried by the option, the=20 length of the option option-len =3D sum of each of the user class lengths=20 + 2*n.=20 option-data The user classes carried by the client.=20 This option is used by the client to optionally identify itself as=20 representing a user or application. The DHCP server uses the user class=20 information to allocate addresses from a specific pool or select a=20 specific configuration option.=20 =20 The user class option may contain one or more instances of user class=20 data. Each instance of the user class data is formatted as follows:=20 =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+=20 | user class1 len | user1 class data |=20 =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+=20 The user class length is two octets long and specifies the length of the=20 opaque user class data in network byte order.=20 Servers may interpret the meanings of multiple class specifications in=20 an implementation dependent or configuration dependent manner, and so=20 the use of multiple classes by a DHCP client should be based on the=20 specific server implementation and configuration which will be used to=20 process that User class option. Servers not equipped to interpret the=20 user class information sent by a client MUST ignore it (although it may=20 be reported).=20 Vendor Class Option=20 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1=20 =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | OPTION_VENDOR_CLASS | option-len |=20 =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | option-data |=20 | . . . |=20 =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 option-code TBD=20 option-len Variable=20 option-data The information is an opaque object of option-len octets,=20 presumably interpreted by vendor-specific code on the clients and=20 servers=20 This option is used by clients and servers to exchange vendor- specific=20 information. The definition of this information is vendor specific.=20 The vendor is indicated in the vendor class identifier option. Servers=20 not equipped to interpret the vendor-specific information sent by a=20 client MUST ignore it (although it may be reported). Clients which do=20 not receive desired vendor-specific information SHOULD make an attempt=20 to operate without it, although they may do so(and announce they are=20 doing so) in a degraded mode.=20 If a vendor potentially encodes more than one item of information in=20 this option, then the vendor SHOULD encode the option using=20 "Encapsulated vendor-specific options" as described below:=20 The Encapsulated vendor-specific options field SHOULD be encoded as a=20 sequence of code/length/value fields of identical syntax to the DHCP=20 options field.=20 When encapsulated vendor-specific extensions are used, each of the=20 encapsulated options is formatted as follows.=20 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1=20 =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | opt code | opt len |=20 =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | option-data |=20 | . . . |=20 =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 References=20 [1] Stump, G., Droms, R., Y.Gu, R.Vyaghrapuri, A. Demirtjis, B.=20 Beser, J. Privat "The User Class Option For DHCP", RFC 3004, November=20 2000.=20 [2] S. Alexander and R. Droms. DHCP Options and BOOTP Vendor Extensions. Request for Comments (Draft Standard) 2132, Internet=20 Engineering Task Force, March 1997.=20 -----Original Message-----=20 From: Ralph Droms [mailto:rdroms@cisco.com]=20 Sent: Monday, October 15, 2001 12:02 PM=20 To: dhcwg@ietf.org=20 Subject: [dhcwg] -20e rev of DHCPv6 spec=20 I've posted a -20e rev to www.dhcp.org, with changes based on recent=20 input from the mailing list...=20 - Ralph=20 _______________________________________________=20 dhcwg mailing list=20 dhcwg@ietf.org=20 http://www1.ietf.org/mailman/listinfo/dhcwg=20 _______________________________________________=20 dhcwg mailing list=20 dhcwg@ietf.org=20 http://www1.ietf.org/mailman/listinfo/dhcwg=20 ------_=_NextPart_001_01C1568F.10EB3056 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Thanks=20 for your comments. You are right - we are just porting the V4 options to = V6. I=20 will change the wording to indicate that the vendor is indicated by the = client=20 to the server and the server replies with the encapsulated=20 options.
 
thx
-----Original Message-----
From: = Bernie Volz=20 (EUD) [mailto:Bernie.Volz@am1.ericsson.se]
Sent: Tuesday, = October=20 16, 2001 2:23 PM
To: Thirumalesh Bhat; Ralph Droms;=20 dhcwg@ietf.org
Subject: RE: [dhcwg] -20e rev of DHCPv6=20 spec

We don't have a vendor class identifier option = specified for=20 DHCPv6:

        "The = vendor is=20 indicated in the vendor class identifier option. "

So, that option will be required as well. =

I would assume we'd just take the existing DHCPv4 = option (see=20 RFC 2132,
section 9.13) changing it to be in = the=20 16-bit option format?

- Bernie

-----Original Message-----
From:=20 Thirumalesh Bhat [mailto:thirub@windows.micros= oft.com]=20
Sent: Monday, October 15, 2001 9:53 PM =
To: Ralph Droms; dhcwg@ietf.org
Subject: RE:=20 [dhcwg] -20e rev of DHCPv6 spec


The text for the user and vendor class options is = attached=20 below for
review:

User Class Option

        0 1 2 3 4 = 5 6 7 8 9=20 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    =20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =
    =20 |      =20 OPTION_USER_CLASS      =20 |          =20 option-len          = |=20
    =20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =
     | =20 =              =            user class = data=20
|
    =20 = |            =             &= nbsp;   =20 . .=20 = .            =             &= nbsp;   =20 |
    =20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =

option-code   TBD

option-len    Variable; If n user = classes are=20 carried by the option, the
length of the = option=20 option-len =3D sum of each of the user class lengths
+=20 2*n.

option-data   The user classes carried by = the=20 client.

This option is used by the client to optionally = identify=20 itself as
representing a user or = application. The DHCP=20 server uses the user class
information to = allocate=20 addresses from a specific pool or select a
specific=20 configuration option.

       
The = user class=20 option may contain one or more instances of user class =
data. Each instance of the user class data is formatted as=20 follows:

    =20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+ =
    =20 |       user class1=20 len        =20 |           user1 = class=20 data    |
    =20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+ =


The user class length is two octets long and = specifies the=20 length of the
opaque user class data in = network byte=20 order.

Servers may interpret the meanings of multiple class = specifications in
an implementation = dependent or=20 configuration dependent manner, and so
the = use of=20 multiple classes by a DHCP client should be based on the =
specific server implementation and configuration which will = be used=20 to
process that User class option. Servers = not=20 equipped to interpret the
user class = information sent=20 by a client MUST ignore it (although it may
be=20 reported).


Vendor Class Option

      0 1 2 3 4 5 6 7 8 9 0 = 1 2 3 4 5=20 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    =20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =
     = |     =20 OPTION_VENDOR_CLASS     =20 |          =20 option-len          = |=20
    =20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =
    =20 = |            =             &= nbsp;=20 = option-data          &n= bsp;           &nb= sp;  =20 |
    =20 = |            =             &= nbsp;   =20 . .=20 = .            =             &= nbsp;   =20 |
    =20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =

option-code   TBD

option-len    Variable

option-data   The information is an opaque = object of=20 option-len octets,
presumably interpreted by = vendor-specific code on the clients and
servers=20

This option is used by clients and servers to = exchange vendor-=20 specific
information. The definition of this = information is vendor specific.
The vendor = is=20 indicated in the vendor class identifier option. Servers =
not equipped to interpret the vendor-specific information = sent by=20 a
client MUST ignore it (although it may be = reported).=20 Clients which do
not receive desired = vendor-specific=20 information SHOULD make an attempt
to = operate without=20 it, although they may do so(and announce they are
doing so) in a degraded mode.

If a vendor potentially encodes more than one item = of=20 information in
this option, then the vendor = SHOULD=20 encode the option using
"Encapsulated = vendor-specific=20 options" as described below:

The Encapsulated vendor-specific options field = SHOULD be=20 encoded as a
sequence of code/length/value = fields of=20 identical syntax to the DHCP
options = field.=20

When encapsulated vendor-specific extensions are = used, each of=20 the
encapsulated options is formatted as=20 follows.

      0 1 2 3 4 5 6 7 8 9 0 = 1 2 3 4 5=20 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    =20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =
    =20 |       opt=20 = code           &nb= sp;   =20 = |            =      =20 opt len      |
    =20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =
    =20 = |            =             &= nbsp;=20 = option-data          &n= bsp;           &nb= sp;  =20 |
    =20 = |            =             &= nbsp;   =20 . .=20 = .            =             &= nbsp;   =20 |
    =20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =


References

   [1] Stump, G., Droms, R., Y.Gu, = R.Vyaghrapuri, A.=20 Demirtjis, B.
Beser, J. Privat "The User = Class Option=20 For DHCP", RFC 3004, November
2000. =
   [2] S. Alexander and R. Droms.  DHCP = Options and=20 BOOTP Vendor
Extensions.  Request for = Comments=20 (Draft Standard) 2132, Internet
Engineering = Task=20 Force, March 1997.


-----Original Message-----
From: Ralph=20 Droms [mailto:rdroms@cisco.com]=20
Sent: Monday, October 15, 2001 12:02 = PM=20
To: dhcwg@ietf.org
Subject: [dhcwg]=20 -20e rev of DHCPv6 spec


I've posted a -20e rev to www.dhcp.org, with changes = based on=20 recent
input from the mailing list... =

- Ralph




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

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

=00 ------_=_NextPart_001_01C1568F.10EB3056-- --------------InterScan_NT_MIME_Boundary-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Oct 16 21:26:52 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23684; Tue, 16 Oct 2001 21:26:48 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA29657; Tue, 16 Oct 2001 21:24:00 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA29638 for ; Tue, 16 Oct 2001 21:23:58 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23676 for ; Tue, 16 Oct 2001 21:23:56 -0400 (EDT) Received: from rdroms-w2k.cisco.com (rtp-vpn1-284.cisco.com [10.82.225.28]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id VAA01402; Tue, 16 Oct 2001 21:23:25 -0400 (EDT) Message-Id: <4.3.2.7.2.20011016212351.034e4b48@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 16 Oct 2001 21:24:36 -0400 To: "Bernie Volz (EUD)" From: Ralph Droms Subject: RE: [dhcwg] -20e rev of DHCPv6 spec Cc: "'Thirumalesh Bhat'" , dhcwg@ietf.org In-Reply-To: <66F66129A77AD411B76200508B65AC697B379D@eambunt705.ena-east .ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Oops - I missed the requirement for the vendor class ID option. We'll put it in the -21 rev... - Ralph At 04:22 PM 10/16/2001 -0500, Bernie Volz (EUD) wrote: >We don't have a vendor class identifier option specified for DHCPv6: > > "The vendor is indicated in the vendor class identifier option. " > >So, that option will be required as well. > >I would assume we'd just take the existing DHCPv4 option (see RFC 2132, >section 9.13) changing it to be in the 16-bit option format? > >- Bernie > >-----Original Message----- >From: Thirumalesh Bhat >[mailto:thirub@windows.microsoft.com] >Sent: Monday, October 15, 2001 9:53 PM >To: Ralph Droms; dhcwg@ietf.org >Subject: RE: [dhcwg] -20e rev of DHCPv6 spec > >The text for the user and vendor class options is attached below for >review: > >User Class Option > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | OPTION_USER_CLASS | option-len | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | user class data >| > | . . . | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >option-code TBD > >option-len Variable; If n user classes are carried by the option, the >length of the option option-len = sum of each of the user class lengths >+ 2*n. > >option-data The user classes carried by the client. > >This option is used by the client to optionally identify itself as >representing a user or application. The DHCP server uses the user class >information to allocate addresses from a specific pool or select a >specific configuration option. > > >The user class option may contain one or more instances of user class >data. Each instance of the user class data is formatted as follows: > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+ > | user class1 len | user1 class data | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+ > >The user class length is two octets long and specifies the length of the >opaque user class data in network byte order. > >Servers may interpret the meanings of multiple class specifications in >an implementation dependent or configuration dependent manner, and so >the use of multiple classes by a DHCP client should be based on the >specific server implementation and configuration which will be used to >process that User class option. Servers not equipped to interpret the >user class information sent by a client MUST ignore it (although it may >be reported). > >Vendor Class Option > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | OPTION_VENDOR_CLASS | option-len | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | option-data | > | . . . | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >option-code TBD > >option-len Variable > >option-data The information is an opaque object of option-len octets, >presumably interpreted by vendor-specific code on the clients and >servers > >This option is used by clients and servers to exchange vendor- specific >information. The definition of this information is vendor specific. >The vendor is indicated in the vendor class identifier option. Servers >not equipped to interpret the vendor-specific information sent by a >client MUST ignore it (although it may be reported). Clients which do >not receive desired vendor-specific information SHOULD make an attempt >to operate without it, although they may do so(and announce they are >doing so) in a degraded mode. > >If a vendor potentially encodes more than one item of information in >this option, then the vendor SHOULD encode the option using >"Encapsulated vendor-specific options" as described below: > >The Encapsulated vendor-specific options field SHOULD be encoded as a >sequence of code/length/value fields of identical syntax to the DHCP >options field. > >When encapsulated vendor-specific extensions are used, each of the >encapsulated options is formatted as follows. > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | opt code | opt len | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | option-data | > | . . . | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >References > > [1] Stump, G., Droms, R., Y.Gu, R.Vyaghrapuri, A. Demirtjis, B. >Beser, J. Privat "The User Class Option For DHCP", RFC 3004, November >2000. > [2] S. Alexander and R. Droms. DHCP Options and BOOTP Vendor >Extensions. Request for Comments (Draft Standard) 2132, Internet >Engineering Task Force, March 1997. > >-----Original Message----- >From: Ralph Droms [mailto:rdroms@cisco.com] >Sent: Monday, October 15, 2001 12:02 PM >To: dhcwg@ietf.org >Subject: [dhcwg] -20e rev of DHCPv6 spec > >I've posted a -20e rev to www.dhcp.org, with changes based on recent >input from the mailing list... > >- Ralph > > > >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >http://www1.ietf.org/mailman/listinfo/dhcwg > > >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >http://www1.ietf.org/mailman/listinfo/dhcwg > _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Oct 16 22:21:11 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25123; Tue, 16 Oct 2001 22:21:10 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA01223; Tue, 16 Oct 2001 22:17:55 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA01198 for ; Tue, 16 Oct 2001 22:17:54 -0400 (EDT) Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.125]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25107 for ; Tue, 16 Oct 2001 22:17:52 -0400 (EDT) Received: from inet-vrs-01.redmond.corp.microsoft.com ([157.54.8.27]) by mail1.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 16 Oct 2001 19:17:25 -0700 Received: from 157.54.9.108 by inet-vrs-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 16 Oct 2001 19:17:25 -0700 Received: from red-imc-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-imc-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 16 Oct 2001 19:17:21 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 16 Oct 2001 19:17:21 -0700 Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3541.1); Tue, 16 Oct 2001 19:17:19 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6063.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [dhcwg] -20e rev of DHCPv6 spec Date: Tue, 16 Oct 2001 19:16:51 -0700 Message-ID: <2E33960095B58E40A4D3345AB9F65EC10294027D@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Thread-Topic: [dhcwg] -20e rev of DHCPv6 spec Thread-Index: AcFWiMa1F8+crCM3RSqa6jyhU5/RXgAKJrlg From: "Thirumalesh Bhat" To: "Bernie Volz (EUD)" , "Ralph Droms" , X-OriginalArrivalTime: 17 Oct 2001 02:17:19.0684 (UTC) FILETIME=[D93B8040:01C156B1] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id WAA01199 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 8bit Bernie/Ralph - I changed the message slightly to make it clear that the same option ( for vendor specific option ) can be used when the client communicates with the server and the server communicates with the client. -- User Class Option 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OPTION_USER_CLASS | option-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | user class data | | . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ option-code TBD option-len Variable; If n user classes are carried by the option, the length of the option option-len = sum of each of the user class lengths + 2*n. option-data The user classes carried by the client. This option is used by the client to optionally identify itself as representing a user or application. The DHCP server uses the user class information to allocate addresses from a specific pool or select a specific configuration option. The user class option may contain one or more instances of user class data. Each instance of the user class data is formatted as follows: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+ | user class1 len | user1 class data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+ The user class length is two octets long and specifies the length of the opaque user class data in network byte order. Servers may interpret the meanings of multiple class specifications in an implementation dependent or configuration dependent manner, and so the use of multiple classes by a DHCP client should be based on the specific server implementation and configuration which will be used to process that User class option. Servers not equipped to interpret the user class information sent by a client MUST ignore it (although it may be reported). Vendor Class Option 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OPTION_VENDOR_CLASS | option-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | option-data | | . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ option-code TBD option-len Variable option-data The information is an opaque object of option-len octets, presumably interpreted by vendor-specific code on the clients and servers This option is used by clients and servers to exchange vendor- specific information. The definition of this information is vendor specific. The vendor is indicated in the OPTION_VENDOR_CLASS option. Servers not equipped to interpret the vendor-specific information sent by a client MUST ignore it (although it may be reported). Clients which do not receive desired vendor-specific information SHOULD make an attempt to operate without it, although they may do so(and announce they are doing so) in a degraded mode. The vendor specific data sent by the client to the server is formatted in the OPTION_VENDOR_CLASS as indicated below. +-+-+-+-...-+-+-+-+-+-+-+ | vendor data | +-+-+-+-...-+-+-+-+-+-+-+ If a vendor potentially encodes more than one item of information in this option when communicating to the client from the server, then the vendor SHOULD encode the option using "Encapsulated vendor-specific options" as described below: The Encapsulated vendor-specific options field SHOULD be encoded as a sequence of code/length/value fields of identical syntax to the DHCP options field. When encapsulated vendor-specific extensions are used, each of the encapsulated options is formatted as follows. 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | opt code | opt len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | option-data | | . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ References [1] Stump, G., Droms, R., Y.Gu, R.Vyaghrapuri, A. Demirtjis, B. Beser, J. Privat "The User Class Option For DHCP", RFC 3004, November 2000. [2] S. Alexander and R. Droms. DHCP Options and BOOTP Vendor Extensions. Request for Comments (Draft Standard) 2132, Internet Engineering Task Force, March 1997. -----Original Message----- From: Bernie Volz (EUD) [mailto:Bernie.Volz@am1.ericsson.se] Sent: Tuesday, October 16, 2001 2:23 PM To: Thirumalesh Bhat; Ralph Droms; dhcwg@ietf.org Subject: RE: [dhcwg] -20e rev of DHCPv6 spec We don't have a vendor class identifier option specified for DHCPv6: "The vendor is indicated in the vendor class identifier option. " So, that option will be required as well. I would assume we'd just take the existing DHCPv4 option (see RFC 2132, section 9.13) changing it to be in the 16-bit option format? - Bernie -----Original Message----- From: Thirumalesh Bhat [mailto:thirub@windows.microsoft.com] Sent: Monday, October 15, 2001 9:53 PM To: Ralph Droms; dhcwg@ietf.org Subject: RE: [dhcwg] -20e rev of DHCPv6 spec The text for the user and vendor class options is attached below for review: User Class Option 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OPTION_USER_CLASS | option-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | user class data | | . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ option-code TBD option-len Variable; If n user classes are carried by the option, the length of the option option-len = sum of each of the user class lengths + 2*n. option-data The user classes carried by the client. This option is used by the client to optionally identify itself as representing a user or application. The DHCP server uses the user class information to allocate addresses from a specific pool or select a specific configuration option. The user class option may contain one or more instances of user class data. Each instance of the user class data is formatted as follows: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+ | user class1 len | user1 class data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+ The user class length is two octets long and specifies the length of the opaque user class data in network byte order. Servers may interpret the meanings of multiple class specifications in an implementation dependent or configuration dependent manner, and so the use of multiple classes by a DHCP client should be based on the specific server implementation and configuration which will be used to process that User class option. Servers not equipped to interpret the user class information sent by a client MUST ignore it (although it may be reported). Vendor Class Option 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OPTION_VENDOR_CLASS | option-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | option-data | | . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ option-code TBD option-len Variable option-data The information is an opaque object of option-len octets, presumably interpreted by vendor-specific code on the clients and servers This option is used by clients and servers to exchange vendor- specific information. The definition of this information is vendor specific. The vendor is indicated in the vendor class identifier option. Servers not equipped to interpret the vendor-specific information sent by a client MUST ignore it (although it may be reported). Clients which do not receive desired vendor-specific information SHOULD make an attempt to operate without it, although they may do so(and announce they are doing so) in a degraded mode. If a vendor potentially encodes more than one item of information in this option, then the vendor SHOULD encode the option using "Encapsulated vendor-specific options" as described below: The Encapsulated vendor-specific options field SHOULD be encoded as a sequence of code/length/value fields of identical syntax to the DHCP options field. When encapsulated vendor-specific extensions are used, each of the encapsulated options is formatted as follows. 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | opt code | opt len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | option-data | | . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ References [1] Stump, G., Droms, R., Y.Gu, R.Vyaghrapuri, A. Demirtjis, B. Beser, J. Privat "The User Class Option For DHCP", RFC 3004, November 2000. [2] S. Alexander and R. Droms. DHCP Options and BOOTP Vendor Extensions. Request for Comments (Draft Standard) 2132, Internet Engineering Task Force, March 1997. -----Original Message----- From: Ralph Droms [mailto:rdroms@cisco.com] Sent: Monday, October 15, 2001 12:02 PM To: dhcwg@ietf.org Subject: [dhcwg] -20e rev of DHCPv6 spec I've posted a -20e rev to www.dhcp.org, with changes based on recent input from the mailing list... - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Oct 17 05:35:23 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16716; Wed, 17 Oct 2001 05:35:23 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA18586; Wed, 17 Oct 2001 05:34:01 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA18569 for ; Wed, 17 Oct 2001 05:33:59 -0400 (EDT) Received: from uq.net.au (root@fox.uq.net.au [203.101.255.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16710 for ; Wed, 17 Oct 2001 05:33:57 -0400 (EDT) Received: from puss (d-7-167.stlucia.uq.net.au [203.100.7.167]) by uq.net.au (8.9.3/8.9.3) with SMTP id TAA12621 for ; Wed, 17 Oct 2001 19:33:58 +1000 (GMT+1000) Message-ID: <003001c156ef$4e543b00$a70764cb@puss> From: "Rouhshi Low" To: Date: Wed, 17 Oct 2001 19:37:14 +1000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_002D_01C15743.1F619A00" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Subject: [dhcwg] Which network devices may not use DHCP? Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_002D_01C15743.1F619A00 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Can someone tell me which network devices may use DHCP and which must = not (and why not)?=20 Rouhshi ------=_NextPart_000_002D_01C15743.1F619A00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Can someone tell me which network = devices may use=20 DHCP and which must not (and why not)?
 
Rouhshi
------=_NextPart_000_002D_01C15743.1F619A00-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Oct 17 12:29:28 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29355; Wed, 17 Oct 2001 12:29:27 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA01435; Wed, 17 Oct 2001 12:28:28 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA01419 for ; Wed, 17 Oct 2001 12:28:26 -0400 (EDT) Received: from internaut.com ([64.38.134.99]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29327 for ; Wed, 17 Oct 2001 12:28:24 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id JAA11902; Wed, 17 Oct 2001 09:20:40 -0700 (PDT) (envelope-from aboba@internaut.com) Date: Wed, 17 Oct 2001 09:20:40 -0700 (PDT) From: Bernard Aboba To: Rouhshi Low cc: dhcwg@ietf.org Subject: Re: [dhcwg] Which network devices may not use DHCP? In-Reply-To: <003001c156ef$4e543b00$a70764cb@puss> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org > Can someone tell me which network devices may use DHCP and which must not (and why not)? > > Rouhshi > In general, IPv4 hosts which use static addressing or IPv4 linklocal addresses exclusively will not use DHCPv4 for addressing. Similarly, IPv6 hosts may use stateless autoconfig, and so may not need DHCPv6 for addressing. However, even if addresses aren't needed, DHCPv4 or DHCPv6 might still be used to obtain configuration information. Check out: draft-ietf-zeroconf-ipv4-linklocal-04.txt for more info on IPv4 linklocal addressing. _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Oct 18 07:12:16 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04055; Thu, 18 Oct 2001 07:12:16 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA04669; Thu, 18 Oct 2001 07:08:33 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA04647 for ; Thu, 18 Oct 2001 07:08:32 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03817; Thu, 18 Oct 2001 07:08:28 -0400 (EDT) Message-Id: <200110181108.HAA03817@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: dhcwg@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Thu, 18 Oct 2001 07:08:27 -0400 Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-dhcpv6-20.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@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 : Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Author(s) : J. Bound, M. Carney, C. Perkins, R. Droms Filename : draft-ietf-dhc-dhcpv6-20.txt Pages : 72 Date : 17-Oct-01 The Dynamic Host Configuration Protocol for IPv6 (DHCP) enables DHCP servers to pass configuration parameters such as IPv6 network addresses to IPv6 nodes. It offers the capability of automatic allocation of reusable network addresses and additional configuration flexibility. This protocol is a stateful counterpart to 'IPv6 Stateless Address Autoconfiguration' [13], and can be used separately or concurrently with the latter to obtain configuration parameters. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-20.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dhc-dhcpv6-20.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dhc-dhcpv6-20.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: <20011017113514.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-dhcpv6-20.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-dhcpv6-20.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20011017113514.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Oct 18 07:34:43 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04550; Thu, 18 Oct 2001 07:34:42 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA05518; Thu, 18 Oct 2001 07:33:31 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA05491 for ; Thu, 18 Oct 2001 07:33:29 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04480 for ; Thu, 18 Oct 2001 07:33:25 -0400 (EDT) Received: from rdroms-w2k.cisco.com (rtp-vpn2-29.cisco.com [10.82.240.29]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id HAA29921 for ; Thu, 18 Oct 2001 07:32:59 -0400 (EDT) Message-Id: <4.3.2.7.2.20011018072637.03533de8@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 18 Oct 2001 07:27:46 -0400 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [dhcwg] WG scheduling in Salt Lake City Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org I plan to request one slot for a DHC WG meeting. Please let me know if you have conflicts with other WGs you want to avoid. - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Oct 19 00:07:58 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25865; Fri, 19 Oct 2001 00:07:58 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA03901; Fri, 19 Oct 2001 00:05:11 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA03874 for ; Fri, 19 Oct 2001 00:05:10 -0400 (EDT) Received: from hotmail.com (f265.law7.hotmail.com [216.33.236.143]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25857 for ; Fri, 19 Oct 2001 00:05:08 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 18 Oct 2001 21:04:39 -0700 Received: from 130.102.79.7 by lw7fd.law7.hotmail.msn.com with HTTP; Fri, 19 Oct 2001 04:04:39 GMT X-Originating-IP: [130.102.79.7] From: "Darren Jonsson" To: dhcwg@ietf.org Date: Fri, 19 Oct 2001 14:04:39 +1000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 19 Oct 2001 04:04:39.0427 (UTC) FILETIME=[2C71CD30:01C15853] Subject: [dhcwg] DHCP & Organisations Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org How and why would DHCP be used within an organisation? Also What is the relationship in functionality between DHCP and NAT? Thanks Darren -------------- Regards Darren Jonsson -------------- _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sun Oct 21 05:28:16 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11391; Sun, 21 Oct 2001 05:28:12 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA04824; Sun, 21 Oct 2001 05:20:20 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA04794 for ; Sun, 21 Oct 2001 05:20:18 -0400 (EDT) Received: from trinity.cc.uq.edu.au (trinity.cc.uq.edu.au [130.102.5.4]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11369 for ; Sun, 21 Oct 2001 05:20:15 -0400 (EDT) Received: from nightmare (ihj14.inthouse.uq.edu.au [172.21.29.156]) by trinity.cc.uq.edu.au (8.11.6/8.11.6) with SMTP id f9L9JZf17906 for ; Sun, 21 Oct 2001 19:19:35 +1000 (EST) Message-ID: <005001c15a11$7f843840$9c1d15ac@inthouse.uq.edu.au> From: "Obi Ukabiala" To: Date: Sun, 21 Oct 2001 19:19:32 +1000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_004D_01C15A65.509010A0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: [dhcwg] Limitations of DHCP Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_004D_01C15A65.509010A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I am presently researching into the use of DHCP. I have read of lots of = its benefits, can anyone let me know of some of its limitations. = Specifically, I am inetersted in knowing if all the network devices of = an organisation can use DHCP. Thanks, Obi Ukabiala ------=_NextPart_000_004D_01C15A65.509010A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
 
I am presently researching into the use = of DHCP. I=20 have read of lots of its benefits, can anyone let me know of some of its = limitations. Specifically, I am inetersted in knowing if all the network = devices=20 of an organisation can use DHCP.
 
Thanks,
 
Obi Ukabiala
------=_NextPart_000_004D_01C15A65.509010A0-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Oct 22 10:39:01 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18810; Mon, 22 Oct 2001 10:38:56 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA23181; Mon, 22 Oct 2001 10:35:46 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA23155 for ; Mon, 22 Oct 2001 10:35:45 -0400 (EDT) Received: from curlew.cs.man.ac.uk (noplay@curlew.cs.man.ac.uk [130.88.13.7]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18738 for ; Mon, 22 Oct 2001 10:35:41 -0400 (EDT) Received: from mrbounce.compsoc.man.ac.uk ([192.84.78.5]) by curlew.cs.man.ac.uk with esmtp (Exim 2.05 #6) id 15vgB7-0005iB-00 for dhcwg@ietf.org; Mon, 22 Oct 2001 15:35:45 +0100 Received: from mrbusy.compsoc.man.ac.uk ([192.84.78.3]) by mrbounce.compsoc.man.ac.uk with esmtp (Exim 3.22 #1) id 15vgB6-0001jl-00 for dhcwg@ietf.org; Mon, 22 Oct 2001 15:35:44 +0100 Received: from jason by mrbusy.compsoc.man.ac.uk with local (Exim 3.12 #1 (Debian)) id 15vgB5-0005Xh-00 for ; Mon, 22 Oct 2001 15:35:43 +0100 Date: Mon, 22 Oct 2001 15:35:43 +0100 From: Jason Williams To: dhcwg@ietf.org Message-ID: <20011022153543.J29607@mrbusy.compsoc.man.ac.uk> Reply-To: jason@compsoc.man.ac.uk Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="nfvf/JXVyOeI7XiA" Content-Disposition: inline User-Agent: Mutt/1.2.5i X-Geek-Code: GCS d- s-:- a-- C++ UL+++ P+++ L+++ E--- W++ N++ o? K w--- O- M-- V- PS+ PE- Y+ PGP++ t 5? X R tv b+ DI+ D+ G e+>++ h- r y+ X-PGP-keyid: 0x683DE441 X-PGP-fingerprint: 6CFF 566A 1772 F72F 8948 67AB 703B DD4B 683D E441 X-PGP-key-at: http://www.compsoc.man.ac.uk/~jason/pubkey.asc Subject: [dhcwg] draft-ietf-dhc-dhcpv6-20 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org --nfvf/JXVyOeI7XiA Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Good afternoon... Having breathlessly rushed to download and print off the lovely draft 20 of your DHCPv6 specification, I can't help noticing it seems to be short a change log - was there a reason for this?=20 Thanks. --=20 jason@khendon.org.uk --nfvf/JXVyOeI7XiA Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 5.0i for non-commercial use MessageID: v6ZWuPHMuvqmv8YahhHbuAeQTOOVEZMk iQA/AwUBO9Quv3A73UtoPeRBEQJPdQCg5EMlXDFLKzXWcMlQCFJhUmNzqmgAoNNy 9B0pIw6MPOjYUN5p31e4bT5G =AEzt -----END PGP SIGNATURE----- --nfvf/JXVyOeI7XiA-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From mailman-owner@ietf.org Wed Oct 24 13:43:53 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08272 for ; Wed, 24 Oct 2001 13:43:52 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA04884 for ; Wed, 24 Oct 2001 13:43:53 -0400 (EDT) Date: Wed, 24 Oct 2001 13:43:53 -0400 (EDT) Message-Id: <200110241743.NAA04884@optimus.ietf.org> From: mailman-owner@ietf.org Subject: ietf.org mailing list memberships reminder To: dhc-archive@ietf.org X-No-Archive: yes Precedence: bulk X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, dhcwg-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. If you have questions, problems, comments, etc, send them to mailman-owner@ietf.org. Thanks! Passwords for dhc-archive@lists.ietf.org: List Password // URL ---- -------- dhcwg@ietf.org aCBd http://www1.ietf.org/mailman/options/dhcwg/dhc-archive@lists.ietf.org From dhcwg-admin@ietf.org Wed Oct 24 13:58:04 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09226; Wed, 24 Oct 2001 13:58:04 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA14053; Wed, 24 Oct 2001 13:57:15 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA14029 for ; Wed, 24 Oct 2001 13:57:14 -0400 (EDT) Received: from hotmail.com (f205.law9.hotmail.com [64.4.9.205]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09158 for ; Wed, 24 Oct 2001 13:57:12 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 24 Oct 2001 10:56:45 -0700 Received: from 195.217.141.65 by lw9fd.law9.hotmail.msn.com with HTTP; Wed, 24 Oct 2001 17:56:44 GMT X-Originating-IP: [195.217.141.65] From: "Andy Wolstenholme" To: dhcwg@ietf.org Date: Wed, 24 Oct 2001 17:56:44 +0000 Mime-Version: 1.0 Content-Type: text/html Message-ID: X-OriginalArrivalTime: 24 Oct 2001 17:56:45.0189 (UTC) FILETIME=[3E954350:01C15CB5] Subject: [dhcwg] DHCP info Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org
Hi there,
I am currently a student based in london working in the third year of my studies towards a communications and networks degree.  I am basically writing to ask if anyone can point me in the right direction to answer some quiries I have about DHCP.  As my final year poject I intend to build a network administration tool that relies heavily on a DHCP server of (which I currently know very little about) requesting network inforamtion such as IP address lists, and other information.  Firstly can anyone point me in the right direction to find a comprehensive guide to the essentials of DHCP, its administration and how it generally works and stores its information.  Secondly, I will need to build a DHCP server myself upon a linux or windows based environment, initially to show my competence to do so and also to develop my software on a contained LAN.  Can somebody suggest any good comprehensive DHCP server software for the best platform.
 
Your help and suggestions would be greatly appreciated.
 
My Thanks
Andy...

Get your FREE download of MSN Explorer at http://explorer.msn.com
_______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Oct 24 19:51:25 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17349; Wed, 24 Oct 2001 19:51:25 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA03756; Wed, 24 Oct 2001 19:46:38 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA03727 for ; Wed, 24 Oct 2001 19:46:36 -0400 (EDT) Received: from hygro.adsl.duke.edu (cichlid.adsl.duke.edu [152.16.64.203]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17280 for ; Wed, 24 Oct 2001 19:46:35 -0400 (EDT) Received: from hygro.adsl.duke.edu (narten@localhost) by hygro.adsl.duke.edu (8.11.6/8.11.6) with ESMTP id f9ONh4v05425; Wed, 24 Oct 2001 19:43:05 -0400 Message-Id: <200110242343.f9ONh4v05425@hygro.adsl.duke.edu> To: "Bernard Aboba" cc: dhcwg@ietf.org In-Reply-To: Message from "Mon, 01 Oct 2001 14:43:37 EDT." <200110011843.OAA12437@astro.cs.utk.edu> Date: Wed, 24 Oct 2001 19:43:04 -0400 From: Thomas Narten Subject: [dhcwg] Re: Last Call: DHCP Domain Search Option to Proposed Standard Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org IETF Last Call has ended on this document, and I recall that Keith Moore had some comments. Not sure if any other issues were raised. Note that as the document is currently written, I believe it has a normative dependency on the draft-ietf-dhc-concat-01.txt ID. There was some discussion about whether that was necessary or not, but I'm not sure what the final resolution was. In any case, I think wording changes would be need to make the reference non-normative. If the intention is that the reference be normative, we need the other ID to move forward as well. Are there any other issues that need to be resolved? Once the remaining issues are resolved and a new ID is out, I can bring the document before the IESG for consideration. Thomas _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Oct 24 21:38:47 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19924; Wed, 24 Oct 2001 21:38:46 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA07063; Wed, 24 Oct 2001 21:34:43 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA07034 for ; Wed, 24 Oct 2001 21:34:41 -0400 (EDT) Received: from telecom.samsung.co.kr (metro.telecom.samsung.co.kr [165.213.221.4]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19017 for ; Wed, 24 Oct 2001 21:34:38 -0400 (EDT) Received: from cychong (a22421 [165.213.224.21]) by telecom.samsung.co.kr (8.11.6/8.11.6) with SMTP id f9P1Sg503374 for ; Thu, 25 Oct 2001 10:28:43 +0900 (KST) Message-ID: <001801c15cf5$9de5a3a0$15e0d5a5@cychong> From: "Chae-yong Chong" To: Date: Thu, 25 Oct 2001 10:37:31 +0900 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0015_01C15D41.0D46DD90" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Subject: [dhcwg] Question about DHCPv6 bootstraping Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0015_01C15D41.0D46DD90 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 SGkgYWxsLg0KDQpJIGdvdCBhbiBxdWVzdGlvbiBhYm91dCBESENQdjYgdnMuIERIQ1B2NCBvciBC T09UUC4NCg0KV2hpbGUgSSBhbSByZWFkaW5nIGEgREhDUHY2IGRyYWZ0KDE5KSBJIGZpbmQgdGhh dCB0aGUgREhDUHY2IGRvZXMgbm90DQpzdXBwb3J0IGJvb3RzdHJhcHBpbmcgaW5mb3JtYXRpb24g bGlrZSAiYm9vdCBmaWxlbmFtZSIgZmlsZWQgaW4gQk9PVFAuDQoNCkluIHBhZ2UgNjAsDQoNCiAg ICAgbyBTb21lIERIQ1B2NCBvcHRpb25zIGFyZSB1bm5lY2Vzc2FyeSBub3cgYmVjYXVzZSB0aGUg Y29uZmlndXJhdGlvbg0KICAgICAgIHBhcmFtZXRlcnMgYXJlIGVpdGhlciBvYnRhaW5lZCB0aHJv dWdoIElQdjYgTmVpZ2hib3IgRGlzY292ZXJ5IG9yDQogICAgICAgdGhlIFNlcnZpY2UgTG9jYXRp b24gcHJvdG9jb2wgWzIxXS4NCg0KSG93ZXZlciBJIGNhbiBub3QgZmluZCBhbnkgdGV4dCBhYm91 dCBib290c3RyYXBwaW5nIGluIFNMUCBkb2N1bWVudC4NCkNhbiBhbnlib2R5IHBvaW50IG1lIHRv IHRoZSB0ZXh0IG9yIGluZm9ybWF0aW9uIGFib3V0IGJvb3RzdHJhcHBpbmcgaW4gSVB2Nj8NCg0K VGhhbmtzIGluIGFkdmFuY2UuDQoNCkNoYWUteW9uZw0KDQo= ------=_NextPart_000_0015_01C15D41.0D46DD90 Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWtz X2NfNTYwMS0xOTg3IiBodHRwLWVxdWl2PUNvbnRlbnQtVHlwZT4NCjxNRVRBIGNvbnRlbnQ9Ik1T SFRNTCA1LjAwLjMzMTUuMjg3MCIgbmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwv SEVBRD4NCjxCT0RZIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+PEZPTlQgc2l6ZT0yPkhpIGFsbC48 L0ZPTlQ+PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+SSBnb3Qg YW4gcXVlc3Rpb24gYWJvdXQgREhDUHY2IHZzLiBESENQdjQgb3IgDQpCT09UUC48L0ZPTlQ+PC9E SVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+V2hpbGUgSSBhbSByZWFk aW5nIGEgREhDUHY2IGRyYWZ0KDE5KSBJIGZpbmQgdGhhdCB0aGUgREhDUHY2IA0KZG9lcyBub3Q8 L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj5zdXBwb3J0IGJvb3RzdHJhcHBpbmcgaW5m b3JtYXRpb24gbGlrZSAiYm9vdCBmaWxlbmFtZSIgZmlsZWQgDQppbiBCT09UUC48L0ZPTlQ+PC9E SVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+SW4gcGFnZSA2MCw8L0ZP TlQ+PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IG8gU29tZSBESENQdjQgb3B0aW9ucyBhcmUgdW5uZWNlc3NhcnkgDQpu b3cgYmVjYXVzZSB0aGUgY29uZmlndXJhdGlvbjxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgcGFyYW1ldGVycyANCmFyZSBlaXRoZXIgb2J0YWluZWQgdGhyb3VnaCBJUHY2 IE5laWdoYm9yIERpc2NvdmVyeSANCm9yPEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyB0aGUgU2VydmljZSBMb2NhdGlvbiBwcm90b2NvbCANClsyMV0uPC9GT05UPjwvRElW Pg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPkhvd2V2ZXIgSSBjYW4gbm90 IGZpbmQgYW55IHRleHQgYWJvdXQgYm9vdHN0cmFwcGluZyBpbiBTTFAgDQpkb2N1bWVudC48L0ZP TlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj5DYW4gYW55Ym9keSBwb2ludCBtZSB0byB0aGUg dGV4dCBvciBpbmZvcm1hdGlvbiBhYm91dCANCmJvb3RzdHJhcHBpbmcgaW4gSVB2Nj88L0ZPTlQ+ PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+VGhhbmtzIGluIGFk dmFuY2UuPC9GT05UPjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0y PkNoYWUteW9uZzwvRk9OVD48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+PC9CT0RZPjwvSFRNTD4N Cg== ------=_NextPart_000_0015_01C15D41.0D46DD90-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Oct 25 01:06:23 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24671; Thu, 25 Oct 2001 01:06:23 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA12538; Thu, 25 Oct 2001 01:00:49 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA12519 for ; Thu, 25 Oct 2001 01:00:48 -0400 (EDT) Received: from imr2.ericy.com (imr2.ericy.com [12.34.240.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24500 for ; Thu, 25 Oct 2001 01:00:46 -0400 (EDT) Received: from mr6.exu.ericsson.se (mr6att.ericy.com [138.85.92.14]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id f9P50K008769 for ; Thu, 25 Oct 2001 00:00:20 -0500 (CDT) Received: from eamrcnt747.exu.ericsson.se (eamrcnt747.exu.ericsson.se [138.85.133.37]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with SMTP id f9P50Kr26437 for ; Thu, 25 Oct 2001 00:00:20 -0500 (CDT) Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt747.exu.ericsson.se ; Thu Oct 25 00:00:19 2001 -0500 Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id <4CP0T1TH>; Thu, 25 Oct 2001 00:00:19 -0500 Message-ID: <66F66129A77AD411B76200508B65AC697B37E5@eambunt705.ena-east.ericsson.se> From: "Bernie Volz (EUD)" To: "'Chae-yong Chong'" , dhcwg@ietf.org Subject: RE: [dhcwg] Question about DHCPv6 bootstraping Date: Thu, 25 Oct 2001 00:00:19 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C15D11.F1AC1B60" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C15D11.F1AC1B60 Content-Type: text/plain; charset="KS_C_5601-1987" If someone needs the BOOTP functionality - to get the boot filename and other similar parameters - it is fairly easy to do with IPv6 ... write an internet draft to specify the options for DHCPv6. Or send the information to the mailing list and perhaps it will be included in the next revision of the draft. These parameters would not be obtained via SLP or neighbor discovery. They are truely options and simply need to be defined. - Bernie Volz -----Original Message----- From: Chae-yong Chong [mailto:cychong@metro.telecom.samsung.co.kr] Sent: Wednesday, October 24, 2001 9:38 PM To: dhcwg@ietf.org Subject: [dhcwg] Question about DHCPv6 bootstraping Hi all. I got an question about DHCPv6 vs. DHCPv4 or BOOTP. While I am reading a DHCPv6 draft(19) I find that the DHCPv6 does not support bootstrapping information like "boot filename" filed in BOOTP. In page 60, o Some DHCPv4 options are unnecessary now because the configuration parameters are either obtained through IPv6 Neighbor Discovery or the Service Location protocol [21]. However I can not find any text about bootstrapping in SLP document. Can anybody point me to the text or information about bootstrapping in IPv6? Thanks in advance. Chae-yong ------_=_NextPart_001_01C15D11.F1AC1B60 Content-Type: text/html; charset="KS_C_5601-1987"
If someone needs the BOOTP functionality - to get the boot filename and other similar parameters - it is fairly easy to do with IPv6 ... write an internet draft to specify the options for DHCPv6. Or send the information to the mailing list and perhaps it will be included in the next revision of the draft. These parameters would not be obtained via SLP or neighbor discovery. They are truely options and simply need to be defined.
 
- Bernie Volz
-----Original Message-----
From: Chae-yong Chong [mailto:cychong@metro.telecom.samsung.co.kr]
Sent: Wednesday, October 24, 2001 9:38 PM
To: dhcwg@ietf.org
Subject: [dhcwg] Question about DHCPv6 bootstraping

Hi all.
 
I got an question about DHCPv6 vs. DHCPv4 or BOOTP.
 
While I am reading a DHCPv6 draft(19) I find that the DHCPv6 does not
support bootstrapping information like "boot filename" filed in BOOTP.
 
In page 60,
 
     o Some DHCPv4 options are unnecessary now because the configuration
       parameters are either obtained through IPv6 Neighbor Discovery or
       the Service Location protocol [21].
 
However I can not find any text about bootstrapping in SLP document.
Can anybody point me to the text or information about bootstrapping in IPv6?
 
Thanks in advance.
 
Chae-yong
 
------_=_NextPart_001_01C15D11.F1AC1B60-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Oct 25 01:12:51 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA25055; Thu, 25 Oct 2001 01:12:47 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA17378; Thu, 25 Oct 2001 01:08:59 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA17321 for ; Thu, 25 Oct 2001 01:08:57 -0400 (EDT) Received: from imr2.ericy.com (imr2.ericy.com [12.34.240.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24791 for ; Thu, 25 Oct 2001 01:08:55 -0400 (EDT) Received: from mr6.exu.ericsson.se (mr6att.ericy.com [138.85.92.14]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id f9P58T010960 for ; Thu, 25 Oct 2001 00:08:29 -0500 (CDT) Received: from eamrcnt749 (eamrcnt749.exu.ericsson.se [138.85.133.47]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with SMTP id f9P58Tr27692 for ; Thu, 25 Oct 2001 00:08:29 -0500 (CDT) Received: FROM eamrcnt760.exu.ericsson.se BY eamrcnt749 ; Thu Oct 25 00:08:29 2001 -0500 Received: by eamrcnt760.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id <4CQ1JCP9>; Thu, 25 Oct 2001 00:08:29 -0500 Message-ID: <66F66129A77AD411B76200508B65AC697B37E6@eambunt705.ena-east.ericsson.se> From: "Bernie Volz (EUD)" To: "'Thomas Narten'" , Bernard Aboba Cc: dhcwg@ietf.org Subject: RE: [dhcwg] Re: Last Call: DHCP Domain Search Option to Proposed Standard Date: Thu, 25 Oct 2001 00:08:27 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C15D13.14D01EB0" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C15D13.14D01EB0 Content-Type: text/plain; charset="iso-8859-1" Thomas ... I believe the conclusion was that these references to the concat draft are necessary. They are necessary for any options that could possibly ever need to make use of the concat technique. The domain search option is one of the options that could be long enough to require concat techniques. We must require that both the client and server supporting this option MUST also support the concat option. If this isn't the case, then if the server implements concat but the client doesn't, the client may easily improperly process the returned option and this would cause significant problems since the client would not know how to handle multiple occurrences of the option and might use any one of the occurrences (rather than concatenating) or drop the packet as being malformed (since the original DHCP specification said an option may occur only once if I recall correctly). If a new option is defined that has a fixed length (such as carrying a single IP address), there is no need to require that the client and server also implement concat to support that option. - Bernie -----Original Message----- From: Thomas Narten [mailto:narten@us.ibm.com] Sent: Wednesday, October 24, 2001 7:43 PM To: Bernard Aboba Cc: dhcwg@ietf.org Subject: [dhcwg] Re: Last Call: DHCP Domain Search Option to Proposed Standard IETF Last Call has ended on this document, and I recall that Keith Moore had some comments. Not sure if any other issues were raised. Note that as the document is currently written, I believe it has a normative dependency on the draft-ietf-dhc-concat-01.txt ID. There was some discussion about whether that was necessary or not, but I'm not sure what the final resolution was. In any case, I think wording changes would be need to make the reference non-normative. If the intention is that the reference be normative, we need the other ID to move forward as well. Are there any other issues that need to be resolved? Once the remaining issues are resolved and a new ID is out, I can bring the document before the IESG for consideration. Thomas _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg ------_=_NextPart_001_01C15D13.14D01EB0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] Re: Last Call: DHCP Domain Search Option to Proposed = Standard

Thomas ... I believe the conclusion was that these = references to the concat draft are necessary. They are necessary for = any options that could possibly ever need to make use of the concat = technique. The domain search option is one of the options that could be = long enough to require concat techniques.

We must require that both the client and server = supporting this option MUST also support the concat option. If this = isn't the case, then if the server implements concat but the client = doesn't, the client may easily improperly process the returned option = and this would cause significant problems since the client would not = know how to handle multiple occurrences of the option and might use any = one of the occurrences (rather than concatenating) or drop the packet = as being malformed (since the original DHCP specification said an = option may occur only once if I recall correctly).

If a new option is defined that has a fixed length = (such as carrying a single IP address), there is no need to require = that the client and server also implement concat to support that = option.

- Bernie

-----Original Message-----
From: Thomas Narten [mailto:narten@us.ibm.com]
Sent: Wednesday, October 24, 2001 7:43 PM
To: Bernard Aboba
Cc: dhcwg@ietf.org
Subject: [dhcwg] Re: Last Call: DHCP Domain Search = Option to Proposed
Standard


IETF Last Call has ended on this document, and I = recall that Keith
Moore had some comments. Not sure if any other = issues were raised.

Note that as the document is currently written, I = believe it has a
normative dependency on the = draft-ietf-dhc-concat-01.txt ID. There was
some discussion about whether that was necessary or = not, but I'm not
sure what the final resolution was. In any case, I = think wording
changes would be need to make the reference = non-normative. If the
intention is that the reference be normative, we = need the other ID to
move forward as well.

Are there any other issues that need to be = resolved?

Once the remaining issues are resolved and a new ID = is out, I can
bring the document before the IESG for = consideration.

Thomas

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

------_=_NextPart_001_01C15D13.14D01EB0-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Oct 25 10:10:54 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19934; Thu, 25 Oct 2001 10:10:53 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA06859; Thu, 25 Oct 2001 10:07:09 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA06840 for ; Thu, 25 Oct 2001 10:07:07 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19775 for ; Thu, 25 Oct 2001 10:07:02 -0400 (EDT) Received: from rdroms-w2k.cisco.com ([161.44.150.51]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id KAA11932; Thu, 25 Oct 2001 10:02:56 -0400 (EDT) Message-Id: <4.3.2.7.2.20011025094843.038b1238@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 25 Oct 2001 10:00:56 -0400 To: jason@compsoc.man.ac.uk From: Ralph Droms Subject: Re: [dhcwg] draft-ietf-dhc-dhcpv6-20 Cc: dhcwg@ietf.org In-Reply-To: <20011022153543.J29607@mrbusy.compsoc.man.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org The consensus was that including the change log in the doc was confusing to the ever-growing group of new readers. I do have a list of issues that the new draft addresses, which is based on the list of issues we developed at the DHC WG meeting in London... - Ralph At 03:35 PM 10/22/2001 +0100, Jason Williams wrote: >Good afternoon... > >Having breathlessly rushed to download and print off the lovely draft 20 >of your DHCPv6 specification, I can't help noticing it seems to be short a >change log - was there a reason for this? > >Thanks. > >-- > jason@khendon.org.uk _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Oct 25 13:44:09 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25216; Thu, 25 Oct 2001 13:44:08 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA14995; Thu, 25 Oct 2001 13:39:46 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA14969 for ; Thu, 25 Oct 2001 13:39:45 -0400 (EDT) Received: from web14002.mail.yahoo.com (web14002.mail.yahoo.com [216.136.175.93]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA25092 for ; Thu, 25 Oct 2001 13:39:39 -0400 (EDT) Message-ID: <20011025173943.89372.qmail@web14002.mail.yahoo.com> Received: from [209.211.221.2] by web14002.mail.yahoo.com via HTTP; Thu, 25 Oct 2001 10:39:43 PDT Date: Thu, 25 Oct 2001 10:39:43 -0700 (PDT) From: Nitin John To: dhcwg@ietf.org Cc: rwoundy@cisco.com, kkinnear@cisco.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [dhcwg] dhcp lease query Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Hi My name is Nitin and I work for a telcom company in MA. I am interested in implementing the dhcp lease query draft on our DHCP server implementation. We noticed there are several to be discussed(TBD) items in the draft. Specifically they are 1. The values of the following message types Value Message Type --------------------- TBD DHCPLEASEQUERY TBD DHCPKNOWN TBD DHCPUNKNOWN 2. The new reservation bit defined in the flag field of the DHCP packet and 3. The option code for the new DHCP option client-last-transaction-time added. Since the draft expires Jan 2002, I was wondering if the DHCWG was leaning towards any particular value. I would also appreciate it if anyone is aware of what current implementations are using as codes and values for the above mentioned items. Thanks Nitin Reference: http://www.ietf.org/internet-drafts/draft-ietf-dhc-leasequery-02.txt - dated July 2001 __________________________________________________ Do You Yahoo!? Make a great connection at Yahoo! Personals. http://personals.yahoo.com _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Oct 25 13:54:03 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25613; Thu, 25 Oct 2001 13:53:59 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA15220; Thu, 25 Oct 2001 13:53:05 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA15189 for ; Thu, 25 Oct 2001 13:53:03 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25553 for ; Thu, 25 Oct 2001 13:52:58 -0400 (EDT) Received: from KKINNEAR-W2K.cisco.com (dhcp-161-44-149-107.cisco.com [161.44.149.107]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id NAA16501; Thu, 25 Oct 2001 13:52:24 -0400 (EDT) Message-Id: <4.3.2.7.2.20011025134853.021faaa0@funnel.cisco.com> X-Sender: kkinnear@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 25 Oct 2001 13:55:41 -0400 To: Nitin John , dhcwg@ietf.org From: Kim Kinnear Cc: rwoundy@cisco.com, kkinnear@cisco.com In-Reply-To: <20011025173943.89372.qmail@web14002.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [dhcwg] Re: dhcp lease query Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Nitin, Until the draft gets through enough of the approval process to become an RFC and get a number, the TBD values are officially just that -- TBD. To the best of my knowledge there are *no* extant implementations of the current draft, and therefore no defacto numbers for the TBD values. At Cisco we have an implementation that is similar to an earlier version of the draft, but it would not interoperate with an implementation the current version. After the TBD values get determined (just before it becomes an RFC), we will update our implementation to match both the protocol and numbers of the RFC. Cheers -- Kim At 10:39 AM 10/25/2001 -0700, Nitin John wrote: >Hi > >My name is Nitin and I work for a telcom company in >MA. I am interested in implementing the dhcp lease >query draft on our DHCP server implementation. > >We noticed there are several to be discussed(TBD) >items in the draft. Specifically they are > >1. The values of the following message types > > Value Message Type >--------------------- > TBD DHCPLEASEQUERY > TBD DHCPKNOWN > TBD DHCPUNKNOWN > >2. The new reservation bit defined in the flag field >of the DHCP packet and > >3. The option code for the new DHCP option >client-last-transaction-time added. > >Since the draft expires Jan 2002, I was wondering if >the DHCWG was leaning towards any particular value. I >would also appreciate it if anyone is aware of what >current implementations are using as codes and values >for the above mentioned items. > >Thanks > >Nitin > >Reference: > >http://www.ietf.org/internet-drafts/draft-ietf-dhc-leasequery-02.txt >- dated July 2001 > >__________________________________________________ >Do You Yahoo!? >Make a great connection at Yahoo! Personals. >http://personals.yahoo.com _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sun Oct 28 13:06:18 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15007; Sun, 28 Oct 2001 13:06:13 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA23004; Sun, 28 Oct 2001 13:04:53 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA22984 for ; Sun, 28 Oct 2001 13:04:36 -0500 (EST) Received: from 3miasto.net (root@3miasto.net [217.96.12.60]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15003 for ; Sun, 28 Oct 2001 13:04:32 -0500 (EST) Received: from 192.168.254.42 (pc64.gdynia.sdi.tpnet.pl [213.77.131.64]) by 3miasto.net (8.11.6/8.11.0) with ESMTP id f9SI4TB28634 for ; Sun, 28 Oct 2001 19:04:29 +0100 Date: Sun, 28 Oct 2001 19:05:10 +0100 From: Artur Guja X-Mailer: The Bat! (v1.49) UNREG / CD5BF9353B3B7091 Reply-To: Artur Guja X-Priority: 3 (Normal) Message-ID: <4229586092.20011028190510@3miasto.net> To: DHCWG List Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [dhcwg] Lease database storage in DHCPv6 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 7bit Hello, Here is a fragment of my diploma documentation. Thell me what you think about such a scenario. "After each change in the lease cache in memory (allocation, update, release), the lease information has to be saved on non-volatile storage to ensure its maximum accuracy in case of a server crash. To minimize storage use (especially for flash-based storage and similar), the whole database is updated only once every several changes (the specific number is a configuration parameter, 0 meaning update every time). The intermittent information is kept in a separate file/storage, treated as a transaction cache. On update, the whole lease database is first saved to a separate file, and then the main database file is unlinked and replaced by the new file. This minimizes risk of a reboot occurring while the main file is not up-to-date. In case there is a serious limitation set on the use of a non-volatile storage, the saving of the lease database can be omitted. In such a case, no network information is available after a server crash. The server starts a general reconfiguration of the network right after resuming operation, in order to establish a known network state. Each client is sent a reconfiguration request. This causes much network traffic, but ensures proper operation and a fully known address pool state." -- Best regards, Artur mailto:skybird@3miasto.net _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Oct 29 01:48:15 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26988; Mon, 29 Oct 2001 01:48:14 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA11954; Mon, 29 Oct 2001 01:47:26 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA11928 for ; Mon, 29 Oct 2001 01:47:24 -0500 (EST) Received: from dell (adsl-66-124-64-34.dsl.sntc01.pacbell.net [66.124.64.34]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA26826 for ; Mon, 29 Oct 2001 01:47:21 -0500 (EST) x-esmtp: 0 0 1 Message-ID: <243941-220011012961628874@proj.com> X-EM-Version: 6, 0, 1, 0 X-EM-Registration: #00F06206106618006920 X-Priority: 3 From: "Rene Rodrigez" To: "dhcwg@ietf.org" Date: Sun, 28 Oct 2001 22:16:28 -0800 MIME-Version: 1.0 Content-type: text/plain; charset="US-ASCII" X-SMTPExp-Version: 1, 0, 2, 13 X-SMTPExp-Registration: 00B0320C107602006905 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id BAA11929 Subject: [dhcwg] Instructors: Announcing New Server Side Train the Trainer workshop Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 8bit I found your name on the website as someone who teaches existing server-side Java courses. My company has developed a new, practical server-side Java course, and we would like you to consider offering it to your students in the future. You can view the syllabus of this new class that we developed at www.basebeans.com . The web site has the complete details of the Train the Trainer workshop. As technology advances from servlets to JSPs, the next step is towards JSP frameworks. As an instructor, I'm sure you are aware of the constant need to stay ahead of the curve. If you would contact me at (415) 781-1463, I can tell you more. Thanks, Rene dhcwg@ietf.org _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Oct 29 05:30:26 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08145; Mon, 29 Oct 2001 05:30:26 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA16259; Mon, 29 Oct 2001 05:29:26 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA00876 for ; Thu, 25 Oct 2001 07:15:03 -0400 (EDT) Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13507 for ; Thu, 25 Oct 2001 07:14:58 -0400 (EDT) Received: from palrel1.hp.com (palrel1.hp.com [156.153.255.242]) by mail.bucknell.edu (8.11.6/8.11.6) with ESMTP id f9PBEvL31365 for ; Thu, 25 Oct 2001 07:15:01 -0400 (EDT) Received: from postbox.india.hp.com (postbox.india.hp.com [15.10.45.1]) by palrel1.hp.com (Postfix) with ESMTP id DF98269A; Thu, 25 Oct 2001 04:14:52 -0700 (PDT) Received: from india.hp.com (bansal@tohfa.india.hp.com [15.10.44.199]) by postbox.india.hp.com (8.9.3 (PHNE_18546)/8.9.3 SMKit7.02) with ESMTP id QAA15498; Thu, 25 Oct 2001 16:52:49 +0530 (IST) Message-ID: <3BD7F3E1.12DC5EDB@india.hp.com> Date: Thu, 25 Oct 2001 16:43:38 +0530 From: AJAY BANSAL Organization: HP-ISO X-Mailer: Mozilla 4.75 [en] (X11; U; HP-UX B.10.20 9000/712) X-Accept-Language: en MIME-Version: 1.0 To: Andy Wolstenholme , "dhcp-v4@bucknell.edu" Subject: Re: [dhcwg] DHCP info References: Content-Type: multipart/alternative; boundary="------------3C99076F40011C924084C6DF" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org --------------3C99076F40011C924084C6DF Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Andy, I think for knowing the very basics of DHCP/BOOTP you should refer the Vol 1 of TCP/IP by Coomer. Administration should depend on the server you are using. (though i have never done it myself) So you should refer manual pages/help with that particular implementation of DHCP. You can download isc's DHCP implementation (server + client) freely available on their site. regards, Ajay Bansal. Andy Wolstenholme wrote: > Hi there,I am currently a student based in > london working in the third year of my studies > towards a communications and networks degree. I > am basically writing to ask if anyone can point > me in the right direction to answer some quiries > I have about DHCP. As my final year poject I > intend to build a network administration tool > that relies heavily on a DHCP server of (which I > currently know very little about) requesting > network inforamtion such as IP address lists, > and other information. Firstly can anyone point > me in the right direction to find a > comprehensive guide to the essentials of DHCP, > its administration and how it generally works > and stores its information. Secondly, I will > need to build a DHCP server myself upon a linux > or windows based environment, initially to show > my competence to do so and also to develop my > software on a contained LAN. Can somebody > suggest any good comprehensive DHCP server > software for the best platform. Your help and > suggestions would be greatly appreciated. My > ThanksAndy... > > > ------------------------------------------------- > Get your FREE download of MSN Explorer at > http://explorer.msn.com > _______________________________________________ > dhcwg mailing list dhcwg@ietf.org > http://www1.ietf.org/mailman/listinfo/dhcwg --------------3C99076F40011C924084C6DF Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Andy,

 I think for knowing the very basics of DHCP/BOOTP
you should refer the Vol 1 of TCP/IP by Coomer.
Administration should depend on the server you are using.
(though i have never done it myself)
So you should refer manual pages/help with that particular
implementation of DHCP.

You can download isc's DHCP implementation (server + client)
freely available on their site.

regards,
Ajay Bansal.
 
 
 
 

Andy Wolstenholme wrote:

Hi there,I am currently a student based in london working in the third year of my studies towards a communications and networks degree.  I am basically writing to ask if anyone can point me in the right direction to answer some quiries I have about DHCP.  As my final year poject I intend to build a network administration tool that relies heavily on a DHCP server of (which I currently know very little about) requesting network inforamtion such as IP address lists, and other information.  Firstly can anyone point me in the right direction to find a comprehensive guide to the essentials of DHCP, its administration and how it generally works and stores its information.  Secondly, I will need to build a DHCP server myself upon a linux or windows based environment, initially to show my competence to do so and also to develop my software on a contained LAN.  Can somebody suggest any good comprehensive DHCP server software for the best platform. Your help and suggestions would be greatly appreciated. My ThanksAndy...


Get your FREE download of MSN Explorer at http://explorer.msn.com
_______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg
--------------3C99076F40011C924084C6DF-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Oct 29 08:50:49 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12512; Mon, 29 Oct 2001 08:50:49 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA19977; Mon, 29 Oct 2001 08:49:51 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA19954 for ; Mon, 29 Oct 2001 08:49:49 -0500 (EST) Received: from web13901.mail.yahoo.com (web13901.mail.yahoo.com [216.136.175.27]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA12405 for ; Mon, 29 Oct 2001 08:49:44 -0500 (EST) Message-ID: <20011029134948.73437.qmail@web13901.mail.yahoo.com> Received: from [212.117.147.115] by web13901.mail.yahoo.com via HTTP; Mon, 29 Oct 2001 05:49:48 PST Date: Mon, 29 Oct 2001 05:49:48 -0800 (PST) From: Eli Mana Reply-To: emana@zahav.net.il To: dhcwg@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [dhcwg] ACK in response to INFORM Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org In case server response to DHCPINFORM by DHCPACK, Is the option 51 (Ip address lease time) must not appear in the packet or it's value should be zero? Thanks __________________________________________________ Do You Yahoo!? Make a great connection at Yahoo! Personals. http://personals.yahoo.com _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Oct 29 10:50:01 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17515; Mon, 29 Oct 2001 10:50:00 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA23151; Mon, 29 Oct 2001 10:49:34 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA23129 for ; Mon, 29 Oct 2001 10:49:33 -0500 (EST) Received: from hotmail.com (f147.law8.hotmail.com [216.33.241.147]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17503 for ; Mon, 29 Oct 2001 10:49:29 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 29 Oct 2001 07:49:02 -0800 Received: from 212.2.6.140 by lw8fd.law8.hotmail.msn.com with HTTP; Mon, 29 Oct 2001 15:49:02 GMT X-Originating-IP: [212.2.6.140] From: "Geoff Lawrence" To: dhcwg@ietf.org Date: Mon, 29 Oct 2001 15:49:02 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 29 Oct 2001 15:49:02.0773 (UTC) FILETIME=[3B7E1E50:01C16091] Subject: [dhcwg] Client Quirks Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Hi, I have built my own DHCP server that runs on Win32. NT 4 and Windows 2000 can get IP addresses just fine, Windows 95 refuses. Is anyone familiar with the quirks of Win95? Thanks Geoff _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Oct 29 11:54:28 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19589; Mon, 29 Oct 2001 11:54:28 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA25184; Mon, 29 Oct 2001 11:51:43 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA25159 for ; Mon, 29 Oct 2001 11:51:41 -0500 (EST) Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19484 for ; Mon, 29 Oct 2001 11:51:36 -0500 (EST) Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate.mot.com (motgate 2.1) with ESMTP id JAA23484 for ; Mon, 29 Oct 2001 09:51:41 -0700 (MST)] Received: [from il02exb01.comm.mot.com (il02exb01.comm.mot.com [145.1.204.17]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id JAA10570 for ; Mon, 29 Oct 2001 09:51:41 -0700 (MST)] Received: by il02exb01.comm.mot.com with Internet Mail Service (5.5.2654.52) id <413FX3ZN>; Mon, 29 Oct 2001 10:51:40 -0600 Message-ID: <01FAF65DEA16D4119B95009027E78F3104E89EC3@il02exm26.comm.mot.com> From: Narayanan Vidya-CVN065 To: "'dhcp'" Date: Mon, 29 Oct 2001 10:51:39 -0600 X-MS-TNEF-Correlator: <01FAF65DEA16D4119B95009027E78F3104E89EC3@il02exm26.comm.mot.com> MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C16099.FA7726A0" Subject: [dhcwg] PPP and DHCP Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C16099.FA7726A0 Content-Type: text/plain; charset="iso-8859-1" Hi, I was wondering if there was any information on running DHCP over PPP links. Is there a way to use DHCP to configure the IP address of a device on its PPP interface instead of using IPCP? I am new to this mailing list. So, please pardon me if this question has been raised before. In that case, I'd appreciate any pointers to the discussion. Thanks, Vidya ------_=_NextPart_000_01C16099.FA7726A0 Content-Type: application/ms-tnef Content-Transfer-Encoding: base64 eJ8+IioQAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQWAAwAOAAAA0QcKAB0ACgAzACcAAQBkAQEggAMADgAAANEHCgAd AAoAMwAnAAEAZAEBCYABACEAAAA1QzE1NDcyNTg0Q0NENTExOUJFRDAwOTAyN0U3OEYzMQARBwEE gAEADQAAAFBQUCBhbmQgREhDUACCAwENgAQAAgAAAAIAAgABA5AGAEAHAAAyAAAAAgFxAAEAAAAW AAAAAcFgmfo2t1zB7cyCEdW+vQAQpMVj/gAAAwDeP69vAAADAAiACCAGAAAAAADAAAAAAAAARgAA AABShQAA8BMAAB4ACYAIIAYAAAAAAMAAAAAAAABGAAAAAFSFAAABAAAABAAAADguNQALAAqACCAG AAAAAADAAAAAAAAARgAAAAAGhQAAAAAAAAMAC4AIIAYAAAAAAMAAAAAAAABGAAAAAAGFAAAAAAAA CwAAgAggBgAAAAAAwAAAAAAAAEYAAAAAA4UAAAAAAAALABSACCAGAAAAAADAAAAAAAAARgAAAAAO hQAAAAAAAAMAAoAIIAYAAAAAAMAAAAAAAABGAAAAABCFAAAAAAAAAwAVgAggBgAAAAAAwAAAAAAA AEYAAAAAEYUAAAAAAAADABeACCAGAAAAAADAAAAAAAAARgAAAAAYhQAAAAAAAB4AJoAIIAYAAAAA AMAAAAAAAABGAAAAADaFAAABAAAAAQAAAAAAAAAeACeACCAGAAAAAADAAAAAAAAARgAAAAA3hQAA AQAAAAEAAAAAAAAAHgAogAggBgAAAAAAwAAAAAAAAEYAAAAAOIUAAAEAAAABAAAAAAAAAAsARIAL IAYAAAAAAMAAAAAAAABGAAAAAACIAAAAAAAACwBFgAsgBgAAAAAAwAAAAAAAAEYAAAAABYgAAAAA AAACAQkQAQAAAK4BAACqAQAAAAIAAExaRnX/Vh6JAwAKAHJjcGcxMjUWMgD4C2BuDhAwMzNPAfcC pAPjAgBjaArAc7BldDAgBxMCgH0KgZJ2CJB3awuAZDQMYA5jAFALAwu1IEhpLEMKogqASSB3YQQg dycCIASBC4BnIAaQIHRaaASQZRRzAHB5FVBupQIQcgDAdGkCICAXARhydW4DABUxREhDSlAXIHYE kCBQGIAggmwLgGtzLiBJBCANFZRhFHEWUHRvIHWfESAX1BohBaAWgGlnCHCPFdAVkRkgGBBhZGQJ cL0EEW8VcBnAAQASIGMV0LkXAWl0BCAYgguAdASQ7mYA0BXQC4BzHjAcIByS7xpQFSIb8BgAPwrj CoQUQvBhbSBuB9EaIRWQBAB+IADAAxAVIhjAHtAZEFP4bywgC1Ae8BphCwIXAfcHgBVUIcFxClAe 0BbyEPD9BCBiCeEXUAtwESAfECVw/RaRZRkRA6AVkBbQGwAjQYki8EknHxBhcHAJcM5jBzAeMBYj cG8eExlB6yGCFdBkBABjGlAAkAIgOi4gKlQQ8BjhE/VWaVhkeWEUBBHhACzwAAAeAHAAAQAAAA0A AABQUFAgYW5kIERIQ1AAAAAACwACAAEAAAADAP0/5AQAAEAAOQCgJnf6mWDBAQMA8T8JBAAAHgAx QAEAAAAHAAAAQ1ZOMDY1AAADABpAAAAAAB4AMEABAAAABwAAAENWTjA2NQAAAwAZQAAAAAADACYA AAAAAAMANgAAAAAACwDyEAEAAAADAIAQ/////wIBRwABAAAAMAAAAGM9VVM7YT0gO3A9bW90O2w9 SUwwMkVYTTI2LTAxMTAyOTE2NTEzOVotMTA3NjM4AAIB+T8BAAAARwAAAAAAAADcp0DIwEIQGrS5 CAArL+GCAQAAAAAAAAAvTz1NT1QvT1U9TE1QU0lMMDIvQ049UkVDSVBJRU5UUy9DTj1DVk4wNjUA AB4A+D8BAAAAFwAAAE5hcmF5YW5hbiBWaWR5YS1DVk4wNjUAAB4AOEABAAAABwAAAENWTjA2NQAA AgH7PwEAAABHAAAAAAAAANynQMjAQhAatLkIACsv4YIBAAAAAAAAAC9PPU1PVC9PVT1MTVBTSUww Mi9DTj1SRUNJUElFTlRTL0NOPUNWTjA2NQAAHgD6PwEAAAAXAAAATmFyYXlhbmFuIFZpZHlhLUNW TjA2NQAAHgA5QAEAAAAHAAAAQ1ZOMDY1AABAAAcwD8p0+plgwQFAAAgwJlh5+plgwQEeAD0AAQAA AAEAAAAAAAAAHgAdDgEAAAANAAAAUFBQIGFuZCBESENQAAAAAB4ANRABAAAAQgAAADwwMUZBRjY1 REVBMTZENDExOUI5NTAwOTAyN0U3OEYzMTA0RTg5RUMzQGlsMDJleG0yNi5jb21tLm1vdC5jb20+ AAAACwApAAAAAAALACMAAAAAAAMABhCQrdLrAwAHEB8BAAADABAQAAAAAAMAERAAAAAAHgAIEAEA AABlAAAASEksSVdBU1dPTkRFUklOR0lGVEhFUkVXQVNBTllJTkZPUk1BVElPTk9OUlVOTklOR0RI Q1BPVkVSUFBQTElOS1NJU1RIRVJFQVdBWVRPVVNFREhDUFRPQ09ORklHVVJFVEhFSQAAAAACAX8A AQAAAEIAAAA8MDFGQUY2NURFQTE2RDQxMTlCOTUwMDkwMjdFNzhGMzEwNEU4OUVDM0BpbDAyZXht MjYuY29tbS5tb3QuY29tPgAAAIhk ------_=_NextPart_000_01C16099.FA7726A0-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Oct 29 12:47:10 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21487; Mon, 29 Oct 2001 12:47:05 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA26922; Mon, 29 Oct 2001 12:43:10 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA26899 for ; Mon, 29 Oct 2001 12:43:08 -0500 (EST) Received: from 3miasto.net (root@3miasto.net [217.96.12.60]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21336 for ; Mon, 29 Oct 2001 12:42:57 -0500 (EST) Received: from 192.168.254.42 (pc64.gdynia.sdi.tpnet.pl [213.77.131.64]) by 3miasto.net (8.11.6/8.11.0) with ESMTP id f9THgOB25901; Mon, 29 Oct 2001 18:42:24 +0100 Date: Mon, 29 Oct 2001 18:43:13 +0100 From: Artur Guja X-Mailer: The Bat! (v1.49) UNREG / CD5BF9353B3B7091 Reply-To: Artur Guja X-Priority: 3 (Normal) Message-ID: <1139225695.20011029184313@3miasto.net> To: steve CC: DHCWG List Subject: Re[2]: [dhcwg] Lease database storage in DHCPv6 In-reply-To: <000201c16094$5e8bc890$3500000a@relicore.com> References: <000201c16094$5e8bc890$3500000a@relicore.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 7bit Hello steve, Monday, October 29, 2001, 5:11:28 PM, you wrote: s> In dhcp v4, there is no standard way for a server to reconfigure s> a client. The protocol is designed so that it is always the client s> who has to obtain or renew the lease. s> Mind you , there has been some proposals to do this, but s> AFAIK no RFC. Sorry, I wasn't specific enough (just assumes people would associate this mail with my previous portings) :))) My work, in fact my university diploma, is about DHCPv6, which has reconfiguration defined in the drafts. As to other limitations, I'm a bit concerned about the peak network load right after the server restart, due to all clients reconfiguring. Maybe there should be a random wait defined, just as for SOLICIT, to desynchronise the clients. This issue, however, pertains only to servers based on thin embedded systems, working with flash or similar stroage, where frequent writing is out of the question, either due to hardware or performance limitations. Artur Guja _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Oct 29 14:14:59 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24079; Mon, 29 Oct 2001 14:14:55 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA28907; Mon, 29 Oct 2001 14:04:33 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA28880 for ; Mon, 29 Oct 2001 14:04:32 -0500 (EST) Received: from 3miasto.net (root@3miasto.net [217.96.12.60]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23772 for ; Mon, 29 Oct 2001 14:04:15 -0500 (EST) Received: from 192.168.254.42 (pc64.gdynia.sdi.tpnet.pl [213.77.131.64]) by 3miasto.net (8.11.6/8.11.0) with ESMTP id f9TJ3qB30116; Mon, 29 Oct 2001 20:03:52 +0100 Date: Mon, 29 Oct 2001 20:04:39 +0100 From: Artur Guja X-Mailer: The Bat! (v1.49) UNREG / CD5BF9353B3B7091 Reply-To: Artur Guja X-Priority: 3 (Normal) Message-ID: <13814110880.20011029200439@3miasto.net> To: steve CC: DHCWG List In-reply-To: <000801c160a3$91d55ea0$3500000a@relicore.com> References: <000801c160a3$91d55ea0$3500000a@relicore.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [dhcwg] Re: Lease database storage in DHCPv6 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 7bit Hello steve, s> BTW there is a v6 implementation already, based on the ISc codebase. s> Given that you are going to put a lot of effort into dhcp V6, s> which the world clearly needs, you may as well get behind s> the isc server. I am also interested in furthering the cause. The ISC code is a good reference point, but what I'm working on here is generally a different environment. Basically I'm trying to implement a simple, yet fully functional DHCPv6 (both client & server) for my univ diploma. The ISC is a bit to big/monstrual/overelaborated and, basically, I'm required to build my code from scratch :))) As for technical stuff: I'm trying not to assume too much about the network. The number of clients I'm basing my model on is serveral thousand. As for the network type, I'm basing on Ethernet in general and estimating for 10/100. All implementations of DHCPv6 I've come across were based on drafts -15 or similar, and were closer to v4 than to the current state of v6. The deadline of my diploma is May'02, so I will base my code on draft -20, there being not much chance to have it based on an actual RFC :))) As for ISC code: 1) As I'm targeting thin clients and embeds, multithreading is out, all single threaded. 2) IMHO, dhcp is not a very performance-dependent protocol. Just have to make sure the replies reach clients within reasonable timeouts (much less than max timeouts). 3) The main problem is getting the whole thing to function in the first place :))) (God, please, give me an RFC :))) Much work still has to be done to get it all straight :)) Artur Guja _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Oct 30 03:41:13 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22729; Tue, 30 Oct 2001 03:41:13 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA21805; Tue, 30 Oct 2001 03:27:06 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA21774 for ; Tue, 30 Oct 2001 03:27:05 -0500 (EST) Received: from 3miasto.net (root@3miasto.net [217.96.12.60]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22622 for ; Tue, 30 Oct 2001 03:27:01 -0500 (EST) Received: from 192.168.254.42 (pc64.gdynia.sdi.tpnet.pl [213.77.131.64]) by 3miasto.net (8.11.6/8.11.0) with ESMTP id f9U8QnB20698 for ; Tue, 30 Oct 2001 09:26:54 +0100 Date: Tue, 30 Oct 2001 09:27:44 +0100 From: Artur Guja X-Mailer: The Bat! (v1.49) UNREG / CD5BF9353B3B7091 Reply-To: Artur Guja X-Priority: 3 (Normal) Message-ID: <972269773.20011030092744@3miasto.net> To: DHCWG List Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [dhcwg] Re[2]: Lease database storage in DHCPv6 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 7bit Hello steve, Monday, October 29, 2001, 9:08:42 PM, you wrote: s> Ah. Wireless environment... I rather hope not :))) s> The client has to be compact, but the env does not necessarily constrain the s> server. s> (unless it is running on a linksys hub...is this the sort of server you are s> after?) Well, what I'm after is a more-or-less general solution (home PC-based), but I do have to take some embedded issues into consideration (my diploma requires that). s> Then just do an in-memory hash based database, with an optional transaction s> journal file backup. The "optional" is a bit of a problem. The dhcpv6 draft says that the server MUST save the leases to non-volatile storage. Well, what if one is NOT AVAILABLE :))) That's what I've been pointing at :))) s> the throughput may be as high as a couple of thousand transactions s> per sec. ( I am talking carrier class servers, not embedded). I have a dhvpv4 server in my home net. It is incorporated into a modem-net transciever (right, I got my modem connected straight to the network). I looked inside, and it is just one chip doing the dhcp-ing. My point: You can build a dhcp server on a carrier-class server, or even a cluster, if you like :)) But my goal here is to make it work on a reasonable computer with the option of porting it easily to an embedded environment or even a single ship. s> btw where are you based? Gdansk University of Technology, Poland (or, if you prefer, in Polish) Politechnika Gdanska, Polska -- Best regards, Artur mailto:skybird@3miasto.net _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Oct 30 07:31:16 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25622; Tue, 30 Oct 2001 07:31:12 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA27379; Tue, 30 Oct 2001 07:25:04 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA27353 for ; Tue, 30 Oct 2001 07:25:02 -0500 (EST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25396 for ; Tue, 30 Oct 2001 07:24:58 -0500 (EST) Received: from rdroms-w2k.cisco.com (rtp-vpn1-197.cisco.com [10.82.224.197]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id HAA02147; Tue, 30 Oct 2001 07:24:02 -0500 (EST) Message-Id: <4.3.2.7.2.20011030065458.031e3e80@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 30 Oct 2001 07:22:06 -0500 To: Artur Guja From: Ralph Droms Subject: Re: [dhcwg] Lease database storage in DHCPv6 Cc: DHCWG List In-Reply-To: <4229586092.20011028190510@3miasto.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org The scenario you describe in the first paragraph is, I believe, a reasonably well-known optimization. One detail to note is that the server should, on reboot, consult the transaction cache and complete those outstanding transactions before processing any new requests. In the scenario you describe in the second paragraph, if a server has no non-volatile storage in which to record its clients, how does the server know what clients to contact? In a followup message, you noted: >As to other limitations, I'm a bit concerned about the peak network >load right after the server restart, due to all clients reconfiguring. >Maybe there should be a random wait defined, just as for SOLICIT, to >desynchronise the clients. In DHCPv6, any delay between reconfigure messages is the responsibility of the server and is not explicitly described in the protocol specification. The delay is left unspecified because servers are under explicitly administrative control and may have widely varying requirements for load-leveling depending on the particular network in which those servers are deployed. - Ralph At 07:05 PM 10/28/2001 +0100, Artur Guja wrote: >Here is a fragment of my diploma documentation. >Thell me what you think about such a scenario. > >"After each change in the lease cache in memory >(allocation, update, release), the lease information >has to be saved on non-volatile storage to ensure >its maximum accuracy in case of a server crash. >To minimize storage use (especially for flash-based >storage and similar), the whole database is updated >only once every several changes (the specific number >is a configuration parameter, 0 meaning update every >time). The intermittent information is kept in a >separate file/storage, treated as a transaction cache. >On update, the whole lease database is first saved to >a separate file, and then the main database file is >unlinked and replaced by the new file. This minimizes >risk of a reboot occurring while the main file is not >up-to-date. >In case there is a serious limitation set on the use >of a non-volatile storage, the saving of the lease >database can be omitted. In such a case, no network >information is available after a server crash. The >server starts a general reconfiguration of the network >right after resuming operation, in order to establish >a known network state. Each client is sent a >reconfiguration request. This causes much network >traffic, but ensures proper operation and a fully >known address pool state." > >-- >Best regards, > Artur mailto:skybird@3miasto.net > > > >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >http://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Oct 30 07:31:18 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25641; Tue, 30 Oct 2001 07:31:17 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA27320; Tue, 30 Oct 2001 07:24:32 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA27293 for ; Tue, 30 Oct 2001 07:24:30 -0500 (EST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25365 for ; Tue, 30 Oct 2001 07:24:27 -0500 (EST) Received: from rdroms-w2k.cisco.com (rtp-vpn1-197.cisco.com [10.82.224.197]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id HAA02118; Tue, 30 Oct 2001 07:23:57 -0500 (EST) Message-Id: <4.3.2.7.2.20011030060452.031e3e80@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 30 Oct 2001 06:05:55 -0500 To: steve , DHCWG List From: Ralph Droms Subject: Re[2]: [dhcwg] Lease database storage in DHCPv6 In-Reply-To: <1139225695.20011029184313@3miasto.net> References: <000201c16094$5e8bc890$3500000a@relicore.com> <000201c16094$5e8bc890$3500000a@relicore.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org BTW, draft-ietf-dhc-pv4-reconfigure-06.txt has been accepted as a draft standard, and will be published as an RFC soon. - Ralph At 06:43 PM 10/29/2001 +0100, Artur Guja wrote: >Hello steve, > >Monday, October 29, 2001, 5:11:28 PM, you wrote: > >s> In dhcp v4, there is no standard way for a server to reconfigure >s> a client. The protocol is designed so that it is always the client >s> who has to obtain or renew the lease. >s> Mind you , there has been some proposals to do this, but >s> AFAIK no RFC. _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Oct 30 14:04:09 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11515; Tue, 30 Oct 2001 14:04:09 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA15109; Tue, 30 Oct 2001 14:01:10 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA15082 for ; Tue, 30 Oct 2001 14:01:08 -0500 (EST) Received: from hygro.adsl.duke.edu ([66.115.46.201]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11427 for ; Tue, 30 Oct 2001 14:01:04 -0500 (EST) Received: from hygro.adsl.duke.edu (narten@localhost) by hygro.adsl.duke.edu (8.11.6/8.11.6) with ESMTP id f9UJ0JM04653; Tue, 30 Oct 2001 14:00:20 -0500 Message-Id: <200110301900.f9UJ0JM04653@hygro.adsl.duke.edu> To: Ralph Droms cc: steve , DHCWG List Subject: Re: Re[2]: [dhcwg] Lease database storage in DHCPv6 In-Reply-To: Message from Ralph Droms of "Tue, 30 Oct 2001 06:05:55 EST." <4.3.2.7.2.20011030060452.031e3e80@funnel.cisco.com> Date: Tue, 30 Oct 2001 13:59:50 -0500 From: Thomas Narten Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org > BTW, draft-ietf-dhc-pv4-reconfigure-06.txt has been accepted as > a draft standard, and will be published as an RFC soon. Just to be clear, I don't think you didn't mean "Draft Standard" in the formal IETF sense. The document has been approved by the IESG as a Proposed Standard. Thomas _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Oct 30 14:05:59 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11590; Tue, 30 Oct 2001 14:05:59 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA15287; Tue, 30 Oct 2001 14:04:02 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA15263 for ; Tue, 30 Oct 2001 14:04:01 -0500 (EST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11505 for ; Tue, 30 Oct 2001 14:03:57 -0500 (EST) Received: from rdroms-w2k.cisco.com ([161.44.150.51]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA02192; Tue, 30 Oct 2001 14:03:29 -0500 (EST) Message-Id: <4.3.2.7.2.20011030140400.00b86078@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 30 Oct 2001 14:04:39 -0500 To: DHCWG List From: Ralph Droms Subject: Re: Re[2]: [dhcwg] Lease database storage in DHCPv6 Cc: steve , Thomas Narten In-Reply-To: <200110301900.f9UJ0JM04653@hygro.adsl.duke.edu> References: <4.3.2.7.2.20011030060452.031e3e80@funnel.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Sorry - I mis-typed. It will be a Proposed Standard... - Ralph At 01:59 PM 10/30/2001 -0500, Thomas Narten wrote: > > BTW, draft-ietf-dhc-pv4-reconfigure-06.txt has been accepted as > > a draft standard, and will be published as an RFC soon. > >Just to be clear, I don't think you didn't mean "Draft Standard" in >the formal IETF sense. The document has been approved by the IESG as a >Proposed Standard. > >Thomas _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg