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

Benjamin Kaduk <> Thu, 13 August 2020 19:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 53FB13A10E9; Thu, 13 Aug 2020 12:50:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id GJS0Vk5EIWB6; Thu, 13 Aug 2020 12:50:42 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2A5DB3A10C2; Thu, 13 Aug 2020 12:50:40 -0700 (PDT)
Received: from ([]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by (8.14.7/8.12.4) with ESMTP id 07DJoXj9003352 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 13 Aug 2020 15:50:35 -0400
Date: Thu, 13 Aug 2020 12:50:32 -0700
From: Benjamin Kaduk <>
To: Jen Linkova <>
Cc: The IESG <>,, "Bernie Volz (volz)" <>,,
Message-ID: <>
References: <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.12.1 (2019-06-15)
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: Thu, 13 Aug 2020 19:50:51 -0000

Hi Jen,

On Sat, Aug 08, 2020 at 11:06:38PM +1000, Jen Linkova wrote:
> 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"
> Fixed.
> >    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."
> ?

That works for me, thanks.

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

Okay, thanks for the extra background/explanation.

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

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.

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

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

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

Okay, thanks.

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

(I'm not sure, either.)

> > 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
> preferable."
> Would it address your comment?

Sounds good, yes.

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