On 15.04.2025 18:53, Tim Chown via Datatracker wrote: > Document: draft-ietf-dhc-rfc8415bis > Title: Dynamic Host Configuration Protocol for IPv6 (DHCPv6) > Reviewer: Tim Chown > Review result: Has Nits > > 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. Hey Tim, Thanks a lot for reviewing and your very thorough comments. It took us a bit to dig through them. I think -10 introduced many changes that hopefully address most of your comments. We still have couple issues open and in several cases decided not to make changes. So I suppose the current status is "partially addressed", I guess? As Michael said in the other mail, we used issues and PRs in the github repo (https://github.com/dhcwg/rfc8415bis/issues, https://github.com/dhcwg/rfc8415bis/pulls). Extra details and background discussions are available for anyone interested. When referencing numbers below, the related issues can be looked up on github. > 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. The IA_TA appears 10 times in this I-D, every time with "deprecated" around it. Maybe that's too many, but it's definitely down from 8415, where it was mentioned 71 times. > 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? We were not sure what's the extent of changes we were mandated to do. This isn't a typical bis work. The original guidance we received was to obsolete two options, apply erratas and keep other changes to minimum. Removing whole major sections would probably be too much. My personal interpretation is that Section 16 defines basic validation and then Section 18 adds extra checks on top for specific cases. Anyway, some changes were made to Section 18. > 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. Your interpretation is correct. You can do IA only, PD only, or IA+PD. In any case, you can send multiple IAs and/or multiple PDs to get multiple addresses and/or prefixes. > 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. Added a note about it in Section 5.3. > Likewise the difference between the use of RENEW/T1 and REBIND/T2 could be made > clearer early on. This is explained briefly in 7.3: "[REBIND] this message is sent after a client receives no response to a Renew message." > 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. We tried to address > 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. Am afraid this ship has sailed two decades ago. I was not part of the discussion back when original 3315 was being defined. The comments I heard is that having the state machine with diagrams (as in RFC2131 for DHCPv4) was ultimately more harmful than useful. So how to handle internal state was left up to the implementers to decide. > 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. Added both: 9243 and 9686. > 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? Added section 1.3 that server policy and general configuration, ops and management are out of scope, with a pointer to 9243 being one proposal how to manage a server. > 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. Yes. Added. > 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? We didn't have clear consensus on this, but one voice was raised that referencing it in IS would somehow suggest the 9663 is part of the requirements. > 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. With the SHOULD NOT/MUST NOT choice, the problem is what to do with legacy implementations. As a server implementer, I'd like to keep maximize interoperability with older implementations. > Specific comments: > > Section 1 > > Para 3, delete “using DHCPv6”. Removed. > 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. Referencing an I-D in an RFC, especially one seeking the Internet Standard level, would be a major problem. I can't speak for Tim, but he was part of many of the discussions and I think didn't add anything 7084bis specific. > Para 4 - “much smaller” - not sure “smaller” is the right word. Rephrased as "simpler". > 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. We discussed this and decided not to make any changes. The IPv6-mostly is an DHCPv4 option, so not directly applicable. As mentioned above, we can't reference I-Ds from Internet Standards RFC. > Section 3 > > Maybe add a 4th RFC to the list to read - RFC8504? (not that I’m biased, but it > is a good reference :) I'll defer answering this to Tim Winters, who was involved both in 8504 and 8415bis discussions. > Section 5 > > Para 1 - insert “source” to read “link-local source address” Added. > 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”. Updated to 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. Added forward reference to 12.1. > > Section 6.3 > > Para 3 - might need updating now RFC 9663 exists? See above. > Section 6.5 > > Can we point to RFC 7934 here as extra rationale for multiple addresses / > prefixes being provided? Added. > 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? We decided to keep the text as is, because the first Solicit message can't be delayed by a negative amount, while a Renew can be. > 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. See my answer above. > 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? Depends on what the message is being answered. Inf-request without client-id is allowed, but it's requires in all other messages sent from a client. > 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. Added note in 5.3. > Figure 9 > > Perhaps add where client and server identifier options are added. We discussed this proposal, but decided against it. This is already complex diagram and adding identifiers would make it less readable. Also, many other options that could possibly be added, so if we added one, someone could incorrectly assume that it's the only option being sent. > Section 18.2 > > Para 4 - “they may be faked” - but isn’t authentication required? It is, but let's just say it's the most bullet-proof mechanism ever. There's new subsection in the Security Considerations (23.3) dedicated to the RKAP and its limitations. Briefly, the reconfigure secret is sent in the open during first configuration. And before anyone ask to fix it, we tried. We really tried. There were too many conflicting opinions how to do it. If you want to know more, draft-ietf-dhc-sedhcpv6 was abandoned at -21 rev after 5 long years. See many discussions about it. > 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. We left the text as is. I missed the meeting when this was discussed, so can't say for other authors, but my take is that we should use minimum number of requirement keywords to get the protocol defined. In this and many similar cases, we would be repeating the same requirement in two places. The text says "send this option" and here's a pointer to text which makes it mandatory. This also applies to many similar comments below. > Section 18.2.6 > > Para 1 - maybe say “without using DHPCv6 to request addresses or prefixes”? Added "without requesting addresses and/or delegated prefixes to be assigned." > > 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? Not addressed yet. See #68. > Section 18.2.7 > > Para 3 - another implied MUST Not addressed yet. See #68. > Section 18.2.8 > > Para 1 - or by itself? Possible? A client can't send a Decline because it is already using the address. Are you thinking about a situation when two IA_NA options were sent and server assigned the same address to both? This would be a server error. Not sure if we should do anything about it. > > Para 4 - implied MUST. Not addressed yet. See #68. > 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? Not addressed yet. See #39. > Section 18.2.10.1 > > Another important principle in here about what a client must do when restarting > the server discovery process. Not addressed yet. See #40. > Section 18.2.11 > > No mention of the requirement to authenticate the message? Not addressed yet. See #67. > > Section 18.2.12 > > Para 3 - “The client includes” - implied MUST Not addressed yet. See #68. > Section 18.3.2 > > So is RKAP weak? If so should this be mentioned in the Security section? It is weak. The security sections was reshuffled a bit, and split to separate sections. One of them is about RKAP. Hopefully it's honest enough. > Section 18.3.6 > > Last para - is that really desirable behaviour? We discussed it and decided to keep the text as is. It's not desirable behavior, but the server can't really do about it. This is a good example of "SHOULD is really a MUST, unless you have good reasons and understand the implications". That's what we're trying to say. It's better for the server to respond, even with some generic and possibly not too useful options than to discard the message. Because it if does, the client will likely keep sending the message forever. > Section 18.3.7 > > Last para - “A server MAY” ? > (This is also another useful bit of information mentioned only here) This is really a server policy. Some servers choose to keep a history to potentially offer the same address to returning clients. Others don't. So I think the reasoning here is that we didn't want to start the policy stuff to creep in. Also, there's now section 1.3 that says policy is out of scope. This is a huge topic, with host reservations, classification, access control, policies etc. We definitely do not want that in this document. And probably not in any IETF document either. > Section 18.3.8 > > Para 2- so would a LOT of such declines be a DoS attack on the server? Possibly. Or recovering server that lost all leases. Most servers have configurable parameter how long to put such a lease out of circulation. > > Section 18.3.9 > > Para 1 - implied MUST - “The server MUST include” Not addressed yet. See #68. > Section 18.3.11 > > This is the first place Reconfigure authentication is stated as required - > could be earlier? It's now mentioned earlier. See note in 5.3. > 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) This is a guidance for server implementors. If a link configuration changes, it might not be a good idea to send all the reconfigure messages at once, if there are 1000s of devices. > Section 19 > > Could be handy to have RFC 6939 mentioned in here? It's mentioned now in 19.1.1. > Section 19.3 > > Any MTU issues here, or is the message always small even with the extra options > chained this way? That was one of the reasons why the max number of encapsulation levels were decreased to 8 from original 32. In practice, there are no options that are large enough to cause problems. The UDP packet can be fragmented and the option lengths are 16bits. So real tough problems could start when packets could get close to 64k. In practice, the packets are way below 1280. > Section 19.4 > > Just curious, why is RKAP just defined for Reconfigure? Because that's the only message the server sends on its own, rather than by responding to client? Or maybe because RKAP and Reconfigure is optional, because its protection is not that great and it adds much complexity? > Section 22 > > “third parts” -> “third party” Fixed. > 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? Yes. The whole section was reshuffled. Little text was added, but much moved around. There's now initial, generic part, client-specific (23.1), server-specific (23.2), one about reconfigure (23.3) and mitigation (23.4). > Appendix A > > Somehow I feel these aren’t all the changes? We probably misses some. > Appendix B > > “informational” and may differ to the main text - still worth keeping? We decided to keep it. It's just one page of an appendix at the end of a long document. > > Time for some sleep. Agree. Thanks again for your thorough review and apologies it took so long to respond. Cheers, Tomek -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
