Subject: RE: why seperate Ia is needed for sending new Requests?

From: "Bernie Volz (EUD)" <[email-masked]>
Date: Wed, 14 Mar 2001 14:29:24 -0600

The problem with is approach is that is requires the client to know how many addresses it wants. We don't want clients to have to know this. All they should do is request addresses - how many are returned is a server policy issue.

- Bernie

-----Original Message-----
From: Vijay Bhaskar A K [mailto:[email-masked]]
Sent: Wednesday, March 14, 2001 2:51 PM
To: DHCPv6 discussion list
Cc: [email-masked]; DHCPv6 discussion list
Subject: why seperate Ia is needed for sending new Requests?

Hi Jim and Ralph,

I have issues to discuss in telecon.
Why seperate IA is needed for sending new requests.
It can be send in the same IA itself.
 This can be done very will the single IA. 
sume the IA has already 2 addresses. Now, the client wants another
3 addresses. For requesting another 3 addresses, send the same IA
option with following. 
1. make num-addrs field as 5.
2. Include already existing 2 addresses in the IA option with filled
prefix length, IPv6 address and preferred lifetime and valid life time
values.
For the remaining 3 address newly asked, fill the prefix length,
IPv6 address, pref-life time, valid-life time with zero and make the
corresponding VB> addr status to ADDR_REQUEST indicating, the client is
asking the address.

This has some advantages also.
1. The DUID is need not to be generated for each and every request.
2. The server can maintain the list of IP-address it is managing for
a particular interface of a node. This will minimize the number of
records maintained.
3. If a client has sent 100 different requests, then it will have 100
IAs. Thus the server has to sent unicast Reconfigure-init message to the
same client 100 times, since the server no way identify the different
IAs belong to same client.

Regards,
Vijay

-- 
____Vijay_Bhaskar_A_K____
______Inet_Services______
________HP_ISO___________
____Ph:_2251554_1424_____
___Pager:_9624_371137____

---

From: Vijay Bhaskar A K <[email-masked]>
Date: Thu, 15 Mar 2001 17:31:32 +0530

so, the client won't ask that it wants "n" number of address. It will
just send a blank request. The server will allocate the number of
addresses according to its policy. In case, if the client needs some 10
addresses. If the server's policy is to allocate one IP-address per
request, then, the client has to send 10 requests instead of asking a
request of 10 IP-address. Isn't it? 
Is there any specific reason for bringing the control to the number of
addresses allocated to the server from the client. Actually, the client
has to ask for this much number of address and the server has to
allocate it, if it is able to do so. I this is the correct approach.

-Vijay
> "Bernie Volz (EUD)" wrote:
> 
> The problem with is approach is that is requires the client to know
> how many addresses it wants. We don't want clients to have to know
> this. All they should do is request addresses - how many are returned
> is a server policy issue.
> 
> - Bernie
>