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

From: Vijay Bhaskar A K <[email-masked]>
Date: Thu, 15 Mar 2001 01:21:27 +0530

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: "Bernie Volz (EUD)" <[email-masked]>
Date: Thu, 15 Mar 2001 07:17:04 -0600

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

---

From: "Thirumalesh Bhat" <[email-masked]>
Date: Thu, 15 Mar 2001 09:18:32 -0800

If there is a facility to get additional addresses (which is present in
the current draft) after the client boot in the spec, I think it is
good. It is my experience in multicast address allocation that an app on
the client may request an address anytime. There is even an RFC for the
client APIs to request an address.
(http://www.ietf.org/rfc/rfc2771.txt). In my opinion, address allocation
problem in IPv6 will be somewhat similar to multicast address allocation
in IPv4 mainly because of the presence of stateless address allocation
protocol and the abundance of the address pool.

thx

-----Original Message-----
From: Ted Lemon [mailto:[email-masked]] 
Sent: Thursday, March 15, 2001 8:40 AM
To: DHCPv6 discussion list
Subject: Re: why seperate Ia is needed for sending new Requests? 

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

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_

---

From: "Bernie Volz (EUD)" <[email-masked]>
Date: Thu, 15 Mar 2001 18:34:42 -0600

No, Ted you are correct.

I said you "might" configure your DHCPv6 server such. You certainly do not have to. The client can get more addresses by simply using multiple identify associations.

In the question at hand, the system wanted say 1000 addresses. In that case (ASSUMING THE DHCPv6 SERVER ONLY GAVE BACK 1 ADDRESS PER IDENTITY ASSOCIATION), the problem is you'd have 1000 identity associations for that system (client).

What I was suggesting is that in this case, you could make this more efficient by configuring the DHCPv6 server such that for that particular client, the server gave it "a lot of addresses" for each identity association. In my example, I said 50. Then the client only needs 20 identify associations for the 1000 addresses.

Again, you *COULD* if the server provided this capability. You are NOT required to.

- Bernie

-----Original Message-----
From: Ted Lemon [mailto:[email-masked]]
Sent: Thursday, March 15, 2001 7:13 PM
To: DHCPv6 discussion list
Subject: Re: why seperate Ia is needed for sending new Requests? 

> If you have a web hosting system, you might configure your DHCPv6
> server to give it LOTS of addresses (on one or more prefixes). That
> would reduce the number of requests that system would need to
> make. But, even if you don't, it can still get the addresses it wants
> (provided the server's policy allows it).

This is actually not at all what we talked about yesterday, if I
understood correctly what we talked about.   You don't need to
configure the DHCP server to give the client more addresses - you just
need to not configure it to refuse to accept multiple identity
associations from the same client.   And you need to configure the
*client* to ask for multiple identity associations.   Or did I
misunderstand yesterday's conversation?

			       _MelloN_

---

From: Ralph Droms <[email-masked]>
Date: Thu, 15 Mar 2001 19:56:52 -0500

If I remember correctly, we've considered the issue of virtual web servers 
in the past.  Based on the capabilities of the current version of HTTP for 
identifying virtual web servers behind a single IP address, we've discarded 
virtual web servers as a motivation for on-demand address assignment.

That's not to say there aren't other motivations for on-demand address 
assignment.  Perhaps temporary addresses are a good motivating example.  If 
we're going to add complexity to the protocol to support on-demand address 
assignment, we need to make sure we understand the specific motivations and 
requirements.

- Ralph

At 07:31 AM 3/15/2001 -0800, Thirumalesh Bhat wrote:
>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.

---

From: "Thirumalesh Bhat" <[email-masked]>
Date: Thu, 15 Mar 2001 21:51:46 -0800

I will try to enumerate several motivations for having the capability to
request "normal" addresses in the future. 

a) Reservations: 
	In Ipv6 there is no concept of reservations. However,
"reservations" or static IP addresses will be required in some
applications. In IPv4 itself, I have heard requests that there should be
APIs to request multiple static addresses from a dhcp server. This is
required in applications such as clustering where the same machine may
have multiple IP addresses . The IP addresses may be used for each node
in the cluter or for each service in the cluster. As an example, using
Microsoft cluster service, it is possible to host a DHCP Server on one
IP address and the WINS server on another IP address on the same
cluster. It is not mandatory that the admin should have all the IP
addresses at hand while configuring the cluster. The admin is free to
add a service to the cluster any time he wants. In a IPv6 network, I can
see the cluster service go to a dhcp server in the network to demand
more "normal" addresses.

b) A server hosting different network services. 
   Let us take an example of a server that is hosting telnet server,
