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

From: "Bernie Volz \(volz\)" <[email-masked]>
Date: Fri, 3 Nov 2006 17:44:54 -0500

Many clients do send an unspecified address (:: or 0::0 if you like) in
the IAADDR. I've tried to suggest that those that developed those
clients do not that at least by default, but there is one use case where
it can be useful.

Our server (Cisco Network Registrar 6.2 which has supported DHCPv6 for
almost a year now) ignores these -- expect to pick up client hints about
the lifetimes desired (and the prefix length desired if it is an
IAPREFIX). Of course, we only use those hints if the client is allowed
to suggest them.

- Bernie

-----Original Message-----
From: Damien Neil [mailto:[email-masked]] 
Sent: Friday, November 03, 2006 5:37 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [dhcwg] [DHCPv6] Address options in Request messages

On Nov 3, 2006, at 2:17 PM, Shane Kerr wrote:
> Good timing. We've just been doing some interop testing this week,  
> and noticed
> 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?

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

Sounds like a bug to me.  I can't see any possible reason for doing  
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.)

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.

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

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

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

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

---

From: "Bernie Volz \(volz\)" <[email-masked]>
Date: Sat, 4 Nov 2006 10:21:57 -0500

See inline.

- Bernie 

-----Original Message-----
From: Damien Neil [mailto:[email-masked]] 
Sent: Friday, November 03, 2006 11:23 PM
To: Bernie Volz (volz)
Cc: [email-masked]; [email-masked]
Subject: Re: [dhcwg] [DHCPv6] Address options in Request messages

On Nov 3, 2006, at 2:52 PM, Bernie Volz ((volz)) wrote:
> While I generally agree with you, I think there are valid cases  
> where a
> client can suggest addresses and if they're not in use, what's the  
> harm
> in giving the client what it "wanted". (DHCPv4 clients do that all the
> time -- they often try to get the same address that they last had.)

I'm specifically talking about Request messages, which are (to my  
understanding) only sent as the third step of a Solicit-Advertise- 
Request-Reply sequence.  In this case, the client has had an  
opportunity to suggest addresses in its initial Solicit message, and  
the server has already indicated in the Advertise response whether it  
intends to follow those suggestions.

My gut "feel" is that I dislike the potential for the client to  
ignore the results of the Advertise and proceed with a Request for  
different addresses.  (Although, as I said earlier, I haven't come up  
with a compelling technical reason to prohibit this behavior.)

BV> And why would you want to bother having to explicitly check for that
in the server? And, don't forget that Requests aren't necessarily always
preceeded by a Solicit/Advertise. For example in 18.1.8:

   When the client receives a Reply message in response to a Renew or
   Rebind message, the client examines each IA independently.  For each
   IA in the original Renew or Rebind message, the client:

   -  sends a Request message if the IA contained a Status Code option
      with the NoBinding status (and does not send any additional
      Renew/Rebind messages)

> The con is that the client's addresses might not be on that same link,
> but RFC 3315 is clear about what a server does in that case -- send
> NOTONLINK status.

I'm not certain why a server should do this, actually.  (Aside, of  
course, from the RFC requiring it.)  If the IAADDRs contained in an  
IA in a Request message are merely suggestions, why not simply ignore  
those suggestions when they are inappropriate for the link?

BV> There is always the possibility that the client has moved between
the Solicit/Request (perhaps the client didn't detect the link state
change). So, in that case, we'd ideally want the client to restart the
complete sequence in case there was a "better" server (higher
preference, etc.) server available. Hence, the NOTONLINK status gives
the client that information. I do agree it is a marginal case.

> I don't agree that this needs to be specified one way or the other in
> the RFC.

The problem is that the RFC is currently entirely silent on the  
question of what IADDRs in an IA in a Request message are used for,  
other than the requirement to send a NotOnLink status if one doesn't  
match the client's link.  This leaves both server and client  
implementors vulnerable to the possibility of conflicting  
interpretations.

I can argue, I think, that it is conforming behavior for a server to  
allocate no bindings to a client if that client fails to include any  
IAADDR options in its IAs in a Request message.  I can also argue  
that a server must ignore IAADDR options in Requests, except for the  
purposes of returning a NotOnLink status when required.  These  
positions are, of course, not compatible.  I'd much prefer if RFC  
3315 clarified this point.

BV> Well, I think if you did the first you'd likely find
interoperatability issues (though I don't recall if there is a client
I've run across that would do this). And, I can't see why you'd do that
(again, see 18.1.8). You are certainly free to do the later -- that
actually is a server POLICY issue IMHO.

BV> My personal opinion is that what the server returns in an Advertise
is just an indication of what the server will give the client -- not a
guarantee. What comes back in the Reply is what matters and what the
client must use. Hence, what the client sends in the Request may be what
it sent in the Solicit or what it got from the server in the Advertise
(it could also be something completely different but I can't think of a
good reason a client would ever do that). In any case, I can't see how
the server much cares.

BV> An RFC 3315-bis will likely be discussed at the San Diego IETF to
advance DHCPv6 along the standards track and if we start work on it, you
could certainly supply text for consideration but personally I think it
is far better to say less and not over specify things. Given the
excellent interoperability track record for completely independent
client and server (and relay) implementations, I also don't see that
what is there has caused any grief.

                          - Damien