Re: [dhcwg] [Iot-directorate] Iotdir last call partial review of draft-ietf-dhc-mac-assign-06


Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E80EF3A07E3 for <>; Thu, 28 May 2020 12:26:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ixtkVtBTv50e for <>; Thu, 28 May 2020 12:26:43 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::12e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C5DF73A085C for <>; Thu, 28 May 2020 12:26:43 -0700 (PDT)
Received: by with SMTP id y17so88659ilg.0 for <>; Thu, 28 May 2020 12:26:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=CBSmWJZFcoAHTxsmok966EATTV207ONUk1me0u7rwFs=; b=dxAEEDbfW7NvTGwFlP6FgJwkazqQXXW3oYKpsYWsnO0yLonMDDykmaBXNPdFNeoYFo VRF49XzgBJz5ccBWW+M+eLhkXQ9bJKsaTGKN4GnuMaOH+bnKJzDQVO+ay1kduVulEwzi CjZ/m1EfDJGXrjm3hzspCC1xl0OcuX887jWMHRLI5pT8HJwfw2iImTo1qK3b15+fIKtV j6qXDXbvDj9mvW/K1+dAFEqOeE+PpMIKbIfuO5kiNUGQPj7pgeQrWBK8bP8WCXZG7vfg kvFGe9sffSn8IAg0sibfGYiYJ4/87norhp61MIJH4fv5yHbJD3YqFbIHVoR7cDp3txVD UEyw==
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=CBSmWJZFcoAHTxsmok966EATTV207ONUk1me0u7rwFs=; b=TyI18oy0F/+tUPxG97+zfioL2/CcdyBLS0J1gTn/0KLUp+1D7u5XOtDD1dpZITQjSX 83QLMdDpkj+67i7CetmIjt5g4MBgwbS46dgW1FYTlrKnNPIKhWxUd2rCdCb5kB+MUx4F S/YhagWOx10tZSt6cJjXr48n7b/IbLFWabLajgcCdgxgs40CqzqJVITSbUXxvCkhn1Ue 2ieEwYKXbfXW4W5QZZiuUO3MjdnTR4zo1vE3GQDnCAIyf22WPURvahazeMLTvzuURkPD oS57g6R4fQIdM56AeuYZncDVN3tw/laEc8W9d6kWh4QlTsI8AIGZkr5KPUEu5NdbPnKg zY+g==
X-Gm-Message-State: AOAM532oh49OvnQj9TquMzbVw2UCS3vp1qHpP2mbR4Q7G0SKfe9PfM9P PGhjtpt1JMgMFVYektwqaM97w42HVDaEjBSZNLyjaQ==
X-Google-Smtp-Source: ABdhPJxlQdnzbYCVkPYzEa3EJRDv8vXgBt4D//NEpauxIdBLpPi5e+e1PjWYimRXP6HPMIH38pEcExWFT1aRqp1Emag=
X-Received: by 2002:a92:980f:: with SMTP id l15mr4242156ili.251.1590694001982; Thu, 28 May 2020 12:26:41 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
Date: Thu, 28 May 2020 21:26:25 +0200
Message-ID: <>
To: "Bernie Volz (volz)" <>
Cc: "Eric Vyncke (evyncke)" <>, Samita Chakrabarti <>, "" <>, "" <>, "" <>, Ian Farrer <>
Content-Type: multipart/alternative; boundary="000000000000ef85d705a6ba4e30"
Archived-At: <>
Subject: Re: [dhcwg] [Iot-directorate] Iotdir last call partial review of draft-ietf-dhc-mac-assign-06
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, 28 May 2020 19:26:46 -0000


Apologies for the belated response. Please see inline below for some
comments on the IEEE aspect.

On Tue, May 26, 2020 at 10:47 PM Bernie Volz (volz) <> wrote:

> Hum ... I never seemed to have received the original email -
> .
> Some comments below (BV>).
> ---
> I took a quick glance at the draft from IoT point of view (only partial
> review ).
> Section 4.2 talks about the IoT use case as Direct Client Mode -- where
> they
> talk about cheap devices which may not have unique UUID associated with it.
> Note that a client that operates as above that does not have a
>    globally unique link-layer address on any of its interfaces MUST NOT
>    use a link-layer based DUID (DHCP Unique Identifier), i.e., DUID-LLT
>    or DUID-LL.  For more details, refer to Section 11 of [RFC8415].
> 1. However,  it is not clear what  source initial link-layer address
> should be
> used by these devices. should it point to section 6? will that suffice?
> BV> There are two different issues here. One is the DUID this device would
> use for DHCPv6 - we were just pointing out here that these devices must not
> use Link Layer based DUIDs (hence, they should use DUID-EN or DUID-UUID).
> In terms of the "initial link-layer address", I'm not sure that a reference
> to section 6 (I assume of the dhc-mac-assign draft) would be useful? In
> section 4.2, we already say "Upon first boot, the device uses a  temporary
> address, as described in [IEEE-802.11-02-109r0], to send initial DHCP
> packets to available DHCP server", so I'm not sure what is missing?
> 2. Moreover,  how safe the mechanism would be if the Security section says
> that
> mechanism defined in this draft may be used by a bad actor ?
> BV> I'm also not sure what would be needed here? I guess we could point
> out that randomly selecting an initial mac-address and trusting a DHCPv6
> server to assign an address is very insecure? But that's pretty much
> covered by Perhaps more
> clarity on what should be added would help?
> 3. It appears to me the mechanisms are designed for VMs behind an
> hypervisor
> and then IoT usages are added. My concerns are two fold for challenged low
> capability IoT devices -- 1) will they be able to handle the complicated
> option
> processing described here? 2) How to mitigate the security vulnerability
> for
> IoT devices as direct clients?  (The security section does not talk about
> mitigation)
> Should there be a simpler option processing structure without TLV option
> processing ( i,e a fixed structure part + then TLV part for optional
> information]?
> BV> The TLV structure is what DHCPv6 is based on. I'm not really sure that
> this is that complicated and if it is ... this is OPTIONAL - a IOT device
> could consider using it; of course, if it really is low end perhaps it is
> not the best technique for it? The IEEE was also working on a specification
> for doing link-layer address assignment and theirs (when available) would
> most likely be at a much lower layer in the "stack" and may be better
> optimized for the IOT case (and may also cover the initial allocation issue
> that exists with DHCPv6). So the IOT case was indeed not the first
> priority, as that likely would be better accommodated by IEEE.
> BV> I don't know if Carlos might have some more data on the IEEE work, as
> my contacts at IEEE seem to have dried up.

[Carlos] From what I understand IEEE is working on some mechanisms, as
Bernie has mentioned, and also referencing this draft as one of the
possible solutions. I can try to ask about more details to one colleague
that participates in IEEE.


> - Bernie
> -----Original Message-----
> From: Éric Vyncke via Datatracker <>
> Sent: Saturday, May 23, 2020 2:55 AM
> To: The IESG <>
> Cc:;;
>; Tomek Mrugalski <>om>; Ian Farrer <
> Subject: Éric Vyncke's Yes on draft-ietf-dhc-mac-assign-06: (with COMMENT)
> Éric Vyncke has entered the following ballot position for
> draft-ietf-dhc-mac-assign-06: Yes
> 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
> for more information about IESG DISCUSS and COMMENT positions.
> The document, along with other ballot positions, can be found here:
> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> Thank you for this useful and easy to read document.
> Please also address the IoT Directorate review by Samita Chakrabarti:
> Regards
> -éric