tftp server and ftp server. In IPv4 world, the machine had one IP
address and all the services bound to that IP address. I dont see this
requirement in IPv6. It is entirely possible that each service will
choose a different IP address to bind to. It is also possible for the
administrator to add more network services after the initial boot of the
server and it is desirable to have a way to get multiple addresses in
the future.

c) Multiple IP addresses per interface: 
  Although it is possible to configure multiple IP addresses per
interface today, it is not used widely in a lot of applications. This
situation may change in a IPv6 world. A client may request 'n' addresses
for a particular interface.

d) The malloc ( Multicast Address Allocation ) group allows this feature
in IPv4 multicast. RFCs 2730 and 2771.
I see a lot of parallels with the IPv4 multicast address pool and IPv6
unicast address pool. ( in terms of the size/use of the address pool
with respect to the available applications. ) The feature to request IP
addresses at any time is being used by several multicast applications
that need multicast address today. I can see the same scenario repeating
in a IPv6 network.

In RFC 2730, section 3.8, this is addressed as follows.

3.8. Number of Addresses Requested

   This option specifies the minimum and desired number of addresses
   requested by the client. It is only used in DISCOVER and REQUEST
   messages and is only sent by the client.

   The minimum and desired number of addresses requested are unsigned 16
   bit integers in network byte order. The minimum MUST be less than or
   equal to the desired number. If a message is received where this is
   not the case, the MADCAP server MUST generate and process an Invalid
   Request error in the manner described in section 2.6.

   The client MAY obtain more than one address either by repeating the
   protocol for every address or by requesting several addresses at the
   same time via this option. When the client is requesting only one
   address, this option SHOULD NOT be included. A MADCAP server

Hanna, et al.               Standards Track                    [Page 34]

RFC 2730                         MADCAP                    December 1999

   receiving a DISCOVER or REQUEST packet including this option MUST
   include between the minimum and desired number of addresses in any
   OFFER or ACK response.

In RFC 2771, this is addressed in the following API.

3.1 Allocating multicast addresses:

   alloc_multicast_addr(in AddressFamily family,
                        in Scope scope,
                        in Integer minDesiredAddresses,
                        in Integer maxDesiredAddresses,
                        in Time minDesiredStartTime,
                        in Time maxDesiredStartTime,
                        in Time minDesiredLifetime,
                        in Time maxDesiredLifetime,
                        out Lease multicastAddressSetLease,
                        out Status status)

   This operation attempts to allocate a set of multicast addresses (the
   size of this set is in the range [minDesiredAddresses,
   maxDesiredAddresses]) within the given address family and scope, and
   within a given range of desired lifetimes.  ("minDesiredStartTime"
   and "maxDesiredStartTime" are used to specify "advance allocation";
   this is described in more detail below.)

   If the address allocation succeeds, the result is returned in
   "multicastAddressSetLease" (with "status" = OK).

   During the lifetime of this lease, the allocation service will make a
   "best-effort" attempt to not allocate any of these addresses to
   others.  (However, once the lease's lifetime has expired, any of its
   addresses can be allocated to others.)

   Multicast addresses are allocated for a limited lifetime.  An
   application may attempt to extend this lifetime, but this operation
   may fail.  Therefore, an application must be prepared for the
   possibility it will not be able to use the same addresses for as long
   as it desires.  In particular, the application must be prepared to
   either quit early (because its original multicast address assignments
   have expired), or, alternatively, to occasionally 'renumber' its
   multicast addresses (in some application or higher-level-protocol
   dependent way), by making a new allocation.  However, if an
   application needs to consider 'renumbering', it will always know this
   in advance, at the time it acquired its current address(es) - by
   checking the lifetime in the returned lease.  An application will
   never need to be notified asynchronously of the need to 'renumber'.

 e) The only reason I see for not having a feature in the client not to
