From otroan@employees.org Mon Oct 9 23:10:19 2023 Return-Path: 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 ADF5FC15108C for ; Mon, 9 Oct 2023 23:10:19 -0700 (PDT) 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_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=employees.org 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 cm-OQGR-m5wu for ; Mon, 9 Oct 2023 23:10:15 -0700 (PDT) Received: from proxmox01.kjsl.com (proxmox01.kjsl.com [IPv6:2607:7c80:54:6::6]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDFBFC14CF09 for ; Mon, 9 Oct 2023 23:10:15 -0700 (PDT) Received: from proxmox01.kjsl.com (localhost.localdomain [127.0.0.1]) by proxmox01.kjsl.com (Proxmox) with ESMTP id 4A62BE357A; Tue, 10 Oct 2023 06:10:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=employees.org; h=cc:cc:content-transfer-encoding:content-type:content-type :date:from:from:in-reply-to:message-id:mime-version:references :reply-to:subject:subject:to:to; s=prox2023; bh=XTw0k+8Gw7KTiQhn ZZR1rR5VWu+K4yxfyeffmymeMyU=; b=GSUUHXbVUf6mvDnE2nx/KV2vuDJwBKxU 9K0h1/xGoK2X56tsxM3FMciHMRpFxlvyMZ+VrirOXXEqjk1Nb5zXJl/DAZjbG8/p he19JtkgNV8aZQrJYBqcz9oMZ2kXI8r7PRGiCDVl2EpJOYMzJCaKv0DuBpjnLT6F LfJ7/6UyAjHDubKy6ZxrGyq2jkaHtcXK5+v0T9AX8AzFuI0wU7uVo7xvxzVhYyKd gsCECUD15gm3xjrCy+LQRmBgqH534fwobFRqoXHDjQgPHeDQt7jLbNdWMF8mJvzs B36Hye2KztYxa7gam7AQ21kd7vchgBBmrID519DIN4VomLKiCdKCcQ== Received: from clarinet.employees.org (clarinet.employees.org [IPv6:2607:7c80:54:3::74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by proxmox01.kjsl.com (Proxmox) with ESMTPS id 229A9E1570; Tue, 10 Oct 2023 06:10:15 +0000 (UTC) Received: from smtpclient.apple (unknown [IPv6:2001:4650:c3ed:37a:1107:65f5:fd7e:6b6d]) (using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by clarinet.employees.org (Postfix) with ESMTPSA id 03A8E4E12DC2; Tue, 10 Oct 2023 06:10:12 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.100.2.1.4\)) From: Ole Troan In-Reply-To: Date: Tue, 10 Oct 2023 08:10:01 +0200 Cc: Jen Linkova , V6 Ops List , Pascal Thubert , Vasilenko Eduard , "Joel M. Halpern" , Brian E Carpenter , Paolo Nero Content-Transfer-Encoding: quoted-printable Message-Id: References: <169660647031.23597.13067349132781805398@ietfa.amsl.com> <2AE8C0BD-4290-45B2-82A6-7DE89BBD6EAD@employees.org> To: Lorenzo Colitti X-Mailer: Apple Mail (2.3774.100.2.1.4) Archived-At: Subject: Re: [v6ops] Continuing WGLC: ietf-v6ops-dhcp-pd-per-device-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.39 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Oct 2023 06:10:19 -0000 > On Mon, Oct 9, 2023 at 5:29=E2=80=AFPM Ole Troan = wrote: > I think section 8 is enough and that this could be deleted. > It=E2=80=99s regardlessly an operational choice. > Alternatively say something like: > =E2=80=9CIf SLAAC is {needed, required, used}, the server MUST provide = a prefix short enough=E2=80=A6=E2=80=9D >=20 > Section 8 is what motivates this recommendation, but by itself, = section 8 is clearly more about discussion than about recommendations. I = think it's useful to have that requirement in the server consideration = sections as well, to provide clear advice to implementors and guarantee = interoperability with the most devices and scenarios (e.g., RFC 7084 = requires at least one /64). I suggest it=E2=80=99s replaced with guidance rather than requirement. (MUSTs in informational documents aside). > Garbage collection is going to be a challenge in this solution. > Regardless of deployment you will have a fairly small number space, = that can easily be exhausted. >=20 > The only way you can deal with that is by using short lease timers, = right? > Would it be worth providing some guidelines regarding that? At least = describe the problem? >=20 > Actuall, this is less of a problem than it sounds, because this model = is effectively identical to how we manage IPv4 addresses today. The = draft sort of already says this in the "prefix pool allocation" section, = but perhaps we could add an extra sentence to clarify: >=20 > =3D=3D=3D=3D > This is very similar to how address pools are allocated when using = DHCP to assign individual addresses (e.g., DHCPv4 or DHCPv6 IA_NA), = where each link has a dedicated pool of addresses, and clients on the = link obtain addresses from the pool. In this model, each link's pool can = be sized according to the expected maximum of devices on a particular = link, similar to how DHCPv4 pools are sized today. For example, if the = network assigns a /64 to every client, then any link that is assigned an = IPv4 prefix of /X (e.g., X=3D/18, X=3D/24) would require a corresponding = prefix pool of size X+32 (e.g., X=3D/50, X=3D56). > =3D=3D=3D=3D I think I would like to see some operational guidance. Also, regarding the prefix pool idea. When this was last discussed in = SNAC the opinions seemed to lean towards flat allocation. That=E2=80=99s = a lot more efficient for address utilisation. The pool approach is = hierarchical. At least at the first level. If an EN has 3 downstream links, I think the network should get a PD = request with 3 IA_PD options. Assigning a /64 to each. Instead of a = request of a /62 with a prefix hint. The document likely needs some = guidance regarding that. Not quite sure how the text should look like. Cheers, Ole=