From sacadmin Fri Jun 25 06:06:20 2004 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Fri, 25 Jun 2004 09:05:37 -0400 From: James Carlson To: psarc@sac.sfbay.sun.com cc: Jim Paugh Subject: 2004/534 DHCP Shared Network Content-Length: 3742 I'm sponsoring the following fast-track request for Jim Paugh. The timer is set to 07/02/2004. Summary and Problem Description ------------------------------- The in.dhcpd(1M) server assumes that there will be one subnet per physical interface on a Solaris box. This assumption causes problems for applications and network topologies that require configuring multiple subnets per physical interface and leaves our dhcp server at a competitive disadvantage to other 3rd party offerings, such as ISC's dhcp server. This RFE will correct this by modifying the in.dhcpd to recognize and configure more than one subnet address per interface. The server will then be able to manage leased addresses and respond to client requests on these multiple subnets. Release Binding --------------- Patch/micro - For all but the default change Minor - For the default value change Changes to in.dhcpd ------------------ The server will be modified to read the interface table and include logical interfaces that represent additional subnets on the physical interface. These subnets will be configured as part of a shared network. Client requests received on the physical interface will have no indication for which subnet the clients are destined. From an administrator's perspective, assignment of addresses will be arbitrary. In an attempt to distribute addresses evenly, a "round robin" method of assignment will be used. The in.dhcpd '-i' option -------------------------- The 'in.dhcpd -i' option will be modified to allow logical interfaces of the format, :x (e.g. hme0:1). Changes to /etc/inet/dhcpsvc.conf file -------------------------------------- A new keyword, SHARED_NETWORKS, will be added to dhcpsvc.conf that will indicate whether this feature should be enabled or disabled with a value of TRUE of FALSE. This will default to FALSE for the patch/micro binding for strict compatibility, and will change to TRUE for the next minor release. The keyword, INTERFACES, will be modified to include logical interfaces in the list of interfaces to listen to. Impact of changes ----------------- These changes to the server will affect existing dhcp server installations in the following way. An existing installed in.dhcpd server configured with multiple subnets on a single physical interface will start listening for requests on those subnets that were previously ignored. Since this maybe an undesirable effect, the SHARED_NETWORKS keyword will be added with a default to FALSE for patch releases. The default will be TRUE in the next minor release. (A future case may remove the keyword itself entirely.) What will not be included ------------------------- The subnet option that is described in RFC 3011 will not be included with this RFE. The subnet option could be used by clients to control the subnets to which subnets they are assigned. This is not a requirement for this project and can be done at a later time. Interface Table The following interfaces will be modified by the solution above. Interface Classification Comments ------------------------------------------------------------------------ in.dhcpd -i Evolving Modified to include logical interfaces. ------------------------------------------------------------------------ INTERFACES Evolving INTERFACES keyword in dhcpsvc.conf updated to accept logical interfaces. ------------------------------------------------------------------------ SHARED_NETWORK Unstable Added to /etc/inet/dhcpsvc.conf. ------------------------------------------------------------------------ From sacadmin Fri Jun 25 07:33:07 2004 From: Bill Sommerfeld To: James Carlson cc: psarc@sac.sfbay.sun.com, Jim Paugh Subject: Re: 2004/534 DHCP Shared Network Date: Fri, 25 Jun 2004 10:32:20 -0400 Content-Length: 560 > These subnets will be configured as part of a shared network. > Client requests received on the physical interface will have no > indication for which subnet the clients are destined. From an > administrator's perspective, assignment of addresses will be > arbitrary. In an attempt to distribute addresses evenly, a "round > robin" method of assignment will be used. I presume that the round robin assignment occurs only after the daemon checks all existing subnets attached to the interface for a matching lease/fixed address assignment... - Bill From sacadmin Fri Jun 25 08:12:02 2004 Date: Fri, 25 Jun 2004 17:12:47 +0200 (MEST) From: Steve McKinty Subject: Re: 2004/534 DHCP Shared Network To: James.Paugh@sun.com Cc: psarc@sac.sfbay.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: V120kdsY6P/BuHQ7Ij5ERA== Content-Length: 754 > The server will be modified to read the interface table and include > logical interfaces that represent additional subnets on the physical > interface. These subnets will be configured as part of a shared > network. Client requests received on the physical interface will have > no indication for which subnet the clients are destined. From an > administrator's perspective, assignment of addresses will be > arbitrary. In an attempt to distribute addresses evenly, a "round > robin" method of assignment will be used. Maybe a dumb quetsion, since I'm not a subject-matter expert, but what about VLAN situations, where multiple VLANs are configured on an interface? In this case the client would have to get an address on the right VLAN. Steve From sacadmin Fri Jun 25 08:18:20 2004 Date: Fri, 25 Jun 2004 16:17:32 +0100 From: Paul Durrant Subject: Re: 2004/534 DHCP Shared Network To: Steve McKinty Cc: psarc@sac.sfbay.sun.com, James.Paugh@Sun.COM MIME-version: 1.0 Content-type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary=Apple-Mail-22-347786420 Content-transfer-encoding: 7bit X-Pgp-Agent: GPGMail 1.0.1 (v33, 10.3) Content-Length: 1915 --Apple-Mail-22-347786420 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed On 25 Jun 2004, at 16:12, Steve McKinty wrote: > >> The server will be modified to read the interface table and include >> logical interfaces that represent additional subnets on the physical >> interface. These subnets will be configured as part of a shared >> network. Client requests received on the physical interface will have >> no indication for which subnet the clients are destined. From an >> administrator's perspective, assignment of addresses will be >> arbitrary. In an attempt to distribute addresses evenly, a "round >> robin" method of assignment will be used. > > Maybe a dumb quetsion, since I'm not a subject-matter expert, but what > about VLAN situations, where multiple VLANs are configured on an > interface? In this case the client would have to get an address on the > right VLAN. different VLAN == different 'physical' interface as far as the client is concerned Paul ==================================================== Paul Durrant Sun Microsystems Senior Software Engineer 54 Clarendon Road Solaris Networking & Security Watford Phone: +44 1923 696823/x(70)78923 HERTS WD17 1DU Fax: +44 1923 696801 UK Mobile: +44 7717 868957 mailto: paul.durrant@sun.com http://watford.uk.sun.com/~pauldur ==================================================== --Apple-Mail-22-347786420 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) iD8DBQFA3EIMFA5Mscx8cjwRAk74AJ9zYi5NfII6R7+eIWxJ8ofdB3ho4wCbBRsP sK791VTmFX/+lQUTpFwi0Bg= =oTke -----END PGP SIGNATURE----- --Apple-Mail-22-347786420-- From sacadmin Fri Jun 25 10:00:55 2004 Date: Fri, 25 Jun 2004 10:00:12 -0700 From: Jim Paugh User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: sommerfeld@east.sun.com CC: James Carlson , psarc@sac.sfbay.sun.com, Jim Paugh Subject: Re: 2004/534 DHCP Shared Network Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Length: 688 Bill Sommerfeld wrote: >>These subnets will be configured as part of a shared network. >>Client requests received on the physical interface will have no >>indication for which subnet the clients are destined. From an >>administrator's perspective, assignment of addresses will be >>arbitrary. In an attempt to distribute addresses evenly, a "round >>robin" method of assignment will be used. >> >> > >I presume that the round robin assignment occurs only after the daemon >checks all existing subnets attached to the interface for a matching >lease/fixed address assignment... > Yes, it's only in the case that the address is available and is being offered as a new lease. Jim From sacadmin Wed Jun 30 12:33:22 2004 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 30 Jun 2004 15:32:34 -0400 From: James Carlson To: psarc@sac.sfbay.sun.com cc: Jim Paugh Subject: Re: 2004/534 DHCP Shared Network Content-Length: 421 This fast-track request was approved during ARC business at today's meeting. I've extracted the final specification (with a clarification for Bill's question) as 'spec.txt' in the case directory. -- 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