Subject: Simplify release and decline of addresses

From: Ralph Droms <[email-masked]>
Date: Wed, 18 Jul 2001 09:43:13 -0400

Ted suggests a simplification: requiring that all the addresses in an IA be 
released or declined, rather than just some of those addresses.  Ted also 
wrote text describing the server behavior in response to a Decline message 
(which is missing from the -19 rev).

- Ralph

14.4.5. Receipt of Release messages

    Upon the receipt of a valid Release message, the server examines the
    IAs and the addresses in the IAs for validity.  If the IAs in the
    message are in a binding for the client and the addresses in the IAs
    have been assigned by the server to those IA, the server deletes
    the addresses from the IAs and makes the addresses available for
    assignment to other clients.

[IMHO, this is too complicated.  I think the client should always
release all addresses in an IA - that is, it should just send an empty
IA as described below.   Otherwise you get into complexities about how
to back out of an erroneous transaction that I think can't be solved.]

14.4.5-1/2. Receipt of Decline messages (To be inserted after existing
                                          section 14.4.5 in -19 rev)

    Upon the receipt of a valid Decline message, the server examines the
    IAs and the addresses in the IAs for validity.  If any IA in the
    message is not an IA that has been assigned by the server to that
    client, or if any addresses are mentioned in an IA that were not
    assigned by the server to the client, the server MUST NOT further
    process the message, but should send a Reply message indicating a
    NoBinding status.

    For each IA in the message, if there are any addresses mentioned in
    that IA, the server SHOULD mark each of these addresses as in
    conflict and SHOULD NOT make these addresses available for
    allocation to other clients.  Any addresses that the server has
    allocated to that IA but that are not mentioned in the message
    SHOULD be made available for assignment to other clients.

[As above, I would argue that the client should simply send empty IAs,
and let all the addresses be declined.   This has the disadvantage
that you can lose addresses that were not in conflict, but it makes
the whole transaction a lot simpler, and I think simplicity is a real
virtue in this case.]

    If an IA is mentioned in the Decline message without any
    accompanying addresses, the server SHOULD mark all the addresses in
    the IA as being in conflict, and SHOULD NOT make these addresses
    available for immediate assignment to other clients.

    Server implementors SHOULD implement a strategy for reclaiming
    these IP addresses if there are no addresses available for
    allocation.   Server implementors MAY also implement a strategy to
    detect a client that is repeatedly allocating and then declining
    addresses.   When such a client is detected, the server SHOULD
    refuse to allocate further addresses to that client for
    DECLINE_COOLOFF (see section 7.5) seconds.

    The server then generates a Reply message.  If all of the IAs were
    valid, the server sets the "status" field to "Success".  If any of
    the IAs were invalid, the server sets the "status" field to
    "NoBinding" (section 7.4).

---

From: Vijay Bhaskar A K <[email-masked]>
Date: Wed, 18 Jul 2001 18:16:33 -0400 (EDT)

Hi,
Find my comments inline.
~Vijay

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of Ralph Droms
> Sent: Wednesday, July 18, 2001 7:13 PM
> To: DHCPv6 discussion list
> Subject: Simplify release and decline of addresses
> 
> 

Yes.  I agree that, the  release/decline  of  addresses as whole IA will
simplify the more.  So, here,the  status field returned will be the same
for all the addresses of the IA and it can be very well  reflected in IA
status.  So, do we really need the "addr  status"  field?  Whatever  the
error  status  defined can be returned in IA status  itself.  So, i feel
that, we can  remove  the "addr  status"  field in IA.  It can save many
bytes, if the addresses in th IA are very large in number.

Another  suggestion is, because of handling  Temporary  address only, we
have  introduced  the "T" bit in IA  option.  Why  can't we define a new
option for temporary address IA (TMP_IA).  Using this TMP_IA, the client
can ask for one or more temporary addresses.  

The main reason behind is,

* The time values T1 and T2 are defined for specifying the time at which
the client has to contact the server.  But, for the temporary addresses,
renewal  and rebind is not  possible.  So, T1 and T2 are not  necessary.
So, we can remove these fields.

* Normally, if the clients are requesting for the normal addresses, they
will not be needing  temporary  addresses.  The clients  requesting  for
both  will be  rare.  So,  why do we need to put a bit in IA and  giving
more burden to IA option.

So, the TMP_IA option looks like this.

   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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |           OPTION TMP_IA        |          option-len          | 
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                        IAID (4 octets)                        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   IA status   |   num-addrs   | prefix length  | IPv6         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
     |                                                               |
     |                          addresses                            |          
     |                          (16 octets)             +-+-+-+-+-+-+
     |                                                 | preferred   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                      lifetime                   | valid       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                       lifetime                  |IPv6         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
     |                                                               |
     |                          addresses                            |          
     |                          (16 octets)             +-+-+-+-+-+-+
     |                                                 | preferred   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                      lifetime                   | valid       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                       lifetime                  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

I'm not sure whether  there will be an allignment  problem.  But, we can
reduce unnecessary bytes using this option.

* One more point to be noted is, a fair  implementation of DHCPv6 should
support "graceful  renumbering".  It should provide some grace period to
the old  prefixes.  The  deprecated  IPv6  addresses  (addresses  of old
prefixes)  almost look like the temporary  address with  preferred  life
time as 0 and valid  life time as 1-2  days.  This  option  will be more
useful for handling those  deprecated  addresses,  since those addresses
are not supposed to be renewed/rebinded.

-- 
____Vijay_Bhaskar_A_K____
______Inet_Services______
________HP_ISO___________
____Ph:_2251554_1424_____
___Pager:_9624_371137____

---

From: "Bernie Volz (EUD)" <[email-masked]>
Date: Wed, 18 Jul 2001 17:37:37 -0500

For a Release and Decline, these are sent to a specific server and can reach
the server via a relay.

But the server might receive multiple copies (and if it has no transaction
cache ...). However, that's exactly the case my suggested processing
for the client covers - ignore addresses not assigned to the IA (don't
consider this an error).

BTW, in this case the server must be able to handle a Release or a Decline of
an IA that doesn't exist. Or, if it returns an error the client must be able
to handle it.

- Bernie

-----Original Message-----
From: Ted Lemon [mailto:[email-masked]]
Sent: Wednesday, July 18, 2001 4:46 PM
To: DHCPv6 discussion list
Subject: Re: Simplify release and decline of addresses 

> - The client always has the ability to Release/Decline all address
> if it gets an error back. Then the client/server should be in
> agreement regarding that IA (no addresses). In this case, the client
> MUST send an IA with no addresses.

If the client doesn't have a routable address, I don't think it can
send a Release message.   It doesn't seem like a good idea to just
broadcast a Release message through a relay agent.   I can't really
justify that, but that's my gut feeling on the matter.   :'}

			       _MelloN_

