From nobody Thu Sep 30 22:50:45 2021 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 27F273A0772 for ; Thu, 30 Sep 2021 22:50:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -18.097 X-Spam-Level: X-Spam-Status: No, score=-18.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.499, 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CIAPAUT9BNOy for ; Thu, 30 Sep 2021 22:50:38 -0700 (PDT) Received: from mail-io1-xd34.google.com (mail-io1-xd34.google.com [IPv6:2607:f8b0:4864:20::d34]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F26F3A0101 for ; Thu, 30 Sep 2021 22:50:38 -0700 (PDT) Received: by mail-io1-xd34.google.com with SMTP id i62so10385775ioa.6 for ; Thu, 30 Sep 2021 22:50:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=PNulzM9bYPT5M0rwY6k+RJ3MqN7WPt51pCW0pwH9nAY=; b=LIkXZEO6UMNUyTiIMbBp+EiAvALD/PBXbcRfwA1qBTzGm1FWOh7Ukbvcd+jvpCxXP0 0A/9a7et6ni+/yeWlVbW3O5kO1Ss9BrsABhgRcUeJ7RFQGPO1j2r+tRcoLlPDllNLi0I 7gNDT1/15qzW5AdB8pgDLeNar9XCt/5CDK+N6ZMTZ6ttyadxYZ+TbnlVamfoSB0IyI19 Hvf3p2589aeJ05w7WMcc40qL5bIEcdyxKKLMkJ08Cx3waENklwVHkFi5h6E0i5eArNqD RgFmK52kpDxrqaiaHzaElIpYX46Q8dA4x3gwzPCjwW+/jpG+kTvcASHU5uO0yRNiXjRl Ob+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=PNulzM9bYPT5M0rwY6k+RJ3MqN7WPt51pCW0pwH9nAY=; b=mZf3pnqzCKGCifC+Ar89c7KbQeEZw1UJsMCf2KVfE0fSVApkdx0IoCpIhjFsWHWQG6 e4YQduj63LvuLxwSKAET7XguWKmeBcakfEn4Rw+0604HgW53A7G4dduEAOVt0msOCG/x 9kqDo6j4tPULmAQCKtLdn/ECGrBibzMTBBstbZFV7UtiLWdxaZmKT8HpjxYO+MrzjkhG JqohoLQE1L8dAIRaY4evRGroYpjANicgie67vvOMZUS3bbQAVMCzAqJGMp8GwwGD8kRf QnEk9TCZ0TV4a21ucutKGWx3jSucBCc99Nfu8QSc+wtztglfY54wp63pIh4NMz6BtyUM XsXQ== X-Gm-Message-State: AOAM531gk8c7x7eyC42kGIMoeqYXAm32pw//i8p9Qg1bx8Ah3BWiX10d 1jdvdrbPhztHKume6kDPjIZdIozFhbcD/OmT6Ui8FRg1B1kBnA== X-Google-Smtp-Source: ABdhPJyNb+l1lMEt9un2xbWXuP9siWIYcahFce2FGFaFD4ziRP4CMbIap87MFQzbqkIiB3YgNnHLZDtbIoXIUlsempc= X-Received: by 2002:a05:6638:14d0:: with SMTP id l16mr8112543jak.142.1633067436824; Thu, 30 Sep 2021 22:50:36 -0700 (PDT) MIME-Version: 1.0 References: <0B533C71-5DB0-410D-A5A3-7E8FD559F214@delong.com> <5FAD5290-3616-4194-B783-D473DB38A89A@delong.com> <1e9444b30d964a5cb17ff419eca6cc35@huawei.com> <08D2885E-B824-48E8-9703-DCA98771FA37@delong.com> <1A6ED87B-666E-439C-852F-2E5C904C0515@delong.com> In-Reply-To: From: Lorenzo Colitti Date: Fri, 1 Oct 2021 14:50:24 +0900 Message-ID: To: David Farmer Cc: Owen DeLong , v6ops list Content-Type: multipart/alternative; boundary="00000000000077da3705cd44242e" Archived-At: Subject: Re: [v6ops] Implementation Status of PREF64 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Oct 2021 05:50:44 -0000 --00000000000077da3705cd44242e Content-Type: text/plain; charset="UTF-8" On Fri, Oct 1, 2021 at 2:15 PM David Farmer wrote: > So, is there a compromise somewhere between 1 and 2^64 addresses to be > had? Isn't it possible to request multiple addresses, that is to request > multiple IA_NA options? Then if the server returns a number of addresses > below a threshold, then refuse the addresses? > Well, let's find out. :-) Let's see if we get enough consensus to work on an RFC that says that all general-purpose DHCPv6 clients are entitled to receive N addresses; that any network that does not provide that number of addresses is in violation of the RFC; and that any client disabling the IPv4 stack if it does not get at least N addresses is in full compliance with all IETF specifications including RFC 8415. Personally I will be very surprised if you get consensus on any N even on this thread (let alone the WG or the IETF). The reason for that 1 is unacceptable to some folks, but any time you go beyond 1, then lots of infrastructure needs to be changed. And that's the rub here: IMO, when folks say they want DHCPv6, it's not because they want security or access control or tracking or whatever else. It's because they want to run their networks *in the same way as they do in IPv4*. That means an IPAM that maps one MAC to one IP and one DNS name, for example. If you're an enterprise, that's a legitimate desire: why pay costs that you don't think are necessary? The problem is that the enterprise does not pay the costs of NAT; device manufacturers, app developers, and users do. It would be good for users to stop having to pay those costs when we upgrade to IPv6. This is where we're stuck I think. Another reason for not having a hard number is that TCAM is expensive and that any number that would provide enough flexibiilty in the long term (e.g., one IPv6 address per app on the device) would likely be too expensive today. That's obviously easily solved with DHCPv6 PD, but the problem with DHCPv6 PD is that it's not IA_NA, and requires infrastructure to be changed. Same problem as above. Anyway, we can try this out as a thought experiment. I'll start: how about N=64? --00000000000077da3705cd44242e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, Oct 1, 2021 at 2:15 PM David Farmer <farmer=3D40umn.edu@dmarc.ietf.org> wrote:
S= o, is there a compromise somewhere between 1 and 2^64=C2=A0addresses to be = had? Isn't it possible=C2=A0to request multiple addresses, that is to r= equest multiple IA_NA options? Then if the server returns a number of addre= sses below a threshold, then refuse the addresses?=C2=A0
=

Well, let's find out. :-)

<= div>Let's see if we get enough consensus to work on an RFC that says th= at all general-purpose DHCPv6 clients are entitled to receive N addresses; = that any network that does not provide that number of addresses is=20 in violation of the RFC; and that any client disabling the IPv4 stack if it= does not get at least N addresses is in full compliance with all IETF spec= ifications including RFC 8415.

Personally I will b= e very surprised if you get consensus on any N even on this thread (let alo= ne the WG or the IETF). The reason for that 1 is unacceptable to some folks= , but any time you go beyond 1, then lots of infrastructure needs to be cha= nged. And that's the rub here: IMO, when folks say they want DHCPv6, it= 's not because they want security or access control or tracking or what= ever else. It's because they want to run their networks in the same = way as they do in IPv4. That means an IPAM that maps one MAC to one IP = and one DNS name, for example. If you're an enterprise, that's a le= gitimate desire: why pay costs that you don't think are necessary? The = problem is that the enterprise does not pay the costs of NAT; device manufa= cturers, app developers, and users do. It would be good for users to stop h= aving to pay those costs when we upgrade to IPv6. This is where we're s= tuck I think.

Another reason for not having a hard= number is that TCAM is expensive and that any number that would provide en= ough flexibiilty in the long term (e.g., one IPv6 address per app on the de= vice) would likely be too expensive today. That's obviously easily solv= ed with DHCPv6 PD, but the problem with DHCPv6 PD is that it's not IA_N= A, and requires infrastructure to be changed. Same problem as above.
<= div>
Anyway, we can try this out as a thought experiment. I&#= 39;ll start: how about N=3D64?
--00000000000077da3705cd44242e--