Telechat Review of draft-ietf-dhc-rfc8415bis-09
review-ietf-dhc-rfc8415bis-09-opsdir-telechat-chown-2025-04-15-00

Hi,

I have reviewed this document as part of the Operational directorate's ongoing
effort to review all IETF documents being processed by the IESG. These comments
were written with the intent of improving the operational aspects of the IETF
drafts. Comments that are not addressed in last call may be included in AD
reviews during the IESG review.  Document editors and WG chairs should treat
these comments just like any other last call comments.

The draft updates DHCPv6 (RFC 8415).  It's long :)

I believe the draft state is Ready with Nits.

General comments:

Is there any need to keep the references to IA_TA in the document? There could
just be a note in the introduction that it was removed and then make no mention
of it through the rest of the document.  It doesn’t even need to be in the
terminology.

There is inconsistency between sections 16 and 18 on validation and the
definitions, e.g., in 16.2 and 18.2.1. There’s quite a few like this - is
section 16 really needed?  Either update it if keeping it or just remove?

The document could better clarify the use of IA/PD and requesting other
configuration information. In some places it’s implied doing one means you
don’t do the other, but my understanding is as per 18.2.2 and 18.3.2 that a
client and server can include IA and other configuration information in a
Request and Reply.

There are a few places where it’s implied that reconfigure messages are not
authenticated, or at least the text makes no mention of it, but 18.3.11 is very
clear about the requirement - that should be stated earlier.

Likewise the difference between the use of RENEW/T1 and REBIND/T2 could be made
clearer early on.

There are quite a few examples of important principles that are somewhat
"buried" in the document but could be emphasised perhaps in a separate early
section.

There’s a lot of implied MUSTs; the writing style needs to be consistent,
currently it is not.  I have reported many of them below but probably missed a
few given the size of this document.

It would be handy to have a list of the specific state that a client and a
server may maintain; this could also help reinforce the security text on
attacks on state.

What of the new RFCs published since this -bis was worked on?  I see the latest
reference is RFC 9096 but it would seem good to include pointers to RFC 9243
and RFC 9686 in this document.

The omission of RFC 9243 does highlight there’s nothing in the document about
management of DHCPv6 servers, relays or clients.  Perhaps a short section could
be added that points to this RFC?

RFC 9686 could perhaps be a model of use for DHCPv6 for section 6?  You can use
this self-registration scheme without using DHCPv6 to provide addresses or
prefixes.

There is also the very good work on a “prefix per host” using DHCP-PD for hosts
- we should include a pointer to RFC 9663 here and cite it?  Perhaps in Section
6 on operational models?

Git issues and errata:

There are 3 open issues in the tracker at
https://github.com/dhcwg/rfc8415bis/issues, two of which seem important.  On
the third, I do note that section 16 is not consistent with section 18 and we
could argue to just remove it - if not it does need to be consistent.

On the RFC8415 errata at https://www.rfc-editor.org/errata_search.php?rfc=8415,
the first one has been corrected, the second one seems to be covered by Section
18.4 (which says a server SHOULD NOT accept unicast traffic - it would have
been nicer maybe to make that a MUST though?) and the third no irrelevant with
there being no IA_TA now. So the errata look to be covered.

Specific comments:

Section 1

Para 3, delete “using DHCPv6”.

Citing RFC7084 - is there anything in draft-winters-v6ops-rfc7084bis-03 we need
to consider in this document?  I had a quick scan and couldn’t see anything,
but TimW as an author of both docs may wish to double check.

Para 4 - “much smaller” - not sure “smaller” is the right word.

Section 1.2

Maybe note here that DHCPv4 is needed to run IPv6-Mostly as per
draft-ietf-v6ops-6mops, which I think is nailed on to be an RFC before long.

Section 3

Maybe add a 4th RFC to the list to read - RFC8504? (not that I’m biased, but it
is a good reference :)

Section 5

