Subject: -16 rev of DHCPv6 spec; design team teleconference

From: Ralph Droms <[email-masked]>
Date: Thu, 23 Nov 2000 21:06:32 -0500

I've published the -16 rev of the DHCPv6 spec later today.  The changes to 
this document are based primarily on the results of the design team 
teleconference of 8/31 and subsequent WG mailing list discussion.  I've 
included a summary of changes at the end of this message.

I am planning another design team teleconference for 12/5, 12noon-3PM 
EST.  The purpose for this teleconference is to discuss the changes in the 
-16 rev, with the goal of identifying and resolving as many outstanding 
issues as possible.  The results of the teleconference will be reported at 
the WG meeting in San Diego.  Any unresolved issues from the teleconference 
will be discussed during the WG meeting.

Cisco Systems is happy to host the design team teleconference
in Chelmsford, MA.  In  addition to a conference room in Chelmsford,
we will have conference call capability to accommodate those who
can't attend in person. and will be happy to reimburse those outside
the U.S. for their calls.

If you want to participate in the call on 12/5, please contact me for the
phone number and conference ID.  More details will follow next week.

- Ralph

PS If you're just *dying* to get a copy of the -16 rev, try 
ftp://ftp.eg.bucknell.edu/pub/draft-ietf-dhc-dhcpv6-16.txt

=====

23. Changes in this draft

    This section describes the changes between this version of the DHCPv6
    specification and draft-ietf-dhc-dhcpv6-15.txt.

23.1. Order of sections

    New sections have been added at the end of this document to minimize
    changes in section numbering.  Those sections will be rearranged in a
    future revision.

23.2. Reconfigure message

    DHCP Reconfigure and Reconfigure-reply messages and the associated
    mechanisms have been removed from this draft of the specification.

23.3. Releasable resources

    ``Releasable resources'' have been removed from this draft.

23.4. DHCP message header

    A common fixed DHCP message header has been defined.  Not all fields
    are used in all messages.

23.5. Design goals

    The second sentence in the 8th design goal bullet has been removed.

23.6. Overview

    Section 8.2 (DHCP agents) has been removed.  DHCP clients no longer
    need to know about specific DHCP agents.

    Section 8.3 has been modified to reflect the new encapsulating
    mechanism through which relays forward client messages to servers.

    Section 8.6 and 8.7 have been modified to describe ``identity
    associations''.

    Section 8.8 has been modified to reflect the deletion of
    ``reconfigure'' and ``reconfigure-reply'' messages.

23.7. Message formats, 9

    Message formats have been changed.  All messages share a common fixed
    message header followed by options.

23.8. Solicit and Advertise messages, (section 10)

    The description of the message exchanges have been changed to
    reflect:

     -  New relay behavior - encapsulated client messages
     -  Use of IAs

23.9. Prefix advertisement

    Servers no longer advertise prefixes.

23.10. Identity Associations

    Section 9.11 describes IAs in detail.  A definition of ``IA'' has
    been added to section 2.  The description of messages exchanges
    have been extended to include IAs.  The IA option is defined in
    section 22.2

23.11. Extensions renamed options; defined in this document

    ``extensions'' are now called ``options''; the options referenced in
    this document are defined in section 22.

23.12. Transaction-ID ranges

    Solicit, Advertise, Request, Reply, Release and Reconfigure-init
    messages all use an unsigned 16-bit integer ``Transaction-ID''.
    Transaction-IDs generated by clients are considered to be chosen from
    a different namespace than those chosen by servers.  There is no
    need to restrict clients and servers to select Transaction-IDs from
    specific ranges to avoid conflicts.

23.13. Release messages and relays

    Release/Reply messages are forwarded through relays.  This mechanism
    eliminates the need for an 'R' bit.

23.14. Discovering relay agents

    Clients no longer learn the identity of relay agents.  When the
    client only has a link-local address (e.g., the client has no
    assigned addresses), it now multicasts Request message, which is then
    forwarded by a relay agent on the same link.

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 28 Nov 2000 10:12:55 -0800 (PST)

Ralph,

I hope I can attend the telecon. Can you send me the phone number etc.

Thanks,
   Erik