Re: [dhcwg] URL option (again)?

[Ralph Droms <[e-mail]>]

I don't think any of the existing DHCp options really fit your intended 
application.  Option 114 is unused (see 
draft-ietf-dhc-unused-optioncodes-06.txt).

There are a couple of ways you could proceed.

You could define a vendor-specific information option (option 43 in RFC 
2132).  You'll need to make up your own "vendor class identifier" (option 
60) that the client can send to the server, and you'll only be able to use 
this option if the clients are not already using options 60 and 43.

If the new option is to be used for experimentation at your site, you could 
use one of the site-specific option codes (128-254) and define your own 
option.  If you eventually want to use the option outside your site, you 
can put the option through the IETF standards process to obtain an 
IANA-assigned option code.

In either case, you'll need access to the client code on the host to add 
code that can interpret the contents of the vendor-specific info and a 
server that you can program to return the appropriate option(s) to the client.

- Ralph Droms

At 01:49 PM 7/24/2003 -0400, Thamer Al-Harbash wrote:
>Hello all,
>we are investigating location based services for
>mobile devices that are connected to our campus network
>(and thus the Internet) via WLAN.
>
>Our intention is to provide users with web-based information
>depending on the area they reside in, while consuming as little
>resources as possible, and withoud introducing new protocol stacks.
>
>I found a the document specifying the URL option (#114) but
>it seems to be unused as well as too little flexible.
>
>The only other dhcp option that includes URLs is in the uap option
>set (rfc2485) to pass the url of a login page, which is too specific
>for our intentions.
>
>I would like to use an option that codes not only the url itself, but
>also a string that identifies the service/application that should
>be addressed. The latter lets us route information to different applications
>on the mobile client and clarify the intentions/content of the passed
>URL.
>
>URL data can be passed whenever the client asks for a new address, or
>could be pushed asynchronously by the server using the reconfigure
>extension (a la rfc3203).
>
>As I have not played around with dhcp implementations yet, I'd
>like to know if this is seems feasible and a sound approach.
>
>Is there a option region reserved for experimental options so I can
>start a test implementation without too many side effects?


_______________________________________________
dhcwg mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/dhcwg