From owner-dhcp-v6@bucknell.edu Fri Jun 1 03:56:59 2001 Received: from mail.bucknell.edu ([134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA02380; Fri, 1 Jun 2001 03:56:59 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.3/8.11.3) with SMTP id f517uiJ25638; Fri, 1 Jun 2001 03:56:44 -0400 (EDT) Received: from ausmtp02.au.ibm.com (ausmtp02.au.ibm.COM [202.135.136.105]) by mail.bucknell.edu (8.11.3/8.11.3) with ESMTP id f517uZJ12093 for ; Fri, 1 Jun 2001 03:56:35 -0400 (EDT) Received: from f03n05e.au.ibm.com by ausmtp02.au.ibm.com (IBM AP 1.0) with ESMTP id RAA255638 for ; Fri, 1 Jun 2001 17:45:49 +1000 From: skodati@in.ibm.com Received: from d73mta01.au.ibm.com (f06n01s [9.185.166.65]) by f03n05e.au.ibm.com (8.8.8m3/NCO v4.96) with SMTP id RAA71770 for ; Fri, 1 Jun 2001 17:01:50 +1000 Received: by d73mta01.au.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id CA256A5E.002625DB ; Fri, 1 Jun 2001 16:56:40 +1000 X-Lotus-FromDomain: IBMIN@IBMAU To: DHCPv6 discussion list cc: bsuparna@in.ibm.com, rsharada@in.ibm.com Message-ID: Date: Fri, 1 Jun 2001 12:17:34 +0530 Subject: Re: Reconfigure-init message in DHCPv6 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN >2) if the client contacts the server again, nothing breaks, though > there is a performance penalty. The client just gets the same info > over again. There could be a case where a client may be busy in the cycle of messages of single server and not in a position to attend RECONFIG from other servers, since a client has to complete REQUEST/RENEW ( as pointed by Ralph) for each RECONFIG message, (or) is it possible for a client to send REQUEST to some server while waiting for REPLY from other server. (or) Server should not send RECONFIG messages to client who completed REQUEST/REPLY for the same reconfig ( this is more an implementation issue) >3) if this was a real concern, the client can retain state (even after > contacting the server) that keeps track of the last transaction ID, > in which case it would recognize the retransmission and ignore > it. This is the case if there is a mechanism ensured from server side that a client gets the same transacion id for each re-transmitted RECONFIG message, otherwise a client can discard duplicated messages only. Thanks and Regards Suresh From owner-dhcp-v4@bucknell.edu Wed Jun 6 11:47:36 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA03634 for ; Wed, 6 Jun 2001 11:47:35 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f56Ff0L10294; Wed, 6 Jun 2001 11:41:00 -0400 (EDT) Received: from quadntweb.quadritek.com ([198.200.138.211]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f56FevL12421 for ; Wed, 6 Jun 2001 11:40:57 -0400 (EDT) Received: from blasserw2k ([198.200.138.237]) by quadntweb.quadritek.com (Post.Office MTA v3.5.3 release 223 ID# 0-59484U200L100S0V35) with SMTP id com for ; Wed, 6 Jun 2001 11:37:04 -0400 From: "Robert J. Lasser" To: DHCPv4 discussion list Subject: Suffix search order RFC Date: Wed, 6 Jun 2001 11:41:27 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Reply-To: rlasser@lucent.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit Greetings one and all, Does anyone know if there's an RFC (or draft) regarding sending DNS resolver suffix search orders through a DHCP extension? I've looked around on ietf.org but couldn't find anything. Many thanks Bob Lasser From owner-dhcp-v4@bucknell.edu Wed Jun 6 12:28:10 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA04640 for ; Wed, 6 Jun 2001 12:27:58 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f56GIIL07892; Wed, 6 Jun 2001 12:18:18 -0400 (EDT) Received: from quadntweb.quadritek.com ([198.200.138.211]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f56GIAL13408 for ; Wed, 6 Jun 2001 12:18:10 -0400 (EDT) Received: from agrabilnt ([10.100.30.254]) by quadntweb.quadritek.com (Post.Office MTA v3.5.3 release 223 ID# 0-59484U200L100S0V35) with SMTP id com; Wed, 6 Jun 2001 12:14:10 -0400 From: "A. Gregory Rabil" To: DHCPv4 discussion list Subject: RE: Suffix search order RFC Date: Wed, 6 Jun 2001 12:18:01 -0400 Message-ID: <00e301c0eea4$42ffee10$fe1e640a@quadritek.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Reply-To: grabil@lucent.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit Bob, The draft draft-aboba-dhc-domsearch-01.txt was submitted for this, but has since expired. I don't believe there has been any renewed interest... Regards, Greg > -----Original Message----- > From: owner-dhcp-v4@bucknell.edu [mailto:owner-dhcp-v4@bucknell.edu]On > Behalf Of Robert J. Lasser > Sent: Wednesday, June 06, 2001 11:41 AM > To: DHCPv4 discussion list > Subject: Suffix search order RFC > > > Greetings one and all, > > Does anyone know if there's an RFC (or draft) regarding > sending DNS resolver > suffix search orders through a DHCP extension? I've looked around on > ietf.org but couldn't find anything. > > Many thanks > > Bob Lasser > > From owner-dhcp-v4@bucknell.edu Wed Jun 6 12:32:15 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA04733 for ; Wed, 6 Jun 2001 12:32:15 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f56GUxL15441; Wed, 6 Jun 2001 12:30:59 -0400 (EDT) Received: from imr2.ericy.com (imr2.ericy.com [12.34.240.68]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f56GUjL27830 for ; Wed, 6 Jun 2001 12:30:45 -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 f56GUS806035 for ; Wed, 6 Jun 2001 11:30:28 -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 f56GUSq03990 for ; Wed, 6 Jun 2001 11:30:28 -0500 (CDT) Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt749 ; Wed Jun 06 10:52:38 2001 -0500 Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 6 Jun 2001 10:52:39 -0500 Message-ID: <66F66129A77AD411B76200508B65AC694CBC1B@eambunt705.ena-east.ericsson.se> From: "Bernie Volz (EUD)" To: DHCPv4 discussion list Subject: RE: Suffix search order RFC Date: Wed, 6 Jun 2001 10:52:37 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0EEA0.B5836880" Reply-To: Bernie.Volz@am1.ericsson.se Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN 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_01C0EEA0.B5836880 Content-Type: text/plain; charset="iso-8859-1" See http://www.ietf.org/internet-drafts/draft-aboba-dhc-domsearch-01.txt -----Original Message----- From: Robert J. Lasser [mailto:rlasser@lucent.com] Sent: Wednesday, June 06, 2001 11:41 AM To: DHCPv4 discussion list Subject: Suffix search order RFC Greetings one and all, Does anyone know if there's an RFC (or draft) regarding sending DNS resolver suffix search orders through a DHCP extension? I've looked around on ietf.org but couldn't find anything. Many thanks Bob Lasser ------_=_NextPart_001_01C0EEA0.B5836880 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Suffix search order RFC

See http://www.ietf.org/internet-drafts/draft-aboba-dhc-do= msearch-01.txt


-----Original Message-----
From: Robert J. Lasser [mailto:rlasser@lucent.com]=
Sent: Wednesday, June 06, 2001 11:41 AM
To: DHCPv4 discussion list
Subject: Suffix search order RFC


Greetings one and all,

Does anyone know if there's an RFC (or draft) = regarding sending DNS resolver
suffix search orders through a DHCP extension?  = I've looked around on
ietf.org but couldn't find anything.

Many thanks

Bob Lasser

------_=_NextPart_001_01C0EEA0.B5836880-- From owner-dhcp-v4@bucknell.edu Wed Jun 6 15:01:51 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA07902 for ; Wed, 6 Jun 2001 15:01:50 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f56IvWL04246; Wed, 6 Jun 2001 14:57:32 -0400 (EDT) Received: from mail.ifatec.fr (mailer@[194.98.13.50]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f56IvOL01555 for ; Wed, 6 Jun 2001 14:57:24 -0400 (EDT) Received: by mail.ifatec.fr; id UAA28465; Wed, 6 Jun 2001 20:33:59 +0200 (CEST) Message-Id: <200106061833.UAA28465@mail.ifatec.fr> From: "MALOMSOKI Christian (EURIWARE S.A.)" To: DHCPv4 discussion list Subject: unsubscribe Date: Wed, 6 Jun 2001 20:55:32 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Reply-To: chmaloms@euriware.fr Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN From owner-dhcp-v4@bucknell.edu Thu Jun 7 07:11:50 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA03566 for ; Thu, 7 Jun 2001 07:11:49 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f57B8eL09901; Thu, 7 Jun 2001 07:08:40 -0400 (EDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f57B8cL23607 for ; Thu, 7 Jun 2001 07:08:38 -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 HAA03438; Thu, 7 Jun 2001 07:07:59 -0400 (EDT) Message-Id: <200106071107.HAA03438@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: DHCPv4 discussion list Cc: dhcp-v4@bucknell.edu From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dhc-dhcproam-00.txt Date: Thu, 07 Jun 2001 07:07:58 -0400 Sender: owner-dhcp-v4@bucknell.edu X-Sender: nsyracus@cnri.reston.va.us X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN --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 : Extensions to DHCP for Roaming Users Author(s) : B. Mukherjee, B. Gage, Y. Liu Filename : draft-ietf-dhc-dhcproam-00.txt Pages : 15 Date : 06-Jun-01 This draft defines enhancements to DHCP so that it can be used by access networks as an initial configuration protocol for nomadic users. The authentication mechanism described here interacts with existing public Authentication, Authorization, and Accounting (AAA) mechanisms, thus enabling per customer authentication and authorization across multiple domains. In addition, we describe a mechanism that enables the client to authenticate the network to prevent attacks on an end host from a bogus network access point. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcproam-00.txt 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-dhcproam-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dhc-dhcproam-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010606114516.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-dhcproam-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-dhcproam-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010606114516.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-dhcp-v6@bucknell.edu Thu Jun 7 18:10:51 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA15313; Thu, 7 Jun 2001 18:10:51 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f57M9nL28897; Thu, 7 Jun 2001 18:09:49 -0400 (EDT) Received: from imr2.ericy.com (imr2.ericy.com [12.34.240.68]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f57M9lL22154 for ; Thu, 7 Jun 2001 18:09:47 -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 f57M9O826111 for ; Thu, 7 Jun 2001 17:09:28 -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 f57M9O903602 for ; Thu, 7 Jun 2001 17:09:24 -0500 (CDT) Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt747.exu.ericsson.se ; Thu Jun 07 17:09:23 2001 -0500 Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 7 Jun 2001 17:09:23 -0500 Message-ID: <66F66129A77AD411B76200508B65AC697B316E@eambunt705.ena-east.ericsson.se> From: "Bernie Volz (EUD)" To: DHCPv6 discussion list Subject: RE: Spec text for Reconfigure-init Date: Thu, 7 Jun 2001 17:09:21 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0EF9E.80DC3400" Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN 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_01C0EF9E.80DC3400 Content-Type: text/plain; charset="iso-8859-1" Ralph: Sorry for the slow response ... some comments (I haven't seen other feedback yet?): 1) This text still does not state that the transaction-id of the Reconfigure-Init is meaningless. It should. 2) What if the number of IAs that might need to be included exceed the packet size? Do we want to provide a means for a client to send multiple Requests in this case. Hopefully, this is not a common occurrance. I would leave the obligation to handle this at the client and it is not a server issue. A server assumes a Reconfigure-Init is done when a Request is received from the client. A client's reconfiguration is not complete until it has done a Request (or multiple Requests) on all of the IAs for the interface. Impacts section 14.3.2. 3) As discussed later (see BV>), we need to clarify exactly what Reconfigure-Init means: a) Reconfigure *ALL* addresses on that particular interface regardless of the server OR b) Reconfigure only the addresses on that particular interface obtained from that server. There could be cases where there are multiple servers and clients even obtained addresses from multiple servers (because a server was temporarily down, for example). So, we need to be clear. >From the text below, it would imply that all IAs on the interface are sent (at least by my interpretation) - even those that might not have been obtained from the server that sent the Reconfigure-Init. I assume this is the desired behavoir but we need to be more explicit about it. Additional comments below. - Bernie Volz -----Original Message----- From: Ralph Droms [mailto:rdroms@cisco.com] Sent: Thursday, May 31, 2001 5:08 PM To: DHCPv6 discussion list Subject: Spec text for Reconfigure-init Here's some proposed text describing the use of the Reconfigure-init message. I've extracted this text from the draft spec, so watch the section numbers to be warned of elided text. - Ralph 7. DHCP Constants This section describes various program and networking constants used by DHCP. 7.5. Configuration Variables This section presents a table of client and server configuration variables and the default or initial values for these variables. The client-specific variables MAY be configured on the server and MAY be delivered to the client through the "DHCP Retransmission Parameter Option" in a Reply message. _________________________________________________________________________ |Parameter__________|Default|_Description______________________________|_ |MIN_SOL_DELAY______|1______|_MIN_(secs)_to_delay_1st_mesg_____________|_ |MAX_SOL_DELAY______|5______|_MAX_(secs)_to_delay_1st_mesg_____________|_ |ADV_MSG_TIMEOUT____|500____|_SOL_Retrans_timer_(msecs)________________|_ |ADV_MSG_MAX________|30_____|_MAX_timer_value_(secs)___________________|_ |SOL_MAX_ATTEMPTS___|-1_____|_MAX_attempts_(-1_=_infinite)_____________|_ |REP_MSG_TIMEOUT____|250____|_Retrans_timer_(msecs)_for_Reply__________|_ |QRY_MSG_ATTEMPTS___|10_____|_MAX_Request/Confirm/Renew/Rebind_attempts|_ |REL_MSG_ATTEMPTS___|5______|_MAX_Release/Decline_attempts_____________|_ |RECREP_MSG_TIMEOUT_|2000___|_Retrans_timer_(msecs)____________________|_ |REC_MSG_ATTEMPTS___|10_____|_Reconfigure_attempts_____________________|_ |REC_THRESHOLD______|100____|_%_of_required_clients____________________|_ |SRVR_PREF_WAIT_____|2______|_Advertise_Collect_timer_(secs)___________|_ 9. Message Formats Each DHCP message has an identical fixed format header; some messages also allow a variable format area for options. Not all fields in the header are used in every message. In this section, every field is described for every message and fields that are not used in a message are marked as "unused". All unused fields in a message MUST be transmitted as zeroes and ignored by the receiver of the message. The DHCP message header: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | msg-type | preference | transaction-ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | client-link-local-address | | (16 octets) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | server-address | | (16 octets) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . options . | (variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 9.10. DHCP Reconfigure-init Message Format msg-type RECONF-INIT preference (unused) MUST be 0 transaction-ID An unsigned integer generated by the server to identify this Reconfigure-init message client-link-local-address (unused) MUST be 0 server-address The IP address of the DHCP server issuing the Reconfigure-init message. MUST be of sufficient scope to be reachable by all clients. options See section 17. 14. DHCP Server-Initiated Configuration Exchange A server initiates a configuration exchange to force DHCP clients to obtain new addresses and other configuration information. For example, an administrator may use a server-initiated configuration exchange when links in the DHCP domain are to be renumbered. Other examples include changes in the location of directory servers, addition of new services such as printing, and availability of new software (system or application). 14.1. Reconfigure-init Message Validation Agents MUST silently discard any received Reconfigure-init messages. BV> Say "Servers and Agents MUST silently ..." Clients MUST discard any Reconfigure-init messages that do not contain an authentication option or that fail the client's authentication check. 14.2. Server Behavior A server sends a Reconfigure-init message to cause a client to initiate immediately a Request/Reply message exchange with the server. 14.2.1. Creation and sending of Reconfigure-init messages The server sets the "msg-type" field to RECONFIG-INIT. The server generates a transaction-ID and inserts it in the "transaction-ID" field. The server places its address (of appropriate scope) in the "server-address" field. The server MAY include an ORO option to inform the client of what information has been changed or new information that has been added. The server MUST include an authentication option with the appropriate settings and add that option as the last option in the "options" field of the Reconfigure-init message. The server MUST NOT include any other options in the Reconfigure-init except as specifically allowed in the definition of individual options. The server unicasts the Reconfigure-init message to one client. The server may unicast Reconfigure-init messages to more than one client concurrently; for example, to reliably reconfigure all known clients, the server will unicast a Reconfigure-init message to each client. After the server sends the Reconfigure-init message, it waits for a Request message from those clients confirming that each client has received the Reconfigure-init and are thus initiating a Request/Reply transaction with the server. 14.2.2. Time out and retransmission of Reconfigure-init messages If the server does not receive a Request message from the client in RECREP_MSG_TIMEOUT milliseconds, the server retransmits the Reconfigure-init message, doubles the RECREP_MSG_TIMEOUT value and waits again. The server continues this process until REC_MSG_ATTEMPTS unsuccessful attempts have been made, at which point the server SHOULD abort the reconfigure process. Default and initial values for RECREP_MSG_TIMEOUT and REC_MSG_ATTEMPTS are documented in section 7.5. 14.2.3. Receipt of Request messages The server generates and sends Reply message(s) to the client as described in section 13.4.6, including in the "option" field new values for configuration parameters. 14.3. Client Behavior A client MUST always monitor UDP port 546 for Reconfigure-init messages on interfaces upon which it has acquired DHCP parameters. Since the results of a reconfiguration event may affect application layer programs, the client SHOULD log these events, and MAY notify these programs of the change through an implementation-specific interface. 14.3.1. Receipt of Reconfigure-init messages Upon receipt of a valid Reconfigure-init message, the client initiates a Request/Reply transaction with the server. While the Request/Reply transaction is in progress, the client silently discards any Reconfigure-init messages it receives. BV> "the client MUST silently discard any Reconfigure-init messages it receives BV> on that interface [from that server]." The "from that server" is likely BV> important? What if a client has obtained several addresses from one server BV> and later tried to obtain more but was unable to from that server so it BV> sent a SOLICIT and started working with another server? We probably need to BV> be clear about what a Reconfigure-Init message means. Does it mean BV> reconfigure ALL addresses on that interface or does it mean to reconfigure BV> all addresses allocated by that server? Depending on how that is answered, BV> the "silently discard" needs to be conditionalized accordingly. And, what BV> happens if another server initiates a Reconfigure-Init (should it not too BV> be sent Request/Reply with all addresses). Perhaps it is OK to defer BV> processing of this new request until the first has been handled to simplify BV> client bookkeeping and operation? BV> BV> Also, I assume that a client MUST always send a Request, even if it has no BV> addresses or obtained configuration information from that server? Should BV> this be explicitly stated (it is assumed by the logic). DISCUSSION: The Reconfigure-init message acts as a trigger that signals the client to complete a successful Request/Reply message exchange. Once the client has received a Recongfigure-init, the client proceeds with the Request/Reply message exchange (retransmitting the Request if necessary); the client ignores any additional Reconfigure-init messages (regardless of the transaction ID in the Reconfigure-init message) until the Request/Reply exchange is complete. Subsequent Reconfigure-init messages (again independent of the transaction ID) cause the client to initiate a new Request/Reply exchange. How does this mechanism work in the face of duplicated or retransmitted Reconfigure-init messages? Duplicate messages will be ignored because the client will begin the Request/Reply exchange after the receipt of the first Reconfigure-init. Retransmitted messages will either trigger the Request/Reply exchange (if the first Reconfigure-init was not received by the client) or will be ignored. The server can discontinue retransmission of Reconfigure-init messages to the client once the server receives the client's Request. It might be possible for a duplicate or retransmitted Reconfigure-init to be sufficiently delayed (and delivered out of order) to arrive at the client after the Request/Reply exchange (initiated by the original Reconfigure-init) has been completed. In this case, the client would initiate a redundant Request/Reply exchange. The likelihood of delayed and out of order delivery is small enough to be ignored. The consequence of the redundant exchange is inefficiency rather than incorrect operation. 14.3.2. Creation and sending of Request messages When responding to a Reconfigure-init, the client creates and sends the Request message in exactly the same manner as outlined in section 13.3.1 with the following difference: IAs The client includes IA options containing the addresses the client currently has assigned to those IAs for the interface through which the Reconfigure-init message was received. 14.3.3. Time out and retransmission of Request messages The client uses the same variables and retransmission algorithm as it does with Request messages generated as part of a client-initiated configuration exchange. See section 13.3.1 for details. 14.3.4. Receipt of Reply messages Upon the receipt of a valid Reply message, the client extracts the contents of the "options" field, and sets (or resets) configuration parameters appropriately. The client records and updates the lifetimes for any addresses specified in IAs in the Reply message. If the configuration parameters changed were requested by the application layer, the client notifies the application layer of the changes using an implementation-specific interface. 17. DHCP options Options are used to carry additional information and parameters in DHCP messages. Every option shares a common base format, as described in section 17.1. This document describes the DHCP options defined as part of the base DHCP specification. Other options may be defined in the future in a separate document. 17.1. Format of DHCP options 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | option-code | option-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | option-data | | (option-len octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ option-code An unsigned integer identifying the specific option type carried in this option. option-len An unsigned integer giving the length of the data in this option in octets. option-data The data for the option; the format of this data depends on the definition of the option. 17.3. Option request option 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OPTION_ORO | option-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | requested-option-code-1 | requested-option-code-2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ option-code OPTION_ORO (2) option-len Variable; equal to twice the number of option codes carried in this option. option-data A list of the option codes for the options requested in this option. ------_=_NextPart_001_01C0EF9E.80DC3400 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Spec text for Reconfigure-init

Ralph:

Sorry for the slow response ... some comments (I = haven't seen other feedback yet?):

1) This text still does not state that the = transaction-id of the Reconfigure-Init is meaningless. It = should.

2) What if the number of IAs that might need to be = included exceed the packet size? Do we want to provide a means for a = client to send multiple Requests in this case. Hopefully, this is not a = common occurrance. I would leave the obligation to handle this at the = client and it is not a server issue. A server assumes a = Reconfigure-Init is done when a Request is received from the client. A = client's reconfiguration is not complete until it has done a Request = (or multiple Requests) on all of the IAs for the interface. Impacts = section 14.3.2.

3) As discussed later (see BV>), we need to = clarify exactly what Reconfigure-Init means:
        a) = Reconfigure *ALL* addresses on that particular interface regardless of = the server OR
        b) = Reconfigure only the addresses on that particular interface obtained = from that server.

There could be cases where there are multiple servers = and clients even obtained addresses from multiple servers (because a = server was temporarily down, for example). So, we need to be = clear.

From the text below, it would imply that all IAs on = the interface are sent (at least by my interpretation) - even those = that might not have been obtained from the server that sent the = Reconfigure-Init. I assume this is the desired behavoir but we need to = be more explicit about it.


Additional comments below.

- Bernie Volz

-----Original Message-----
From: Ralph Droms [mailto:rdroms@cisco.com]
Sent: Thursday, May 31, 2001 5:08 PM
To: DHCPv6 discussion list
Subject: Spec text for Reconfigure-init



Here's some proposed text describing the use of the = Reconfigure-init
message.  I've extracted this text from the = draft spec, so watch the
section numbers to be warned of elided text.

- Ralph

7. DHCP Constants

    This section describes various = program and networking constants used
    by DHCP.

7.5. Configuration Variables

    This section presents a table of = client and server configuration
    variables and the default or = initial values for these variables.  The
    client-specific variables MAY be = configured on the server and MAY be
    delivered to the client through = the "DHCP Retransmission Parameter
    Option" in a Reply = message.

    = ________________________________________________________________________= _
    = |Parameter__________|Default|_Description______________________________|= _
    = |MIN_SOL_DELAY______|1______|_MIN_(secs)_to_delay_1st_mesg_____________|= _
    = |MAX_SOL_DELAY______|5______|_MAX_(secs)_to_delay_1st_mesg_____________|= _
    = |ADV_MSG_TIMEOUT____|500____|_SOL_Retrans_timer_(msecs)________________|= _
    = |ADV_MSG_MAX________|30_____|_MAX_timer_value_(secs)___________________|= _
    = |SOL_MAX_ATTEMPTS___|-1_____|_MAX_attempts_(-1_=3D_infinite)____________= _|_
    = |REP_MSG_TIMEOUT____|250____|_Retrans_timer_(msecs)_for_Reply__________|= _
    = |QRY_MSG_ATTEMPTS___|10_____|_MAX_Request/Confirm/Renew/Rebind_attempts|= _
    = |REL_MSG_ATTEMPTS___|5______|_MAX_Release/Decline_attempts_____________|= _
    = |RECREP_MSG_TIMEOUT_|2000___|_Retrans_timer_(msecs)____________________|= _
    = |REC_MSG_ATTEMPTS___|10_____|_Reconfigure_attempts_____________________|= _
    = |REC_THRESHOLD______|100____|_%_of_required_clients____________________|= _
    = |SRVR_PREF_WAIT_____|2______|_Advertise_Collect_timer_(secs)___________|= _

9. Message Formats

    Each DHCP message has an identical = fixed format header; some messages
    also allow a variable format area = for options.  Not all fields in
    the header are used in every = message.  In this section, every field
    is described for every message = and fields that are not used in a
    message are marked as = "unused".  All unused fields in a message MUST
    be transmitted as zeroes and = ignored by the receiver of the message.

    The DHCP message header:

       = 0            = ;       = 1            = ;       = 2            = ;       3
       0 1 2 3 4 5 6 7 = 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
      |    = msg-type   |  preference   = |         = transaction-ID        |
      = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
      = |            = ;            = ;            = ;            = ;            = ;   |
      = |            = ;       = client-link-local-address        = ;           |
      = |            = ;            = ;  (16 = octets)           = ;            = ;   |
      = |            = ;            = ;            = ;            = ;            = ;   |
      = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
      = |            = ;            = ;            = ;            = ;            = ;   |
      = |            = ;            = ; = server-address         &nbs= p;           &nbs= p;  |
      = |            = ;            = ;  (16 = octets)           = ;            = ;   |
      = |            = ;            = ;            = ;            = ;            = ;   |
      = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
      = .           &nbs= p;           &nbs= p;           &nbs= p;           &nbs= p;           &nbs= p;   .
      = .           &nbs= p;           &nbs= p;    = options           = ;            = ;     .
      = |            = ;            = ;  = (variable)          &n= bsp;           &n= bsp;    |
      = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=


9.10. DHCP Reconfigure-init Message Format

       = msg-type          &nbs= p;         RECONF-INIT

       = preference          &n= bsp;       (unused) MUST be 0

       = transaction-ID         &nbs= p;    An unsigned integer generated
          &nb= sp;           &nb= sp;            = by the server to identify this
          &nb= sp;           &nb= sp;            = Reconfigure-init message

       = client-link-local-address   (unused) MUST be 0

       = server-address         &nbs= p;    The IP address of the DHCP server
          &nb= sp;           &nb= sp;            = issuing the Reconfigure-init message.
          &nb= sp;           &nb= sp;            = MUST be of sufficient scope to be
          &nb= sp;           &nb= sp;            = reachable by all clients.

       = options           = ;          See section = 17.

14. DHCP Server-Initiated Configuration = Exchange

    A server initiates a configuration = exchange to force DHCP clients
    to obtain new addresses and other = configuration information.  For
    example, an administrator may use = a server-initiated configuration
    exchange when links in the DHCP = domain are to be renumbered.  Other
    examples include changes in the = location of directory servers,
    addition of new services such as = printing, and availability of new
    software (system or = application).


14.1. Reconfigure-init Message Validation

    Agents MUST silently discard any = received Reconfigure-init messages.
BV> Say "Servers and Agents MUST silently = ..."

    Clients MUST discard any = Reconfigure-init messages that do
    not contain an authentication = option or that fail the client's
    authentication check.


14.2. Server Behavior

    A server sends a Reconfigure-init = message to cause a client to
    initiate immediately a = Request/Reply message exchange with the
    server.


14.2.1. Creation and sending of Reconfigure-init = messages

    The server sets the = "msg-type" field to RECONFIG-INIT. The server
    generates a transaction-ID and = inserts it in the "transaction-ID"
    field.  The server places = its address (of appropriate scope) in the
    "server-address" = field.

    The server MAY include an ORO = option to inform the client of what
    information has been changed or = new information that has been added.

    The server MUST include an = authentication option with the appropriate
    settings and add that option as = the last option in the "options"
    field of the Reconfigure-init = message.

    The server MUST NOT include any = other options in the Reconfigure-init
    except as specifically allowed in = the definition of individual
    options.

    The server unicasts the = Reconfigure-init message to one client.  The
    server may unicast = Reconfigure-init messages to more than one client
    concurrently; for example, to = reliably reconfigure all known clients,
    the server will unicast a = Reconfigure-init message to each client.

    After the server sends the = Reconfigure-init message, it waits for a
    Request message from those = clients confirming that each client has
    received the Reconfigure-init and = are thus initiating a Request/Reply
    transaction with the = server.


14.2.2. Time out and retransmission of = Reconfigure-init messages

    If the server does not receive a = Request message from the client
    in RECREP_MSG_TIMEOUT = milliseconds, the server retransmits
    the Reconfigure-init message, = doubles the RECREP_MSG_TIMEOUT
    value and waits again.  The = server continues this process until
    REC_MSG_ATTEMPTS unsuccessful = attempts have been made, at which point
    the server SHOULD abort the = reconfigure process.

    Default and initial values for = RECREP_MSG_TIMEOUT and
    REC_MSG_ATTEMPTS are documented = in section 7.5.


14.2.3. Receipt of Request messages

    The server generates and sends = Reply message(s) to the client as
    described in section 13.4.6, = including in the "option" field new
    values for configuration = parameters.


14.3. Client Behavior

    A client MUST always monitor UDP = port 546 for Reconfigure-init
    messages on interfaces upon which = it has acquired DHCP parameters.
    Since the results of a = reconfiguration event may affect application
    layer programs, the client SHOULD = log these events, and MAY notify
    these programs of the change = through an implementation-specific
    interface.


14.3.1. Receipt of Reconfigure-init messages

    Upon receipt of a valid = Reconfigure-init message, the client
    initiates a Request/Reply = transaction with the server.  While
    the Request/Reply transaction is = in progress, the client silently
    discards any Reconfigure-init = messages it receives.
BV> "the client MUST silently discard any = Reconfigure-init messages it receives
BV> on that interface [from that server]." = The "from that server" is likely
BV> important? What if a client has obtained = several addresses from one server
BV> and later tried to obtain more but was unable = to from that server so it
BV> sent a SOLICIT and started working with = another server? We probably need to
BV> be clear about what a Reconfigure-Init = message means. Does it mean
BV> reconfigure ALL addresses on that interface = or does it mean to reconfigure
BV> all addresses allocated by that server? = Depending on how that is answered,
BV> the "silently discard" needs to be = conditionalized accordingly. And, what
BV> happens if another server initiates a = Reconfigure-Init (should it not too
BV> be sent Request/Reply with all addresses). = Perhaps it is OK to defer
BV> processing of this new request until the = first has been handled to simplify
BV> client bookkeeping and operation?
BV>
BV> Also, I assume that a client MUST always send = a Request, even if it has no
BV> addresses or obtained configuration = information from that server? Should
BV> this be explicitly stated (it is assumed by = the logic).

    DISCUSSION:

       The = Reconfigure-init message acts as a trigger that signals
       the client to = complete a successful Request/Reply message
       exchange.  = Once the client has received a Recongfigure-init,
       the client = proceeds with the Request/Reply message
       exchange = (retransmitting the Request if necessary); the
       client ignores = any additional Reconfigure-init messages
       (regardless of = the transaction ID in the Reconfigure-init
       message) until = the Request/Reply exchange is complete.
       Subsequent = Reconfigure-init messages (again independent
       of the = transaction ID) cause the client to initiate a new
       Request/Reply = exchange.

       How does this = mechanism work in the face of duplicated
       or = retransmitted Reconfigure-init messages?  Duplicate
       messages will = be ignored because the client will begin
       the = Request/Reply exchange after the receipt of the
       first = Reconfigure-init.  Retransmitted messages will
       either trigger = the Request/Reply exchange (if the first
       = Reconfigure-init was not received by the client) or will
       be = ignored.  The server can discontinue retransmission of
       = Reconfigure-init messages to the client once the server
       receives the = client's Request.

       It might be = possible for a duplicate or retransmitted
       = Reconfigure-init to be sufficiently delayed (and
       delivered out = of order) to arrive at the client after
       the = Request/Reply exchange (initiated by the original
       = Reconfigure-init) has been completed.  In this case, the
       client would = initiate a redundant Request/Reply exchange.
       The likelihood = of delayed and out of order delivery is small
       enough to be = ignored.  The consequence of the redundant
       exchange is = inefficiency rather than incorrect operation.


14.3.2. Creation and sending of Request = messages

    When responding to a = Reconfigure-init, the client creates and
    sends the Request message in = exactly the same manner as outlined in
    section 13.3.1 with the following = difference:

       IAs   = The client includes IA options containing the addresses the
          &nb= sp;  client currently has assigned to those IAs for the = interface
          &nb= sp;  through which the Reconfigure-init message was = received.


14.3.3. Time out and retransmission of Request = messages

    The client uses the same variables = and retransmission algorithm as it
    does with Request messages = generated as part of a client-initiated
    configuration exchange.  See = section 13.3.1 for details.


14.3.4. Receipt of Reply messages

    Upon the receipt of a valid Reply = message, the client extracts the
    contents of the = "options" field, and sets (or resets) configuration
    parameters appropriately.  = The client records and updates the
    lifetimes for any addresses = specified in IAs in the Reply message.
    If the configuration parameters = changed were requested by the
    application layer, the client = notifies the application layer of the
    changes using an = implementation-specific interface.

17. DHCP options

    Options are used to carry = additional information and parameters
    in DHCP messages.  Every = option shares a common base format, as
    described in section 17.1.

    This document describes the DHCP = options defined as part of the base
    DHCP specification.  Other = options may be defined in the future in a
    separate document.


17.1. Format of DHCP options

       = 0            = ;       = 1            = ;       = 2            = ;       3
       0 1 2 3 4 5 6 7 = 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
      = |          = option-code          = |           = option-len          = |
      = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
      = |            = ;            = ;  = option-data          &= nbsp;           &= nbsp;   |
      = |            = ;          (option-len = octets)           = ;           |
      = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=



       option-code An = unsigned integer identifying the specific option
          &nb= sp;      type carried in this option.

       option-len An = unsigned integer giving the length of the data in
          &nb= sp;      this option in octets.

       option-data The = data for the option; the format of this data
          &nb= sp;      depends on the definition of the = option.


17.3. Option request option

       = 0            = ;       = 1            = ;       = 2            = ;       3
       0 1 2 3 4 5 6 7 = 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
      = |           = OPTION_ORO          = |           = option-len          = |
      = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
      |    = requested-option-code-1    |    = requested-option-code-2    |
      = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
      = |            = ;            = ;      = ...           &n= bsp;           &n= bsp;      |
      = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=



       option-code = OPTION_ORO (2)

       option-len = Variable; equal to twice the number of option codes
          &nb= sp;      carried in this option.

       option-data A = list of the option codes for the options requested
          &nb= sp;      in this option.

------_=_NextPart_001_01C0EF9E.80DC3400-- From owner-dhcp-v6@bucknell.edu Fri Jun 8 23:36:01 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA26107; Fri, 8 Jun 2001 23:36:01 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f593Z9L08362; Fri, 8 Jun 2001 23:35:09 -0400 (EDT) Received: from mail.users.bit-net.com (www.bit-net.com [208.146.132.4]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f593YsL12037 for ; Fri, 8 Jun 2001 23:34:54 -0400 (EDT) Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA29913; Fri, 8 Jun 2001 23:34:53 -0400 Date: Fri, 8 Jun 2001 23:34:53 -0400 (EDT) From: Jim Bound To: DHCPv6 discussion list Subject: RE: Spec text for Reconfigure-init In-Reply-To: <66F66129A77AD411B76200508B65AC697B316E@eambunt705.ena-east.ericsson.se> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Bernie, > 1) This text still does not state that the transaction-id of the > Reconfigure-Init is meaningless. It should. No comment at this point. > 2) What if the number of IAs that might need to be included exceed the > packet size? Do we want to provide a means for a client to send multiple > Requests in this case. Hopefully, this is not a common occurrance. I > would leave the obligation to handle this at the client and it is not a > server issue. A server assumes a Reconfigure-Init is done when a Request > is received from the client. A client's reconfiguration is not complete > until it has done a Request (or multiple Requests) on all of the IAs for > the interface. Impacts section 14.3.2. This is not necessary with IPv6. If the UDP packet exceeds the PMTU or the Link-MTU fragmentation will happen as part of IPv6 at the client and the server will reassemble. Unless your concerned about something else? > > 3) As discussed later (see BV>), we need to clarify exactly what > Reconfigure-Init means: > a) Reconfigure *ALL* addresses on that particular interface > regardless of the server OR > b) Reconfigure only the addresses on that particular interface > obtained from that server. Reconfigur-Init just tells the client to react based on the ORO. It is telling the client to act on an interface the server does not have be known by the client at all thats why authentication is mandatory for this feature and really all features I guess. > > There could be cases where there are multiple servers and clients even > obtained addresses from multiple servers (because a server was > temporarily down, for example). So, we need to be clear. > > >From the text below, it would imply that all IAs on the interface are > sent (at least by my interpretation) - even those that might not have > been obtained from the server that sent the Reconfigure-Init. I assume > this is the desired behavoir but we need to be more explicit about it. > > That is correct. And I agree. > Additional comments below. > > - Bernie Volz > > -----Original Message----- > From: Ralph Droms [mailto:rdroms@cisco.com] > Sent: Thursday, May 31, 2001 5:08 PM > To: DHCPv6 discussion list > Subject: Spec text for Reconfigure-init > > > > Here's some proposed text describing the use of the Reconfigure-init > message. I've extracted this text from the draft spec, so watch the > section numbers to be warned of elided text. > > - Ralph > > 7. DHCP Constants > > This section describes various program and networking constants used > by DHCP. > > 7.5. Configuration Variables > > This section presents a table of client and server configuration > variables and the default or initial values for these variables. The > client-specific variables MAY be configured on the server and MAY be > delivered to the client through the "DHCP Retransmission Parameter > Option" in a Reply message. > > _________________________________________________________________________ > |Parameter__________|Default|_Description______________________________|_ > |MIN_SOL_DELAY______|1______|_MIN_(secs)_to_delay_1st_mesg_____________|_ > |MAX_SOL_DELAY______|5______|_MAX_(secs)_to_delay_1st_mesg_____________|_ > |ADV_MSG_TIMEOUT____|500____|_SOL_Retrans_timer_(msecs)________________|_ > |ADV_MSG_MAX________|30_____|_MAX_timer_value_(secs)___________________|_ > |SOL_MAX_ATTEMPTS___|-1_____|_MAX_attempts_(-1_=_infinite)_____________|_ > |REP_MSG_TIMEOUT____|250____|_Retrans_timer_(msecs)_for_Reply__________|_ > |QRY_MSG_ATTEMPTS___|10_____|_MAX_Request/Confirm/Renew/Rebind_attempts|_ > |REL_MSG_ATTEMPTS___|5______|_MAX_Release/Decline_attempts_____________|_ > |RECREP_MSG_TIMEOUT_|2000___|_Retrans_timer_(msecs)____________________|_ > |REC_MSG_ATTEMPTS___|10_____|_Reconfigure_attempts_____________________|_ > |REC_THRESHOLD______|100____|_%_of_required_clients____________________|_ > |SRVR_PREF_WAIT_____|2______|_Advertise_Collect_timer_(secs)___________|_ > > 9. Message Formats > > Each DHCP message has an identical fixed format header; some messages > also allow a variable format area for options. Not all fields in > the header are used in every message. In this section, every field > is described for every message and fields that are not used in a > message are marked as "unused". All unused fields in a message MUST > be transmitted as zeroes and ignored by the receiver of the message. > > The DHCP message header: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | msg-type | preference | transaction-ID | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > | client-link-local-address | > | (16 octets) | > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > | server-address | > | (16 octets) | > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > . . > . options . > | (variable) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > 9.10. DHCP Reconfigure-init Message Format > > msg-type RECONF-INIT > > preference (unused) MUST be 0 > > transaction-ID An unsigned integer generated > by the server to identify this > Reconfigure-init message > > client-link-local-address (unused) MUST be 0 > > server-address The IP address of the DHCP server > issuing the Reconfigure-init message. > MUST be of sufficient scope to be > reachable by all clients. > > options See section 17. > > 14. DHCP Server-Initiated Configuration Exchange > > A server initiates a configuration exchange to force DHCP clients > to obtain new addresses and other configuration information. For > example, an administrator may use a server-initiated configuration > exchange when links in the DHCP domain are to be renumbered. Other > examples include changes in the location of directory servers, > addition of new services such as printing, and availability of new > software (system or application). > > > 14.1. Reconfigure-init Message Validation > > Agents MUST silently discard any received Reconfigure-init messages. > BV> Say "Servers and Agents MUST silently ..." > > Clients MUST discard any Reconfigure-init messages that do > not contain an authentication option or that fail the client's > authentication check. > > > 14.2. Server Behavior > > A server sends a Reconfigure-init message to cause a client to > initiate immediately a Request/Reply message exchange with the > server. > > > 14.2.1. Creation and sending of Reconfigure-init messages > > The server sets the "msg-type" field to RECONFIG-INIT. The server > generates a transaction-ID and inserts it in the "transaction-ID" > field. The server places its address (of appropriate scope) in the > "server-address" field. > > The server MAY include an ORO option to inform the client of what > information has been changed or new information that has been added. > > The server MUST include an authentication option with the appropriate > settings and add that option as the last option in the "options" > field of the Reconfigure-init message. > > The server MUST NOT include any other options in the Reconfigure-init > except as specifically allowed in the definition of individual > options. > > The server unicasts the Reconfigure-init message to one client. The > server may unicast Reconfigure-init messages to more than one client > concurrently; for example, to reliably reconfigure all known clients, > the server will unicast a Reconfigure-init message to each client. > > After the server sends the Reconfigure-init message, it waits for a > Request message from those clients confirming that each client has > received the Reconfigure-init and are thus initiating a Request/Reply > transaction with the server. > > > 14.2.2. Time out and retransmission of Reconfigure-init messages > > If the server does not receive a Request message from the client > in RECREP_MSG_TIMEOUT milliseconds, the server retransmits > the Reconfigure-init message, doubles the RECREP_MSG_TIMEOUT > value and waits again. The server continues this process until > REC_MSG_ATTEMPTS unsuccessful attempts have been made, at which point > the server SHOULD abort the reconfigure process. > > Default and initial values for RECREP_MSG_TIMEOUT and > REC_MSG_ATTEMPTS are documented in section 7.5. > > > 14.2.3. Receipt of Request messages > > The server generates and sends Reply message(s) to the client as > described in section 13.4.6, including in the "option" field new > values for configuration parameters. > > > 14.3. Client Behavior > > A client MUST always monitor UDP port 546 for Reconfigure-init > messages on interfaces upon which it has acquired DHCP parameters. > Since the results of a reconfiguration event may affect application > layer programs, the client SHOULD log these events, and MAY notify > these programs of the change through an implementation-specific > interface. > > > 14.3.1. Receipt of Reconfigure-init messages > > Upon receipt of a valid Reconfigure-init message, the client > initiates a Request/Reply transaction with the server. While > the Request/Reply transaction is in progress, the client silently > discards any Reconfigure-init messages it receives. > BV> "the client MUST silently discard any Reconfigure-init messages it receives > BV> on that interface [from that server]." The "from that server" is likely > BV> important? What if a client has obtained several addresses from one server > BV> and later tried to obtain more but was unable to from that server so it > BV> sent a SOLICIT and started working with another server? We probably need to > BV> be clear about what a Reconfigure-Init message means. Does it mean > BV> reconfigure ALL addresses on that interface or does it mean to reconfigure > BV> all addresses allocated by that server? Depending on how that is answered, > BV> the "silently discard" needs to be conditionalized accordingly. And, what > BV> happens if another server initiates a Reconfigure-Init (should it not too > BV> be sent Request/Reply with all addresses). Perhaps it is OK to defer > BV> processing of this new request until the first has been handled to simplify > BV> client bookkeeping and operation? > BV> > BV> Also, I assume that a client MUST always send a Request, even if it has no > BV> addresses or obtained configuration information from that server? Should > BV> this be explicitly stated (it is assumed by the logic). > > DISCUSSION: > > The Reconfigure-init message acts as a trigger that signals > the client to complete a successful Request/Reply message > exchange. Once the client has received a Recongfigure-init, > the client proceeds with the Request/Reply message > exchange (retransmitting the Request if necessary); the > client ignores any additional Reconfigure-init messages > (regardless of the transaction ID in the Reconfigure-init > message) until the Request/Reply exchange is complete. > Subsequent Reconfigure-init messages (again independent > of the transaction ID) cause the client to initiate a new > Request/Reply exchange. > > How does this mechanism work in the face of duplicated > or retransmitted Reconfigure-init messages? Duplicate > messages will be ignored because the client will begin > the Request/Reply exchange after the receipt of the > first Reconfigure-init. Retransmitted messages will > either trigger the Request/Reply exchange (if the first > Reconfigure-init was not received by the client) or will > be ignored. The server can discontinue retransmission of > Reconfigure-init messages to the client once the server > receives the client's Request. > > It might be possible for a duplicate or retransmitted > Reconfigure-init to be sufficiently delayed (and > delivered out of order) to arrive at the client after > the Request/Reply exchange (initiated by the original > Reconfigure-init) has been completed. In this case, the > client would initiate a redundant Request/Reply exchange. > The likelihood of delayed and out of order delivery is small > enough to be ignored. The consequence of the redundant > exchange is inefficiency rather than incorrect operation. > > > 14.3.2. Creation and sending of Request messages > > When responding to a Reconfigure-init, the client creates and > sends the Request message in exactly the same manner as outlined in > section 13.3.1 with the following difference: > > IAs The client includes IA options containing the addresses the > client currently has assigned to those IAs for the interface > through which the Reconfigure-init message was received. > > > 14.3.3. Time out and retransmission of Request messages > > The client uses the same variables and retransmission algorithm as it > does with Request messages generated as part of a client-initiated > configuration exchange. See section 13.3.1 for details. > > > 14.3.4. Receipt of Reply messages > > Upon the receipt of a valid Reply message, the client extracts the > contents of the "options" field, and sets (or resets) configuration > parameters appropriately. The client records and updates the > lifetimes for any addresses specified in IAs in the Reply message. > If the configuration parameters changed were requested by the > application layer, the client notifies the application layer of the > changes using an implementation-specific interface. > > 17. DHCP options > > Options are used to carry additional information and parameters > in DHCP messages. Every option shares a common base format, as > described in section 17.1. > > This document describes the DHCP options defined as part of the base > DHCP specification. Other options may be defined in the future in a > separate document. > > > 17.1. Format of DHCP options > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | option-code | option-len | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | option-data | > | (option-len octets) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > option-code An unsigned integer identifying the specific option > type carried in this option. > > option-len An unsigned integer giving the length of the data in > this option in octets. > > option-data The data for the option; the format of this data > depends on the definition of the option. > > > 17.3. Option request option > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | OPTION_ORO | option-len | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | requested-option-code-1 | requested-option-code-2 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | ... | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > option-code OPTION_ORO (2) > > option-len Variable; equal to twice the number of option codes > carried in this option. > > option-data A list of the option codes for the options requested > in this option. > From owner-dhcp-v6@bucknell.edu Sat Jun 9 22:03:03 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA22566; Sat, 9 Jun 2001 22:03:02 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f5A22nL21639; Sat, 9 Jun 2001 22:02:49 -0400 (EDT) Received: from rdroms-w2k.bucknell.edu (rtp-isp-nat-pool1-1.cisco.com [64.102.254.34]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f5A22XL15679 for ; Sat, 9 Jun 2001 22:02:33 -0400 (EDT) Message-Id: <4.3.2.7.2.20010608091727.00b4f810@mail.bucknell.edu> X-Sender: droms@mail.bucknell.edu X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sat, 09 Jun 2001 10:01:27 -0400 To: DHCPv6 discussion list From: Ralph Droms Subject: RE: Spec text for Reconfigure-init In-Reply-To: <66F66129A77AD411B76200508B65AC697B316E@eambunt705.ena-east .ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Bernie - thanks for the feedback. I'm still waiting for other reviews of this text. =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=* Soapbox: It is *CRUCIAL* that we get feedback from other WG members *AS SOON AS POSSIBLE*. In addition to this Reconfigure-init text, I will be posting some text excerpts about authentication and DHCPv6 options. We need you to read and comment on those excerpts so we can complete the next rev of the draft. =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=* Here are my responses to your (Bernie's) comments: 1) OK; text to be added pointing out that transaction-id of Reconfigure-init will be unused by client 2) I don't know that we have an upper bound on DHCPv6 message size that is smaller than the IPv6 UDP datagram size (in contrast with the DHCPv4 message size limit, which was imposed for compatibility with BOOTP and circa 1990 IPv4 stacks). I don't think the DHCPv6 message size is an issue. 3) I think the semantics should be to reconfigure all addresses (regardless of source) *AND* all DHCP-supplied configuration parameters on the interface over which the Reconfigure-init message was received. - Ralph At 05:09 PM 6/7/2001 -0500, Bernie Volz (EUD) wrote: >Ralph: > >Sorry for the slow response ... some comments (I haven't seen other >feedback yet?): > >1) This text still does not state that the transaction-id of the >Reconfigure-Init is meaningless. It should. > >2) What if the number of IAs that might need to be included exceed the >packet size? Do we want to provide a means for a client to send multiple >Requests in this case. Hopefully, this is not a common occurrance. I would >leave the obligation to handle this at the client and it is not a server >issue. A server assumes a Reconfigure-Init is done when a Request is >received from the client. A client's reconfiguration is not complete until >it has done a Request (or multiple Requests) on all of the IAs for the >interface. Impacts section 14.3.2. > >3) As discussed later (see BV>), we need to clarify exactly what >Reconfigure-Init means: > a) Reconfigure *ALL* addresses on that particular interface > regardless of the server OR > b) Reconfigure only the addresses on that particular interface > obtained from that server. > >There could be cases where there are multiple servers and clients even >obtained addresses from multiple servers (because a server was temporarily >down, for example). So, we need to be clear. > > From the text below, it would imply that all IAs on the interface are > sent (at least by my interpretation) - even those that might not have > been obtained from the server that sent the Reconfigure-Init. I assume > this is the desired behavoir but we need to be more explicit about it. > >Additional comments below. > >- Bernie Volz > >-----Original Message----- >From: Ralph Droms [mailto:rdroms@cisco.com] >Sent: Thursday, May 31, 2001 5:08 PM >To: DHCPv6 discussion list >Subject: Spec text for Reconfigure-init > > >Here's some proposed text describing the use of the Reconfigure-init >message. I've extracted this text from the draft spec, so watch the >section numbers to be warned of elided text. > >- Ralph > >7. DHCP Constants > > This section describes various program and networking constants used > by DHCP. > >7.5. Configuration Variables > > This section presents a table of client and server configuration > variables and the default or initial values for these variables. The > client-specific variables MAY be configured on the server and MAY be > delivered to the client through the "DHCP Retransmission Parameter > Option" in a Reply message. > > >_________________________________________________________________________ > >|Parameter__________|Default|_Description______________________________|_ > >|MIN_SOL_DELAY______|1______|_MIN_(secs)_to_delay_1st_mesg_____________|_ > >|MAX_SOL_DELAY______|5______|_MAX_(secs)_to_delay_1st_mesg_____________|_ > >|ADV_MSG_TIMEOUT____|500____|_SOL_Retrans_timer_(msecs)________________|_ > >|ADV_MSG_MAX________|30_____|_MAX_timer_value_(secs)___________________|_ > >|SOL_MAX_ATTEMPTS___|-1_____|_MAX_attempts_(-1_=_infinite)_____________|_ > >|REP_MSG_TIMEOUT____|250____|_Retrans_timer_(msecs)_for_Reply__________|_ > >|QRY_MSG_ATTEMPTS___|10_____|_MAX_Request/Confirm/Renew/Rebind_attempts|_ > >|REL_MSG_ATTEMPTS___|5______|_MAX_Release/Decline_attempts_____________|_ > >|RECREP_MSG_TIMEOUT_|2000___|_Retrans_timer_(msecs)____________________|_ > >|REC_MSG_ATTEMPTS___|10_____|_Reconfigure_attempts_____________________|_ > >|REC_THRESHOLD______|100____|_%_of_required_clients____________________|_ > >|SRVR_PREF_WAIT_____|2______|_Advertise_Collect_timer_(secs)___________|_ > >9. Message Formats > > Each DHCP message has an identical fixed format header; some messages > also allow a variable format area for options. Not all fields in > the header are used in every message. In this section, every field > is described for every message and fields that are not used in a > message are marked as "unused". All unused fields in a message MUST > be transmitted as zeroes and ignored by the receiver of the message. > > The DHCP message header: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | msg-type | preference | transaction-ID | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > | client-link-local-address | > | (16 octets) | > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > | server-address | > | (16 octets) | > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > . . > . options . > | (variable) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >9.10. DHCP Reconfigure-init Message Format > > msg-type RECONF-INIT > > preference (unused) MUST be 0 > > transaction-ID An unsigned integer generated > by the server to identify this > Reconfigure-init message > > client-link-local-address (unused) MUST be 0 > > server-address The IP address of the DHCP server > issuing the Reconfigure-init message. > MUST be of sufficient scope to be > reachable by all clients. > > options See section 17. > >14. DHCP Server-Initiated Configuration Exchange > > A server initiates a configuration exchange to force DHCP clients > to obtain new addresses and other configuration information. For > example, an administrator may use a server-initiated configuration > exchange when links in the DHCP domain are to be renumbered. Other > examples include changes in the location of directory servers, > addition of new services such as printing, and availability of new > software (system or application). > >14.1. Reconfigure-init Message Validation > > Agents MUST silently discard any received Reconfigure-init messages. >BV> Say "Servers and Agents MUST silently ..." > > Clients MUST discard any Reconfigure-init messages that do > not contain an authentication option or that fail the client's > authentication check. > >14.2. Server Behavior > > A server sends a Reconfigure-init message to cause a client to > initiate immediately a Request/Reply message exchange with the > server. > >14.2.1. Creation and sending of Reconfigure-init messages > > The server sets the "msg-type" field to RECONFIG-INIT. The server > generates a transaction-ID and inserts it in the "transaction-ID" > field. The server places its address (of appropriate scope) in the > "server-address" field. > > The server MAY include an ORO option to inform the client of what > information has been changed or new information that has been added. > > The server MUST include an authentication option with the appropriate > settings and add that option as the last option in the "options" > field of the Reconfigure-init message. > > The server MUST NOT include any other options in the Reconfigure-init > except as specifically allowed in the definition of individual > options. > > The server unicasts the Reconfigure-init message to one client. The > server may unicast Reconfigure-init messages to more than one client > concurrently; for example, to reliably reconfigure all known clients, > the server will unicast a Reconfigure-init message to each client. > > After the server sends the Reconfigure-init message, it waits for a > Request message from those clients confirming that each client has > received the Reconfigure-init and are thus initiating a Request/Reply > transaction with the server. > >14.2.2. Time out and retransmission of Reconfigure-init messages > > If the server does not receive a Request message from the client > in RECREP_MSG_TIMEOUT milliseconds, the server retransmits > the Reconfigure-init message, doubles the RECREP_MSG_TIMEOUT > value and waits again. The server continues this process until > REC_MSG_ATTEMPTS unsuccessful attempts have been made, at which point > the server SHOULD abort the reconfigure process. > > Default and initial values for RECREP_MSG_TIMEOUT and > REC_MSG_ATTEMPTS are documented in section 7.5. > >14.2.3. Receipt of Request messages > > The server generates and sends Reply message(s) to the client as > described in section 13.4.6, including in the "option" field new > values for configuration parameters. > >14.3. Client Behavior > > A client MUST always monitor UDP port 546 for Reconfigure-init > messages on interfaces upon which it has acquired DHCP parameters. > Since the results of a reconfiguration event may affect application > layer programs, the client SHOULD log these events, and MAY notify > these programs of the change through an implementation-specific > interface. > >14.3.1. Receipt of Reconfigure-init messages > > Upon receipt of a valid Reconfigure-init message, the client > initiates a Request/Reply transaction with the server. While > the Request/Reply transaction is in progress, the client silently > discards any Reconfigure-init messages it receives. >BV> "the client MUST silently discard any Reconfigure-init messages it >receives >BV> on that interface [from that server]." The "from that server" is likely >BV> important? What if a client has obtained several addresses from one >server >BV> and later tried to obtain more but was unable to from that server so it >BV> sent a SOLICIT and started working with another server? We probably >need to >BV> be clear about what a Reconfigure-Init message means. Does it mean >BV> reconfigure ALL addresses on that interface or does it mean to >reconfigure >BV> all addresses allocated by that server? Depending on how that is >answered, >BV> the "silently discard" needs to be conditionalized accordingly. And, what >BV> happens if another server initiates a Reconfigure-Init (should it not too >BV> be sent Request/Reply with all addresses). Perhaps it is OK to defer >BV> processing of this new request until the first has been handled to >simplify >BV> client bookkeeping and operation? >BV> >BV> Also, I assume that a client MUST always send a Request, even if it >has no >BV> addresses or obtained configuration information from that server? Should >BV> this be explicitly stated (it is assumed by the logic). > > DISCUSSION: > > The Reconfigure-init message acts as a trigger that signals > the client to complete a successful Request/Reply message > exchange. Once the client has received a Recongfigure-init, > the client proceeds with the Request/Reply message > exchange (retransmitting the Request if necessary); the > client ignores any additional Reconfigure-init messages > (regardless of the transaction ID in the Reconfigure-init > message) until the Request/Reply exchange is complete. > Subsequent Reconfigure-init messages (again independent > of the transaction ID) cause the client to initiate a new > Request/Reply exchange. > > How does this mechanism work in the face of duplicated > or retransmitted Reconfigure-init messages? Duplicate > messages will be ignored because the client will begin > the Request/Reply exchange after the receipt of the > first Reconfigure-init. Retransmitted messages will > either trigger the Request/Reply exchange (if the first > Reconfigure-init was not received by the client) or will > be ignored. The server can discontinue retransmission of > Reconfigure-init messages to the client once the server > receives the client's Request. > > It might be possible for a duplicate or retransmitted > Reconfigure-init to be sufficiently delayed (and > delivered out of order) to arrive at the client after > the Request/Reply exchange (initiated by the original > Reconfigure-init) has been completed. In this case, the > client would initiate a redundant Request/Reply exchange. > The likelihood of delayed and out of order delivery is small > enough to be ignored. The consequence of the redundant > exchange is inefficiency rather than incorrect operation. > >14.3.2. Creation and sending of Request messages > > When responding to a Reconfigure-init, the client creates and > sends the Request message in exactly the same manner as outlined in > section 13.3.1 with the following difference: > > IAs The client includes IA options containing the addresses the > client currently has assigned to those IAs for the interface > through which the Reconfigure-init message was received. > >14.3.3. Time out and retransmission of Request messages > > The client uses the same variables and retransmission algorithm as it > does with Request messages generated as part of a client-initiated > configuration exchange. See section 13.3.1 for details. > >14.3.4. Receipt of Reply messages > > Upon the receipt of a valid Reply message, the client extracts the > contents of the "options" field, and sets (or resets) configuration > parameters appropriately. The client records and updates the > lifetimes for any addresses specified in IAs in the Reply message. > If the configuration parameters changed were requested by the > application layer, the client notifies the application layer of the > changes using an implementation-specific interface. > >17. DHCP options > > Options are used to carry additional information and parameters > in DHCP messages. Every option shares a common base format, as > described in section 17.1. > > This document describes the DHCP options defined as part of the base > DHCP specification. Other options may be defined in the future in a > separate document. > >17.1. Format of DHCP options > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | option-code | option-len | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | option-data | > | (option-len octets) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > option-code An unsigned integer identifying the specific option > type carried in this option. > > option-len An unsigned integer giving the length of the data in > this option in octets. > > option-data The data for the option; the format of this data > depends on the definition of the option. > >17.3. Option request option > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | OPTION_ORO | option-len | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | requested-option-code-1 | requested-option-code-2 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | ... | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > option-code OPTION_ORO (2) > > option-len Variable; equal to twice the number of option codes > carried in this option. > > option-data A list of the option codes for the options requested > in this option. From owner-dhcp-v6@bucknell.edu Sun Jun 10 23:26:32 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA17811; Sun, 10 Jun 2001 23:26:31 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f5B3PmL12141; Sun, 10 Jun 2001 23:25:49 -0400 (EDT) Received: from imr2.ericy.com (imr2.ericy.com [12.34.240.68]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f5B3PaL12988 for ; Sun, 10 Jun 2001 23:25:36 -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 f5B3PL819986 for ; Sun, 10 Jun 2001 22:25:21 -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 f5B3PJ716416 for ; Sun, 10 Jun 2001 22:25:20 -0500 (CDT) Received: FROM eamrcnt760.exu.ericsson.se BY eamrcnt747.exu.ericsson.se ; Sun Jun 10 22:25:19 2001 -0500 Received: by eamrcnt760.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Sun, 10 Jun 2001 22:25:19 -0500 Message-ID: <66F66129A77AD411B76200508B65AC697B317A@eambunt705.ena-east.ericsson.se> From: "Bernie Volz (EUD)" To: DHCPv6 discussion list Subject: RE: Spec text for Reconfigure-init Date: Sun, 10 Jun 2001 22:25:18 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0F226.2397E4D0" Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN 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_01C0F226.2397E4D0 Content-Type: text/plain; charset="iso-8859-1" Ralph: >2) I don't know that we have an upper bound on DHCPv6 message size that is >smaller than the IPv6 UDP datagram size (in contrast with the DHCPv4 >message size limit, which was imposed for compatibility with BOOTP and >circa 1990 IPv4 stacks). I don't think the DHCPv6 message size is an issue. While I don't forsee any client having such a huge number of addresses, but just in case, it would be good to know what the maximum message size a server (and hence client) needs to support? After all it is a lot more work to have to support an arbitrary message size (ones needs to first determine the size of the message before reading it with UDP). So, I think we should specify a maximum message size. I would think that 8192 or 16384 should likely be more the sufficient for most cases? Regarding lack of feedback from others ... please don't let that stop you from publishing other parts. I'm most interested in the client identifier (DHCP Unique Identifier or whatever) and IA details. - Bernie Volz -----Original Message----- From: Ralph Droms [mailto:droms@bucknell.edu] Sent: Saturday, June 09, 2001 10:01 AM To: DHCPv6 discussion list Subject: RE: Spec text for Reconfigure-init Bernie - thanks for the feedback. I'm still waiting for other reviews of this text. =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=* Soapbox: It is *CRUCIAL* that we get feedback from other WG members *AS SOON AS POSSIBLE*. In addition to this Reconfigure-init text, I will be posting some text excerpts about authentication and DHCPv6 options. We need you to read and comment on those excerpts so we can complete the next rev of the draft. =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=* Here are my responses to your (Bernie's) comments: 1) OK; text to be added pointing out that transaction-id of Reconfigure-init will be unused by client 2) I don't know that we have an upper bound on DHCPv6 message size that is smaller than the IPv6 UDP datagram size (in contrast with the DHCPv4 message size limit, which was imposed for compatibility with BOOTP and circa 1990 IPv4 stacks). I don't think the DHCPv6 message size is an issue. 3) I think the semantics should be to reconfigure all addresses (regardless of source) *AND* all DHCP-supplied configuration parameters on the interface over which the Reconfigure-init message was received. - Ralph At 05:09 PM 6/7/2001 -0500, Bernie Volz (EUD) wrote: >Ralph: > >Sorry for the slow response ... some comments (I haven't seen other >feedback yet?): > >1) This text still does not state that the transaction-id of the >Reconfigure-Init is meaningless. It should. > >2) What if the number of IAs that might need to be included exceed the >packet size? Do we want to provide a means for a client to send multiple >Requests in this case. Hopefully, this is not a common occurrance. I would >leave the obligation to handle this at the client and it is not a server >issue. A server assumes a Reconfigure-Init is done when a Request is >received from the client. A client's reconfiguration is not complete until >it has done a Request (or multiple Requests) on all of the IAs for the >interface. Impacts section 14.3.2. > >3) As discussed later (see BV>), we need to clarify exactly what >Reconfigure-Init means: > a) Reconfigure *ALL* addresses on that particular interface > regardless of the server OR > b) Reconfigure only the addresses on that particular interface > obtained from that server. > >There could be cases where there are multiple servers and clients even >obtained addresses from multiple servers (because a server was temporarily >down, for example). So, we need to be clear. > > From the text below, it would imply that all IAs on the interface are > sent (at least by my interpretation) - even those that might not have > been obtained from the server that sent the Reconfigure-Init. I assume > this is the desired behavoir but we need to be more explicit about it. > >Additional comments below. > >- Bernie Volz > >-----Original Message----- >From: Ralph Droms [mailto:rdroms@cisco.com] >Sent: Thursday, May 31, 2001 5:08 PM >To: DHCPv6 discussion list >Subject: Spec text for Reconfigure-init > > >Here's some proposed text describing the use of the Reconfigure-init >message. I've extracted this text from the draft spec, so watch the >section numbers to be warned of elided text. > >- Ralph > >7. DHCP Constants > > This section describes various program and networking constants used > by DHCP. > >7.5. Configuration Variables > > This section presents a table of client and server configuration > variables and the default or initial values for these variables. The > client-specific variables MAY be configured on the server and MAY be > delivered to the client through the "DHCP Retransmission Parameter > Option" in a Reply message. > > >_________________________________________________________________________ > >|Parameter__________|Default|_Description______________________________|_ > >|MIN_SOL_DELAY______|1______|_MIN_(secs)_to_delay_1st_mesg_____________|_ > >|MAX_SOL_DELAY______|5______|_MAX_(secs)_to_delay_1st_mesg_____________|_ > >|ADV_MSG_TIMEOUT____|500____|_SOL_Retrans_timer_(msecs)________________|_ > >|ADV_MSG_MAX________|30_____|_MAX_timer_value_(secs)___________________|_ > >|SOL_MAX_ATTEMPTS___|-1_____|_MAX_attempts_(-1_=_infinite)_____________|_ > >|REP_MSG_TIMEOUT____|250____|_Retrans_timer_(msecs)_for_Reply__________|_ > >|QRY_MSG_ATTEMPTS___|10_____|_MAX_Request/Confirm/Renew/Rebind_attempts|_ > >|REL_MSG_ATTEMPTS___|5______|_MAX_Release/Decline_attempts_____________|_ > >|RECREP_MSG_TIMEOUT_|2000___|_Retrans_timer_(msecs)____________________|_ > >|REC_MSG_ATTEMPTS___|10_____|_Reconfigure_attempts_____________________|_ > >|REC_THRESHOLD______|100____|_%_of_required_clients____________________|_ > >|SRVR_PREF_WAIT_____|2______|_Advertise_Collect_timer_(secs)___________|_ > >9. Message Formats > > Each DHCP message has an identical fixed format header; some messages > also allow a variable format area for options. Not all fields in > the header are used in every message. In this section, every field > is described for every message and fields that are not used in a > message are marked as "unused". All unused fields in a message MUST > be transmitted as zeroes and ignored by the receiver of the message. > > The DHCP message header: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | msg-type | preference | transaction-ID | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > | client-link-local-address | > | (16 octets) | > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > | server-address | > | (16 octets) | > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > . . > . options . > | (variable) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >9.10. DHCP Reconfigure-init Message Format > > msg-type RECONF-INIT > > preference (unused) MUST be 0 > > transaction-ID An unsigned integer generated > by the server to identify this > Reconfigure-init message > > client-link-local-address (unused) MUST be 0 > > server-address The IP address of the DHCP server > issuing the Reconfigure-init message. > MUST be of sufficient scope to be > reachable by all clients. > > options See section 17. > >14. DHCP Server-Initiated Configuration Exchange > > A server initiates a configuration exchange to force DHCP clients > to obtain new addresses and other configuration information. For > example, an administrator may use a server-initiated configuration > exchange when links in the DHCP domain are to be renumbered. Other > examples include changes in the location of directory servers, > addition of new services such as printing, and availability of new > software (system or application). > >14.1. Reconfigure-init Message Validation > > Agents MUST silently discard any received Reconfigure-init messages. >BV> Say "Servers and Agents MUST silently ..." > > Clients MUST discard any Reconfigure-init messages that do > not contain an authentication option or that fail the client's > authentication check. > >14.2. Server Behavior > > A server sends a Reconfigure-init message to cause a client to > initiate immediately a Request/Reply message exchange with the > server. > >14.2.1. Creation and sending of Reconfigure-init messages > > The server sets the "msg-type" field to RECONFIG-INIT. The server > generates a transaction-ID and inserts it in the "transaction-ID" > field. The server places its address (of appropriate scope) in the > "server-address" field. > > The server MAY include an ORO option to inform the client of what > information has been changed or new information that has been added. > > The server MUST include an authentication option with the appropriate > settings and add that option as the last option in the "options" > field of the Reconfigure-init message. > > The server MUST NOT include any other options in the Reconfigure-init > except as specifically allowed in the definition of individual > options. > > The server unicasts the Reconfigure-init message to one client. The > server may unicast Reconfigure-init messages to more than one client > concurrently; for example, to reliably reconfigure all known clients, > the server will unicast a Reconfigure-init message to each client. > > After the server sends the Reconfigure-init message, it waits for a > Request message from those clients confirming that each client has > received the Reconfigure-init and are thus initiating a Request/Reply > transaction with the server. > >14.2.2. Time out and retransmission of Reconfigure-init messages > > If the server does not receive a Request message from the client > in RECREP_MSG_TIMEOUT milliseconds, the server retransmits > the Reconfigure-init message, doubles the RECREP_MSG_TIMEOUT > value and waits again. The server continues this process until > REC_MSG_ATTEMPTS unsuccessful attempts have been made, at which point > the server SHOULD abort the reconfigure process. > > Default and initial values for RECREP_MSG_TIMEOUT and > REC_MSG_ATTEMPTS are documented in section 7.5. > >14.2.3. Receipt of Request messages > > The server generates and sends Reply message(s) to the client as > described in section 13.4.6, including in the "option" field new > values for configuration parameters. > >14.3. Client Behavior > > A client MUST always monitor UDP port 546 for Reconfigure-init > messages on interfaces upon which it has acquired DHCP parameters. > Since the results of a reconfiguration event may affect application > layer programs, the client SHOULD log these events, and MAY notify > these programs of the change through an implementation-specific > interface. > >14.3.1. Receipt of Reconfigure-init messages > > Upon receipt of a valid Reconfigure-init message, the client > initiates a Request/Reply transaction with the server. While > the Request/Reply transaction is in progress, the client silently > discards any Reconfigure-init messages it receives. >BV> "the client MUST silently discard any Reconfigure-init messages it >receives >BV> on that interface [from that server]." The "from that server" is likely >BV> important? What if a client has obtained several addresses from one >server >BV> and later tried to obtain more but was unable to from that server so it >BV> sent a SOLICIT and started working with another server? We probably >need to >BV> be clear about what a Reconfigure-Init message means. Does it mean >BV> reconfigure ALL addresses on that interface or does it mean to >reconfigure >BV> all addresses allocated by that server? Depending on how that is >answered, >BV> the "silently discard" needs to be conditionalized accordingly. And, what >BV> happens if another server initiates a Reconfigure-Init (should it not too >BV> be sent Request/Reply with all addresses). Perhaps it is OK to defer >BV> processing of this new request until the first has been handled to >simplify >BV> client bookkeeping and operation? >BV> >BV> Also, I assume that a client MUST always send a Request, even if it >has no >BV> addresses or obtained configuration information from that server? Should >BV> this be explicitly stated (it is assumed by the logic). > > DISCUSSION: > > The Reconfigure-init message acts as a trigger that signals > the client to complete a successful Request/Reply message > exchange. Once the client has received a Recongfigure-init, > the client proceeds with the Request/Reply message > exchange (retransmitting the Request if necessary); the > client ignores any additional Reconfigure-init messages > (regardless of the transaction ID in the Reconfigure-init > message) until the Request/Reply exchange is complete. > Subsequent Reconfigure-init messages (again independent > of the transaction ID) cause the client to initiate a new > Request/Reply exchange. > > How does this mechanism work in the face of duplicated > or retransmitted Reconfigure-init messages? Duplicate > messages will be ignored because the client will begin > the Request/Reply exchange after the receipt of the > first Reconfigure-init. Retransmitted messages will > either trigger the Request/Reply exchange (if the first > Reconfigure-init was not received by the client) or will > be ignored. The server can discontinue retransmission of > Reconfigure-init messages to the client once the server > receives the client's Request. > > It might be possible for a duplicate or retransmitted > Reconfigure-init to be sufficiently delayed (and > delivered out of order) to arrive at the client after > the Request/Reply exchange (initiated by the original > Reconfigure-init) has been completed. In this case, the > client would initiate a redundant Request/Reply exchange. > The likelihood of delayed and out of order delivery is small > enough to be ignored. The consequence of the redundant > exchange is inefficiency rather than incorrect operation. > >14.3.2. Creation and sending of Request messages > > When responding to a Reconfigure-init, the client creates and > sends the Request message in exactly the same manner as outlined in > section 13.3.1 with the following difference: > > IAs The client includes IA options containing the addresses the > client currently has assigned to those IAs for the interface > through which the Reconfigure-init message was received. > >14.3.3. Time out and retransmission of Request messages > > The client uses the same variables and retransmission algorithm as it > does with Request messages generated as part of a client-initiated > configuration exchange. See section 13.3.1 for details. > >14.3.4. Receipt of Reply messages > > Upon the receipt of a valid Reply message, the client extracts the > contents of the "options" field, and sets (or resets) configuration > parameters appropriately. The client records and updates the > lifetimes for any addresses specified in IAs in the Reply message. > If the configuration parameters changed were requested by the > application layer, the client notifies the application layer of the > changes using an implementation-specific interface. > >17. DHCP options > > Options are used to carry additional information and parameters > in DHCP messages. Every option shares a common base format, as > described in section 17.1. > > This document describes the DHCP options defined as part of the base > DHCP specification. Other options may be defined in the future in a > separate document. > >17.1. Format of DHCP options > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | option-code | option-len | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | option-data | > | (option-len octets) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > option-code An unsigned integer identifying the specific option > type carried in this option. > > option-len An unsigned integer giving the length of the data in > this option in octets. > > option-data The data for the option; the format of this data > depends on the definition of the option. > >17.3. Option request option > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | OPTION_ORO | option-len | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | requested-option-code-1 | requested-option-code-2 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | ... | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > option-code OPTION_ORO (2) > > option-len Variable; equal to twice the number of option codes > carried in this option. > > option-data A list of the option codes for the options requested > in this option. ------_=_NextPart_001_01C0F226.2397E4D0 Content-Type: text/html; charset="iso-8859-1" RE: Spec text for Reconfigure-init

