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

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

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

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

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.

So, what's the problem if a client includes addresses. The server can
try to give the client those addresses (if on link and its policy
allows) or the server is perfectly free to ignore them.

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

The client can only use what comes back in the REPLY, so how can what
the client sent in matter all that much?

We've had extremely good interoperability with client implementations to
date.

- 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: Damien Neil <[email-masked]>
Date: Fri, 3 Nov 2006 20:22:51 -0800

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

> but RFC 3315 is clear about what a server does in that case -- send

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?

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

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.

                          - Damien