Para 1 - insert “source” to read “link-local source address”

Section 6.2

Para 2 - is that “allocate” or “assign”?  It’s presumably for use, and later
on, e.g., in 18.2.6 we say “assign”.

Para 3 - I don’t think preferred or valid lifetimes have been defined or cited
before this point.  I see it explained in 12.1 via a pointer to RFC 4862, but
that’s way after this first use.

Section 6.3

Para 3 - might need updating now RFC 9663 exists?

Section 6.5

Can we point to RFC 7934 here as extra rationale for multiple addresses /
prefixes being provided?

Section 15

It talks of RAND for RT here being -0.1 to 0.1, but later in 18.2.1 it says the
first RT must have RAND > 0.  Maybe sync these bits more clearly?

Section 16

As above, do we really need this section?  If so it needs to be 100% consistent
with the later definitions in Section 18 and possibly elsewhere.

An example is the Elapsed Time Option, referred to in many places in Section
18, e.g., in 18.2.1, that’s not mentioned in section 16.

Section 16.3

Another example of inconsistency. Says discard if no IA_NA or IA_PD and MUST do
SOL_MAX_RT and INF_MAX_RT in 18.2.9 - but not mentioned here.

Section 16.8

Another example - section 18.2.8 says and no PD.

Section 16.10

Why the text on “if the client did not include a Client Identifier” when 18.2.2
says it MUST include one?  Should it then not discard the request?

Section 16.11

Authentication is mentioned here, but to date in the document nothing has said
this is required - that is only said later in Section 18.3.11.

Figure 9

Perhaps add where client and server identifier options are added.

Section 18.2

Para 4 - “they may be faked” - but isn’t authentication required?

Section 18.2.4

“The client includes an Option Request option” is an example of where we should
be consistent in language and say “The client MUST include an Option Request
option”.  This happens in many sections.  In 18.2.2 it is a MUST for the same
option, here it isn’t.

Section 18.2.6

Para 1 - maybe say “without using DHPCv6 to request addresses or prefixes”?

Para 6 - another example of an implied MUST… “the client MUST include”.  Also
here section 16.12 says the DUIDs MUST match but I don’t see that stated here?

Section 18.2.7

Para 3 - another implied MUST

Section 18.2.8

Para 1 - or by itself? Possible?

Para 4 - implied MUST.

Section 18.2.10

Para 6 here is a really important principle about what to do if a subsequent
Reply omits something included in a previous Reply.  This should be stated
clearly earlier?

Section 18.2.10.1

Another important principle in here about what a client must do when restarting
the server discovery process.

Section 18.2.11

No mention of the requirement to authenticate the message?

Section 18.2.12

Para 3 - “The client includes” - implied MUST

Section 18.3.2

So is RKAP weak?  If so should this be mentioned in the Security section?

Section 18.3.6

Last para - is that really desirable behaviour?

Section 18.3.7

Last para - “A server MAY” ?
(This is also another useful bit of information mentioned only here)

Section 18.3.8

Para 2- so would a LOT of such declines be a DoS attack on the server?

Section 18.3.9

Para 1 - implied MUST - “The server MUST include”

Section 18.3.11

This is the first place Reconfigure authentication is stated as required -
could be earlier?

Para 6 - what “information” is this?  Might we have a section on the state a
server can hold about clients?  (and a client state list would be of interest
too)

Section 19

Could be handy to have RFC 6939 mentioned in here?

Section 19.3

Any MTU issues here, or is the message always small even with the extra options
chained this way?

Section 19.4

Just curious, why is RKAP just defined for Reconfigure?

Section 22

“third parts” -> “third party”

Section 23

This is quite meandering over topics - can we get 3 or 4 subsections with the
key issues and the text for these into those subsections?

Appendix A

Somehow I feel these aren’t all the changes?

Appendix B

“informational” and may differ to the main text - still worth keeping?

Time for some sleep.

Best wishes,
Tim