Subject: List of issues for WG meeting with resolution summaries

From: Ralph Droms <[email-masked]>
Date: Tue, 07 Aug 2001 12:17:55 +0100

Here's a revision of the list of issues, with an annotation for each issue 
either explaining my understanding of WG consensus on resolution or marking 
the issue as open.  Note that the list of issues has been somewhat 
rearranged from the list I sent out earlier to provide a little more 
logical grouping.  Thanks to Bernie for his quick review and input on this 
list.

Please review and reply with comments before tomorrow's meeting if possible...

- Ralph

* Should addresses in an Advertise message be "real" addresses or
   "informational"; e.g., just prefixes?

   WG consensus: addresses in Advertise are the addresses the server
   will return in a subsequent Reply; client supplies those addresses
   to server in IA in Request message

* Servers will only assign complete addresses and not prefixes (e.g.,
   to be used by the client for stateless autoconfiguration)

   WG consensus: yes; prefix advertisement is handled through ND

* Modify IA option so that all addresses in an IA are "regular" or
   "temporary".  Modify text so that client indicates types of
   addresses to be assigned by sending appropriate IAs.  Server then
   fills in each IA with assigned addresses.

   Open issue

* Define separate IA option for temporary addresses rather than
   indicate the type of address in a single IA option

   Open issue

* How and when does the client use DAD on addresses in Advertise and
   Reply messages?

   WG consensus: Client does DAD on addresses in Reply message and
   responds with Decline if addresses unacceptable (e.g., already in
   use)

* Advertise message SHOULD include options for all OROs that were
   included in the Solicit if the server is willing/capable of offering
   a value for that option

   WG consensus: yes

* Should we consider a "quick" handshake for allowing a client to
   assign an address in a single exchange of two messages?

   WG consensus: defer for later reconsideration

* Tighten up text on T1/T2 to require T1/T2 occur prior to expiration
   of lifetimes of addresses in IA; no need to describe default as
   T1/T2 are fields in IA header and must be supplied by server

   WG consensus: yes

   Open issue: what about selection of T1/T2 with temporary addresses
               and with addresses whose lifetimes won't be extended;
               e.g. addresses to be deprecated/discarded due to
               renumbering.

* The semantics of the use of IA must be clarified (see Volz message
   of 7/19).  In particular, what are the semantics of a Request
   containing an IA that the client has previously sent to the server?
   What are the semantics of a Requst containing a new IA?

   Open issue: rules about when to reuse old IA or use new IA

* Simplify Release and Decline so the all of the addresses in an IA
   are released or declined, rather than allowing the client to release
   or decline just some addresses.

   WG consensus: yes

* Add "NAK" function:

    If the server finds that the prefix on one or more IP addresses in
    any IA in the {Request,Confirm,Rebind} message is not a valid
    prefix for the link to which the client is connected, the server
    MUST send an NoPrefixMatch status in the IA status field for that
    IA in the DHCP Reply message.

   WG consensus: yes; indicate "NAK" through return of "NoPrefixMatch"
                 error code.  Add text allowing client to ignore
                 "NoPrefixMatch" from other servers if ACK received from
                 at least one server.

* Define DUID to be one of:
   - Link-layer address plus time
   - Vendor-assigned unique ID
   - Link-layer address
   - IMSI
   - IMEI

   WG consensus: yes; based on text submitted by Lemon with extensions
                 from subsequent WG discussion

* Use IPsec for secure agent/server communication

   WG consensus: yes; add text to draft

* Add an "error code" option, to indicate errors not connected with a
   specific option

   WG consensus: yes

* Tighten up language for unicasting Reconfigure-Init; in particular,
   the server may not have an appropriate address to use to send the
   message to the client.

   WG consensus: yes

* Reply to a Confirm should be a simple ACK/NAK without changing any
   values in options

   WG consensus: yes

* Reply to Decline or Release should carry no options

   WG consensus: yes

* Restrict options in Decline or Release to IA with text to allow
   other options in the future

   Open issue

* Server does not respond to Solicit when server has no addresses

   Open issue

* Include only options specifically mentioned in the text in the
   DHCPv6 spec; move others to second doc or separate appendix

   Open issue; generate list of options based on previous work

* Add 'secs' field to fixed header

   Open issue

* Describe message transmission and retransmission in a separate
   section of the spec and reference that text throughout the remainder
   of the spec

   Open issue

* Discard the client unicast or recheck the entire spec for
   consistency in reference to message transmission

   Open issue

* Remove client link-local address from client message header.  Agent
   can then determine link-local from source (IP header) in client
   message and insert into agent->server message.  Server responds to
   source from IP header (whether agent or client).

   Open issue

---

From: Vijay Bhaskar A K <[email-masked]>
Date: Wed, 8 Aug 2001 01:39:44 +0530 (IST)

Hi,
see my comments inline.

>    to server in IA in Request message

Isn't  enough that, if the server  sends the prefix in the IA?  because,
the server has to remember  these  OFFERED  addresses.  There  should be
some  expiration  time for these OFFERED  addresses  and in the case, if
this time has expired, and the server has  assigned  this  addresses  to
different  clients, then the client has to accept  different  addresses.
The main  purpose of this  sending the  addresses  is to show the client
that the  server is willing to serve the client  with IP  addresses.  In
the client point of view, whatever  addresses it get, it doesn't matter.
Do you think, do we need to include  unnecessary load of remembering and
maintaining  the  OFFERED  addresses  and  keeping a time knob for those
addresses?

In the case, if it is finalised as the server SHOULD send the addresses,
the text has to be added for the time knob for those  OFFERED  addresses
and behaviour of the client, if it gets the different  addresses, it has
sent in the request.

>    indicate the type of address in a single IA option

The  two  possible  solutions  for  handling  IA  containing   temporary
addresses are,