---

From: [email-masked]
Date: Thu, 19 Jul 2001 08:52:43 -0700

been trying to unsubscribe..

                                                          

"Jim Bound" <[email-masked]> on 07/18/2001 09:41:40 PM

Please respond to [email-masked]

 To:      "DHCPv6 discussion list" <[email-masked]>     
                                                              
 cc:      (bcc: Relfe Tan/SB/GAPINC)                          

 Subject: RE: Simplify release and decline of addresses       

The client does not request addresses per se in dhcpv6 now directly. It
asks for them.  So the server has control over the T bit via policy.

/jim

On Wed, 18 Jul 2001, Bernie Volz (EUD) wrote:

> Vijay:
>
> Removing "addr status" in the IA option without also removing the T bit
> won't help save bytes since the T bit will require the byte anyway. We
> might change "addr status" to "unused - MBZ" though if we're not using it.
>
> Regarding a new option to handle Temporary Addresses, I think this has
> merit simply because there has been no way for a client to communicate
> what kind of addresses it wants. Having this option provides that mechanism.
> Alternatives, such as allowing 'num-addrs' and thus some address information
> (T bit) to be specified by the client in a Request were discussed at one
> point but did not make it into the -19 draft and I'm not sure if it would be
> in the -20.
>
> Perhaps Ralph and Jim will care to provide some indication of how this will be
> resolved in the -20 draft - to give the client some ability to communicate to
> the server what it needs. OR, perhaps the answer is simply "no, we're not
> going to support it - it is up to the server to figure it out."
>
> There are some issues with a new option - such as the IAID spaces must not
> overlap, and then what happens if the wrong option is used with an IAID in
> a Renew (or Release, ...). So, it gets messy and is probably not the best
> approach.
>
> Your point about graceful renumbering doesn't make sense ... IPv6 (and
> DHCPV6) already provide for this. I don't think we want addresses to between
> IA's so I think this concept is a bad one. Just like stateless addresses where
> lifetimes can be extended, so can they with DHCPv6 (that is either or both
> the preferred and valid).
>
> - Bernie
>
> From: Vijay Bhaskar A K [mailto:[email-masked]]
> Sent: Wednesday, July 18, 2001 6:17 PM
> Subject: RE: Simplify release and decline of addresses
>
>
> Hi,
> Find my comments inline.
> ~Vijay
>

---

From: "Bernie Volz (EUD)" <[email-masked]>
Date: Tue, 24 Jul 2001 18:09:19 -0500

The issues you have are:

- What if multiple servers are involved. A client only wants a new temporary address,
but gets a boatload of other addresses. Perhaps it releases them (but then if we don't
allow the selective release ...). This adds extra processing overhead to client and
server.

- This imposes additional requirements on a server. If a server gets a new IA, does
it automatically assume well that client already has <n> non-temporary addresses, so
just give it <y> more temporary addresses. What if a server doesn't have this policy
and keeps giving the client more and more non-temporary addresses as well? We need to
make sure we reflect that as a requirement to server implementators. Again a client
culd release those it doesn't want (assuming selective release allowed) but again
that adds extra processing overhead to both client and server.

- All I think we really need is "I want addresses (of whatever type the server is
willing to give" and "I want temporary addresses only". I don't really see a need
for any other cases since a client can simply use a new IA if it wants more addresses
in general.

- Bernie

-----Original Message-----
From: Ralph Droms [mailto:[email-masked]]
Sent: Tuesday, July 24, 2001 6:42 PM
To: DHCPv6 discussion list
Subject: RE: Simplify release and decline of addresses

My memory is that we've come to consensus that the client doesn't get to 
specify what kind of addresses it wants; the client sends an IA to the 
server and the server's response is determined by the server's admin policies.

- Ralph