I'm vaguely unfamiliar with vendor-use of 249 (I recall it, but I
can't remember why), but 252 I recognize as being used by WPAD;

  http://en.wikipedia.org/wiki/Web_Proxy_Autodiscovery_Protocol
  http://www.ietf.org/proceedings/99nov/I-D/draft-ietf-wrec-wpad-01.txt

MAC OSX is indeed nice enough to put this on their PRL; Windows (as of
95 I think?) will DHCPINFORM multiple times expecting to find WPAD in
the reply, without putting it in the PRL, and will continue to
retransmit if it's absent.  If you throw 252 in there, it will only
DHCPINFORM once, and (if you search the archive of the dhcp-users
mailing list) you'll see someone who tried this got hits on the proxy
they named which indicated they were from "Microsoft Industry
Updater."  So it sounds like Windows' automatic updates use WPAD to
locate a proxy to load updates from.

It also appears that if you provide this option in normal Request/Acks
that other software, such as IE and Firefox, will find and use its
contents.

I believe the reason it appears in Mac OSX's PRL is because Safari
will use it.


Ruben;

You can use whatever option codes you want from 224 to 254 inclusive,
including options 249 and 252.  Collissions within the site-local
space was one of the things Ted prepared for when he originally wrote
the software; you can manage collisions in ISC DHCP by using 'site
local spaces'.  Documentation for these can be found in the dhcpd.conf
manpage, but here's a brief primer;

	option space vendor1;
	option vendor1.blart code 252 = text;

	option space vendor2;
	option vendor2.frobnitz code 252 = array of ip address;

	class "vendor1s" {
		match if option vendor-class-identifier = "vendor1";

		site-local-space "vendor1";

		# vendor1s do not put 252 on their PRL!
		option dhcp-parameter-request-list =
			concat(option dhcp-parameter-request-list, FC);
	}

	class "vendor2s" {
		match if option vendor-class-identifier = "vendor2";

		site-local-space "vendor2";
	}

	option vendor1.blart "http://global.example.com/your.pac";
	option vendor2.frobnitz global.example.com;

	subnet yadda yadda {
		option vendor1.blart "http://local.example.com/your.pac";
	}

In this example, the vendor-class-identifier provided by the client
(check wireshark or vendor documentation to find out what these really
say) is used to assign the client a site-local-space.  When the
reply packet is transmitted, options within the "site local" range are
tried first from the named site local space.  So vendor1's will use
the vendor1.blart values, and vendor2's are given theirs.

This gives you a way to make sense of varying, different views of
the site-local option space.

3.1.0 and later differ from 3.0.x maintenance track; in 3.1.0 we
changed the site-local cutoff to 224 to track RFC 3942, but forgot to
put in a warning for configs using options prior to 224.  We're going
to put in a warning in 3.1.1, and since we're bothering to detect
options between 128-224, we're supporting them as well (3.1.0 won't
"find" options between 128-224 in site-local spaces).

-- 
Ash bugud-gul durbatuluk agh burzum-ishi krimpatul.
Why settle for the lesser evil?	 https://secure.isc.org/store/t-shirt/
-- 
David W. Hankins	"If you don't do it right the first time,
Software Engineer		     you'll just have to do it again."
Internet Systems Consortium, Inc.		-- Jack T. Hankins

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg