Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
draft-ietf-dhc-rfc8415bis-12

Received changes through RFC Editor sync (changed state to RFC, created became rfc relationship between draft-ietf-dhc-rfc8415bis and RFC 9915, changed IESG state to RFC Published)

[Ballot comment]
Hi Tomek, Bernie, Michael, Sheng, and Tim,

Thank you for taking care of the DISCUSS and COMMENTs points in [1]. I also appreciate the detailed reply to Tim’s comprehensive review [2]. I was waiting for a follow-up from Tim before updating by ballot. I will leave it to Éric if he can hold publication for some few days. Thanks.

I checked diff 09/10. I really like the changes. FWIW, some minor “things” I sport when reviewing the changes:

# Section 1.3: More accurate scope of 9243

OLD: One possible way to manage a DHCPv6 server is proposed in [RFC9243]

NEW: An approach to manage DHCPv6 relays and servers is specified  in [RFC9243]

# Section 5

## ALL_DHCP_Relay_Agents_and_Servers

Consider changing it to All_DHCP_Relay_Agents_and_Servers :-)

## Naturally inherit whatever updates will be made to RFC8085

OLD: and BCP 145 [RFC8085]

NEW: and [BCP145]

## Help readers find where DHCP multicast addresses are defined

For example, consider the following change:

OLD: All_DHCP_Relay_Agents_and_Servers multicast address

NEW: All_DHCP_Relay_Agents_and_Servers multicast address (Section 7.1)

# Section 6.5: nit

OLD: To meet the recommendations of [RFC7934], A client

NEW: To meet the recommendations of [RFC7934], a client

# Section 6.6

## nit

OLD: [RFC9686] introduced a method

NEW: [RFC9686] introduces a method

## minor edit

OLD: The major difference between other use cases and this is

NEW: The major specificity of this mechanism is

# Section 18.2.6: Use the correct option name

OLD: The relay SHOULD insert a Client Link-Layer option

NEW: The relay SHOULD insert a Client Link-Layer Address option

Thank you again for your effort on the maintenance of this important piece.

Cheers,
Med

[1] https://mailarchive.ietf.org/arch/msg/dhcwg/j7I13uN9pjlSnCoT3Q3_htz7YCo/

[2] https://mailarchive.ietf.org/arch/msg/dhcwg/mcUhzp1lh_icTH6fW4F9yqeuGWA/

[Ballot comment]
Excellent work, and glad to see this moving to IS. A few minor comments that might be incorporated at the discretion of the authors and the responsible AD:

1.1: RFCs are immutable; "For a complete list of changes made to [RFC8415] see Appendix A." => "For a complete list of differences from [RFC8415], see Appendix A."

7.6: "This table of values used to describe the message transmission behavior of clients and servers." => "This table of values is used to describe the message transmission behavior of clients and servers." (Otherwise it invites the question what it describes now!)

[Ballot comment]
Thanks to the authors and the WG for their work on this document for getting DHCPv6 to Internet Standard.

I've focused on the changes from RFC8415. However, instead of looking at only the diff between the two, I've looked at what other (non-technical) changes that are required have been made. Since this document is going to specify an Internet Standard, its bar should be higher. Please consider all of my comments below with the spirit of making this document crisp and current with the objective of helping a someone new implement DHCPv6 from scratch.

All the comments below have been provided inline in the idnits output of v09 of the document. If you do not see the  at the end of the email, please check the mailer archive since certain email clients are known to truncate reviews.


17 Abstract

19   This document describes the Dynamic Host Configuration Protocol for
20   IPv6 (DHCPv6): an extensible mechanism for configuring nodes with

perhaps ... s/describes/specifies ?


274 1.1.  Relationship to Previous DHCPv6 Standards

276   The initial specification of DHCPv6 was defined in [RFC3315], and a
277   number of follow-up documents were published over the years:

I see that this document is trying to carry forward history prior
to RFC8415 about DHCPv6 specifications. I find this concerning since it asks
the reader to go back to those old and obsoleted documents when reading this
brand new RFC. My concern is that it has the potential to at worst confuse and
at best waste time of someone trying to implement DHCPv6 afresh. Especially,
given that this is moving to Internet Standard, I would like to discuss if
there are any problems in removing all references to the obsoleted documents
other than RFC8415 itself.

The reader could be pointed to RFC8415 section 1.1 for history (just as done
for IA_TA).


311 1.2.  Relationship to DHCPv4

313   The operational models and relevant configuration information for
314   DHCPv4 [RFC2131] [RFC2132] and DHCPv6 are sufficiently different that
315   integration between the two services is not included in this
316   document.  [RFC3315] suggested that future work might be to extend
317   DHCPv6 to carry IPv4 address and configuration information.  However,
318   the current consensus of the IETF is that DHCPv4 should be used
319   rather than DHCPv6 when conveying IPv4 configuration information to

The above text may be harmful to new implementations of DHCPv6. If the
WG has taken the decision to not use it for IPv4, then isn't now the
time to clarify this aspect before this moves to Internet Standard? If I were
implementing DHCPv6 currently, would I design and write code expecting that at
some point, my implementation would need to support IPv4 as well? Or, can
the spec provide definitive clarity to implementors on such aspects and not
carry forward these uncertainties?


324   Merging DHCPv4 and DHCPv6 configuration is out of scope for this
325   document.  [RFC4477] discusses some issues and possible strategies

Is this important consideration not yet settled by the WG? If it is
then suggest clarifying. If it is not then does it impact maturity level to
move to Internet Standard?

326   for running DHCPv4 and DHCPv6 services together.  While [RFC4477] is
327   a bit dated, it provides a good overview of the issues at hand.


683   A DHCP client sends messages using a reserved, link-scoped multicast
684   destination address (ALL_DHCP_Relay_Agenda_and_service - ff02::1:2)

How about s/client sends messages/client sends all messages/ ... to
better express the change and its intent?


793 6.1.  Stateless DHCP

795   Stateless DHCP [RFC3736] can be used at any time, typically when a
796   node requires some missing or expired configuration information that
797   is available via DHCP.

RFC8415 obsoleted RFC3736. This document obsoletes RFC8415. Why do we
still need to reference RFC3736 for this term. Perhaps we should have a forward
reference to section 6.1 of this document instead? Please see similar comments
for a few other references to obsoleted RFCs.


836 6.3.  DHCP for Prefix Delegation

838   The prefix delegation mechanism, originally described in [RFC3633],

Isn't the reference to RFC3633 that has been obsoleted to the 2nd
degree avoidable?


948   A client that has delegated any of the address space received through
949   DHCP Prefix Delegation MUST NOT issue a DHCP Release on the relevant
950   delegated prefix while any of the address space is outstanding.
951   [RFC9096] section WPD-9 makes this Best Current Practice.  That

I didn't find a section WPD-9 in RFC9096. Is it section 3.1? If so,
please rephrase. If still using WPD-9, please expand that acronym.


1009 7.1.  Multicast Addresses

1011   [RFC3315] registered the following multicast addresses, and this
1012   specification is now authoritative for:

The reference to RFC3315 is outdated and incorrect. The IANA registry
points to RFC8415. What does it mean "now authoritative for"? That was perhaps
appropriate for RFC8415, but seems very odd for this document.


1029 7.2.  UDP Ports

1031   Clients listen for DHCP messages on UDP port 546.  Servers and relay
1032   agents listen for DHCP messages on UDP port 547.

1034   Clients, servers, and relay agents MAY send DHCP messages from any
1035   UDP (source) port they are allowed to use, including their designated
1036   destination ports.  Nevertheless, regardless of the source port used,
1037   DHCP messages MUST be sent to ports specified above (e.g., clients
1038   sending to port 547).

