Subject: RE: Questions about Release message

From: "Thirumalesh Bhat" <[email-masked]>
Date: Mon, 19 Feb 2001 09:56:04 -0800

I think the ability for a client to get multiple IP addresses from a
server is relevant in IPv6. ( either by using multiple IAs or by some
other method. ) The number of IP addresses available is no longer a
constraint and I can think of some apps that would like to take
advantage of this. It is even possible that new apps/protocols will be
developed to make use of the abundant supply of IP addresses.
 
thx

-----Original Message-----
From: Bernie Volz (EUD) [mailto:[email-masked]]
Sent: Monday, February 19, 2001 9:22 AM
To: DHCPv6 discussion list
Subject: RE: Questions about Release message

BTW: What, if any, recommendations should be given in the DHCPv6
specification regarding assignment/generation of addresses? Should the
DHCPv6 server assign addresses using the EUI-64 identifier of the
client? Should the DHCPv6 server NOT assign these addresses but have
some other method of generating addresses?
 
If one assumes that a given network prefix will either be all
auto-configured or all stateful configuration, the stateful
configuration is really free to do what it wants. However, if one
assumes that there could be both methods (perhaps not at the same time),
one might want to make sure that stateful configuration doesn't use
EUI-64 identifiers for the low 64-bits of the address. Otherwise,
problems could exist when switching configuration modes (Duplicate
Address Detection will help to eliminate potential problems).
 
Of course, using EUI-64 identifiers won't work if a client has multiple
IAs (wants multiple addresses) on a single network prefix.
 
Perhaps some of this is addressed in an IPv6 addressing structure RFC or
ID?
 
- Bernie Volz
  Ericsson

-----Original Message-----
From: Bernie Volz (EUD) [mailto:[email-masked]]
Sent: Monday, February 19, 2001 12:02 PM
To: DHCPv6 discussion list
Subject: RE: Questions about Release message

Ralph, et al: 

Haven't seen any discussion about these questions ... 

>Can a client send an empty IA to release all addresses in the IA? 

It would be nice to support this as it provides an easy way for a client
that might have used an IA before but has no record of what addresses it
had. This way, on boot, it can release all without knowning what all
was.

>What is the behavior of the server relative to a ``partially released''
IA; i.e., an IA for which some but not all addresses are released?

My own feeling is that the IAs will need to be rather dynamic - some
addresses will expire, others may be added as time goes on (to an IA).
This may happen because of changes to the topology. For example, a
single IA may start with one address. Later, as a renumbering event
approaches, a new address is added (the new network number). Even later,
the old address disappears from the IA as it has 'expired' (the lifetime
on it has ended).

I believe we also concluded that the client/server should always send
the 'full' address details with the IA. This is needed for failover and
also help that both client and server stay in sync. (The one exception
may be on a release per above - empty IA to release all).

>If the IA becomes empty - all addresses are released - can the server
discard any record of the IA? 

Seems to me it should (just as much as it discards any record of the
client). IPv6 address management is an interesting issue that hasn't
really been discussed. In the IPv4 world the DHCP server remembers the
client associated with an address (even after the client releases the
address). I think the same might apply in IPv6 and thus the server
really should remember the client information (including IA). That way,
it can give the same address back again (just as in IPv4).

Note that for DHCPv6, it might be possible for a server to have no
memory other than the 'last assigned address'. Each time a client
requests a 'new' lease, it increments the address. When renewals and
rebindings arrive, the server simply allows the use of the address. With
about 2^64 bits for addresses, it would take a LONG time before there
would ever be even the potential for trouble (since that only happens
when the addresses roll-over).

Finally, sorry for the late posting regarding these questions. 

- Bernie Volz 
  Ericsson 

-----Original Message----- 
From: Ralph Droms [ mailto:[email-masked]] 
Sent: Friday, February 02, 2001 12:54 AM 
To: DHCPv6 discussion list 
Subject: Questions about Release message 

