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