Summary: Needs 6 more YES or NO OBJECTION positions to pass.
[[ 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/
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?
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.