RE: [dhcwg] Multiple IP addresses for DHCPv6 clients

["Achint Setia" <[e-mail]>]

Thanks Bernie and Ted!

Regarding the scenario where a client may request multiple IP addresses
even I am not very clear whether this is required indeed, so I thought
of putting that as a question for the workgroup. 

The RFC is not very clear when it states that there can be multiple
IA_Addr options in the same IA_NA.

As you mentioned, each binding(or IAID) should be associated with (or
request for)ONLY ONE address unless the server decides to include
multiple addresses depending on some policy.

Thanks for the quick response.
Achint.

-----Original Message-----
From: Bernie Volz (volz) [mailto:[e-mail]] 
Sent: Thursday, May 05, 2005 9:24 PM
To: Achint Setia; [e-mail]
Subject: RE: [dhcwg] Multiple IP addresses for DHCPv6 clients

Hi:
 
Comments inline.

- Bernie

________________________________

	From: [e-mail] [mailto:[e-mail]] On
Behalf Of Achint Setia
	Sent: Thursday, May 05, 2005 10:44 AM
	To: [e-mail]
	Subject: [dhcwg] Multiple IP addresses for DHCPv6 clients
	
	

	Hi,

	 

	The DHCPv6 RFC 3315 mentions that the client can send multiple
IAs in a packet. I have the following queries regarding the same:-

	 

	1.	If the client wants to request multiple IP addresses
from the server, should it send as many IA_Addr in a single IA_NA (i.e
under the same IAID) in the SOLICIT message or send multiple IA_NAs each
with a single IA Address field. I am asking this because the server
identifies a client binding by the triplet <DUID,  IA_Type, IAID> which
means in case of the first option, there have to be multiple addresses
in the same binding. 


BV>
Do not send multiple IAADDRs unless you want to explicitly request
addresses. There is no reason to send *ANY* IAADDR options in a Solicit
unless you want to request a specific address.

If you want multiple addresses, you MUST send multiple IA_NAs.

However, can you give me an example of why you would ever need to do
this?

	2.	Suppose after getting an address, the client wants to
get another address. Should it send another SOLICIT with a new IAID or
can it use the previous IAID to get the new address (assuming multiple
addresses per binding) 

BV>
You could simply send a REQUEST with a new IA. But, as a request is
directed to a single server, this presumes that the server is the
correct one. So, a SOLICIT may be the better approach.

Again, under what conditions would your client need to do this? Do you
have an example?

Note that if a client's previous address needs to be renewed, the RENEW
may either give the client the same address (with new lifetimes) or
could give the client NEW addresses.

	3.	The RFC says in section 18.1.3 (Creation and
Transmission of Renew Messages) "The server may also add new addresses
to the IA" 

	What are the possible scenarios in which the server can itself
chose to send multiple IP addresses to the client without going through
the normal 4 way 

	Handshake. Can we use this as a solution to the issue (2) I
mentioned?

BV>
I just mentioned a case in answer to section 2. A more concrete example
is: Client obtains address with lifetimes. When it renews, the server's
configuration has changed and a second prefix is available. When the
server processes the Renew, it will likely send BOTH address - the
original the client had (perhaps even with 0 lifetimes to tell the
client do remove that address) AND the new one. This can also happen if
the server has policy that, for example, doesn't allow the old address
to be renewed. In this case, the client would get a new address (and
perhaps also be sent the old).

When processing a REPLY to a REQUEST or RENEW/REBIND, the client
generally would do the following processing: For all addresses received,
either add the address to the client's configuration (if new and after
doing DAD) or update the lifetimes if it exists. If an address that the
client had is NOT in the REPLY, the old information for that address
should be retained (it probably means that the server is unwilling to
renew that addresss and decided not to include it in the REPLY).
	 

	 

	I'll appreciate your help in this regard.

	 

	Thanks,

	Achint Setia,

	Microsoft.

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