[dhcwg] Rev of DHCPv6 spec

[Ralph Droms <[e-mail]>]

I've finished another rev of the DHCPv6 spec (-20d), which is available at 
http://www.dhcp.org/dhcpv6.tty  I plan to submit this draft of the spec to 
the IETF for publication on 10/12.  The list of issues addressed by this 
draft is included below; these issues were discussed at the DHC WG meeting 
in London (8/2001).  The -20d draft does not include any changes related to 
IAs.  The changes related to IAs will appear in the next published rev of 
the draft.

- Ralph

=====
Issues from London addressed in this draft.

* 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

* 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

* 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

   MODIFICATION: drop IMSI, IMEI

* 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

   FOLLOWUP:  Issue was not posted to mailing list.  Draft now defines
   Confirm to be simple ACK/NAK.

* 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



_______________________________________________
dhcwg mailing list
[e-mail]
http://www1.ietf.org/mailman/listinfo/dhcwg