Subject: [dhcwg] [DHCPv6] Address options in Request messages

From: Damien Neil <[email-masked]>
Date: Thu, 2 Nov 2006 16:23:00 -0800

RFC 3315 does not describe any client or server behavior related to  
IA Address options contained within IA options in Request messages.   
Based on the lack of mention, I read this as indicating that clients  
should not include IA Address options in Request messages, which  
seems slightly surprising.  Is this correct?

If a client does include an IA Address option in a Request, is the  
server expected to ignore it?  Consider the following scenario:

- Client sends a Solicit containing one IA_NA.
- Server responds with an Advertise containing two addresses, X and  
Y, for the single IA_NA.
- Client sends a Request containing one IA_NA, which contains one IA  
Address option for the address X.

Should the server respond with a Reply containing one or two  
addresses?  (I would expect one, but my reading of RFC 3315 says two.)

                  - Damien

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

---

From: Shane Kerr <[email-masked]>
Date: Fri, 03 Nov 2006 23:17:32 +0100

Damien Neil wrote:
> RFC 3315 does not describe any client or server behavior related to IA
> Address options contained within IA options in Request messages.  Based
> on the lack of mention, I read this as indicating that clients should
> not include IA Address options in Request messages, which seems slightly
> surprising.  Is this correct?
> 
> - Server responds with an Advertise containing two addresses, X and Y,
> for the single IA_NA.
> Should the server respond with a Reply containing one or two addresses? 
> (I would expect one, but my reading of RFC 3315 says two.)

Good timing. We've just been doing some interop testing this week, and noticed
issues with IA_NA and IAADDR from clients.

To answer your question, I also would expect one. In general I consider the main
difference to be whether the client sends no IAADDR or 1 or more. If no IAADDR
is present, then the server picks, if any IAADDR are present, then this is the
set the client wants.

Assuming this logic, there are a few cases:

- - If the client sends an IAADDR in an IA_NA in a Solicit, RFC 3315 is pretty
clear. These are advice to the server. (We did see a client that sends ::, which
seems like a bug to me. Can anyone think of a reason to do this?)

- - If the client sends an IAADDR in an IA_NA in a Request, RFC 3315 is not so
clear. As you noticed 18.2.1 says the server should send NotOnLink if the
address is not appropriate for the link. However, I can think of cases where the
address is appropriate for the link but not the one the server wants to issue.
In these cases, we return NotOnLink. I'm not certain this is the correct
behavior though. (We saw a different client that sends ::, which also seems like
a bug to me. We are currently handle this as a special-case, but will try to get
the client code fixed.)

- - Rapid Commit makes the picture more unclear. If the client sends an IAADDR in
an IA_NA in a Solicit with Rapid Commit, what should the server do? We have
decided to treat it as advice to the server... after all, the client before a
Solicit doesn't actually know too much about the network. But this means that
Solicit+Rapid Commit is not quite the same as a Request.

- --
Shane

---

From: Damien Neil <[email-masked]>
Date: Fri, 3 Nov 2006 14:37:16 -0800

> issues with IA_NA and IAADDR from clients.

The limited selection of clients I've checked all seem to be  
including an IAADDR in IA_NAs in Requests.  Have you seen any which  
don't?

> seems like a bug to me. Can anyone think of a reason to do this?)

Sounds like a bug to me.  I can't see any possible reason for doing  
this.

> a bug to me. We are currently handle this as a special-case, but  

My opinion is that a client should never send an IAADDR in an IA_NA/ 
IA_TA in a request that wasn't sent to that client by the server in a  
prior Advertise.  RFC 3315 is ambiguous enough on the handling of  
IAADDRs in Requests, however, that I can see a case for alternate  
behavior.

I really wish this was more clearly specified, since trying to allow  
for every possible interpretation of the RFC is painful.

> Solicit+Rapid Commit is not quite the same as a Request.

I would consider it appropriate for a server to ignore Rapid Commit  
when responding to a Solicit with an IAADDR that it will not grant to  
the client.  That is, if the server agrees with the client's request  
for that address, it goes ahead and sends a Reply, but falls back to  
an Advertise otherwise.

                     - Damien

---

From: "David W. Hankins" <[email-masked]>
Date: Sun, 5 Nov 2006 16:26:06 +0000

> including an IAADDR in IA_NAs in Requests.  Have you seen any which  

A recent beta release of Windows Vista, under the condition where the
DHCP Server gave an ADVERTISE with no ia_addr and a status code
indicating no addresses were available, will REQUEST with the same
IA_NA minus the IA_ADDR option.