request multiple IPs is the added complexity to the DHCPv6 draft. I do
think that this is small price to pay compared to the inconveniences we
will face because of this in the future.

thx

-----Original Message-----
From: Ralph Droms [mailto:[email-masked]]
Sent: Thursday, March 15, 2001 4:57 PM
To: DHCPv6 discussion list
Cc: DHCPv6 discussion list
Subject: RE: why seperate Ia is needed for sending new Requests?

If I remember correctly, we've considered the issue of virtual web
servers 
in the past.  Based on the capabilities of the current version of HTTP
for 
identifying virtual web servers behind a single IP address, we've
discarded 
virtual web servers as a motivation for on-demand address assignment.

That's not to say there aren't other motivations for on-demand address 
assignment.  Perhaps temporary addresses are a good motivating example.
If 
we're going to add complexity to the protocol to support on-demand
address 
assignment, we need to make sure we understand the specific motivations
and 
requirements.

- Ralph

---

From: [email-masked]
Date: Fri, 16 Mar 2001 10:06:26 -0600

your right and some of these were used to support this in the past.  I even
agree with you 100%.  But........we cannot get consensus on this right now
is my feeling.  the reason is the model to do what you asksn requires us as
protocol developers to head down the path to permit clients to request
addresses as they need them.  this is like a new model.  that new model
causes other new models, etc. etc.  so what we did was just eliminate this
via the use of multiple IAs.  True we don't let at client put xxx in num
addrs today in the IA.  This would be one way to do this in the existing
draft 18.  but I fear it will cause us to still be discussing that at the
london ietf in aug 2000.  that is not good for ipv6 or dhcpv6.  what you
suggest and I believe need (and others will) can be done using draft 18 with
multiple IAs and server admin configuration.  

where I am coming from is kind of like when we all are building products and
one very bright engineer is trying to put that last piece of elegant code
into the source pool to get it just right and meet ALL requirements for
performance, optimization, etc. but the lead engineer has to tell them "I
hear you" but the customer needs this and we need to check this into the
source pool like tonight to meet the next release of the product.  dhcpv6 in
the market is in that position.  we need to ship a spec to the IESG after
minneapolis I think.

trying to get this in is going to slow things down unless some cosmic ray
pops  in and all see what your saying at the same time.  plus our AD Thomas
has put forth many many arguments against following this model right now.  

after we get all to agree with what we have now we can revisit extensions
(as we will for many things I would imagine like all protocols do to evolve)
the number of addresses field can be a place holder for tomorrow.

but lets see if we can get what we have now blessed by the IESG, get PS
status, get v6 implementors to build it.  then we will hear lots of new
input from deployment and the 3GPP IPv6 trials (one I am organizing now for
Sept 2001 in Nice France).  get kame and unh to build test suites etc...

I support what your trying to do just ask that we try to move forward for
now.

If for some reason something else is going to slow us down to not get to the
IESG like really quick after minneapolis I will be greatly disappointed and
the market (customers) and then I would change my position if we are going
to keep hacking on this and not get to PS.

at least think about what I am saying if you can,
thanks
/jim

> From: ext Thirumalesh Bhat [mailto:[email-masked]]
> Sent: Friday,March 16,2001 12:52 AM
> >

---

From: "Thirumalesh Bhat" <[email-masked]>
Date: Fri, 16 Mar 2001 08:44:42 -0800

I agree that there is a need to get the dhcpv6 draft completed soon.
Since this is of great importance, let us move forward at this point.

thx

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Friday, March 16, 2001 8:06 AM
To: DHCPv6 discussion list
Subject: RE: why seperate Ia is needed for sending new Requests?

your right and some of these were used to support this in the past.  I
even
agree with you 100%.  But........we cannot get consensus on this right
now
is my feeling.  the reason is the model to do what you asksn requires us
as
protocol developers to head down the path to permit clients to request
addresses as they need them.  this is like a new model.  that new model
causes other new models, etc. etc.  so what we did was just eliminate
this
via the use of multiple IAs.  True we don't let at client put xxx in num
addrs today in the IA.  This would be one way to do this in the existing
draft 18.  but I fear it will cause us to still be discussing that at
the
london ietf in aug 2000.  that is not good for ipv6 or dhcpv6.  what you
suggest and I believe need (and others will) can be done using draft 18
with
multiple IAs and server admin configuration.  

