IPv6-Only Preferred Option for DHCPv4
Note: This ballot was opened for revision 04 and is now closed.
Erik Kline Yes
Comment (2020-08-08 for -06)
[[ suggestions ]] [ section 5 ] * Consider redoing the table to instead match the columns in the registry. Perhaps: Tag: TBD Name: IPv6-only Preferred option Data Length: 4 Meaning: IPv6-only Preferred option Reference: [THIS-RFC] [[ nits ]] [ section 3.2 ] * Perhaps s/per interface enabled basis/per enabled interface basis/ [ section 3.3 ] * s/assign an address for the pool/assign an address from the pool/
Éric Vyncke Yes
Alvaro Retana No Objection
Comment (2020-08-10 for -06)
I have several comments that I believe are borderline DISCUSS-worthy because collectively they result in the specification not being clear. However, I have decided to ballot No Objection because none of them individually raise to the same level. (1) From the Introduction: If hosts were to delay requesting IPv4 until IPv6 reachability is confirmed, that would penalize IPv4-only and dual-stack networks, which does not seem practical. The mechanism specified may delay the IPv4 process for at least MIN_V6ONLY_WAIT; 5 minutes is a very long time, and it seems longer than "until IPv6 reachability is confirmed". I would like to see the document include operational considerations related to the practicality of implementing the new functionality. Given that the operation (in §3.2) is only recommended ("SHOULD stop the DHCPv4 configuration process for at least V6ONLY_WAIT"), the considerations should include guidance on the tradeoffs, including initial setup. (2) §3.2: What is a "network attachment event"? Is that defined somewhere? I looked at rfc2131 but didn't find the definition there. A "network disconnection event" is mentioned later...same question. Both sound like physical events to me (connect/disconnect). (3) §3.2: What is the difference between these two actions: "the client...SHOULD stop the DHCPv4 configuration process or disable IPv4 stack completely"? Are they defined anywhere? I have an intuition of what the actions mean, but given that they are attached to normative language, it would be ideal if the operation was clear to everyone. (4) [nit] s/MAY configure IPv4 link-local address/MAY configure an IPv4 link-local address (5) [nit] s/specify V6ONLY_WAIT timer/specify the V6ONLY_WAIT timer (6) §3.3: The first paragraph makes configuration recommended/optional ("SHOULD be able to configure...MAY have a configuration option"), but the second paragraph requires an action based on that configuration ("MUST NOT include...if the YIADDR...does not belong to a pool configured..."). First of all, I believe these a Normative conflict: if the configuration is recommended/optional, then a required action can't rely on it. Also, if the pools can't be configured, then it seems that the IPv6-only Preferred option would never be included. Is that the expected behavior? It seems to me that even if individual pools can't be configured, the use of the option could still be useful for all pools. (7) §3.3: "The server SHOULD NOT assign an address for the pool. Instead it SHOULD return 0.0.0.0 as the offered address. Alternatively, the server MAY include an available IPv4 address from the pool into the DHCPOFFER as per recommendations in [RFC2131]." What are the conditions under which the server would select to assign an address? The initial two sentences recommend not doing it. (8) §3.3: "...the server MAY include an available IPv4 address from the pool into the DHCPOFFER as per recommendations in [RFC2131]. In this case, the offered address MUST be a valid address that is not committed to any other client. Because the client is not expected ever to request this address, the server SHOULD NOT reserve the address and SHOULD NOT verify its uniqueness." rfc2131 already contains a similar recommendation as "the server SHOULD NOT reserve", but without using normative language ("Servers need not reserve the offered network address, although the protocol will work more efficiently if the server avoids allocating the offered network address to another client."). It seems to me that the recommendations from rfc2131 already cover the reservation case and don't need to be repeated. OTOH, "SHOULD NOT verify its uniqueness" seems to contradict what rfc2131 recommends: "When allocating a new address, servers SHOULD check that the offered network address is not already in use". I'm assuming that being unique and "not already in use" are equivalent. (9) §3.3.1: [nit] s/on IPv6-mostly network/on an IPv6-mostly network
Benjamin Kaduk No Objection
Comment (2020-08-07 for -06)
Thank you for addressing Martin's point already! Abstract This document specifies a DHCPv4 option to indicate that a host supports an IPv6-only mode and willing to forgo obtaining an IPv4 address if the network provides IPv6 connectivity. It also updates nit: "is willing" RFC2563 to specify the DHCPv4 server behavior when the server receives a DHCPDISCOVER not containing the Auto-Configure option. I know Abstracts should be concise, but perhaps we should pay the few extra words and note that this is limited to just the v6only case -- the current text makes it sound like this is some completely orthogonal thing. Section 1.2 I worry a little bit about how we are sometimes assuming that IPv6-only includes NAT64+DNS64, and sometimes not, but the current text about "this document currently implies" is probably enough to clarify things. Section 2 Thank you for acknowledging the new DoS attack vector :) Being a client/server protocol, DHCPv4 allows IPv4 to be selectively disabled on a per-host basis on a given network segment. Coexistence of IPv6-only, dual-stack and even IPv4-only hosts on the same LAN would not only allow network administrators to preserve scarce IPv4 addresses but would also drastically simplify incremental deployment of IPv6-only networks, positively impacting IPv6 adoption. It seems that the cost of achieving this benefit is that the v4 stack on the network equipment needs to know about the v6 capabilities of the network. When the same hardware provides the v4 and v6 service (would that ever not be the case?), this is presumably no great burden, but it does perhaps present an abstraction barrier violation. Section 3.1 Am I reading this wrong, or do we only specify the semantics of the "Value" field for the server-to-client direction? Should the client just set it to all-zeros in messages it generates? Section 3.2 Is the "for at least <N> seconds or until a network attachment event happens" common enough in DHCP documents that the "whichever comes sooner" is implicit? to that value. Otherwise, the client SHOULD set the V6ONLY_WAIT timer to MIN_V6ONLY_WAIT. The client SHOULD stop the DHCPv4 configuration process for at least V6ONLY_WAIT seconds or until a network attachment event happens. The host MAY disable the IPv4 stack completely for V6ONLY_WAIT seconds or until the network disconnection event happens. I'm not entirely sure if there are some subtle semantic differences between "network attachment event" and "network disconnection event" such that the former applies to the "stop the DHCPv4 configuration process" cases but the latter applies to "disabled IPv5 stack completely" cases. (We only talk about "network disconnection event" in the following paragraph, as applying to both pausing configuaration and disabling the stack entirely.) Section 3.3.1 contain the Auto-Configure option, it is not answered." Such behavior would be undesirable for clients supporting the IPv6-Only Preferred option w/o supporting the Auto-Configure option as they would not receive any response from the server and would keep asking, instead of disabling DHCPv4 for V6ONLY_WAIT seconds. Therefore the Should I infer that the "V6ONLY_WAIT seconds" is modified by "or until a network attachment event occurs"? Section 3.4 V6ONLY_WAIT The minimum time the client SHOULD stop the DHCPv4 configuration process for. The value MUST NOT be less than MIN_V6ONLY_WAIT seconds. Default: 1800 seconds nit(?): is this really a "minimum" time? The previous discussion is inconsistent about using "at least V6ONLY_WAIT seconds" or just "for V6ONLY_WAIT seconds", which might be worth tightening up. Section 6 An attacker might send a spoofed DHCPOFFER containing IPv6-only Preferred option with the value field set to 0xffffffff, disabling DHCPv4 on clients supporting the option. If the network is IPv4-only I don't remember us assigning special semantics to 0xffffffff, so maybe we should just say "value field set to a large number, such as 0xffffffff, effectively disabling DHCPv4". I guess this attack also only works if the client ends up picking that offer (right?), so we might mention that the attacker needs to make the rest of the offer look compelling enough for the client to pick it anyway, even in the presence of other (legitimate) offers. Section 8.1 We seem to only use RFC 4861 in the definition of RA, which itself seems to be unused. Section 8.2 It's a little surprising to see RFC 6146 listed as only an informational reference, given how heavily we rely on/expect NAT64 to be available alongside this mechanism.
Martin Duke (was Discuss) No Objection
Comment (2020-07-30 for -05)
Thanks for addressing my DISCUSS on spoofed long timeouts in the github version. Original comments, since addressed: This seems like an important stepping stone to v6 adoption, so thanks. Sec 3.1 In client-generated messages, what is in the "Value field"? I presume this is one of those "client MUST set to zero and server MUST ignore" cases? Sec 3.3 "If the client then issues a DHCPREQUEST for the address, the server MUST process it per [RFC2131], including replying with a DHCPACK for the address if in the meantime it has not been committed to another client." What if it HAS been committed to another client? What then?
Martin Vigoureux No Objection
Murray Kucherawy No Objection
Comment (2020-08-10 for -06)
In Sections 3.2 and 3.3, there are a lot of SHOULDs and a couple of SHOULD NOTs, but no guidance about what one might do instead of what they say, or when it might be appropriate to deviate from the SHOULD, or what the impact of doing so might be. Since you're providing a choice, I suggest fully developing the choice. And a few nits: Abstract: * "... supports an IPv6-only mode and willing to ..." -- s/willing/is willing/ Section 1.2: * "This document currently implies that ..." -- Is this document going to imply something else later? * "a deployment scenario when ..." -- s/when/where/
Robert Wilton No Objection
Comment (2020-08-13 for -07)
Hi, Thank you for your work on this document, I found it easy to read. I have a few minor comments/nits that may help improve this document: Minor comments: Would it be helpful for the the term dual-stack need to be defined (or the definition imported)? 6. Security Considerations ... could be considered a security feature. Perhaps better for the security ADs to comment, but I wasn't sure whether this is so much a security feature, or instead just reducing the possible attack surface. Nits: "such approach" => "such an approach" "IPv6-Only" => "IPv6-only"? (for consistency with other terms) "operate in IPv6-only network" => "operate in an IPv6-only network" "Strictly speaking IPv6-only ... " => "More precisely, IPv6-only ..." " ... declaring a host or (strictly speaking, a host interface) IPv6-only capable ..." => "... declaring a host (technically, a host interface) as IPv6-only capable ..." "Hypothetically it" => "Hypothetically, it" "in IPv6-only environment" => "in an IPv6-only environment" "via NAT64 service" => "via a NAT64 service"
Roman Danyliw No Objection
Comment (2020-08-12 for -07)
A few editorial nits: -- Section 3.3.1. Editorial. “w/o” --> “without” -- Section 3.3.1. Editorial. OLD Therefore the following update is proposed to Section 2.3 of [RFC2563]" NEW Therefore, the following update is made to Section 2.3 of [RFC2563]. -- Section 3.4 Please review the SECDIR review for revised text on V6ONLY_WAIT (and thank you Russ Housley for doing the review)
Warren Kumari No Objection
Comment (2020-08-10 for -06)
Thank you for this document - it is well written and should help significantly with address exhaustion (and, potentially, knowing when we are done :-)) Also, thanks to Sheng for the OpsDir review.
(Barry Leiba; former steering group member) No Objection
( for -07)
(Deborah Brungard; former steering group member) No Objection
( for -07)