IETF Logo Mail Archive

Re: [dhcwg] Regarding dhcpv4 client id

Roy Marples <roy@marples.name> Mon, 05 October 2020 07:39 UTC

Return-Path: <roy@marples.name>
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6A353A0E08 for <dhcwg@ietfa.amsl.com>; Mon, 5 Oct 2020 00:39:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.313
X-Spam-Level:
X-Spam-Status: No, score=-2.313 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, NICE_REPLY_A=-0.213, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=marples.name
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zzX91V9WW_TF for <dhcwg@ietfa.amsl.com>; Mon, 5 Oct 2020 00:39:40 -0700 (PDT)
Received: from relay2.marples.name (relay2.marples.name [IPv6:2a00:da00:1800:80d6::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D62FA3A0E06 for <dhcwg@ietf.org>; Mon, 5 Oct 2020 00:39:39 -0700 (PDT)
Received: from mail.marples.name (mail.marples.name [IPv6:2001:470:690c:1::59]) by relay2.marples.name (Postfix) with ESMTPS id 0187B761 for <dhcwg@ietf.org>; Mon, 5 Oct 2020 07:39:36 +0000 (UTC)
Received: from [10.73.1.30] (uberpc.marples.name [10.73.1.30]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail.marples.name (Postfix) with ESMTPSA id 81F145B0F; Mon, 5 Oct 2020 08:39:35 +0100 (BST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=marples.name; s=mail; t=1601883575; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=WZ7C+cLxwd3R69kElM9I/8508u//QTjtjRYFzl0ahIc=; b=aCmY5ehjlSNWGV1hsp3RUJSxpQw1lCHyuNsc71QzoToHYHTNJy7Kr3/EpdqLWqMf/2HC8m 7D4UEA+MWP/Agle3Bn2HWkKlIUvtSEnLGUwsggUBA8oWioF34Hu6DRZ0U6oZdIAA6tUBD2 MLuC6a44PDSzG/Z5yzW1UqgOOKwQVqo=
To: Venkataratnam Naidu <ratnameee@gmail.com>, dhcwg@ietf.org
References: <CANgMM_CQvWO4iARKt7apNQHFSzLmhCEcONVpueydfWEei1Gi2w@mail.gmail.com>
From: Roy Marples <roy@marples.name>
Message-ID: <8309d902-03e0-9548-9c0d-80c7a3accb75@marples.name>
Date: Mon, 05 Oct 2020 08:39:35 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.12.1
MIME-Version: 1.0
In-Reply-To: <CANgMM_CQvWO4iARKt7apNQHFSzLmhCEcONVpueydfWEei1Gi2w@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-GB
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/nWpq2vnRXtWaH5mCQFVZh3pLiXI>
Subject: Re: [dhcwg] Regarding dhcpv4 client id
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dhcwg/>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 05 Oct 2020 07:39:42 -0000

On 05/10/2020 06:53, Venkataratnam Naidu wrote:
> Hi Experts,
> 
> I have a question on dhcpv4 client id that client sends in dhcp discover/request 
> msg.
> 
> when the client id is other than hardware address, is that mandatory to encode 
> "type 0" in client-identifier.
> if client doesn't encode type 0, does this work in all dhcp server implementations.

 From RFC 2132 section 9.14

Identifiers SHOULD be treated as opaque objects by DHCP servers.

The problem here is should. Servers *do* try to interpet the client id and some 
reject the DHCP outright if it cannot.
The use of MUST would have been better here, but sadly that ship sailed years ago.

RFC 8415 section 11 does improve this for DHCPv6, but sadly there are still 
servers out there that reject unknown DUID types because the word SHOULD is 
still there.

Short answer - no it's not mandatory as per the RFC's but server implementations 
make it so.

Roy

v2.23.0 | Report a Bug | By Email