Re: Re[2]: DHCP & MAC Address Grouping
Ted Lemon <mellon@fugue.com> Fri, 24 May 1996 20:27 UTC
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03364;
24 May 96 16:27 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa03360;
24 May 96 16:27 EDT
Received: from reef.bucknell.edu by CNRI.Reston.VA.US id aa13447;
24 May 96 16:27 EDT
Received: from localhost by reef.bucknell.edu with SMTP
(5.65/IDA-1.2.8) id AA29213; Fri, 24 May 1996 16:25:25 -0400
Date: Fri, 24 May 1996 16:25:25 -0400
Message-Id: <199605242005.NAA08271@toccata.fugue.com>
Errors-To: droms@bucknell.edu
Reply-To: dhcp-v4@bucknell.edu
Originator: dhcp-v4@bucknell.edu
X-Orig-Sender: dhcp-v4@bucknell.edu
Precedence: bulk
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Ted Lemon <mellon@fugue.com>
To: Multiple recipients of list <dhcp-v4@bucknell.edu>
Subject: Re: Re[2]: DHCP & MAC Address Grouping
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
X-Comment: Discussion of DHCP for IPv4
> For example say I have Unix and NT boxes sharing a subnet, but the > configuration for the Unix machines for DNS is different to that of the NT > boxes. > I could use the vendor portion of the MAC address to decide if I want to > service the DHCP request - given the Unix (as long as it's not PC Unix) is > most likely to have a different vendors Ethernet adapter (e.g. SUN rather > than Compaq[0080F5]) Yup. Unfortunately the whole thing falls down if you're running an environment with a lot of unix and non-unix PCs. Still, in isolated instances, it could definitely be useful. I think it would be more useful to use the vendor class tag or user class tag to differentiate between clients, though, although not many clients actually use these... :'( _MelloN_
- DHCP & MAC Address Grouping Marcel Groenewald
- Re: DHCP & MAC Address Grouping Ted Lemon
- Re[2]: DHCP & MAC Address Grouping Luke ROBERTS
- Re: Re[2]: DHCP & MAC Address Grouping Ted Lemon