Suggest rephrasing for clarity.

SUGGEST
  Clients listen for DHCP messages on UDP port 546.  Servers and relay
  agents listen for DHCP messages on UDP port 547. These designated
          destination ports MUST be used for sending DHCP messages (e.g.,
          clients sending to port 547).

  Clients, servers, and relay agents MAY send DHCP messages from any
  UDP (source) port they are allowed to use, including their designated
  destination ports.


1950   Clients, relay agents, and servers MUST NOT discard messages that
1951   contain unknown options (or instances of vendor options with unknown
1952   enterprise-number values).  These options should be ignored as if
1953   they were not present.  This is critical to provide for future
1954   extensions of DHCP.

There was a text blob here in RFC8415 that used normative MUST to
discard certain unicast messages. That has been removed. Is that really
appropriate? Was this text wrong? I am not a DHCP expert, but this seems like
going beyond the stated desire to remove the Server Unicast Option?


1956   A client or server MUST discard any received DHCP messages with an
1957   unknown message type.


2316 18.1.  A Single Exchange for Multiple IA Options

2318   This document assumes that a client SHOULD use a single transaction
2319   for all of the IA options required on an interface; this simplifies
2320   the client implementation and reduces the potential number of
2321   transactions required (for the background on this design choice,
2322   refer to Section 4 of [RFC7550]).  To facilitate a client's use of a

Isn't the reference to RFC7550 that has been obsoleted to the 2nd
degree avoidable?



3319   When a client receives a Reconfigure message from the server, the
3320   client initiates sending a Renew, Rebind, or Information-request
3321   message as indicated by msg-type in the Reconfigure Message option
3322   (see Section 21.19).  The server sends IAs and/or other configuration
3323   information to the client in a Reply message.  The server MAY include
3324   options containing the IAs and new values for other configuration
3325   parameters in the Reply message, even if those IAs and parameters
3326   were not requested in the client's message.

Since the text blobs related to use of unicast in each of the
following sub-sections have been removed, perhaps we need something here to
indicate that the handling of unicast messages for all these messages is
covered in section 18.4 ?



3933 19.1.  Relaying a Client Message or a Relay-forward Message

3935   A relay agent relays both messages from clients and Relay-forward
3936   messages from other relay agents.  When a relay agent receives a
3937   Relay-forward message, a recognized message type for which it is not
3938   the intended target, or an unrecognized message type [RFC7283], it

Isn't the reference to RFC7283 that has been obsoleted to the 2nd
degree avoidable?


4790 21.11.  Authentication Option

4792   The Authentication option carries authentication information to
4793   authenticate the identity and contents of DHCP messages.  The use of
4794   the Authentication option is described in Section 20.  The delayed
4795   authentication protocol, defined in [RFC3315], was obsoleted by
4796   [RFC8415].  The format of the Authentication option is:

If this is something that was already obsoleted by RFC8415, why is it
even present in this document?



6092   [RFC8415]  Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A.,
6093               Richardson, M., Jiang, S., Lemon, T., and T. Winters,
6094               "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)",
6095               RFC 8415, DOI 10.17487/RFC8415, November 2018,
6096               .

RFC8415 should be an informative reference since it is being obsoleted by this document.

6098 26.2.  Informative References

[Ballot comment]
# Internet AD comments for draft-ietf-dhc-rfc8415bis-09
CC @ekline

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* "Handling Ballot Positions":
  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/

## Nits

### S5

* "s/ALL_DHCP_Relay_Agenda_and_service/All_DHCP_Relay_Agents_and_Servers/"

  agenda -> agents
  service -> servers

  based on IANA's "IPv6 Multicast Address Space Registry", and also elsewhere
  in this document.

[Ballot comment]
Thank you to Dale R. Worley for the GENART review.

** Section 25. 
  IANA is requested to mark the IA_TA (option code 4) and UNICAST
  (option code 12) in the Option Codes table at
    as obsolete.

  IANA is requested to mark the UseMulticast (status code 5) in the
  Status Codes table at  as obsolete.