No one present at the time had any idea what the client hoped to
acheive.  If someone responsible for this implementations knows
what it hoped to acheive, I would like to be educated.

But unless I'm mistaken 3315 doesn't seem to discourage this
behaviour?

> Sounds like a bug to me.  I can't see any possible reason for doing  

We've seen two clients that do this (one seems to do it because of
the other).  I also feel it is a bug, but I can see a possible reason
for doing this:  To supply valid/preferred lifetimes as hints to the
server for a desired set of values.  These are in the ia_addr at
the tail end, so you have to include the address field.

I think this is not supported by rfc3315 (every place I looked
tells the client to fill these time fields with zeroes, as the
'server will ignore them anyway'...note that some clients fill
them with the values provided by the server).

To discourage this behaviour, we might create a separate option
for clients to deliver a desired-lease-time-hint if people think
it's helpful for clients to request their lease times.

It should also be noted that the IBM dhcpv6 server will emit, we are
told, a log warning if it encounters clients that do not supply a
zeroed ia_addr in their solicit.  This is the reason we were given by
one of the client implementors for including the :: value.

I don't think I can give you one of the client's names.  But the
other that does this is the Dibbler client.  Which also was found
to supply an elapsed time option whose length was 4 octets (oops?).

> IAADDRs in Requests, however, that I can see a case for alternate  

It needs to be clear that an IA_ADDR in a SOLICIT is a hint.  An
IA_ADDR in a REQUEST is not a hint (and so it's pretty odd to expect
anything to work if you fill it with a value the server did not
provide).

> for every possible interpretation of the RFC is painful.

I think most of us learned the perils of this from rfc2131.

> for that address, it goes ahead and sends a Reply, but falls back to  

So, try building a reply packet, and if there is any error, scrap it
and build an advertise.

It is ironic that rapid commit, designed I understand to reduce
overhead all around, would double the amount of work a dhcp server
would have to undertake.

But this is a pretty small corner case, so perhaps this is
completely reasonable.

The question is how much weight we're going to put behind 3315's
indication that the server is expected to 'treat the solicit as a
request' (those are 3315's words).

Holding fast to that indication, I think what you suggest is the
best way to do so.

Either way I think someone needs to write a 'rapid commit how-to'
draft, and give examples of how clients and servers interact.  The
3315 document is needfully written from a 4-way exchange POV.  v4
rapid commit is less problematic in this sense as well, it was a
separate document.

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

---

From: "David W. Hankins" <[email-masked]>
Date: Sun, 5 Nov 2006 19:26:20 +0000

> them with the values provided by the server).

My mistake, the OPTION_IAADDR does document these as 'server hints'.
I'm confusing this with t1/t2 values that are, in a few places,
documented as 'filled with zero as the server will ignore them'.

But :: is clearly not documented as a valid value, so we're still
at something of an impasse here.

One more thought:  RFC3315 is either not strenuous enough in
suggesting against requests for infinite lifetimes, or not clear
enough.  One DHCPv6 client asks for infinite lifetimes by default.

Additionally, I'm not sure which ones without reconsulting my packet
dumps, but multiple clients seem to copy in t1/t2 pref/valid with
values they got in the server's reply...when they transmit their
renew.

In DHCPv4, servers would elect to play games with lease lifetimes
in certain situations...lower values usually.  DHCPv4 failover
talks about giving out a low "MCLT" lease time so that it
can negotiate with its peer for the preferred lifetime on the
next renewal.  I've experimented with reducing lease time when
DDNS updates have not yet concluded successfully - as a means to
use the client to restart transmissions, or to involve the client
in name negotiations.

I'm not convinced there's no similar use cases in DHCPv6.  It
doesn't really matter however since the main client that does
this is Windows Vista.

So servers are going to have to regard values in client packets
as more or less completely and totally irrational hints and
follow their own compass.

---

From: "David W. Hankins" <[email-masked]>
Date: Mon, 6 Nov 2006 18:09:34 +0000

On Mon, Nov 06, 2006 at 12:02:44AM -0800, Damien Neil wrote:
> On Nov 5, 2006, at 8:26 AM, David W. Hankins wrote:
> I (regrettably) do not believe that this view is supported by 3315.   
> (If you can find language in there to prove me wrong, I'll be  
> delighted, however!)

Right, but I think that's the direction we should move in.  We
should, through standards action, make it become clear.

---

From: Damien Neil <[email-masked]>
Date: Mon, 6 Nov 2006 11:01:29 -0800

> should, through standards action, make it become clear.

I think we are in violent agreement on this point.

                 - Damien

---

From: Damien Neil <[email-masked]>
Date: Mon, 6 Nov 2006 00:02:44 -0800

- Damien