where I am coming from is kind of like when we all are building products
and
one very bright engineer is trying to put that last piece of elegant
code
into the source pool to get it just right and meet ALL requirements for
performance, optimization, etc. but the lead engineer has to tell them
"I
hear you" but the customer needs this and we need to check this into the
source pool like tonight to meet the next release of the product.
dhcpv6 in
the market is in that position.  we need to ship a spec to the IESG
after
minneapolis I think.

trying to get this in is going to slow things down unless some cosmic
ray
pops  in and all see what your saying at the same time.  plus our AD
Thomas
has put forth many many arguments against following this model right
now.  

after we get all to agree with what we have now we can revisit
extensions
(as we will for many things I would imagine like all protocols do to
evolve)
the number of addresses field can be a place holder for tomorrow.

but lets see if we can get what we have now blessed by the IESG, get PS
status, get v6 implementors to build it.  then we will hear lots of new
input from deployment and the 3GPP IPv6 trials (one I am organizing now
for
Sept 2001 in Nice France).  get kame and unh to build test suites etc...

I support what your trying to do just ask that we try to move forward
for
now.

If for some reason something else is going to slow us down to not get to
the
IESG like really quick after minneapolis I will be greatly disappointed
and
the market (customers) and then I would change my position if we are
going
to keep hacking on this and not get to PS.

---

From: "Bernie Volz (EUD)" <[email-masked]>
Date: Fri, 16 Mar 2001 11:45:59 -0600

Jim:
 
Just as in DHCPv4 where an admin can use the haddr or client identifier, we'll be able to use the DUID (or whatever we end up calling it) to identify the client. So, why can't an admin add a policy for a specific client to give it <n> addresses? Again, this is an implementation issue - your server may not offer this facility whereas one that I build could.
 
Also, we'll likely add some sort of options to identify the 'class' or 'type' of client - perhaps that can be used as a trigger to the server to grant a specific number of addresses.
 
- Bernie Volz

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, March 16, 2001 10:34 AM
To: DHCPv6 discussion list
Subject: RE: why seperate Ia is needed for sending new Requests?

true bernie.....but as I said on the design con call I am not clear how the admin differentiates one client from the other to satisfy specific client requests as right now the client can't ask for any specific number of addresses (which I support too).  
 
/jim

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

There is nothing in the DHCPv6 spec that prohibits a client from getting any number of addresses, as often as it likes. It just can't say exactly how many addresses it wants. If the client doesn't get enough, it can ask for more. If it later wants more, it can ask for them. If it wants to get rid of some, it can do that too.
 
If you have a web hosting system, you might configure your DHCPv6 server to give it LOTS of addresses (on one or more prefixes). That would reduce the number of requests that system would need to make. But, even if you don't, it can still get the addresses it wants (provided the server's policy allows it).
 
- Bernie

-----Original Message-----
From: Thirumalesh Bhat [mailto:[email-masked]]
Sent: Thursday, March 15, 2001 10:32 AM
To: DHCPv6 discussion list
Subject: RE: why seperate Ia is needed for sending new Requests?

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: 

- Bernie Volz 