There are some outstanding questions about Release messages in section 
11.6.2 of the -16 DHCPv6 spec: 

What is the behavior of the server relative to a ``partially 
released'' IA; i.e., an IA for which some but not all addresses are 
released? 

Can a client send an empty IA to release all addresses in the IA? 

If the IA becomes empty - all addresses are released - can the server 
discard any record of the IA?

---

From: Charlie Perkins <[email-masked]>
Date: Mon, 19 Feb 2001 10:31:59 -0800

Hello,

Well, good luck getting them.  I hope you succeed.  Of course, you
have no way to predict when or where the application wants to run,
so you can't preconfigure clients for application needs.  This is a good

thing in my opinion, and yet the DHCPv6 specification may never
support that feature again.

Regards,
Charlie P.

Thirumalesh Bhat wrote:

> developed to make use of the abundant supply of IP addresses.thx
>
>      BTW: What, if any, recommendations should be given in the
>      DHCPv6 specification regarding assignment/generation of
>      addresses? Should the DHCPv6 server assign addresses using
>      the EUI-64 identifier of the client? Should the DHCPv6
>      server NOT assign these addresses but have some other method
>      of generating addresses?If one assumes that a given network
>      prefix will either be all auto-configured or all stateful
>      configuration, the stateful configuration is really free to
>      do what it wants. However, if one assumes that there could
>      be both methods (perhaps not at the same time), one might
>      want to make sure that stateful configuration doesn't use
>      EUI-64 identifiers for the low 64-bits of the address.
>      Otherwise, problems could exist when switching configuration
>      modes (Duplicate Address Detection will help to eliminate
>      potential problems).Of course, using EUI-64 identifiers
>      won't work if a client has multiple IAs (wants multiple
>      addresses) on a single network prefix. Perhaps some of this
>      is addressed in an IPv6 addressing structure RFC or ID?-
>      Bernie Volz  Ericsson
>
>           It would be nice to support this as it provides an
>           easy way for a client that might have used an IA
>           before but has no record of what addresses it had.
>           This way, on boot, it can release all without
>           knowning what all was.
>
>           >What is the behavior of the server relative to a
>           ``partially released'' IA; i.e., an IA for which
>           some but not all addresses are released?
>
>           My own feeling is that the IAs will need to be
>           rather dynamic - some addresses will expire,
>           others may be added as time goes on (to an IA).
>           This may happen because of changes to the
>           topology. For example, a single IA may start with
>           one address. Later, as a renumbering event
>           approaches, a new address is added (the new
>           network number). Even later, the old address
>           disappears from the IA as it has 'expired' (the
>           lifetime on it has ended).
>
>           I believe we also concluded that the client/server
>           should always send the 'full' address details with
>           the IA. This is needed for failover and also help
>           that both client and server stay in sync. (The one
>           exception may be on a release per above - empty IA
>           to release all).
>
>           >If the IA becomes empty - all addresses are
>           released - can the server discard any record of
>           the IA?
>
>           Seems to me it should (just as much as it discards
>           any record of the client). IPv6 address management
>           is an interesting issue that hasn't really been
>           discussed. In the IPv4 world the DHCP server
>           remembers the client associated with an address
>           (even after the client releases the address). I
>           think the same might apply in IPv6 and thus the
>           server really should remember the client
>           information (including IA). That way, it can give
>           the same address back again (just as in IPv4).
>
>           Note that for DHCPv6, it might be possible for a
>           server to have no memory other than the 'last
>           assigned address'. Each time a client requests a
>           'new' lease, it increments the address. When
>           renewals and rebindings arrive, the server simply
>           allows the use of the address. With about 2^64
>           bits for addresses, it would take a LONG time
>           before there would ever be even the potential for
>           trouble (since that only happens when the
>           addresses roll-over).
>
>           From: Ralph Droms [mailto:[email-masked]]