Subject: RE: Simplify release and decline of addresses

From: "Thirumalesh Bhat" <[email-masked]>
Date: Wed, 18 Jul 2001 09:33:38 -0700

Are we still considering the addition of NAK to v6? If the client is
waiting for an ACK from the server for release/decline, it could be a
problem when the client has switched networks. Either we need to have
"Release/decline - go to the next state" or "release/wait for a NAK/ACK"
to speed up the process.

I think there is a typo in the current draft:
 
Section 14.3.11 needs to be changed as:
 
From
14.3.11. Receipt of Reply message in response to a Release message
 
To
14.3.11. Receipt of Reply message in response to a Decline message

thx

-----Original Message-----
From: Bernie Volz (EUD) [mailto:[email-masked]] 
Sent: Wednesday, July 18, 2001 7:17 AM
To: DHCPv6 discussion list
Subject: RE: Simplify release and decline of addresses

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 14:19:35 -0400 (EDT)

I don't think so... See mail on prefrix notification and text bernie just
sent...

/jim