Re: [dhcwg] 3315 clarifications

[Ralph Droms <[e-mail]>]

On 3/12/07 1:15 PM, "Shane Kerr" <[e-mail]> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Bud Millwood wrote:
>> On Sunday 11 March 2007 16:57, Bernie Volz (volz) wrote:
>>> Bud:
>>> 
>>> 1. In our server chose to allow no IAs for SOLICIT/REQUEST -- there was
>>> some discussion a while back about this topic (RFC 3315 vs RFC 3736 and
>>> the meaning of the RA M & O bits).
> 
> As a data point, the ISC DHCPv6 server (not yet release) happily replies to
> Solicit/Request messages without addresses.
> 
>> Hmm. If you allow no IAs for solicit/request, then it's kinda like stateless,
>> right?
> 
> Kinda, but not necessarily. The server might provide no information at all in
> the case of Solicit/Request without IAs, and this is perfectly okay. Not so
> good
> for Information-Request...

What do you mean by "no information"?  No response at all or an
Advertise/Reply (resp.) with no options?

> Sending Solicit/Request without IAs is probably something clients should not
> do,
> and something server should probably handle gracefully. :)

If I'm understanding Bernie and Shane correctly, a Solicit/Request with no
IAs might not be particularly useful - or perhaps redundant with
Information-Request - but there's no critical reason to include an outright
ban on Solicit/Request with no IAs.

>>> 2. I would say NO to IAs in Replys for Information-Request.
>>> We presently
>>> have no address specific options (when working on early drafts of what
>>> is now RFC 4704, I had proposed allowing the FQDN option in IAs and
>>> IAADDR options to restrict the applicability but that was deemed more
>>> complicated than it was worth).
>> 
>> Wow... My reading of 3315 gave me the impression that most any DHCPv6 option
>> could appear anywhere in the options heirarchy, and the client should
>> understand that a delivered option was only valid in the context in which it
>> was delivered. In fact, my server presently allows you to set options in
>> IAADDRS, and I was seriously wondering if DHCPv6 clients would really
>> understand that a DNS server option (for example), delivered in an IAADDR,
>> was really only to be used for that address. It seemed to be asking *a lot*
>> from a DHCP client.

What does it mean for a DNS server option only with a given address?

> Well, there is the handy Appendix A: Appearance of Options in Message Types,
> which says which are allowed or not. (Although others on this list have
> mentioned that this appendix is not 100% correct...)
> 
>>> And, the general rule is that IA_*
>>> options in server replies are restricted to those that were in the
>>> client's message (except for the Reconfigure message -- which isn't a
>>> server reply anyway).
>> 
>> It seems that I should view my server from a much more client-driven
>> approach. 
>> An administrative policy defining a set of options should first give those
>> options that are asked for in IAs, then those asked for in the top-level
>> options, then, anything remaining in the policy goes in the top-level
>> options. Does this seem like a coherent strategy?
> 
> I'm not 100% sure what you mean. But we work basically how I think you are
> suggesting. :)
> 
> There are options not associated with any specific IA, which are added to the
> Reply (or Advertise) packets from the server. Each IA added as an option to
> the
> Reply/Advertise has its own options. (We don't currently put options in
> IAADDR,
> but I suppose that could happen eventually.)
> 
> These are all determined by both the ORO from the client as well as any
> configuration on the server side and some requirements from the RFCs.
> 
> - --
> Shane
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> 
> iD8DBQFF9YqtMsfZxBO4kbQRAs99AKCdAPqqet4gGZrXhns5USz59i1fUwCfXJFq
> VAXoLSqxchuFzQPpa0OeBDI=
> =SJAZ
> -----END PGP SIGNATURE-----
> 
> _______________________________________________
> dhcwg mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/dhcwg

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