Ralph:

>2) I don't know that we have an upper bound on DHCPv6 message size that is
>smaller than the IPv6 UDP datagram size (in contrast with the DHCPv4
>message size limit, which was imposed for compatibility with BOOTP and
>circa 1990 IPv4 stacks).  I don't think the DHCPv6 message size is an issue.

While I don't forsee any client having such a huge number of addresses, but just
in case, it would be good to know what the maximum message size a server (and
hence client) needs to support? After all it is a lot more work to have to support
an arbitrary message size (ones needs to first determine the size of the message
before reading it with UDP). So, I think we should specify a maximum message size.
I would think that 8192 or 16384 should likely be more the sufficient for most
cases?


Regarding lack of feedback from others ... please don't let that stop you from
publishing other parts. I'm most interested in the client identifier (DHCP Unique
Identifier or whatever) and IA details.

- Bernie Volz

-----Original Message-----
From: Ralph Droms [mailto:droms@bucknell.edu]
Sent: Saturday, June 09, 2001 10:01 AM
To: DHCPv6 discussion list
Subject: RE: Spec text for Reconfigure-init


Bernie - thanks for the feedback.  I'm still waiting for other reviews of
this text.

=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*
Soapbox: It is *CRUCIAL* that we get feedback from
other WG members *AS SOON AS POSSIBLE*.    In addition
to this Reconfigure-init text, I will be posting some
text excerpts about authentication and DHCPv6 options.
We need you to read and comment on those excerpts so
we can complete the next rev of the draft.
=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*

Here are my responses to your (Bernie's) comments:

1) OK; text to be added pointing out that transaction-id of
Reconfigure-init will be unused by client

2) I don't know that we have an upper bound on DHCPv6 message size that is
smaller than the IPv6 UDP datagram size (in contrast with the DHCPv4
message size limit, which was imposed for compatibility with BOOTP and
circa 1990 IPv4 stacks).  I don't think the DHCPv6 message size is an issue.

3) I think the semantics should be to reconfigure all addresses (regardless
of source) *AND* all DHCP-supplied configuration parameters on the
interface over which the Reconfigure-init message was received.

- Ralph


At 05:09 PM 6/7/2001 -0500, Bernie Volz (EUD) wrote:

>Ralph:
>
>Sorry for the slow response ... some comments (I haven't seen other
>feedback yet?):
>
>1) This text still does not state that the transaction-id of the
>Reconfigure-Init is meaningless. It should.
>
>2) What if the number of IAs that might need to be included exceed the
>packet size? Do we want to provide a means for a client to send multiple
>Requests in this case. Hopefully, this is not a common occurrance. I would
>leave the obligation to handle this at the client and it is not a server
>issue. A server assumes a Reconfigure-Init is done when a Request is
>received from the client. A client's reconfiguration is not complete until
>it has done a Request (or multiple Requests) on all of the IAs for the
>interface. Impacts section 14.3.2.
>
>3) As discussed later (see BV>), we need to clarify exactly what
>Reconfigure-Init means:
>         a) Reconfigure *ALL* addresses on that particular interface
> regardless of the server OR
>         b) Reconfigure only the addresses on that particular interface
> obtained from that server.
>
>There could be cases where there are multiple servers and clients even
>obtained addresses from multiple servers (because a server was temporarily
>down, for example). So, we need to be clear.
>
> From the text below, it would imply that all IAs on the interface are
> sent (at least by my interpretation) - even those that might not have
> been obtained from the server that sent the Reconfigure-Init. I assume
> this is the desired behavoir but we need to be more explicit about it.
>
>Additional comments below.
>
>- Bernie Volz
>
>-----Original Message-----
>From: Ralph Droms [<mailto:rdroms@cisco.com>mailto:rdroms@cisco.com]
>Sent: Thursday, May 31, 2001 5:08 PM
>To: DHCPv6 discussion list
>Subject: Spec text for Reconfigure-init
>
>
>Here's some proposed text describing the use of the Reconfigure-init
>message.  I've extracted this text from the draft spec, so watch the
>section numbers to be warned of elided text.
>
>- Ralph
>
>7. DHCP Constants
>
>     This section describes various program and networking constants used
>     by DHCP.
>
>7.5. Configuration Variables
>
>     This section presents a table of client and server configuration
>     variables and the default or initial values for these variables.  The
>     client-specific variables MAY be configured on the server and MAY be
>     delivered to the client through the "DHCP Retransmission Parameter
>     Option" in a Reply message.
>
>
>_________________________________________________________________________
>
>|Parameter__________|Default|_Description______________________________|_
>
>|MIN_SOL_DELAY______|1______|_MIN_(secs)_to_delay_1st_mesg_____________|_
>
>|MAX_SOL_DELAY______|5______|_MAX_(secs)_to_delay_1st_mesg_____________|_
>
>|ADV_MSG_TIMEOUT____|500____|_SOL_Retrans_timer_(msecs)________________|_
>
>|ADV_MSG_MAX________|30_____|_MAX_timer_value_(secs)___________________|_
>
>|SOL_MAX_ATTEMPTS___|-1_____|_MAX_attempts_(-1_=_infinite)_____________|_
>
>|REP_MSG_TIMEOUT____|250____|_Retrans_timer_(msecs)_for_Reply__________|_
>
>|QRY_MSG_ATTEMPTS___|10_____|_MAX_Request/Confirm/Renew/Rebind_attempts|_
>
>|REL_MSG_ATTEMPTS___|5______|_MAX_Release/Decline_attempts_____________|_
>
>|RECREP_MSG_TIMEOUT_|2000___|_Retrans_timer_(msecs)____________________|_
>
>|REC_MSG_ATTEMPTS___|10_____|_Reconfigure_attempts_____________________|_
>
>|REC_THRESHOLD______|100____|_%_of_required_clients____________________|_
>
>|SRVR_PREF_WAIT_____|2______|_Advertise_Collect_timer_(secs)___________|_
>
>9. Message Formats
>
>     Each DHCP message has an identical fixed format header; some messages
>     also allow a variable format area for options.  Not all fields in
>     the header are used in every message.  In this section, every field
>     is described for every message and fields that are not used in a
>     message are marked as "unused".  All unused fields in a message MUST
>     be transmitted as zeroes and ignored by the receiver of the message.
>
>     The DHCP message header:
>
>        0                   1                   2                   3
>        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |    msg-type   |  preference   |         transaction-ID        |
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |                                                               |
>       |                   client-link-local-address                   |
>       |                          (16 octets)                          |
>       |                                                               |
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |                                                               |
>       |                         server-address                        |
>       |                          (16 octets)                          |
>       |                                                               |
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       .                                                               .
>       .                            options                            .
>       |                          (variable)                           |
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>9.10. DHCP Reconfigure-init Message Format
>
>        msg-type                    RECONF-INIT
>
>        preference                  (unused) MUST be 0
>
>        transaction-ID              An unsigned integer generated
>                                    by the server to identify this
>                                    Reconfigure-init message
>
>        client-link-local-address   (unused) MUST be 0
>
>        server-address              The IP address of the DHCP server
>                                    issuing the Reconfigure-init message.
>                                    MUST be of sufficient scope to be
>                                    reachable by all clients.
>
>        options                     See section 17.
>
>14. DHCP Server-Initiated Configuration Exchange
>
>     A server initiates a configuration exchange to force DHCP clients
>     to obtain new addresses and other configuration information.  For
>     example, an administrator may use a server-initiated configuration
>     exchange when links in the DHCP domain are to be renumbered.  Other
>     examples include changes in the location of directory servers,
>     addition of new services such as printing, and availability of new
>     software (system or application).
>
>14.1. Reconfigure-init Message Validation
>
>     Agents MUST silently discard any received Reconfigure-init messages.
>BV> Say "Servers and Agents MUST silently ..."
>
>     Clients MUST discard any Reconfigure-init messages that do
>     not contain an authentication option or that fail the client's
>     authentication check.
>
>14.2. Server Behavior
>
>     A server sends a Reconfigure-init message to cause a client to
>     initiate immediately a Request/Reply message exchange with the
>     server.
>
>14.2.1. Creation and sending of Reconfigure-init messages
>
>     The server sets the "msg-type" field to RECONFIG-INIT. The server
>     generates a transaction-ID and inserts it in the "transaction-ID"
>     field.  The server places its address (of appropriate scope) in the
>     "server-address" field.
>
>     The server MAY include an ORO option to inform the client of what
>     information has been changed or new information that has been added.
>
>     The server MUST include an authentication option with the appropriate
>     settings and add that option as the last option in the "options"
>     field of the Reconfigure-init message.
>
>     The server MUST NOT include any other options in the Reconfigure-init
>     except as specifically allowed in the definition of individual
>     options.
>
>     The server unicasts the Reconfigure-init message to one client.  The
>     server may unicast Reconfigure-init messages to more than one client
>     concurrently; for example, to reliably reconfigure all known clients,
>     the server will unicast a Reconfigure-init message to each client.
>
>     After the server sends the Reconfigure-init message, it waits for a
>     Request message from those clients confirming that each client has
>     received the Reconfigure-init and are thus initiating a Request/Reply
>     transaction with the server.
>
>14.2.2. Time out and retransmission of Reconfigure-init messages
>
>     If the server does not receive a Request message from the client
>     in RECREP_MSG_TIMEOUT milliseconds, the server retransmits
>     the Reconfigure-init message, doubles the RECREP_MSG_TIMEOUT
>     value and waits again.  The server continues this process until
>     REC_MSG_ATTEMPTS unsuccessful attempts have been made, at which point
>     the server SHOULD abort the reconfigure process.
>
>     Default and initial values for RECREP_MSG_TIMEOUT and
>     REC_MSG_ATTEMPTS are documented in section 7.5.
>
>14.2.3. Receipt of Request messages
>
>     The server generates and sends Reply message(s) to the client as
>     described in section 13.4.6, including in the "option" field new
>     values for configuration parameters.
>
>14.3. Client Behavior
>
>     A client MUST always monitor UDP port 546 for Reconfigure-init
>     messages on interfaces upon which it has acquired DHCP parameters.
>     Since the results of a reconfiguration event may affect application
>     layer programs, the client SHOULD log these events, and MAY notify
>     these programs of the change through an implementation-specific
>     interface.
>
>14.3.1. Receipt of Reconfigure-init messages
>
>     Upon receipt of a valid Reconfigure-init message, the client
>     initiates a Request/Reply transaction with the server.  While
>     the Request/Reply transaction is in progress, the client silently
>     discards any Reconfigure-init messages it receives.
>BV> "the client MUST silently discard any Reconfigure-init messages it
>receives
>BV> on that interface [from that server]." The "from that server" is likely
>BV> important? What if a client has obtained several addresses from one
>server
>BV> and later tried to obtain more but was unable to from that server so it
>BV> sent a SOLICIT and started working with another server? We probably
>need to
>BV> be clear about what a Reconfigure-Init message means. Does it mean
>BV> reconfigure ALL addresses on that interface or does it mean to
>reconfigure
>BV> all addresses allocated by that server? Depending on how that is
>answered,
>BV> the "silently discard" needs to be conditionalized accordingly. And, what
>BV> happens if another server initiates a Reconfigure-Init (should it not too
>BV> be sent Request/Reply with all addresses). Perhaps it is OK to defer
>BV> processing of this new request until the first has been handled to
>simplify
>BV> client bookkeeping and operation?
>BV>
>BV> Also, I assume that a client MUST always send a Request, even if it
>has no
>BV> addresses or obtained configuration information from that server? Should
>BV> this be explicitly stated (it is assumed by the logic).
>
>     DISCUSSION:
>
>        The Reconfigure-init message acts as a trigger that signals
>        the client to complete a successful Request/Reply message
>        exchange.  Once the client has received a Recongfigure-init,
>        the client proceeds with the Request/Reply message
>        exchange (retransmitting the Request if necessary); the
>        client ignores any additional Reconfigure-init messages
>        (regardless of the transaction ID in the Reconfigure-init
>        message) until the Request/Reply exchange is complete.
>        Subsequent Reconfigure-init messages (again independent
>        of the transaction ID) cause the client to initiate a new
>        Request/Reply exchange.
>
>        How does this mechanism work in the face of duplicated
>        or retransmitted Reconfigure-init messages?  Duplicate
>        messages will be ignored because the client will begin
>        the Request/Reply exchange after the receipt of the
>        first Reconfigure-init.  Retransmitted messages will
>        either trigger the Request/Reply exchange (if the first
>        Reconfigure-init was not received by the client) or will
>        be ignored.  The server can discontinue retransmission of
>        Reconfigure-init messages to the client once the server
>        receives the client's Request.
>
>        It might be possible for a duplicate or retransmitted
>        Reconfigure-init to be sufficiently delayed (and
>        delivered out of order) to arrive at the client after
>        the Request/Reply exchange (initiated by the original
>        Reconfigure-init) has been completed.  In this case, the
>        client would initiate a redundant Request/Reply exchange.
>        The likelihood of delayed and out of order delivery is small
>        enough to be ignored.  The consequence of the redundant
>        exchange is inefficiency rather than incorrect operation.
>
>14.3.2. Creation and sending of Request messages
>
>     When responding to a Reconfigure-init, the client creates and
>     sends the Request message in exactly the same manner as outlined in
>     section 13.3.1 with the following difference:
>
>        IAs   The client includes IA options containing the addresses the
>              client currently has assigned to those IAs for the interface
>              through which the Reconfigure-init message was received.
>
>14.3.3. Time out and retransmission of Request messages
>
>     The client uses the same variables and retransmission algorithm as it
>     does with Request messages generated as part of a client-initiated
>     configuration exchange.  See section 13.3.1 for details.
>
>14.3.4. Receipt of Reply messages
>
>     Upon the receipt of a valid Reply message, the client extracts the
>     contents of the "options" field, and sets (or resets) configuration
>     parameters appropriately.  The client records and updates the
>     lifetimes for any addresses specified in IAs in the Reply message.
>     If the configuration parameters changed were requested by the
>     application layer, the client notifies the application layer of the
>     changes using an implementation-specific interface.
>
>17. DHCP options
>
>     Options are used to carry additional information and parameters
>     in DHCP messages.  Every option shares a common base format, as
>     described in section 17.1.
>
>     This document describes the DHCP options defined as part of the base
>     DHCP specification.  Other options may be defined in the future in a
>     separate document.
>
>17.1. Format of DHCP options
>
>        0                   1                   2                   3
>        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |          option-code          |           option-len          |
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |                          option-data                          |
>       |                      (option-len octets)                      |
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>
>        option-code An unsigned integer identifying the specific option
>                  type carried in this option.
>
>        option-len An unsigned integer giving the length of the data in
>                  this option in octets.
>
>        option-data The data for the option; the format of this data
>                  depends on the definition of the option.
>
>17.3. Option request option
>
>        0                   1                   2                   3
>        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |           OPTION_ORO          |           option-len          |
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |    requested-option-code-1    |    requested-option-code-2    |
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |                              ...                              |
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>
>        option-code OPTION_ORO (2)
>
>        option-len Variable; equal to twice the number of option codes
>                  carried in this option.
>
>        option-data A list of the option codes for the options requested
>                  in this option.

------_=_NextPart_001_01C0F226.2397E4D0-- From owner-dhcp-v4@bucknell.edu Fri Jun 15 18:08:16 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00611 for ; Fri, 15 Jun 2001 18:08:15 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f5FM4oL16965; Fri, 15 Jun 2001 18:04:51 -0400 (EDT) Received: from mail-out2.apple.com (mail-out2.apple.com [17.254.0.51]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f5FM4gL14922 for ; Fri, 15 Jun 2001 18:04:42 -0400 (EDT) Received: from apple.con (A17-128-100-225.apple.com [17.128.100.225]) by mail-out2.apple.com (8.9.3/8.9.3) with ESMTP id PAA14935 for ; Fri, 15 Jun 2001 15:04:41 -0700 (PDT) Received: from scv1.apple.com (scv1.apple.com) by apple.con (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Fri, 15 Jun 2001 15:02:59 +0100 Received: from [206.111.147.149] (vpn-gh-1026.apple.com [17.254.140.1]) by scv1.apple.com (8.9.3/8.9.3) with SMTP id PAA00539 for ; Fri, 15 Jun 2001 15:04:40 -0700 (PDT) Message-Id: <200106152204.PAA00539@scv1.apple.com> Subject: RE: Suffix search order RFC Date: Fri, 15 Jun 2001 15:04:40 -0700 x-sender: cheshire@mail.apple.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Stuart Cheshire To: DHCPv4 discussion list Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Reply-To: cheshire@apple.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN >Bob, >The draft draft-aboba-dhc-domsearch-01.txt was submitted for this, but has >since expired. I don't believe there has been any renewed interest... > >Regards, >Greg There's *interest*. This is very useful, and we'd implement it in a moment at Apple just as soon as it gets an IANA option code. Unfortunately everyone involved is very busy, and I think the draft just languished. I'm resisting the temptation to offer to resurrect it myself because I have other obligations I need to catch up with before I take on more work. The Classless Static Route Option is another example of a useful feature just waiting for the ink to dry and the IANA option code to be assigned. Stuart Cheshire * Wizard Without Portfolio, Apple Computer * Chairman, IETF ZEROCONF * www.stuartcheshire.org From owner-dhcp-v4@bucknell.edu Fri Jun 15 19:13:22 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01525 for ; Fri, 15 Jun 2001 19:13:22 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f5FNAhL19040; Fri, 15 Jun 2001 19:10:43 -0400 (EDT) Received: from internaut.com ([64.38.134.99]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f5FNAUL09910 for ; Fri, 15 Jun 2001 19:10:30 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id QAA00677; Fri, 15 Jun 2001 16:04:50 -0700 (PDT) (envelope-from aboba@internaut.com) Date: Fri, 15 Jun 2001 16:04:50 -0700 (PDT) From: Bernard Aboba To: DHCPv4 discussion list cc: DHCPv4 discussion list Subject: RE: Suffix search order RFC In-Reply-To: <200106152204.PAA00539@scv1.apple.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: aboba@internaut.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN I've updated the draft and resubmitted it. Should be posted on the archive soon. On Fri, 15 Jun 2001, Stuart Cheshire wrote: > >Bob, > >The draft draft-aboba-dhc-domsearch-01.txt was submitted for this, but has > >since expired. I don't believe there has been any renewed interest... > > > >Regards, > >Greg > > There's *interest*. This is very useful, and we'd implement it in a > moment at Apple just as soon as it gets an IANA option code. > Unfortunately everyone involved is very busy, and I think the draft just > languished. > > I'm resisting the temptation to offer to resurrect it myself because I > have other obligations I need to catch up with before I take on more work. > > The Classless Static Route Option is another example of a useful feature > just waiting for the ink to dry and the IANA option code to be assigned. > > Stuart Cheshire > * Wizard Without Portfolio, Apple Computer > * Chairman, IETF ZEROCONF > * www.stuartcheshire.org > > From owner-dhcp-v6@bucknell.edu Tue Jun 19 13:26:51 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA27988; Tue, 19 Jun 2001 13:26:50 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f5JHQ9L07283; Tue, 19 Jun 2001 13:26:10 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f5JHQ7L09800; Tue, 19 Jun 2001 13:26:07 -0400 (EDT) Received: from rdroms-w2k.cisco.com (dhcp-161-44-149-121.cisco.com [161.44.149.121]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id NAA02897; Tue, 19 Jun 2001 13:25:48 -0400 (EDT) Message-Id: <4.3.2.7.2.20010619131635.00b38618@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 19 Jun 2001 13:24:50 -0400 To: DHCPv6 discussion list From: Ralph Droms Subject: Changes to mailing lists Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN I'm about to move the DHC WG mailing lists to the IETF mailing list service. This transition gives us a chance to think about the organization of the mailing lists. Why make a change? Well, there's some duplication of e-mail and (at least recently) not a lot of traffic on either list. For example, I send WG meeting announcements, minutes, (this message!), etc. to both lists. Here are three ways we could make the transition to the IETF mail service: * Merge dhcp-v4 and dhcp-v6 into one list * Create a dhcwg mailing list for all WG-related administrivia and technical conversation about DHCP RFCs and I-Ds, and a dhcpv6 mailing list focused on the DHCPv6 I-D * Leave the lists unchanged I'm bringing this issue to the mailing list to explore options and develop consensus about any changes to the mailing list as I move them to the IETF service. Please post all follow up e-mail to the dhcp-v4@bucknell.edu mailing *only*. - Ralph From owner-dhcp-v4@bucknell.edu Tue Jun 19 13:29:28 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA28048 for ; Tue, 19 Jun 2001 13:29:28 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f5JHQ9L13632; Tue, 19 Jun 2001 13:26:09 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f5JHQ7L09800; Tue, 19 Jun 2001 13:26:07 -0400 (EDT) Received: from rdroms-w2k.cisco.com (dhcp-161-44-149-121.cisco.com [161.44.149.121]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id NAA02897; Tue, 19 Jun 2001 13:25:48 -0400 (EDT) Message-Id: <4.3.2.7.2.20010619131635.00b38618@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 19 Jun 2001 13:24:50 -0400 To: DHCPv4 discussion list From: Ralph Droms Subject: Changes to mailing lists Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Reply-To: rdroms@cisco.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN I'm about to move the DHC WG mailing lists to the IETF mailing list service. This transition gives us a chance to think about the organization of the mailing lists. Why make a change? Well, there's some duplication of e-mail and (at least recently) not a lot of traffic on either list. For example, I send WG meeting announcements, minutes, (this message!), etc. to both lists. Here are three ways we could make the transition to the IETF mail service: * Merge dhcp-v4 and dhcp-v6 into one list * Create a dhcwg mailing list for all WG-related administrivia and technical conversation about DHCP RFCs and I-Ds, and a dhcpv6 mailing list focused on the DHCPv6 I-D * Leave the lists unchanged I'm bringing this issue to the mailing list to explore options and develop consensus about any changes to the mailing list as I move them to the IETF service. Please post all follow up e-mail to the dhcp-v4@bucknell.edu mailing *only*. - Ralph From owner-dhcp-v4@bucknell.edu Wed Jun 20 16:00:10 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA20557 for ; Wed, 20 Jun 2001 16:00:10 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f5KJtML01405; Wed, 20 Jun 2001 15:55:22 -0400 (EDT) Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f5KJtIL04657 for ; Wed, 20 Jun 2001 15:55:18 -0400 (EDT) Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id PAA24306; Wed, 20 Jun 2001 15:51:54 -0400 Received: from rotala.raleigh.ibm.com (root@rotala.raleigh.ibm.com [9.37.60.3]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id PAA24260; Wed, 20 Jun 2001 15:54:55 -0400 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.9.3/8.7/RTP-ral-1.0) with ESMTP id PAA16749; Wed, 20 Jun 2001 15:52:06 -0400 Message-Id: <200106201952.PAA16749@rotala.raleigh.ibm.com> To: DHCPv4 discussion list cc: DHCPv4 discussion list Subject: Re: Changes to mailing lists In-Reply-To: Message from Ralph Droms of "Tue, 19 Jun 2001 13:24:50 EDT." <4.3.2.7.2.20010619131635.00b38618@funnel.cisco.com> Date: Wed, 20 Jun 2001 15:52:06 -0400 From: Thomas Narten Reply-To: narten@raleigh.ibm.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN > Here are three ways we could make the transition to the IETF mail service: > * Merge dhcp-v4 and dhcp-v6 into one list Personally, I'd prefer a single list. I think there is value in having all the folks interested in DHCP in one place. There have been times when discussion on the v6 side of things could have used input from those familiar with DHCPv4, even if those folks weren't really following the v6 work very closely. > I'm bringing this issue to the mailing list to explore options and develop > consensus about any changes to the mailing list as I move them to the IETF > service. Please post all follow up e-mail to the dhcp-v4@bucknell.edu > mailing *only*. I hope that folks are sending Ralph private replies, because one of the hardest things for a WG chair is making decisions when no one responds to an explicit call for input. Thomas From owner-dhcp-v4@bucknell.edu Wed Jun 20 16:58:12 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA22554 for ; Wed, 20 Jun 2001 16:58:11 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f5KKtqL09170; Wed, 20 Jun 2001 16:55:52 -0400 (EDT) Received: from zcars0m9.ca.nortel.com (h157s242a129n47.user.nortelnetworks.com [47.129.242.157]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f5KKtcL14300 for ; Wed, 20 Jun 2001 16:55:38 -0400 (EDT) Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57]) by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f5KKt8026957 for ; Wed, 20 Jun 2001 16:55:09 -0400 (EDT) Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com; Wed, 20 Jun 2001 16:55:05 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 20 Jun 2001 16:55:08 -0400 Message-ID: <75C9A75D295AD31184E70008C79189D20874B334@zcard00b.ca.nortel.com> From: "Glenn Waters" To: DHCPv4 discussion list Subject: RE: Changes to mailing lists Date: Wed, 20 Jun 2001 16:55:05 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0F9CB.48B01330" X-Orig: Reply-To: gww@nortelnetworks.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN 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_01C0F9CB.48B01330 Content-Type: text/plain; charset="iso-8859-1" Thanks for the prompt Thomas. I like having the two lists so that I can separate v4 issues from v6 issues. I still subscribe to both lists but I filter them to separate mailboxes. In the end I could live with one list if that makes Ralph's job easier. Cheers, /gww -----Original Message----- From: Thomas Narten [mailto:narten@raleigh.ibm.com] Sent: Wednesday, June 20, 2001 3:52 PM To: DHCPv4 discussion list Cc: DHCPv4 discussion list Subject: Re: Changes to mailing lists > Here are three ways we could make the transition to the IETF mail service: > * Merge dhcp-v4 and dhcp-v6 into one list Personally, I'd prefer a single list. I think there is value in having all the folks interested in DHCP in one place. There have been times when discussion on the v6 side of things could have used input from those familiar with DHCPv4, even if those folks weren't really following the v6 work very closely. > I'm bringing this issue to the mailing list to explore options and develop > consensus about any changes to the mailing list as I move them to the IETF > service. Please post all follow up e-mail to the dhcp-v4@bucknell.edu > mailing *only*. I hope that folks are sending Ralph private replies, because one of the hardest things for a WG chair is making decisions when no one responds to an explicit call for input. Thomas ------_=_NextPart_001_01C0F9CB.48B01330 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Changes to mailing lists

Thanks for the prompt Thomas.

I like having the two lists so that I can separate v4 = issues from v6 issues. I still subscribe to both lists but I filter = them to separate mailboxes.

In the end I could live with one list if that makes = Ralph's job easier.

Cheers, /gww

-----Original Message-----
From: Thomas Narten [mailto:narten@raleigh.ibm.com= ]
Sent: Wednesday, June 20, 2001 3:52 PM
To: DHCPv4 discussion list
Cc: DHCPv4 discussion list
Subject: Re: Changes to mailing lists

> Here are three ways we could make the transition = to the IETF mail service:

> * Merge dhcp-v4 and dhcp-v6 into one list

Personally, I'd prefer a single list. I think there = is value in having
all the folks interested in DHCP in one place. There = have been times
when discussion on the v6  side of things could = have used input from
those familiar  with DHCPv4, even if those = folks weren't really
following the v6 work very closely.

> I'm bringing this issue to the mailing list to = explore options and develop
> consensus about any changes to the mailing list = as I move them to the IETF
> service.  Please post all follow up e-mail = to the dhcp-v4@bucknell.edu
> mailing *only*.

I hope that folks are sending Ralph private replies, = because one of
the hardest things for a WG chair is making = decisions when no one
responds to an explicit call for input.

Thomas

------_=_NextPart_001_01C0F9CB.48B01330-- From owner-dhcp-v4@bucknell.edu Wed Jun 20 17:19:49 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA23301 for ; Wed, 20 Jun 2001 17:19:48 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f5KLJ6L12080; Wed, 20 Jun 2001 17:19:06 -0400 (EDT) Received: from diablo.cisco.com (diablo.cisco.com [171.68.224.210]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f5KLIpL17716 for ; Wed, 20 Jun 2001 17:18:51 -0400 (EDT) Received: from JSCHNIZL-W2K.cisco.com (rtp-vpn-87.cisco.com [10.82.192.87]) by diablo.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id OAA25703 for ; Wed, 20 Jun 2001 14:18:34 -0700 (PDT) Message-Id: <4.3.2.7.2.20010620170455.00b8a818@diablo.cisco.com> X-Sender: jschnizl@diablo.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 20 Jun 2001 17:08:13 -0400 To: DHCPv4 discussion list From: John Schnizlein Subject: Re: Changes to mailing lists In-Reply-To: <200106201952.PAA16749@rotala.raleigh.ibm.com> References: <4.3.2.7.2.20010619131635.00b38618@funnel.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Reply-To: jschnizl@cisco.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN I would also prefer a single list. From my limited view, it seems traffic is manageable. ;-) John Normally don't send "me too" replies, but this one seemed licensed. At 03:52 PM 6/20/2001, Thomas Narten wrote: >Personally, I'd prefer a single list. ... >I hope that folks are sending Ralph private replies, because one of >the hardest things for a WG chair is making decisions when no one >responds to an explicit call for input. From owner-dhcp-v6@bucknell.edu Fri Jun 22 16:11:17 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA08161; Fri, 22 Jun 2001 16:11:16 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f5MKARL11439; Fri, 22 Jun 2001 16:10:27 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f5MKAOL02482 for ; Fri, 22 Jun 2001 16:10:24 -0400 (EDT) Received: from rdroms-w2k.cisco.com (sjc-vpn-531.cisco.com [10.21.66.19]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id QAA12676 for ; Fri, 22 Jun 2001 16:10:03 -0400 (EDT) Message-Id: <4.3.2.7.2.20010622152754.036b43f8@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 22 Jun 2001 15:36:59 -0400 To: DHCPv6 discussion list From: Ralph Droms Subject: Authentication for DHCPv6 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN I've completed the text for authentication in the DHCPv6 spec. I've excerpted the relevant sections from the draft and included the text below. Because authentication added a fair amount of new text, I'd like to start getting feedback on this text while I finish other revisions to the spec. So, I would appreciate your review and any comments you might have on this text. Those of you who have read the DHCPv4 authentication RFC will recognize much of this text. Watch the section numbers in the text below; I've elided sections not of interest to the authentication spec... - Ralph ===== 17. Authentication of DHCP messages Some network administrators may wish to provide authentication of the source and contents of DHCP messages. For example, clients may be subject to denial of service attacks through the use of bogus DHCP servers, or may simply be misconfigured due to unintentionally instantiated DHCP servers. Network administrators may wish to constrain the allocation of addresses to authorized hosts to avoid denial of service attacks in "hostile" environments where the network medium is not physically secured, such as wireless networks or college residence halls. Because of the risk of denial of service attacks against DHCP clients, the use of authentication is mandated in Reconfigure-init messages. A DHCP server MUST include an authentication option in Reconfigure-init messages sent to clients. The DHCP authentication mechanism is based on the design of authentication for DHCP for IPv4 [8]. 17.1. DHCP threat model The threat to DHCP is inherently an insider threat (assuming a properly configured network where DHCPv6 ports are blocked on the enterprise's perimeter gateways.) Regardless of the gateway configuration, however, the potential attacks by insiders and outsiders are the same. The attack specific to a DHCP client is the possibility of the establishment of a "rogue" server with the intent of providing incorrect configuration information to the client. The motivation for doing so may be to establish a "man in the middle" attack or it may be for a "denial of service" attack. There is another threat to DHCP clients from mistakenly or accidentally configured DHCP servers that answer DHCP client requests with unintentionally incorrect configuration parameters. The threat specific to a DHCP server is an invalid client masquerading as a valid client. The motivation for this may be for "theft of service", or to circumvent auditing for any number of nefarious purposes. The threat common to both the client and the server is the resource "denial of service" (DoS) attack. These attacks typically involve the exhaustion of valid addresses, or the exhaustion of CPU or network bandwidth, and are present anytime there is a shared resource. In current practice, redundancy mitigates DoS attacks the best. 17.2. Summary of DHCP authentication Authentication of DHCP messages is accomplished through the use of the Authentication option. The authentication information carried in the Authentication option can be used to reliably identify the source of a DHCP message and to confirm that the contents of the DHCP message have not been tampered with. The Authentication option provides a framework for multiple authentication protocols. Two such protocols are defined here. Other protocols defined in the future will be specified in separate documents. The protocol field in the Authentication option identifies the specific protocol used to generate the authentication information carried in the option. The algorithm field identifies a specific algorithm within the authentication protocol; for example, the algorithm field specifies the hash algorithm used to generate the message authentication code (MAC) in the authentication option. The replay detection method (RDM) field specifies the type of replay detection used in the replay detection field. 17.3. Replay detection The Replay Detection Method (RDM) field determines the type of replay detection used in the Replay Detection field. If the RDM field contains 0x00, the replay detection field MUST be set to the value of a monotonically increasing counter. Using a counter value such as the current time of day (e.g., an NTP-format timestamp [12]) can reduce the danger of replay attacks. This method MUST be supported by all protocols. 17.4. Configuration token protocol If the protocol field is 0, the authentication information field holds a simple configuration token. The configuration token is an opaque, unencoded value known to both the sender and receiver. The sender inserts the configuration token in the DHCP message and the receiver matches the token from the message to the shared token. If the configuration option is present and the token from the message does not match the shared token, the receiver MUST discard the message. Configuration token may be used to pass a plain-text configuration token and provides only weak entity authentication and no message authentication. This protocol is only useful for rudimentary protection against inadvertently instantiated DHCP servers. DISCUSSION: The intent here is to pass a constant, non-computed token such as a plain-text password. Other types of entity authentication using computed tokens such as Kerberos tickets or one-time passwords will be defined as separate protocols. 17.5. Delayed authentication protocol If the protocol field is 1, the message is using the "delayed authentication" mechanism. In delayed authentication, the client requests authentication in its Solicit message and the server replies with an Advertise message that includes authentication information. This authentication information contains a nonce value generated by the source as a message authentication code (MAC) to provide message authentication and entity authentication. The use of a particular technique based on the HMAC protocol [10] using the MD5 hash [18] is defined here. 17.5.1. Management issues in the delayed authentication protocol The "delayed authentication" protocol does not attempt to address situations where a client may roam from one administrative domain to another, i.e. interdomain roaming. This protocol is focused on solving the intradomain problem where the out-of-band exchange of a shared secret is feasible. 17.5.2. Use of the Authentication option in the delayed authentication protocol In a Solicit message, the Authentication option carries the Protocol, Algorithm, RDM and Replay detection fields, but no Authentication information. In an Advertise, Request, Renew, Rebind or Confirm message, the Authentication option carries the Protocol, Algorithm, RDM and Replay detection fields and Authentication information. The format of the Authentication information is: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Secret ID (32 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | HMAC-MD5 (128 bits) | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The following definitions will be used in the description of the authentication information for delayed authentication, algorithm 1: Replay Detection - as defined by the RDM field K - a secret value shared between the source and destination of the message; each secret has a unique identifier (secret ID) secret ID - the unique identifier for the secret value used to generate the MAC for this message HMAC-MD5 - the MAC generating function. The sender computes the MAC using the HMAC generation algorithm [10] and the MD5 hash function [18]. The entire DHCP message (except as noted below), including the DHCP message header and the options field, is used as input to the HMAC-MD5 computation function. The 'secret ID' field MUST be set to the identifier of the secret used to generate the MAC. DISCUSSION: Algorithm 1 specifies the use of HMAC-MD5. Use of a different technique, such as HMAC-SHA, will be specified as a separate protocol. Delayed authentication requires a shared secret key for each client on each DHCP server with which that client may wish to use the DHCP protocol. Each secret key has a unique identifier that can be used by a receiver to determine which secret was used to generate the MAC in the DHCP message. Therefore, delayed authentication may not scale well in an architecture in which a DHCP client connects to multiple administrative domains. 17.5.3. Message validation To validate an incoming message, the receiver first checks that the value in the replay detection field is acceptable according to the replay detection method specified by the RDM field. Next, the receiver computes the MAC as described in [10]. The receiver MUST set the 'MAC' field of the authentication option to all 0s for computation of the MAC, and because a DHCP relay agent may alter the values of the 'giaddr' and 'hops' fields in the DHCP message, the contents of those two fields MUST also be set to zero for the computation of the MAC. If the MAC computed by the receiver does not match the MAC contained in the authentication option, the receiver MUST discard the DHCP message. 17.5.4. Key utilization Each DHCP client has a key, K. The client uses its key to encode any messages it sends to the server and to authenticate and verify any messages it receives from the server. The client's key SHOULD be initially distributed to the client through some out-of-band mechanism, and SHOULD be stored locally on the client for use in all authenticated DHCP messages. Once the client has been given its key, it SHOULD use that key for all transactions even if the client's configuration changes; e.g., if the client is assigned a new network address. Each DHCP server MUST know, or be able to obtain in a secure manner, the keys for all authorized clients. If all clients use the same key, clients can perform both entity and message authentication for all messages received from servers. However, the sharing of keys is strongly discouraged as it allows for unauthorized clients to masquerade as authorized clients by obtaining a copy of the shared key. To authenticate the identity of individual clients, each client MUST be configured with a unique key. 17.5.5. Client considerations for delayed authentication protocol 17.5.5.1. Sending Solicit messages When the client sends a Solicit message and wishes to use authentication, it includes an Authentication option with the desired protocol, algorithm, RDM and replay detection field as described in section 17.5. The client does not include any authentication information in the Authentication option. 17.5.6. Receiving Advertise messages The client validates any Advertise messages containing an Authentication option specifying the delayed authentication protocol using the validation test described in section 17.5.3. Client behavior if no Advertise messages include authentication information or pass the validation test is controlled by local policy on the client. According to client policy, the client MAY choose to respond to a Advertise message that has not been authenticated. The decision to set local policy to accept unauthenticated messages should be made with care. Accepting an unauthenticated Advertise message can make the client vulnerable to spoofing and other attacks. If local users are not explicitly informed that the client has accepted an unauthenticated Advertise message, the users may incorrectly assume that the client has received an authenticated address and is not subject to DHCP attacks through unauthenticated messages. A client MUST be configurable to discard unauthenticated messages, and SHOULD be configured by default to discard unauthenticated messages. A client MAY choose to differentiate between Advertise messages with no authentication information and Advertise messages that do not pass the validation test; for example, a client might accept the former and discard the latter. If a client does accept an unauthenticated message, the client SHOULD inform any local users and SHOULD log the event. 17.5.6.1. Sending Request, Confirm, Renew, Rebind or Release messages If the client authenticated the Advertise message through which the client selected the server, the client MUST generate authentication information for subsequent Request, Confirm, Renew, Rebind or Release messages sent to the server as described in section 17.5. When the client sends a subsequent message, it MUST use the same secret used by the server to generate the authentication information. 17.5.6.2. Receiving Reply messages If the client authenticated the Advertise it accepted, the client MUST validate the associated Reply message from the server. The client MUST discard the Reply if the message fails to pass validation and MAY log the validation failure. If the Reply fails to pass validation, the client MUST restart the DHCP configuration process by sending a Solicit message. The client MAY choose to remember which server replied with a Reply message that failed to pass validation and discard subsequent messages from that server. If the client accepted an Advertise message that did not include authentication information or did not pass the validation test, the client MAY accept an unauthenticated Reply message from the server. 17.5.7. Server considerations for delayed authentication protocol 17.5.7.1. Receiving Solicit messages and Sending Advertise messages The server selects a secret for the client and includes authentication information in the Advertise message returned to the client as specified in section 17.5. The server MUST record the identifier of the secret selected for the client and use that same secret for validating subsequent messages with the client. 17.5.7.2. Receiving Request, Confirm, Renew, Rebind or Release messages and Sending Reply messages The server uses the secret identified in the message and validates the message as specified in section 17.5.3. If the message fails to pass validation or the server does not know the secret identified by the 'secret ID' field, the server MUST discard the message and MAY choose to log the validation failure. If the message passes the validation procedure, the server responds to the specific message as described in section 14.4. The server MUST include authentication information generated using the secret identified in the received message as specified in section 17.5. 17.5.7.3. Sending Reconfigure-Init messages The server MUST include authentication information in a Reconfigure-Init message, generated as specified in section 17.5 using the secret the server initially selected for the client to which the Reconfigure-Init message is to be sent. 18. DHCP options Options are used to carry additional information and parameters in DHCP messages. Every option shares a common base format, as described in section 18.1. This document describes the DHCP options defined as part of the base DHCP specification. Other options may be defined in the future in a separate document. 18.1. Format of DHCP options 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | option-code | option-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | option-data | | (option-len octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ option-code An unsigned integer identifying the specific option type carried in this option. option-len An unsigned integer giving the length of the data in this option in octets. option-data The data for the option; the format of this data depends on the definition of the option. 18.9. Authentication option The Authentication option carries authentication information to authenticate the identity and contents of DHCP messages. The use of the Authentication option is described in section 17. The format of the Authentication option is: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OPTION_AUTH | option-length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Protocol | Algorithm | RDM | Replay detect.| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Replay Detection (64 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Replay cont. | Auth. Info | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Authentication Information | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ option-code OPTION_AUTH (TBD) option-length Variable protocol The authentication protocol used in this authentication option algorithm The algorithm used in the authentication protocol RDM The replay detection method used in this authentication option Replay detection The replay detection information for the RDM Authentication information The authentication information, as specified by the protocol and algorithm used in this authentication option 24. IANA Considerations This document defines several new name spaces associated with DHCPv6 and DHCPv6 options. IANA is requested to manage the allocation of values from these name spaces. New values in each of these name spaces should be approved by the process of IETF Consensus [14]. 24.5. Authentication option Section 17 defines three new name spaces associated with the Authentication Option (section 18.9), which are to be created and maintained by IANA: Protocol, Algorithm and RDM. Initial values assigned from the Protocol name space are 0 (for the configuration token Protocol in section 17.4) and 1 (for the delayed authentication Protocol in section 17.5). Additional protocols may be defined in the future. The Algorithm name space is specific to individual Protocols. That is, each Protocol has its own Algorithm name space. The guidelines for assigning Algorithm name space values for a particular protocol should be specified along with the definition of a new Protocol. For the configuration token Protocol, the Algorithm field MUST be 0, as described in section 17.4. For the delayed authentication Protocol, the Algorithm value 1 is assigned to the HMAC-MD5 generating function as defined in section 17.5. Additional algorithms for the delayed authentication protocol may be defined in the future. The initial value of 0 from the RDM name space is assigned to the use of a monotonically increasing value as defined in section 17.3. Additional replay detection methods may be defined in the future. References [8] R. Droms and W. Arbaugh. Authentication for DHCP Messages. Internet Draft, Internet Engineering Task Force, January 2001. Work in progress. [10] H. Krawczyk, M. Bellare, and R. Canetti. HMAC: Keyed-Hashing for Message Authentication. Request for Comments (Informational) 2104, Internet Engineering Task Force, February 1997. [12] David L. Mills. Network Time Protocol (Version 3) Specification, Implementation. Request for Comments (Draft Standard) 1305, Internet Engineering Task Force, March 1992. [14] T. Narten and H. Alvestrand. Guidelines for Writing an IANA Considerations Section in RFCs. Request for Comments (Best Current Practice) 2434, Internet Engineering Task Force, October 1998. [18] R. Rivest. The MD5 Message-Digest Algorithm. Request for Comments (Informational) 1321, Internet Engineering Task Force, April 1992. From owner-dhcp-v6@bucknell.edu Fri Jun 22 16:11:54 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA08216; Fri, 22 Jun 2001 16:11:54 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f5MKBfL07281; Fri, 22 Jun 2001 16:11:41 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f5MKAPL14649 for ; Fri, 22 Jun 2001 16:10:25 -0400 (EDT) Received: from rdroms-w2k.cisco.com (sjc-vpn-531.cisco.com [10.21.66.19]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id QAA12681 for ; Fri, 22 Jun 2001 16:10:07 -0400 (EDT) Message-Id: <4.3.2.7.2.20010622154842.036b80b8@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 22 Jun 2001 15:54:45 -0400 To: DHCPv6 discussion list From: Ralph Droms Subject: Draft text for DUID and IAID Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Included below is draft text from the -19 rev of the DHCPv6 spec that describes the "DHCP unique identifier" (DUID) and the "identity association identifier" (IAID). I've explicitly separated the DUID from the IAID. We had been discussing generating an "IA identifier" as the combination of a client identifier and an interface index. Separating the two identifiers seemed cleaner to me. A binding is now identified by . The rules for selecting a DUID are still TBD. Please review and comment on this draft text. - Ralph ===== 6.2. DHCP Terminology Terminology specific to DHCP can be found below. binding A binding (or, client binding) is a group of server data records containing the server's information about the addresses in an IA and any other configuration information assigned to the client. A binding is indexed by the tuple . DUID A DHCP unique identifier for a client. DISCUSSION: Rules for choosing a DUID are TBD. Identity association (IA) A collection of addresses assigned to a client. Each IA has an associated IAID. An IA may have 0 or more addresses associated with it. Identity association identifier (IAID) An identifier for an IA, chosen by the client. Each IA has an IAID, which is chosen to be unique among all IAIDs for IAs belonging to that client. 11. DHCP unique identifier (DUID) Each DHCP client has a DUID. DHCP servers use DUIDs to identify clients for the selection of configuration parameters and in the association of IAs with clients. See section 18.2 for the representation of a DUID in a DHCP message. DISCUSSION: The syntax, rules for selecting and requirements for gloabl uniqueness in DUIDs are TBD. The DUID is carried in an option because it may be variable length and because it is not required in all DHCP options (e.g., messages sent by servers need not include a DUID). 12. Identity association An "identity-association" (IA) is a construct through which a server and a client can identify, group and manage IPv6 addresses. Each IA consists of an IAID and a list of associated IPv6 addresses (the list may be empty). A client associates an IA with one of its interfaces and uses the IA to obtain IPv6 addresses for that interface from a server. See section 18.3 for the representation of an IA in a DHCP message. 18. DHCP options Options are used to carry additional information and parameters in DHCP messages. Every option shares a common base format, as described in section 18.1. This document describes the DHCP options defined as part of the base DHCP specification. Other options may be defined in the future in a separate document. 18.1. Format of DHCP options 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | option-code | option-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | option-data | | (option-len octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ option-code An unsigned integer identifying the specific option type carried in this option. option-len An unsigned integer giving the length of the data in this option in octets. option-data The data for the option; the format of this data depends on the definition of the option. 18.2. DHCP unique identifier option The DHCP unique identifier option is used to carry a DUID. The format for the DUID is keyed to mark the type of identifier and is of variable length. The format of the DUID option is: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OPTION DUID | option-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DUID type | DUID len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DUID | . . . . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 18.3. Identity association option The identity association option is used to carry an identity association, the parameters associated with the IA and the addresses assigned to the IA. The format of the IA option is: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OPTION IA | option-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IAID (4 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | T1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | T2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IA status | num-addrs |T| addr status | prefix length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | IPv6 address | | (16 octets) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | preferred lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | valid lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |T| addr status | prefix length | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | IPv6 address | | (16 octets) | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | preferred lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | pref. lifetime (cont.) | valid lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | valid lifetime (cont.) |T| addr status | prefix length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | IPv6 address | | (16 octets) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ option-code OPTION_IA (1) option-len Variable; equal to 24 + num-addrs*26 IA ID The unique identifier for this IA; chosen by the client T1 The time at which the client contacts the server from which the addresses in the IA were obtained to extend the lifetimes of the addresses assigned to the IA. T2 The time at which the client contacts any available server to extend the lifetimes of the addresses assigned to the IA. T When set to 1, indicates that this address is a "temporary address" [?]; when set to 0, the address is not a temporary address. IA status Status of the IA in this option. num-addrs An unsigned integer giving the number of addresses carried in this IA option (MAY be zero). addr status Status of the addresses in this IA. prefix length Prefix length for this address. IPv6 address An IPv6 address assigned to this IA. preferred lifetime The preferred lifetime for the associated IPv6 address. valid lifetime The valid lifetime for the associated IPv6 address. The "IPv6 address", "preferred lifetime" and "valid lifetime" fields are repeated for each address in the IA option (as determined by the "num-addrs" field). Note that an IA has no explicit "lifetime" or "lease length" of its own. When the lifetimes of all of the addresses in an IA have expired, the IA can be considered as having expired. T1 and T2 are included to give servers explicit control over when a client recontacts the server about a specific IA. The 'T' bit identifies the associated address as a temporary address. If the server is configured to assign temporary addresses to the client, the server marks those temporary addresses with the 'T' bit. The number of temporary addresses assigned to the client and the lifetimes of those addresses is determined by the administrative configuration of the server. The 'T' bit only identifies an address as a temporary address; identification of an address as ``temporary'' has no implication on the lifetime of the extensibility of the lifetime of the address. From owner-dhcp-v6@bucknell.edu Fri Jun 22 16:11:58 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA08240; Fri, 22 Jun 2001 16:11:58 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f5MKBmL05130; Fri, 22 Jun 2001 16:11:48 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f5MKARL06162 for ; Fri, 22 Jun 2001 16:10:27 -0400 (EDT) Received: from rdroms-w2k.cisco.com (sjc-vpn-531.cisco.com [10.21.66.19]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id QAA12694 for ; Fri, 22 Jun 2001 16:10:10 -0400 (EDT) Message-Id: <4.3.2.7.2.20010622151615.00b55208@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 22 Jun 2001 15:57:06 -0400 To: DHCPv6 discussion list From: Ralph Droms Subject: Next rev of DHCP spec Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN I expect to publish the -19 rev of the DHCP spec by the end of the day next Monday, 6/24. I've posted excerpts from the new spec on Reconfigure-init, authentication and DUID/IAID. I will post a summary by the end of the afternoon of the other changes in the -19 draft. If you have any comments, please get them to me by noon EDT Mon, 6/25, for inclusion in the -19 rev. Earlier than noon Mon would *really* be appreciated if you have substantial comments... - Ralph From owner-dhcp-v6@bucknell.edu Fri Jun 22 16:12:11 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA08261; Fri, 22 Jun 2001 16:12:11 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f5MKBuL25493; Fri, 22 Jun 2001 16:11:56 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f5MKAUL31349; Fri, 22 Jun 2001 16:10:30 -0400 (EDT) Received: from rdroms-w2k.cisco.com (sjc-vpn-531.cisco.com [10.21.66.19]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id QAA12700; Fri, 22 Jun 2001 16:10:12 -0400 (EDT) Message-Id: <4.3.2.7.2.20010622151525.0367ed78@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 22 Jun 2001 16:01:11 -0400 To: DHCPv6 discussion list From: Ralph Droms Subject: DHC WG meetings in London Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN I'm working up the schedule for DHC WG meetings in London... I expect to send off the -19 rev of the DHCPv6 draft Monday evening (6/25). I *sincerely* hope that this draft will be ready for WG last call. Assuming that the DHCPv6 spec is ready for WG last call, we will have little DHCPv6 business to discuss in London. Accordingly, I plan to schedule one DHC WG session in London for both DHCPv4 and DHCPv6 business. If you have specific agenda items for the London WG meeting or specific schedulign constraints (other WG meetings to avoid, specific days you will not be in London), please let me know by Tuesday afternoon (6/26). - Ralph From owner-dhcp-v4@bucknell.edu Fri Jun 22 16:15:46 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA08404 for ; Fri, 22 Jun 2001 16:15:45 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f5MKAfL23399; Fri, 22 Jun 2001 16:10:43 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f5MKAUL31349; Fri, 22 Jun 2001 16:10:30 -0400 (EDT) Received: from rdroms-w2k.cisco.com (sjc-vpn-531.cisco.com [10.21.66.19]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id QAA12700; Fri, 22 Jun 2001 16:10:12 -0400 (EDT) Message-Id: <4.3.2.7.2.20010622151525.0367ed78@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 22 Jun 2001 16:01:11 -0400 To: DHCPv4 discussion list From: Ralph Droms Subject: DHC WG meetings in London Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Reply-To: rdroms@cisco.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN I'm working up the schedule for DHC WG meetings in London... I expect to send off the -19 rev of the DHCPv6 draft Monday evening (6/25). I *sincerely* hope that this draft will be ready for WG last call. Assuming that the DHCPv6 spec is ready for WG last call, we will have little DHCPv6 business to discuss in London. Accordingly, I plan to schedule one DHC WG session in London for both DHCPv4 and DHCPv6 business. If you have specific agenda items for the London WG meeting or specific schedulign constraints (other WG meetings to avoid, specific days you will not be in London), please let me know by Tuesday afternoon (6/26). - Ralph From owner-dhcp-v4@bucknell.edu Fri Jun 22 19:30:10 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA15061 for ; Fri, 22 Jun 2001 19:30:09 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f5MNQkL17337; Fri, 22 Jun 2001 19:26:46 -0400 (EDT) Received: from mail-out1.apple.com (mail-out1.apple.com [17.254.0.52]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f5MNQcL24689 for ; Fri, 22 Jun 2001 19:26:38 -0400 (EDT) Received: from apple.com (A17-129-100-225.apple.com [17.129.100.225]) by mail-out1.apple.com (8.9.3/8.9.3) with ESMTP id QAA25791 for ; Fri, 22 Jun 2001 16:26:37 -0700 (PDT) Received: from scv3.apple.com (scv3.apple.com) by apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Fri, 22 Jun 2001 16:26:37 -0700 Received: from [17.202.44.113] (chesh1.apple.com [17.202.44.113]) by scv3.apple.com (8.9.3/8.9.3) with SMTP id QAA06942 for ; Fri, 22 Jun 2001 16:26:36 -0700 (PDT) Message-Id: <200106222326.QAA06942@scv3.apple.com> Subject: Re: Changes to mailing lists Date: Fri, 22 Jun 2001 16:26:37 -0700 x-sender: cheshire@mail.apple.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Stuart Cheshire To: DHCPv4 discussion list Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Reply-To: cheshire@apple.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN >* Merge dhcp-v4 and dhcp-v6 into one list I'd vote for this. With the limited traffic each list gets, I can easily ignore topics I'm not interested in. Stuart Cheshire * Wizard Without Portfolio, Apple Computer * Chairman, IETF ZEROCONF * www.stuartcheshire.org From owner-dhcp-v4@bucknell.edu Mon Jun 25 18:23:12 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA28507 for ; Mon, 25 Jun 2001 18:23:11 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f5PMIrL24511; Mon, 25 Jun 2001 18:18:53 -0400 (EDT) Received: from robspc.join.com (IDENT:root@tycho-165-227-59-154.tychonet.com [165.227.59.154]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f5PMIZL29882 for ; Mon, 25 Jun 2001 18:18:37 -0400 (EDT) Received: from join.com (IDENT:robs@localhost [127.0.0.1]) by robspc.join.com (8.11.0/8.11.0) with ESMTP id f5PNKxd06194 for ; Mon, 25 Jun 2001 16:21:03 -0700 Sender: owner-dhcp-v4@bucknell.edu Message-ID: <3B37C75A.8C2D01BE@join.com> Date: Mon, 25 Jun 2001 16:20:58 -0700 From: Rob Stevens Organization: Join Systems X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-22 i586) X-Accept-Language: en MIME-Version: 1.0 To: DHCPv4 discussion list Subject: Source Port# for packets from BOOTP relay agent Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Reply-To: robs@join.com X-Sender: robs@robspc.join.com X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit I had always assumed this should be port 67 yet I must admit that in no RFC is this issue addressed. Anyone have any strong opinion/recollection about this? My interest is primarily to install filters on Cable Modems which would block traffic emanating from port67 and then, on the server, discard any packet which purports to have been relayed but which does not come from port67. However a certain WK router manufacturer has port68 as the source port, so this would defeat the scheme. Please note: I'm not talking about what port# DHCP servers should use as the destination port# when replying to relay agents. This *MUST* be port 67. From owner-dhcp-v4@bucknell.edu Mon Jun 25 22:36:26 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA04717 for ; Mon, 25 Jun 2001 22:36:26 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f5Q2XHL09912; Mon, 25 Jun 2001 22:33:19 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f5Q2XDL15614 for ; Mon, 25 Jun 2001 22:33:13 -0400 (EDT) Received: from grosse.bisbee.fugue.com (205-140-116-226.ip.theriver.com [205.140.116.226]) by toccata.fugue.com (8.11.3/8.6.11) with ESMTP id f5Q2TxZ26408; Mon, 25 Jun 2001 19:29:59 -0700 (PDT) Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.3/8.6.11) with ESMTP id f5Q2X6W00585; Mon, 25 Jun 2001 19:33:06 -0700 (MST) Message-Id: <200106260233.f5Q2X6W00585@grosse.bisbee.fugue.com> To: DHCPv4 discussion list cc: DHCPv4 discussion list Subject: Re: Source Port# for packets from BOOTP relay agent In-Reply-To: Message from Rob Stevens of "Mon, 25 Jun 2001 16:20:58 MST." <3B37C75A.8C2D01BE@join.com> Date: Mon, 25 Jun 2001 19:33:05 -0700 From: Ted Lemon Reply-To: mellon@nominum.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN It makes no sense for the relay agent to use port 68 as its source port, since it doesn't listen on port 68. So I would say that the right thing is to use port 67, but I don't see how this helps you with the router vendor that's doing it wrong. :'( _MelloN_ From owner-dhcp-v4@bucknell.edu Tue Jun 26 18:37:28 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA01537 for ; Tue, 26 Jun 2001 18:37:28 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f5QMY9L00485; Tue, 26 Jun 2001 18:34:09 -0400 (EDT) Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f5QMWbL06903 for ; Tue, 26 Jun 2001 18:32:37 -0400 (EDT) Received: from INET-PRV-MTA by prv-mail20.provo.novell.com with Novell_GroupWise; Tue, 26 Jun 2001 16:32:06 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.0 Date: Tue, 26 Jun 2001 16:32:24 -0600 From: "Mark Meredith" To: DHCPv4 discussion list Cc: "Vijay KN" , "Mark Hinckley" Subject: New draft on LDAP Schema for DHCP. Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=_114B1E76.36578F15" Reply-To: MMEREDIT@novell.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=_114B1E76.36578F15 Content-Type: multipart/alternative; boundary="=_114B1E76.35548C16" --=_114B1E76.35548C16 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable I have sent this to the internet-drafts but have not seen it come through, = so I thought I would post it here. =20 =20 Title: LDAP Schema for DHCP Author(s): M. Meredith et al. FileName: draft-ietf-dhc-ldap-schema-00.txt =20 This document defines a schema for representing DHCP configuration in an LDAP directory. It can be used to represent the DHCP Service configuration(s) for an entire enterprise network, a subset of the network, or even a single server. Representing DHCP configuration in an LDAP directory enables centralized management of DHCP services offered by one or more DHCP Servers within the enterprise. =20 -Mark =20 Mark Meredith Senior Software Engineer Novell Inc 1800 Novell Place, Provo UT 84606 mark_meredith@novell.com=20 801-861-2645 =20 Novell, Inc., the leading provider of Net service software www.novell.com=20 =20 --------------------- A boat in the harbor is safe,=20 but that is not what boats are for. --John A. Shed --------------------- --=_114B1E76.35548C16 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I have sent this to the internet-drafts but have not = seen it=20 come through, so I thought I would post it here.
 
 
        =20 Title:    LDAP Schema for=20 DHCP
         Author(s): M. = Meredith=20 et al.
         FileName: = =20 draft-ietf-dhc-ldap-schema-00.txt
      &n= bsp; =20
This document defines a schema for representing DHCP configuration = in=20 an
LDAP directory. It can be used to represent the DHCP=20 Service
configuration(s) for an entire enterprise network, a subset = of=20 the
network, or even a single server. Representing DHCP configuration = in=20 an
LDAP directory enables centralized management of DHCP services=20 offered
by one or more DHCP Servers within the=20 enterprise.
 
-Mark
 
Mark Meredith
Senior Software Engineer
Novell=20 Inc
1800 Novell Place, Provo UT 84606
mark_meredith@novell.com
80= 1-861-2645
 
Novell, Inc., the leading provider of Net service=20 software
www.novell.com
 
---------------------
A boat in the harbor is safe, =
but=20 that is not what boats are for.
--John A.=20 Shed
---------------------
--=_114B1E76.35548C16-- --=_114B1E76.36578F15 Content-Type: text/plain Content-Disposition: attachment; filename="draft-dhc-ldap-schema-00.txt" Network Working Group M. Meredith, Internet Draft V. Nanjundaswamy, Document: M. Hinckley Category: Proposed Standard Novell Inc. Expires: 15th December 2001 16th June 2001 LDAP Schema for DHCP Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [ ]. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet- Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsolete by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet- Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. 1. Abstract This document defines a schema for representing DHCP configuration in an LDAP directory. It can be used to represent the DHCP Service configuration(s) for an entire enterprise network, a subset of the network, or even a single server. Representing DHCP configuration in an LDAP directory enables centralized management of DHCP services offered by one or more DHCP Servers within the enterprise. 2. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [ ]. In places where different sets of terminology are commonly used to represent similar DHCP concepts, this schema uses the terminology of the Internet Software Consortium's DHCP server reference implementation. For more information see www.isc.org. 3. Design Considerations The DHCP LDAP schema is designed to be a simple multi-server schema. The M. Meredith et al. Expires December 2001 [Page 1] INTERNET-DRAFT LDAP Schema for DHCP 16 June 2001 intent of this schema is to provide a basic framework for representing the most common elements used in the configuration of DHCP Server. This should allow other network services to obtain and use basic DHCP configuration information in a server-independent but knowledgeable way. It is expected that some implementations may need to extend the schema objects, in order to implement all of their features or needs. It is recommended that you use the schema defined in this draft to represent DHCP configuration information in an LDAP directory. Conforming to a standard schema improves interoperability between DHCP implementations from different vendors. Some implementations may choose not to support all of the objects defined here. Two decisions are explicitly left up to each implementation: First, implementations may choose not to store the lease information in the directory, so those objects would not be used. Second, implementations may choose not to implement the auditing information. It is up to the implementation to determine if the data in the directory is considered "authoritative", or if it is simply a copy of data from an authoritative source. Validity of the information if used as a copy is to be ensured by the implementation. Primarily two types of applications will use the information in this schema: 1. DHCP servers (for loading their configuration) 2. Management Interfaces (for defining/editing configurations). The schema should be efficient for the needs of both types of applications. The schema is designed to allow objects managed by DHCP (such as computers, subnets, etc) to be present anywhere in a directory hierarchy (to allow those objects to be placed in the directory for managing administrative control and access to the objects). The schema uses a few naming conventions - all object classes and attributes are prefixed with "dhcp" to decrease the chance that object classes and attributes will have the same name. The schema also uses standard naming attributes ("cn", "ou", etc) for all objects. 4. Common DHCP Configuration Attributes Although DHCP manages several different types of objects, the configuration of those objects is often similar. Consequently, most of these objects have a common set of attributes, which are defined below. M. Meredith et al. Expires December 2001 [Page 2] INTERNET-DRAFT LDAP Schema for DHCP 16 June 2001 4.1. Attributes Definitions The schema definitions listed below are for readability. The LDIF layout for this schema will follow in section 8. Name: dhcpPrimaryDN Description: The Distinguished Name of the dhcpServer object, which is the primary server for the configuration. Syntax: DN Flags: SINGLE-VALUE Named: dhcpSecondaryDN Description: The Distinguished Name(s) of the dhcpServer object(s), which are secondary servers for the configuration. Syntax: DN Name: dhcpStatements Description: Flexible storage for representing any specific data depending on the object to which it is attached. Examples include conditional statements, Server parameters, etc. This also serves as a 'catch-all' attribute that allows the standard to evolve without needing to update the schema. Syntax: IA5String Name: dhcpRange Description: The starting and ending IP Addresses in the range (inclusive), separated by a hyphen; if the range only contains one address, then just the address can be specified with no hyphen. Each range is defined as a separate value. Syntax: IA5String Name: dhcpPermitList Description: This attribute contains the permit lists associated with a pool. Each permit list is defined as a separate value. Syntax: IA5String Name: dhcpNetMask Description: The subnet mask length for the subnet. The mask can be easily computed from this length. Syntax: Integer Flags: SINGLE-VALUE Name: dhcpOption Description: Encoded option values to be sent to clients. Each value represents a single option and contains (OptionTag, Length, OptionData) encoded in the format used by DHCP. For more information see [DHCPOPT]. Syntax: OctetString Name: dhcpClassData Description: Encoded text string or list of bytes expressed in hexadecimal, separated by colons. Clients match subclasses based on matching the class data with the results of a 'match' or 'spawn with' statement in the class name declarations. Syntax: IA5String Flags: SINGLE-VALUE Name: dhcpSubclassesDN Description: List of subclasses, these are the actual DN of each subclass object. Syntax: DN Name: dhcpClassesDN Description: List of classes, these are the actual DN of each class object. Syntax: DN M. Meredith et al. Expires December 2001 [Page 3] INTERNET-DRAFT LDAP Schema for DHCP 16 June 2001 Name: dhcpSubnetDN Description: List of subnets, these are the actual DN of each subnet object. Syntax: DN Name: dhcpPoolDN Description: List of pools, these are the actual DN of each Pool object. Syntax: DN Name: dhcpOptionsDN Description: List of options, these are the actual DN of each Options object. Syntax: DN Name: dhcpHostDN Description: List of hosts, these are the actual DN of each host object. Syntax: DN Name: dhcpSharedNetworkDN Description: List of shared networks, these are the actual DN of each shared network object. Syntax: DN Name: dhcpGroupDN Description: List of groups, these are the actual DN of each Group object. Syntax: DN Name: dhcpLeaseDN Description: Single Lease DN. A dhcpHost configuration uses this attribute to identify a static IP address assignment. Syntax: DN Flags: SINGLE-VALUE Name: dhcpLeasesDN Description: List of leases, these are the actual DN of each lease object. Syntax: DN Name: dhcpServiceDN Description: The DN of dhcpService object(s)which contain the configuration information. Each dhcpServer object has this attribute identifying the DHCP configuration(s) that the server is associated with. Syntax: DN Name: dhcpHWAddress Description: The hardware address of the client associated with a lease Syntax: OctetString Flags: SINGLE-VALUE Name: dhcpVersion Description: This is the version identified for the object that this attribute is part of. In case of the dhcpServer object, this represents the DHCP software version. Syntax: IA5String Flags: SINGLE-VALUE Name: dhcpImplementation Description: DHCP Server implementation description e.g. DHCP Vendor information. Syntax: IA5String Flags: SINGLE-VALUE Name: dhcpHashBucketAssignment Description: HashBucketAssignment bit map for the DHCP Server, as defined in DHC Load Balancing Algorithm [RFC 3074]. Syntax: Octet String Flags: SINGLE-VALUE Name: dhcpDelayedServiceParameter Description: Delay in seconds corresponding to Delayed Service Parameter configuration, as defined in M. Meredith et al. Expires December 2001 [Page 4] INTERNET-DRAFT LDAP Schema for DHCP 16 June 2001 DHC Load Balancing Algorithm [RFC 3074]. Syntax: Integer Flags: SINGLE- VALUE Name: dhcpMaxClientLeadTime Description: Maximum Client Lead Time configuration in seconds, as defined in DHCP Failover Protocol [FAILOVR] Syntax: Integer Flags: SINGLE-VALUE Name: dhcpFailOverEndpointState Description: Server (Failover Endpoint) state, as defined in DHCP Failover Protocol [FAILOVR] Syntax: IA5String Flags: SINGLE-VALUE 5. Configurations and Services The schema definitions below are for readability the LDIF layout for this schema will follow in section 8. The DHC working group is currently considering several proposals for fail-over and redundancy of DHCP servers. These may require sharing of configuration information between servers. This schema provides a generalized mechanism for supporting any of these proposals, by separating the definition of a server from the definition of configuration service provided by the server. Separating the DHCP Server (dhcpServer) and the DHCP Configuration (dhcpService) representations allows a configuration service to be provided by one or more servers. Similarly, a server may provide one or more configurations. The schema allows a server to be configured as either a primary or secondary provider of a DHCP configuration. Configurations are also defined so that one configuration can include some of the objects that are defined in another configuration. This allows for sharing and/or a hierarchy of related configuration items. Name: dhcpService Description: Service object that represents the actual DHCP Service configuration. This will be a container with the following attributes. Must: cn, dhcpPrimaryDN May: dhcpSecondaryDN, dhcpSharedNetworkDN, dhcpSubnetDN, dhcpGroupDN, dhcpHostDN, dhcpClassesDN, dhcpOptionsDN, dhcpStatements The following objects could exist inside the dhcpService container: dhcpSharedNetwork, dhcpSubnet, dhcpGroup, dhcpHost, dhcpClass, dhcpServer, dhcpOptions, dhcpLog Name: dhcpServer Description: Server object that the DHCP server will login as. The configuration information is in the dhcpService container that the dhcpServiceDN points to. Must: cn, dhcpServiceDN May: dhcpVersion, dhcpImplementation, dhcpHashBucketAssignment, dhcpDelayedServiceParameter, dhcpMaxClientLeadTime, M. Meredith et al. Expires December 2001 [Page 5] INTERNET-DRAFT LDAP Schema for DHCP 16 June 2001 dhcpFailOverEndpointState 5.1. DHCP Declaration related classes: Name: dhcpSharedNetwork Description: Shared Network class will list what pools and subnets are in this network. This will be a container with the following attributes. Must: cn May: dhcpSubnetDN, dhcpPoolDN, dhcpOptionsDN, dhcpStatements The following objects can exist within a dhcpSharedNetwork container: dhcpSubnet, dhcpPool, dhcpOptions, dhcpLog Name: dhcpSubnet Description: Subnet object will include configuration information associated with a subnet, including a range and a net mask. This will be a container with the following attributes. Must: cn (Subnet address), dhcpNetMask May: dhcpRange, dhcpPoolDN, dhcpGroupDN, dhcpHostDN, dhcpClassesDN, dhcpLeasesDN, dhcpOptionsDN, dhcpStatements The following objects can exist within a dhcpSubnet container: dhcpPool, dhcpGroup, dhcpHost, dhcpClass, dhcpOptions, dhcpLease, dhcpLog Name: dhcpGroup Description: Group object will have configuration information associated with a group. This will be a container with the following attributes. Must: cn May: dhcpHostDN, dhcpOptionsDN, dhcpStatements The following objects can exist within a dhcpGroup container: dhcpHost, dhcpOptions Name: dhcpHost Description: The host object includes DHCP host declarations to assign a static IP address or declare the client as known or specify statements for a specific client. Must: cn May: dhcpLeaseDN, dhcpHWAddress, dhcpOptionsDN, dhcpStatements Name: dhcpOptions Description: The options class is for option space declarations, it contains a list of options. Must: cn May: dhcpOption Name: dhcpClass Description: This is a class to group clients together based on matching rules. This will be a container with the following attributes. Must: cn May: dhcpSubClassesDN, dhcpOptionsDN, dhcpStatements The following object can exist within a dhcpClass container: dhcpSubclass, dhcpOptions M. Meredith et al. Expires December 2001 [Page 6] INTERNET-DRAFT LDAP Schema for DHCP 16 June 2001 Name: dhcpSubClass Description: This includes configuration information for a subclass associated with a class. The dhcpSubClass object will always be contained within the corresponding class container object. Must: cn May: dhcpClassData, dhcpOptionsDN, dhcpStatements Name: dhcpPool Description: This contains configuration for a pool that will have the range of addresses, permit lists and point to classes and leases that are members of this pool. This will be a container that could be contained by dhcpSubnet or a dhcpSharedNetwork. Must: cn, dhcpRange May: dhcpClassesDN, dhcpPermitList, dhcpLeasesDN, dhcpOptionsDN, dhcpStatements The following objects can exist within a dhcpPool container: dhcpClass, dhcpOptions, dhcpLease, dhcpLog 6. Tracking Address Assignments The behavior of a DHCP server is influenced by two factors - it's configuration and the current state of the addresses that have been assigned to clients. This schema defines a set of objects for representing the DHCP configuration associated with a server. The following object classes provide the ability to record how addresses are used including maintaining history (audit log) on individual leases. Recording lease information in a directory could result in a significant performance impact and is therefore optional. Implementations supporting logging of leases need to consider the performance impact. 6.1. dhcpLeases Attribute Definitions The schema definitions below are for readability the LDIF layout for this schema will follow in section 8. Name: dhcpAddressState Description: This stores information about the current binding-status of an address. For dynamic addresses managed by DHCP, the values should be restricted to the states defined in the DHCP Failover Protocol draft [FAILOVR]: 'FREE', 'ACTIVE', 'EXPIRED', 'RELEASED', 'RESET', 'ABANDONED', 'BACKUP'. For more information on these states see [FAILOVR]. For other addresses, it SHOULD be one of the following: 'UNKNOWN', 'RESERVED' (an address that is managed by DHCP that is reserved for a specific client), 'RESERVED-ACTIVE' (same as reserved, but address is currently in use), 'ASSIGNED' (assigned manually or by some other mechanism), 'UNASSIGNED', 'NOTASSIGNABLE'. Syntax: IA5String Flags: SINGLE-VALUE Name: dhcpExpirationTime Description: This is the time the current lease for an address expires. Syntax: DateTime Flags: SINGLE-VALUE M. Meredith et al. Expires December 2001 [Page 7] INTERNET-DRAFT LDAP Schema for DHCP 16 June 2001 Name: dhcpStartTimeOfState Description: This is the time of the last state change for a leased address. Syntax: DateTime Flags: SINGLE-VALUE Name: dhcpLastTransactionTime Description: This is the last time a valid DHCP packet was received from the client. Syntax: DateTime Flags: SINGLE-VALUE Name: dhcpBootpFlag Description: This indicates whether the address was assigned via BOOTP Syntax: Boolean Flags: SINGLE-VALUE Name: dhcpDomainName Description: This is the name of the domain sent to the client by the server. It is essentially the same as the value for DHCP option 15 sent to the client, and represents only the domain - not the full FQDN. To obtain the full FQDN assigned to the client you must prepend the "dhcpAssignedHostName" to this value with a ".". Syntax: IA5String Flags: SINGLE-VALUE Name: dhcpDnsStatus Description: This indicates the status of updating DNS resource records on behalf of the client by the DHCP server for this address. The value is a 16-bit bitmask that has the same values as specified by the Failover-DDNS option (see [FAILOVR]). Syntax: Integer Flags: SINGLE-VALUE Name: dhcpRequestedHostName Description: This is the hostname that was requested by the client. Syntax: IA5String Flags: SINGLE-VALUE Name: dhcpAssignedHostName Description: This is the actual hostname that was assigned to a client. It may not be the name that was requested by the client. The fully qualified domain name can be determined by appending the value of "dhcpDomainName" (with a dot separator) to this name. Syntax: IA5String Flags: SINGLE-VALUE Name: dhcpReservedForClient Description: This is the distinguished name of the "dhcpHost" that an address is reserved for. This may not be the same as the "dhcpAssignedToClient" attribute if the address is being reassigned but the current lease has not yet expired. Syntax: DN Flags: SINGLE-VALUE Name: dhcpAssignedToClient Description: This is the distinguished name of a "dhcpHost" that an address is currently assigned to. This attribute is only present in the class when the address is leased. Syntax: DN Flags: SINGLE-VALUE Name: dhcpRelayAgentInfo Description: If the client request was received via a relay agent, this contains information about the relay agent that was available from the DHCP request. This is a hex-encoded option value. Syntax: OctetString Flags: SINGLE-VALUE M. Meredith et al. Expires December 2001 [Page 8] INTERNET-DRAFT LDAP Schema for DHCP 16 June 2001 6.2. dhcpLeases Object Class This class represents an IP address. It may or may not be leaseable, and the object may exist even though a lease is not currently active for the associated IP address. It is recommended that all Lease objects for a single DHCP Service be centrally located within a single container. This ensures that the lease objects and the corresponding logs do not have to be relocated, when address ranges allocated to individual DHCP subnets and/or pools change. The schema definitions below are for readability the LDIF layout for this schema will follow in section 8. Name: dhcpLeases Description: This is the object that holds state information about an IP address. The cn (which is the IP address), and the current address-state are mandatory attributes. If the address is assigned then, some of the optional attributes will have valid data. Must: cn, dhcpAddressState May: dhcpExpirationTime, dhcpStartTimeOfState, dhcpLastTransactionTime, dhcpBootpFlag, dhcpDomainName, dhcpDnsStatus, dhcpRequestedHostName, dhcpAssignedHostName, dhcpReservedForClient, dhcpAssignedToClient, dhcpRelayAgentInfo, dhcpHWAddress 6.3 Audit Log Information A dhcpLog object is created whenever a lease is assigned or released. This object is intended to be created under the corresponding dhcpLeases container, or dhcpPool, dhcpSubnet, dhcpSharedNetwork or dhcpService containers. The log information under the dhcpLeases container would be for addresses matching that lease information. The log information in the other containers could be used for errors, i.e. when a pool or subnet is out our addresses or if a server is not able to assign any more addresses for a particular dhcpService. Name: dhcpLog Description: This is the object that holds past information about an IP address. The cn is the time/date stamp when the address was assigned or released, the address state at the time, if the address was assigned or released. Must: cn May: dhcpAddressState, dhcpExpirationTime, dhcpStartTimeOfState, dhcpLastTransactionTime, dhcpBootpFlag, dhcpDomainName, dhcpDnsStatus, dhcpRequestedHostName, dhcpAssignedHostName, dhcpReservedForClient, dhcpAssignedToClient, dhcpRelayAgentInfo, dhcpHWAddress M. Meredith et al. Expires December 2001 [Page 9] INTERNET-DRAFT LDAP Schema for DHCP 16 June 2001 7. Determining settings The dhcpStatements attribute is the key to DHC enhancements that may come along, and the different key words that a particular server implementation may use. This attribute can be used to hold conditional DHCP Statements and DHCP server parameters. Having a generic settings attribute that is just a string, allows this schema to be extensible and easy to configure. All of the attributes that end with DN are references to the class that precedes the DN e.g. the dhcpPrimaryDN and dhcpSecondaryDN attributes hold the Distinguished Names of the dhcpServer objects that are associated with the dhcpService object. 8. LDIF format for attributes and classes. # Attributes ( 2.16.840.1.113719.1.203.4.1 NAME 'dhcpPrimaryDN' DESC 'The DN of the dhcpServer which is the primary server for the configuration.' SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE ) ( 2.16.840.1.113719.1.203.4.2 NAME 'dhcpSecondaryDN' DESC 'The DN of dhcpServer(s) which provide backup service for the configuration.' SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 ) ( 2.16.840.1.113719.1.203.4.3 NAME 'dhcpStatements' DESC 'Flexible storage for specific data depending on what object this exists in. Like conditional statements, server parameters, etc. This allows the standard to evolve without needing to adjust the schema.' SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) ( 2.16.840.1.113719.1.203.4.4 NAME 'dhcpRange' DESC 'The starting & ending IP Addresses in the range (inclusive), separated by a hyphen; if the range only contains one address, then just the address can be specified with no hyphen. Each range is defined as a separate value.' SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) ( 2.16.840.1.113719.1.203.4.5 NAME 'dhcpPermitList' DESC 'This attribute contains the permit lists associated with a pool. Each permit list is defined as a separate value.' SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) ( 2.16.840.1.113719.1.203.4.6 NAME 'dhcpNetMask' DESC 'The subnet mask length for the subnet. The mask can be easily computed from this length.' SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE ) ( 2.16.840.1.113719.1.203.4.7 NAME 'dhcpOption' DESC 'Encoded option values to be sent to clients. Each value represents a single option and contains (OptionTag, Length, OptionValue) encoded in the format used by DHCP.' SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 ) M. Meredith et al. Expires December 2001 [Page 10] INTERNET-DRAFT LDAP Schema for DHCP 16 June 2001 ( 2.16.840.1.113719.1.203.4.8 NAME 'dhcpClassData' DESC 'Encoded text string or list of bytes expressed in hexadecimal, separated by colons. Clients match subclasses based on matching the class data with the results of match or spawn with statements in the class name declarations.' SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE ) ( 2.16.840.1.113719.1.203.4.9 NAME 'dhcpOptionsDN' DESC 'The distinguished name(s) of the dhcpOption objects containing the configuration options provided by the server.' SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 ) ( 2.16.840.1.113719.1.203.4.10 NAME 'dhcpHostDN' DESC 'the distinguished name(s) of the dhcpHost objects.' SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 ) ( 2.16.840.1.113719.1.203.4.11 NAME 'dhcpPoolDN' DESC 'The distinguished name(s) of pools.' SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 ) ( 2.16.840.1.113719.1.203.4.12 NAME 'dhcpGroupDN' DESC 'The distinguished name(s) of the groups.' SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 ) ( 2.16.840.1.113719.1.203.4.13 NAME 'dhcpSubnetDN' DESC 'The distinguished name(s) of the subnets.' SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 ) ( 2.16.840.1.113719.1.203.4.14 NAME 'dhcpLeaseDN' DESC 'The distinguished name of a client address.' SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE) ( 2.16.840.1.113719.1.203.4.15 NAME 'dhcpLeasesDN' DESC 'The distinguished name(s) client addresses.' SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 ) ( 2.16.840.1.113719.1.203.4.16 NAME 'dhcpClassesDN' DESC 'The distinguished name(s) of a class(es) in a subclass.' SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 ) ( 2.16.840.1.113719.1.203.4.17 NAME 'dhcpSubclassesDN' DESC 'The distinguished name(s) of subclass(es).' SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 ) ( 2.16.840.1.113719.1.203.4.18 NAME 'dhcpSharedNetworkDN' DESC 'The distinguished name(s) of sharedNetworks.' SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 ) ( 2.16.840.1.113719.1.203.4.19 NAME 'dhcpServiceDN' DESC 'The DN of dhcpService object(s)which contain the configuration information. Each dhcpServer object has this attribute identifying the DHCP M. Meredith et al. Expires December 2001 [Page 11] INTERNET-DRAFT LDAP Schema for DHCP 16 June 2001 configuration(s) that the server is associated with.' SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 ) ( 2.16.840.1.113719.1.203.4.20 NAME 'dhcpVersion' DESC 'The version attribute of this object.' SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE- VALUE ) ( 2.16.840.1.113719.1.203.4.21 NAME 'dhcpImplementation' DESC 'Description of the DHCP Server implementation e.g. DHCP Server's vendor.' SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE ) ( 2.16.840.1.113719.1.203.4.22 NAME 'dhcpAddressState' DESC 'This stores information about the current binding-status of an address. For dynamic addresses managed by DHCP, the values should be restricted to the following: "FREE", "ACTIVE", "EXPIRED", "RELEASED", "RESET", "ABANDONED", "BACKUP". For other addresses, it SHOULD be one of the following: "UNKNOWN", "RESERVED" (an address that is managed by DHCP that is reserved for a specific client), "RESERVED-ACTIVE" (same as reserved, but address is currently in use), "ASSIGNED" (assigned manually or by some other mechanism), "UNASSIGNED", "NOTASSIGNABLE".' SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE ) ( 2.16.840.1.113719.1.203.4.23 NAME 'dhcpExpirationTime' DESC 'This is the time the current lease for an address expires.' SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE ) ( 2.16.840.1.113719.1.203.4.24 NAME 'dhcpStartTimeOfState' DESC 'This is the time of the last state change for a leased address.' SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE ) ( 2.16.840.1.113719.1.203.4.25 NAME 'dhcpLastTransactionTime' DESC 'This is the last time a valid DHCP packet was received from the client.' SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE ) ( 2.16.840.1.113719.1.203.4.26 NAME 'dhcpBootpFlag' DESC 'This indicates whether the address was assigned via BOOTP.' SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 SINGLE-VALUE ) ( 2.16.840.1.113719.1.203.4.27 NAME 'dhcpDomainName' DESC 'This is the name of the domain sent to the client by the server. It is essentially the same as the value for DHCP option 15 sent to the client, and represents only the domain - not the full FQDN. To obtain the full FQDN assigned to the client you must prepend the "dhcpAssignedHostName" to this value with a ".".' SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE- VALUE ) ( 2.16.840.1.113719.1.203.4.28 NAME 'dhcpDnsStatus' DESC 'This indicates the status of updating DNS resource records on behalf of the client by M. Meredith et al. Expires December 2001 [Page 12] INTERNET-DRAFT LDAP Schema for DHCP 16 June 2001 the DHCP server for this address. The value is a 16-bit bitmask.' SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE ) ( 2.16.840.1.113719.1.203.4.29 NAME 'dhcpRequestedHostName' DESC 'This is the hostname that was requested by the client.' SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE ) ( 2.16.840.1.113719.1.203.4.30 NAME 'dhcpAssignedHostName' DESC 'This is the actual hostname that was assigned to a client. It may not be the name that was requested by the client. The fully qualified domain name can be determined by appending the value of "dhcpDomainName" (with a dot separator) to this name.' SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE- VALUE ) ( 2.16.840.1.113719.1.203.4.31 NAME 'dhcpReservedForClient' DESC 'The distinguished name of a "dhcpClient" that an address is reserved for. This may not be the same as the "dhcpAssignedToClient" attribute if the address is being reassigned but the current lease has not yet expired.' SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE ) ( 2.16.840.1.113719.1.203.4.32 NAME 'dhcpAssignedToClient' DESC 'This is the distinguished name of a "dhcpClient" that an address is currently assigned to. This attribute is only present in the class when the address is leased.' SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE ) ( 2.16.840.1.113719.1.203.4.33 NAME 'dhcpRelayAgentInfo' DESC 'If the client request was received via a relay agent, this contains information about the relay agent that was available from the DHCP request. This is a hex-encoded option value.' SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 SINGLE-VALUE ) ( 2.16.840.1.113719.1.203.4.34 NAME 'dhcpHWAddress' DESC 'The clients hardware address that requested this IP address.' SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 SINGLE-VALUE ) ( 2.16.840.1.113719.1.203.4.35 NAME 'dhcpHashBucketAssignment' DESC 'HashBucketAssignment bit map for the DHCP Server, as defined in DHC Load Balancing Algorithm [RFC 3074].' SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 SINGLE-VALUE ) ( 2.16.840.1.113719.1.203.4.36 NAME 'dhcpDelayedServiceParameter' DESC 'Delay in seconds corresponding to Delayed Service Parameter configuration, as defined in DHC Load Balancing Algorithm [RFC 3074]. ' SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE ) ( 2.16.840.1.113719.1.203.4.37 NAME 'dhcpMaxClientLeadTime' DESC 'Maximum Client Lead Time configuration in seconds, as defined in DHCP Failover Protocol [FAILOVR]' SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 M. Meredith et al. Expires December 2001 [Page 13] INTERNET-DRAFT LDAP Schema for DHCP 16 June 2001 SINGLE-VALUE ) ( 2.16.840.1.113719.1.203.4.38 NAME 'dhcpFailOverEndpointState' DESC 'Server (Failover Endpoint) state, as defined in DHCP Failover Protocol [FAILOVR]' SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE ) #Classes ( 2.16.840.1.113719.1.203.6.1 NAME 'dhcpService' DESC ' Service object that represents the actual DHCP Service configuration. This is a container object.' SUP top MUST (cn $ dhcpPrimaryDN) MAY (dhcpSecondaryDN $ dhcpSharedNetworkDN $ dhcpSubnetDN $ dhcpGroupDN $ dhcpHostDN $ dhcpClassesDN $ dhcpOptionsDN $ dhcpStatements ) ) ( 2.16.840.1.113719.1.203.6.2 NAME 'dhcpSharedNetwork' DESC 'This stores configuration information for a shared network.' SUP top MUST cn MAY (dhcpSubnetDN $ dhcpPoolDN $ dhcpOptionsDN $ dhcpStatements) X- NDS_CONTAINMENT ('dhcpService' ) ) ( 2.16.840.1.113719.1.203.6.3 NAME 'dhcpSubnet' DESC 'This class defines a subnet. This is a container object.' SUP top MUST ( cn $ dhcpNetMask ) MAY (dhcpRange $ dhcpPoolDN $ dhcpGroupDN $ dhcpHostDN $ dhcpClassesDN $ dhcpLeasesDN $ dhcpOptionsDN $ dhcpStatements) X-NDS_CONTAINMENT ('dhcpService' ) ) ( 2.16.840.1.113719.1.203.6.4 NAME 'dhcpPool' DESC 'This stores configuration information about a pool.' SUP top MUST ( cn $ dhcpRange ) MAY (dhcpClassesDN $ dhcpPermitList $ dhcpLeasesDN $ dhcpOptionsDN $ dhcpStatements) X-NDS_CONTAINMENT ('dhcpSubnet' 'dhcpSharedNetwork') ) ( 2.16.840.1.113719.1.203.6.5 NAME 'dhcpGroup' DESC 'Group object that lists host DNs and parameters. This is a container object.' SUP top MUST cn MAY ( dhcpHostDN $ dhcpOptionsDN $ dhcpStatements ) X-NDS_CONTAINMENT ('dhcpSubnet' 'dhcpService' ) ) ( 2.16.840.1.113719.1.203.6.6 NAME 'dhcpHost' DESC 'This represents information about a particular client' SUP top MUST cn MAY (dhcpLeaseDN $ dhcpHWAddress $ dhcpOptionsDN $ dhcpStatements) X-NDS_CONTAINMENT ('dhcpService' 'dhcpSubnet' 'dhcpGroup') ) ( 2.16.840.1.113719.1.203.6.7 NAME 'dhcpClass' DESC 'Represents information about a collection of related clients.' SUP top MUST cn MAY (dhcpSubClassesDN $ dhcpOptionsDN $ dhcpStatements) X-NDS_CONTAINMENT ('dhcpService' 'dhcpSubnet' ) ) ( 2.16.840.1.113719.1.203.6.8 NAME 'dhcpSubClass' DESC 'Represents information about a collection of related classes.' SUP top MUST cn MAY (dhcpClassData $ dhcpOptionsDN $ dhcpStatements) X-NDS_CONTAINMENT M. Meredith et al. Expires December 2001 [Page 14] INTERNET-DRAFT LDAP Schema for DHCP 16 June 2001 'dhcpClass' ) ( 2.16.840.1.113719.1.203.6.9 NAME 'dhcpOptions' DESC 'Represents information about a collection of options defined.' SUP top MUST cn MAY ( dhcpOption ) X-NDS_CONTAINMENT ('dhcpService' 'dhcpSharedNetwork' 'dhcpSubnet' 'dhcpPool' 'dhcpGroup' 'dhcpHost' 'dhcpClass' ) ( 2.16.840.1.113719.1.203.6.10 NAME 'dhcpLeases' DESC 'This class represents an IP Address, which may or may not have been leased.' SUP top MUST ( cn $ dhcpAddressState ) MAY ( dhcpExpirationTime $ dhcpStartTimeOfState $ dhcpLastTransactionTime $ dhcpBootpFlag $ dhcpDomainName $ dhcpDnsStatus $ dhcpRequestedHostName $ dhcpAssignedHostName $ dhcpReservedForClient $ dhcpAssignedToClient $ dhcpRelayAgentInfo $ dhcpHWAddress ) X-NDS_CONTAINMENT ( 'dhcpService' 'dhcpSubnet' 'dhcpPool') ) ( 2.16.840.1.113719.1.203.6.11 NAME 'dhcpLog' DESC 'This is the object that holds past information about the IP address. The cn is the time/date stamp when the address was assigned or released, the address state at the time, if the address was assigned or released.' SUP top MUST ( cn ) MAY ( dhcpAddressState $ dhcpExpirationTime $ dhcpStartTimeOfState $ dhcpLastTransactionTime $ dhcpBootpFlag $ dhcpDomainName $ dhcpDnsStatus $ dhcpRequestedHostName $ dhcpAssignedHostName $ dhcpReservedForClient $ dhcpAssignedToClient $ dhcpRelayAgentInfo $ dhcpHWAddress ) X-NDS_CONTAINMENT ('dhcpLeases' 'dhcpPool' 'dhcpSubnet' 'dhcpSharedNetwork' 'dhcpService' ) ) ( 2.16.840.1.113719.1.203.6.12 NAME 'dhcpServer' DESC 'DHCP Server Object' SUP top MUST (cn, dhcpServiceDN) MAY (dhcpVersion $ dhcpImplementation $ dhcpHashBucketAssignment $ dhcpDelayedServiceParameter $ dhcpMaxClientLeadTime $ dhcpFailOverEndpointState) X-NDS_CONTAINMENT 'dhcpService' ) 9. Security Considerations Since the DHCP Configuration information is stored in a directory, the security of the information is limited to the security offered by the directory including the security of the objects within that directory. 10. Intellectual Property Rights Notices The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards- M. Meredith et al. Expires December 2001 [Page 15] INTERNET-DRAFT LDAP Schema for DHCP 16 June 2001 related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. 11. Full Copyright Statement Copyright (C) The Internet Society (2001). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 12. References [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997. [RFC2132] Alexander, S., Droms, R., "DHCP Options and BOOTP Vendor Extensions", RFC 2132, March 1997. M. Meredith et al. Expires December 2001 [Page 16] INTERNET-DRAFT LDAP Schema for DHCP 16 June 2001 [MSDHCP] Gu, Y., Vyaghrapuri, R., "An LDAP Schema for Dynamic Host Configuration Protocol Service", Internet Draft , August 1998. [NOVDHCP] Miller, T., Patel, A., Rao, P., "Lightweight Directory Access Protocol (v3): Schema for Dynamic Host Configuration Protocol (DHCP)", Internet Draft , June 1998. [FAILOVR] Droms, R., Rabil, G., Dooley, M., Kapur, A., Gonczi, S., Volz, B., "DHCP Failover Protocol", Internet Draft , July 2000. [RFC 3074] Volz B., Gonczi S., Lemon T., Stevens R., "DHC Load Balancing Algorithm", February 2001 [AGENT] Patrick, M., "DHCP Relay Agent Information Option", Internet Draft , March 2000. [DHCPOPT] Carney, M., "New Option Review Guidelines and Additional Option Namespace", Internet Draft , October 1999. [POLICY] Strassner, J., Elleson, E., Moore, B., "Policy Framework LDAP Core Schema", Internet Draft , November 1999. [RFC2251] Wahl, M., Howes, T., Kille, S., "Lightweight Directory Access Protocol (v3)", RFC 2251, December 1997. [RFC2252] Wahl, M., Coulbeck, A., Howes, T., Kille, S., "Lightweight Directory Access Protocol (v3) Attribute Syntax Definitions", RFC 2252, December 1997. [RFC2255] Howes, T., Smith, M., "The LDAP URL Format", RFC 2255, December 1997. [RFC951] Croft, B., Gilmore, J., "Bootstrap Protocol (BOOTP)", RFC 951, September 1985. [RFC2119] Bradner, S. "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. 13. Acknowledgments This work is partially based on a previous draft draft-ietf-dhc- schema-02.doc. M. Meredith et al. Expires December 2001 [Page 17] INTERNET-DRAFT LDAP Schema for DHCP 16 June 2001 14. Author's Addresses Comments regarding this draft may be sent to the authors at the following address: Mark Meredith Mark Hinckley Novell Inc. 1800 S. Novell Place Provo, Utah 84606 Vijay K. Nanjundaswamy Novell Software Development (I) Ltd 49/1 & 49/3, Garvebhavi Palya, 7th Mile, Hosur Road Bangalore 560068 email: mark_meredith@novell.com email: knvijay@novell.com email: mhinckley@novell.com This Internet Draft expires December 16, 2001. M. Meredith et al. Expires December 2001 [Page 18] --=_114B1E76.36578F15-- From owner-dhcp-v4@bucknell.edu Thu Jun 28 07:17:20 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA11431 for ; Thu, 28 Jun 2001 07:17:19 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f5SBE5L24547; Thu, 28 Jun 2001 07:14:05 -0400 (EDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f5SBDuL08425 for ; Thu, 28 Jun 2001 07:13:58 -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 HAA10593; Thu, 28 Jun 2001 07:13:15 -0400 (EDT) Message-Id: <200106281113.HAA10593@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: DHCPv4 discussion list Cc: dhcp-v4@bucknell.edu From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dhc-dhcpv6-19.txt Date: Thu, 28 Jun 2001 07:13:14 -0400 Sender: owner-dhcp-v4@bucknell.edu X-Sender: nsyracus@cnri.reston.va.us X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN --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-19.txt Pages : 69 Date : 27-Jun-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-19.txt 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-19.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-19.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: <20010627132240.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-dhcpv6-19.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-dhcpv6-19.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010627132240.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-dhcp-v4@bucknell.edu Thu Jun 28 17:59:31 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA14039 for ; Thu, 28 Jun 2001 17:59:31 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f5SLuDL08358; Thu, 28 Jun 2001 17:56:13 -0400 (EDT) Received: from firewall.ma.virata.com (agranat.com [198.113.147.2]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f5SLuCL22281 for ; Thu, 28 Jun 2001 17:56:12 -0400 (EDT) Received: from agranat.com (IDENT:root@alice.agranat.com [10.21.0.130]) by firewall.ma.virata.com (8.9.0/8.9.0) with ESMTP id RAA11861 for ; Thu, 28 Jun 2001 17:55:57 -0400 Received: from dhcp75.ma.virata.com (dhcp75.ma.virata.com [10.21.0.75]) by agranat.com (8.9.3/8.9.3) with ESMTP id RAA14892 for ; Thu, 28 Jun 2001 17:55:56 -0400 Received: (from worley@localhost) by dhcp75.ma.virata.com (8.11.0/8.11.0) id f5SLttE00879; Thu, 28 Jun 2001 17:55:55 -0400 Date: Thu, 28 Jun 2001 17:55:55 -0400 Message-Id: <200106282155.f5SLttE00879@dhcp75.ma.virata.com> X-Authentication-Warning: dhcp75.ma.virata.com: worley set sender to dworley@virata.com using -f From: worley@agranat.com To: DHCPv4 discussion list In-reply-to: <200106260233.f5Q2X6W00585@grosse.bisbee.fugue.com> (message from Ted Lemon on Mon, 25 Jun 2001 19:33:05 -0700) Subject: Re: Source Port# for packets from BOOTP relay agent Reply-To: worley@agranat.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN From: Ted Lemon It makes no sense for the relay agent to use port 68 as its source port, since it doesn't listen on port 68. So I would say that the right thing is to use port 67, but I don't see how this helps you with the router vendor that's doing it wrong. :'( Maybe it *is* listening on port 68, using it in a non-standard way. That's icky, yes, but is it a violation of the protocol? Dale -- Dale R. WORLEY Project Manager - UPnP Virata Corp. Applications Infrastructure http://emweb.com From owner-dhcp-v4@bucknell.edu Thu Jun 28 21:38:37 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA15957 for ; Thu, 28 Jun 2001 21:38:36 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f5T1ZtL05423; Thu, 28 Jun 2001 21:35:55 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f5T1ZdL31958 for ; Thu, 28 Jun 2001 21:35:39 -0400 (EDT) Received: from mirtagpa.fugue.com (205-140-116-229.ip.theriver.com [205.140.116.229]) by toccata.fugue.com (8.11.3/8.6.11) with ESMTP id f5T1WEZ03103; Thu, 28 Jun 2001 18:32:14 -0700 (PDT) Received: from mirtagpa.fugue.com (localhost [127.0.0.1]) by mirtagpa.fugue.com (8.11.3/8.6.11) with ESMTP id f5T1aia14901; Thu, 28 Jun 2001 18:36:44 -0700 (MST) Message-Id: <200106290136.f5T1aia14901@mirtagpa.fugue.com> To: DHCPv4 discussion list cc: DHCPv4 discussion list Subject: Re: Source Port# for packets from BOOTP relay agent In-Reply-To: Message from worley@agranat.com of "Thu, 28 Jun 2001 17:55:55 -0400." <200106282155.f5SLttE00879@dhcp75.ma.virata.com> Date: Thu, 28 Jun 2001 18:36:44 -0700 From: Ted Lemon Reply-To: mellon@nominum.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN > Maybe it *is* listening on port 68, using it in a non-standard way. Sure. But it won't hear anything from a DHCP client on port 68. The DHCP client sends its packets to port 67. So it *must* listen on port 67. If it also listens on port 68, that has nothing to do with what the DHCP protocol specification requires. I can easily imagine a bridge that listens on port 68 and intercepts packets on that port, but that's a hack, and someone who is doing a hack like that should be doing their best to ensure that the thing doesn't give away its presence by behaving in ways that aren't apparently in accordance with the behaviour the protocol specificion calls for. _MelloN_ From owner-dhcp-v4@bucknell.edu Fri Jun 29 01:37:13 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA04172 for ; Fri, 29 Jun 2001 01:37:12 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f5T5YGL20898; Fri, 29 Jun 2001 01:34:16 -0400 (EDT) Received: from robspc.join.com (IDENT:root@tycho-165-227-59-154.tychonet.com [165.227.59.154]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f5T5YDL15633 for ; Fri, 29 Jun 2001 01:34:13 -0400 (EDT) Received: from join.com (IDENT:robs@localhost [127.0.0.1]) by robspc.join.com (8.11.0/8.11.0) with ESMTP id f5T6aWN08783 for ; Thu, 28 Jun 2001 23:36:40 -0700 Sender: owner-dhcp-v4@bucknell.edu Message-ID: <3B3C21EE.EC7B01E3@join.com> Date: Thu, 28 Jun 2001 23:36:30 -0700 From: Rob Stevens Organization: Join Systems X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-22 i586) X-Accept-Language: en MIME-Version: 1.0 CC: DHCPv4 discussion list Subject: Re: Source Port# for packets from BOOTP relay agent References: <200106282155.f5SLttE00879@dhcp75.ma.virata.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Reply-To: robs@join.com X-Sender: robs@robspc.join.com To: DHCPv4 discussion list X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit worley@agranat.com wrote: > .. > > Maybe it *is* listening on port 68, using it in a non-standard way. > That's icky, yes, but is it a violation of the protocol? No, it doesn't appear to be. I was mildly surprised that it wasn't. It's a nuisance though, and as Ted says is rather nonsensical, because it's one more filtering strategy that is now rendered invalid. > > > Dale > -- > Dale R. WORLEY Project Manager - UPnP > Virata Corp. Applications Infrastructure http://emweb.com