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

Jen Linkova <> Sat, 08 August 2020 13:06 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8E47F3A09D6; Sat, 8 Aug 2020 06:06:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.848
X-Spam-Status: No, score=-1.848 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ZLCIxrUOkhZF; Sat, 8 Aug 2020 06:06:50 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::832]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 851FC3A09EB; Sat, 8 Aug 2020 06:06:50 -0700 (PDT)
Received: by with SMTP id 6so3405866qtt.0; Sat, 08 Aug 2020 06:06:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=HkwdT+chYHz6eP2ToJBdvChFHRRUgLK78bqxAJ1VSS0=; b=N7FaonqPVJUa2N8N52mOa71zzCjS5nTIK/5ktXkw+Nf+NuXE7DAZCMqErYNd4I9rbT PxTcODkjVTE+aw1+MiiXJCV8XFVIjgn0g3pNxb+/gSxeMBjGXr/vTOngbX3G7Jv03an/ Ee1tfQsjtcermGkV4rPS2L3ogAvKtPlLomATsnTYJ6ANvBiP7MU4gG9fx+WIHUJNqDnH aTachXL1lrI01rleuaMXPURrDbmxBzTT2KA/Np3D8Uhi1IsgE7kt922JF8ciwQNEQdd9 /DzccNI7KVaFN9OejuJMiw4ol5adQtyY0MaWC2VCMM28otsNeSlIw6JZIoC0zewedIkB v92w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=HkwdT+chYHz6eP2ToJBdvChFHRRUgLK78bqxAJ1VSS0=; b=cSw23i5QGzEqiHZMPhUhdOfrphoCgkyXqTQVIRRHjocK4RpZxVjyYUJdFpJmxhdNft ZhB6KSdXWYboQ+2xpU2XVwThgRCvFfChSpAMoMpldpQvu8Gxt7DeRntkdS0QWrMJUdAs wwD1YaM6hXMXgNJUHj0Os1fo9dftUsfpx6zVgul0ml0pnyQkiS2QZ+/BlVG/DJ03zPhv 4L/JSqEKxBIj0WKPAAsdbXYS3re0T3s0OK3qRC8nb7iMOrs7V8c4CM7RZ7eA8nRm9oBd PDGRZOwB3cYiqOx69CGc6Q4js7gYtOwyB8JKgRRt++U1FKEYw/XhRVImyMLBNG+fvofR nglA==
X-Gm-Message-State: AOAM533HT1cea2hN/1JWe4ELze4tu4tCv036SRcuB9PawqZKiAFfQHyI YML9Nl0MMnDZ2QV/96srGNY/mcaB1l+gaFSCBvI=
X-Google-Smtp-Source: ABdhPJz41MvvpWwRnVTGpxmzKJrCBifA5oQck64+dyLg16eCZm3HtPsO90JYd2/R5YXMIvm1RgkHXS6QMqJCWKPWz9U=
X-Received: by 2002:ac8:6f22:: with SMTP id i2mr18803431qtv.384.1596892009325; Sat, 08 Aug 2020 06:06:49 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Jen Linkova <>
Date: Sat, 8 Aug 2020 23:06:38 +1000
Message-ID: <>
To: Benjamin Kaduk <>
Cc: The IESG <>,, "Bernie Volz (volz)" <>,,
Content-Type: text/plain; charset="UTF-8"
Archived-At: <>
Subject: Re: [dhcwg] Benjamin Kaduk's No Objection on draft-ietf-dhc-v6only-06: (with COMMENT)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 08 Aug 2020 13:06:54 -0000

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.

On Sat, Aug 8, 2020 at 2:47 PM Benjamin Kaduk via Datatracker
<> wrote:
> 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.

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."


> 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.

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
The draft describes the assumptions which are correct at the time of
writing but that could change.

> 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.

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?

> 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?

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."

> 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?

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

>    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"

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.

> 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"?

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.

> 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.

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?

> 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".

Make sense, the text updated.

> 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.

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

Would it address your comment?

> Section 8.1
> We seem to only use RFC 4861 in the definition of RA, which itself seems
> to be unused.

Moved to the Informative section.

> 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.

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