How does one mark something as obsolete in a registry which does not have an explicit status column?

[Ballot discuss]
Hi Tomek, Bernie, Michael, Sheng, and Tim,

Thank you for the effort put into this important piece of work. I will be definitely balloting "YES".

Thanks to Tim Chown for his outstanding OPSDIR review. I appreciate that the authors already engaged to address the review. I hear the arguments made by the authors for the proposal to cite some recent specs. I'm monitoring that discussion and hope the right balance will be found given the intended IS status.

Till then, I borrow the main issue from Tom as a DICUSS point. I added an additional easy-to-fix DISCUSS point based on a review of the diff vs 8415.

# Consistency (raised by Tim)

"
I think there’s two main areas of concern.

One is the use of MUST in some places and not in others, for the same context, e.g., “the client MUST insert foo” vs “the client inserts foo”. That happens inconsistently e.g. in Section 18.

The other is the inconsistency in what’s said in Sections 16 and 18. I’d suggest someone (an author) goes through them both and checks in detail.  One way to simplify it would be to just remove section 16, much like the last Appendix where there might (but I didn’t check) also be inconsistencies.  But that validation information being spelled out from the spec in Section 18 is useful.

It’s also clear that the spec has evolved over time so the document has a somewhat “patchwork” feel to it.  The way Reconfigure authentication is introduced (or rather isn’t) and then very ambiguous up until it’s spelled out in Section 18 is a good example.  So it depends if you, or the IESG, care about that.

The other points in my review I made because they seemed odd to me, or confusing.  If you’ve been working to that spec since it was 3315 I suspect you wouldn’t feel that way.
"

# RFC8415 is not normative

Please move RFC8415 to be listed as Informative. That one will be obsoleted.

[Ballot comment]
# Section 1

OLD:
  DHCPv6 also provides a mechanism for automated delegation of IPv6
  prefixes using DHCPv6. 

NEW:
  DHCPv6 also supports a mechanism for automated delegation of IPv6
  prefixes. 

# Section 4.2

OLD:
  IA_TA                    Identity Association for Temporary
                            Addresses: an IA that carries temporary
                            addresses (see [RFC8981]).  This option is
                            obsolete.

NEW:
  IA_TA                    Identity Association for Temporary
                            Addresses: an IA that carries temporary
                            addresses (see [RFC8981]). This option is
                            obsoleted by this document.

# Section 7.2

CURRENT:
  Clients, servers, and relay agents MAY send DHCP messages from any
  UDP (source) port they are allowed to use, including their designated
  destination ports.  Nevertheless, regardless of the source port used,
  DHCP messages MUST be sent to ports specified above (e.g., clients
  sending to port 547).

What is meant by "designated destination ports"? What is a "designated destination port" for a server?

Please reword.

The same wording is used in other parts of the spec. Please update those as well. Thanks.

# Section 21.5

OLD:
  The Identity Association for Temporary Addresses (IA_TA) option is
  obsolete. 

NEW:
  The Identity Association for Temporary Addresses (IA_TA) option is
  obsoleted. 

# Section 21.7

CURRENT:
  A client MUST include an Option Request option in a Solicit, Request,
  Renew, Rebind, or Information-request message to inform the server
  about options the client wants the server to send to the client.  For
  certain message types, some option codes MUST be included in the
  Option Request option; see [IANA-OPTION-DETAILS] for details.

Glad to see that the table was replaced with the pointer to the IANA registry. Can we add a sentence to say that registry is the authoritative reference for the up-to-date options?

# Section 22: Implementation Status

If this is not done yet, please consider having the implem details in a public page (wiki) and add the link as "related_implementations" under "Additional resources" in the datatracker.

[Ballot comment]
Thank you for this update, I am pleased that DHC has completed this important work.
I have reviewed the latest .bis relative to RFC 8415, and I am happy to see this standard progress to IS!

