From lorenzo@google.com Mon Oct 9 17:59:45 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 39B26C1519BF for ; Mon, 9 Oct 2023 17:59:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.609 X-Spam-Level: X-Spam-Status: No, score=-17.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, 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, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 NLSxBYYIIeay for ; Mon, 9 Oct 2023 17:59:43 -0700 (PDT) Received: from mail-qk1-x736.google.com (mail-qk1-x736.google.com [IPv6:2607:f8b0:4864:20::736]) (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 1EDD9C151087 for ; Mon, 9 Oct 2023 17:59:43 -0700 (PDT) Received: by mail-qk1-x736.google.com with SMTP id af79cd13be357-7742da399a2so341011285a.0 for ; Mon, 09 Oct 2023 17:59:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1696899582; x=1697504382; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=BHo8zzE5/uG9YMWD86xaWMV8NZb7oP9z2t0khHaWCzg=; b=QO133iZA3XRI8gB3UlpYpT5fdLegnNLyikYwY5Y8tJojWDROxZauMDVbF8KhUq+7U1 q8tF+ZXQR1SSqvWJxTFMzV0do7wrtsQ1KTu2p/SqKvYyW9vzzvJ7BZe/CKRkI262iYg3 mTKgzA7foUO17s8xNbAH1LYFL2NChXkbs8ZfwoJf2dLXf4QH2GLLlDmH/5xx1J4/ndX5 81rw+WB7reEm25d8end9H7gAo2qZUAZOT53+kNTXLhNSkAVd2ImmJ44tuLJT03A2i38+ 7SWGYs3AlUWzdf8e2hz0+Nn/cevvaxdrT5XfQi2pY1VwJlJdqEY4qk9JRoqFm6zqrfIo 0Tog== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1696899582; x=1697504382; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=BHo8zzE5/uG9YMWD86xaWMV8NZb7oP9z2t0khHaWCzg=; b=eVskWx+dRCas+2HDcrw1YgWf77aOlh4PSDc/uADpWZ1Jq0qN4W37yKIx+2xxtln1Zb x7H/sGzv3NAKa2RIqv9itNFDYP5yEoJeYEKcn3aVAuWfhxzqaTcfbaKVjWu+8+PN3H/u pAmTgF0/q+tuQrVU7iuXriLUy+JJq6JPXGruPXtZpG/ko/FS6detJaXPj/yFX7b92vpf hAFqPLzRehv48ETUW54CJrXSQ4lTY60lNZXxJxv4gpK6m32/hkvgbuKenbgOEuPsyyQh ccr8XBYKOYwpnsWFjJEGF9/W4kd/70Enom6hS9BsWv0BKswXP+mztvBHWcx841yvnTmU hhaA== X-Gm-Message-State: AOJu0Yxsvq7L1u7RFZtbinvzFPysy4Sa98AkATmx1y3U9vOG93j8bKE4 VLCr4uqqEY2QL2B6GVHb5T1BdwiPAHOmlucX0/tCYw== X-Google-Smtp-Source: AGHT+IH4m+gt9KPusiILYgkvXytYsib6IN6AL1CPi+uM2SoYBxWyS+pcdb0GFQ80MMnpqJ4fuRD6tYjLe3riprhZvZk= X-Received: by 2002:a05:6214:2427:b0:65a:f5e3:5ad1 with SMTP id gy7-20020a056214242700b0065af5e35ad1mr21226928qvb.48.1696899581896; Mon, 09 Oct 2023 17:59:41 -0700 (PDT) MIME-Version: 1.0 References: <169660647031.23597.13067349132781805398@ietfa.amsl.com> <2AE8C0BD-4290-45B2-82A6-7DE89BBD6EAD@employees.org> In-Reply-To: <2AE8C0BD-4290-45B2-82A6-7DE89BBD6EAD@employees.org> From: Lorenzo Colitti Date: Tue, 10 Oct 2023 09:59:30 +0900 Message-ID: To: Ole Troan Cc: Jen Linkova , V6 Ops List , Pascal Thubert , Vasilenko Eduard , "Joel M. Halpern" , Brian E Carpenter , Paolo Nero Content-Type: multipart/alternative; boundary="000000000000ccb718060752384c" 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 00:59:45 -0000 --000000000000ccb718060752384c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Oct 9, 2023 at 5:29=E2=80=AFPM Ole Troan wro= te: > 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 > 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). > 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. > > 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? > 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: =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 --000000000000ccb718060752384c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Oct 9, 2023 at 5:29=E2=80=AFPM Ol= e Troan <otroan@employees.org> 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 pr= efix short enough=E2=80=A6=E2=80=9D

Garbage collection is going to be a challenge in this solution.
Regardless of deployment you will have a fairly small number space, that ca= n easily be exhausted.

The only way you can deal with that is by using short lease timers, right?<= br> Would it be worth providing some guidelines regarding that? At least descri= be the problem?

Actuall, this is less of a p= roblem than it sounds, because this model is effectively identical to how w= e manage IPv4 addresses today. The draft sort of already says this in the &= quot;prefix pool allocation" section, but perhaps we could add an extr= a sentence to clarify:

=3D=3D=3D=3D
This is very = similar to how address pools are allocated when using DHCP to assign indivi= dual addresses (e.g., DHCPv4 or DHCPv6 IA_NA), where each link has a dedica= ted pool of addresses, and clients on the link obtain addresses from the po= ol. In this model, each link's pool can be sized according to the expec= ted maximum of devices on a particular link, similar to how DHCPv4 pools ar= e sized today. For example, if the network assigns a /64 to every client, t= hen 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
--000000000000ccb718060752384c--