[IPv6]Re: Working Group Last Call for <draft-ietf-6man-pio-pflag>

Jen Linkova <furry13@gmail.com> Tue, 11 June 2024 06:11 UTC

Return-Path: <furry13@gmail.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8ECE3C1519AB for <ipv6@ietfa.amsl.com>; Mon, 10 Jun 2024 23:11:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.859
X-Spam-Level:
X-Spam-Status: No, score=-1.859 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, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 NJSRS-ZY8EGP for <ipv6@ietfa.amsl.com>; Mon, 10 Jun 2024 23:11:11 -0700 (PDT)
Received: from mail-lj1-x229.google.com (mail-lj1-x229.google.com [IPv6:2a00:1450:4864:20::229]) (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 308C6C151549 for <ipv6@ietf.org>; Mon, 10 Jun 2024 23:11:06 -0700 (PDT)
Received: by mail-lj1-x229.google.com with SMTP id 38308e7fff4ca-2ebdfe26242so24118761fa.0 for <ipv6@ietf.org>; Mon, 10 Jun 2024 23:11:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1718086264; x=1718691064; darn=ietf.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=Q5npfXW1boU+OC55sQVJArqPCYQTr7/UqY9+5cf1KFM=; b=nVnbik+6TPpDxzDY1RkQdau5AIjssnvNGbZtamzV5gY+42gDUFkZql0I8r13ezJ5Oz 4GpDp5Xs0NpJyF9w6pNLOULzmPDcU+aTmIcwdzfx9F1EeRg/110vyCA95Rbpg1N3TKXO MTd1jjgqiL5+B7f4XF5ekhfvcXfYsIOT3Hk3YoLLPrPs7EmVRKfECidrYSbS8jTJg/45 s3F+x0+K2FpzwknBDUNIPQy76jpxAwe2iWuizQVpnp9KBXzISLT+iJJVmhIJgt8ccxCa ou0UiNkCkXqsMnS348h8gFgi8LZ5JWY9iBYuQ5lyTFWf24SCmYuh2Sz2v06CQyP3U7uQ GNwg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1718086264; x=1718691064; h=content-transfer-encoding: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=Q5npfXW1boU+OC55sQVJArqPCYQTr7/UqY9+5cf1KFM=; b=vII3RxVL+OrrLDriz+fNHuIq4TDfV7jJROAwnc6EIVBof5j2ntycRcdP+L9Dqso2Ky KthTNDvD7h7pPP0bNNxgb/7cIzuU2AHQdCJ9divQ8b/Gn//sfM7CbDTYqgcVMUbipyJm 6FRZEG5H0gPHApbvVEF1Bkuhw/LBIyRgJp+N6HEaKw8Vz/WDTOF7PVKQ6I1taRdaXs0Y ILkrPjC5YE15IZVJrBPhm2Rrm5rtpfcOmO4BcwwvoLwb+db7i+VPUCH9RFmJ3Rj9JLem k00vXWZ7y60G+5kBAjEj8927WKx0KM2Oyn8upTh+r7YHwm6yZzgE12AON+aIAP71cUDS nSDg==
X-Forwarded-Encrypted: i=1; AJvYcCXFhZEQ8oD8rvyl4DjuuEAxQ6gzs11PJcO5lXq45LhbFJKmhA2KPOlGWk8e5KuhZjmWMqMkdr+GgVFAQbB0
X-Gm-Message-State: AOJu0YyGFXvkNaoH8megZ3A4T+fmchTHa6WytN6gEqMSXaFR5LAKN15o 2mE30DbaBqA6YVQSsKxpQlLt5fBsJkmRWr/S8XHB5brchqATuUgOCROAX2W9Bmu5dEFx4oBtHZL 721ANLkdfldeWCT8vPl9hMhzIADHG1A==
X-Google-Smtp-Source: AGHT+IHclHxhUKPoQ8LU/TLj4kh6RhmJdij4jwmEin5gi6yEo+f2XrbtXsFtqYiH312r/FG7Gx9Y4AMMSuH/oi6qNts=
X-Received: by 2002:a05:651c:b0a:b0:2eb:e405:dc with SMTP id 38308e7fff4ca-2ebe405027dmr45167211fa.14.1718086263889; Mon, 10 Jun 2024 23:11:03 -0700 (PDT)
MIME-Version: 1.0
References: <18236.1717011844@obiwan.sandelman.ca> <2AD87DE1-075E-45E7-A682-8042F04EF59A@employees.org> <89dbde8c-82c9-4a2e-9cff-8d4fd2d8fbe6@gmail.com> <9E7BEA1C-4597-4142-A3AB-57211C436197@employees.org> <CAKD1Yr0iR+RZHvuquCGYfntiD+K7-PdkvGJzHLx1PLrFqJ=Z4Q@mail.gmail.com> <47BF97B8-2BEE-47CC-A965-C6BB112990AB@employees.org> <4bcfcd71-d295-433d-813f-1183c7da3cf3@gmail.com> <CAKD1Yr1CL_Jw4O-iETF6T1v8EL_Lj-fMi6EV=3MgPhN+M2tc8w@mail.gmail.com> <84f6e699-5587-4407-a566-b031c31e2cd5@gmail.com> <CAMGpriWqD99OzdOaJU7_nQTwvD=o1wsVxOQrbMqy5sH7sX7gwA@mail.gmail.com> <95dfd2e9-25da-4449-b740-724804a34735@gmail.com> <CAKr6gn12Vq9xJWGH+Na6xhDXXsW2XSDCnLegjXMRLN8KJ2CEZQ@mail.gmail.com> <CAKD1Yr24RyW_oxhY3iz5nEdXd0EZENy9cZBo7tfxLqLLMHOX_g@mail.gmail.com> <e2e406e1-1231-4c28-8163-c0e220da7453@lear.ch>
In-Reply-To: <e2e406e1-1231-4c28-8163-c0e220da7453@lear.ch>
From: Jen Linkova <furry13@gmail.com>
Date: Tue, 11 Jun 2024 16:10:52 +1000
Message-ID: <CAFU7BATpcSFGNNEgfZWgmHEEp2S_w_Fk4v0KQf4nRru2qFyCvQ@mail.gmail.com>
To: Eliot Lear <lear@lear.ch>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Message-ID-Hash: YPCBZ3VK6EH73IQNV5HHPBZMYXFSN3BN
X-Message-ID-Hash: YPCBZ3VK6EH73IQNV5HHPBZMYXFSN3BN
X-MailFrom: furry13@gmail.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-ipv6.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: Lorenzo Colitti <lorenzo=40google.com@dmarc.ietf.org>, George Michaelson <ggm@algebras.org>, 6man WG <ipv6@ietf.org>
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [IPv6]Re: Working Group Last Call for <draft-ietf-6man-pio-pflag>
List-Id: "IPv6 Maintenance Working Group (6man)" <ipv6.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/6blBQJP9HmkY9HiGjYX-_0Bkq0U>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Owner: <mailto:ipv6-owner@ietf.org>
List-Post: <mailto:ipv6@ietf.org>
List-Subscribe: <mailto:ipv6-join@ietf.org>
List-Unsubscribe: <mailto:ipv6-leave@ietf.org>

On Mon, Jun 3, 2024 at 7:35 PM Eliot Lear <lear@lear.ch> wrote:
> On 03.06.2024 06:37, Lorenzo Colitti wrote:
>
>> FWIW, if we do want to change the subnet boundary from /64 to /80, one of the ways to do so might be to do that a decade in advance and tie it to one of the other prefixes (say, 3000::/4). After 10 years have passed, hopefully most of the implementations will be ready. But again, it's not clear that we actually need to do this now.
>
> Without taking a position on whether /64->/80 is a good or a bad idea, while I like the idea of taking time to make a change of this nature, I would not be a fan of tying yet more semantics to IP addresses.  For one thing, what do you do if an implementation doesn't make the change in that time table and still lands in this new block?

I'd say it would be similar to a scenario when a device which doesn't
support SLAAC at all lands on a SLAAC-only network. Or a device which
can not process certain flags or certain RA options and ignore the
whole RA (all cases are examples from real life) - so such devices
would violate a MUST, would not work and need to be fixed.

-- 
Cheers, Jen Linkova