[Ballot comment]
***RFC 8415 was a proposed standard, this -bis document elevates DHCPv6 to Internet Standard by clarifying the text and removing unused/unimplemented features, i.e., it is suggested that the IESG only review the diffs with RFC 8415, i.e., https://author-tools.ietf.org/iddiff?url1=rfc8415&url2=draft-ietf-dhc-rfc8415bis-08&difftype=--html See also section 2.2 of RFC 6410 ***

The following Last Call announcement was sent out (ends 2025-01-13):

From: The IESG
To: IETF-Announce
CC: dhc-chairs@ietf.org, dhcwg@ietf.org, draft-ietf-dhc-rfc8415bis@ietf.org, evyncke@cisco.com, sureshk@cisco.com
Reply-To: last-call@ietf.org
Sender:
Subject: Extended Last Call:  (Dynamic Host Configuration Protocol for IPv6 (DHCPv6)) to Internet Standard

Note: This Last Call was originally sent on 2024-12-12 with an end date
of 2024-12-26. This Last Call has been extended until 2025-01-13.

The IESG has received a request from the Dynamic Host Configuration WG (dhc)
to consider the following document: - 'Dynamic Host Configuration Protocol
for IPv6 (DHCPv6)'
  as Internet Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2025-01-13. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This document describes the Dynamic Host Configuration Protocol for
  IPv6 (DHCPv6): an extensible mechanism for configuring nodes with
  network configuration parameters, IP addresses, and prefixes.
  Parameters can be provided statelessly, or in combination with
  stateful assignment of one or more IPv6 addresses and/or IPv6
  prefixes.  DHCPv6 can operate either in place of or in addition to
  stateless address autoconfiguration (SLAAC).

  This document obsoletes RFC8415 to incorporate reported errata and to
  obsolete the assignment of temporary addresses (the IA_TA option) and
  the server unicast capability (the Server Unicast option and
  UseMulticast status code).




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-dhc-rfc8415bis/



No IPR declarations have been submitted directly on this I-D.


The document contains these normative downward references.
See RFC 3967 for additional information:
    rfc4861: Neighbor Discovery for IP version 6 (IPv6) (Draft Standard - Internet Engineering Task Force (IETF) stream)
    rfc4862: IPv6 Stateless Address Autoconfiguration (Draft Standard - Internet Engineering Task Force (IETF) stream)
    rfc6221: Lightweight DHCPv6 Relay Agent (Proposed Standard - Internet Engineering Task Force (IETF) stream)
    rfc6355: Definition of the UUID-Based DHCPv6 Unique Identifier (DUID-UUID) (Proposed Standard - Internet Engineering Task Force (IETF) stream)
    rfc8213: Security of Messages Exchanged between Servers and Relay Agents (Proposed Standard - Internet Engineering Task Force (IETF) stream)
    rfc8415: Dynamic Host Configuration Protocol for IPv6 (DHCPv6) (Proposed Standard - Internet Engineering Task Force (IETF) stream)

IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-dhc-rfc8415bis-07. If any part of this review is inaccurate, please let us know.

IANA understands that, upon approval of this document, there are three actions which we must complete.

First, in the following registries, the existing references to [RFC8415] will be changed to [ RFC-to-be ]:

https://www.iana.org/assignments/dhcpv6-parameters/
https://www.iana.org/assignments/auth-namespaces/
https://www.iana.org/assignments/bootp-dhcp-parameters/
https://www.iana.org/assignments/ipv6-multicast-addresses/
https://www.iana.org/assignments/service-names-port-numbers/

Second, in the Option Codes registry in the Dynamic Host Configuration Protocol for IPv6 (DHCPv6) registry group located at:

https://www.iana.org/assignments/dhcpv6-parameters/

the following option codes will be marked OBSOLETE:

Value: 4
Description: IA_TA
Client ORO: No
Singleton Option: No

