@lparkes Nice, thanks! This is all I really need for #282, I'd be happy to close that one if this merges.

@lparkes I cannot find any public reference for IANA or RFC DHCP option 245.
https://www.iana.org/assignments/bootp-dhcp-parameters/bootp-dhcp-parameters.xhtml

I don't argue your change is good, but I can't find any standard outside of Azure for it.

@rsmarples I believe you are correct. My understanding is that this is an Azure specific option in the IANA "Reserved (Private Use)" option range 224-254. For the comment in the commit I copied the phrasing of the similar option 249 (also in that same range).

Should a link/reference to some suitable Azure documentation be added to the comment in the config file?

@rsmarples I believe you are correct. My understanding is that this is an Azure specific option in the IANA "Reserved (Private Use)" option range 224-254. For the comment in the commit I copied the phrasing of the similar option 249 (also in that same range).

Should a link/reference to some suitable Azure documentation be added to the comment in the config file?

At a minimum I think yes. We strive to be a public service and this is very much a private option.
My only fear is what happens if IANA decide to give this option another meaning?

Currently dhcpcd only has RFC options (although a few have expired).

Your statement that "dhcpcd only has RFC options" is not entirely correct because it has a definition for option 249, which while the contents of that option have an RFC number, the option number itself is not assigned by an RFC or IANA.

I am not concerned about option 245 being redefined for something else in the future because there are still plenty of unassigned option numbers for IANA to allocate. On top of that, if the site-specific "Reserved (Private Use)" range was redefined again (as in RFC 3942) then Microsoft could simply ask IANA to define option 245 to its Azure usage. RFC 3942 defined a process for this.

What I am concerned about is if someone decides to use option 245 in their own cloud for a similar service, but with a different definition. Maybe an IPv6 address instead of an IPv4 address. This is a risk for the entire range 224-254, including the currently implemented option 249.

We must support site-specific options in some way or other because the sites will set them in the DHCP servers and the clients need to get them somehow. If we are wary of decoding the site-specific options, then maybe put in 31 site specific binhex definitions. I don't actually know what a binhex definition is, but I think I can guess.

If we are wary of decoding the site-specific options, then maybe put in 31 site specific binhex definitions. I don't actually know what a binhex definition is, but I think I can guess.

@lparkes I assume you're suggesting something like this?

# Options 224-254 are reserved for Private Use
define 224	binhex			private_option_224
define 225	binhex			private_option_225
define 226	binhex			private_option_226
...
define 254	binhex			private_option_254

That seems reasonable. Not assuming the length or type of the content of the option should be general purpose enough to meet the requirements of multiple sites. I assume that option 249 will need to retain its rfc3442 format for existing users?

Exactly. I would use the name "site_specific" instead of "private_option" because that is a phrase used in the RFCs and it also indicates to whom the option is private. I should be able to find the time to create an alternative draft PR in a day or two.

I've been mulling this over for some time. I think I would like to merge both changes. Obviously they conflict, so you'll need to make some adjustments.

I think we need to add to the private use comment that the options we define such as this:
These options are designed to be configured by the end user if needed and any configuration here may change in the future.
A kind of disclaimer if you will. I'll leave the exact wording up to you.

I also think it needs be in this order

1. Commentary
2. Configured options such as 245 and 249
3. The options without any specific configuration - we need to treat it as binary data and expose it in hex - binhex.

@lparkes does this make sense?

That all makes sense to me. I'll get on with a revised PR.