Subject: Notes from DHCPv6 discussion at WG meeting

From: Ralph Droms <[email-masked]>
Date: Thu, 09 Aug 2001 09:44:44 +0100

Here are my raw notes from the DHC WG discussion on DHCPv6.  Those of you 
who were at the discussion will recognize these notes as the notes I was 
editing in real time during the discussion.

One major result of the discussion is that Ted Lemon, Mark Stapp and Bernie 
Volz have volunteered to redesign the IA option format and document that 
design with draft-ready text by 8/24.  Because of that effort, several 
related issues have been deferred for resolution in the Lemon-Stapp-Volz IA 
design or after the design has been submitted.

- Ralph

-----
* Mark Stapp suggests a number of problems have arisen because of "C
   struct"-like structure of IA option.  Mark suggests a solution like
   that used in failover: IP address marks a "frame", in which options
   specific to that address follow the IP address; IA option then marks
   start of a frame that carries options specific to the IA.

   WG consensus: Bernie, Mark and Ted will develop text defining new IA
   structure.  The draft text will be complete and submitted to the WG
   for review by 8/24.  WG will review and definition will be
   integrated into -20 draft if approved by WG.

* 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 - hold for new IA definition (WG has already agreed that
   client can ask for regular or temporary addresses)

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

   Open issue - hold for new IA definition

* 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: Mark, Ted and Bernie will do it...

   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.

   Notes: T1/T2 are independent of "regular"/"temporary"
   characteristic.  T1/T2 might even be used for clients that do not
   have any assigned addresses for periodic renewal of other
   information

* 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 Request containing a new IA?

   Open issue: rules about when to reuse old IA or use new IA
   WG consensus: When the client submits an IA that the server has seen
   in the past, the server should interpret the request as a request
   for the current state of the existing IA.  When the client submits
   an IA that the server has not seen before, the server should
   interpret the request as a request for additional addresses to be
   assigned to the new IA.

   Discussion to continue on WG mailing list

* 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: Wait for Bernie to fix in IA definition

* 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; should allow inclusion of text message

* 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: Discussion to be taken to mailing list
   Note: check to make sure there is text in the draft describing
   behavior if no response is heard to a Confirm

* 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

   WG consensus: no; this is an overspecification

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

   WG consensus: Server should be allowed to respond

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

   WG consensus: anything we have consensus on stays; anything else
   gets punted to a separate draft.

* Add 'secs' field to fixed header

   WG consensus: if client retransmits, MUST send option called
   "milliseconds"

* Make the preference field an option

   WG consensus: yes

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

   WG consensus: yes

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

   WG consensus: yes, authors to fix spec

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

   WG consensus: Yes