On 10/10/14 16:42, Ted Lemon wrote: > On Oct 10, 2014, at 4:36 AM, Ole Troan <[email protected]> wrote: >> hmm. that's actually an interesting point. does it harm to allow >> this to be a hint to the server? if that how DHCP servers generally >> work? > > The problem is that the client might supply a wrong hint. I am not > aware of any DHCP servers that actually support this kind of hinting, > but it is allowed in the spec. I argued against it, but lost. :} Dibbler is able to take hints and use them if it's allowed by the server configuration. But it's working only for some options. Anyway, that's a feature that was codified in RFC3315, so new options are bound to it.
Here's proposed update. I tried to avoid any normative language here. The only exception is to be very explicit that this is a hint only and server may send something completely different. It's similar to the prefix length hints in PD. Some implementors didn't get that right in PD and there are all sorts of odd behaviours observed out there. OLD: A server MAY send more than one OPTION_S46_RULE option in a container, if it is configured to do so. This option has no meaning when sent from client to server. However, servers may take options sent by clients as a hint for what values to return, so clients MUST NOT send this option to servers. NEW: This option follows behavior described in Sections 17.1.1 and 18.1.1 of RFC3315. Clients can insert those options with specific values as hints for the server. Depending on the server configuration and policy, it may accept or ignore the hints. Client MUST be able to process received values that are different than the hints it sent. Tomek _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
