Re: [v6ops] New Version Notification for draft-ietf-v6ops-dhcp-pd-per-device-05.txt
Martin Huněk <martin.hunek@tul.cz> Mon, 06 November 2023 01:40 UTC
Return-Path: <martin.hunek@tul.cz>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03C5FC1C02AD for <v6ops@ietfa.amsl.com>; Sun, 5 Nov 2023 17:40:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.107
X-Spam-Level:
X-Spam-Status: No, score=-2.107 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, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, 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=tul.cz
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 Sl4T5eRjVXFB for <v6ops@ietfa.amsl.com>; Sun, 5 Nov 2023 17:40:54 -0800 (PST)
Received: from bubo.tul.cz (bubo.tul.cz [147.230.16.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 3037BC151701 for <v6ops@ietf.org>; Sun, 5 Nov 2023 17:40:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at tul.cz
Received: from asclepius.adm.tul.cz (unknown [147.230.238.39]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by bubo.tul.cz (Postfix) with ESMTPSA id 01B8D18050A06; Mon, 6 Nov 2023 02:40:46 +0100 (CET)
DKIM-Filter: OpenDKIM Filter v2.11.0 bubo.tul.cz 01B8D18050A06
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tul.cz; s=tul2021; t=1699234847; bh=rpm+ALUKVE82babTkrlB6XD+vJW78maAZMOrIPvLKX0=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=dVBPnLdL3wJCdR8A4pPdI5bd2iQpi/aibniJKbDzj7Pz3SjiCWTgjycZY7sGU+x1B QCwlHPgSJRydzpgY7E1NRwPkczkzeN2DTA61s0KPOLRvqksttI9egQCufWA7QjgyUA I45wOB4rXUiHDacJ4bKk/OXN0imR2G2gnVk3hX/8fRZts8rgtJtsHHwVP7M7dd6xcZ Vp2zKuaIt4ec+fmJCUvWPyH8+60Ipbhy7SX4Q+RQypOsclswr9TBlg5/kHM8lRTWTa xM37vEqU3UARI5wc/zZtu2bxdUhrylrvLpTL0is+dOelLjV5zBm5gqxeCeVrn9TmWL RErhHgQdLugGg==
From: Martin Huněk <martin.hunek@tul.cz>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>, Ole Troan <otroan@employees.org>, V6 Ops List <v6ops@ietf.org>
Cc: Xiao Ma <xiaom@google.com>, Jen Linkova <furry13@gmail.com>
Date: Mon, 06 Nov 2023 02:40:41 +0100
Message-ID: <4598146.F5Vx1aKkY9@asclepius.adm.tul.cz>
Organization: Technická univerzita v Liberci
In-Reply-To: <CAFU7BATnx3n2hPf5i2=9rH-gpV=oXkT6rxoQw2eQ9dY81mRNVw@mail.gmail.com>
References: <169919966581.36738.5162400304409089286@ietfa.amsl.com> <CAFU7BATnx3n2hPf5i2=9rH-gpV=oXkT6rxoQw2eQ9dY81mRNVw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart2947533.CK8QYMRfkY"; micalg="sha384"; protocol="application/pkcs7-signature"
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/J3YDIKRjqH7lMc1nRqEGKgUBtNc>
Subject: Re: [v6ops] New Version Notification for draft-ietf-v6ops-dhcp-pd-per-device-05.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 06 Nov 2023 01:40:59 -0000
Hi Jen, Dne neděle 5. listopadu 2023 17:17:13 CET, Jen Linkova napsal(a): > Hello, > > Following the conclusion of the WGLC (thanks to everyone who > commented!), we've submitted a -05 version with the following changes: > 1. Making it more clear that the draft requires the network to > delegate a SLAAC-suitable prefix, and /64 is currently required for > SLAAC to work - but it doesn't have to be like that in the future. > Examples also use /64. Brian, does it address your comment? Even in the hypothetical situation in which IETF agrees on making SLAAC work on longer prefixes, you will still need to maintain compatibility with older implementations that require /64. So the /64 is set to the stone. > 2. To address most of Ole's comments: > 2.1 Making it explicit that the draft only covers the network > behavior, while host requirements are out of scope. This seems to be an elegant way to solve the elephant-in-the-room problem. Pretend that the elephant is out of scope. The Client/Host behaviour makes a difference between address space hungry draft dangerous for a lot of address plans and the useful tool that can solve multiple entries in neighbour cache for all networks (even for those with a single /64). The difference in question is in what the client puts in the prefix-length hint field (together with 2nd point of section 7 - an unnecessary requirement of implicit min. /64). > 2.2 Clarifying that the network can support both flat and > hierarchical models - it's up to the host to specify the hint. Undefined behaviour of the host ... > 3. Rewriting examples in the prefix length consideration section to > make it clearer that the proposal does not require an excessive amount > of IPv6 space. But it does! It is the same address-space-hungry draft as the initial collin-00 version. The formula used in the -05 version of the draft means: If you have at least X+32 of IPv6, you can be in the same situation with IPv6 as you are in IPv4. Now, do we want to be in the same situation? Why migrate to IPv6, then? At least, I want to have some reasonable route aggregation and not look so often if I'm running out of space every time. This cost some additional space. If I can choose between having a "nicer," more aggregated addressing plan or allowing every host to extend the network, what do you think I will choose? I don't want to be in the same situation as I'm in IPv4. I agree with Gert. You can have /80s all you want, but you are not getting /64s from me. If your implementation requires it, then it is NAT66 for you, ND proxy, or IPv4 only. You choose. We are trying to solve the excessive amount of addresses used by some implementations by the excessive prefix size given to them. Is it a smart solution? Regard, Martin > > > > On Sun, Nov 5, 2023 at 4:54 PM <internet-drafts@ietf.org> wrote: > > > > A new version of Internet-Draft draft-ietf-v6ops-dhcp-pd-per-device-05.txt has > > been successfully submitted by Jen Linkova and posted to the > > IETF repository. > > > > Name: draft-ietf-v6ops-dhcp-pd-per-device > > Revision: 05 > > Title: Using DHCPv6-PD to Allocate Unique IPv6 Prefix per Client in Large Broadcast Networks > > Date: 2023-11-05 > > Group: v6ops > > Pages: 20 > > URL: https://www.ietf.org/archive/id/draft-ietf-v6ops-dhcp-pd-per-device-05.txt > > Status: https://datatracker.ietf.org/doc/draft-ietf-v6ops-dhcp-pd-per-device/ > > HTML: https://www.ietf.org/archive/id/draft-ietf-v6ops-dhcp-pd-per-device-05.html > > HTMLized: https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-dhcp-pd-per-device > > Diff: https://author-tools.ietf.org/iddiff?url2=draft-ietf-v6ops-dhcp-pd-per-device-05 > > > > Abstract: > > > > This document discusses an IPv6 deployment scenario when individual > > clients connected to large broadcast networks (such as enterprise > > networks or public Wi-Fi networks) are allocated unique prefixes via > > DHCPv6 Prefix Delegation (DHCPv6-PD). > > > > > > > > The IETF Secretariat > > > > > > >
- Re: [v6ops] New Version Notification for draft-ie… Jen Linkova
- Re: [v6ops] New Version Notification for draft-ie… Martin Huněk
- Re: [v6ops] New Version Notification for draft-ie… Mark Elkins
- Re: [v6ops] New Version Notification for draft-ie… Jen Linkova
- Re: [v6ops] New Version Notification for draft-ie… Brian E Carpenter
- Re: [v6ops] New Version Notification for draft-ie… Gert Doering
- Re: [v6ops] New Version Notification for draft-ie… Lorenzo Colitti
- Re: [v6ops] New Version Notification for draft-ie… Martin Huněk
- Re: [v6ops] New Version Notification for draft-ie… Lorenzo Colitti
- Re: [v6ops] New Version Notification for draft-ie… Delong.com
- Re: [v6ops] New Version Notification for draft-ie… jordi.palet@consulintel.es
- Re: [v6ops] New Version Notification for draft-ie… Owen DeLong
- Re: [v6ops] New Version Notification for draft-ie… jordi.palet@consulintel.es
- Re: [v6ops] New Version Notification for draft-ie… Alexandre Petrescu
- Re: [v6ops] New Version Notification for draft-ie… Frank Habicht
- Re: [v6ops] New Version Notification for draft-ie… Owen DeLong
- Re: [v6ops] New Version Notification for draft-ie… owen@Delong.com
- Re: [v6ops] New Version Notification for draft-ie… Owen DeLong
- Re: [v6ops] New Version Notification for draft-ie… Martin Huněk
- Re: [v6ops] New Version Notification for draft-ie… Tim Chown
- Re: [v6ops] New Version Notification for draft-ie… Philipp S. Tiesel
- Re: [v6ops] New Version Notification for draft-ie… Nick Buraglio
- Re: [v6ops] New Version Notification for draft-ie… Brian E Carpenter