Subject: [dhcwg] 3315 clarifications

From: Bud Millwood <[email-masked]>
Date: Sat, 10 Mar 2007 15:00:16 +0100

I have a couple of questions about 3315:

1. Is a SOLICIT or REQUEST message valid if it contains no IAs? The text 
doesn't seem to explicitly say such messages are invalid (indeed, seems to 
hint otherwise).

2. An Information-Request is invalid if the client includes IAs, but what 
about the server? If the server knows the client has bindings, and each bound  
IAADDRESS might have address-specific options, should the server include 
those in response to Information-Request? IOW, is it illegal for the server 
to include IAs in response to Information-Request?

- Bud

Bud Millwood
Weird Solutions, Inc.
http://www.weird-solutions.com
tel: +46 8 758 3700
fax: +46 8 758 3687

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

---

From: "Bernie Volz \(volz\)" <[email-masked]>
Date: Sun, 11 Mar 2007 11:57:47 -0400

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

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

- Bernie

-----Original Message-----
From: Bud Millwood [mailto:[email-masked]] 
Sent: Saturday, March 10, 2007 9:00 AM
To: [email-masked]
Subject: [dhcwg] 3315 clarifications

doesn't seem to explicitly say such messages are invalid (indeed, seems
to 
hint otherwise).

2. An Information-Request is invalid if the client includes IAs, but
what 
about the server? If the server knows the client has bindings, and each
bound  
IAADDRESS might have address-specific options, should the server include

those in response to Information-Request? IOW, is it illegal for the
server 
to include IAs in response to Information-Request?

- Bud

Bud Millwood
Weird Solutions, Inc.

---

From: Bud Millwood <[email-masked]>
Date: Sun, 11 Mar 2007 23:38:21 +0100

> the meaning of the RA M & O bits).

Hmm. If you allow no IAs for solicit/request, then it's kinda like stateless, 
right?

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

> And, the general rule is that IA_*

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?

- Bud

Bud Millwood
Weird Solutions, Inc.

---

From: "David W. Hankins" <[email-masked]>
Date: Sun, 11 Mar 2007 17:18:56 -0700

> Hmm. If you allow no IAs for solicit/request, then it's kinda like stateless, 

I vaguely recall this discussion but cannot remember the details.

I would really like to see this captured somewhere permanent, because
on different weeks I think this is either a good or bad idea, and
can't remember why I thought differently last week.

> was delivered. In fact, my server presently allows you to set options in 

There is an easily overlooked "third paragraph" (sort of like a
second gunman) in RFC3315 section 22.

   Unless otherwise noted, each option may appear only in the options
   area of a DHCP message and may appear only once.  If an option does
   appear multiple times, each instance is considered separate and the
   data areas of the options MUST NOT be concatenated or otherwise
   combined.

This is in a section of RFC3315 which commences to describe those
options and their contents that RFC3315 needs to (server/client
DUID, etc, etc).

One problem is that this isn't normative language (except that options
MUST NOT be concatenated), and if options "may" appear only one way,
then it stands to reason that they "might not".

Another problem is that the paragraph that preceeds it does not give
the reader a strong sense that subsequent work is subject to the
same "default" as has just been described.

Further compounding this, is that some subsequent work (RFC3646 for
example) does not explicitly cite this default, explicitly state
where the option is appropriate for use, or etc.

So it's a problem.

I think therefore realistically, as a server implementer you should
put options in the global space unless the option's RFC explicitly
allows otherwise (which means you are going to need a mechanism for
non-global options eventually, but not today).  "YAGNI".

As a client implementer, it would be good to be ready to inter-operate
on a DHCPv6 level with servers that don't seek that wisdom, even if
the local host operating system isn't instrumented in such a way that
can be configured in such detail.

-- 
David W. Hankins	"If you don't do it right the first time,
Software Engineer		you'll just have to do it again."
Internet Systems Consortium, Inc.	-- Jack T. Hankins
_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: "Bernie Volz \(volz\)" <[email-masked]>
Date: Sun, 11 Mar 2007 21:46:40 -0400

I think you're asking a lot for clients to support address based
options, at least for the "data" options that we have defined so far.

For example, what does it mean to you give a client two addresses with
different dns server options? Both those addresses are for a single
interface. Is the dns server list to be concatentated when installed?
Does it mean that the client must first determine the source address it
would use (which is difficult if the destination address isn't yet
known) and then determine which dns server to contact? I'm not sure how
a client could be written to do this - let alone try to specify the
expected behavior.

There may be options in the future that make sense on an address or IA_*
basis, but for now I think that is a complexity that isn't warranted.
Having support in the protocol for it doesn't mean we have to make full
use of it.

Currently, it is complex enough for clients to deal with IPv4 and IPv6
support and multiple interfaces and the multiple different instances of
configuration data that they may receive with each of these
transactions.

And, in most cases I suspect that there is one IA_* and one IAADDR
involved anyway.

- Bernie

