From sacadmin Tue Sep 21 13:54:32 2004 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 21 Sep 2004 16:53:37 -0400 From: James Carlson To: psarc@sac.sfbay.sun.com cc: Peter.Memishian@Sun.COM Subject: 2004/674 DHCP Vendor Class Algorithm Content-Length: 4440 I'm sponsoring this fast-track request for Peter Memishian. The timer is set to 09/28/2004. Overview ======== In order to fix 5028977, this case proposes to slightly change the current algorithm used to map a platform name to a DHCP vendor class identifier. The new format is identical to the old format, with one exception: the DHCP vendor class identifier is only prefixed with "SUNW." if the platform name does *not* already contain a stock symbol. Fujitsu systems, whose platform names start with "FJSV,", are the only systems which will be affected. Further, this case also proposes to document the format in dhcpagent(1M). We also propose to classify the format as "Evolving". The requested release binding is minor. Details ======= The DHCP vendor class identifier is one of a set of identifiers the DHCP client provides to the DHCP server during lease negotiation. The DHCP server uses the class identifier to help decide what vendor options are applicable to the client, and what the values of those options should be. RFC 2132, which documents the vendor class identifier, does not specify any particular format, but just states: This option is used by DHCP clients to optionally identify the vendor type and configuration of a DHCP client. The information is a string of n octets, interpreted by servers. Vendors may choose to define specific vendor class identifiers to convey particular configuration or other identification information about a client. For example, the identifier may encode the client's hardware configuration. However, Solaris has an established de-facto format that we have been using since Solaris 2.6: STOCK-SYMBOL.Platform-Name -- e.g.: SUNW.Ultra-60. One will note that this is the same as "uname -i | tr , ." with one exception: i86pc. To accomodate i86pc, we added code to the DHCP client which automatically prepends "SUNW." if the returned platform name does not already include it. This is done to increase the probability that the client class identifier is globally unique across all operating systems that the DHCP server may be serving. Unfortunately, this algorithm failed to consider that it might run on platforms sold by other vendors. As such, on Fujitsu machines, the DHCP client uses a bogus vendor class identifier of "SUNW.FJSV.platform-name", rather than the correct "FJSV.platform-name". Thus, we propose to revise the algorithm so that the DHCP vendor class identifier is only prefixed with "SUNW." if the platform name does *not* already contain a stock symbol. Compatibility ============= This change will not affect Sun SPARC systems, since all such platform names already start with "SUNW,", and will not affect x86 systems since all systems have the unprefixed platform name of "i86pc". Thus, the change is isolated to Fujitsu systems. While some that DHCP servers which serve Fujitsu systems will have to be updated to reflect the new class identifier, the impact is mitigated because: * The vendor class identifier is primarily used for DHCP-based net installs. However, the Fujitsu PROM's have always properly identified their machines as FJSV.platform-name. Thus, DHCP servers have historically included entries for both vendor class identifiers. * DHCP is more prevalent on desktop systems. Since Fujitsu has targeted the server market, we expect comparatively few Fujitsu systems are configured as DHCP clients. Still, we understand that some systems will be affected. Unfortunately, since the DHCP server will necessarily be serving a variety of different operating systems (and thus, different releases of Solaris), and may itself be running on a previous release of Solaris, there is no transparent way to handle systems which are affected by this change. However, we feel it's best we correct this mistake now, before it sediments further. Documentation ============= We propose to add the following to dhcpagent(1M): All DHCP packets sent by dhcpagent include a vendor class identifier (RFC 2132, option code 60). This identifier is the same as the platform name returned by "uname -i", except: * Any commas in the platform name are changed to periods. * If the name does not start with a stock symbol and a comma, it is automatically prefixed with "SUNW." From sacadmin Tue Sep 21 16:43:18 2004 Date: Tue, 21 Sep 2004 16:42:33 -0700 (PDT) From: Mike Oliver Subject: Re: 2004/674 DHCP Vendor Class Algorithm To: Peter.Memishian@Sun.COM Cc: psarc@sac.sfbay.sun.com MIME-version: 1.0 Content-type: TEXT/plain; charset=us-ascii Content-MD5: VwgWyBg5uaUM6UvkdM6SwA== Content-Length: 5059 James Carlson wrote: > I'm sponsoring this fast-track request for Peter Memishian. The timer > is set to 09/28/2004. > > > Overview > ======== > > In order to fix 5028977, this case proposes to slightly change the current > algorithm used to map a platform name to a DHCP vendor class identifier. > > The new format is identical to the old format, with one exception: the DHCP > vendor class identifier is only prefixed with "SUNW." if the platform name > does *not* already contain a stock symbol. I suppose someone has to ask the obvious question: Precisely how do you propose to recognise the presence of a stock symbol? Are you really proposing to look for a match against some form of regular expression? > Fujitsu systems, whose platform > names start with "FJSV,", are the only systems which will be affected. Just out of curiosity, do you happen to know the form of the client identifiers presented by Tadpole and Naturetech systems? Mike. -- mike.oliver@sun.com > Further, this case also proposes to document the format in dhcpagent(1M). > We also propose to classify the format as "Evolving". > > The requested release binding is minor. > > Details > ======= > > The DHCP vendor class identifier is one of a set of identifiers the DHCP > client provides to the DHCP server during lease negotiation. The DHCP > server uses the class identifier to help decide what vendor options are > applicable to the client, and what the values of those options should be. > > RFC 2132, which documents the vendor class identifier, does not specify any > particular format, but just states: > > This option is used by DHCP clients to optionally identify the vendor > type and configuration of a DHCP client. The information is a string > of n octets, interpreted by servers. Vendors may choose to define > specific vendor class identifiers to convey particular configuration > or other identification information about a client. For example, the > identifier may encode the client's hardware configuration. > > However, Solaris has an established de-facto format that we have been using > since Solaris 2.6: STOCK-SYMBOL.Platform-Name -- e.g.: SUNW.Ultra-60. > > One will note that this is the same as "uname -i | tr , ." with one > exception: i86pc. To accomodate i86pc, we added code to the DHCP client > which automatically prepends "SUNW." if the returned platform name does not > already include it. This is done to increase the probability that the > client class identifier is globally unique across all operating systems > that the DHCP server may be serving. > > Unfortunately, this algorithm failed to consider that it might run on > platforms sold by other vendors. As such, on Fujitsu machines, the DHCP > client uses a bogus vendor class identifier of "SUNW.FJSV.platform-name", > rather than the correct "FJSV.platform-name". > > Thus, we propose to revise the algorithm so that the DHCP vendor class > identifier is only prefixed with "SUNW." if the platform name does *not* > already contain a stock symbol. > > Compatibility > ============= > > This change will not affect Sun SPARC systems, since all such platform names > already start with "SUNW,", and will not affect x86 systems since all > systems have the unprefixed platform name of "i86pc". Thus, the change is > isolated to Fujitsu systems. > > While some that DHCP servers which serve Fujitsu systems will have to be > updated to reflect the new class identifier, the impact is mitigated > because: > > * The vendor class identifier is primarily used for DHCP-based > net installs. However, the Fujitsu PROM's have always properly > identified their machines as FJSV.platform-name. Thus, DHCP > servers have historically included entries for both vendor > class identifiers. > > * DHCP is more prevalent on desktop systems. Since Fujitsu has > targeted the server market, we expect comparatively few Fujitsu > systems are configured as DHCP clients. > > Still, we understand that some systems will be affected. Unfortunately, > since the DHCP server will necessarily be serving a variety of different > operating systems (and thus, different releases of Solaris), and may itself > be running on a previous release of Solaris, there is no transparent way to > handle systems which are affected by this change. However, we feel it's > best we correct this mistake now, before it sediments further. > > Documentation > ============= > > We propose to add the following to dhcpagent(1M): > > All DHCP packets sent by dhcpagent include a vendor class > identifier (RFC 2132, option code 60). This identifier is > the same as the platform name returned by "uname -i", except: > > * Any commas in the platform name are changed to > periods. > > * If the name does not start with a stock symbol and > a comma, it is automatically prefixed with "SUNW." From sacadmin Tue Sep 21 17:31:58 2004 From: Peter Memishian MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 21 Sep 2004 20:30:14 -0400 To: Mike Oliver Cc: Peter.Memishian@Sun.COM, psarc@sac.sfbay.sun.com Subject: Re: 2004/674 DHCP Vendor Class Algorithm Content-Length: 1157 > I suppose someone has to ask the obvious question: Precisely how do you > propose to recognise the presence of a stock symbol? we don't recognize it. we just look for a comma in the platform name and assume everything before it is a stock symbol. > Just out of curiosity, do you happen to know the form of the client > identifiers presented by Tadpole and Naturetech systems? that's a good question. i don't have systems to check on, but google suggests that naturetech systems use "NATE,platform-name" -- in which case they will also be affected by this change, since the dhcp client will now use "NATE.platform-name" instead of "SUNW.NATE.platform-name". google further suggests that tadpole uses "Tadpole_platform-name" -- in which case they are not affected, and retain the (very questionable) use of "SUNW.Tadpole_platform-name". as you point out above, since we can't intuit what's a stock symbol, there's not a whole lot we can do about companies that ship platforms that don't use the defacto format. as an aside, i'm surprised to see that there doesn't appear to be any documented rule for the format of the platform name. -- meem From sacadmin Wed Sep 29 12:29:51 2004 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 29 Sep 2004 15:28:56 -0400 From: James Carlson To: psarc@sac.sfbay.sun.com cc: Peter.Memishian@Sun.COM Subject: 2004/674 DHCP Vendor Class Algorithm Content-Length: 422 This fast-track request was approved during ARC business at today's meeting. The final specification (amended to include the Naturetech and Tadpole details) is in the case directory as 'spec.txt'. -- James Carlson, IP Systems Group Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From sacadmin Wed Sep 29 14:55:56 2004 From: Peter Memishian MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 29 Sep 2004 17:53:52 -0400 To: James Carlson Cc: psarc@sac.sfbay.sun.com, Peter.Memishian@Sun.COM Subject: re: 2004/674 DHCP Vendor Class Algorithm Content-Length: 356 > This fast-track request was approved during ARC business at today's > meeting. The final specification (amended to include the Naturetech > and Tadpole details) is in the case directory as 'spec.txt'. spec.text isn't quite correct: there's no change for tadpole systems (it generates SUNW.Tadpole_ currently, and will continue to do so). -- meem From sacadmin Thu Sep 30 04:29:28 2004 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 30 Sep 2004 07:28:32 -0400 From: James Carlson To: Peter Memishian Cc: psarc@sac.sfbay.sun.com Subject: re: 2004/674 DHCP Vendor Class Algorithm Content-Length: 1066 Peter Memishian writes: > > > This fast-track request was approved during ARC business at today's > > meeting. The final specification (amended to include the Naturetech > > and Tadpole details) is in the case directory as 'spec.txt'. > > spec.text isn't quite correct: there's no change for tadpole systems (it > generates SUNW.Tadpole_ currently, and will continue to do so). I've changed this: That last one will end up as "SUNW.Tadpole_", but there's not much we can do about systems that don't use the defacto format. to this: That last one will still be "SUNW.Tadpole_" after the change, but there's not much we can do about systems that don't use the defacto format. I don't think it's a significant change, as the point was that "Tadpole" should be the vendor name but isn't, but I believe that fixes your concern. -- James Carlson, IP Systems Group Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From sacadmin Thu Sep 30 06:45:12 2004 From: Peter Memishian MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 30 Sep 2004 09:43:07 -0400 To: James Carlson Cc: Peter Memishian , psarc@sac.sfbay.sun.com Subject: re: 2004/674 DHCP Vendor Class Algorithm Content-Length: 183 > I don't think it's a significant change, as the point was that > "Tadpole" should be the vendor name but isn't, but I believe that > fixes your concern. yep, thanks! -- meem