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

From: Benjamin Kaduk via Datatracker <[email-masked]>
Date: Fri, 07 Aug 2020 21:47:14 -0700

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.

---

From: Jen Linkova <[email-masked]>
Date: Sat, 8 Aug 2020 23:06:38 +1000

Hi Benjamin,

Thanks for your comments!
When the text below says 'done/fixed' it means that the Github version
has been updated and changes will appear in -07.

>    address if the network provides IPv6 connectivity.  It also updates

Fixed.

> current text makes it sound like this is some completely orthogonal

How about:
"It also updates RFC2563 to specify the DHCPv4 server behavior when
the server receives a DHCPDISCOVER not containing the Auto-Configure
option but containing the new option defined in this document."

?

> about "this document currently implies" is probably enough to clarify

Oh that has been discussed in the WG and between the authors
extensively. The thing here is:
- normally, NAT64 is needed as the host might want to talk to
IPv4-only destinations.
- however let's say a device (a smart sensor? or smth else) is
designed to talk to very limited cloud-based destinations which are
guaranteed to be IPv6-enabled. Shall we prohibit such devices from
sending the option? I do not think so.
- Nowadays *most* devices would need the IPv6-only network to provide
them with DNS64. However it's not always necessary for devices which
are able to discover NAT64 prefix and perform DNS64 synthesys
themselves. So it would be unwise to assume that DNS64 *must* be
there.
The draft describes the assumptions which are correct at the time of
writing but that could change.

> does perhaps present an abstraction barrier violation.

I might be misunderstanding your comment but the whole idea here is
that no intermediate hardware needs to know anything.
The administrator decides if the particular network segment (served by
the particular DHCPv4 pool) is 'IPv6-mostly' and configures the DHCPv4
server accordingly.
Done. This option is about what the client and the server negotiate.
You can even have different routers acting as IPv4 and IPv6 default
routers if you'd like.
Am I missing anything?

> just set it to all-zeros in messages it generates?

The client does not send the full option. The client includes the
option code into the Parameter Request List (RPL) and the server
responds with the option.
Martin did ask the same question so I assumed it was not clear enough
in -05. -06 says (in the Code field description):
"The client includes the Code in the Parameter Request List in
DHCPDISCOVER and DHCPREQUEST messages as described in Section 3.2."
Your comment makes me think it's still not clear enough.
Would it help if we add the following text into the Value field description:
"The client never sets this field as it never sends the full option
but includes the option code in the Parameter Request List as
described in Section 3.2."
?

> happens" common enough in DHCP documents that the "whichever comes

Good point. I'll update the text with 'whichever happens first'.

> between "network attachment event" and "network disconnection event"

Actually not, it's just me being lazy with wordings I'm afraid ;)
Thanks for pointing this out, I'll clean up the text to use 'network
attachment even' is used consistently.

> network attachment event occurs"?

Yes indeed. I'm not sure if it's worth explicitly mentioning here as
it's not a normative text, just an explanation of desired behavior.

> V6ONLY_WAIT seconds", which might be worth tightening up.

Yeah, good catch.
IMHO we can remove 'the minimum' and 'at least' and require the client
to disable DHCPv4 for  V6ONLY_WAIT seconds.
Dear co-authors, any objections?

> 0xffffffff, effectively disabling DHCPv4".

Make sense, the text updated.

> anyway, even in the presence of other (legitimate) offers.

Oh that's a good point, thanks!
The following text will be added to the very end of the first
paragraph of the section 6:
"Additionally such attacks can only be executed if the victim prefers
the rogue DHCPOFFER over the legitimate ones. Therefore for the attack
to be successful the attacker needs to know the selection criteria
used by the client and to be able to make its rogue offer more
preferable."

Would it address your comment?

> We seem to only use RFC 4861 in the definition of RA, which itself seems

Moved to the Informative section.

> alongside this mechanism.

I might be wrong here but I assumed that the fine line between the
normative and informative is somewhere around 'do I need this
reference to be able to implement this draft?'.
For this option to work NAT64 is not really needed - if we completely
rewrite NAT64 machinery but keep the provided service intact it would
not affect this document..
I'm fine with moving this reference to Normative, just not sure if
it's really needed.

-- 
SY, Jen Linkova aka Furry

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 13 Aug 2020 12:50:32 -0700

Hi Jen,

> option but containing the new option defined in this document."

That works for me, thanks.

> writing but that could change.

Okay, thanks for the extra background/explanation.

> the particular DHCPv4 pool) is 'IPv6-mostly' and configures the DHCPv4

I think we have a similar understanding, as my "v4 stack needs to know" is
achieved by your "administrator configures the DHCPv4 server accordingly".
My comment was mostly assuming that the v4 stack would (at least sometimes)
be acting without explicit administrator action, if it knew by some other
means about the nature of the v6 network, but administrator action makes
sense and is still not a great burden to achieve.

> described in Section 3.2."

That would have gotten the point through to me, but I don't think you need
to feel obligated to make this change just for my benefit; if I was better
versed in the DHCP operation the text in the -06 would have made sense to
me.

> attachment even' is used consistently.

Okay, thanks.

> it's not a normative text, just an explanation of desired behavior.

(I'm not sure, either.)

> Would it address your comment?

Sounds good, yes.

> I'm fine with moving this reference to Normative, just not sure if

https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
notes that references relevant only for optional features must be
classified as normative [given the normal conditions], but I guess that is
still not a clear-cut answer in this case.  Regardless, I trust your
judgment on this one; it's not a huge deal to me either way.

Thanks,

Ben