Value: 12
Description: UNICAST
Client ORO: No
Singleton Option: Yes

Per the IANA action above, the references for these OBSOLETE option codes will be changed to [ RFC-to-be ].

Third, in the Status Codes registry also in the Dynamic Host Configuration Protocol for IPv6 (DHCPv6) registry group located at:

https://www.iana.org/assignments/dhcpv6-parameters/

the following status code will be marked OBSOLETE:

Code: 5
Name: UseMulticast

Per the IANA action above, the reference for this OBSOLETE status code will be changed to [ RFC-to-be ].

We understand that these are the only actions required to be completed upon approval of this document.

NOTE: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Sr. Specialist

The following Last Call announcement was sent out (ends 2024-12-26):

From: The IESG
To: IETF-Announce
CC: dhc-chairs@ietf.org, dhcwg@ietf.org, draft-ietf-dhc-rfc8415bis@ietf.org, evyncke@cisco.com, sureshk@cisco.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Dynamic Host Configuration Protocol for IPv6 (DHCPv6)) to Internet Standard


The IESG has received a request from the Dynamic Host Configuration WG (dhc)
to consider the following document: - 'Dynamic Host Configuration Protocol
for IPv6 (DHCPv6)'
  as Internet Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2024-12-26. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This document describes the Dynamic Host Configuration Protocol for
  IPv6 (DHCPv6): an extensible mechanism for configuring nodes with
  network configuration parameters, IP addresses, and prefixes.
  Parameters can be provided statelessly, or in combination with
  stateful assignment of one or more IPv6 addresses and/or IPv6
  prefixes.  DHCPv6 can operate either in place of or in addition to
  stateless address autoconfiguration (SLAAC).

  This document obsoletes RFC8415 to incorporate reported errata and to
  obsolete the assignment of temporary addresses (the IA_TA option) and
  the server unicast capability (the Server Unicast option and
  UseMulticast status code).




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-dhc-rfc8415bis/



No IPR declarations have been submitted directly on this I-D.


The document contains these normative downward references.
See RFC 3967 for additional information:
    rfc4861: Neighbor Discovery for IP version 6 (IPv6) (Draft Standard - Internet Engineering Task Force (IETF) stream)
    rfc4862: IPv6 Stateless Address Autoconfiguration (Draft Standard - Internet Engineering Task Force (IETF) stream)
    rfc6221: Lightweight DHCPv6 Relay Agent (Proposed Standard - Internet Engineering Task Force (IETF) stream)
    rfc6355: Definition of the UUID-Based DHCPv6 Unique Identifier (DUID-UUID) (Proposed Standard - Internet Engineering Task Force (IETF) stream)
    rfc8213: Security of Messages Exchanged between Servers and Relay Agents (Proposed Standard - Internet Engineering Task Force (IETF) stream)
    rfc8415: Dynamic Host Configuration Protocol for IPv6 (DHCPv6) (Proposed Standard - Internet Engineering Task Force (IETF) stream)

The following Last Call announcement was sent out (ends 2024-12-26):

From: The IESG
To: IETF-Announce
CC: dhc-chairs@ietf.org, dhcwg@ietf.org, draft-ietf-dhc-rfc8415bis@ietf.org, evyncke@cisco.com, sureshk@cisco.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Dynamic Host Configuration Protocol for IPv6 (DHCPv6)) to Internet Standard


The IESG has received a request from the Dynamic Host Configuration WG (dhc)
to consider the following document: - 'Dynamic Host Configuration Protocol
for IPv6 (DHCPv6)'
  as Internet Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2024-12-26. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This document describes the Dynamic Host Configuration Protocol for
  IPv6 (DHCPv6): an extensible mechanism for configuring nodes with
  network configuration parameters, IP addresses, and prefixes.
  Parameters can be provided statelessly, or in combination with
  stateful assignment of one or more IPv6 addresses and/or IPv6
  prefixes.  DHCPv6 can operate either in place of or in addition to
  stateless address autoconfiguration (SLAAC).

  This document obsoletes RFC8415 to incorporate reported errata and to
  obsolete the assignment of temporary addresses (the IA_TA option) and
  the server unicast capability (the Server Unicast option and
  UseMulticast status code).




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-dhc-rfc8415bis/



