Subject: RE: Simplify release and decline of addresses

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

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

-----Original Message-----
From: Vijay Bhaskar A K [mailto:[email-masked]]
Sent: Wednesday, July 18, 2001 6:17 PM
To: DHCPv6 discussion list
Subject: RE: Simplify release and decline of addresses

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
> 
> 
> 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.]

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.

> 
> 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).
> 

-- 
____Vijay_Bhaskar_A_K____
______Inet_Services______
________HP_ISO___________
____Ph:_2251554_1424_____
___Pager:_9624_371137____

---

From: "Vijay Bhaskar A K" <[email-masked]>
Date: Thu, 19 Jul 2001 05:47:45 +0530

RE: Simplify release and decline of addresses
  -----Original Message-----
  From: [email-masked] [mailto:[email-masked]]On
Behalf Of Bernie Volz (EUD)
  Sent: Thursday, July 19, 2001 4:27 AM
  To: DHCPv6 discussion list
  Subject: RE: Simplify release and decline of addresses

  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.
  [Vijay Bhaskar A K] What is the use of having "unused - MBZ". Is it
related to allignment problem?

  But, do we need 4 octets for IAID? It will be hardly 4-5 IA's per client,
in the normal case. But, if we reduce 1 byte in IAID, we can escape from
alignment problem and another byte "addr status" is also freed. (provided,
we are giving a seperate option for temporary address IA)

  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.
  [Vijay Bhaskar A K] *********

  Since, the temporary addresses are to be handled in a different way, we
need to keep temporary addresses in a different IA option. This simplifies
the IA option and make it easy to process temporary addresses.

  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,
  [Vijay Bhaskar A K] This is just an implementation isuue. What will
happen, if the two IAs are given the same IAID? Two IAs should not be given
the same IAID. Basically, these two types of IAs are same in the term of
content, but, behaviour of the IP addresses are different.

  Alternative is, we can seperate the address spaces for Temporary
addresses. We can put the "T" bit in the IAID,

   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.
  [Vijay Bhaskar A K]  For this case, the server has to return error as,
Binding not available.
  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).
  [Vijay Bhaskar A K] I agree that the DHCPv6 support graceful renumbering.
But, once the subnet has got renumbered, the IA will contain the IP
addresses of old and new subnet prefixes. Instead of putting those addresses
belonging to two subnets, we can keep the deprecated one seperately. The
handling of those deprecated become more easier. I agree that, this is
merely an implemntation issue. I felt that putting together the valid and
deprecated ones gives a messy look, since T1 and T2 of the IA hold only for
the valid addresses and not for deprecated ones.

  ~vijay

  - Bernie

  -----Original Message-----
  From: Vijay Bhaskar A K [mailto:[email-masked]]
  Sent: Wednesday, July 18, 2001 6:17 PM
  To: DHCPv6 discussion list
  Subject: RE: Simplify release and decline of addresses

  Hi,
  Find my comments inline.
  ~Vijay

     0                   1                   2                   3

---

From: Jim Bound <[email-masked]>
Date: Thu, 19 Jul 2001 00:41:40 -0400 (EDT)

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