IPv6-Only Preferred Option for DHCPv4
RFC 8925

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

No Objection ( for -07)
No email
send info

(Deborah Brungard; former steering group member) No Objection

No Objection ( for -07)
No email
send info