-----Original Message----- 
From: Vijay Bhaskar A K [ mailto:[email-masked] <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? 

-Vijay 
> From: Vijay Bhaskar A K [ mailto:[email-masked] <mailto:[email-masked]> ]

---

From: [email-masked]
Date: Fri, 16 Mar 2001 12:28:22 -0600

that fine......and I will work.
thx
/jim

-----Original Message-----
From: ext Bernie Volz (EUD) [mailto:[email-masked]]
Sent: Friday,March 16,2001 12:46 PM
To: DHCPv6 discussion list
Subject: RE: why seperate Ia is needed for sending new Requests?

Jim:
 
Just as in DHCPv4 where an admin can use the haddr or client identifier,
we'll be able to use the DUID (or whatever we end up calling it) to identify
the client. So, why can't an admin add a policy for a specific client to
give it <n> addresses? Again, this is an implementation issue - your server
may not offer this facility whereas one that I build could.
 
Also, we'll likely add some sort of options to identify the 'class' or
'type' of client - perhaps that can be used as a trigger to the server to
grant a specific number of addresses.
 
- Bernie Volz

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, March 16, 2001 10:34 AM
To: DHCPv6 discussion list
Subject: RE: why seperate Ia is needed for sending new Requests?

true bernie.....but as I said on the design con call I am not clear how the
admin differentiates one client from the other to satisfy specific client
requests as right now the client can't ask for any specific number of
addresses (which I support too).  
 
/jim

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

There is nothing in the DHCPv6 spec that prohibits a client from getting any
number of addresses, as often as it likes. It just can't say exactly how
many addresses it wants. If the client doesn't get enough, it can ask for
more. If it later wants more, it can ask for them. If it wants to get rid of
some, it can do that too.
 
If you have a web hosting system, you might configure your DHCPv6 server to
give it LOTS of addresses (on one or more prefixes). That would reduce the
number of requests that system would need to make. But, even if you don't,
it can still get the addresses it wants (provided the server's policy allows
it).
 
- Bernie

-----Original Message-----
From: Thirumalesh Bhat [mailto:[email-masked]]
Sent: Thursday, March 15, 2001 10:32 AM
To: DHCPv6 discussion list
Subject: RE: why seperate Ia is needed for sending new Requests?

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]
<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? 

-Vijay

---

From: [email-masked]
Date: Fri, 16 Mar 2001 22:44:29 -0600

mike carney was one who wanted the version number.  issue was client
implementations at bake-offs and in practice would break for a long time
when new features were added. 
 
I don't think we need it just don't want it to pop up at the last minute.
but if folks want it I can see a use for it too.  so I am agnostic on the
issue.  but would like to end that loose end if it exists one way or the
other.
 
/jim

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

Ralph: 

Wish I could remember the details as well. 

I think one argument might be that why not just change the UDP port number
if you revise the protocol? 

Another is that by using a version number, you might not gain that much
because at least part of the message format must stay the same in order to
be able to recognize that this is a new version of the protocol.

And, a third possiblity is that since the message type is the first byte,
why not just use new message types? 

And, forth, future revisions of the protocol could be handled by sending a
special option on the Advertise or Solicit to indicate that the server is
capable of the extended functionality. Though in this case, the basic
message format has to be retained.

BTW: Regarding the error message issue, how about we have a message type
which can be sent by a agent (server or relay) to respond to a client to
return some error. That way, if the client sends an unknown message type,
the server (or relay) can respond. This message type MUST be unicast by the
relay or server. That message type might be formatted as follows:

      0                   1                   2                   3 
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
     |    msg-type   |  error-number |      error-text               | 
     .                                                               . 
     .                                                               . 
     |                                                               | 
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

Probably the only error number that is needed today is
"unknown/unimplemented message type"? 

- Bernie 

-----Original Message----- 
From: Ralph Droms [ mailto:[email-masked] <mailto:[email-masked]> ] 
Sent: Friday, March 16, 2001 5:11 PM 
To: DHCPv6 discussion list 
Subject: RE: why seperate Ia is needed for sending new Requests? 

It's Friday afternoon, my wife's been visiting her mother in Wisconsin all 
week and I'm rushing around getting ready to go to Minneapolis - so I'm 
having trouble remembering the details about previous discussions about a 
version number in the DHCP message header. 

But it strikes me that we came to the conclusion that a version number 
turns out to be not all that useful.  Does anyone else remember having this 
discussion previously - it might have been regarding DHCPv4? 

- Ralph 

