Re: [dhcwg] RFC 3925 Data Length Placement

Bernie Volz <bevolz@gmail.com> Tue, 04 April 2023 21:25 UTC

Return-Path: <bevolz@gmail.com>
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 10797C15C296 for <dhcwg@ietfa.amsl.com>; Tue, 4 Apr 2023 14:25:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.201
X-Spam-Level:
X-Spam-Status: No, score=-1.201 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_FROM=0.001, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.1, MIME_HTML_ONLY_MULTI=0.001, MIME_QP_LONG_LINE=0.001, MPART_ALT_DIFF=0.79, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BQ3gclsoWo8W for <dhcwg@ietfa.amsl.com>; Tue, 4 Apr 2023 14:25:35 -0700 (PDT)
Received: from mail-qv1-xf32.google.com (mail-qv1-xf32.google.com [IPv6:2607:f8b0:4864:20::f32]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14AC4C15256B for <dhcwg@ietf.org>; Tue, 4 Apr 2023 14:25:35 -0700 (PDT)
Received: by mail-qv1-xf32.google.com with SMTP id jl13so24918767qvb.10 for <dhcwg@ietf.org>; Tue, 04 Apr 2023 14:25:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1680643534; h=to:in-reply-to:cc:references:message-id:date:subject:mime-version :from:content-transfer-encoding:from:to:cc:subject:date:message-id :reply-to; bh=YibwKqnwpKj/+U0hk7h+ehLcnJy3a0VwBS1qR70I2Gg=; b=qPPkgzK8qUNC65kYgQKSffrZhLSeByVY98lisOqlRMTrVU3usAK/qWWLkBk63vFi4S F/za6OUNah/4gFKDMW7Sy37ut3LwA8tC8vOwPtkKGiK2TddLfpyKJrwIUS29z7Kt1rSY 5mx1DZXH/aEIA5v28VD6WNc8vfLa7WReQANE1uJUoKEZ6Oyqyd6IVzOfPOf61BJU/+tx yIgTpnf+0mMK3GF6vVcuDNfGVIkrnr3Wth8+4TutIJFlrzaL2btglvDeaX8XMwnoRiSF OhqlRhAogcrA3xRgmhhTQYmw1dOyd5uYeMCTSOcPpyARZMNtYVA0kyYYnoMGgR7QiNJ6 Jppg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1680643534; h=to:in-reply-to:cc:references:message-id:date:subject:mime-version :from:content-transfer-encoding:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=YibwKqnwpKj/+U0hk7h+ehLcnJy3a0VwBS1qR70I2Gg=; b=l2Oa/GUg5+uGK4s2hPY5QxqMR7hG8d85q+8lf5Fmm9kMgypOrFbDRdtfW8yNIAKjGL sqQvfHUMar1vG0Scmh6LVlDI7pOJUvtC8aN1mt827r0uq48l3v8sDZuo3flhmk0UNrYM 81qy97Deqp/Y4t44Tc0ovrjh/xqDvvbjMYJAajtYfhZ3DaJiiX1sGLvLfaRECaG/D9ux 08ykfr/DdsqRtCAp+CrBVCCMxGgh+GyiFSaZFx/eTdfhrty4zkqsATItkby8jaqIckRC RQ7YZB81HKswQIZE4nD72otJWpWZPo36Cdbxd415ihAEQJCuQdXK3Sebi+xKtJkc0dIg o0sw==
X-Gm-Message-State: AAQBX9cFMD8S7WQg5om5mnr1N152YofefCWYNpEzRDe7SJe4SklC5r8g /YqROdXqvHOzjmSwMw19iA==
X-Google-Smtp-Source: AKy350aj3RoTWcONMPs8fZRsGAmKth7TTPYeRzeGjr2tHByFtE65IOd3wtmd8I2nFSDit0tKnOKZcQ==
X-Received: by 2002:ad4:5dcb:0:b0:5cd:3326:7ab with SMTP id m11-20020ad45dcb000000b005cd332607abmr5519853qvh.46.1680643533843; Tue, 04 Apr 2023 14:25:33 -0700 (PDT)
Received: from smtpclient.apple (d-24-233-121-124.nh.cpe.atlanticbb.net. [24.233.121.124]) by smtp.gmail.com with ESMTPSA id ks8-20020a056214310800b005e45f6a5bd5sm985957qvb.16.2023.04.04.14.25.33 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 04 Apr 2023 14:25:33 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail-14EC128F-FA61-479C-88DF-A75EEDE1C958"
Content-Transfer-Encoding: 7bit
From: Bernie Volz <bevolz@gmail.com>
Mime-Version: 1.0 (1.0)
Date: Tue, 04 Apr 2023 17:25:22 -0400
Message-Id: <AB4F9083-A7F9-4959-843C-E25355F1C285@gmail.com>
References: <CAPt1N1m-PyNkV+3i2t9qgJW5_acBd0Gd-Mv=webaVhQMg0gkwA@mail.gmail.com>
Cc: Timothy Winters <tim@qacafe.com>, dhcwg <dhcwg@ietf.org>
In-Reply-To: <CAPt1N1m-PyNkV+3i2t9qgJW5_acBd0Gd-Mv=webaVhQMg0gkwA@mail.gmail.com>
To: Ted Lemon <mellon@fugue.com>
X-Mailer: iPad Mail (20E246)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/B4fNsvUR0EHxcrKDsKCf7lBrc3s>
Subject: Re: [dhcwg] RFC 3925 Data Length Placement
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Dynamic Host Configuration <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: Tue, 04 Apr 2023 21:25:39 -0000

Hi:

While I agree that there is an overall length for the vendor-class data, it must be formatted as per RFC:

The vendor-class-data comprises a series of separate items, each of
   which describes some characteristic of the client's hardware
   configuration or capabilities.  Examples of vendor-class-data
   instances might include the version of the operating system the
   client is running or the amount of memory installed on the client.

   Each instance of the vendor-class-data is formatted as follows:

                        1 1 1 1 1 1
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   data-len    |               |
   +-+-+-+-+-+-+-+-+  opaque-data  |
   /                               /
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The data-len is one octet long and specifies the length of the opaque
   vendor class data in network byte order.

There’s also a MUST for how the Vendor Information option is formatted … so it is not up to the vendor.

The reason for an overall length was that it made the server’s processing when skipping a specific vendor’s data easier. (And also avoided severe problems if a vendor didn’t follow the rules.)

So, if there is one vendor class of “abcd”, it is formatted as octet of 5, 4, and then “abcd”. If there are two vendor classes “abcd” and “efgh”, it is formatted as octet of 10, 4, abcd, 4, efgh. The 4 octet followed by the 4 bytes represent the diagram above for each piece of opaque-data. The overall length of 5 or 10 is the data-len1 (or 2, …).

- Bernie Volz

On Apr 4, 2023, at 5:11 PM, Ted Lemon <mellon@fugue.com> wrote:


There is a length per enterprise and a length for the total option. The format of the per-enterprise data is up to the enterprise to define.

On Tue, Apr 4, 2023 at 4:04 PM Timothy Winters <tim@qacafe.com> wrote:
Hello,

As part of CPEs implementing https://usp.technology/specification/03-index-discovery.html#sec:using-dhcp" target="_blank" rel="nofollow">DHCP Discovery for USP, we had several implementations recently ask about the packet format of Option 124.  In particular the data-len fields documented in RFC 3925, Section 3.  There is confusion if there is a single data length following each enterprise-number for the VI Vendor Class or if the vendor-class-data option has a data length as well.  

Single Data Len
8 (data-len1)
   abcd (first class)
   defg (second class)

OR 

Multiple Data Len
8 (data-len1)
  3 abc (first class)
  3 def (second class)

Regards,
Tim
_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www.ietf.org/mailman/listinfo/dhcwg" rel="noreferrer nofollow" target="_blank">https://www.ietf.org/mailman/listinfo/dhcwg
_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www.ietf.org/mailman/listinfo/dhcwg