RE: [dhcwg] 3315 clarifications

>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. 

That's at least my opinion on this issue. There may also be benefits to
allowing it - such as the ability to do delayed authentication (since
the 4-way handshake is available).

If I recall correctly, it originally came up during the M&O bit
discussion. If M had been defined as always do a
Solicit/Advertise/Request/Reply sequence, then a stateless client would
need to send a Solicit but would not include an IA (since it has no
support for this).

I also see no strong reason to disallow this.

- Bernie

-----Original Message-----
From: Ralph Droms (rdroms) 
Sent: Sunday, March 18, 2007 12:29 PM
To: shane_kerr@isc.org; Bud Millwood
Cc: dhcwg@ietf.org
Subject: Re: [dhcwg] 3315 clarifications

On 3/12/07 1:15 PM, "Shane Kerr" <Shane_Kerr@isc.org> 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
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg