[dhcwg] Re: New Version Notification for draft-tojens-dhcp-option-concat-considerations-00.txt
Tommy Jensen <tojens.ietf@gmail.com> Tue, 22 October 2024 03:36 UTC
Return-Path: <tojens.ietf@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 7BCADC22919D for <dhcwg@ietfa.amsl.com>; Mon, 21 Oct 2024 20:36:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.105
X-Spam-Level:
X-Spam-Status: No, score=-2.105 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, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham 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 TUegtgCvUHK2 for <dhcwg@ietfa.amsl.com>; Mon, 21 Oct 2024 20:36:31 -0700 (PDT)
Received: from mail-pg1-x531.google.com (mail-pg1-x531.google.com [IPv6:2607:f8b0:4864:20::531]) (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 ietfa.amsl.com (Postfix) with ESMTPS id B6FF9C14F71C for <dhcwg@ietf.org>; Mon, 21 Oct 2024 20:36:31 -0700 (PDT)
Received: by mail-pg1-x531.google.com with SMTP id 41be03b00d2f7-7ea6a4f287bso3275873a12.3 for <dhcwg@ietf.org>; Mon, 21 Oct 2024 20:36:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1729568191; x=1730172991; darn=ietf.org; h=mime-version:subject:references:in-reply-to:message-id:cc:to:from :date:from:to:cc:subject:date:message-id:reply-to; bh=lqdUxDbO2l6I2s69xWn2/NoqgUvquthM52JTTXP5TEM=; b=Ulf+l2hssOKibMz6VikFur4VLOf9nV0EP93JtVEmDgZw/Xw/Pkneu5eV+1y6rcVkon z8hiKfc97waogdiRGteWgjkwjKsPWmjIgeVowUYs8a/1eXNeawbJ/AkVFCCU7DTIUOhp PYOFIQeeawcnrsJqvXiQz1mHIxhegn8tJlqPlYof1zixD32Jsv3Ta3SozRYYofNEoSwL g/Yynw+6elWPjMRx7xAo0i3dIMMa0Ksr5oqP3Gc2xN2xTWM8xDOGbJQ82PZmseMFZwyd f2yM2DtCBBEfdWoQj4sqYPuDMhlqXPD/7svuOGbXPTRu8Kize9gh0/VDvNHeQxMYiMLg dD0g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1729568191; x=1730172991; h=mime-version:subject:references:in-reply-to:message-id:cc:to:from :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=lqdUxDbO2l6I2s69xWn2/NoqgUvquthM52JTTXP5TEM=; b=i6S+X8R0DiJZhoDngEG4yLvejsvoomsA2Jd9DkQQNSvomoIcUSZjspKUFHQwVc7Ti7 hElMaL+3PKdV9KTdCGVBSruIPi9YzIoNkEJDKmTbFeGhVbnZuUoJdVRCFm8sExIBPWCF NODTTwrqtMmH/tTVbE1GCIKuInIDKz9JE7ZdvBXSr+cAUR45/synZ1pGFIBrNLsrZgSK E1+nHfQvzv5MVooe+zcsHnSy82m6wni9j8LzI4jsgYUjslQfY6PWZyw4BvTihOhpURG+ 7cUFVW+fKjHMrOYCDNbJq+Ro+bdNr4gklbVONLPj2C/c7KVzeTeek2d8GQSdlN29KuBA nR/A==
X-Gm-Message-State: AOJu0YwjmAkM5U3t3ZOIOjAN6Tfg8B6ZW5C3+31JgHsNrsoeo6bz8TEo V9r4LOd2bhz2hjl1I+G50puKOqjPYP6xwd+Rg326Ygr7df3FF+nWhnV1qg==
X-Google-Smtp-Source: AGHT+IHdAZ7Y9mIdrsxTKMZ5njfHy2j783V0sQ5FQyRg0xn0FHlUAIsWBpIrO38lKCe8g09YNmcqLA==
X-Received: by 2002:a05:6300:668a:b0:1d9:2992:d6c2 with SMTP id adf61e73a8af0-1d92c49fc95mr18778503637.2.1729568191026; Mon, 21 Oct 2024 20:36:31 -0700 (PDT)
Received: from [127.0.0.1] (static-198-54-131-102.cust.tzulo.com. [198.54.131.102]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-20e7f0de3dasm33633745ad.226.2024.10.21.20.36.30 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 21 Oct 2024 20:36:30 -0700 (PDT)
Date: Mon, 21 Oct 2024 20:36:29 -0700
From: Tommy Jensen <tojens.ietf@gmail.com>
To: Bernie Volz <bevolz@gmail.com>
Message-ID: <86e132fa-dec3-4c44-9cb0-9c24177eeca1@gmail.com>
In-Reply-To: <7A2A3D9C-9FAE-4FE4-BA63-FA5D8E2A19FB@gmail.com>
References: <2B669533-AAEB-42CF-93D8-BF01AEEE6F5E@gmail.com> <7A2A3D9C-9FAE-4FE4-BA63-FA5D8E2A19FB@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_Part_7_155021467.1729568189367"
X-Correlation-ID: <86e132fa-dec3-4c44-9cb0-9c24177eeca1@gmail.com>
Message-ID-Hash: Z7WU3DU2AX4ATF7HQNAIYZHGODJFJSMB
X-Message-ID-Hash: Z7WU3DU2AX4ATF7HQNAIYZHGODJFJSMB
X-MailFrom: tojens.ietf@gmail.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-dhcwg.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: dhcwg@ietf.org, Milan Justel <milanjustel@microsoft.com>
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [dhcwg] Re: New Version Notification for draft-tojens-dhcp-option-concat-considerations-00.txt
List-Id: Dynamic Host Configuration <dhcwg.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/vy40AVN2VuRtSfDssdkAL3K32gY>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dhcwg>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Owner: <mailto:dhcwg-owner@ietf.org>
List-Post: <mailto:dhcwg@ietf.org>
List-Subscribe: <mailto:dhcwg-join@ietf.org>
List-Unsubscribe: <mailto:dhcwg-leave@ietf.org>
Oops, missed your second email while responding. Interesting point. I was hoping to avoid a full-blown inventory of options by using the categories defined in the text. Do you think there are non-concatenation-requiring options for which the guidance we give is wrong or insufficiently granular? We say options that do not require concatenation (and do not otherwise describe what should be done) are either fixed length, are lists of fixed length elements, and truly arbitrary length values. That breakdown ought to address "could reasonable require concatenation even though not defined" (the last two categories) without actually listing every option definition. Thanks, Tommy Oct 21, 2024 20:21:42 Bernie Volz <bevolz@gmail.com>: > Also, I should add that there are some options, such as relay agent option, that could be long (greater than 255 bytes) and I don’t think were explicitly called out as requiring this feature. > > The text in 3396 was written to force implementations to support this for those new options that required it (since we didn’t want to break existing implementations). But it was not prohibited for other options to use it (though the client or server had to be reasonably sure the partner supported it). > > If we changed this, then there would need to be a whole section on what options where allowed to use it (even though not required). > > - Bernie (from iPad) > >> On Oct 22, 2024, at 3:58 PM, Bernie Volz <bevolz@gmail.com> wrote: >> >> Hi: >> >> For this draft, you used the example of presumably two address options (51) in the same packet. Why would this occur? Seems to me that the server is broken already if it is doing this and the outcome is unpredictable anyway: >> 1) some clients use first instance >> 2) some clients use second (which could be same as first) >> 3) some clients concat and end up with invalid option (or use first 4 octets). >> >> Do you have a valid real world example where this is a problem? V4 options were designed to carry single value, except for newer options where lists are allowed and handled correctly (length, data, length, data, …). >> >> If you do, it could add more weight to this draft. Otherwise, not yet convinced the problem is real? >> >> - Bernie (from iPad) >> >>> On Oct 22, 2024, at 12:24 PM, tojens.ietf@gmail.com wrote: >>> >>> Good day dhc! >>> >>> Milan and I submitted a draft today that revisits RFC 3396, which talks about how DHCP options are concatenated, in the context of current deployments. Unfortunately, we have seen issues with interpreting 3396 strictly that major implementors have had to work around in non-standard ways. RFC 3396 continues to be referenced as new DHCP options are defined to make the new options concatenation-requiring. Therefore, we believe some deployment considerations are needed to clarify when concatenation is appropriate and if/how a peer can recover from non-standard behavior. >>> >>> Feedback is welcome! I know we are not meeting at IETF 121, but if anyone wants to also discuss this in the hallway in addition to the list, I will be there. >>> >>> Thanks, >>> Tommy >>> >>>> -----Original Message----- >>>> From: internet-drafts@ietf.org <internet-drafts@ietf.org> >>>> Sent: Monday, October 21, 2024 4:06 PM >>>> To: Milan Justel <milanjustel@microsoft.com>; Tommy Jensen >>>> <tojens.ietf@gmail.com> >>>> Subject: New Version Notification for draft-tojens-dhcp-option-concat- >>>> considerations-00.txt >>>> >>>> A new version of Internet-Draft >>>> draft-tojens-dhcp-option-concat-considerations-00.txt has been successfully >>>> submitted by Tommy Jensen and posted to the IETF repository. >>>> >>>> Name: draft-tojens-dhcp-option-concat-considerations >>>> Revision: 00 >>>> Title: DHCP Option Concatenation Considerations >>>> Date: 2024-10-21 >>>> Group: Individual Submission >>>> Pages: 7 >>>> URL: https://www.ietf.org/archive/id/draft-tojens-dhcp-option-concat- >>>> considerations-00.txt >>>> Status: https://datatracker.ietf.org/doc/draft-tojens-dhcp-option-concat- >>>> considerations/ >>>> HTML: https://www.ietf.org/archive/id/draft-tojens-dhcp-option-concat- >>>> considerations-00.html >>>> HTMLized: https://datatracker.ietf.org/doc/html/draft-tojens-dhcp-option- >>>> concat-considerations >>>> >>>> >>>> Abstract: >>>> >>>> DHCP has a length limit of 255 on individual options because of its >>>> one-byte length field for options. To accommodate longer options, >>>> splitting option data across multiple instances of the same Option >>>> Type is defined by [RFC3396]. However, this mechanism is required to >>>> be supported for all options. This leads to real-world >>>> implementations in the years since the RFC was published to deviate >>>> from these requirements to avoid breaking basic functionality. This >>>> document updates RFC 3396 to be more flexible regarding when DHCP >>>> agents are required to concatenate options to reflect deployement >>>> experiences. >>>> >>>> >>>> >>>> The IETF Secretariat >>>> >>> >>> >>> _______________________________________________ >>> dhcwg mailing list -- dhcwg@ietf.org >>> To unsubscribe send an email to dhcwg-leave@ietf.org
- [dhcwg] Re: New Version Notification for draft-to… tojens.ietf
- [dhcwg] Re: New Version Notification for draft-to… Bernie Volz
- [dhcwg] Re: New Version Notification for draft-to… Bernie Volz
- [dhcwg] Re: New Version Notification for draft-to… Tommy Jensen
- [dhcwg] Re: New Version Notification for draft-to… Tommy Jensen
- [dhcwg] Re: New Version Notification for draft-to… Bernie Volz
- [dhcwg] Re: New Version Notification for draft-to… Tommy Jensen
- [dhcwg] Re: New Version Notification for draft-to… Ted Lemon