Subject: RE: Simplify release and decline of addresses

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

I'd rather keep the existing behavoir. I don't think it is that much
more complicated. It basically requires a validation of the request
(to make sure all addresses are truely in the IA) and then only
removing a subset of the addresses instead of all.

If Ted's concerned that a client and server may not agree on the
addresses it has, I see three solutions:
- If the address a client specified is not part of the server's IA
but the address is not otherwise in use (by another client or IA),
then ignore the 'error' and consider the address released. After all
it is! (In the case of a Decline, ignore the address as that client
has no right to decline it.)
- 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.
- The client can simply 'drop' the IA and let the addresses' lifetime
clean them up.

Or, am I missing some set of events that cause more severe problems?

I like the text below - though it might need a slight revision if we
feel the above is appropriate.

- Bernie

-----Original Message-----
From: Ralph Droms [mailto:[email-masked]]
Sent: Wednesday, July 18, 2001 9:43 AM
To: DHCPv6 discussion list
Subject: Simplify release and decline of addresses

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: Jim Bound <[email-masked]>
Date: Wed, 18 Jul 2001 10:36:21 -0400 (EDT)

I thought teds text was fine.  simple and will reduce errors for
programmers which reduces engineering cost.

if we agree with ted and I am pretty sure I do.  lets just adopt the text
it will work.

other comments please

/jim

---

From: Ted Lemon <[email-masked]>
Date: Wed, 18 Jul 2001 13:46:00 -0700

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