-----Original Message-----
From: Bud Millwood [mailto:[email-masked]] 
Sent: Sunday, March 11, 2007 6:38 PM
To: [email-masked]
Subject: Re: [dhcwg] 3315 clarifications

> the meaning of the RA M & O bits).

Hmm. If you allow no IAs for solicit/request, then it's kinda like
stateless, 
right?

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

> client's message (except for the Reconfigure message -- which isn't a

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

- Bud

Bud Millwood
Weird Solutions, Inc.

---

From: Shane Kerr <[email-masked]>
Date: Mon, 12 Mar 2007 18:15:25 +0100

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

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

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

> was really only to be used for that address. It seemed to be asking *a lot* 

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

> 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

---

From: Bud Millwood <[email-masked]>
Date: Mon, 12 Mar 2007 21:57:00 +0100

On Monday 12 March 2007 18:15, Shane Kerr wrote:

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

From what I understand, your approach differs from Bernie's suggestion 
(Bernie: correct me if I'm misunderstanding you). If Bernie was suggesting 
that a server should only enforce an option at the IA level if the IA 
requests it at that level using ORO, then I would be prone to take your 
approach over his. Your approach allows the admin to decide if a particular 
option is bound to a specific IA... period.

It makes the most sense to me that an admin will want to enforce that specific 
options are only for specific IAs, regardless of what ORO was found in the 
IA. (Not suggesting that you not process IA-ORO, only that you allow the 
admin to add more than requested)

Since a message may contain multiple IAs, it makes sense to enfore IA-specific 
options by placing them in the IA.

- Bud

Bud Millwood
Weird Solutions, Inc.

---

From: "Bernie Volz \(volz\)" <[email-masked]>
Date: Wed, 14 Mar 2007 07:54:18 -0400

Bud:

I hadn't specifically said anything about OROs and where they appeared
in a client message and don't believe I implied any either. I think they
can only to appear in the main client options and not in IAs or IAADDRs.

- Bernie

-----Original Message-----
From: Bud Millwood [mailto:[email-masked]] 
Sent: Monday, March 12, 2007 4:57 PM
To: [email-masked]
Subject: Re: [dhcwg] 3315 clarifications

>From what I understand, your approach differs from Bernie's suggestion 
(Bernie: correct me if I'm misunderstanding you). If Bernie was
suggesting 
that a server should only enforce an option at the IA level if the IA 
requests it at that level using ORO, then I would be prone to take your 
approach over his. Your approach allows the admin to decide if a
particular 
option is bound to a specific IA... period.

It makes the most sense to me that an admin will want to enforce that
specific 
options are only for specific IAs, regardless of what ORO was found in
the 
IA. (Not suggesting that you not process IA-ORO, only that you allow the

Since a message may contain multiple IAs, it makes sense to enfore
IA-specific 
options by placing them in the IA.

- Bud

Bud Millwood
Weird Solutions, Inc.

---

From: Ralph Droms <[email-masked]>
Date: Sun, 18 Mar 2007 12:28:49 -0400

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

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Bud Millwood wrote:

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

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

>> was really only to be used for that address. It seemed to be asking *a lot*

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

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

---

From: "Bernie Volz \(volz\)" <[email-masked]>
Date: Mon, 19 Mar 2007 04:24:59 -0400

>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: [email-masked]; Bud Millwood
Cc: [email-masked]
Subject: Re: [dhcwg] 3315 clarifications

stateless,
> the case of Solicit/Request without IAs, and this is perfectly okay.
Not so
> good

> Sending Solicit/Request without IAs is probably something clients
should not
> do,

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.

option
which it
IAADDR,

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

---

From: "David W. Hankins" <[email-masked]>
Date: Mon, 19 Mar 2007 10:23:36 +0100

On Mon, Mar 19, 2007 at 04:24:59AM -0400, Bernie Volz (volz) wrote:
> >Information-Request -

Up until this point I agree...

> but there's no critical reason to include an
> outright

And then suddenly I'm not sure I agree.  A non-specified behaviour
like this left up to the server implementor becomes an incompatibility
based on secret knowledge.

So it's either specify as required, or ban.

> the 4-way handshake is available).

I think this is compelling.

So if we're going to allow it, we have to require it (or else we
have that compatibility concern).

I lean towards requiring it, as I think the authentication gains
with a 4-packet 'info request' exchange are important.

-- 
ISC Training!  http://www.isc.org/training/  [email-masked]
Washington DC area, April 16-20 2007.  DNS & BIND, DDNS & DHCP.
-- 
David W. Hankins	"If you don't do it right the first time,
Software Engineer		you'll just have to do it again."
Internet Systems Consortium, Inc.	-- Jack T. Hankins
_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: Shane Kerr <[email-masked]>
Date: Mon, 19 Mar 2007 14:10:02 +0100

> Up until this point I agree...

Exactly.

> with a 4-packet 'info request' exchange are important.

Okay, this makes sense. If it could theoretically be useful, then lets mandate
it as required behavior. If we never use it, it is still non-harmful, IMHO.

- --
Shane