Subject: List of issues for WG discussion, 8/8

From: Ralph Droms <[email-masked]>
Date: Tue, 07 Aug 2001 09:19:25 +0100

Here's a draft list of issues in the -19 rev of the DHCPv6 spec.  We
will review mailing list discussion of these issues and come to
consensus on resolution at the WG meeting on 8/8.  I will post a
message later today summarizing resolution for those
issues where consensus seems to exist.

- Ralph

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

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

* 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

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

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

* 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 at
   T1/T2 are fields in IA header and must be supplied by server

* 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?

* Add 'secs' field to fixed header

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

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

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

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

* Simplify release and decline simplified 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.

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

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

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

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

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

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

* Reply to Decline or Release should carry no options

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

* Use IPsec for secure agent/server communication

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