At 03:25 PM 3/16/2001 -0600, [email-masked] wrote: 
>I mean't to bring up the version number before.  We were asked for this
some 
>time ago and a suggestion from several.  I can't recall arguments against
it 
>and it may have fell through the cracks? 
> 
>/jim 
> 
> > From: ext ebenezer schubert [ mailto:[email-masked]
<mailto:[email-masked]> ] 
> > Sent: Friday,March 16,2001 3:12 PM 
> > Hi, 
> >     I would agree with what Jim is saying. The market 
> >     is ready for DHCPv6 and we need some conclusion 
> >     on this fast. 
> > 
> >    At the same time there should be some scope for 
> >    whatever the future versions to interoperate with 
> >    the older ones. I would like to make 2 suggestions 
> >    in this regard 
> > 
> >     1. To have an unimplemented error message. 
> >     2. To have a version field in the header. 
> > 
> >    So that even if the IESG takes a long time to make 
> >    a standard. We can proceed with the existing drafts, 
> >    if the standard is different from the draft, we should 
> >    be able to handle them easily. 
> > 
> > 
> > -ebi 
> > Hewlett-Packard 
> > 408-447-7652 
> > 
> > ----- Original Message ----- 
> > From: <[email-masked]> 
> > To: DHCPv6 discussion list <[email-masked]> 
> > Sent: Friday, March 16, 2001 7:50 AM 
> > > hi ralph, 
> > > I agree with you in spirit but the flesh is weak.  we have 
> > chased the 
> > client 
> > > telling servers "I want x addresses" for a long time.  I 
> > suggest as I 
> > do for 
> > > reconf-init multicast we not permit in our effort to get to PS.  We 
> > will not 
> > > reach consensus and the market is ready for dhcp using ipv6. I also 
> > believe 
> > > reality is that most clients will get a default number of addresses 
> > from the 
> > > server.  clients that send another IA will get x addresses as they 
> > will be 
> > > special anyway.  So though in "theory" it seems messy, in practice I 
> > think 
> > > it will work fine. 
> > > 
> > > for temporary addresses I think the client setting a bit in 
> > IA Status 
> > will 
> > > tell the server I need to "note" temporary addresses.  When the 
> > server 
> > > responds it will send x addresses to the client.  Before 
> > each address 
> > a bit 
> > > will be set in the addr status field that this address is "noted" as 
> > > temporary.  I really don't think temporary addresses is a complex 
> > thing and 
> > > I think we need to be careful we don't over complicate this part of 
> > what we 
> > > need to do.  at the server for the T1,T2,Preferred, and Valid 
> > lifetimes the 
> > > server can apply the recommendations of rfc 3041 to the 
> > times it uses 
> > to 
> > > provide the client leases.  Pretty simplex stuff I think.  then we 
> > just need 
> > > to make a decision on whether we let server renew temporary 
> > addresses.  in 
> > > the design call I think I heard it was ok to extend the valid 
> > lifetime but 
> > > not the preferred lifetime.  I think we should be able to wrap this 
> > up at 
> > > minneapolis. 
> > > 
> > > what would be really useful for the wed dhcpv6 venue is if ted could 
> > provide 
> > > the format and datum picture of the IA + client-id parts for the IA 
> > option 
> > > and the text for forming it so we can discuss.  That is necessary to 
> > go to 
> > > last call.  I think this is the most important and critical item we 
> > work on 
> > > next week. 
> > > 
> > > thanks 
> > > 
> > > /jim 
> > > 
> > > > From: ext Ralph Droms [ mailto:[email-masked]
<mailto:[email-masked]> ] 
> > > > Sent: Thursday,March 15,2001 7:57 PM

---

From: [email-masked]
Date: Fri, 16 Mar 2001 22:54:10 -0600

this is a good taxonomy for discussion point.  thanks.
I also don't think we should use a port number. I want to know from the
protocol the version has changed not by looking at the port number nor do I
want to run different versions of dhcpv6.

/jim