1) modify the IA option by adding one bit before the "IA  status"  field
and  removing  "T" bit  before the "addr  status".  The IA option  looks
something like this. I have already posted this format.

 	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 IA           |          option-len           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                        IAID (4 octets)                        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                              T1                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                              T2                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |T| IA status   |   num-addrs   | prefix length |               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               |
     |                                                               |
     |                         IPv6 address                          |
     |                          (16 octets)                          |
     |                                                               |
     +               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |               |      preferred lifetime                       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |               |        valid lifetime                         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |               | prefix length |                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
     |                         IPv6 address                          |
     |                          (16 octets)                          |
     |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                               |      preferred lifetime       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | pref. lifetime (cont.)        |        valid lifetime         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | valid lifetime (cont.)        | prefix length |               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               +
     |                                                               |
     |                         IPv6 address                          |
     |                          (16 octets)                          |
     |                                                               |
     +               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |               |              ...                              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Since the T bit before "addr  status"  field has no use and since we are
not going to do something  specific to a particular  IP address in an IA
(since,  release or decline  will be done for the whole IA only, not for
some address in the IA), there is no use for "addr  status"  field.  The
whole status of the IA can be reflected  in IA status  itself.  Thus, we
can eliminate  the "addr  status"  also.  But, i'm not sure there may be
some alignment  problem, if we directly  reomove that field.  So, we can
put an Must be Zero byte  there.  But, one  thing, we need to take  care
is, if the number of addresses  in the IA is large, then, we are wasting
that much number of unused bytes.  Alternatively, we can remove one byte
from the IAID and make alignement proper.

2) Second solution is, keeping a different option for Temporary  address
IA.  Since, the  temporary  addresses  MUST not be renewed,  there is no
point in having T1 and T2 values  for the IA.  We can  define a seperate
option for Temporary Address IA similar to the IA option but without the
T1 and T2 values.  The temporary IA option will look 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 address                          |
     |                          (16 octets)                          |
     |                                                               |
     +               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |               |      preferred lifetime                       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |               |        valid lifetime                         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |               | prefix length |                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
     |                         IPv6 address                          |
     |                          (16 octets)                          |
     |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                               |      preferred lifetime       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | pref. lifetime (cont.)        |        valid lifetime         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | valid lifetime (cont.)        | prefix length |               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     |                         IPv6 address                          |
     |                          (16 octets)                          |
     |                                                               |
     +               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |               |              ...                              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Here, we don't  need to have "T" bit  before  the IA  option  and TMP IA
option also.

The problem told by Bernie on this model was,

a) According to the IA option defined in 19th rev, we need a "T" bit for
identifying the temporary addresses.  So, he told that even though "addr
status" is unused, we need to  allocate a byte for "T" bit, so we cannot
remove it.  Now, we can move the "T" bit  before the "IA  status"  byte.
So, this  problem is solved.  In the case, if we are  defining  seperate
option, we don't need the "T" bit itself.

b) ** comments from Bernie***
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. 
**end of bernie's comments***

The  problem  of  IAID  spaces  overlapping,  if the  client  mistakenly
allocates the same IAID for the 2 IAs.  This is purely an implementation
problem, the client MUST not allocate same IAID for two IAs.

The second problem's solution is, if the client has an Temporary Address
IA with IAID 36 and if it sends the  renew/rebind as IA option with IAID
36, the server has to discard  that  option.  because of  following  two
reasons.

i) It doesn't have the bindings of Temporary IA with IAID 36
ii) The temporary addresses cannot be renewed/rebinded.

I prefer defining a seperate option for Temporary  address IA, since the
behaviour of the  addresses  inside the IAs are different  for these two
type of IAs.

>    T1/T2 are fields in IA header and must be supplied by server

But, obviously, as per default definitions for T1 and T2, T1 wont expire
before the  expiration of lifetimes in the IA.  Since T1 defaults to 50%
of the preferred  lifetime of the IP address with shortest life time.  I
think there is no harm in keeping this.

>                e.g. addresses to be deprecated/discarded due to

If we are going to use seperate  option for IA for normal  addresses and
IA for temporary addresses, then, this problem won't occur.

If we are going to use same  option  for both,  then, for IA  containing
temporary address, T1 and T2 should be infinity, meaning that, it SHOULD
not contact the server for renewal.

> * Add an "error code" option, to indicate errors not connected with a

yes, this error option is  necessary.  Ebi has already  given the format
of the "error  code"  option and  various  error  codes.  Do you want me
resend those details?

> * Server does not respond to Solicit when server has no addresses

The  server  MUST  respond  with  the  remaining  available  parameters.
eventhough it doesn't have the address to allocate.  This is because, if
the client has got a reponse  from some other server which is capable of
allocating IP  addresses,  but, not having one or few other  parameters.
For getting those remaining parameters, it can contact this server.

>    Open issue; generate list of options based on previous work

We have some extensions defined in DHCPv6 extension draft -12th version.
Can we bring some of the valid extensions from there to here as options?
(DNS server  address was brought  inside this draft already) This has to
be done, because, at present DHCPv6 support very few options only.

I have  previously  sent a mail about  changing the format of ORO option
(refer my mail on 7/19/01) to include  parameter  number and putting the
index for those parameters.

We need to include this.

>    source from IP header (whether agent or client).

But, we cannot say that, the source  address  will always be a linklocal
address.  If the  client  sends  the  request  with  one of the  address
allocated  by the  server,  as source  address,  and after  sending  the
request,  the address has expired, so the client  deletes it, then, what
will be the  behaviour  for the  reply?  how does the reply  arrive  the
client?  Do we need to include the text  something  like  "client  while
sending  the  packet to  agents/server,  they MUST  have to put the link
local address as the From address".

~vijay