No IPR declarations have been submitted directly on this I-D.


The document contains these normative downward references.
See RFC 3967 for additional information:
    rfc4861: Neighbor Discovery for IP version 6 (IPv6) (Draft Standard - Internet Engineering Task Force (IETF) stream)
    rfc4862: IPv6 Stateless Address Autoconfiguration (Draft Standard - Internet Engineering Task Force (IETF) stream)
    rfc6221: Lightweight DHCPv6 Relay Agent (Proposed Standard - Internet Engineering Task Force (IETF) stream)
    rfc6355: Definition of the UUID-Based DHCPv6 Unique Identifier (DUID-UUID) (Proposed Standard - Internet Engineering Task Force (IETF) stream)
    rfc8213: Security of Messages Exchanged between Servers and Relay Agents (Proposed Standard - Internet Engineering Task Force (IETF) stream)
    rfc8415: Dynamic Host Configuration Protocol for IPv6 (DHCPv6) (Proposed Standard - Internet Engineering Task Force (IETF) stream)

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

Yes. There is strong consensus to progress this document that elevates the DHCPv6 specification to to an Internet Standard.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

No. There was some confusion about the IA Address option as to whether it was mandatory to be encapsulated inside an IA_NA as RFC8415 had some text with a lower case "must". After some investigation it was then clear that there was already a mechanism (DHCPv6 Leasequery[RFC5007]) that used IA Address outside IA_NA. This text has now been reworked to document this exception. There was some clarifying text regarding significant prefix changes that was required and this has also been added.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

No.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

There are numerous interoperable implementations on multiple platforms and they have been documented in an Implementation Status section (Section 22 of the draft)

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

This document contains minor clarifying changes and removal of less used features such as IA_TA and the server unicast capability from RFC8415, which has gone through the entire IETF process. I had performed a complete review of RFC8415 as the shepherding AD, and that of this draft as the Document Shepherd.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

N/A

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

N/A

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

N/A

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

Yes. I have reviewed the document and it is ready to progress to the responsible AD.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

None of the issues identified in the Internet Area affect this document.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Internet Standard. The original DHCPv6 protocol (RFC3315) was published, implemented and deployed over two decades ago. RFC8415 published in 2018 consolidated the base DHCPv6 protocol defined in RFC3315, and incorporated several key extensions, clarifications and errata. This draft meets the criteria to be elevated to Internet standard

a) There are multiple independent interoperating implementations with widespread deployment and successful operational experience.

b) There are no errata against the specification that would cause a new implementation to fail to interoperate with deployed ones.

c) The unused features in the specification that increased implementation complexity have been removed. The IA_TA option has been deprecated and has not been supported in the Kea DHCP Server [KEA] which is the most commonly used open source DHCPv6 server. The server unicast option was not widely deployed since most deployments that require DHCPv6 traffic to go through relays (e.g. Cable networks) would have issues if the messages were unicasted to the servers.

[KEA] https://kea.readthedocs.io/en/kea-2.2.0/arm/dhcp6-srv.html#supported-dhcpv6-standards

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Yes.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

Yes.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

There are no remaining ID-nits. The warnings and comments thrown up by idnits are spurious.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

No.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

No.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

No.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

No.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

Yes. This document will Obsolete RFC8415 and this is covered by the draft.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

There are a couple of options and a status code that have been obsoleted due to lack of use and this is reflected correctly in the IANA considerations section.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

N/A

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

Yes. There is strong consensus to progress this document that elevates the DHCPv6 specification to to an Internet Standard.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

