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

From: "Bernie Volz (EUD)" <[email-masked]>
Date: Fri, 16 Mar 2001 08:18:57 -0600

Hi:

It may also be fairly easy to add this feature in the future. For example, the client could include an additional option that specifies the addresses requested (min ... max)? This option could also include the prefixes on which the addresses are requested (in cases where multiple prefixes are active on a single link).

The option parameters might be a sequence of one or more of the following sets of data:
- <Identity-Association> ID that this request goes with [this might not be needed if we 'order' options such that this appears BEFORE the Identity-Association to which it applies.
- Address prefix (length + prefix) (all 0's if don't care)
- Minimum number of addresses desired (16-bits?)
- Maximum number of addresses desired (16-bits?)

Note that the above option would be ignored by servers that don't support it. That may be bad. If that is a problem, an alternative is to define another 'address allocation request' option that basically is similar to the Identity-Association Option but adds some of the above data to allow a client to specify more details about the addresses it is looking for.

But is something like this needed today in the 'core' protocol standard? I think the 'core' protocol standard has what's required now (and can even handle the requested requirements, although not as efficiently as might be desired). There will always be special applications that may need extensions, and we can easily add them later.

Also, in the examples given below, it is unlikely that you'd need thousands of addresses.

- Bernie Volz

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

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

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: Ted Lemon <[email-masked]>
Date: Fri, 16 Mar 2001 10:21:29 -0800

The protocol as we have discussed it already provides a mechanism
whereby a client can get more than one network identity (i.e., address
set): the Identity Association.  We do not know of a need for an
additional mechanism, and the mechanism you described is basically the
same one we rejected back at -14 or so, because while it looked easy
in the packet, it was actually very complex to implement.  It sounds
like you don't want to do things the way you've proposed either - it
was just an example of how things *might* be done differently - so
let's just drop this and get on with the work at hand.  I don't think
there's any need to continue this discussion.

			       _MelloN_