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

From: "Thirumalesh Bhat" <[email-masked]>
Date: Thu, 15 Mar 2001 07:31:31 -0800

It is entirely possible for a client to ask for more "normal" addresses.
The reason being in IPv4, addresses were a bottle neck and in IPv6 it
wont be. A server that does web hosting may need thousands of IP
addresses and it may not be possible to know the requirement ahead of
time in all cases. It will contact the DHCP Server to request more IP
addresses in this case or use stateless config to generate the IPs it
needs. A server hosting different services may want to use different
"normal" addresses for each service.
 
It is also possible for the client to use different IP addresses for
different browser sessions. In this case, the client may request
temporary addresses. 
 
In any case, it is likely that the DHCP client will have to generate IP
addresses on the fly using stateless/stateful configs. In other words,
the dhcpv6 spec shouldnt exclude this scenario as it is difficult to
predict the future.
 
thx

-----Original Message-----
From: Bernie Volz (EUD) [mailto:[email-masked]]
Sent: Thursday, March 15, 2001 5:17 AM
To: DHCPv6 discussion list
Subject: RE: why seperate Ia is needed for sending new Requests?

Vijay: 

Any design has trade offs. If a client were to ask for 5 addresses, what
does that mean? Does it mean 5 addresses on a single prefix or on 5
different prefixes? Networks might have multiple prefixes active at one
time, so asking for "n" addresses isn't all you'd have to do - the
client would have to say give me "m" on prefix a, "o" on prefix b, and
so on.

Normally clients will only ask for their 'normal' addressess. If they
later need additional addresses (such as temporary ones), they can do
additional requests.

Do you really expect a client to want to ask for many sets of addresses?
If one excludes the temporary address issue, do you see a client ever
asking for more 'normal' addresses? Yes, we have the mechanism by using
the IA option, but is that likely to be the normal behavior?

- Bernie Volz 

-----Original Message----- 
From: Vijay Bhaskar A K [ mailto:[email-masked]] 
Sent: Thursday, March 15, 2001 7:02 AM 
To: DHCPv6 discussion list 
Subject: Re: why seperate Ia is needed for sending new Requests? 

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

-- 
____Vijay_Bhaskar_A_K____ 
______Inet_Services______ 
________HP_ISO___________ 
____Ph:_2251554_1424_____ 
___Pager:_9624_371137____

---

From: Ted Lemon <[email-masked]>
Date: Thu, 15 Mar 2001 08:39:32 -0800

> the dhcpv6 spec shouldnt exclude this scenario as it is difficult to

The current spec, as far as I can tell (and I am also quite interested
in this), supports this scenario.  I'm not convinced it's likely, but
it is supported.  You do it with multiple IAs.  We were originally
going to do it the way you're proposing, and it turned out that that
was actually a _lot_ more complicated, because we had no key<->address
set relationship.

I say "address set" rather than "address" because even a very simple
individual client that needs only one way of being contacted may still
be assigned more than one address by the server.  This is because the
address the client has been using may be deprecated during a
renumbering event, for example.  In this case, the client will be
given its old address, which is deprecated, along with a new address,
which is be preferred for starting new network connections.

Because we can't depend on there being a single address for a given
client even under the most simple circumstances, we can't use the
client's assigned address as an identifier.  That's why we're now
solving the problem with one logical identifier per address set rather
than one logical identifier per client.  The identity association is
the tuple of (logical identifier, address set, ...), and the server
can use the logical identifier as a key to look up this identity
association.  We will still have a unique per-client identifier.  The
IA identifier will be a single logical identifier per IA that is
constructed in a well-defined way using the per-client identifier and
a per-IA index.

Do you think that this isn't going to work at all, or did we just not
explain ourselves well enough, or is it just not the solution that
you'd prefer?

			       _MelloN_