Appendix A.  Summary of Changes

   This appendix provides a summary of the significant changes made to
   this updated DHCPv6 specification.

   1.   The Introduction (Section 1) was reorganized and updated.  In
        particular, the client/server message exchanges were moved into
        a new (and expanded) section on their own (see Section 5).

   2.   New sections were added to discuss the relationship to previous
        DHCPv6 documents and also to DHCPv4.

   3.   Sections 2 ("Requirements") and 3 ("Background") had very minor
        edits.

   4.   Section 4 ("Terminology") had minor edits.

   5.   Section 4.2 ("DHCP Terminology") was expanded to incorporate
        definitions from RFC 3633, add T1/T2 definitions, add
        definitions useful in describing combined address assignment and
        prefix delegation operations, and improve some existing
        definitions.

   6.   Section 5 ("Client/Server Exchanges") was added from material
        previously in Section 1 of RFC 3315 ("Introduction and
        Overview") and was expanded.

   7.   Section 6 ("Operational Models") is new.  It provides
        information on the kinds of DHCP clients and how they operate.

   8.   Section 7 ("DHCP Constants") was primarily updated to add
        constants from RFC 4242 and RFC 7083.  Note that the default
        HOP_COUNT_LIMIT value was reduced from 32 to 8.

   9.   Sections 8 ("Client/Server Message Formats"), 9 ("Relay Agent/
        Server Message Formats"), and 10 ("Representation and Use of
        Domain Names") had only very minor changes.

   10.  Section 11 ("DHCP Unique Identifier (DUID)") now discourages,
        rather than disallows, a server to parse the DUID; now includes
        some information on the DUID-UUID (RFC 6355); and had other
        minor edits.

   11.  Section 12 ("Identity Association") was expanded to better
        explain the concept and to also include prefix delegation.

   12.  Section 13 ("Assignment to an IA") incorporates material from
        two sections (11 and 12) of RFC 3315 and also includes a section
        on prefix delegation.

   13.  Section 14 ("Transmission of Messages by a Client") was expanded
        to include rate limiting by clients and how clients should
        handle T1 or T2 values of 0.

   14.  Section 15 ("Reliability of Client-Initiated Message Exchanges")
        was expanded to clarify that the Elapsed Time option must be
        updated in retransmitted messages and that a client is not
        required to listen for DHCP traffic for the entire
        retransmission period.

   15.  Section 16 ("Message Validation") had minor edits.

   16.  Section 17 ("Client Source Address and Interface Selection") was
        expanded to include prefix delegation.

   17.  Section 18 ("DHCP Configuration Exchanges") consolidates what
        used to be in the following sections in RFC 3315: "DHCP Server
        Solicitation" (Section 17), "DHCP Client-Initiated Configuration
        Exchange" (Section 18), and "DHCP Server-Initiated Configuration
        Exchange" (Section 19).  This material was reorganized and
        enhanced, and it incorporates prefix delegation from RFC 3633
        and other changes from RFC 4242, RFC 7083, and RFC 7550.  A few
        changes of note:

        A.  The Option Request option is no longer optional for some
            messages (Solicit and Information-request), as RFC 7083
            requires clients to request SOL_MAX_RT or INF_MAX_RT
            options.

        B.  The Reconfigure message should no longer contain
            IA_NA/IA_PD, ORO, or other options to indicate to the client
            what was reconfigured.  The client should request everything
            it needs in the response to the Reconfigure.

        C.  The lifetime and T1/T2 hints should not be sent by a client
            (it should send values of 0 in these fields), and any
            non-zero values should be ignored by the server.

        D.  Clarified that a server may return different addresses in
            the Reply than requested by a client in the Request message.
            Also clarified that a server must not include addresses that
            it will not assign.

        Also, Section 18.2.12 ("Refreshing Configuration Information")
        was added to indicate use cases for when a client should try to
        refresh network information.

   18.  Section 19 ("Relay Agent Behavior") incorporates RFC 7283 and
        had minor edits.  A new section, "Interaction between Relay
        Agents and Servers" (Section 19.4), was added.

   19.  Section 20 ("Authentication of DHCP Messages") includes
        significant changes: IPsec materials were mostly removed and
        replaced with a reference to RFC 8213, and the delayed
        authentication protocol has been obsoleted (see Section 25).
        Note that RKAP is still considered current.

   20.  Section 21 ("DHCP Options") was expanded to incorporate
        OPTION_IA_PD and OPTION_IAPREFIX from RFC 3633, the Information
        Refresh Time option (OPTION_INFORMATION_REFRESH_TIME) from
        RFC 4242, and the SOL_MAX_RT and INF_MAX_RT options from
        RFC 7083.  Some additional edits were made to clarify option
        handling, such as which options should not be in an Option
        Request option.

   21.  The security considerations (Section 22) were updated to expand
        the discussion of security threats and include material from the
        incorporated documents, primarily RFC 3633.

   22.  New privacy considerations were added (Section 23) to account
        for privacy issues.

   23.  Section 24 ("IANA Considerations") was rewritten to reflect the
        changes requested for this document, as other documents have
        already made the message, option, DUID, and status code
        assignments and this document does not add any new assignments.

   24.  Section 25 ("Obsoleted Mechanisms") is a new section that
        documents the mechanisms obsoleted by this specification.

   25.  Appendices B ("Appearance of Options in Message Types") and C
        ("Appearance of Options in the "options" Field of DHCP Options")
        were updated to reflect the incorporated options from RFC 3633,
        RFC 4242, and RFC 7083.

   26.  Where appropriate, informative references have been added to
        provide further background and guidance throughout the document
        (as can be noted by the vast increase in references).

   27.  Changes were made to incorporate the following errata for
        RFC 3315: Erratum IDs 294, 295, 1373, 1815, 2471, 2472, 2509,
        2928, 3577, 5450; RFC 3633: Erratum IDs 248, 2468, 2469, 2470,
        3736; and RFC 3736: Erratum ID 3796.  Note that Erratum ID 1880
        for RFC 3633 no longer applies, as servers (delegating routers)
        ignore received T1/T2 hints (see (C) in item 17 above).

   28.  General changes to other IPv6 specifications, such as removing
        the use of site-local unicast addresses and adding unique local
        addresses, were made to the document.

   29.  It should be noted that this document does not refer to all
        DHCPv6 functionality and specifications.  Readers of this
        specification should visit <https://www.iana.org/assignments/
        dhcpv6-parameters> and <https://datatracker.ietf.org/wg/dhc/> to
        learn of the RFCs that define DHCPv6 messages, options,
        status codes, and more.

Appendix B.  Appearance of Options in Message Types

   The following tables indicate with a "*" the options that are allowed
   in each DHCP message type.

   These tables are informational.  If they conflict with text earlier
   in this document, that text should be considered authoritative.

         Client Server IA_NA/                  Elap. Relay       Server
           ID     ID   IA_TA IA_PD  ORO   Pref Time   Msg. Auth. Unicast
 Solicit   *             *     *     *           *
 Advert.   *      *      *     *           *
 Request   *      *      *     *     *           *
 Confirm   *             *                       *
 Renew     *      *      *     *     *           *
 Rebind    *             *     *     *           *
 Decline   *      *      *     *                 *
 Release   *      *      *     *                 *
 Reply     *      *      *     *                             *     *
 Reconf.   *      *                                          *
 Inform.   * (see note)              *           *
 R-forw.                                               *
 R-repl.                                               *

   NOTE: The Server Identifier option (see Section 21.3) is only
   included in Information-request messages that are sent in response to
   a Reconfigure (see Section 18.2.6).

                                                                  Info
           Status  Rap. User  Vendor Vendor Inter. Recon. Recon. Refresh
            Code  Comm. Class Class  Spec.    ID    Msg.  Accept  Time
   Solicit          *     *     *      *                    *
   Advert.   *            *     *      *                    *
   Request                *     *      *                    *
   Confirm                *     *      *
   Renew                  *     *      *                    *
   Rebind                 *     *      *                    *
   Decline                *     *      *
   Release                *     *      *
   Reply     *      *     *     *      *                    *        *
   Reconf.                                           *
   Inform.                *     *      *                    *
   R-forw.                             *      *
   R-repl.                             *      *

           SOL_MAX_RT  INF_MAX_RT
   Solicit
   Advert.    *
   Request
   Confirm
   Renew
   Rebind
   Decline
   Release
   Reply      *           *
   Reconf.
   Inform.
   R-forw.
   R-repl.

Appendix C.  Appearance of Options in the "options" Field of DHCP
             Options

   The following table indicates with a "*" where options defined in
   this document can appear as top-level options or can be encapsulated
   in other options defined in this document.  Other RFCs may define
   additional situations where options defined in this document are
   encapsulated in other options.

   This table is informational.  If it conflicts with text earlier in
   this document, that text should be considered authoritative.

                   Top-    IA_NA/                        RELAY-  RELAY-
                   Level   IA_TA  IAADDR IA_PD  IAPREFIX FORW    REPL
   Client ID          *
   Server ID          *
   IA_NA/IA_TA        *
   IAADDR                     *
   IA_PD              *
   IAPREFIX                                 *
   ORO                *
   Preference         *
   Elapsed Time       *
   Relay Message                                            *       *
   Authentic.         *
   Server Uni.        *
   Status Code        *       *             *
   Rapid Comm.        *
   User Class         *
   Vendor Class       *
   Vendor Info.       *                                     *       *
   Interf. ID                                               *       *
   Reconf. MSG.       *
   Reconf. Accept     *
   Info Refresh Time  *
   SOL_MAX_RT         *
   INF_MAX_RT         *

   Notes: Options asterisked in the "Top-Level" column appear in the
   "options" field of client messages (see Section 8).  Options
   asterisked in the "RELAY-FORW" and "RELAY-REPL" columns appear in the
   "options" field of the Relay-forward and Relay-reply messages (see
   Section 9).

Acknowledgments

   This document is merely a refinement of earlier work by the authors
   of the following documents and would not be possible without their
   original work:

   -  RFC 3315 (Ralph Droms, Jim Bound, Bernie Volz, Ted Lemon, Charles
      Perkins, and Mike Carney)

   -  RFC 3633 (Ole Troan and Ralph Droms)

   -  RFC 3736 (Ralph Droms)

   -  RFC 4242 (Stig Venaas, Tim Chown, and Bernie Volz)

   -  RFC 7083 (Ralph Droms)

   -  RFC 7283 (Yong Cui, Qi Sun, and Ted Lemon)

   -  RFC 7550 (Ole Troan, Bernie Volz, and Marcin Siodelski)

   A number of additional people have contributed to identifying issues
   with RFC 3315 and RFC 3633 and proposed resolutions to these issues
   as reflected in this document (listed here in no particular order):
   Ole Troan, Robert Marks, Leaf Yeh, Michelle Cotton, Pablo Armando,
   John Brzozowski, Suresh Krishnan, Hideshi Enokihara, Alexandru
   Petrescu, Yukiyo Akisada, Tatuya Jinmei, Fred Templin, and Christian
   Huitema.

   We also thank the following, not otherwise acknowledged and in no
   particular order, for their review comments: Jeremy Reed, Francis
   Dupont, Lorenzo Colitti, Tianxiang Li, Ian Farrer, Yogendra Pal, Kim
   Kinnear, Shawn Routhier, Michayla Newcombe, Alissa Cooper, Allison
   Mankin, Adam Roach, Kyle Rose, Elwyn Davies, Eric Rescorla, Ben
   Campbell, Warren Kumari, and Kathleen Moriarty.

   Also, special thanks to Ralph Droms for answering many questions
   related to the original RFC 3315 and RFC 3633 work and for
   shepherding this document through the IETF process.

Authors' Addresses

   Tomek Mrugalski
   Internet Systems Consortium, Inc.
   950 Charter Street
   Redwood City, CA  94063
   United States of America

   Email: tomasz.mrugalski@gmail.com


   Marcin Siodelski
   Internet Systems Consortium, Inc.
   950 Charter Street
   Redwood City, CA  94063
   United States of America

   Email: msiodelski@gmail.com


   Bernie Volz
   Cisco Systems, Inc.
   1414 Massachusetts Ave.
   Boxborough, MA  01719
   United States of America

   Email: volz@cisco.com


   Andrew Yourtchenko
   Cisco Systems, Inc.
   De kleetlaan 6a
   Diegem  BRABANT 1831
   Belgium

   Email: ayourtch@cisco.com


   Michael C. Richardson
   Sandelman Software Works
   470 Dawson Avenue
   Ottawa, ON  K1Z 5V7
   Canada

   Email: mcr+ietf@sandelman.ca
   URI:   http://www.sandelman.ca/

   Sheng Jiang
   Huawei Technologies Co., Ltd
   Q14, Huawei Campus, No. 156 Beiqing Road
   Hai-Dian District, Beijing  100095
   China

   Email: jiangsheng@huawei.com


   Ted Lemon
   Nibbhaya Consulting
   P.O. Box 958
   Brattleboro, VT  05301-0958
   United States of America

   Email: mellon@fugue.com


   Timothy Winters
   University of New Hampshire, Interoperability Lab (UNH-IOL)
   Durham, NH
   United States of America

   Email: twinters@iol.unh.edu