> From: ext Ebenezer Schubert [mailto:[email-masked]]
> Sent: Friday,March 16,2001 6:10 PM
> 	As long as there is an agreement that any new 
> functionality starting
> 	from  draft  revision  xxxx,  there  would be no 
> changes  to the msg
> 	structure or the  interpretation  of existing  message 
> types and any
> 	new feature would be through the introduction of a new 
> message type.
> 	Then it is ok.
> 
> 	But right  now,  there  seems to be a lot of  changes.  
> So  having a
> 	version  no.  field,  can help to  start  the  
> development  activity
> 	parallel to the work in the IETF.
> 
> 	This is the reason why  revising  the  protocol  port 
> no.  would not
> 	make any  sense,  because  we may not be able to  
> change  port  nos,
> 	between different  versions of the draft.  Also, we 
> cannot gurantee,
> 	that the interpretation of a particular message type 
> will not change
> 	until this becomes an RFC.
> 
> -ebi
> 
> 
> > Ralph:
> > 
> > I think one argument might be that why not just change the 
> UDP port number if you revise the protocol?
> > 
> > Another is that by using a version number, you might not 
> gain that much because at least part of the message format 
> must stay the same in order to be able to recognize that this 
> is a new version of the protocol.
> > 
> > And, a third possiblity is that since the message type is 
> the first byte, why not just use new message types? 
> > 
> > And, forth, future revisions of the protocol could be 
> handled by sending a special option on the Advertise or 
> Solicit to indicate that the server is capable of the 
> extended functionality. Though in this case, the basic 
> > BTW: Regarding the error message issue, how about we have a 
> message type which can be sent by a agent (server or relay) 
> to respond to a client to return some error. That way, if the 
> client sends an unknown message type, the server (or relay) 
> can respond. This message type MUST be unicast by the relay 
> or server. That message type might be formatted as follows:
> > 
> >       0                   1                   2                   3
> >      .                                                      
>          .
> >      .                                                      
>          .
> >      |                                                      
>          |
> > From: Ralph Droms [mailto:[email-masked]]
> > >I mean't to bring up the version number before.  We were 
> asked for this some
> > >time ago and a suggestion from several.  I can't recall 
> arguments against it
> > > > From: ext ebenezer schubert [mailto:[email-masked]]
> > > > > > From: ext Ralph Droms [mailto:[email-masked]]
> > > > > > >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

---

From: "Bernie Volz (EUD)" <[email-masked]>
Date: Tue, 20 Mar 2001 19:35:16 -0600

Ebi:
 
The post RFC makes more sense. Though I think history has shown that it often isn't that useful (an exception is probably the IP header version field!).
 
I think there are plenty of other alternatives - such as using new message numbers, a new port number if really different, or perhaps even just options. So, the question becomes is it worth paying the price for a byte (or at least a few bits if we can find them).
 
- Bernie

-----Original Message-----
From: ebenezer schubert [mailto:[email-masked]]
Sent: Tuesday, March 20, 2001 10:41 AM
To: DHCPv6 discussion list
Subject: Re: why seperate Ia is needed for sending new Requests?

Hi Bernie,
    
    The reason for asking version number is 
    not only for DEVOLOPMENT of the protocol.
    It is also post RFC. 
 
    The suggestion to use it during the development
     is just opportunistic.
 
 -ebi

----- Original Message ----- 

From: Bernie Volz (EUD) <mailto:[email-masked]>  
To: DHCPv6  <mailto:[email-masked]> discussion list 
Sent: Sunday, March 18, 2001 10:29 PM
Subject: RE: why seperate Ia is needed for sending new Requests?

Why do we need a version number during DEVELOPMENT of the protocol. It 
is pretty usual for I-Ds to change over time and that's just the price 
you pay for implementing early. I don't see a need to introduce a 
version number during the development phase. We really need to be able 
to maintain the flexibility to change things (though let's hope we're 
only doing very minor tweaks now if any!). 

I thought the original version number question was raised regarding the 
longer term issue - post RFC status how to we evolve it from there 
should we want to. I guess not. 

     Bernie 

-----Original Message----- 
From: [email-masked] [ mailto:[email-masked] <mailto:[email-masked]> ] 
Sent: Friday, March 16, 2001 11:54 PM 
To: DHCPv6 discussion list 
Subject: RE: why seperate Ia is needed for sending new Requests? 

/jim 

> From: ext Ebenezer Schubert [ mailto:[email-masked] <mailto:[email-masked]> ] 
> > > > From: ext ebenezer schubert [ mailto:[email-masked] <mailto:[email-masked]> ] 
> > > > > > From: ext Ralph Droms [ mailto:[email-masked] <mailto:[email-masked]> ]