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

>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:Damien.Neil@nominum.com] 
Sent: Friday, November 03, 2006 5:37 PM
To: shane_kerr@isc.org
Cc: dhcwg@ietf.org
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
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg