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

From: "Bernie Volz \(volz\)" <[email-masked]>
Date: Thu, 2 Nov 2006 21:45:17 -0500

My view is that the client can send in either what it sent in the
Solicit or what was sent back from the server.

So, it could send:
- Just the IA.
- The IA with both addresses.
- The IA with either addresses.
- (Technically, it could also send additional addresses.)

In all cases, I would expect it to get back two addresses if that is
what the server's configuration is set to do (because of the Solicit).

It may not get the same addresses it got in the Solicit (though in most
cases it likely would).

(If it sent additional addresses, it might or might not get them.)

- Bernie

-----Original Message-----
From: Damien Neil [mailto:[email-masked]] 
Sent: Thursday, November 02, 2006 7:23 PM
To: [email-masked]
Subject: [dhcwg] [DHCPv6] Address options in Request messages

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

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

---

From: Damien Neil <[email-masked]>
Date: Thu, 2 Nov 2006 20:49:35 -0800

> - (Technically, it could also send additional addresses.)

I recalled one item that I was forgetting earlier.  From section 18.2.1:

    If the server finds that the prefix on one or more IP addresses in
    any IA in the message from the client is not appropriate for the  
link
    to which the client is connected, the server MUST return the IA to
    the client with a Status Code option with the value NotOnLink.

This is, so far as I can tell, the only mention of addresses in a  
Request message in RFC 3315.  It does indicate that addresses may  
exist in the Request, and it implies that the server should consider  
them when deciding what addresses to allocate to the client.

> It may not get the same addresses it got in the Solicit (though in  

17.2.2 strongly indicates that the server should offer the same  
addresses in a Reply as were offered in a Solicit:

    If the Solicit message from the client included one or more IA
    options, the server MUST include IA options in the Advertise message
    containing any addresses that would be assigned to IAs contained in
    the Solicit message from the client.

Coming from a DHCPv4 perspective, it feels to me as if the client  
really should be including all desired addresses in Request messages,  
but I don't know if I have a sound technical reason to justify this  
opinion.

                     - Damien