From dhcp-v4@bucknell.edu Sun Jan 3 08:25:00 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.7.249]) by ietf.org (8.8.5/8.8.7a) with ESMTP id IAA01760 for ; Sun, 3 Jan 1999 08:24:59 -0500 (EST) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.8.8/8.8.8) with SMTP id IAA19605; Sun, 3 Jan 1999 08:22:45 -0500 (EST) Date: Sun, 3 Jan 1999 08:22:45 -0500 (EST) Message-Id: Errors-To: droms@bucknell.edu Reply-To: droms@bucknell.edu Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Ralph Droms To: Multiple recipients of list Subject: Minutes from Orlando WG meetings X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Type: text/plain; charset="us-ascii" Mime-Version: 1.0 Here are the revised minutes, based on comments received on the draft minutes I posted a couple of weeks ago. Changes are indicated with <>. - Ralph ===== The DHC WG met twice in Orlando. The first meeting was a one hour meeting in which the failover protocol was discussed. The second meeting was used for discussion of general DHCP issues. The failover meeting included a ten minute overview of the protocol, ten minutes of collecting questions and the remainder of the meeting addressed the collected questions. Kim Kinnear (cisco) presented an overview of the current protocol draft spec, the protocol status and recent developments. The draft is progressing and identified problems are being hammered out. There are two implementations (which are not yet interoperable). The draft authors feel that there is not widespread understanding of the current draft. Bernie Volz (Process Software) gave a brief review of the RUTS BOF meeting (which is addressing the issue of internet protocol). After the overview, a list of questions were collected. The list has been posted to the dhcp-serve@bucknell.edu mailing list. The remainder of the meeting was used to generate answers to . The other questions will be discussed on the dhcp-serve list. The second WG meeting included discussion of various DHCP issues. Bernie Volz began with a summary of the LDAP schema developers' meeting held in November. The attendees developed objectives and initial schema model, common objects and a containment hierarchy. The group considered coordination with the Desktop Management Task Force (DMTF). The next step will be to write a draft describing the proposed schema. Several old drafts were resurrected. Mark Stapp (cisco) reviewed the status of the "DHCP-DNS Interaction" draft, which he will revise to address the open issue of name disambiguation. The draft will then go back to the WG for standards track review. Pratik Gupta (IBM) revived the "Domain Search" option. Two issues arose: how to encode multiple domains in a single option and should the option go into the current option space or the new ("futures panel") option space. The WG consensus was to specify multiple options through length-encoded encapsulation and to include the option in the current option space. The specifics of the encapsulation mechanism will be coordinated with the data representation standards being developed by the futures panel. Ralph Droms (Bucknell) reviewed the "User Class" option. Two issues will be moved to the mailing list: syntax and semantics for encoding multiple classes in the option and how can a DHCP server tell the client what classes are available to choose from. A follow up draft, specifying rules for address assignment using the "User Class" option, was discussed. The WG consensus was to review this draft for acceptance as an informational RFC. Erik Guttman (Sun) discussed the most recent revision of the "SLP Server" option draft. One issue about a flag byte to override local configuration with the configuration in the DHCP message was raised and will be discussed further on the mailing list. Burcak Beser (3COM) discussed the use of the vendor class identifier by VoIP equipment. WG input was that the vendor class identifier may be appropriate to identify the vendor of the equipment. SLP may be a better mechanism for providing more individualized configurations through a bootfile. Ralph Droms and Bill Arbaugh (Univ. of Pennsylvania) reviewed revisions to the authentication protocol draft. Peter Ford (Microsoft) expressed concern that the current draft over-specifies the protocol by prescribing some details of the implementation. The WG discussed the issue of privacy in the client identifying itself to a server before learning the identity of the server; after a short discussion, the current protocol was found to allow "server-first" identification if the client leaves any identification out of the DISCOVER and the servers are configured to respond to anonymous DISCOVER messages with an OFFER that includes some identification of the server. Finally, there was a request for an example specification of a version of the authentication protocol using PK technology. Mike Carney (Sun) gave a brief review of the activities of the futures panel and the current draft. Updates to the draft will be posted soon for final discussion at the next WG meeting. Kim Kinnear gave a brief summary of the failover protocol meeting. Finally, Ryan Troll (CMU) summarized the current state of the IPv4 autoconfiguration drafts and asked for WG input as to handling of the drafts - BCP vs. STD? The conversation will continue on the mailing list. From dhcp-v4@bucknell.edu Sun Jan 3 08:28:20 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.7.249]) by ietf.org (8.8.5/8.8.7a) with ESMTP id IAA01775 for ; Sun, 3 Jan 1999 08:28:20 -0500 (EST) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.8.8/8.8.8) with SMTP id IAA20938; Sun, 3 Jan 1999 08:27:37 -0500 (EST) Date: Sun, 3 Jan 1999 08:27:37 -0500 (EST) Message-Id: Errors-To: droms@bucknell.edu Reply-To: droms@bucknell.edu Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Ralph Droms To: Multiple recipients of list Subject: Postings from Chicago meeting X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Type: text/plain; charset="us-ascii" Mime-Version: 1.0 I've updated http://www.dhcp.org with the minutes from the Chicago meeting. www.dhcp.org was renumbered within the last week or two; please let me know i you have any trouble contacting it. - Ralph Droms From dhcp-v4@bucknell.edu Sun Jan 3 10:19:15 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.7.249]) by ietf.org (8.8.5/8.8.7a) with ESMTP id KAA02261 for ; Sun, 3 Jan 1999 10:19:14 -0500 (EST) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.8.8/8.8.8) with SMTP id KAA24965; Sun, 3 Jan 1999 10:17:31 -0500 (EST) Date: Sun, 3 Jan 1999 10:17:31 -0500 (EST) Message-Id: Errors-To: droms@bucknell.edu Reply-To: droms@bucknell.edu Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Ralph Droms To: Multiple recipients of list Subject: Re: Postings from Chicago meeting X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Type: text/plain; charset="us-ascii" Mime-Version: 1.0 Here's a problem report (already!). Until the DNS entries get straightened out, www.dhcp.org can be reached at http://134.82.56.120. - Ralph At 9:38 AM -0500 1/3/99, Kelly McGrew wrote: >Tried to get there and couldn't--timed out. > >>www.dhcp.org was renumbered within the last week or two; please let me know >>i you have any trouble contacting it. From dhcp-v4@bucknell.edu Fri Jan 8 14:43:47 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.7.249]) by ietf.org (8.8.5/8.8.7a) with ESMTP id OAA18223 for ; Fri, 8 Jan 1999 14:43:47 -0500 (EST) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.8.8/8.8.8) with SMTP id OAA02343; Fri, 8 Jan 1999 14:40:15 -0500 (EST) Date: Fri, 8 Jan 1999 14:40:15 -0500 (EST) Message-Id: <199901081914.OAA14141@funnel.cisco.com> Errors-To: droms@bucknell.edu Reply-To: kkinnear@cisco.com Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Kim Kinnear To: Multiple recipients of list Subject: Interim Failover Meeting Annoucement X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Type: text/plain; charset="us-ascii" Mime-Version: 1.0 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 Meeting Announcement: Interim Failover Protocol Meeting Now that it is the new year, and you all have your 1999 calendars, you can mark the dates for the interim failover protocol meeting: Wednesday, February 10, 10:00 am -> ~ 6:00 pm Thursday, February 11, 8:30 am -> 12:30 am We will be hosting the meeeting here at the Cisco facilites in Chelmsford, MA. Chelmsford is northwest of Boston at the intersection of US 3 and I-495, and is about an hours drive (best case) from Logan airport in downtown Boston. The goals of the meeting are: 1. Promote better understanding of the failover protocol as currently defined. 2. Review the technical correctness of the failover protocol. Revise the protocol as necessary to solve any problems found. 3. Understand requirements that are not met or concerns people have with the current failover protocol (or draft), and attempt to modify the protocol and draft to meet these requirements or concerns. After the meeting, I will produce a new draft for submission to the IETF, but due to other commitments it will not be available by the likely submission cutoff for Minneapolis IETF. I would expect, however, to produce it in time for distribution on the www.dhcp.org site just prior to the Minneapolis IETF meeting. Anyone who may be interested in implementing the failover protocol is strongly urged to attend, and anyone who is seriously interested in the failover protocol is welcome. I'm hoping for a group of 10-15 people who can make substantial progress toward creating a protocol that solves the problem and that we can all live with. ------------------ If you are interested in attending this meeting, please send me the following information for each person attending: Name: Affiliation: Phone number: Email: Please respond even if you have already responded concerning the possibility of these dates. ----------------- Thanks -- Kim Kim Kinnear Cisco Systems 300 Apollo Dr. Chelmsford MA, 01824 (978) 244-8376 kkinnear@cisco.com From dhcp-v4@bucknell.edu Mon Jan 11 04:44:19 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.7.249]) by ietf.org (8.8.5/8.8.7a) with ESMTP id EAA15182 for ; Mon, 11 Jan 1999 04:44:19 -0500 (EST) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.8.8/8.8.8) with SMTP id EAA30167; Mon, 11 Jan 1999 04:38:42 -0500 (EST) Date: Mon, 11 Jan 1999 04:38:42 -0500 (EST) Message-Id: <990111011805.ZM11884@sherlock.eos.home.net> Errors-To: droms@bucknell.edu Reply-To: pace@corp.home.net Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: pace@corp.home.net (Jim Pace) To: Multiple recipients of list Subject: WPAD Proposal? X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 X-Mailer: Z-Mail (4.0.1 13Jan97) I was somewhat surprised to see a pointer on CNET News (http://www.news.com/News/Item/0,4,30032,00.html) to http://ietf43.microsoft.com/wpad/wpad.txt. The WPAD proposal was alluded to by Josh Cohen at the Chicago IETF, but I never heard anything further regarding this. Perusing the Orlando notes, I didn't see any references to a follow up on this, hence my questions... Has the DHC WG reviewed this draft? I've seen no discussion on the list. Given my impression of draft-ietf-dhc-agent-options-05.txt, no option codes are to be allocated until the draft reaches RFC status... Can anyone on the list from Netscape comment as to whether or not there are plans to roll this into a future release? thanks, pace From dhcp-v4@bucknell.edu Mon Jan 11 15:40:03 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.7.249]) by ietf.org (8.8.5/8.8.7a) with ESMTP id PAA25735 for ; Mon, 11 Jan 1999 15:40:02 -0500 (EST) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.8.8/8.8.8) with SMTP id PAA19087; Mon, 11 Jan 1999 15:35:55 -0500 (EST) Date: Mon, 11 Jan 1999 15:35:55 -0500 (EST) Message-Id: <63D30D6E10CFD11190A90000F805FE86B041D0@lespaul.process.com> Errors-To: droms@bucknell.edu Reply-To: Gonczi@process.com Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Steve Gonczi To: Multiple recipients of list Subject: DHCP schema meeting announcement X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Type: text/plain X-Mailer: Internet Mail Service (5.0.1460.8) Mime-Version: 1.0 Greetings to all, Those of you who attended the DHCP WG sessions in Chicago, may recall the report Bernie Volz (Process Software Corporation) presented on an on-going effort to develop a DHCP LDAP schema draft. We are planning a follow up meeting to continue this work. The meeting will be scheduled for February 8 and 9 in the greater Boston area, at the corporate headquarters of Process Software. Anyone interested is welcome to attend. Since this is an open meeting, the response may exceed our space capacity. In this case we will move to another nearby location. This also means that it's extremely important that you respond to us as soon as possible regarding your attendance. Please let us know by January 15, if you plan on attending. We will soon post a proposed agenda for your comments. Please contact Linda Scobo (scobo@process.com or call at 508-879-6994 x 345). Notes from the first meeting are available at : www.process.com/schema.htm. For the time being, Ralph Droms kindly agreed to provide space for this topic on this mailing list, feel free to post your comments, etc. Steve Gonczi From dhcp-v4@bucknell.edu Tue Jan 12 01:20:43 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.7.249]) by ietf.org (8.8.5/8.8.7a) with ESMTP id BAA02426 for ; Tue, 12 Jan 1999 01:20:43 -0500 (EST) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.8.8/8.8.8) with SMTP id BAA13777; Tue, 12 Jan 1999 01:15:23 -0500 (EST) Date: Tue, 12 Jan 1999 01:15:23 -0500 (EST) Message-Id: Errors-To: droms@bucknell.edu Reply-To: ryan@andrew.cmu.edu Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Ryan Troll To: Multiple recipients of list Subject: DHCP Server MIB Comments X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Type: text/plain; charset=US-ASCII Mime-Version: 1.0 (generated by tm-edit 7.108) X-Mailer: BatIMail version 3.1 The recent version of the DHCP MIB has made a bunch of good changes since the last version. While many of the scenarios that I originally commented on to the authors were addressed, a few were not. To help with these, I figured I'd bring them up on the list. After reading through many of the DHCP drafts and RFCs, I've come to the conclusion that DHCP is expandable enough to allow network administrators to select IP addresses (and other options) for clients based on any number of factors: - Client Identifier - Vendor Class - HType Information - Gateway Address (Subnet Information) and some new ones on the horizon: - User Class - Identifiers that allow the server to determine what relay agent was used With the suggested changes below, I've tried to make sure that the MIB may be augmented (without further changes) to support any of these scenarios. Our existing setup uses DHCP to hand out static bindings. [ You may ask why we don't use dynamics everywhere yet, and that's being looked into. However, until then, we're handing out static addresses. :) ] All of our address assignments are performed solely on the htype information. In our environment, this is always an ethernet MAC address. When our servers receive BOOTP/DHCP requests from clients that are unregistered (and thus don't have a static IP address assigned to them), the request is ignored. Client Request Tracking ####################### Currently, we are able to track whether or not a client request was received in the server, and what was done to that request. This functionality is not fully present in the current MIB draft. For my environment, I'd suggest adding a table such as: IMPORTS DateAndTime from SNMPv2-TC; dhcpClientHtypeTable OBJECT-TYPE SYNTAX SEQUENCE OF DhcpClientHtypeEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains information on the last DHCP packet received by the server, indexed by the contents of the htype field. If the server is using information other than the htype field to determine address assignment, this table will be empty, and an alternate table used instead." ::= { dhcpClients 2 } dhcpClientHtypeEntry OBJECT-TYPE SYNTAX ClientHtypeRequestEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A logical row in the dhcpClientHtypeTable." INDEX { dhcpClientHType } ::= { dhcpClientHtypeTable 1 } dhcpClientHtypeEntry ::= SEQUENCE { dhcpClientHtype OCTET STRING, dhcpClientAddress IpAddress, dhcpClientTimeOfLastRequest DateAndTime, dhcpClientLastRequestType Integer, dhcpClientLastResponse Integer } dhcpClientHtype OBJECT-TYPE SYNTAX OCTET STRING (SIZE (0..255)) MAX-ACCESS read-only STATUS current DESCRIPTION "The hardware type and hardware address of the client that has been assigned this lease. The first octet of this object contains the hardware type from the 'htype' field of the BOOTP packet and the remaining octets contain the hardware address from the 'chaddr' field of the BOOTP packet." ::= { dhcpClientHtypeEntry 1 } dhcpClientAddress OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-only STATUS current DESCRIPTION "IP Address last handed out to this client." ::= { dhcpClientHtypeEntry 2 } dhcpClientTimeOfLastRequest OBJECT-TYPE SYNTAX DateAndTime MAX-ACCESS read-only STATUS current DESCRIPTION "The time of the last request received containing this rows' htype information." ::= { dhcpClientHtypeEntry 3 } dhcpClientLastRequestType OBJECT-TYPE SYNTAX Integer MAX-ACCESS read-only STATUS current DESCRIPTION "The value of option 53 in the last DHCP packet received from this client." ::= { dhcpClientHtypeEntry 4 } dhcpClientLastResponse OBJECT-TYPE SYNTAX Integer MAX-ACCESS read-only STATUS current DESCRIPTION "The value of option 53 in the server's response to the last DHCP packet received from this client, listed in dhcpClientLastRequestType. If the server did not respond to this client, the value of this entry MUST be 0.." ::= { dhcpClientHtypeEntry 5 } This table could be followed by similar tables that use vendor class, user class, or relay agent information to help determine which address was handed out to a specific client. (For example, if this was used in a cable-modem environment, the table may use the relay agent extension information as part of the index, so that administrators can see what MAC addresses attempted to get an address from behind any relay agent by walking the table.) With this table in place, I can determine whether or not a user's machine actually attempted to use DHCP; whether or not we answered it; and where the machine was when it booted. If it was given a lease (static or dynamic), the address is present, and additional information may be looked up in the serverAddressTable. Whether or not this lease is still active may be determined by comparing the htype information used to index this table with the MacAddress entry in the serverAddressTable row specified by the dhcpClientAddress. If they are identical, the serverAddressTable entry is correct for this host. If they are not, it has been reallocated to another client. dhcpClientTable ############### Not all clients specify a client identifier -- the DHCP spec does not say this is a required option. This table will be useful for administrative domains in which the admins have full control over the clients, and may configure client identifiers. However, this is not always the case, and sometimes clients will not use them. In these environments, administrators (and the servers) will be using some other piece of information to lookup lease information. The table I described above would solve this in one possible environment: one that only uses MAC address information. As I stated above, other tables may be added to address other environments. read-write values ################# Some of the values within the MIB are labeled as read-write, and I guess I'm at a loss as to what being able to write these values would be useful for, other than resetting them to 0. If that's the case, there are some other values that are currently read-only, which could benefit from being read-write in order to reset the values to 0. The data in question appears in the bootpStatistics and dhcpStatistics tables. range vs. subnet ################ What's the difference between a range and a subnet? It looks like range is supposed to refer to the addresses that are handed out on a subnet, and a subnet is the routed infrastructure in which address ranges work. According to section 2.3, a range is a member of a subnet. The range is a list of addresses (specified by listing the first and last addresses), which are either reserved or dynamicly assigned. Since a range is a subset of a subnet, I guess I'm wondering what's in a subnet but not a range? And why is it advantageous to keep these two pieces of information separate? Thanks, and keep up the good work, -Ryan From dhcp-v4@bucknell.edu Tue Jan 12 12:54:01 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.7.249]) by ietf.org (8.8.5/8.8.7a) with ESMTP id MAA19391 for ; Tue, 12 Jan 1999 12:54:00 -0500 (EST) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.8.8/8.8.8) with SMTP id MAA29483; Tue, 12 Jan 1999 12:46:25 -0500 (EST) Date: Tue, 12 Jan 1999 12:46:25 -0500 (EST) Message-Id: <000a01be3e48$1a533260$8a50fb8d@net-gwaters.corpnorth.baynetworks.com> Errors-To: droms@bucknell.edu Reply-To: Glenn_Waters@BayNetworks.COM Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Glenn_Waters@BayNetworks.COM (Glenn Waters) To: Multiple recipients of list Subject: RE: DHCP Server MIB Comments X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; Mime-Version: 1.0 comments inline. > -----Original Message----- > From: dhcp-v4@bucknell.edu [mailto:dhcp-v4@bucknell.edu]On Behalf Of > Ryan Troll > Sent: Tuesday, January 12, 1999 01:17 > To: Multiple recipients of list > Subject: DHCP Server MIB Comments > > Client Request Tracking > ####################### > > Currently, we are able to track whether or not a client request was > received in the server, and what was done to that request. This > functionality is not fully present in the current MIB draft. For my > environment, I'd suggest adding a table such as: > > IMPORTS > DateAndTime from SNMPv2-TC; > > dhcpClientHtypeTable OBJECT-TYPE > SYNTAX SEQUENCE OF DhcpClientHtypeEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "This table contains information on the last DHCP packet received > by the server, indexed by the contents of the htype field. If > the server is using information other than the htype field to > determine address assignment, this table will be empty, and an > alternate table used instead." > ::= { dhcpClients 2 } > > dhcpClientHtypeEntry OBJECT-TYPE > SYNTAX ClientHtypeRequestEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "A logical row in the dhcpClientHtypeTable." > INDEX { dhcpClientHType } > ::= { dhcpClientHtypeTable 1 } > > dhcpClientHtypeEntry ::= SEQUENCE { > dhcpClientHtype OCTET STRING, > dhcpClientAddress IpAddress, > dhcpClientTimeOfLastRequest DateAndTime, > dhcpClientLastRequestType Integer, > dhcpClientLastResponse Integer > } > > dhcpClientHtype OBJECT-TYPE > SYNTAX OCTET STRING (SIZE (0..255)) > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The hardware type and hardware address of the client that has > been assigned this lease. The first octet of this object > contains the hardware type from the 'htype' field of the BOOTP > packet and the remaining octets contain the hardware address from > the 'chaddr' field of the BOOTP packet." > ::= { dhcpClientHtypeEntry 1 } > > dhcpClientAddress OBJECT-TYPE > SYNTAX IpAddress > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "IP Address last handed out to this client." > ::= { dhcpClientHtypeEntry 2 } > > dhcpClientTimeOfLastRequest OBJECT-TYPE > SYNTAX DateAndTime > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The time of the last request received containing this rows' > htype information." > ::= { dhcpClientHtypeEntry 3 } > > dhcpClientLastRequestType OBJECT-TYPE > SYNTAX Integer > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The value of option 53 in the last DHCP packet received from > this client." > ::= { dhcpClientHtypeEntry 4 } > > dhcpClientLastResponse OBJECT-TYPE > SYNTAX Integer > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The value of option 53 in the server's response to the last > DHCP packet received from this client, listed in > dhcpClientLastRequestType. If the server did not respond to > this client, the value of this entry MUST be 0.." > ::= { dhcpClientHtypeEntry 5 } > > > This table could be followed by similar tables that use vendor class, > user class, or relay agent information to help determine which address > was handed out to a specific client. (For example, if this was used > in a cable-modem environment, the table may use the relay agent > extension information as part of the index, so that administrators can > see what MAC addresses attempted to get an address from behind any > relay agent by walking the table.) > > With this table in place, I can determine whether or not a user's > machine actually attempted to use DHCP; whether or not we answered it; > and where the machine was when it booted. If it was given a lease > (static or dynamic), the address is present, and additional > information may be looked up in the serverAddressTable. Whether or > not this lease is still active may be determined by comparing the > htype information used to index this table with the MacAddress entry > in the serverAddressTable row specified by the dhcpClientAddress. If > they are identical, the serverAddressTable entry is correct for this > host. If they are not, it has been reallocated to another client. the above table is OK but there is one problem and i would like to change a few things. first, the table needs to have the subnet as a second index since a hardware address is only subnet unique. this would prevent two entries from clashing (however unlikely that may be). second, the table is dhcp specific. i would like to change that to contain dhcp and bootp clients. that means the lastRequestType and the lastResponse object would need some rework. i believe that rework should not be too hard. third, i would change the timeOfLastRequest object to be a TimeTicks and the object would contain the value of sysUpTime at the time the last request was received. this is the way that the other MIB WGs design objects of this type and i believe we should follow their lead. > dhcpClientTable > ############### > > Not all clients specify a client identifier -- the DHCP spec does not > say this is a required option. This table will be useful for > administrative domains in which the admins have full control over the > clients, and may configure client identifiers. However, this is not > always the case, and sometimes clients will not use them. > > In these environments, administrators (and the servers) will be using > some other piece of information to lookup lease information. The > table I described above would solve this in one possible environment: > one that only uses MAC address information. As I stated above, other > tables may be added to address other environments. i agree there is a problem there. i would propose that we remove both the bootClientTable and the dhcpClientTable and replace them with the new table above. we may need some additional tweaking and wordsmithing to accomplish this task, but i think it the right approach. > read-write values > ################# > > Some of the values within the MIB are labeled as read-write, and I > guess I'm at a loss as to what being able to write these values would > be useful for, other than resetting them to 0. If that's the case, > there are some other values that are currently read-only, which could > benefit from being read-write in order to reset the values to 0. > > The data in question appears in the bootpStatistics and dhcpStatistics > tables. the only reason the stats table are read-write is so that the stats can be reset. the stats are dynamic (i.e.: non-configuration) data. one non-goal that is explicitly stated is that we do NOT want to accomplish the ability to change configuration data (the first paragraph of section 2.3 says this and explains why). i still believe this to be a valid restraint on this work, hence i do not think that changing the configuration objects from read-only to read-write is warranted. > range vs. subnet > ################ > > What's the difference between a range and a subnet? It looks like > range is supposed to refer to the addresses that are handed out on a > subnet, and a subnet is the routed infrastructure in which address > ranges work. > > According to section 2.3, a range is a member of a subnet. The range > is a list of addresses (specified by listing the first and last > addresses), which are either reserved or dynamicly assigned. > > Since a range is a subset of a subnet, I guess I'm wondering what's in > a subnet but not a range? > > And why is it advantageous to keep these two pieces of information > separate? you are correct that ranges are subsets of subnets, however they have enough different attributes that i believe it is warranted to keep them separate. i think that if we merged the two tables then we end with attributes that are only meaningful in certain instances of the ranges. the other note of interest here is the both the ISC dhcp server and our dhcp server model our data with ranges and subnets -- not a reason but just indicates that maybe it is a OK way to model the data. > Thanks, and keep up the good work, > -Ryan thanks for keep on reviewing. /gww From dhcp-v4@bucknell.edu Tue Jan 12 12:58:26 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.7.249]) by ietf.org (8.8.5/8.8.7a) with ESMTP id MAA19516 for ; Tue, 12 Jan 1999 12:58:25 -0500 (EST) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.8.8/8.8.8) with SMTP id MAA00936; Tue, 12 Jan 1999 12:53:05 -0500 (EST) Date: Tue, 12 Jan 1999 12:53:05 -0500 (EST) Message-Id: <000301be3e4c$f482ec10$af060280@ANDREW.NT.CMU.EDU> Errors-To: droms@bucknell.edu Reply-To: ryan@andrew.cmu.edu Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: "Ryan Troll" To: Multiple recipients of list Subject: RE: DHCP Server MIB Comments X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; Mime-Version: 1.0 > first, the table needs to have the subnet as a second index since > a hardware > address is only subnet unique. this would prevent two entries > from clashing > (however unlikely that may be). Hm. I thought that MAC addresses were globally unique, per the IEEE definition. > second, the table is dhcp specific. i would like to change that > to contain > dhcp and bootp clients. that means the lastRequestType and the > lastResponse > object would need some rework. i believe that rework should not be too > hard. No problem. > > third, i would change the timeOfLastRequest object to be a > TimeTicks and the > object would contain the value of sysUpTime at the time the last > request was > received. this is the way that the other MIB WGs design objects of this > type and i believe we should follow their lead. I'm still concerned about the use of sysUpTime in a distributed SNMP infrastructure, such as AgentX. The definition of sysUpTime is rather misleading in this scenario, as it refers to the management entity. When the management entity is distributed across multiple processes, some of which may reboot while the others are running, sysUpTime cannot be used to reliably state an epoch for all management subagents on the system. Also, using sysUpTime to represent this does not help keep track of things that were received before the system was restarted. The choice of time value I selected would allow this to work. I'm very open to other suggestions, as long as it allows a management agent to determine the time (in the management agent's timezone) of the last received packet, regardless of whether or not the dhcp server (or any other part of the SNMP subsystem) has been restarted. > i agree there is a problem there. i would propose that we remove both the > bootClientTable and the dhcpClientTable and replace them with the > new table > above. we may need some additional tweaking and wordsmithing to > accomplish > this task, but i think it the right approach. Cool. > > > read-write values > > ################# > the only reason the stats table are read-write is so that the stats can be > reset. the stats are dynamic (i.e.: non-configuration) data. > one non-goal > that is explicitly stated is that we do NOT want to accomplish the ability > to change configuration data (the first paragraph of section 2.3 says this > and explains why). i still believe this to be a valid restraint on this > work, hence i do not think that changing the configuration objects from > read-only to read-write is warranted. Ok. I guess I wondered why some of the other stats were not resetable as well (not the configuration information), but if everybody's happy, I'm happy. :) > > you are correct that ranges are subsets of subnets, however they > have enough > different attributes that i believe it is warranted to keep them > separate. i > think that if we merged the two tables then we end with > attributes that are > only meaningful in certain instances of the ranges. What are the different attributes that would be lost by merging the tables? Knowing this would help me see what I'm mising. > > the other note of interest here is the both the ISC dhcp server > and our dhcp > server model our data with ranges and subnets -- not a reason but just > indicates that maybe it is a OK way to model the data. -Ryan From dhcp-v4@bucknell.edu Tue Jan 12 14:08:41 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.7.249]) by ietf.org (8.8.5/8.8.7a) with ESMTP id OAA22228 for ; Tue, 12 Jan 1999 14:08:40 -0500 (EST) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.8.8/8.8.8) with SMTP id OAA22978; Tue, 12 Jan 1999 14:02:37 -0500 (EST) Date: Tue, 12 Jan 1999 14:02:37 -0500 (EST) Message-Id: <199901121839.MAA28844@bears.austin.ibm.com> Errors-To: droms@bucknell.edu Reply-To: galthaus@austin.ibm.com Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Greg Althaus To: Multiple recipients of list Subject: Re: DHCP Server MIB Comments X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 X-Mailer: exmh version 2.0gamma 1/27/96 > > > > you are correct that ranges are subsets of subnets, however they > > have enough > > different attributes that i believe it is warranted to keep them > > separate. i > > think that if we merged the two tables then we end with > > attributes that are > > only meaningful in certain instances of the ranges. > > What are the different attributes that would be lost by merging the tables? > Knowing this would help me see what I'm mising. > > > > > > the other note of interest here is the both the ISC dhcp server > > and our dhcp > > server model our data with ranges and subnets -- not a reason but just > > indicates that maybe it is a OK way to model the data. > > > -Ryan > I know in the IBM DHCP servers (on various platforms), the DHCP administrator has the ability to assign different attributes to ranges of addresses with in an address pool. A subnet may be defined by multiple address pools. So, I think there is value in maintaining ranges separate from the subnet definitions. Greg Althaus AIX TCPIP Development and Support From dhcp-v4@bucknell.edu Tue Jan 12 14:09:30 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.7.249]) by ietf.org (8.8.5/8.8.7a) with ESMTP id OAA22248 for ; Tue, 12 Jan 1999 14:09:30 -0500 (EST) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.8.8/8.8.8) with SMTP id OAA21988; Tue, 12 Jan 1999 14:03:56 -0500 (EST) Date: Tue, 12 Jan 1999 14:03:56 -0500 (EST) Message-Id: Errors-To: droms@bucknell.edu Reply-To: ryan@andrew.cmu.edu Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Ryan Troll To: Multiple recipients of list Subject: Re: DHCP Server MIB Comments X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Type: text/plain; charset=US-ASCII Mime-Version: 1.0 (generated by tm-edit 7.108) X-Mailer: BatIMail version 3.1 > I know in the IBM DHCP servers (on various platforms), the DHCP administrator > has the ability to assign different attributes to ranges of addresses with > in an address pool. A subnet may be defined by multiple address pools. So, > I think there is value in maintaining ranges separate from the subnet > definitions. Ah, that makes sense. The different attributes aren't necessarily present in the table we're looking at, but could easily be displayed via a vendor specific MIB that uses this table to index it. Now I understand why ranges would be separate. In the table that I asked about, there isn't really any reason to keep them seperate based on the content there. However, in the context of the server itself, and data outside of the scope of that data, keeping the ranges seperate makes a lot of sense. Thanks, -Ryan From dhcp-v4@bucknell.edu Tue Jan 12 17:36:55 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.7.249]) by ietf.org (8.8.5/8.8.7a) with ESMTP id RAA26082 for ; Tue, 12 Jan 1999 17:36:54 -0500 (EST) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.8.8/8.8.8) with SMTP id RAA13001; Tue, 12 Jan 1999 17:33:19 -0500 (EST) Date: Tue, 12 Jan 1999 17:33:19 -0500 (EST) Message-Id: Errors-To: droms@bucknell.edu Reply-To: dhcp-v4@bucknell.edu Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: dhcp-v4@bucknell.edu (by way of Ralph Droms) To: Multiple recipients of list Subject: Re: DHCP Server MIB Comments X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Type: text/plain; charset="us-ascii" Mime-Version: 1.0 message sent to dhcp-v4@bucknell.edu by MELLON@GROSSE.FUGUE.COM follows. ------------------------------------------------------------------------ > Hm. I thought that MAC addresses were globally unique, per the IEEE > definition. They're globally unique to a CPU, not a network. Sun machines generally have (or had) one ethernet address per machine, and that would be used by all ethernet cards installed in that machine. It's also perfectly legal for a DHCP client to roam between networks without cancelling its leases, and if it remembers its old, unexpired leases when it moves back, it's not stretching things very far to suggest that it should be allowed to use them. So it wouldn't even be that surprising to find the same mac address on more than one subnet. _MelloN_ From dhcp-v4@bucknell.edu Tue Jan 12 18:37:48 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.7.249]) by ietf.org (8.8.5/8.8.7a) with ESMTP id SAA26896 for ; Tue, 12 Jan 1999 18:37:47 -0500 (EST) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.8.8/8.8.8) with SMTP id SAA30359; Tue, 12 Jan 1999 18:34:55 -0500 (EST) Date: Tue, 12 Jan 1999 18:34:55 -0500 (EST) Message-Id: <2F42142EAA6FD211B8FA0008C7A4F99C2B1948@msgbay15.snfc370.PacBell.COM> Errors-To: droms@bucknell.edu Reply-To: RBHIBBS@msg.pacbell.com Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: "Hibbs, R BARR (PB-rbhibbs)" To: Multiple recipients of list Subject: RE: DHCP Server MIB Comments X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Type: text/plain X-Mailer: Internet Mail Service (5.5.2232.9) Mime-Version: 1.0 Glenn, Ryan, Greg, et al., Here I'm commenting on Ryan's responses to Glenn's note (is everybody confused yet?) ---------- From: Ryan Troll [SMTP:ryan@andrew.cmu.edu] Sent: Tuesday, January 12, 1999 9:53 AM To: Multiple recipients of list Subject: RE: DHCP Server MIB Comments > first, the table needs to have the subnet as a second index since > a hardware > address is only subnet unique. this would prevent two entries > from clashing > (however unlikely that may be). Hm. I thought that MAC addresses were globally unique, per the IEEE definition. [while it is true that the IEEE requirements are for global uniqueness of the sequence number portion of a MAC address for any given manufacturer number and hardware type, the DHCP rfc only requires subnet uniqueness of the client hardware address -- this is to permit a client to "roam" from one subnet to another. Ryan, you may recall that we discussed very briefly the matter of global uniqueness for the client identifier both in Chicago and Orlando, but the client hardware address remains only unique per subnet] > second, the table is dhcp specific. i would like to change that > to contain > dhcp and bootp clients. that means the lastRequestType and the > lastResponse > object would need some rework. i believe that rework should not be too > hard. No problem. [here, I agree with Glenn] > > third, i would change the timeOfLastRequest object to be a > TimeTicks and the > object would contain the value of sysUpTime at the time the last > request was > received. this is the way that the other MIB WGs design objects of this > type and i believe we should follow their lead. I'm still concerned about the use of sysUpTime in a distributed SNMP infrastructure, such as AgentX. The definition of sysUpTime is rather misleading in this scenario, as it refers to the management entity. When the management entity is distributed across multiple processes, some of which may reboot while the others are running, sysUpTime cannot be used to reliably state an epoch for all management subagents on the system. Also, using sysUpTime to represent this does not help keep track of things that were received before the system was restarted. The choice of time value I selected would allow this to work. I'm very open to other suggestions, as long as it allows a management agent to determine the time (in the management agent's timezone) of the last received packet, regardless of whether or not the dhcp server (or any other part of the SNMP subsystem) has been restarted. [we may have to revisit the basis for our timers as a general matter before advancing this draft -- one thing I would like is for this MIB to be consistent with the general practice and also to not knowingly introduce problems in its use, as the possible confusion over time values suggests] --Barr From dhcp-v4@bucknell.edu Tue Jan 12 18:37:52 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.7.249]) by ietf.org (8.8.5/8.8.7a) with ESMTP id SAA26906 for ; Tue, 12 Jan 1999 18:37:51 -0500 (EST) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.8.8/8.8.8) with SMTP id SAA30119; Tue, 12 Jan 1999 18:33:37 -0500 (EST) Date: Tue, 12 Jan 1999 18:33:37 -0500 (EST) Message-Id: <2F42142EAA6FD211B8FA0008C7A4F99C2B1947@msgbay15.snfc370.PacBell.COM> Errors-To: droms@bucknell.edu Reply-To: RBHIBBS@msg.pacbell.com Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: "Hibbs, R BARR (PB-rbhibbs)" To: Multiple recipients of list Subject: RE: DHCP Server MIB Comments X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Type: text/plain; X-Mailer: Internet Mail Service (5.5.2232.9) Mime-Version: 1.0 Ryan, Glenn, Greg, et al., My comments to Ryan's original message are included inline.... ---------- From: Ryan Troll [SMTP:ryan@andrew.cmu.edu] Sent: Monday, January 11, 1999 10:17 PM To: Multiple recipients of list Subject: DHCP Server MIB Comments [stuff deleted] After reading through many of the DHCP drafts and RFCs, I've come to the conclusion that DHCP is expandable enough to allow network administrators to select IP addresses (and other options) for clients based on any number of factors: - Client Identifier [yes] - Vendor Class [no, as I read the Vendor Class option description, it is NOT a determinant of IP address to be offered a client, although it DOES influence the selection of other option values] - HType Information [no, the hardware type information is not a determinant of IP address, despite its suggested use in creating Client Identifiers -- while I tend to agree that the hardware type octet should be considered for future adoption as a means for disambiguating the client hardware address, it is not now appropriate to use it in that way] - Gateway Address (Subnet Information) [again, I must disagree: the possibility of aggregating multiple subnets on a single network segment demands some means of identifying these shared network segments, but the Gateway Address should not be the key.... the problem is again one of ambiguity: assuming multiple gateways are defined for a network segment, which should be the key?] and some new ones on the horizon: - User Class [agreed that it is a factor in selecting other options, but not client IP addresses] - Identifiers that allow the server to determine what relay agent was used [I don't see this, but am willing to yield the point....] [stuff deleted] Currently, we are able to track whether or not a client request was received in the server, and what was done to that request. This functionality is not fully present in the current MIB draft. For my environment, I'd suggest adding a table such as: IMPORTS DateAndTime from SNMPv2-TC; dhcpClientHtypeTable OBJECT-TYPE SYNTAX SEQUENCE OF DhcpClientHtypeEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains information on the last DHCP packet received by the server, indexed by the contents of the htype field. If the server is using information other than the htype field to determine address assignment, this table will be empty, and an alternate table used instead." ::= { dhcpClients 2 } [first, I must raise an objection to the naming that you've suggested: this is not a sequence of hardware type objects, but rather an invented meta-object consisting of the hardware type octet prepended to the client hardware address. Glenn raises the issue of uniqueness in a later note as the RFC does not require global uniqueness for the client hardware address (nor for the client identifier either!). Since you are proposing an meta-object, in order to guarantee the uniqueness that is required for this table to be useful, either multiple indices are required (i.e., subnet, hardware type, MAC address), or tables must be nested to provide the uniqueness necessary. I would oppose constructing an even larger index by simply concatenating the three items because that confuses and hides their individual characteristics.... [second, the existence of this table presupposes that for each client the server must keep some state information. Certainly the ISC server (and my variant of it) does not presently retain client state information, and also does not keep any state information about "static" IP address assignments. While I won't oppose inclusion of this table in the server MIB, I will insist on a clear statement of the response that can be expected from a server that does not record state information] [stuff deleted] dhcpClientHtype OBJECT-TYPE SYNTAX OCTET STRING (SIZE (0..255)) MAX-ACCESS read-only STATUS current DESCRIPTION "The hardware type and hardware address of the client that has been assigned this lease. The first octet of this object contains the hardware type from the 'htype' field of the BOOTP packet and the remaining octets contain the hardware address from the 'chaddr' field of the BOOTP packet." ::= { dhcpClientHtypeEntry 1 } [an editorial note: the client hardware address is limited to 16 octets, so the size of the octet string should be adjusted to match] [stuff deleted] This table could be followed by similar tables that use vendor class, user class, or relay agent information to help determine which address was handed out to a specific client. (For example, if this was used in a cable-modem environment, the table may use the relay agent extension information as part of the index, so that administrators can see what MAC addresses attempted to get an address from behind any relay agent by walking the table.) [before including other such tables in the server MIB, I would want to see some indication of need or desirability from other implementors -- with supporting requests there is no reason why other tables couldn't be included] With this table in place, I can determine whether or not a user's machine actually attempted to use DHCP; whether or not we answered it; and where the machine was when it booted. [how do you know where the machine was located? You've not provided for capture and reporting of gateway from which the request originated.] If it was given a lease (static or dynamic), the address is present, and additional information may be looked up in the serverAddressTable. Whether or not this lease is still active may be determined by comparing the htype information used to index this table with the MacAddress entry in the serverAddressTable row specified by the dhcpClientAddress. If they are identical, the serverAddressTable entry is correct for this host. If they are not, it has been reallocated to another client. [yeah, I suppose so, but if this information is important to you for the management of your client population, why not capture and report it in a more direct fashion?] [stuff deleted] Some of the values within the MIB are labeled as read-write, and I guess I'm at a loss as to what being able to write these values would be useful for, other than resetting them to 0. If that's the case, there are some other values that are currently read-only, which could benefit from being read-write in order to reset the values to 0. The data in question appears in the bootpStatistics and dhcpStatistics tables. [as Glenn pointed out in his note, the idea is to permit reset of the statistics and not the reconfiguration of the server.... we'll look at the read-write status of individual items to ensure consistency....] [stuff deleted] Since a range is a subset of a subnet, I guess I'm wondering what's in a subnet but not a range? And why is it advantageous to keep these two pieces of information separate? [the idea is that multiple, disjoint ranges of IP addresses may exist within a subnet in order to simplify the configuration of that subnet. In my case, certain ranges of IP addresses within a given subnet are reserved for gateways, name servers (both DNS and WINS), applications servers, testing, and to account for certain fixed uses. For example, the dynamic address pool for one of my subnets is: 129.245.198.16 -- 129.245.198.191 and 129.245.198.208 -- 129.245.198.231. Also, we typically assign multiple subnets to a single network segment, for example, 129.245.139.xxx, 129.245.197.xxx, and 129.245.198.xxx are all on the same LAN (as represented by hub/router), so we would really like to have three elements.... Again, if we did not clearly specify the definition of subnet and address range, Glenn and I will commit to clarifying the definitions.] Thanks for your comments! --Barr From dhcp-v4@bucknell.edu Wed Jan 13 12:11:59 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.7.249]) by ietf.org (8.8.5/8.8.7a) with ESMTP id MAA12150 for ; Wed, 13 Jan 1999 12:11:58 -0500 (EST) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.8.8/8.8.8) with SMTP id MAA13739; Wed, 13 Jan 1999 12:04:35 -0500 (EST) Date: Wed, 13 Jan 1999 12:04:35 -0500 (EST) Message-Id: <000001be3f0c$d163ab00$af060280@ANDREW.NT.CMU.EDU> Errors-To: droms@bucknell.edu Reply-To: ryan@andrew.cmu.edu Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: "Ryan Troll" To: Multiple recipients of list Subject: RE: DHCP Server MIB Comments X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; Mime-Version: 1.0 > > that is supposed to be the case for ethernet. i my past experience i have > seen the same ethernet address come out of two devices on the same wire. > > the real answer though is what about other hardware types. i just don't > know the answer. > > the question is, do you object to the second index? > Not really. What I want to do can be done with the second index, just not as efficiently. But the second index does give you more information, like the ability to track a host across subnets, which is really cool. Looks good to me. > > i am going on what the agentx developers have recommended to me. part of > the agentx protocol is to pass sysUpTime to the subagents. all clocks are > supposed to be relative to the sysUpTime. i will reconfirm with > one of the > agentx authors on this particular issue. That would be really cool. Personally, the use of sysUpTime doesn't allow me to keep historical information around, which is a little distressing. Using sysUpTime as a root for all future times (IE: lease expiration) works, but using it for things that happened in the past (IE: when was this client heard from last) brings up the question of what to do when sysUpTime resets to 0. -Ryan From dhcp-v4@bucknell.edu Wed Jan 13 12:17:54 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.7.249]) by ietf.org (8.8.5/8.8.7a) with ESMTP id MAA12261 for ; Wed, 13 Jan 1999 12:17:54 -0500 (EST) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.8.8/8.8.8) with SMTP id MAA10669; Wed, 13 Jan 1999 12:12:22 -0500 (EST) Date: Wed, 13 Jan 1999 12:12:22 -0500 (EST) Message-Id: <000201be3f13$a3bdb540$af060280@ANDREW.NT.CMU.EDU> Errors-To: droms@bucknell.edu Reply-To: ryan@andrew.cmu.edu Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: "Ryan Troll" To: Multiple recipients of list Subject: RE: DHCP Server MIB Comments X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; Mime-Version: 1.0 > > sysUpTime is sufficient to keep historical information. it works as > follows: when the management platform retrieves an object that > is based on > sysUpTime it looks at the current value of the sysUpTime object and at the > current clock on the management platform. subtract the sysUpTime from the > current clock to get the time when the agent started. add to that > the value > of the object that is based on sysUpTime. you now have a time that is no > longer relative. so for example to get the absolute time of the object > dhcpClientLastResponse: > > current_time_on_mgmt_platform - sysUpTime + dhcpClientLastResponse That's understood. The problem I have is when sysUpTime resets to 0. > i agree this could be a problem, however this is a general SNMP agent > problem. i don't think that we should try to solve this. there have been > many long discussions on the SNMPv3 list about this. That's good to hear. -Ryan From dhcp-v4@bucknell.edu Wed Jan 13 12:21:38 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.7.249]) by ietf.org (8.8.5/8.8.7a) with ESMTP id MAA12352 for ; Wed, 13 Jan 1999 12:21:37 -0500 (EST) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.8.8/8.8.8) with SMTP id MAA20198; Wed, 13 Jan 1999 12:13:42 -0500 (EST) Date: Wed, 13 Jan 1999 12:13:42 -0500 (EST) Message-Id: <000301be3f13$aff12ea0$af060280@ANDREW.NT.CMU.EDU> Errors-To: droms@bucknell.edu Reply-To: ryan@andrew.cmu.edu Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: "Ryan Troll" To: Multiple recipients of list Subject: RE: DHCP Server MIB Comments X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; Mime-Version: 1.0 > - HType Information > > [no, the hardware type information is not a determinant of IP > address, despite its suggested use in creating Client Identifiers > -- while I > tend to agree that the hardware type octet should be considered for future > adoption as a means for disambiguating the client hardware address, it is > not now appropriate to use it in that way] I meant to say the combination of htype and client address information. So, for MAC addresses, this would be the usual '\006 aa:bb:cc:dd:ee:ff'. (I believe \006 was the octet for ethernet.) This information, along with the gateway address, is exactly what we use to determine what IP address a user should receive. > > - Gateway Address (Subnet Information) > > [again, I must disagree: the possibility of aggregating multiple > subnets on a single network segment demands some means of > identifying these > shared network segments, but the Gateway Address should not be the key.... > the problem is again one of ambiguity: assuming multiple gateways are > defined for a network segment, which should be the key?] The list I presented were things that could be used, and this is definately something that could be used. We use this to determine where a client is when it requests an IP address. In our dorms, we have multiple subnets on a single network, and the DHCPD setup knows which subnets are valid behind any one gateway, and assigns information appropriately. This may not work for other sites, but it does work well for us. > > and some new ones on the horizon: > > - User Class > > [agreed that it is a factor in selecting other options, but not client IP > addresses] Hm. I thought this was what Microsoft was using to implement QoS-like stuff in Windows 2000. At the PDC over a year ago, they demonstrated QoS functionality by having machines change IP addresses to ranges that had better performance charactoristics on the local wire based on who logged in. > > - Identifiers that allow the server to determine what relay agent was > used > > [I don't see this, but am willing to yield the point....] This is what the Cable Modem guys wanted to use. Based on which house the request is starting in, they can determine what IP address to assign the request. Assuming that they wanted to give only 5 addresses per house, this would allow them to give one of the dynamic addresses for the house the request eminates from. They could also use this information to determine whether or not a machine should receive a DHCP lease, based on current registration or household usage. [ I'm using house to refer to an actual site, which could be an apartment, etc. ] > [first, I must raise an objection to the naming that you've > suggested: this > is not a sequence of hardware type objects, but rather an invented > meta-object consisting of the hardware type octet prepended to the client > hardware address. Glenn raises the issue of uniqueness in a later note as > the RFC does not require global uniqueness for the client hardware address > (nor for the client identifier either!). Since you are proposing an > meta-object, in order to guarantee the uniqueness that is > required for this > table to be useful, either multiple indices are required (i.e., subnet, > hardware type, MAC address), or tables must be nested to provide the > uniqueness necessary. I would oppose constructing an even larger index by > simply concatenating the three items because that confuses and hides their > individual characteristics.... No problem with the name. Given my previous assumption of MAC address global uniqueness, this would have worked. But, as others have pointed out, this isn't the case, so the presented table won't work. Adding the subnet field to the index will solve this, and does present more data to the administrator that will be helpful. > [second, the existence of this table presupposes that for each client the > server must keep some state information. Certainly the ISC server (and my > variant of it) does not presently retain client state > information, and also > does not keep any state information about "static" IP address assignments. > While I won't oppose inclusion of this table in the server MIB, I will > insist on a clear statement of the response that can be expected from a > server that does not record state information] That's fine. I'm just thinking about what I need to do to remotely manage a DHCP server, and being able to determine these things are part of that. And it's what we do now. We are going to implement this in the ISC server, using an external logging mechanism, so that the existing ISC server doesn't get bloated with all of the SNMP stuff. It will also keep the number of changes to the ISC server at a minimum. Just a few printf - like functions here and there. > [before including other such tables in the server MIB, I would want to see > some indication of need or desirability from other implementors -- with > supporting requests there is no reason why other tables couldn't be > included] Exactly. > > With this table in place, I can determine whether or not a user's > machine actually attempted to use DHCP; whether or not we answered it; > and where the machine was when it booted. > > [how do you know where the machine was located? You've not provided for > capture and reporting of gateway from which the request originated.] You are right, I'd only have that for successful responses. Not for things that were unanswered. Adding subnet information to the OID would solve this. > [yeah, I suppose so, but if this information is important to you for the > management of your client population, why not capture and report it in a > more direct fashion?] I was trying to come up with a way to do this with the data present, rather than introduce another table. Unless others have a better suggestion. :) Thanks again, -Ryan From dhcp-v4@bucknell.edu Wed Jan 13 14:53:54 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.7.249]) by ietf.org (8.8.5/8.8.7a) with ESMTP id OAA18025 for ; Wed, 13 Jan 1999 14:53:45 -0500 (EST) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.8.8/8.8.8) with SMTP id OAA04199; Wed, 13 Jan 1999 14:47:59 -0500 (EST) Date: Wed, 13 Jan 1999 14:47:59 -0500 (EST) Message-Id: Errors-To: droms@bucknell.edu Reply-To: droms@bucknell.edu Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: "Ralph E. Droms" To: Multiple recipients of list Subject: IMPORTANT: DHCPv6 Work in this Working Group Issue (fwd) X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Type: TEXT/PLAIN; charset=US-ASCII Mime-Version: 1.0 message sent to dhcp-v6@bucknell.edu by BOUND@WASTED.ZK3.DEC.COM follows. ------------------------------------------------------------------------- Dear DHCPv6 WG, Charlie Perkins and I have put a lot of work into DHCPv6 and so has Ralph Droms, and Thomas Narten. Ralph and I have asked for input from you many times. This last flurry of mail on the final discussions is important as we want to put this stage of DHCPv6 to bed and get to Proposed Standard. Also up until about March 98 at least some of the WG was working on this and before Chicago Aug 98 we had good input at the IETF meetings or the spec would not have been ready for Last Call. But since July and when we received the last minute last call comments in October 98 WG input has been void. We are having the discussions now to resolve the WG Last Call input we received and will be updating the specifications soon. Current specs are: draft-ietf-dhc-dhcpv6-13.txt (dhcpv6 protocol spec) draft-ietf-dhc-v6exts-10.txt (dhcpv6 extensions for dhcpv6) I am very concerned about the lack of responses on this mail list and from this working group, because the mechanism for completion of discussion on the list by Ralph is that silence is not a valid response as consensus for the DHC WG. This is the chairs perogative and though different than any other WG I work on, we support this method. But there is nothing else I can think of to do to stimulate this WG to work on this last part DHCPv6 to reach PS. I know at least 6 persons who came up to me at the IETF and said "I thought we were done and moving to Proposed Standard based on the drafts from July 1998". But we are not and need your support. The issues which are not major protocol issues with our design are being discussed and have been presented to the list. But I must assume either the list is burned out, not interested, too busy working on dhcpv4 or other things, or whatever. What we told Ralph and our Internet Area Directors (Thomas and Jeff) is we will have to be proactive to go outside of this list and get review of these updates in the new specs to get this work completed. I am going to start that process today and enlist the support of the IETF to get this next spec reviewed. To leave all this review to Ralph and Thomas is simply not fair and also not the IETF way. I know you have done work on this spec and we appreciate it greatly to get us to where we are today. But we are now on the home stretch and DHCPv6 is important to the deployment of IPv6. One example is that it is a valuable transition mechanism/tool for the interoperation of IPv4 and IPv6, and there are other deployment reasons for real customers that will need DHCPv6. Also as many of you know I have been around IPv6 since its inception and wear both an architect and implementors hat for this next generation protocol. The folkway/more/attitude or whatever you want to call it for IPv6 implementation to begin is normally that a spec move to Proposed Standard. We have some implementations underway (mine included) but to get this specification implemented we need to wrap up a DHCPv6 WG last call and then an IETF/IESG last call. So as I begin to ask for help in the IETF community please do not take this as a slam against the WG or anyone else, we cannot continue with the silence on this mailing list. If you would like to respond to Charlie and I privately that is OK, but I highly suggest and encourage you to respond to Ralph too. When I told Ralph at Orlando about some of your comments he told me "they" need to state those comments to me. One comment was even the DHCPv4 WG mail list could be more active and part of the problem is that the DHC WG is one of the oldest WGs in the IETF. But Ralph needs to hear that directly. Sincerely, /jim From dhcp-v4@bucknell.edu Wed Jan 13 14:57:10 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.7.249]) by ietf.org (8.8.5/8.8.7a) with ESMTP id OAA18168 for ; Wed, 13 Jan 1999 14:57:09 -0500 (EST) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.8.8/8.8.8) with SMTP id OAA02233; Wed, 13 Jan 1999 14:50:20 -0500 (EST) Date: Wed, 13 Jan 1999 14:50:20 -0500 (EST) Message-Id: Errors-To: droms@bucknell.edu Reply-To: droms@bucknell.edu Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: "Ralph E. Droms" To: Multiple recipients of list Subject: RE: DHCP Server MIB Comments (fwd) X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Type: TEXT/PLAIN; charset=US-ASCII Mime-Version: 1.0 message sent to dhcp-v4@bucknell.edu by GLENN_WATERS@CORPEAST.BAYNETWORKS.COM follows. ------------------------------------------------------------------------------ > > i am going on what the agentx developers have recommended to > me. part of > > the agentx protocol is to pass sysUpTime to the subagents. all > clocks are > > supposed to be relative to the sysUpTime. i will reconfirm with > > one of the > > agentx authors on this particular issue. > > That would be really cool. > > Personally, the use of sysUpTime doesn't allow me to keep historical > information around, which is a little distressing. Using sysUpTime as a > root for all future times (IE: lease expiration) works, but using it for > things that happened in the past (IE: when was this client heard > from last) sysUpTime is sufficient to keep historical information. it works as follows: when the management platform retrieves an object that is based on sysUpTime it looks at the current value of the sysUpTime object and at the current clock on the management platform. subtract the sysUpTime from the current clock to get the time when the agent started. add to that the value of the object that is based on sysUpTime. you now have a time that is no longer relative. so for example to get the absolute time of the object dhcpClientLastResponse: current_time_on_mgmt_platform - sysUpTime + dhcpClientLastResponse (time values may need to be normalized to all be in the same units) > brings up the question of what to do when sysUpTime resets to 0. i agree this could be a problem, however this is a general SNMP agent problem. i don't think that we should try to solve this. there have been many long discussions on the SNMPv3 list about this. > > > -Ryan > > From dhcp-v4@bucknell.edu Thu Jan 14 17:52:48 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.7.249]) by ietf.org (8.8.5/8.8.7a) with ESMTP id RAA18775 for ; Thu, 14 Jan 1999 17:52:45 -0500 (EST) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.8.8/8.8.8) with SMTP id RAA05686; Thu, 14 Jan 1999 17:42:36 -0500 (EST) Date: Thu, 14 Jan 1999 17:42:36 -0500 (EST) Message-Id: Errors-To: droms@bucknell.edu Reply-To: dhcp-v4@bucknell.edu Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: dhcp-v4@bucknell.edu (by way of Ralph Droms) To: Multiple recipients of list Subject: RE: DHCP Server MIB Comments X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Type: text/plain; charset="us-ascii" Mime-Version: 1.0 message sent to dhcp-v4@bucknell.edu by GLENN_WATERS@CORPEAST.BAYNETWORKS.COM follows. ------------------------------------------------------------------------------- with regards to DateAndTime... uncle :) i will change all appropriate TimeTicks objects to DateAndTime. the SNMPv3 guys used to recommend using a TimeTicks object based on sysUpTime. now they are divided, so, if they don't care which we use then i will go with the DateAndTime syntax. /gww > -----Original Message----- > From: dhcp-v4@bucknell.edu [mailto:dhcp-v4@bucknell.edu]On Behalf Of > Ryan Troll > Sent: Wednesday, January 13, 1999 12:13 > To: Multiple recipients of list > Subject: RE: DHCP Server MIB Comments > > > > > > sysUpTime is sufficient to keep historical information. it works as > > follows: when the management platform retrieves an object that > > is based on > > sysUpTime it looks at the current value of the sysUpTime object > and at the > > current clock on the management platform. subtract the > sysUpTime from the > > current clock to get the time when the agent started. add to that > > the value > > of the object that is based on sysUpTime. you now have a time > that is no > > longer relative. so for example to get the absolute time of the object > > dhcpClientLastResponse: > > > > current_time_on_mgmt_platform - sysUpTime + dhcpClientLastResponse > > That's understood. The problem I have is when sysUpTime resets to 0. > > > > i agree this could be a problem, however this is a general SNMP agent > > problem. i don't think that we should try to solve this. > there have been > > many long discussions on the SNMPv3 list about this. > > That's good to hear. > > -Ryan > > From dhcp-v4@bucknell.edu Thu Jan 14 18:42:50 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.7.249]) by ietf.org (8.8.5/8.8.7a) with ESMTP id SAA19160 for ; Thu, 14 Jan 1999 18:42:47 -0500 (EST) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.8.8/8.8.8) with SMTP id SAA08174; Thu, 14 Jan 1999 18:38:47 -0500 (EST) Date: Thu, 14 Jan 1999 18:38:47 -0500 (EST) Message-Id: Errors-To: droms@bucknell.edu Reply-To: dhcp-v6@bucknell.edu Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: dhcp-v6@bucknell.edu (by way of Ralph Droms) To: Multiple recipients of list Subject: Re: IMPORTANT: DHCPv6 Work in this Working X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Type: text/plain; charset="us-ascii" Mime-Version: 1.0 message sent to dhcp-v6@bucknell.edu by BRIAN@HURSLEY.IBM.COM follows. ---------------------------------------------------------------------- I'm not competent to comment technically. I do know that we need DHCPv6, so I'd urge those who feel competent to either support the drafts, or say what needs fixing. Brian Jim Bound wrote: > > Dear DHCPv6 WG, > > Charlie Perkins and I have put a lot of work into DHCPv6 and so has > Ralph Droms, and Thomas Narten. Ralph and I have asked for input from > you many times. This last flurry of mail on the final discussions is > important as we want to put this stage of DHCPv6 to bed and get to > Proposed Standard. Also up until about March 98 at least some of the WG > was working on this and before Chicago Aug 98 we had good input at the > IETF meetings or the spec would not have been ready for Last Call. But > since July and when we received the last minute last call comments in > October 98 WG input has been void. > > We are having the discussions now to resolve the WG Last Call input we > received and will be updating the specifications soon. > > Current specs are: > > draft-ietf-dhc-dhcpv6-13.txt (dhcpv6 protocol spec) > draft-ietf-dhc-v6exts-10.txt (dhcpv6 extensions for dhcpv6) > > I am very concerned about the lack of responses on this mail list and > from this working group, because the mechanism for completion of > discussion on the list by Ralph is that silence is not a valid response > as consensus for the DHC WG. This is the chairs perogative and though > different than any other WG I work on, we support this method. > > But there is nothing else I can think of to do to stimulate this WG to > work on this last part DHCPv6 to reach PS. I know at least 6 persons who > came up to me at the IETF and said "I thought we were done and moving to > Proposed Standard based on the drafts from July 1998". But we are not and > need your support. The issues which are not major protocol issues with > our design are being discussed and have been presented to the list. > > But I must assume either the list is burned out, not interested, too > busy working on dhcpv4 or other things, or whatever. > > What we told Ralph and our Internet Area Directors (Thomas and Jeff) is > we will have to be proactive to go outside of this list and get review of > these updates in the new specs to get this work completed. I am going to > start that process today and enlist the support of the IETF to get this > next spec reviewed. To leave all this review to Ralph and Thomas is simply > not fair and also not the IETF way. I know you have done work on this spec > and we appreciate it greatly to get us to where we are today. But we are > now on the home stretch and DHCPv6 is important to the deployment of > IPv6. One example is that it is a valuable transition mechanism/tool > for the interoperation of IPv4 and IPv6, and there are other deployment > reasons for real customers that will need DHCPv6. > > Also as many of you know I have been around IPv6 since its inception and > wear both an architect and implementors hat for this next generation > protocol. The folkway/more/attitude or whatever you want to call it for > IPv6 implementation to begin is normally that a spec move to Proposed > Standard. We have some implementations underway (mine included) but to > get this specification implemented we need to wrap up a DHCPv6 WG last > call and then an IETF/IESG last call. > > So as I begin to ask for help in the IETF community please do not take > this as a slam against the WG or anyone else, we cannot continue with > the silence on this mailing list. > > If you would like to respond to Charlie and I privately that is OK, but I > highly suggest and encourage you to respond to Ralph too. When I told > Ralph at Orlando about some of your comments he told me "they" need to > state those comments to me. One comment was even the DHCPv4 WG mail > list could be more active and part of the problem is that the DHC WG is > one of the oldest WGs in the IETF. But Ralph needs to hear that > directly. > > Sincerely, > /jim From dhcp-v4@bucknell.edu Thu Jan 14 22:01:21 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.7.249]) by ietf.org (8.8.5/8.8.7a) with ESMTP id WAA21193 for ; Thu, 14 Jan 1999 22:01:19 -0500 (EST) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.8.8/8.8.8) with SMTP id VAA24614; Thu, 14 Jan 1999 21:57:20 -0500 (EST) Date: Thu, 14 Jan 1999 21:57:20 -0500 (EST) Message-Id: Errors-To: droms@bucknell.edu Reply-To: droms@bucknell.edu Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Ralph Droms To: Multiple recipients of list Subject: Phone call X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Type: text/plain; charset="us-ascii" Mime-Version: 1.0 Mike - can I give you a call some time Friday or Monday? I have a couple of things to ask you about. Thanks... - Ralph From dhcp-v4@bucknell.edu Thu Jan 14 22:41:50 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.7.249]) by ietf.org (8.8.5/8.8.7a) with ESMTP id WAA23708 for ; Thu, 14 Jan 1999 22:41:49 -0500 (EST) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.8.8/8.8.8) with SMTP id WAA01959; Thu, 14 Jan 1999 22:37:52 -0500 (EST) Date: Thu, 14 Jan 1999 22:37:52 -0500 (EST) Message-Id: Errors-To: droms@bucknell.edu Reply-To: droms@bucknell.edu Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Ralph Droms To: Multiple recipients of list Subject: Re: Phone call X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Type: text/plain; charset="us-ascii" Mime-Version: 1.0 Nuts - it's the new year, and time for my annual "oops, I didn't mean to send that to the whole list" goof. Sorry for the interruptions... - Ralph From dhcp-v4@bucknell.edu Tue Jan 19 14:38:05 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.7.249]) by ietf.org (8.8.5/8.8.7a) with ESMTP id OAA25389 for ; Tue, 19 Jan 1999 14:38:01 -0500 (EST) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.8.8/8.8.8) with SMTP id OAA18632; Tue, 19 Jan 1999 14:29:18 -0500 (EST) Date: Tue, 19 Jan 1999 14:29:18 -0500 (EST) Message-Id: <19990119183313.5666.rocketmail@send102.yahoomail.com> Errors-To: droms@bucknell.edu Reply-To: shiva_s@yahoo.com Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Shiva Shenoy To: Multiple recipients of list Subject: [Q]: dhcpinform packets X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 I have a network where dhcp requests are relayed through a Relay Agent to a DHCP server. Occasionally the client sends DHCPINFORM packets. (I do not know if these DHCPINFORM packets are being unicast to the the DHCP server or brodcast) >From the trace captured on the side of the DHCP server, I see that these DHCPINFORM packets arrive at the server with the giaddr field stamped with the address of the relay agent. According to RFC2131, the server should unicast the packet to the address in 'ciaddr'. However from the packet trace, I see that the ACKs are being unicast to the relay agent. These ACKs never make it back to the client. Questions: 1. Are clients required to send the DHCPINFORM packets unicast to the server ? Or should they be broadcast ? 2. Has anybody seen implementations of dhcp servers which behave as described above ? Thanks, -SS _________________________________________________________ DO YOU YAHOO!? Get your free @yahoo.com address at http://mail.yahoo.com From dhcp-v4@bucknell.edu Tue Jan 19 17:42:05 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.7.249]) by ietf.org (8.8.5/8.8.7a) with ESMTP id RAA01461 for ; Tue, 19 Jan 1999 17:41:58 -0500 (EST) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.8.8/8.8.8) with SMTP id RAA01799; Tue, 19 Jan 1999 17:36:00 -0500 (EST) Date: Tue, 19 Jan 1999 17:36:00 -0500 (EST) Message-Id: <4.1.19990119135246.00959300@mail.join.com> Errors-To: droms@bucknell.edu Reply-To: robs@join.com Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Rob Stevens To: Multiple recipients of list Subject: Re: [Q]: dhcpinform packets X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Type: text/plain; charset="us-ascii" Mime-Version: 1.0 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 At 02:33 PM 1/19/99 -0500, Shiva Shenoy wrote: > >I have a network where dhcp requests are relayed through a Relay >Agent to a DHCP server. Occasionally the client sends >DHCPINFORM packets. (I do not know if these DHCPINFORM >packets are being unicast to the the DHCP server or brodcast) >>From the trace captured on the side of the DHCP server, I see that >these DHCPINFORM packets arrive at the server with the giaddr >field stamped with the address of the relay agent. They must be broadcast. The relay agent would not insert giaddr on a unicast packet. (And in fact it might not insert giaddr even on a local broadcast packet, dropping it instead). > >According to RFC2131, the server should unicast the packet >to the address in 'ciaddr'. However from the packet trace, I see >that the ACKs are being unicast to the relay agent. These ACKs >never make it back to the client. Yes. According to rfc1542 (Wimer) the server should unicast back to ciaddr if it is non-zero without regard to the value in giaddr. I must confess that our server does not do this: it looks at giaddr first. I think this is because we had some problems early on with clients setting ciaddr improperly (when they were not willing to respond to ARP) > >Questions: >1. Are clients required to send the DHCPINFORM packets unicast > to the server ? Or should they be broadcast ? I think it is a grey area. It makes sense to broadcast, because then only the relay agents need know where the server are. >2. Has anybody seen implementations of dhcp servers which > behave as described above ? Perforce, yes. > From dhcp-v4@bucknell.edu Tue Jan 19 17:43:16 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.7.249]) by ietf.org (8.8.5/8.8.7a) with ESMTP id RAA01533 for ; Tue, 19 Jan 1999 17:43:14 -0500 (EST) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.8.8/8.8.8) with SMTP id RAA06130; Tue, 19 Jan 1999 17:38:39 -0500 (EST) Date: Tue, 19 Jan 1999 17:38:39 -0500 (EST) Message-Id: <19990119222357.1490.rocketmail@send104.yahoomail.com> Errors-To: droms@bucknell.edu Reply-To: shiva_s@yahoo.com Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Shiva Shenoy To: Multiple recipients of list Subject: Re: [Q]: dhcpinform packets X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Rob, In such a case, ( where the server unicasts the ACK back to the relay agent, instead of the client), the relay agent has no easy way to distinguish between the ACK for the DHCPINFORM packet and other ACKs. Should the relay agent drop this ACK since the 'yiaddr' is zero ? If not, should the relay agent interpret the 'ciaddr' and unicast it to this address ? Thanks for the answer. - SS ---Rob Stevens wrote: > > At 02:33 PM 1/19/99 -0500, Shiva Shenoy wrote: > > > >I have a network where dhcp requests are relayed through a Relay > >Agent to a DHCP server. Occasionally the client sends > >DHCPINFORM packets. (I do not know if these DHCPINFORM > >packets are being unicast to the the DHCP server or brodcast) > >>From the trace captured on the side of the DHCP server, I see that > >these DHCPINFORM packets arrive at the server with the giaddr > >field stamped with the address of the relay agent. > > They must be broadcast. The relay agent would not insert giaddr > on a unicast packet. (And in fact it might not insert giaddr even > on a local broadcast packet, dropping it instead). > > > >According to RFC2131, the server should unicast the packet > >to the address in 'ciaddr'. However from the packet trace, I see > >that the ACKs are being unicast to the relay agent. These ACKs > >never make it back to the client. > > Yes. According to rfc1542 (Wimer) the server should unicast back > to ciaddr if it is non-zero without regard to the value in giaddr. > I must confess that our server does not do this: it looks at giaddr > first. I think this is because we had some problems early on with > clients setting ciaddr improperly (when they were not willing to respond > to ARP) > > > >Questions: > >1. Are clients required to send the DHCPINFORM packets unicast > > to the server ? Or should they be broadcast ? > > I think it is a grey area. It makes sense to broadcast, because > then only the relay agents need know where the server are. > > >2. Has anybody seen implementations of dhcp servers which > > behave as described above ? > > Perforce, yes. > > > _________________________________________________________ DO YOU YAHOO!? Get your free @yahoo.com address at http://mail.yahoo.com From dhcp-v4@bucknell.edu Wed Jan 20 12:50:15 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.7.249]) by ietf.org (8.8.5/8.8.7a) with ESMTP id MAA22697 for ; Wed, 20 Jan 1999 12:50:12 -0500 (EST) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.8.8/8.8.8) with SMTP id MAA29745; Wed, 20 Jan 1999 12:41:11 -0500 (EST) Date: Wed, 20 Jan 1999 12:41:11 -0500 (EST) Message-Id: <199901201706.MAA07655@funnel.cisco.com> Errors-To: droms@bucknell.edu Reply-To: kkinnear@cisco.com Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Kim Kinnear To: Multiple recipients of list Subject: Re: [Q]: dhcpinform packets X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Type: text/plain; charset="us-ascii" Mime-Version: 1.0 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 At 05:37 PM 1/19/99 -0500, Rob Stevens wrote: > >Yes. According to rfc1542 (Wimer) the server should unicast back >to ciaddr if it is non-zero without regard to the value in giaddr. >I must confess that our server does not do this: it looks at giaddr >first. I think this is because we had some problems early on with >clients setting ciaddr improperly (when they were not willing to respond >to ARP) Interesting... In RFC 2131, page 23, 4th full paragraph: "If the 'giaddr' field in a DHCP message from a client is non-zero, the server sends any return messages to the 'DHCP server' port on the BOOTP relay agent whose address appears in 'giaddr'. If the 'giaddr' field is zero and the 'ciaddr' field is non-zero, then the server unicasts DHCPOFFER and DHCPACK messages to the address in 'ciaddr'. ..." This might explain why your server looks at giaddr first, as does ours. Cheers -- Kim From dhcp-v4@bucknell.edu Sat Jan 23 14:25:33 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.7.249]) by ietf.org (8.8.5/8.8.7a) with ESMTP id OAA26139 for ; Sat, 23 Jan 1999 14:25:32 -0500 (EST) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.8.8/8.8.8) with SMTP id OAA14377; Sat, 23 Jan 1999 14:21:50 -0500 (EST) Date: Sat, 23 Jan 1999 14:21:50 -0500 (EST) Message-Id: Errors-To: droms@bucknell.edu Reply-To: r.j.letts@salford.ac.uk Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: "Richard Letts" To: Multiple recipients of list Subject: Re: [Q]: dhcpinform packets X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Type: TEXT/PLAIN; charset=US-ASCII Mime-Version: 1.0 On Tue, 19 Jan 1999, Rob Stevens wrote: > >Questions: > >1. Are clients required to send the DHCPINFORM packets unicast > > to the server ? Or should they be broadcast ? > > I think it is a grey area. It makes sense to broadcast, because > then only the relay agents need know where the server are. DHCPinform is used by client to elicit further information from the dhcp server. the client already needs to keep track of where it obtained its lease from. HOWEVER the DHCPinform doesn't need to obtain the information from the same sever that gave it its address. IMHO broadcast is the better option for DHCPinform packets. (an example of this would be where a ISC DHCP server tells a winNT+NW5 client what its IP address is, but a NetWare5 DHCP server tells the client which tree and which context to use.. will this work? I'll know in a cuople of weeks when I try it in practice) Richard Letts mail: R.J.Letts@ais.salford.ac.uk Network Services Manager phone: +44 161 295 5252 University of Salford fax: +44 161 295 5888 Great Britain mobile: +44 385 275394 From dhcp-v4@bucknell.edu Sun Jan 24 21:19:31 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.7.249]) by ietf.org (8.8.5/8.8.7a) with ESMTP id VAA06342 for ; Sun, 24 Jan 1999 21:19:31 -0500 (EST) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.8.8/8.8.8) with SMTP id VAA21528; Sun, 24 Jan 1999 21:15:55 -0500 (EST) Date: Sun, 24 Jan 1999 21:15:55 -0500 (EST) Message-Id: <000001be4804$a3fba680$c0060280@kryten> Errors-To: droms@bucknell.edu Reply-To: ryan@andrew.cmu.edu Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: "Ryan Troll" To: Multiple recipients of list Subject: DHCP Auto-Configure Option Draft X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Content-Type: text/plain; Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id VAA06342 I've submitted a new version of this draft to the archive. This version contains all of the requested changes per the IESG last call. The only outstanding issue I know of is Mike Carney's comment of 12/17/98: - Using DHCPOFFERs w/ a yiaddr of 0.0.0.0 violates RFC2131. Rather than overloading a DHCPOFFER, why not define a new message type? I know that what I'm suggesting is basicly a hack to get this functionality into the existing protocol, with no major changes. A new option would be another way to go. I can't say which would be better, if there is a better way. What do the rest of you think? -Ryan From dhcp-v4@bucknell.edu Tue Jan 26 16:09:44 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.7.249]) by ietf.org (8.8.5/8.8.7a) with ESMTP id QAA04386 for ; Tue, 26 Jan 1999 16:09:43 -0500 (EST) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.8.8/8.8.8) with SMTP id QAA05570; Tue, 26 Jan 1999 16:02:34 -0500 (EST) Date: Tue, 26 Jan 1999 16:02:34 -0500 (EST) Message-Id: Errors-To: droms@bucknell.edu Reply-To: droms@bucknell.edu Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Ralph Droms To: Multiple recipients of list Subject: Last Call on DHCP Options for SLP X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Type: text/plain; charset="us-ascii" Mime-Version: 1.0 This is a WG last call for comments on DHCP Options for SLP . Please respond to the dhcp-v4@bucknell.edu mailing list with comments by 3/5/99. If there are no comments, the draft will be submitted for acceptance as a Proposed Standard. - Ralph Droms From dhcp-v4@bucknell.edu Tue Jan 26 16:16:43 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.7.249]) by ietf.org (8.8.5/8.8.7a) with ESMTP id QAA04668 for ; Tue, 26 Jan 1999 16:16:42 -0500 (EST) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.8.8/8.8.8) with SMTP id QAA16482; Tue, 26 Jan 1999 16:09:53 -0500 (EST) Date: Tue, 26 Jan 1999 16:09:53 -0500 (EST) Message-Id: Errors-To: droms@bucknell.edu Reply-To: droms@bucknell.edu Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Ralph Droms To: Multiple recipients of list Subject: Re: DHCP Auto-Configure Option Draft X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Type: text/plain; charset="us-ascii" Mime-Version: 1.0 At 9:21 PM -0500 1/24/99, Ryan Troll wrote: >I've submitted a new version of this draft to the archive. This version >contains all of the requested changes per the IESG last call. The only >outstanding issue I know of is Mike Carney's comment of 12/17/98: > > > - Using DHCPOFFERs w/ a yiaddr of 0.0.0.0 violates RFC2131. Rather than > overloading a DHCPOFFER, why not define a new message type? > > >I know that what I'm suggesting is basicly a hack to get this >functionality into the existing protocol, with no major changes. A new >option would be another way to go. I can't say which would be better, if >there is a better way. > >What do the rest of you think? I would like to get this draft to last call in time for the IESG to consider it prior to the next IETF. That means it should go to last call no later than early next week. If you have any comments on Ryan's issue, please respond to the mailing list before this coming Friday, 1/29. - Ralph From dhcp-v4@bucknell.edu Tue Jan 26 17:41:50 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.7.249]) by ietf.org (8.8.5/8.8.7a) with ESMTP id RAA07242 for ; Tue, 26 Jan 1999 17:41:49 -0500 (EST) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.8.8/8.8.8) with SMTP id RAA22686; Tue, 26 Jan 1999 17:37:02 -0500 (EST) Date: Tue, 26 Jan 1999 17:37:02 -0500 (EST) Message-Id: <199901262212.RAA09647@wasabi.lcs.mit.edu> Errors-To: droms@bucknell.edu Reply-To: hhh@wasabi.lcs.mit.edu Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Henry Houh To: Multiple recipients of list Subject: Please comment on my draft: DHCP Option for Call Control Servers X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Hi, I'm new to this process so I don't know the procedure, though I have read the info for new IETF folks and other info that I have been able to find. If I have submitted this in an improper fashion or not named it correctly, please let me know the correct way to get this in front of the working group. I would like to introduce a draft for a new DHCP option to support location of call control servers (like an H.323 gatekeeper). There are many new products available that have stand-alone IP-telephone endpoints. This option would facilitate the setup of these endpoints so as to eliminate any configuration necessary for these IP telephones to locate their call control servers. I have tried to do this in a way that allows other vendors with products to add to this option, but I would like comments on whether the method to add a new sub-option is acceptable - I have tried to mirror the method new options are added, and this may be too heavyweight a method. Also, I have not made any assumptions on who else would like to use this option. Comments on the draft are appreciated, Thanks, Henry Houh NBX Corporation Internet Engineering Task Force Henry Houh INTERNET DRAFT NBX Corporation November 1998 Expires May 1999 DHCP Options for Call Control Servers Status of This Memo This document is a submission to the Dynamic Host Configuration Working Group of the Internet Engineering Task Force (IETF). Comments should be submitted to the dhcp-v4@bucknell.edu mailing list. Distribution of this memo is unlimited. This document is an Internet-Draft. 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 obsoleted 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.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (North Europe), ftp.nis.garr.it (South Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Abstract This document defines a new DHCP option for delivering configuration information to telephony enabled hosts in order to locate a call control/signalling server. The option carries several operational parameters that allow multiple call control vendors to utilize this field. 1. Introduction Telephony is emerging as a network-based application. The Call Control Server option allows telephony or gateway devices which cannot independently setup up and signal calls to automatically discover an address of a call control server. Houh Expires May 1999 [Page 1] Internet Draft DHCP Option for Call Control Servers November 1998 This specification describes a DHCP option [1] that can carry one or several Call Control Server sub-options. Each sub-option is treated as a separate potential call control server by the hosts. 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. [2] 2. Call Control Server Option This option specifies one or more fields carrying Call Control Server information. The fields that can be carried by this option are described in the sections that follow. The code for this option is TBD, and its maximum length is 255 octets. Code Len Sub-Option 1 Sub-Option 2 +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-- | TBD | n | a1 | a2 | a3 | a4 | a1 | a2 | a3 | a4 | ... +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-- The 'Len' field specifies the number of octets containing sub-option information within the DHCP option. Each sub-option will contain a code followed by a length that specifies the number of octets containing configuration parameter information within the sub-option. Sub Sub Code Len Configuration Parameter(s) +-----+-----+-----+-----+-----+-----+-----+-----+-- | x | n | a1 | a2 | a3 | a4 | a6 | a7 | ... +-----+-----+-----+-----+-----+-----+-----+-----+-- 2.1. Call Control Servers This section describes the vendor-specific sub-options. Other types/vendors of call control servers can be added by using new sub-option fields. See section 2.2 for the procedure for adding sub-option fields. 2.1.1 NBX Call Control Server Sub-option This sub-option specifies the network address of an NBX Call Control Server. Houh Expires May 1999 [Page 2] Internet Draft DHCP Option for Call Control Servers November 1998 The code for this sub-option is 1. The length specified in the 'Len' field of this sub-option MUST always be 4 octets. Code Len NBX Server Address +-----+-----+-----+-----+-----+-----+ | 1 | 4 | a1 | a2 | a3 | a4 | +-----+-----+-----+-----+-----+-----+ 2.2 Procedure for adding call control server types A vendor may add a new sub-option field by issuing an internet draft that contains the new sub-option. The new sub-option field code MUST be labeled "TBD." This draft will then be submitted to the DHC working group, and, if accepted for inclusion in the DHCP specification, a sub-option field code is assigned and the sub-option specification is published as an RFC which updates this RFC. 3. Using Multiple Sub-options More than one sub-option field MAY be returned to the host. In addition, more than one of any sub-option type MAY be present. This allows the host to select the call control server appropriate to own its signaling protocol, allowing a single DHCP server to support multiple homogeneous call control servers as well as heterogeneous telephony and gateway devices. 4. References [1] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC-2132, March 1997. [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC-2119, March 1997. [3] Droms, R., "Dynamic Host Configuration Protocol", RFC-2131, March 1997. 5. Security Considerations DHCP currently provides no authentication or security mechanisms. Potential exposures to attack are discussed in section 7 of the DHCP protocol specification [3]. In particular, these DHCP options allow an unauthorized DHCP server to misdirect a telephone or gateway host to an unauthorized call control server. Houh Expires May 1999 [Page 3] Internet Draft DHCP Option for Call Control Servers November 1998 6. Author's Address Henry Houh NBX Corporation 100 Brickstone Square Andover, MA 01810 Phone: +1 978 740 0000 x257 EMail: hhouh@nbxcorp.com Houh Expires May 1999 [Page 4] From dhcp-v4@bucknell.edu Tue Jan 26 19:10:02 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.7.249]) by ietf.org (8.8.5/8.8.7a) with ESMTP id TAA08752 for ; Tue, 26 Jan 1999 19:10:01 -0500 (EST) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.8.8/8.8.8) with SMTP id TAA05859; Tue, 26 Jan 1999 19:06:52 -0500 (EST) Date: Tue, 26 Jan 1999 19:06:52 -0500 (EST) Message-Id: Errors-To: droms@bucknell.edu Reply-To: dhcp-v4@bucknell.edu Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: dhcp-v4@bucknell.edu (by way of Ralph Droms) To: Multiple recipients of list Subject: RE: Last Call on DHCP Options for SLP X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Type: text/plain; charset="us-ascii" Mime-Version: 1.0 message sent to dhcp-v4@bucknell.edu by GLENN_WATERS@CORPEAST.BAYNETWORKS.COM follows. ------------------------------------------------------------------------------- the SLP Service Scope Option still requires a one byte "mandatory" field within the option. at the last ietf i thought we concocted a scheme where the mandatory field was not required. my preference is that we define options using only the well defined set of types that have previously been used in option definition and not introduce a new encoding within an option. this option introduces a "structure" encoding within the option. if there is a strong requirement for this type of feature going forward, then i would like to see the dhcp advisory panel address this in a standard. by doing so, dhcp configuration systems can be built to allow for data driven configuration of new options. the SLP Service Scope option requires that new option 79 specific code be added to our product (and likely a number of other vendors products). in summary, generic new code is good. specific to an option new code is bad. option 79 requires the latter. thus i am not in favour of this draft going forward in its current form. /gww > -----Original Message----- > From: dhcp-v4@bucknell.edu [mailto:dhcp-v4@bucknell.edu]On Behalf Of > Ralph Droms > Sent: Tuesday, January 26, 1999 16:06 > To: Multiple recipients of list > Subject: Last Call on DHCP Options for SLP > > > This is a WG last call for comments on DHCP Options for SLP > . Please respond to the dhcp-v4@bucknell.edu > mailing list with comments by 3/5/99. If there are no comments, the draft > will be submitted for acceptance as a Proposed Standard. > > - Ralph Droms > From dhcp-v4@bucknell.edu Tue Jan 26 23:18:50 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.7.249]) by ietf.org (8.8.5/8.8.7a) with ESMTP id XAA12590 for ; Tue, 26 Jan 1999 23:18:50 -0500 (EST) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.8.8/8.8.8) with SMTP id XAA18229; Tue, 26 Jan 1999 23:15:29 -0500 (EST) Date: Tue, 26 Jan 1999 23:15:29 -0500 (EST) Message-Id: <000001be49a6$0c6818a0$c0060280@kryten> Errors-To: droms@bucknell.edu Reply-To: ryan@andrew.cmu.edu Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: "Ryan Troll" To: Multiple recipients of list Subject: get dhcp-v4 log9812 X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; Mime-Version: 1.0 get dhcp-v4 log9812 From dhcp-v4@bucknell.edu Wed Jan 27 19:37:33 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.7.249]) by ietf.org (8.8.5/8.8.7a) with ESMTP id TAA09742 for ; Wed, 27 Jan 1999 19:37:31 -0500 (EST) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.8.8/8.8.8) with SMTP id TAA20316; Wed, 27 Jan 1999 19:31:49 -0500 (EST) Date: Wed, 27 Jan 1999 19:31:49 -0500 (EST) Message-Id: <204324BF087AD211A43A00805F65C13305AD0E@tibet.coppermountain.com> Errors-To: droms@bucknell.edu Reply-To: emichelsen@coppermountain.com Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Eric Michelsen To: Multiple recipients of list Subject: Colliding on Vendor Class Identification? X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Type: text/plain; X-Mailer: Internet Mail Service (5.5.2232.9) Mime-Version: 1.0 I didn't find any reference to this on the web. As I read 2131 and 2132, it is possible for two vendors to inadvertently choose the same vendor class id, and hence conflict with each other. Is there a recommended (or documented) way to avoid this? Am I misunderstanding? ___________________________________________ Eric L. Michelsen, Copper Mountain Networks From dhcp-v4@bucknell.edu Wed Jan 27 19:42:56 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.7.249]) by ietf.org (8.8.5/8.8.7a) with ESMTP id TAA09797 for ; Wed, 27 Jan 1999 19:42:55 -0500 (EST) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.8.8/8.8.8) with SMTP id TAA22645; Wed, 27 Jan 1999 19:39:44 -0500 (EST) Date: Wed, 27 Jan 1999 19:39:44 -0500 (EST) Message-Id: Errors-To: droms@bucknell.edu Reply-To: mumehta@mtu.edu Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Munish Mehta To: Multiple recipients of list Subject: DHCP client from ROOT Floppy X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Type: TEXT/PLAIN; charset=US-ASCII Mime-Version: 1.0 Hi, I am a newbie to the world of DHCP. I am not sure if I can specify my problems appropriately. Here's a try: I have copied "dhcpcd" to my root floppy of the Linux machine. I have also made "/etc/dhcp" directory. I have edited the /etc/rc.d/rc.inet1 and put "/sbin/dhcpcd" there. When I boot the machine using boot/root floppy, this line doesn't give any error but it doesn't recognize the ethernet interface either. It seems it is not able to connect DHCP server. On the contrary, a windows machine on the same network when booted can get IP address from the DHCP server (meaning that server is working fine). I have configured server to give IP addresses based on hardware addresses of the clients. Could anyone please let me know if "dhcpcd" needs any other files, or any configurations to be able to run. Please explain from the point of view of a boot/root floppy system. I want my clients to be able to get IP addresses from the DHCP server based on their hardware addresses, whenever they are booted using boot/root floppy. ---- I also compiled DHCP client on a linux machine by using "make" and "make install". This linux machine is already has an I.P. address. If i run "dhcpcd" here, it also exits ( i think it is supposed to stay as a daemon). I did an strace on it and the results are : execve("/sbin/dhcpcd", ["/sbin/dhcpcd"], [/* 21 vars */]) = 0 personality(0 /* PER_??? */) = 0 getpid() = 1236 geteuid() = 0 getuid() = 0 getegid() = 0 getgid() = 0 getuid() = 0 open(ptrace: umoven: Input/output error 0xbffffd74, O_RDONLY) = -1 ENOENT (No such file or directory) sigaction(SIGHUP, NULL, {SIG_DFL}) = 0 sigaction(SIGHUP, {0x8048f2c, [], SA_STACK|SA_RESTART|SA_INTERRUPT|SA_ONESHOT|0x7fffd94}, NULL) = 0 sigaction(SIGINT, {0x8048f2c, [], SA_STACK|SA_RESTART|SA_INTERRUPT|SA_ONESHOT|0x7fffd94}, NULL) = 0 sigaction(SIGQUIT, {0x8048f2c, [], SA_STACK|SA_RESTART|SA_INTERRUPT|SA_ONESHOT|0x7fffd94}, NULL) = 0 sigaction(SIGILL, {0x8048f2c, [], SA_STACK|SA_RESTART|SA_INTERRUPT|SA_ONESHOT|0x7fffd94}, NULL) = 0 sigaction(SIGTRAP, {0x8048f2c, [], SA_STACK|SA_RESTART|SA_INTERRUPT|SA_ONESHOT|0x7fffd94}, NULL) = 0 sigaction(SIGABRT, {0x8048f2c, [], SA_STACK|SA_RESTART|SA_INTERRUPT|SA_ONESHOT|0x7fffd94}, NULL) = 0 sigaction(SIGBUS, {0x8048f2c, [], SA_STACK|SA_RESTART|SA_INTERRUPT|SA_ONESHOT|0x7fffd94}, NULL) = 0 sigaction(SIGFPE, {0x8048f2c, [], SA_STACK|SA_RESTART|SA_INTERRUPT|SA_ONESHOT|0x7fffd94}, NULL) = 0 sigaction(SIGKILL, {0x8048f2c, [], SA_STACK|SA_RESTART|SA_INTERRUPT|SA_ONESHOT|0x7fffd94}, NULL) = -1 EINVAL (Invalid argument) sigaction(SIGUSR1, {0x8048f2c, [], SA_STACK|SA_RESTART|SA_INTERRUPT|SA_ONESHOT|0x7fffd94}, NULL) = 0 sigaction(SIGSEGV, {0x8048f2c, [], SA_STACK|SA_RESTART|SA_INTERRUPT|SA_ONESHOT|0x7fffd94}, NULL) = 0 sigaction(SIGUSR2, {0x8048f2c, [], SA_STACK|SA_RESTART|SA_INTERRUPT|SA_ONESHOT|0x7fffd94}, NULL) = 0 sigaction(SIGPIPE, {0x8048f2c, [], SA_STACK|SA_RESTART|SA_INTERRUPT|SA_ONESHOT|0x7fffd94}, NULL) = 0 sigaction(SIGALRM, {0x8048f2c, [], SA_STACK|SA_RESTART|SA_INTERRUPT|SA_ONESHOT|0x7fffd94}, NULL) = 0 sigaction(SIGTERM, {0x8048f2c, [], SA_STACK|SA_RESTART|SA_INTERRUPT|SA_ONESHOT|0x7fffd94}, NULL) = 0 alarm(60) = 0 socket(0x11 /* PF_??? */, SOCK_PACKET, 768) = -1 EINVAL (Invalid argument) brk(0) = 0x807a818 brk(0x807a8a8) = 0x807a8a8 brk(0x807b000) = 0x807b000 brk(0x807e000) = 0x807e000 time([917457217]) = 917457217 open("/etc/localtime", O_RDONLY) = 3 fstat(3, {st_dev=makedev(0, 2), st_ino=0, st_mode=0, st_nlink=1250, st_uid=1024, st_gid=4, st_blksize=907934799, st_blocks=0, st_size=0, st_atime=0, st_mtime=35/12/23-04:55:56, st_ctime=69/12/31-19:00:03}) = 0 mmap(0, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40000000 read(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 1024) = 1024 read(3, "\2\1\2\1\0\1\2\1\2\1\2\1\2\1\2\1"..., 1024) = 226 close(3) = 0 munmap(0x40000000, 4096) = 0 getpid() = 1236 sigaction(SIGPIPE, {0x8052240, [], 0}, {0x8048f2c, [], 0}) = 0 socket(PF_UNIX, SOCK_DGRAM, 0) = 3 fcntl(3, F_SETFD, FD_CLOEXEC) = 0 connect(3, {sun_family=AF_UNIX, sun_path="/dev/log"}, 16) = -1 EPROTOTYPE (Protocol wrong type for socket) close(3) = 0 socket(PF_UNIX, SOCK_STREAM, 0) = 3 fcntl(3, F_SETFD, FD_CLOEXEC) = 0 connect(3, {sun_family=AF_UNIX, sun_path="/dev/log"}, 16) = 0 send(3, "<131>Jan 27 12:13:37 dhcpcd[1236"..., 72, 0) = 72 sigaction(SIGPIPE, {0x8048f2c, [], 0}, NULL) = 0 _exit(1) = ? Can anybody kindly let me know why it exits. I will be highly thankful for any help. thanks, Munish From dhcp-v4@bucknell.edu Wed Jan 27 19:43:48 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.7.249]) by ietf.org (8.8.5/8.8.7a) with ESMTP id TAA09818 for ; Wed, 27 Jan 1999 19:43:48 -0500 (EST) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.8.8/8.8.8) with SMTP id TAA08247; Wed, 27 Jan 1999 19:40:21 -0500 (EST) Date: Wed, 27 Jan 1999 19:40:21 -0500 (EST) Message-Id: <63D30D6E10CFD11190A90000F805FE86B041FA@lespaul.process.com> Errors-To: droms@bucknell.edu Reply-To: Gonczi@process.com Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Steve Gonczi To: Multiple recipients of list Subject: FW: Proposed Agenda/Info for 2nd DHCP Schema Meeting X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Type: text/plain; X-Mailer: Internet Mail Service (5.0.1460.8) Mime-Version: 1.0 Greetings, I am posting this for Linda Scobo (PSC). Please e-mail or call her directly. Anyone interested is welcome to attend. Steve Gonczi > Proposed Agenda for the 2nd DHCP Schema Meeting > > Monday, February 8, 1999, 10AM - 5:30PM > > * Meeting logistics > * Agenda bashing > * Review of 1st DHCP schema meeting > * See materials available at http://www.process.com/schema.htm. > * DMTF Networks Working Group's DHCP goals and status (Note 1) > * Existing DHCP schema presentations (Note 2) > * Repeat presentations from 1st meeting with updates > * New participates might want to present their schema or needs for a > schema > * Further refine object model from 1st DHCP schema meeting > * Object relationships > > Tuesday, February 9, 1999, 9AM - noon (or whenever people want to stop) > > * Develop list of attributes, focusing on > * Attribute description and meaning, not names > * Possible attribute values or encoding > * Objects that will have each attribute > * Relationship between attributes > * What next? > * Develop Internet-Draft? If so, need authors > * Provide input to DMTF? > * Other options? > * Next meeting? > * Adjourn > > Agenda Notes: > 1. Need to line up Andrea from Microsoft or Lee from IBM to do this as > they likely know the most. > 2. Anyone that would like to present, please notify Linda Scobo as soon > as possible. These should be relatively short, providing a quick overview > of how the schema is laid out, unique or interesting features, and any > significant differences from other schema. > > Meeting Logistics: > > * Meeting will be held at the Process Software offices in Framingham, > Massachusetts. Directions are available at > http://www.process.com/comment.htp. The offices are about 25 miles west of > downtown Boston and Logan International Airport. > * Process Software will provide lunch and refreshments during both > days of the meeting. > * While the meeting is currently scheduled to end mid-day on the 9th, > if sufficient interest exists we can extend until the end of the day. > > > If you have any questions, need lodging information, etc., please contact > Linda Scobo at 508-879-6994 x 345 or scobo@process.com. From dhcp-v4@bucknell.edu Wed Jan 27 21:57:36 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.7.249]) by ietf.org (8.8.5/8.8.7a) with ESMTP id VAA10765 for ; Wed, 27 Jan 1999 21:57:35 -0500 (EST) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.8.8/8.8.8) with SMTP id VAA02432; Wed, 27 Jan 1999 21:54:05 -0500 (EST) Date: Wed, 27 Jan 1999 21:54:05 -0500 (EST) Message-Id: Errors-To: droms@bucknell.edu Reply-To: Michael.Carney@East.Sun.COM Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Mike Carney - SNT Internet Engineering To: Multiple recipients of list Subject: Re: Colliding on Vendor Class Identification? X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Type: MULTIPART/MIXED; BOUNDARY="-LA_F2157770563R-1106117653A-917488929=:454NCE.Roam" Mime-Version: 1.0 ---LA_F2157770563R-1106117653A-917488929=:454NCE.Roam Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Hi Eric, Please see the attached w.r.t. avoiding vendor class id collision. ---LA_F2157770563R-1106117653A-917488929=:454NCE.Roam Content-Type: APPLICATION/OCTET-STREAM Content-Transfer-Encoding: BASE64 Content-Description: mail-file RnJvbSBtd2NAYXRsYW50aWMgV2VkIE1hciAyNSAxMTo1Mzo1OCAxOTk4ClJl dHVybi1QYXRoOiA8ZGhjcC12NEBidWNrbmVsbC5lZHU+ClJlY2VpdmVkOiBm cm9tIEVhc3QuU3VuLkNPTSAoZWFzdG1haWwxIFsxMjkuMTQ4LjEuMjQwXSkK CWJ5IGF0bGFudGljLmVhc3Quc3VuLmNvbSAoOC44LjgrU3VuK3NhK3JlK2hy LzguOC44KSB3aXRoIFNNVFAgaWQgV0FBMDE1NjUKCWZvciA8bXdjQGF0bGFu dGljPjsgTW9uLCAyMyBNYXIgMTk5OCAyMjoxMjo0MCAtMDUwMCAoRVNUKQpS ZWNlaXZlZDogZnJvbSBlYXJ0aC5zdW4uY29tIGJ5IEVhc3QuU3VuLkNPTSAo U01JLTguNi9TTUktNS4zKQoJaWQgV0FBMjMwMzY7IE1vbiwgMjMgTWFyIDE5 OTggMjI6MTA6NTUgLTA1MDAKUmVjZWl2ZWQ6IGZyb20gbWFpbC5idWNrbmVs bC5lZHUgKG1hcmdlLmJ1Y2tuZWxsLmVkdSBbMTM0LjgyLjcuMjQ5XSkKCWJ5 IGVhcnRoLnN1bi5jb20gKDguOC44LzguOC44KSB3aXRoIEVTTVRQIGlkIFRB QTI5OTgzOwoJTW9uLCAyMyBNYXIgMTk5OCAxOToxMDo1MSAtMDgwMCAoUFNU KQpSZWNlaXZlZDogZnJvbSByZWVmLmJ1Y2tuZWxsLmVkdSAocmVlZi5idWNr bmVsbC5lZHUgWzEzNC44Mi43LjZdKQoJYnkgbWFpbC5idWNrbmVsbC5lZHUg KDguOC44LzguOC44KSB3aXRoIFNNVFAgaWQgV0FBMDA2NTM7CglNb24sIDIz IE1hciAxOTk4IDIyOjEwOjI2IC0wNTAwIChFU1QpCkRhdGU6IE1vbiwgMjMg TWFyIDE5OTggMjI6MTA6MjYgLTA1MDAgKEVTVCkKTWVzc2FnZS1JZDogPFJv YW0uU0lNQy4yLjAuNi44OTA3MDc2NTguMjMzMDQubXdjQGF0bGFudGljLmVh c3Quc3VuLmNvbS4+CkVycm9ycy1UbzogZHJvbXNAYnVja25lbGwuZWR1ClJl cGx5LVRvOiBkaGNwLXY0QGJ1Y2tuZWxsLmVkdQpPcmlnaW5hdG9yOiBkaGNw LXY0QGJ1Y2tuZWxsLmVkdQpTZW5kZXI6IGRoY3AtdjRAYnVja25lbGwuZWR1 ClByZWNlZGVuY2U6IGJ1bGsKRnJvbTogTWlrZSBDYXJuZXkgLSBTTlQgSW50 ZXJuZXQgRW5naW5lZXJpbmcgPE1pY2hhZWwuQ2FybmV5QGVhc3RtYWlsMi5F YXN0LlN1bi5DT00+ClRvOiBNdWx0aXBsZSByZWNpcGllbnRzIG9mIGxpc3Qg PGRoY3AtdjRAYnVja25lbGwuZWR1PgpTdWJqZWN0OiBSRkMgMjEzMSBjb21t ZW50cwpYLUxpc3Rwcm9jZXNzb3ItVmVyc2lvbjogNi4wYyAtLSBMaXN0UHJv Y2Vzc29yIGJ5IEFuYXN0YXNpb3MgS290c2lrb25hcwpYLUNvbW1lbnQ6IERp c2N1c3Npb24gb2YgREhDUCBmb3IgSVB2NApDb250ZW50LVR5cGU6IFRFWFQv UExBSU47IENIQVJTRVQ9VVMtQVNDSUkKTWltZS1WZXJzaW9uOiAxLjAKQ29u dGVudC1MZW5ndGg6IDE1MjEwClN0YXR1czogUk8KWC1TdGF0dXM6ICQkJCQK WC1VSUQ6IDAwMDAwMDAwMjcKCgoKSGkgZm9sa3MsCgoJTXkgZGV0YWlsZWQg cmV2aWV3IG9mIHJmYzIxMzEgZm9sbG93cyBhcyBwcm9taXNlZC4gSSd2ZSBi cm9rZW4gdGhlCmluZm9ybWF0aW9uIHVwIGludG8gdGhyZWUgY2F0ZWdvcmll czogdHlwb3MsIGluY29uc2lzdGVuY2llcywgbGFjayBvZiBjbGFyaXR5LgoK CjEpIFR5cG9zL2V0YwoKCVBnIDIzLCBzZWNvbmQgcGFyYSBvZiBTZWMgNC4x IC0gInJlY2lldmVkIiAtPiAicmVjZWl2ZWQiCgoJUGcgMjMsIHNpeHRoIHBh cmEgb2YgU2VjIDQuMSAtIHJlZmVycyB0byBSRkMgMTUzMywgbm90IFJGQyAy MTMyCgoJUGcgMTUsIEZpZ3VyZSAzLiBUYWJsZSBtaXNmb3JtYXR0ZWQuCgoJ UGcgMTgsIEZpZ3VyZSA0LiBUYWJsZSBtaXNmb3JtYXR0ZWQuCgoJUGcgMjUs IGVsZXZlbnRoIHBhcmEgb2YgU2VjIDQuMSAtICJ1aWNhc3QiIC0+ICJ1bmlj YXN0IgoKCVBnIDMzLCBUYWJsZSA0IC0gbWlzc2luZyBjb2x1bW4gZm9yIERI Q1BJTkZPUk0KCglQZyAzOCwgRmlyc3QgcGFyYSBhZnRlciBUYWJsZSA1LiBP cnBoYW5lZCBzZW50ZW5jZTogIlRoZQoJREhDUFJFUVVFU1QgbWVzc2FnZSBj b250YWlucyB0aGUgc2FtZSAneGlkJyBhcyB0aGUgREhDUE9GRkVSCgltZXNz YWdlIiBObyBpdCBkb2Vzbid0LiBOb3Qgb25seSB0aGF0LCBidXQgdGhpcyBz ZW50ZW5jZSBtYWtlcwoJbm8gc2Vuc2UgaW4gaXRzIGN1cnJlbnQgbG9jYXRp b24uIEl0IHNob3VsZCBiZSByZW1vdmVkLgoKCVBnIDM5LCBMYXN0IHBhcmEg b2YgNC40LjMgc2hvdWxkIGJlIG1vdmVkIHVwIGFzIHRoZSBsYXN0IHBhcmEK CW9mIDQuNC4yLiBXaGVuIHRoZSB0ZXh0IGZvciBESENQSU5GT1JNIHdhcyBh ZGRlZCwgdGhlIHRleHQKCWRlc2NyaWJpbmcgd2hhdCBhIGNsaWVudCBzaG91 bGQgZG8gaWYgbm8gREhDUEFDSyBpcyByZWNlaXZlZCB3YXMKCW1pc3Rha2Vu bHkgcHVzaGVkIGJlbG93IGl0LgoKMikgSW5jb25zaXN0ZW5jaWVzCgoJYSkg UGcgMSwgQWJzdHJhY3QgLSAiVENQSVAiIHNob3VsZCBiZSAiVENQL0lQIiAt IGxpa2UgaXQgaXMgaW4KCXRoZSByZXN0IG9mIHRoZSBkb2N1bWVudC4KCgli KSBMYWNrIG9mIGNvbnNpc3RlbmN5IHdoZW4gZGVzY3JpYmluZyAiSVAgYnJv YWRjYXN0Ii4gU29tZXRpbWVzCglpdCdzIDB4ZmZmZmZmZmYgSVAgYnJvYWRj YXN0LCBvdGhlciB0aW1lcyAibGltaXRlZCBicm9hZGNhc3QiIG9yCgkiYnJv YWRjYXN0Ii4gSSBzdWdnZXN0IHVzaW5nIHRoZSAiMjU1LjI1NS4yNTUuMjU1 IElQIGJyb2FkY2FzdAoJYWRkcmVzcyIgZm9ybSwgYXMgdGhhdCBpcyB0aGUg bW9zdCBzcGVjaWZpYy4KCgkJUGcgMTksIHRoaXJkIHBhcmEgb2YgU2VjIDMu MiwgTGlzdCBpdGVtICMyCgoJCVBnIDIzLCBmaWZ0aCBwYXJhIG9mIFNlYyA0 LjEKCgkJUGcgMjUsIHRoaXJ0ZWVudGggcGFyYSBvZiBTZWMgNC4xCgoJCVBn IDMyLCBTZWMgNC4zLjIsIHRoaXJkIGJ1bGxldCBpdGVtCgoJCVBnIDMyLCBT ZWMgNC4zLjIsIGZpZnRoIGJ1bGxldCBpdGVtCgoJCVBnIDM2LCBzZWNvbmQg cGFyYSBvZiBTZWMgNC40LjEKCgkJUGcgMzksIGxhc3QgcGFyYSBvZiBTZWMg NC40LjEKCgkJUGcgMzksIHNlY29uZCBwYXJhIG9mIFNlYyA0LjQuMwoKCQlQ ZyA0MCwgZmlyc3QgcGFyYSBvZiA0LjQuNAoKCQlQZyA0MCwgc2Vjb25kIHBh cmEgb2YgNC40LjQKCgkJcGcgNDEsIGZpZnRoIHBhcmEgb2YgNC40LjUKCgoz KSBMYWNrIG9mIGNsYXJpdHkKCglhKSBQZyAzLCBTZWMgMS4xLCBmaXJzdCBw YXJhIC0gaW5jbHVkZXMgdGhlIGZvbGxvd2luZyBzZW50ZW5jZToKCSJUaGUg Y2xhc3NpbmcgbWVjaGFuaXNtIGZvciBpZGVudGlmeWluZyBESENQIGNsaWVu dHMgdG8gREhDUAoJc2VydmVycyBoYXMgYmVlbiBleHRlbmRlZCB0byBpbmNs dWRlICJ2ZW5kb3IiIGNsYXNzZXMgYXMgZGVmaW5lZAoJaW4gc2VjdGlvbnMg NC4yIGFuZCA0LjMiCgoJVmVuZG9yIGNsYXNzaW5nIGhhcyBiZWVuIHRoZXJl IHNpbmNlIFJGQyAxNTQxLCB0aHVzIHRoZXJlIGlzbid0Cglhbnl0aGluZyBu ZXcgYWJvdXQgaXQuIEFyZSB5b3UgdGFsa2luZyBhYm91dCBVc2VyIGNsYXNz aW5nPwoJPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PQoKCWIpIFNob3VsZCBhIERIQ1Ag c2VydmVyIHJldHVybiBhbGwgb3B0aW9ucyB0aGF0IGhhdmUgYmVlbgoJZXhw bGljaXRseSBjb25maWd1cmVkLCBvciByZXR1cm4gb25seSB0aG9zZSBvcHRp b25zIGEgY2xpZW50IGhhcwoJcmVxdWVzdGVkIHJlZ2FyZGxlc3Mgb2Ygd2hh dCBpcyBjb25maWd1cmVkIG9uIHRoZSBzZXJ2ZXI/CglDbGllbnRzIGFyZSBy ZXF1aXJlZCB0byBpbmNsdWRlIHRoZSBzYW1lIHBhcmFtZXRlciByZXF1ZXN0 IGxpc3QKCW9uIGFsbCBtZXNzYWdlcy4KCT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQoK CQlQZyA1LCBzZWNvbmQgcGFyYSBvZiBTZWMgMS4zCgoJCVBnIDIxLCBmaXJz dCBwYXJhIG9mIFNlYyAzLjUKCgkJUGcgMjksIGxpc3QgaXRlbXMgZW50aXRs ZWQgIlBhcmFtZXRlcnMgcmVxdWVzdGVkIGJ5IHRoZQoJCWNsaWVudCwgYWNj b3JkaW5nIHRvIHRoZSBmb2xsb3dpbmcgcnVsZXM6IgoKCQlQZyAzNiwgZmly c3QgcGFyYSBvZiBTZWMgNC40LjEKCglEaXNjdXNzaW9uIHBvaW50OgoJCUlN SE8sIEkgZmVlbCBhIERIQ1Agc2VydmVyIHNob3VsZCBhbHdheXMgcmV0dXJu IHdoYXQgaGFzCgliZWVuIGNvbmZpZ3VyZWQgYnkgdGhlIG5ldHdvcmsgYWRt aW5pc3RyYXRvciwgZm9yIHRoZSBmb2xsb3dpbmcKCXJlYXNvbnM6CgkJMCkg Q29uc2lzdGVuY3kuIEEgbmV0d29yayBhZG1pbmlzdHJhdG9yIHdhbnRzIGFs bCBvZiB0aGUKCQljb25maWd1cmVkIG9wdGlvbnMgdG8gc2hvdyB1cCBvbiBl YWNoIGNsaWVudCBvbiB0aGUKCQluZXR3b3JrLCByZWdhcmRsZXNzIG9mIGNs aWVudCB2ZW5kb3IuCgoJCTEpIEEgREhDUCBjbGllbnQgaXMgbGlrZWx5IG9u bHkgZ29pbmcgdG8gcmVxdWVzdCB0aGUKCQlvcHRpb25zIGl0IHN1cHBvcnRz LiBIb3dldmVyLCB0aGVyZSBhcmUgbWFueSBhcHBsaWNhdGlvbgoJCWxheWVy IG9wdGlvbnMgdGhhdCBhcmUgbm90IHVzZWQgYnkgdGhlIERIQ1AgY2xpZW50 IGJ1dAoJCWFyZSB1c2VmdWwgdG8gYXBwbGljYXRpb25zIChzZWUgIzApLgoK CQkyKSBBIERIQ1AgY2xpZW50IHdvdWxkIGVpdGhlciBuZWVkIHRvIGJlIGNv bmZpZ3VyZWQgb3IKCQl1cGRhdGVkIHRvIHJlcXVlc3QgbmV3IG9wdGlvbnMu IFRoZSB3aG9sZSBpZGVhIG9mIGRoY3AKCQlpcyB0byBrZWVwIGNvbmZpZ3Vy YXRpb24gb24gdGhlIHNlcnZlciwgbm90IG9uIHRoZQoJCWNsaWVudCwgd2hp Y2ggaXMgcG9pbnRlZCBvdXQgaW46CgoJCQlQYWdlIDcsIHNlY29uZCBhbmQg dGhpcmQgYnVsbGV0cyBvZiBTZWMgMS42LgoKCQlBdCBjb25uZWN0YXRob24s IHRoZSBhcmd1bWVudCB3YXMgbWFkZSB0aGF0IHNvbWUgREhDUAoJY2xpZW50 cyB3b3VsZCBicmVhayBpZiB0aGV5IHJlY2VpdmVkIG5ldyBvcHRpb25zLCBh bmQgdGhlcmVmb3JlCglhIERIQ1Agc2VydmVyIHNob3VsZCBvbmx5IHJldHVy biB0aGUgb3B0aW9ucyBhIGNsaWVudAoJcmVxdWVzdGVkLiBJIHRoaW5rIHRo YXQgImNsaWVudChzKSIgaXMgYnJva2VuLCBhcyBhbnkgY2xpZW50IHRoYXQK CWZvbGxvd3MgdGhlIFJGQyAxMDQ4IGZvcm0gb2YgdGhlIG9wdGlvbnMgZmll bGQgc2hvdWxkIGhhdmUgbm8KCXByb2JsZW0gcGFyc2luZy9pZ25vcmluZyBv cHRpb25zIGl0IGRvZXMgbm90IHJlY29nbml6ZS4KCQoJCUNoYW5naW5nIHRo ZSBwcm90b2NvbCB0byB3b3JrIGFyb3VuZCBidWdzIGluIHZhcmlvdXMKCWlt cGxlbWVudGF0aW9ucyBjZXJ0YWlubHkgaW1wYWN0cyBpbnRlci1vcGVyYWJp bGl0eS4gVGhlIHVuY2xlYXIKCXRleHQgKGlmIGl0IGV4aXN0cykgd2hpY2gg cmVzdWx0ZWQgaW4gdGhlIGJ1ZyBzaG91bGQgYmUKCWlkZW50aWZpZWQgYW5k IGZpeGVkLgoKCWMpIENsaWVudCAvIFNlcnZlciByZXRyYW5zbWlzc2lvbgoJ PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09CgoJCUJlY2F1c2Ug REhDUCBzZXJ2ZXJzIGFyZSB0aGUgcGFzc2l2ZSBwYXJ0aWNpcGFudHMgYW5k IERIQ1AKCWNsaWVudHMgYXJlIHRoZSBhY3RpdmUgcGFydGljaXBhbnRzLCB0 aGUgREhDUCBwcm90b2NvbCBpcwoJc3VzY2VwdGlibGUgdG8gcG9vcmx5LWJl aGF2ZWQgY2xpZW50cyAocmV0cmFuc21pdCB0b28gZmFzdCkuCglIb3dldmVy LCB0aGVyZSBpcyBubyB0ZXh0IGRlc2NyaWJpbmcgdGhpcyBzdXNjZXB0aWJp bGl0eS4KCUZ1cnRoZXJtb3JlLCB0aGUgdXNlIG9mIHRoZSBwb3dlci1vZi0y IHJldHJhbnNtaXNzaW9uIGFsZ29yaXRobQoJaXMgYSBTSE9VTEQvTUFZLiBJ TUhPLCBJIHRoaW5rIGl0IHNob3VsZCBiZSBhIE1VU1QuIElmIHdlIG5lZWQK CWRpZmZlcmVudCByZXRyYW5zbWlzc2lvbiBhbGdvcml0aG1zIGZvciBkaWZm ZXJlbnQgbWVkaWEsIHRoZW4gd2UKCXNob3VsZCBkZXZlbG9wIC8gZG9jdW1l bnQgdGhlbSBpbiB0YWJsZSBmb3JtLiBUaGUgc3BlYyBhcyBpdAoJc3RhbmRz IGlzIHRvbyBsb29zZSBhbmQgZG9lcyBjYXVzZSBpbnRlci1vcGVyYWJpbGl0 eSBwcm9ibGVtcy4KCgkJUGcgMTcsIHRoaXJkIHBhcmEgb2YgbGlzdCBpdGVt IDUsIFNlYyAzLjEKCgkJUGcgMjQsIGVpZ2h0aCBwYXJhIG9mIFNlYyA0LjEK CgkJUGcgMzYsIGZpcnN0IHBhcmEgb2YgU2VjIDQuNC4xCgoJZCkgVHJhbnNt aXNzaW9uIG9mIERIQ1AgTkFLcwoJPT09PT09PT09PT09PT09PT09PT09PT09 PT09PQoKCQlESENQIG5ha3MgTVVTVCBiZSBicm9hZGNhc3QuIEhvd2V2ZXIs IHRoZSB0ZXh0CglkZXNjcmliaW5nIGEgc2VydmVyJ3MgYmVoYXZpb3Igd2hl biB0aGUgY2xpZW50IGlzIGFjY2Vzc2libGUKCXRocm91Z2ggYSBCT09UUCBy ZWxheSBhZ2VudCBpcyBpbmNvbnNpc3RlbnQuCgoJCVBnIDE5LCBsYXN0IHBh cmEgb2YgbGlzdCBpdGVtIDIsIFNlYyAzLjIKCgkJUGcgMjMsIGZpZnRoIHBh cmEgb2YgU2VjIDQuMQoKCQlwZyAzMiwgTGFzdCBwYXJhIG9mICJESENQUkVR VUVTVCBnZW5lcmF0ZWQgZHVyaW5nCgkJSU5JVC1SRUJPT1Qgc3RhdGU6IiBi dWxsZXQsIFNlYyA0LjMuMi4KCgkJVGhpcyBsYXN0IHJlZmVyZW5jZSBkZXNj cmliZXMgdGhlIGJlaGF2aW9yIHRoYXQncwoJcmVxdWlyZWQgLSBhIHNlcnZl ciBNVVNUIHNldCB0aGUgYnJvYWRjYXN0IGJpdCBpbiBvcmRlciBmb3IgdGhl CglyZWxheSBhZ2VudCB0byBwcm9wZXJseSBicm9hZGNhc3QgdGhlIERIQ1BO QUsuIFdlIGp1c3QgbmVlZCB0bwoJZWl0aGVyIHJlZmVyIHRvIGl0IGluIHRo ZSBmaXJzdCB0d28gcmVmZXJlbmNlcyBvciBkdXBsaWNhdGUgaXQKCXRoZXJl LgoKCWUpIE1pbmltdW0gc2l6ZSBvZiBhIEJPT1RQIC8gREhDUCBmcmFtZQoJ PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09CgoJCVJG QyA5NTEgc3RhdGVzIHRoYXQgYSBCT09UUCBmcmFtZSBpcyAzMDAgYnl0ZXMg aW4KCWxlbmd0aC4gU29tZSBCT09UUCByZWxheSBhZ2VudHMgdGh1cyBkcm9w IGZyYW1lcyBsZXNzIHRoYW4gMzAwCglieXRlcyBpbiBsZW5ndGguIFJGQyA5 NTEgaXMgZXhwbGljaXQgb24gdGhpcyBwb2ludCwgYnV0IFJGQyAyMTMxCglq dXN0IHJlZmVycyB0byBSRkMgOTUxLiBJTUhPLCBJIHN1Z2dlc3Qgd2UgYWRk IGEgbGluZSBzdGF0aW5nCgl0aGF0IHRoZSBtaW5pbXVtIHNpemUgb2YgYSBE SENQIGZyYW1lIGlzIDMwMCBieXRlcyBpbiByZWZlcmVuY2U6CgoJCVBnIDEw LCBmaXJzdCBwYXJhIGFmdGVyIFRhYmxlIDEsIFNlYyAyCgoJCUFmdGVyIGFs bCwgREhDUCBpcyByZWFsbHkgQk9PVFB2MiwgYW5kIGlzIGludGVuZGVkIHRv IGJlCgliYWNrd2FyZCBjb21wYXRpYmxlIHdpdGggQk9PVFAuCgoJZikgVXNl IG9mIGNpYWRkcgoJPT09PT09PT09PT09PT09PQoKCQlSRkMgOTUxIC0gY2xp ZW50cyB1c2UgY2lhZGRyIHdoZW4gdGhleSd2ZSByZWNlaXZlZCBhbiBJUAoJ YWRkcmVzcyBmcm9tIGEgc291cmNlIG91dHNpZGUgb2YgQk9PVFAsIGFuZCB0 aHVzIHNob3VsZCBiZSBhYmxlCgl0byByZXNwb25kIHRvIEFSUHMuCgoJCVRo ZSB0ZXh0IGluIFJGQyAyMTMxIGlzIG1vc3RseSBzdXBwb3J0aXZlIG9mIHRo aXMgcG9pbnQKCXdpdGggdGhlIGZvbGxvd2luZyBleGNlcHRpb246CgoJCVBn IDIxLCBmaXJzdCBzZW50ZW5jZSBvZiBsYXN0IHBhcmEsIFNlYyAzLjQ6ICJU aGUgc2VydmVyCgkJU0hPVUxEIGNoZWNrIHRoZSBuZXR3b3JrIGFkZHJlc3Mg aW4gYSBESENQSU5GT1JNIG1lc3NhZ2UKCQlmb3IgY29uc2lzdGVuY3ksIGJ1 dCBNVVNUIE5PVCBjaGVjayBmb3IgYW4gZXhpc3RpbmcKCQlsZWFzZSIKCgkJ VGhpcyBsaW5lIHNob3VsZCBiZSBzdHJ1Y2sgZnJvbSB0aGUgZG9jdW1lbnQu IFNlcnZlcnMKCXRydXN0IGNpYWRkciwgcGVyaW9kLgoKCQlMaWtld2lzZSwg dGhlIGZvbGxvd2luZyBsaW5lIHNob3VsZCBhbHNvIGJlIHN0cnVjazoKCgkJ UGcgMzIsICJESENQUkVRVUVTVCBnZW5lcmF0ZWQgZHVyaW5nIFJFQklORElO RyBzdGF0ZToiLAoJCVNlYyA0LjMuMjogIlRoZSBESENQIHNlcnZlciBTSE9V TEQgY2hlY2sgJ2NpYWRkcicgZm9yCgkJY29ycmVjdG5lc3MgYmVmb3JlIHJl cGx5aW5nIHRvIHRoZSBESENQUkVRVUVTVCIKCgoJZykgRHVwbGljYXRlIElQ IGFkZHJlc3MgZGV0ZWN0aW9uCgk9PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT0KCgkJVGhlIHNwZWMgc3BlY2lmaWVzIHRoZSByZXF1aXJlbWVu dCB0aGF0IERIQ1AgZ3VhcmFudGVlCgl0aGF0IGFuIElQIGFkZHJlc3MgaXMg bm90IGluIHVzZS4gSG93ZXZlciwgdGhlIHByb3RvY29sIGl0c2VsZgoJZG9l cyBub3QgbWVldCB0aGlzIHJlcXVpcmVtZW50LgoKCQlQZyA3LCBTZWNvbmQg c2V0IG9mIGJ1bGxldCBpdGVtcywgZmlyc3QgYnVsbGV0LCBTZWMgMS42CgkJ c3BlY2lmaWVzIHRoYXQgIkd1YXJhbnRlZSB0aGF0IGFueSBzcGVjaWZpYyBu ZXR3b3JrCgkJYWRkcmVzcyB3aWxsIG5vdCBiZSBpbiB1c2UgYnkgbW9yZSB0 aGFuIG9uZSBESENQIGNsaWVudAoJCWF0IGEgdGltZSIKCgkJSSB0aGluayB3 ZSBtZWFuICJob3N0IiByYXRoZXIgdGhhbiAiREhDUCBjbGllbnQiIGhlcmUu CglUaGUgc3BlYyBkZXNjcmliZXMgdHdvIG1lY2hhbmlzbXMsIGEgSUNNUCBl Y2hvIHJlcXVlc3QgZ2VuZXJhdGVkCglieSB0aGUgREhDUCBzZXJ2ZXIgYW5k IGFuIEFSUCByZXF1ZXN0IGdlbmVyYXRlZCBieSB0aGUgREhDUAoJY2xpZW50 LiBUbyBtZWV0IHRoaXMgcmVxdWlyZW1lbnQsIEkgdGhpbmsgYSBESENQIGNs aWVudCBNVVNUCgl2YWxpZGF0ZSB0aGUgSVAgYWRkcmVzcyBjb250YWluZWQg aW4gYSBESENQQUNLIGJlZm9yZSB1c2luZyBpdCwKCWFuZCB0aGF0IGEgREhD UCBzZXJ2ZXIgTUFZIHZhbGlkYXRlIGFuIElQIGFkZHJlc3MgdXNpbmcgYW4g SUNNUAoJZWNobyByZXF1ZXN0IGJlZm9yZSBPRkZFUmluZyBpdCB0byBhIGNs aWVudC4gUmlnaHQgbm93LCBib3RoCgltZWNoYW5pc21zIGFyZSBTSE9VTEQn cy4gUmVsZXZhbnQgcmVmZXJlbmNlczoKCgkJUGcgMTIsIHNlY29uZCBwYXJh IG9mIFNlYyAyLjIsIGxhc3Qgc2VudGVuY2UKCgkJUGcgMTMsIGxpc3QgaXRl bSAyLCBTZWMgMy4xCgoJCVBnIDM4LCBmaXJzdCBwYXJhIGFmdGVyIFRhYmxl IDUsIFNlYyA0LjQuMQoKCWgpIENsYXJpZnkgdXNlIG9mIGZpbGUgZmllbGQg Zm9yIE9wdGlvbnMgLyBib290ZmlsZQoJPT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09CgoJCVdlIGN1cnJlbnRs eSBoYXZlIGEgV0cgbGlzdCB0aHJlYWQgb24gdGhpcyB0b3BpYy4gV2UKCXNo b3VsZCBjbGFyaWZ5IHRoZSB1c2Ugb2YgdGhlIEZpbGUgZmllbGQgZm9yIERI Q1AgY2xpZW50cy4gVGhpcwoJaXRlbSBpcyByZWxhdGVkIHRvICNpIGJlbG93 LgoKCWkpIENsYXJpZnkgdXNlIG9mIFZlbmRvciBjbGFzcyBpZGVudGlmaWVy IChmb3JtKQoJPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09CgoJCWEpIFdoYXQgY2hhcmFjdGVycyBhcmUgbGVnYWw/ IChzb21lIG5ldyBjbGllbnRzIGhhdmUKCQkgICBzcGFjZXMgaW4gdGhlaXIg aWRlbnRpZmllciwgd2hpY2ggYnJva2Ugc29tZQoJCSAgIGltcGxlbWVudGF0 aW9ucyB3aXRoIGNvbmZpZ3VyYXRpb24gZmlsZSByZWNvcmRzCgkJICAgZGVs aW1pdGVkIGJ5IHdoaXRlLXNwYWNlKS4KCgkJYikgV2hhdCBpcyB0aGUgZm9y bSBvZiB0aGUgbmFtZSBzcGFjZT8gKG9yaWdpbmFsbHkKCQkgICAoMTU0MSB0 aW1lLWZyYW1lKSwgd2UgaGFkIGRpc2N1c3NlZCB1c2luZwoJCSAgICJTdG9j ayBzeW1ib2wvT3JnYW5pemF0aW9uLi4uLiIgZm9ybSB0byBwcmV2ZW50CgkJ ICAgY29sbGlzaW9ucyBiZXR3ZWVuIHZlbmRvcnMuIEUuZy46ICJTVU5XLmZv by5iYXIiIG9yCgkJICAgIkNNVS5mb28uYmFyIi4gVGhpcyB0ZXh0IHNob3Vs ZCBiZSBpbmNsdWRlZCBpbiAyMTMyLgoKCQljKSBUZXh0IGRlc2NyaWJpbmcg ZWFjaCB1bmlxdWUgdmVuZG9yIGNsYXNzIGlkZW50aWZpZXIKCQkgICBjYW4g c3VwcG9ydCBhIDI1MyB1bmlxdWUgZW5jYXBzdWxhdGVkIG9wdGlvbiBuYW1l CgkJICAgc3BhY2UuIFNvbWUgZm9sa3MgdGhpbmsgdGhhdCB0aGVyZSBpcyBv bmx5IG9uZSAyNTMKCQkgICB1bmlxdWUgZW5jYXBzdWxhdGVkIG9wdGlvbiBu YW1lIHNwYWNlLCBhbmQgcmV0dXJuCgkJICAgdGhlIHNhbWUgdmFsdWVzIHRv ICphbnkqIGNsaWVudCByZXR1cm5pbmcgKmFueSoKCQkgICB2ZW5kb3IgY2xh c3MgaWRlbnRpZmllci4gT2J2aW91c2x5LCB3ZSBzaG91bGQgaW5jbHVkZQoJ CSAgIHRleHQgdG8gY2xhcmlmeSB0aGUgcmVsYXRpb25zaGlwIGJldHdlZW4g VmVuZG9yIENsYXNzCgkJICAgaWRlbnRpZmllciBhbmQgdGhlIGVuY2Fwc3Vs YXRlZCBWZW5kb3Igb3B0aW9uLgoKCQlkKSBIb3cgbWFueSBWZW5kb3IgY2xh c3MgaWRlbnRpZmllcnMgY2FuIGEgY2xpZW50IGhhdmU/CgkJICAgT25seSBv bmUsIGFzIHRoZXJlIGlzIG9ubHkgb25lIERIQ1AgY2xpZW50CgkJICAgdmVu ZG9yLiBJdCBpcyBpbXBvc3NpYmxlIHRvIGhhdmUgbW9yZSB0aGFuIG9uZSwg c2luY2UKCQkgICB0aGVyZSB3b3VsZCBiZSBubyB3YXkgdG8ga25vdyB3aGlj aCBlbmNhcHN1bGF0ZWQKCQkgICBvcHRpb24gd2VudCB3aXRoIHdoaWNoIFZl bmRvciBDbGFzcy4KCgkJSGVyZSBpcyBzb21lIG1vcmUgdGV4dCByZWdhcmRp bmcgdmVuZG9yIG9wdGlvbnMgZnJvbQoJYSBwcmV2aW91cyBub3RlIEkgd3Jv dGUgcmVnYXJkaW5nIHRoZSB1c2Ugb2YgVmVuZG9yIGNsYXNzIC8KCWVuY2Fw c3VsYXRlZCBvcHRpb25zOgoKCQlTdWNjZXNzZnVsIFZlbmRvciBjbGFzcyBz dXBwb3J0IHJlcXVpcmVzIHRoZSBhYmlsaXR5IHRvCgljb25maWd1cmUgYSBE SENQIHNlcnZlciB0byBzdXBwb3J0IGEgbmV3IHZlbmRvciBjbGFzcyBieQoJ YXNzb2NpYXRpbmcgdGhhdCB2ZW5kb3IgY2xhc3MgaWRlbnRpZmllciB3aXRo IDI1MyBvcHRpb25zIHdob3NlCgl0eXBlcyBjYW4gdGhlbiBiZSBkZWZpbmVk IGJ5IGZvbGxvd2luZyB0aGUgREhDUCBjbGllbnQncwoJZG9jdW1lbnRhdGlv bi4gRWFjaCBncm91cCBvZiAyNTMgb3B0aW9ucyBoYXMgdGhlICJzY29wZSIg b2YgdGhhdAoJVmVuZG9yLiBGb3IgZXhhbXBsZSwgbGV0J3Mgc2F5IHdlIGhh dmUgdGhlIGZvbGxvd2luZyB0d28gY2xpZW50czoKCglWZW5kb3IgQ2xhc3Mg IlN1bkJlYW0uVG9hc3Rlci4yc2xvdHMiCgoJCU9wdGlvbnMgZm9yIHRoaXMg Y2xhc3M6CgkJQ29kZQlMZW4JRGF0YQoJCTEJMglEYXJrbmVzcyBzZXR0aW5n CgoJCURhcmtuZXNzIHNldHRpbmcgaXMgYSAyIGJ5dGUgaW50ZWdlci4KCglW ZW5kb3IgQ2xhc3MgIkdFLkFuc3dlcmluZy5NYWNoaW5lIgoKCQlPcHRpb25z IGZvciB0aGlzIGNsYXNzOgoJCUNvZGUJTGVuCURhdGEKCQkxCVgJT3V0Z29p bmcgbWVzc2FnZQoKCQlPdXRnb2luZyBtZXNzYWdlIGlzIGFuIEFTQ0lJIHN0 cmluZywgWCBieXRlcyBsb25nLAoJY29uc2lzdGluZyBvZiB0aGUgdGV4dCBv ZiB0aGUgYW5zd2VyIG1lc3NhZ2UuCgoJCUJvdGggY2xpZW50cyBhcmUgb24g dGhlIHNhbWUgbmV0d29yayAiS2l0Y2hlbiIsIGFuZCBhcmUKCWNsaWVudHMg b2YgdGhlIHNhbWUgREhDUCBzZXJ2ZXIuIE5vdGUgdGhhdCBib3RoIHVzZSBF bmNhcHN1bGF0ZWQKCW9wdGlvbiBjb2RlIDEuIExvb2tzIGxpa2UgYSBjb25m bGljdCwgYnV0IGl0IGlzbid0LgoKCQlJbiB0aGUgc3ludGF4IG9mIHRoZSBE SENQIHNlcnZlcidzIGNvbmZpZ3VyYXRpb24gdGFibGUsCglJIGNvbmZpZ3Vy ZSB0d28gbmV3IG9wdGlvbnMsIGVhY2ggd2hpY2ggaGFzIHRoZSAic2NvcGUi IG9mIHRoZQoJdmVuZG9yIGNsYXNzLiBXaGF0IHRoaXMgbWVhbnMgaXMgdGhh dCB3aGVuIHRoZSB0b2FzdGVyIGJvb3RzLAoJdGhlIGRoY3Agc2VydmVyIG9u bHkgcmV0dXJucyB2ZW5kb3IgY2xhc3Mgb3B0aW9ucyBhc3NvY2lhdGVkCgl3 aXRoIHRoZSAiU3VuQmVhbS5Ub2FzdGVyLjJzbG90cyIgY2xhc3MuIFdoZW4g dGhlIGFuc3dlcmluZwoJbWFjaGluZSBib290cywgaXQgb25seSBzZWVucyB2 ZW5kb3IgY2xhc3Mgb3B0aW9ucyBhc3NvY2lhdGVkCgl3aXRoIHRoZSAiR0Uu QW5zd2VyaW5nLk1hY2hpbmUiIGNsYXNzLiBDbGllbnRzIG9mIHZlbmRvciBj bGFzc2VzCglub3QgY3VycmVudGx5IGNvbmZpZ3VyZWQgb24gdGhlIHNlcnZl ciBkb24ndCBzZWUgYW55CgllbmNhcHN1bGF0ZWQgdmVuZG9yIG9wdGlvbnMs IHNpbmNlIHRoZSBzZXJ2ZXIgaGFzbid0IGJlZW4KCWNvbmZpZ3VyZWQgdG8g c3VwcG9ydCB0aGF0IHZlbmRvciBjbGFzcy4gVGhlIGRoY3Agc2VydmVyIGNh bgoJbWFrZSB0aGlzIGRpc3RpbmN0aW9uIGJhc2VkIHVwb246CgoJCWEpIFRo ZSBjbGllbnQgaWRlbnRpZmllcyBpdCdzIHZlbmRvciBjbGFzcy4KCgkJYikg VGhlIHNlcnZlciBjYW4gYmUgKGFuZCBoYXMgYmVlbikgY29uZmlndXJlZCB0 bwoJCSAgIGFzc29jaWF0ZSBlYWNoIGNsaWVudCdzIHZlbmRvciBvcHRpb25z IHdpdGggdGhlCgkJICAgY2xpZW50J3MgY2xhc3MgaWRlbnRpZmllci4KCglq KSBESENQIE1UVSBvcHRpb24KCT09PT09PT09PT09PT09PT09PQoKCQlESENQ IG1lc3NhZ2VzIGNhbid0IGJlIGZyYWdtZW50ZWQsIHNpbmNlIHRoZXJlIGlz IG5vIHdheQoJdG8gZGVsaXZlciB0aGVtIHRvIHJlbW90ZSBuZXR3b3JrcyB2 aWEgYSByZWxheSBhZ2VudCAoZnJhZ21lbnRzCgl3b24ndCBjb250YWluIHRo ZSBCT09UUCBoZWFkZXIgd2hpY2ggdGhlIHJlbGF5IGFnZW50IG5lZWRzIHRv CglkZWxpdmVyIHRoZSBESENQIHJlc3BvbnNlKS4gQXMgc3VjaCwgQ2xpZW50 cyByZWFsbHkgU0hPVUxECgljb21tdW5pY2F0ZSB0aGVpciBsaW5rLWxheWVy IGZyYW1lIHNpemUgdG8gdGhlIERIQ1Agc2VydmVyIHZpYQoJdGhlIERIQ1Ag TVRVIG9wdGlvbi4gV2Ugc2hvdWxkIGNsYXJpZnkgdGhpcyBwb2ludCBib3Ro IGluIHRoZQoJREhDUCBhbmQgQk9PVFAgc3BlY2lmaWNhdGlvbnMuIEkgdGhp bmsgd2Ugc2hvdWxkIGNvbnNpZGVyCgljaGFuZ2luZyBTSE9VTEQgdG8gTVVT VCBpbiB0aGlzIGNhc2UuCgoJCVBnIDIxLCBzZWNvbmQgcGFyYSwgU2VjIDMu NQoKCWspIFNIT1VMRHMgdGhhdCBzaG91bGQgYmUgTVVTVHMsIGV0YwoJPT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09CgoJCVRoZXJlIGFy ZSBtYW55IFNIT1VMRHMgYW5kIFNIT1VMRCBOT1RzIHRoYXQgc2hvdWxkIGJl Cgljb252ZXJ0ZWQgaW50byBNVVNUcyBvciBNVVNUIE5PVHMuIFRvbyBtYW55 IHRvIGxpc3QsIGJ1dCBoZXJlJ3MKCWEgZmV3OgoKCQlQZyAxMiwgc2Vjb25k IHBhcmEgb2YgU2VjIDIuMjogIi4uLiBhbmQgdGhlIGNsaWVudAoJCVNIT1VM RCBwcm9iZSB0aGUgbmV3bHkgcmVjZWl2ZWQgYWRkcmVzcywgZS5nLiB3aXRo IEFSUCIKCQkoTVVTVCkKCgkJUGcgMTYsIGl0ZW0gNCwgU2VjIDMuMSAiVGhl IHNlcnZlciBTSE9VTEQgTk9UIGNoZWNrIHRoZQoJCW9mZmVyZWQgbmV0d29y ayBhZGRyZXNzIGF0IHRoaXMgcG9pbnQuIiAoTVVTVCBOT1QpCgoJCVBnIDE2 LCBpdGVtIDUsIFNlYyAzLjEgIlRoZSBjbGllbnQgU0hPVUxEIHBlcmZvcm0g YQoJCWZpbmFsIGNoZWNrIG9uIHRoZSBwYXJhbWV0ZXJzLi4uIiAoTVVTVCkK CgkJUGcgMTcsIGl0ZW0gNSwgU2VjIDMuMSAiVGhlIGNsaWVudCBTSE9VTEQg d2FpdCBhIG1pbmltdW0KCQlvZiB0ZW4gc2Vjb25kcy4uLiIgKE1VU1QpCgoJ CVBnIDE4LCBpdGVtIDIsIFNlYyAzLjIgIlNlcnZlcnMgU0hPVUxEIE5PVCBj aGVjayB0aGF0CgkJdGhlIGNsaWVudCdzIG5ldHdvcmsgYWRkcmVzcyBpcyBh bHJlYWR5IGluIHVzZTsuLi4iCgkJKE1VU1QgTk9UKQoKCQlQZyAxOSwgaXRl bSAyLCBzZWNvbmQgcGFyYSwgU2VjIDMuMiAiLi4uc2VydmVycyBTSE9VTEQK CQlyZXNwb25kIHdpdGggYSBESENQTkFLIG1lc3NhZ2UgdG8gdGhlIGNsaWVu dCIgKE1VU1QpIFRoZQoJCWZvbGxvd2luZyBzZW50ZW5jZXMgYXJlIHJhdGhl ciBkdWJpb3VzIGluIHRoaXMgcGFyYWdyYXBoCgkJYXMgd2VsbC4KCgkJUGcg MjEsIGZpcnN0IHBhcmEsIFNlYyAzLjQgIlRoZSBzZXJ2ZXJzIFNIT1VMRCB1 bmljYXN0CgkJdGhlIERIQ1BBQ0sgcmVwbGF5IHRvIHRoZSBhZGRyZXNzIGdp dmVuIGludCBoZSAnY2lhZGRyJwoJCWZpZWxkIG9mIHRoZSBESENQSU5GT1JN IG1lc3NhZ2UiIChNVVNUKQoKCQlQZyAyMiwgbGFzdCBwYXJhLCBTZWMgMy41 ICJJZiBhIHNlcnZlciByZWNlaXZlcyBhIERIQ1AKCQlyZXF1ZXN0IG1lc3Nh Z2Ugd2l0aCBhbiBpbnZhbGlkICdyZXF1ZXN0ZWQgSVAgYWRkcmVzcycsCgkJ dGhlIHNlcnZlciBTSE9VTEQgcmVzcG9uZCB0byB0aGUgY2xpZW50IHdpdGgg YSBESENQTkFLCgkJbWVzc2FnZS4uLiIgKE1VU1QpCgoJCWFuZCBzbyBvbi4g V2Ugc2hvdWxkIHJldmlldyB0aGUgTUFZL1NIT1VMRC9NVVNUIChOT1QpcwoJ aW4gdGhlIHNwZWMsIGFuZCB0aWdodGVuIHVwIHRob3NlIHdlIGNhbi4gU0hP VUxEcyBzaG91bGQgbGlzdAoJdGhlIHZhbGlkIGV4Y2VwdGlvbnMgKHNvbWUg ZG87IG1vc3QgZG9uJ3QpLgoKCWwpIEp1c3Qgd3JvbmcKCT09PT09PT09PT09 PT0KCgkJUGcgMjMsIGZpZnRoIHBhcmEsIFNlYyA0LjE6ICJJZiB0aGUgJ2dp YWRkciBmaWVsZCBpcwoJCXplcm8gYW5kIHRoZSAnY2lhZGRyJyBmaWVsZCBp cyBub256ZXJvLCB0aGVuIHRoZSBzZXJ2ZXIKCQl1bmljYXN0cyBESENQT0ZG RVIgYW5kIERIQ1BBQ0sgbWVzc2FnZXMgdG8gdGhlIGFkZHJlc3MgaW4KCQkn Y2lhZGRyJyIuIFRydWUgZm9yIERIQ1BBQ0ssIGZhbHNlIGZvciBESENQT0ZG RVIgKGEKCQlESENQRElTQ09WRVIgd2lsbCBuZXZlciBoYXZlIGFueXRoaW5n IGJ1dCAwIGFzIGNpYWRkcikKCgkJUGcgMjQsIHNldmVudGggcGFyYSwgU2Vj IDQuMTogIk9wdGlvbnMgbWF5IGFwcGVhciBvbmx5CgkJb25jZSwgdW5sZXNz IG90aGVyd2lzZSBzcGVjaWZpZWQgaW4gdGhlIG9wdGlvbnMKCQlkb2N1bWVu dC4gVGhlIGNsaWVudCBjb25jYXRlbmF0ZXMgdGhlIHZhbHVlcyBvZiBtdWx0 aXBsZQoJCWluc3RhbmNlcyBvZiB0aGUgc2FtZSBvcHRpb24gaW50byBhIHNp bmdsZSBwYXJhbWV0ZXIKCQlsaXN0IGZvciBjb25maWd1cmF0aW9uIiBUaGUg Zmlyc3Qgc2VudGVuY2Ugc2hvdWxkIHN0YXJ0CgkJb3V0ICJPcHRpb25zIE1V U1QgYXBwZWFyIG9ubHkgb25jZSwgdW5sZXNzLi4uIi4gVGhlCgkJc2Vjb25k IHNlbnRlbmNlIGJlbG9uZ3MgaW4gdGhlIG9wdGlvbnMgZHJhZnQgZm9yIG9w dGlvbnMKCQl3aGVyZSB0aGVyZSBjYW4gYmUgbXVsdGlwbGUgaW5zdGFuY2Vz LiBUb2dldGhlciwgdGhlc2UgdHdvCgkJc2VudGVuY2VzIGFyZSBjb25mdXNp bmcuCgoJbSkgSnVzdCB1bmNsZWFyCgk9PT09PT09PT09PT09PT0KCQlQZyAz MCwgc2Vjb25kIGZyb20gbGFzdCBidWxsZXQsIFNlYyA0LjMuMS4gVGhpcyBp dGVtCgkJbWFrZXMgbm8gc2Vuc2U6ICJjbGllbnQncyB2ZW5kb3IgY2xhc3MK CQlpZGVudGlmaWVycyBhbmQgY2xpZW50J3MgY2xhc3NlcyBpZGVudGlmaWVk IGluIHRoZQoJCXNlcnZlci4uIj8KCgkJUGcgMTYsIGxhc3Qgc2VudGVuY2Ug b2YgbGlzdCBpdGVtIDMsIFNlYyAzLjEgIlRoZSBjbGllbnQKCQl0aW1lcyBv dXQgYW5kIHJldHJhbnNtaXRzIHRoZSBESENQRElTQ09WRVIgbWVzc2FnZSBp ZgoJCXRoZSBjbGllbnQgcmVjZWl2ZXMgbm8gREhDUE9GRkVSIG1lc3NhZ2Vz LiIgSG93IGxvbmcKCQlzaG91bGQgdGhlIGNsaWVudCB3YWl0PwoKCjQpIEVz Y2FwZSBoYXRjaGVzIC8gVHJhcCBkb29ycyBpbiBwcm90b2NvbAoKCVRoaXMg c2VjdGlvbiBkZXNjcmliZXMgaW5jb21wbGV0ZSBjaGFuZ2VzIHdoaWNoIHJl c3VsdCBpbgppbnRlci1vcGVyYWJpbGl0eSBwcm9ibGVtcy4KCgkJYSkgUGcg MjcsIHRoaXJkIHBhcmEsIFNlYyA0LjMuMTogIk5vdGUgdGhhdCwgaW4gc29t ZQoJCW5ldHdvcmsgYXJjaGl0ZWN0dXJlcyAoZS5nLiwgaW50ZXJuZXRzIHdp dGggbW9yZSB0aGFuIG9uCgkJSVAgc3VibmV0IGFzc2lnbmVkIHRvIGEgcGh5 c2ljYWwgbmV0d29yayBzZWdtZW50KSwgaXQKCQltYXkgYmUgdGhlIGNhc2Ug dGhhdCB0aGUgREhDUCBjbGllbnQgc2hvdWxkIGJlIGFzc2lnbmVkCgkJYW4g YWRkcmVzcyBmcm9tIGEgZGlmZmVyZW50IHN1Ym5ldCB0aGFuIHRoZSBhZGRy ZXNzCgkJcmVjb3JkaW5nIGluICdnaWFkZHInLi4uLiIgV2UgZ28gdGhyb3Vn aCBncmVhdCBkZXRhaWwKCQlpbiB0aGUgcmVzdCBvZiB0aGUgZHJhZnQgdHJ5 aW5nIHRvIGdldCB0aGUgdXNlIG9mCgkJZ2lhZGRyIGNsZWFyIGFzIGl0IHJl bGF0ZXMgdG8gQk9PVFAgcmVsYXkgYWdlbnRzIChSRkMKCQk5NTEgYW5kIFJG QyAxNTQyKSwgdGhlbiB0aGlzIHNlbnRlbmNlIGJhc2ljYWxseSAidW5kb2Vz IgoJCXRoaXMgd29yay4gSU1ITywgc2VydmluZyBtdWx0aXBsZSBJUCBuZXR3 b3JrcyBvbiB0aGUKCQlzYW1lIHdpcmUgc2hvdWxkIGJlIGVpdGhlciBkZXNj cmliZWQgaW4gZGV0YWlsIGluIGl0cwoJCW93biBzZWN0aW9uICh3aXRoIGNh dmVhdHMpIG9yIGFzIGEgc2VwYXJhdGUKCQlpbmZvcm1hdGlvbmFsIFJGQy4g T3RoZXJ3aXNlLCB0aGUgdXNlIG9mIGdpYWRkciBpcwoJCXVuY2xlYXIuCgoK CgpNaWtlIENhcm5leQpTTlQgSW50ZXJuZXQgRW5naW5lZXJpbmcKU3VuIE1p Y3Jvc3lzdGVtcywgSW5jLgo= ---LA_F2157770563R-1106117653A-917488929=:454NCE.Roam-- From dhcp-v4@bucknell.edu Wed Jan 27 23:14:20 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.7.249]) by ietf.org (8.8.5/8.8.7a) with ESMTP id XAA13160 for ; Wed, 27 Jan 1999 23:14:19 -0500 (EST) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.8.8/8.8.8) with SMTP id XAA18467; Wed, 27 Jan 1999 23:10:49 -0500 (EST) Date: Wed, 27 Jan 1999 23:10:49 -0500 (EST) Message-Id: Errors-To: droms@bucknell.edu Reply-To: dhcp-v4@bucknell.edu Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: dhcp-v4@bucknell.edu (by way of Ralph Droms) To: Multiple recipients of list Subject: I-D ACTION:draft-ietf-dhc-autoconfig-03.txt X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Type: text/plain; charset="us-ascii" Mime-Version: 1.0 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. Note: This revision reflects comments received during the last call period. Title : DHCP Option to Disable Stateless Auto-Configuration in IPv4 Clients Author(s) : R. Troll Filename : draft-ietf-dhc-autoconfig-03.txt Pages : 9 Date : 26-Jan-99 Operating Systems are now attempting to support ad-hoc networks of two or more systems, while keeping user configuration at a minimum. To accommodate this, in the absence of a central configuration mechanism (DHCP), some OS's are automatically choosing a link-local IP address which will allow them to communicate only with other hosts on the same link. This address will not allow the OS to communicate with anything beyond a router. However, some sites depend on the fact that a host with no DHCP response will have no IP address. This document describes a mechanism by which DHCP servers are able to tell clients that they do not have an IP address to offer, and that the client should not generate an IP address it's own. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-autoconfig-03.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-autoconfig-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html 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-autoconfig-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. [The following attachment must be fetched by mail. Command-click the URL below and send the resulting message to get the attachment.] [The following attachment must be fetched by ftp. Command-click the URL below to ask your ftp client to fetch it.] From dhcp-v4@bucknell.edu Wed Jan 27 23:15:46 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.7.249]) by ietf.org (8.8.5/8.8.7a) with ESMTP id XAA13182 for ; Wed, 27 Jan 1999 23:15:45 -0500 (EST) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.8.8/8.8.8) with SMTP id XAA29434; Wed, 27 Jan 1999 23:12:43 -0500 (EST) Date: Wed, 27 Jan 1999 23:12:43 -0500 (EST) Message-Id: Errors-To: droms@bucknell.edu Reply-To: dhcp-v4@bucknell.edu Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: dhcp-v4@bucknell.edu (by way of Ralph Droms) To: Multiple recipients of list Subject: Re: Last call:DHCP Options for Service Location Protocol X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Type: text/plain; charset="us-ascii" Mime-Version: 1.0 message sent to dhcp-v4@bucknell.edu by TRUPPER@NOVELL.COM follows. ------------------------------------------------------------------- Ralph, I have concerns about the latest proposal for DHCP options for SLP. It appears that support for RFC 2165 has been removed or significantly changed. The introduction states that these options are used to configure agents using SLP Version 2 [3]. There is nothing describing Version 1. In order to change at this point in time, I propose selecting different option numbers for Version 2. Todd. From dhcp-v4@bucknell.edu Wed Jan 27 23:16:44 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.7.249]) by ietf.org (8.8.5/8.8.7a) with ESMTP id XAA13193 for ; Wed, 27 Jan 1999 23:16:44 -0500 (EST) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.8.8/8.8.8) with SMTP id XAA15186; Wed, 27 Jan 1999 23:13:19 -0500 (EST) Date: Wed, 27 Jan 1999 23:13:19 -0500 (EST) Message-Id: Errors-To: droms@bucknell.edu Reply-To: Michael.Carney@East.Sun.COM Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Mike Carney - SNT Internet Engineering To: Multiple recipients of list Subject: Re: Colliding on Vendor Class Identification? - Not an attachment (Fwd) X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Mime-Version: 1.0 Here it is again, this time not an attachment. (sorry for the duplication) >----------------Begin Forwarded Message----------------< i) Clarify use of Vendor class identifier (form) ================================================ a) What characters are legal? (some new clients have spaces in their identifier, which broke some implementations with configuration file records delimited by white-space). b) What is the form of the name space? (originally (1541 time-frame), we had discussed using "Stock symbol/Organization...." form to prevent collisions between vendors. E.g.: "SUNW.foo.bar" or "CMU.foo.bar". This text should be included in 2132. c) Text describing each unique vendor class identifier can support a 253 unique encapsulated option name space. Some folks think that there is only one 253 unique encapsulated option name space, and return the same values to *any* client returning *any* vendor class identifier. Obviously, we should include text to clarify the relationship between Vendor Class identifier and the encapsulated Vendor option. d) How many Vendor class identifiers can a client have? Only one, as there is only one DHCP client vendor. It is impossible to have more than one, since there would be no way to know which encapsulated option went with which Vendor Class. Here is some more text regarding vendor options from a previous note I wrote regarding the use of Vendor class / encapsulated options: Successful Vendor class support requires the ability to configure a DHCP server to support a new vendor class by associating that vendor class identifier with 253 options whose types can then be defined by following the DHCP client's documentation. Each group of 253 options has the "scope" of that Vendor. For example, let's say we have the following two clients: Vendor Class "SunBeam.Toaster.2slots" Options for this class: Code Len Data 1 2 Darkness setting Darkness setting is a 2 byte integer. Vendor Class "GE.Answering.Machine" Options for this class: Code Len Data 1 X Outgoing message Outgoing message is an ASCII string, X bytes long, consisting of the text of the answer message. Both clients are on the same network "Kitchen", and are clients of the same DHCP server. Note that both use Encapsulated option code 1. Looks like a conflict, but it isn't. In the syntax of the DHCP server's configuration table, I configure two new options, each which has the "scope" of the vendor class. What this means is that when the toaster boots, the dhcp server only returns vendor class options associated with the "SunBeam.Toaster.2slots" class. When the answering machine boots, it only seens vendor class options associated with the "GE.Answering.Machine" class. Clients of vendor classes not currently configured on the server don't see any encapsulated vendor options, since the server hasn't been configured to support that vendor class. The dhcp server can make this distinction based upon: a) The client identifies it's vendor class. b) The server can be (and has been) configured to associate each client's vendor options with the client's class identifier. From dhcp-v4@bucknell.edu Thu Jan 28 06:53:47 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.7.249]) by ietf.org (8.8.5/8.8.7a) with ESMTP id GAA23985 for ; Thu, 28 Jan 1999 06:53:47 -0500 (EST) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.8.8/8.8.8) with SMTP id GAA06002; Thu, 28 Jan 1999 06:40:56 -0500 (EST) Date: Thu, 28 Jan 1999 06:40:56 -0500 (EST) Message-Id: <36B049D5.A6B3AD47@germany.sun.com> Errors-To: droms@bucknell.edu Reply-To: Erik.Guttman@Germany.Sun.COM Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Erik Guttman To: Multiple recipients of list Subject: Re: Last call:DHCP Options for Service Location Protocol X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 X-Mailer: Mozilla 4.5 [en] (X11; U; SunOS 5.5.1 sun4m) by way of Ralph Droms wrote: > > message sent to dhcp-v4@bucknell.edu by TRUPPER@NOVELL.COM follows. > ------------------------------------------------------------------- > Ralph, > > I have concerns about the latest proposal for DHCP options for SLP. It > appears that support for RFC 2165 has been removed or significantly changed. > > The introduction states that these options are used to configure agents > using SLP Version 2 [3]. There is nothing describing Version 1. > > In order to change at this point in time, I propose selecting different > option numbers for Version 2. > > Todd. The options have been rewritten to support SLPv2 agents. As the options were never finalized for SLPv1 we believed that we could issue them for SLPv2 without worrying about backward compatibility. If Novell has released software which implements an old version of the DHCP options draft we have to regroup and figure out what to do. We thought it would be preferable to simply support SLPv2 with these DHCP options as this would make the options simpler and further, provide incentive to move to SLPv2. We did not realize there was legacy code as we had not yet release an RFC. Erik From dhcp-v4@bucknell.edu Thu Jan 28 08:39:47 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.7.249]) by ietf.org (8.8.5/8.8.7a) with ESMTP id IAA25091 for ; Thu, 28 Jan 1999 08:39:46 -0500 (EST) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.8.8/8.8.8) with SMTP id IAA16197; Thu, 28 Jan 1999 08:33:42 -0500 (EST) Date: Thu, 28 Jan 1999 08:33:42 -0500 (EST) Message-Id: <36B05B72.1B019AB4@germany.sun.com> Errors-To: droms@bucknell.edu Reply-To: Erik.Guttman@Germany.Sun.COM Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Erik Guttman To: Multiple recipients of list Subject: Re: Last Call on DHCP Options for SLP X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 X-Mailer: Mozilla 4.5 [en] (X11; U; SunOS 5.5.1 sun4m) GLENN_WATERS@CORPEAST.BAYNETWORKS.COM wrote: > ------------------------------------------------------------------------------- > the SLP Service Scope Option still requires a one byte "mandatory" field > within the option. at the last ietf i thought we concocted a scheme where > the mandatory field was not required. > At the DHC meeting where SLP was discussed I believe we reached two conclusions: 1. A Byte field is acceptable: It would not be hard to implement. 2. Stating that the DHCP configured value MUST override static configuration for the value of scope is a bad idea. But saying that static config overrides the DHCP option supplied value makes the option too weak for administrative control over SLP agent behavior. Adding this control byte provides for either case at the discretion of the administrator. The direction I came away with from the DHC meeting was that I should remove the flag fields and instead include a byte field, and then to reissue the internet draft. > my preference is that we define options using only the well defined set of > types that have previously been used in option definition and not introduce > a new encoding within an option. this option introduces a "structure" > encoding within the option. Another way to issue this draft would be to make it stronger and say that the DHC SLP Scope option, if present, always overrides the user's static configuration. > if there is a strong requirement for this type of feature going forward, > then i would like to see the dhcp advisory panel address this in a standard. > by doing so, dhcp configuration systems can be built to allow for data > driven configuration of new options. the SLP Service Scope option requires > that new option 79 specific code be added to our product (and likely a > number of other vendors products). If this is true, then we should probably go with the stricter interpretation of the option: that it overrides static configuration. In that case, the "MANDATORY" byte is not required. > in summary, generic new code is good. specific to an option new code is > bad. option 79 requires the latter. thus i am not in favour of this draft > going forward in its current form. > > /gww > > > -----Original Message----- > > From: dhcp-v4@bucknell.edu [mailto:dhcp-v4@bucknell.edu]On Behalf Of > > Ralph Droms > > Sent: Tuesday, January 26, 1999 16:06 > > To: Multiple recipients of list > > Subject: Last Call on DHCP Options for SLP > > > > > > This is a WG last call for comments on DHCP Options for SLP > > . Please respond to the dhcp-v4@bucknell.edu > > mailing list with comments by 3/5/99. If there are no comments, the draft > > will be submitted for acceptance as a Proposed Standard. > > > > - Ralph Droms > > Erik Guttman Sun Labs From dhcp-v4@bucknell.edu Thu Jan 28 14:44:41 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.7.249]) by ietf.org (8.8.5/8.8.7a) with ESMTP id OAA07497 for ; Thu, 28 Jan 1999 14:44:26 -0500 (EST) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.8.8/8.8.8) with SMTP id OAA06123; Thu, 28 Jan 1999 14:37:49 -0500 (EST) Date: Thu, 28 Jan 1999 14:37:49 -0500 (EST) Message-Id: Errors-To: droms@bucknell.edu Reply-To: rweather@nc.com Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Rhys Weatherley To: Multiple recipients of list Subject: Re: Colliding on Vendor Class Identification? - Not an attachment (Fwd) X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 X-Mailer: NC 2.2 Mail Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Mike Carney - SNT Internet Engineering wrote on Wed, 27 Jan 1999 21:13:24 GMT: > Successful Vendor class support requires the ability to > configure a DHCP server to support a new vendor class by > associating that vendor class identifier with 253 options whose > types can then be defined by following the DHCP client's > documentation. Each group of 253 options has the "scope" of that > Vendor. For example, let's say we have the following two clients: If I'm reading this correctly, it appears that the only options that can be varied by the server on a vendor class basis are the encapsulated vendor-specific options. It doesn't appear to allow regular DHCP options to be varied based on the vendor class. However, varying the regular DHCP options is the most common use for the vendor class in the network computing space. As an example, x86-based NC's from NCI, and the JavaStation from Sun, both use the root path option (17) to specify the location of a root filesystem to obtain program binaries and related files from. The root filesystems for these two client types are completely different. It isn't possible to use the root filesystem for one client type on another. But option 17 is a regular DHCP option, not an encapsulated option. Without using the vendor class to distinguish the two client types in the server, it is necessary to manually configure MAC addresses for every single client. A daunting task for 1000's of clients. Now, I realize that the vendor class was only supposed to pertain to the encapsulated options in the original formulation of the standard. But common practice seems to have moved away from that, since most clients only need standard options, but still need to be recognized as different by the server. Is it necessary to get the standard's wording altered to reflect common practice, or should we instead come up with another mechanism for determing the differences in the regular options that are returned? Another option, "user class", does exist and could be used to distinguish client types. However, I have yet to come across any clients that support it. It also doesn't have the same meaning in my mind. I see user class as being useful to distinguish two or more groups of users that are using the same vendor's clients, but need to use slightly different software. The vendor class would be the primary identifier, and the user class the secondary identifier, when trying to locate boot information for a network computing client. To the original question: using the vendor's company name or the name of some common standard that the client adheres to (e.g. "PXEClient"), should be sufficient to prevent collisions. The advantage of the string ID model used in Internet standards over the number-based model used in OSI standards has always been that any ordinary human can usually devise a unique string, without having to consult a central repository of knowledge, as long as the human follows a few very obvious naming rules. Cheers, Rhys. From dhcp-v4@bucknell.edu Thu Jan 28 16:45:58 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.7.249]) by ietf.org (8.8.5/8.8.7a) with ESMTP id QAA09537 for ; Thu, 28 Jan 1999 16:45:57 -0500 (EST) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.8.8/8.8.8) with SMTP id QAA28168; Thu, 28 Jan 1999 16:42:13 -0500 (EST) Date: Thu, 28 Jan 1999 16:42:13 -0500 (EST) Message-Id: <4.1.19990128123949.00a07420@mail.join.com> Errors-To: droms@bucknell.edu Reply-To: robs@join.com Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Rob Stevens To: Multiple recipients of list Subject: Re: Colliding on Vendor Class Identification? - Not an X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Type: text/plain; charset="us-ascii" Mime-Version: 1.0 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 At 02:41 PM 1/28/99 -0500, Rhys Weatherley wrote: > > > > >Mike Carney - SNT Internet Engineering wrote on Wed, 27 Jan 1999 21:13:24 GMT: > > > > Successful Vendor class support requires the ability to > > configure a DHCP server to support a new vendor class by > > associating that vendor class identifier with 253 options whose > > types can then be defined by following the DHCP client's > > documentation. Each group of 253 options has the "scope" of that > > Vendor. For example, let's say we have the following two clients: > >If I'm reading this correctly, it appears that the only options that >can be varied by the server on a vendor class basis are the encapsulated >vendor-specific options. It doesn't appear to allow regular DHCP >options to be varied based on the vendor class. However, varying the >regular DHCP options is the most common use for the vendor class in >the network computing space. > >As an example, x86-based NC's from NCI, and the JavaStation from Sun, >both use the root path option (17) to specify the location of a root >filesystem to obtain program binaries and related files from. The >root filesystems for these two client types are completely different. >It isn't possible to use the root filesystem for one client type on >another....... > > Rhys I don't read it that way and I'm sure that Mike doesn't intend it that way. Servers can use the vendor class to determine the the appropriate value for any of the "normal" or what one might call "class less" DHCP options. As you observe, using the vendor class is essential, more and more, for selecting the proper values. What Mike is saying that each non-null value for the vendor class implies 253 other options which differ in type and semantics from each other (although there may be "accidental" coincidences e.g. one vendor may define several vendor tags, but many of the options defined under each tag are likely to be identical in type and semantics (though quite possibly not in value). Nonetheless one cannot assume this) I think it is worth pointing out that although a vendor option may be unique in terms of (type,semantics), its semantics may dictate that its value nonetheless depend on other factors (such as what network the client is attached to, or even the specific client identifier). Rob Stevens From dhcp-v4@bucknell.edu Thu Jan 28 16:46:19 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.7.249]) by ietf.org (8.8.5/8.8.7a) with ESMTP id QAA09550 for ; Thu, 28 Jan 1999 16:46:18 -0500 (EST) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.8.8/8.8.8) with SMTP id QAA02406; Thu, 28 Jan 1999 16:39:01 -0500 (EST) Date: Thu, 28 Jan 1999 16:39:01 -0500 (EST) Message-Id: <199901282015.MAA00780@mpk07.eng.sun.com> Errors-To: droms@bucknell.edu Reply-To: Warren.Belfer@Eng.Sun.COM Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Warren Belfer To: Multiple recipients of list Subject: Re: Colliding on Vendor Class Identification? - Not an attachment (Fwd) X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 X-Mailer: dtmail 1.2.0 CDE Version 1.2 SunOS 5.6 sun4u sparc Content-Type: TEXT/plain; charset=us-ascii Mime-Version: 1.0 > Date: Thu, 28 Jan 1999 14:41:11 -0500 (EST) > Originator: dhcp-v4@bucknell.edu > From: Rhys Weatherley > To: Multiple recipients of list > Subject: Re: Colliding on Vendor Class Identification? - Not an attachment (Fwd) > X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas > X-Comment: Discussion of DHCP for IPv4 > Mime-Version: 1.0 > Content-Transfer-Encoding: 7bit > > > > > > Mike Carney - SNT Internet Engineering wrote on Wed, 27 Jan 1999 21:13:24 GMT: > > > > Successful Vendor class support requires the ability to > > configure a DHCP server to support a new vendor class by > > associating that vendor class identifier with 253 options whose > > types can then be defined by following the DHCP client's > > documentation. Each group of 253 options has the "scope" of that > > Vendor. For example, let's say we have the following two clients: > > If I'm reading this correctly, it appears that the only options that > can be varied by the server on a vendor class basis are the encapsulated > vendor-specific options. It doesn't appear to allow regular DHCP > options to be varied based on the vendor class. However, varying the > regular DHCP options is the most common use for the vendor class in > the network computing space. Although Mike's example deals with the vendor encapsualted options, the server can be configured to send any of the DHCP options to clients that identify themselves with a given vendor class identifier. The ability to do that might be server specific, but for example, the Sun dhcp server can be easily configured to send a different root path option depending on the vendor class identifier. In fact, that's exactly the way we do that with our various NC models. Warren Belfer Sun Microsystems From dhcp-v4@bucknell.edu Thu Jan 28 16:47:11 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.7.249]) by ietf.org (8.8.5/8.8.7a) with ESMTP id QAA09575 for ; Thu, 28 Jan 1999 16:47:07 -0500 (EST) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.8.8/8.8.8) with SMTP id QAA09265; Thu, 28 Jan 1999 16:42:59 -0500 (EST) Date: Thu, 28 Jan 1999 16:42:59 -0500 (EST) Message-Id: <204324BF087AD211A43A00805F65C13305AD1B@tibet.coppermountain.com> Errors-To: droms@bucknell.edu Reply-To: emichelsen@coppermountain.com Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Eric Michelsen To: Multiple recipients of list Subject: RE: Colliding on Vendor Class Identification? - Not an attachment X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Type: text/plain; X-Mailer: Internet Mail Service (5.5.2232.9) Mime-Version: 1.0 > d) How many Vendor class identifiers can a client have? > Only one, as there is only one DHCP client > vendor. It is impossible to have more than one, since > there would be no way to know which encapsulated > option went with which Vendor Class. This limitation inhibits "plug-and-play" in some devices. For example, in the datacomm business, there are many CPE vendors whose device interoperate with many CO equipment vendors. Each CO vendor has some vendor-specific capabilities, which the CPE would like to take advantage of. But the CPE never knows ahead of time what vendor's CO equipment it will connect to. Therefore, it can't ask for that CO vendor's specific options. A similar problem exists in the CO to CPE direction: even given a CPE's vendor class identifier, the CO equipment can't keep up with all the new CPEs hitting the field, and can't know if some new CPE's vendor-class-identifier indicates a superset of the CO equipment's capabilities. It seems that there is a simple option that we could add to DHCP that greatly simplifies vendor-specific extensions. Define a "vendor-extension" option of minimum length 3, whose first 3 octets are the vendor's Organizationally Unique Identifier (OIU), and whose remaining octets (if any) are defined by the OUI's organization. (Smart organizations will pattern their options after the existing "encapsulated options" of the vendor-specific-information option.) Clients and servers may include any number of these vendor-extension options. Unrecognized options are, of course, ignored. With this option, both clients and servers can include extensions for multiple vendors, without knowing ahead of time to whom they are making the request. Does this seem feasible? How can I move this forward? From dhcp-v4@bucknell.edu Thu Jan 28 18:29:47 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.7.249]) by ietf.org (8.8.5/8.8.7a) with ESMTP id SAA10899 for ; Thu, 28 Jan 1999 18:29:47 -0500 (EST) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.8.8/8.8.8) with SMTP id SAA25326; Thu, 28 Jan 1999 18:25:54 -0500 (EST) Date: Thu, 28 Jan 1999 18:25:54 -0500 (EST) Message-Id: <63D30D6E10CFD11190A90000F805FE86B04205@lespaul.process.com> Errors-To: droms@bucknell.edu Reply-To: Gonczi@process.com Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Steve Gonczi To: Multiple recipients of list Subject: Updated DHCP schema meeting info X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Type: text/plain; X-Mailer: Internet Mail Service (5.0.1460.8) Mime-Version: 1.0 Folks: Here's the Proposed (updated) Agenda for the 2nd DHCP Schema Meeting and some additional information. Proposed Agenda for the 2nd DHCP Schema Meeting Monday, February 8, 1999, 10AM - 5:30PM Meeting logistics Agenda bashing Review of 1st DHCP schema meeting See materials available at http://www.process.com/schema.htm. DMTF Networks Working Group's DHCP goals and status (Andrea Westerinen of Microsoft) Existing DHCP schema presentations (see note) Repeat presentations from 1st meeting with updates New participants might want to present their schema or needs for a schema Further refine object model from 1st DHCP schema meeting Object relationships Tuesday, February 9, 1999, 9AM - noon (or whenever people want to stop) Develop list of attributes, focusing on Attribute description and meaning, not names Possible attribute values or encoding Objects that will have each attribute Relationships between objects and attributes What next? Develop Internet-Draft? Provide input to or review of DMTF work? Other options? Next meeting? Adjourn Note: Anyone that would like to present, please notify Linda Scobo as soon as possible. These should be relatively short, providing a quick overview of how the schema is laid out, unique or interesting features, and any significant differences from other schema. Meeting Logistics: Meeting will be held at the Process Software offices in Framingham, Massachusetts. Directions are available at http://www.process.com/corporate/direct.htp. The offices are about 25 miles west of downtown Boston and Logan International Airport. Process Software will provide lunch and refreshments during both days of the meeting. While the meeting is currently scheduled to end mid-day on the 9th, if sufficient interest exists we can extend until the end of the day. We are working out arrangements to allow folks to conference call in. However, you'll likely miss a lot since you won't see what's being drawn on whiteboards. Information on conferencing in will be provided a few days prior to the meeting to those that requested it. Please let us know ASAP. If you have any questions or suggestions on the meeting, please contact Linda Scobo at 508-879-6994 x 345 or scobo@process.com. If you need lodging information, please contact Barbara Gaumond at 508-879-6994 x 359 or gaumond@process.com. From dhcp-v4@bucknell.edu Fri Jan 29 08:31:08 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.7.249]) by ietf.org (8.8.5/8.8.7a) with ESMTP id IAA26251 for ; Fri, 29 Jan 1999 08:31:07 -0500 (EST) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.8.8/8.8.8) with SMTP id IAA12776; Fri, 29 Jan 1999 08:26:19 -0500 (EST) Date: Fri, 29 Jan 1999 08:26:19 -0500 (EST) Message-Id: Errors-To: droms@bucknell.edu Reply-To: dhcp-v4@bucknell.edu Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: dhcp-v4@bucknell.edu (by way of Ralph Droms) To: Multiple recipients of list Subject: Re: Last Call on DHCP Options for SLP X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Type: text/plain; charset="us-ascii" Mime-Version: 1.0 message sent to dhcp-v4@bucknell.edu by MELLON@GROSSE.FUGUE.COM follows. ------------------------------------------------------------------------ > > my preference is that we define options using only the well defined set of > > types that have previously been used in option definition and not introduce > > a new encoding within an option. this option introduces a "structure" > > encoding within the option. > > Another way to issue this draft would be to make it stronger and say that > the DHC SLP Scope option, if present, always overrides the user's static > configuration. The boolean type is a well-known type that we all know how to support. If you, Erik, feel that this boolean is necessary, then I think you should leave it in. I'm all in favour of simplifying the job of DHCP server implementors, obviously, but not at the cost of key functionality. _MelloN_ From dhcp-v4@bucknell.edu Fri Jan 29 09:55:46 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.7.249]) by ietf.org (8.8.5/8.8.7a) with ESMTP id JAA29138 for ; Fri, 29 Jan 1999 09:55:45 -0500 (EST) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.8.8/8.8.8) with SMTP id JAA31074; Fri, 29 Jan 1999 09:51:16 -0500 (EST) Date: Fri, 29 Jan 1999 09:51:16 -0500 (EST) Message-Id: <000601be4b93$53700ac0$8a50fb8d@net-gwaters.corpnorth.baynetworks.com> Errors-To: droms@bucknell.edu Reply-To: gww@nortelnetworks.com Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: "Glenn Waters" To: Multiple recipients of list Subject: RE: Last Call on DHCP Options for SLP X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; Mime-Version: 1.0 > message sent to dhcp-v4@bucknell.edu by MELLON@GROSSE.FUGUE.COM follows. > ------------------------------------------------------------------------ > > > > my preference is that we define options using only the well > defined set of > > > types that have previously been used in option definition and > not introduce > > > a new encoding within an option. this option introduces a "structure" > > > encoding within the option. > > > > Another way to issue this draft would be to make it stronger > and say that > > the DHC SLP Scope option, if present, always overrides the user's static > > configuration. > > The boolean type is a well-known type that we all know how to > support. If you, Erik, feel that this boolean is necessary, then I > think you should leave it in. I'm all in favour of simplifying the > job of DHCP server implementors, obviously, but not at the cost of key > functionality. i whole heartily agree with your last sentence. what i am suggesting is that we standardize the way that types may be put together in options. then i implement can implement a generic option handler, instead of an new option handler for each new option that comes along that happens to be a little bit different. to be clear i have no problem at all with what erik is trying to accomplish. > _MelloN_ /gww From dhcp-v4@bucknell.edu Fri Jan 29 11:05:40 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.7.249]) by ietf.org (8.8.5/8.8.7a) with ESMTP id LAA00897 for ; Fri, 29 Jan 1999 11:05:35 -0500 (EST) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.8.8/8.8.8) with SMTP id KAA02817; Fri, 29 Jan 1999 10:57:53 -0500 (EST) Date: Fri, 29 Jan 1999 10:57:53 -0500 (EST) Message-Id: <36B1DA23.AC334AD7@germany.sun.com> Errors-To: droms@bucknell.edu Reply-To: Erik.Guttman@Germany.Sun.COM Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Erik Guttman To: Multiple recipients of list Subject: Re: Last Call on DHCP Options for SLP X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 X-Mailer: Mozilla 4.5 [en] (X11; U; SunOS 5.5.1 sun4m) Glenn, I want to make sure I fully understand the context of your consideration. I am therefore going to state the nature of things as completely as possible so that we can figure out what to do. Currently it looks like there are the following types transmitted: OPTION # TYPE USED ======== ========= 0,255 NOTHING (Pad, END) 1,2 LEN (4), 4 byte data (Subnet mask, Time offset, ...) 3,4,... LEN (4n), n 4 byte addresses follow (Router, Time Server, ...) 12 LEN (n), n restricted ASCII bytes (Hostname) 13,26 LEN (2), 2 byte data, unsigned, (Boot File Size, Interface MTU) 20,27 LEN (1), 0/1 binary value, (Non-Local Source Routing Enable, All Subnets are Local, ...) 21,58 LEN (8n), n times 4 bytes of address then 4 bytes of mask (Policy Filter Option, Static Route Option is similar) 22 LEN (1), 1 byte of unsigned data (Default IP Time to live) draft-ietf-dhc-slp-06.txt includes two options: Option 78 is of type 3 above: +------+-----+------+------+------+------+------+------+------+----- | 78 | n | a1 | a2 | a3 | a4 | a1 | a2 | a3 | ... +------+-----+------+------+------+------+------+------+------+----- This is therefore OK. Option 79 is the one you are concerned about. It has the form: +------+-----+------+------+------+------+------+------+------+----- | 79 | n | BOOL | s1 | s2 | s3 | s4 | s5 | s6 | ... +------+-----+------+------+------+------+------+------+------+----- BOOL is a 0 or nonzero. s1-s(n-1) are the bytes of a UTF-8 encoded string. Thus, there are two values encoded. Further it is possible that the value of n will be 1, which is to say the string may be omitted from this option. One question is: How is this different than options 21 or 58 which include n pairs of 4 byte data. This includes one pair of boolean and string data? A facile answer is that option 21 and 58 concern pairs of 4 byte words where this concerns a combination of types used in options 20 and 27 on the one hand and a string value on the other, (like option 12). Do options need to contain only tuples of data where all data types in the tuple have the same length? Why? Do you object to the option going forward because you fear a precedent which will allow arbitrarily formatted options to be standardized? I am certainly not attempting to open the door to that. I explicitely asked the WG if they thought this particular format would be easy to implement on existing servers; the answer in Orlando was "Yes." Erik - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Glenn Waters wrote: > > > message sent to dhcp-v4@bucknell.edu by MELLON@GROSSE.FUGUE.COM follows. > > ------------------------------------------------------------------------ > > > > > > my preference is that we define options using only the well > > defined set of > > > > types that have previously been used in option definition and > > not introduce > > > > a new encoding within an option. this option introduces a "structure" > > > > encoding within the option. > > > > > > Another way to issue this draft would be to make it stronger > > and say that > > > the DHC SLP Scope option, if present, always overrides the user's static > > > configuration. > > > > The boolean type is a well-known type that we all know how to > > support. If you, Erik, feel that this boolean is necessary, then I > > think you should leave it in. I'm all in favour of simplifying the > > job of DHCP server implementors, obviously, but not at the cost of key > > functionality. > > i whole heartily agree with your last sentence. what i am suggesting is > that we standardize the way that types may be put together in options. then > i implement can implement a generic option handler, instead of an new option > handler for each new option that comes along that happens to be a little bit > different. > > to be clear i have no problem at all with what erik is trying to accomplish. > > > _MelloN_ > > /gww From dhcp-v4@bucknell.edu Fri Jan 29 18:06:09 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.7.249]) by ietf.org (8.8.5/8.8.7a) with ESMTP id SAA10689 for ; Fri, 29 Jan 1999 18:06:08 -0500 (EST) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.8.8/8.8.8) with SMTP id SAA01192; Fri, 29 Jan 1999 18:01:43 -0500 (EST) Date: Fri, 29 Jan 1999 18:01:43 -0500 (EST) Message-Id: <199901292152.QAA27958@funnel.cisco.com> Errors-To: droms@bucknell.edu Reply-To: kkinnear@cisco.com Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Kim Kinnear To: Multiple recipients of list Subject: Failover Interim Meeting Feb 10/11 - overview agenda X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Type: text/plain; charset="us-ascii" Mime-Version: 1.0 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 In case you are interested, here is a copy of the agenda for the Failover meeting coming up in early February... If you haven't received a longer version of this agenda from me in email, then I don't know you are coming. Please let me know if you wish to come. Thanks! Cheers -- Kim --------------------------------------------- Overview Agenda for Failover Interim Meeting, February 10/11 1999. Held at: Cisco Systems 300 Apollo Dr. Chelmsford MA, 01824 ================= Day 1: February 10, 1999 Start time: 10:00 am Introductions Goals of the meeting -- 5 mins 1. Understand requirements that are not met or concerns people have with the current failover protocol (or draft), and attempt to modify the protocol and draft to meet these requirements or concerns. 2. Review the technical correctness of the failover protocol. Revise the protocol as necessary to solve any problems found. 3. Promote better understanding of the failover protocol as currently defined. Agenda Bashing and Gathering of New Issues -- 20 mins History/Context - 5 mins Protocol Basics -- 45 mins A *very* rapid overview of the key points of the protocol: General protocol overview: 5 minutes Maximum client lead time (used to be MDLI): 10 minutes States: 5 min Examples of Common events: 10 mins Hard cases: 5 mins Q&A about existing protocol: 10 mins Discuss Issues -- rest of the day Protocol Goals: 1. What about more than two servers? Isn't this important? 2. What about load balancing? Protocol Model: 1. What is being synchronized among the DHCP servers? What data must flow from one to the other? 2. "Push" or "Pull" model: Which is advocated, which is allowed? 3. Reliability model: just how far can servers get out of sync and for how long? What is "correct" and what is good operational practice. Protocol Details: 1. How do the POOLREQ/POOLRESP messages work? Why? 2. How do the state fields and the flag bits in the packet interrelate? Shouldn't they all by states? 3. What does it mean to allow renews to come from both servers? How might one use this to assist in load balancing. 4. What about giving a client less than the "configured" lease time -- is that really OK? How often will it happen? 5. Isn't the startup sequence complicated? Can't we we simplify it? Packet Format: 1. Compatibility with DHCP/BOOTP packet formats. Why be compatible at all? 2. Payload offset field -- why allow for "future expansion", since most such allowances don't ever really work out in practice. Protocol Embedding into Network Infrastructure: 1. In the "symmetric" situation, where two server's are both primary and secondary for part of the addresses, how do they keep the messages straight? How do they identify the address pools about this this message applies? 2. TCP vs. UDP: What are the pro's and con's for each approach, once we've agreed (more or less) on the overall approach for the protocol. [Volz] 3. Clock synchronization -- how much do clocks need to be synchronized? Are we recreating NTP in this protocol? ===================== Day 2: February 11, 1999. Start time: 8:30 am. Agenda Bashing: 10 mins Suggest that we choose at most 3 issues -- the 3 most important remaining issues, and try to come to some sort of closure on those. Close out 3 most important issues: 3 hours, 1 hour (or so ) each What next: 30 mins From dhcp-v4@bucknell.edu Sun Jan 31 17:50:43 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.7.249]) by ietf.org (8.8.5/8.8.7a) with ESMTP id RAA05880 for ; Sun, 31 Jan 1999 17:50:43 -0500 (EST) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.8.8/8.8.8) with SMTP id RAA26134; Sun, 31 Jan 1999 17:47:43 -0500 (EST) Date: Sun, 31 Jan 1999 17:47:43 -0500 (EST) Message-Id: Errors-To: droms@bucknell.edu Reply-To: droms@bucknell.edu Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: "Ralph E. Droms" To: Multiple recipients of list Subject: Re: Last Call on DHCP Options for SLP (fwd) X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Type: TEXT/PLAIN; charset=US-ASCII Mime-Version: 1.0 message sent to dhcp-v4@bucknell.edu by MELLON@GROSSE.FUGUE.COM follows. ------------------------------------------------------------------------ > Do you object to the option going forward because you fear a precedent > which will allow arbitrarily formatted options to be standardized? I > am certainly not attempting to open the door to that. I explicitely > asked the WG if they thought this particular format would be easy to > implement on existing servers; the answer in Orlando was "Yes." I did say in Orlando that this format is easy to implement, and several of the other DHCP server implementors nodded and mmm-hmmed sagely. The objection previously was with putting bit-fields into an option, not with putting more than one data type into the option. There's no really special interpretation needed here - just two data items of different types, concatenated. I will admit that this is a bit harder than interpreting a single data item, but I really think it's going too far to say that this is adding another data type, or arguing that it shouldn't be done because it is somehow hard to implement. I suppose the counter-proposal would be to have two options, one of which contains the boolean and one of which contains the the UTF8-encoded name. Given our determination to motivate ourselves to implement wider option codes, I guess this isn't an entirely bad idea, but we've been talking about this option for a *long* time. The current proposal is perfectly reasonable and implementable. Requiring Erik to go through yet another revision for the stated reason strikes me as being unreasonable. _MelloN_ From dhcp-v4@bucknell.edu Sun Jan 31 17:56:29 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.7.249]) by ietf.org (8.8.5/8.8.7a) with ESMTP id RAA05904 for ; Sun, 31 Jan 1999 17:56:28 -0500 (EST) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.8.8/8.8.8) with SMTP id RAA00510; Sun, 31 Jan 1999 17:54:49 -0500 (EST) Date: Sun, 31 Jan 1999 17:54:49 -0500 (EST) Message-Id: Errors-To: droms@bucknell.edu Reply-To: droms@bucknell.edu Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: "Ralph E. Droms" To: Multiple recipients of list Subject: Revised Internet-Draft boilerplate (fwd) X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Type: TEXT/PLAIN; charset=US-ASCII Mime-Version: 1.0 FYI - all draft authors should be sure to include the new boilerplate in any drafts in the future... - Ralph ===== ---------- Forwarded message ---------- Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.bucknell.edu (8.8.8/8.8.8) with ESMTP id MAA16208 for ; Fri, 29 Jan 1999 12:38:27 -0500 (EST) Received: (from adm@localhost) by ietf.org (8.8.5/8.8.7a) id LAA01289 for ietf-123-outbound.06@ietf.org; Fri, 29 Jan 1999 11:25:02 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id LAA01236 for ; Fri, 29 Jan 1999 11:23:40 -0500 (EST) Message-Id: <199901291623.LAA01236@ietf.org> To: IETF-Announce: ; Subject: Revised Internet-Draft boilerplate From: The IESG Date: Fri, 29 Jan 1999 11:23:40 -0500 Sender: scoya@ns.cnri.reston.va.us Following up on the discussion in the plenary session at the IETF meeting in Orlando and the discussion on the poised mailing list, the IESG on Thursday, January 28th approved the new boilerplate text that must be included with all Internet-Draft submissions. Beginning Monday, February 1, all Internet-Draft submissions must include the new boilerplate. Any submissions that do not use the new text will be returned to the author/submitter. The new template can be accessed with this URL: http://www.ietf.org/ietf/1id-guidelines.txt