No. There was some confusion about the IA Address option as to whether it was mandatory to be encapsulated inside an IA_NA as RFC8415 had some text with a lower case "must". After some investigation it was then clear that there was already a mechanism (DHCPv6 Leasequery[RFC5007]) that used IA Address outside IA_NA. This text has now been reworked to document this exception. There was some clarifying text regarding significant prefix changes that was required and this has also been added.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

No.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

There are numerous interoperable implementations on multiple platforms and they have been documented in an Implementation Status section (Section 22 of the draft)

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

This document contains minor clarifying changes and removal of less used features such as IA_TA and the server unicast capability from RFC8415, which has gone through the entire IETF process. I had performed a complete review of RFC8415 as the shepherding AD, and that of this draft as the Document Shepherd.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

N/A

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

N/A

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

N/A

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

Yes. I have reviewed the document and it is ready to progress to the responsible AD.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

None of the issues identified in the Internet Area affect this document.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Internet Standard. The original DHCPv6 protocol (RFC3315) was published, implemented and deployed over two decades ago. RFC8415 published in 2018 consolidated the base DHCPv6 protocol defined in RFC3315, and incorporated several key extensions, clarifications and errata. This draft meets the criteria to be elevated to Internet standard

a) There are multiple independent interoperating implementations with widespread deployment and successful operational experience.

b) There are no errata against the specification that would cause a new implementation to fail to interoperate with deployed ones.

c) The unused features in the specification that increased implementation complexity have been removed

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Yes.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

Yes.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

There are no remaining ID-nits. The warnings and comments thrown up by idnits are spurious.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

No.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

No.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

No.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

No.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

Yes. This document will Obsolete RFC8415 and this is covered by the draft.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

There are a couple of options and a status code that have been obsoleted due to lack of use and this is reflected correctly in the IANA considerations section.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

N/A

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

Yes. There is strong consensus to progress this document that elevates the DHCPv6 specification to to an Internet Standard.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

No. There was some confusion about the IA Address option as to whether it was mandatory to be encapsulated inside an IA_NA as RFC8415 had some text with a lower case "must". After some investigation it was then clear that there was already a mechanism (DHCPv6 Leasequery[RFC5007]) that used IA Address outside IA_NA. This text has now been reworked to document this exception. There was some clarifying text regarding significant prefix changes that was required and this has also been added.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

No.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

There are numerous interoperable implementations on multiple platforms and they have been documented in an Implementation Status section (Section 22 of the draft)

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

This document contains minor clarifying changes and removal of less used features such as IA_TA and the server unicast capability from RFC8415, which has gone through the entire IETF process. I had performed a complete review of RFC8415 as the shepherding AD, and that of this draft as the Document Shepherd.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

N/A

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

N/A

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

N/A

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

Yes. I have reviewed the document and it is ready to progress to the responsible AD.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

None of the issues identified in the Internet Area affect this document.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Internet Standard. The original DHCPv6 protocol (RFC3315) was published, implemented and deployed over two decades ago. RFC8415 published in 2018 consolidated the base DHCPv6 protocol defined in RFC3315, and incorporated several key extensions, clarifications and errata. This draft meets the criteria to be elevated to Internet standard

a) There are multiple independent interoperating implementations with widespread deployment and successful operational experience.

b) There are no errata against the specification that would cause a new implementation to fail to interoperate with deployed ones.

c) The unused features in the specification that increased implementation complexity have been removed

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Yes.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

Yes.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

There are no remaining ID-nits. The warnings and comments thrown up by idnits are spurious.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

No.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

No.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

No.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

No.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

Yes. This document will Obsolete RFC8415 and this is covered by the draft.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

There are a couple of options and a status code that have been obsoleted due to lack of use and this is reflected correctly in the IANA considerations section.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

N/A

Several comments on some minor issues have been posted to WG mailing that authors have been working on and revised -04 generated. One new open issue is confusion on udp ports.