From lorenzo@google.com Mon Nov 6 01:00:31 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 CF30FC1B033C for ; Mon, 6 Nov 2023 01:00:31 -0800 (PST) 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=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 ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rYmgtYB4nFPO for ; Mon, 6 Nov 2023 01:00:31 -0800 (PST) Received: from mail-qk1-x72a.google.com (mail-qk1-x72a.google.com [IPv6:2607:f8b0:4864:20::72a]) (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 33240C1B0318 for ; Mon, 6 Nov 2023 01:00:31 -0800 (PST) Received: by mail-qk1-x72a.google.com with SMTP id af79cd13be357-7789577b53fso279474485a.3 for ; Mon, 06 Nov 2023 01:00:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1699261230; x=1699866030; 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=CtNMeju4nFrBjXLEL5CCelMnxmGQ2v0sggUqaHEjeuw=; b=lx45wlRWZtaCUmMiAypVgCKBLgY0ViBBu4XOLR5tyyKfSJzDrNaykT9247amKdzrf3 JkdHpDt5l7EdUL4ICw+7DAW1K5tGYfGCv4bc41p1CqMfjVrn1TShzABLGmg5ya0kNrPg TBdj9HfZavuA3/wGZtp+lNcFbMHlyerjqE+/EnujscEu6xXTP2d/B617axSHfKq+xMJv qO/yybJB5yyUQhhLz59H/x75QFrr9i0hJv62xNFYebSTSTOGJxuZGWMUNZ8MX5Remlh4 uijen4By8xtVe7pKDtWTYsnCts6zR6uxpSFnhW2MToCJXTK0Yl+Asrp37GoqCPAOOC6F 2Rug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1699261230; x=1699866030; 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=CtNMeju4nFrBjXLEL5CCelMnxmGQ2v0sggUqaHEjeuw=; b=NE7Hn+fIKU0qRmhn+2Hi5g6/TRBw0hy0OlzOb1SExaDXR1FVeEkVjQG2ioreqRjcno FYgg0zApy3emKQPUNwic23bqIOTZDsbRLprxokRGdFIsvvd/kPufezFpLFx/ELRCzNBm aF6sb0xzkDGjJxzsI+5ajZpC4gbxfKvYZMAI82rFTWkEbdsm+YwzINeoI0OB4O91gblR K0FHk7MMcUxl5XPcoeKEsvq67ORdxeCqGQqErKOIAw2ayyMmoMtlIiL0fvP8zZVQic6r WVVLPngyhyTFx+3mgHXZ+6trq1UndqaW9mSPyE8niHp7gLmhOHkTceZgTtoJCc4uQw5F 9JMQ== X-Gm-Message-State: AOJu0YxtTkw52Zt7C5tWzn2BzsbNOEKNM+6yqFF8cg0U4UDqPf2yEVMX p1uvGN1ABcQpc1odvnU0W9Etb6R9+Qph60yFHD1Xvg== X-Google-Smtp-Source: AGHT+IG4RlumlsJeiG4tSA2HkR3Ivv1B8HaESgbwRuuU1w3fa93tFmJFEgKyoG7d9LY7d/Y/3DhwNvqhtrW22RM1E2Q= X-Received: by 2002:a05:6214:1313:b0:66d:4018:da9c with SMTP id pn19-20020a056214131300b0066d4018da9cmr36786945qvb.9.1699261230029; Mon, 06 Nov 2023 01:00:30 -0800 (PST) MIME-Version: 1.0 References: <169919966581.36738.5162400304409089286@ietfa.amsl.com> <4598146.F5Vx1aKkY9@asclepius.adm.tul.cz> In-Reply-To: <4598146.F5Vx1aKkY9@asclepius.adm.tul.cz> From: Lorenzo Colitti Date: Mon, 6 Nov 2023 09:00:14 +0000 Message-ID: To: =?UTF-8?Q?Martin_Hun=C4=9Bk?= Cc: Brian E Carpenter , Ole Troan , V6 Ops List , Xiao Ma Content-Type: multipart/alternative; boundary="000000000000ff92ff060978154d" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Nov 2023 09:00:31 -0000 --000000000000ff92ff060978154d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Nov 6, 2023 at 2:41=E2=80=AFAM Martin Hun=C4=9Bk wrote: > 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? > It's not the same situation. As the draft explains, x+32 is 32 times better than IPv4 if we never move beyond 2000::/3. If we move beyond 2000::/3, it's 256 times better than IPv4. Whether any given network has enough space for that is up to the operators and the RIRs. Based on your comments, it's clearly not enough for your network. That's OK - whether a network uses this model is up to the network, and it's pretty clear that there are some networks, like home networks with only a /64 or a /60, that will never be able to run this model due to lack of space. FWIW, I think you said that in order to use this you'd need to assign a /49 to your Wi-Fi network? That doesn't seem unreasonable to me, or to other operators that are part of this discussion. Remember, what we are trying to do here is a compromise: provide to network operators the control and tracking that they like to have via DHCPv6, while ensuring that connected devices can support pretty much any use case, including hosts forming unlimited addresses, plugging in routers, and doing a moderate amount of network extension with end-to-end connectivity and without NAT. We think this model has a lot of advantages, but it's definitely not the only one. 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 yo= u, > ND proxy, or IPv4 only. You choose. > I hate to say it, but... network operators saying, "my network, my rules" and insisting that devices will only have the amount of address space that they think they need is precisely why host implementers don't trust networks to do the right thing. This is why we need a fixed boundary - otherwise we end up with a race to the bottom that ends at /128. At the moment, the only possible fixed boundary is /64, because once the device gets a /64, it can do whatever it wants, and extend the network all it wants, using SLAAC. If we make SLAAC run on longer prefixes, then maybe we'll all agree on one size. But who knows if that will work. Just like you say, "you can have all the /80s you want, but you're not getting /64s", some other operators saying, "you can have all the /128s you want, but you're not getting /80s". One thing at a time. If we make this model work with /64s, maybe it's possible to imagine changing SLAAC. --000000000000ff92ff060978154d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Nov 6, 2023 at 2:41=E2=80=AFAM Martin Hun=C4=9Bk <martin.hunek@tul.cz> wrote:
If you have at least X+3= 2 of IPv6, you can be in the same situation with IPv6 as you are in IPv4. N= ow, do we want to be in the same situation? Why migrate to IPv6, then?
<= /blockquote>

It's not the same situation. As the dra= ft explains, x+32 is 32 times better than IPv4 if we never move beyond 2000= ::/3. If we move beyond 2000::/3, it's 256 times better than IPv4. Whet= her any given network has enough space for that is up to the operators and = the RIRs. Based on your comments, it's clearly not enough for your netw= ork. That's OK - whether a network uses this model is up to the network= , and it's pretty clear that there are some networks, like home network= s with only a /64 or a /60, that will never be able to run this model due t= o lack of space.

FWIW, I think you said that in or= der to use this you'd need to assign a /49 to your Wi-Fi network? That = doesn't seem unreasonable to me, or to other operators that are part of= this discussion.

Remember, what we are trying= to do here is a compromise: provide to network operators the control and t= racking that they like to have via DHCPv6, while ensuring that connected de= vices can support pretty much any use case, including hosts forming unlimit= ed addresses, plugging in routers, and doing a moderate amount of network e= xtension with end-to-end connectivity and without NAT. We think this model = has a lot of advantages, but it's definitely not the only one.

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.

I = hate to say it, but... network operators saying, "my network, my rules= " and insisting that devices will only have the amount of address spac= e that they think they need is precisely why host implementers don't tr= ust networks to do the right thing.

This is why we= need a fixed boundary - otherwise we end up with a race to the bottom that= ends at /128. At the moment, the only possible fixed boundary is /64, beca= use once the device gets a /64, it can do whatever it wants, and extend the= network all it wants, using SLAAC. If we make SLAAC run on longer prefixes= , then maybe we'll all agree on one size. But who knows if that will wo= rk. Just like you say, "you can have all the /80s you want, but you= 9;re not getting /64s", some other operators saying, "you can hav= e all the /128s you want, but you're not getting /80s". One thing = at a time. If we make this model work with /64s, maybe it's possible to= imagine changing SLAAC.
--000000000000ff92ff060978154d--