[dhcwg] Benjamin Kaduk's No Objection on draft-ietf-dhc-v6only-06: (with COMMENT)

[Benjamin Kaduk via Datatracker <[e-mail]>]

Benjamin Kaduk has entered the following ballot position for
draft-ietf-dhc-v6only-06: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dhc-v6only/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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.