[v6ops] Re: v6ops Digest, Vol 168, Issue 29
Ted Lemon <mellon@fugue.com> Fri, 09 August 2024 22:14 UTC
Return-Path: <mellon@fugue.com>
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 CAB62C18DB9B for <v6ops@ietfa.amsl.com>; Fri, 9 Aug 2024 15:14:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level:
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=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=fugue-com.20230601.gappssmtp.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 V5D3ZglTQ68m for <v6ops@ietfa.amsl.com>; Fri, 9 Aug 2024 15:14:03 -0700 (PDT)
Received: from mail-oo1-xc32.google.com (mail-oo1-xc32.google.com [IPv6:2607:f8b0:4864:20::c32]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8C3EC1840D2 for <v6ops@ietf.org>; Fri, 9 Aug 2024 15:14:03 -0700 (PDT)
Received: by mail-oo1-xc32.google.com with SMTP id 006d021491bc7-5d5b986a806so1676069eaf.1 for <v6ops@ietf.org>; Fri, 09 Aug 2024 15:14:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20230601.gappssmtp.com; s=20230601; t=1723241643; x=1723846443; 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=f6CLB61KVRho9Gm4583LGs2yMGJspTFmPZx4Elgl2sg=; b=BmhNZXvchH0hY1zN8BF+ZU8sqXG9bYOEQkjJuxB5ikZYcpSJw9pAsETa+e6Pe9sdOY /aEt6/70A5tOV0SooNTunBSECfB64cPtg9r7pi5R6EpYslvp3vX91gx+bsCPftMp7Uwb mKcpYKLWZiNkQxbDNp66oRBrtea60Vb2RqDc9877K9KuXMbMoysIuMNCBuok1333qpkO IVRfadZwImN4O1OsD7Y5KZPFFLpVeeyl2rOwjyjLzgUZvmWR6kxSJFoiQH5KFwDbn1r0 BvmQwPosP081esQ9nesZSZjCSMogOqfgtYnfEoKCPwyXAFXWLHs0+ZzDyz5EXe6SyVHY gJXg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1723241643; x=1723846443; 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=f6CLB61KVRho9Gm4583LGs2yMGJspTFmPZx4Elgl2sg=; b=t8KAeM3drTaM9NEMNXL4fnZNDA15i0/NVrhAizP+NakzUaWyCPwACE+PPfifKhUMGs FyavDI9Y7CcSkPdHK00Mq/q/JTk3Ecg2yhoLJCwb0IEBxuK+uu2Ez97JiTdbQiT9MK/I 3OWxFefxMFM8aZDtQvrCbzQBupNi3Gea3+aNJ95GOsj9DL85fB1y2HUxPu6Mizbngj5O KcdZczMhqYJAxjnuNXfmde5hz46F0S8WLrDrxdtFsb8zeJ5hPLK8GZv2jmeniOdeJWYk arGLJ99b8PcyYG49Ij9NCgBpJ7mokRerYBmWBqKAjnvLHqqYKZQ5CB995er47mFvE+ef 8sJw==
X-Forwarded-Encrypted: i=1; AJvYcCU7w5KUdnRHPTKF2ixbjvBzQSXrKiIu9fbXURtdsZNJNp5SWVHQMkY1bjeuPkxW3jmgrklFXX4Tb8F/0m6ukQ==
X-Gm-Message-State: AOJu0YzyKxXIjNgCQprMsB9SDzjN/HMC+j+7M1gj0du3JiKXoefWcJR6 RAnjdpnLIeunbP0AyKP/86wRVl/sdnX/9c3NxQrwUIU0w5bmgx7EVy6kacYw5Gyuq7XHumPVK3Z OspvSeTH9yYjDEYyb+qIiHHy7DIV9aHceEz4uOv7ua4lp3DeR0po=
X-Google-Smtp-Source: AGHT+IEHzQskIsyqkcAlfPfqfWffuhe4WeS4PjNjvzWz8TY3jmeDSNmT0zeKGcLwCXXmtG6XXFcCJLXLG66lMfu0iJ0=
X-Received: by 2002:a05:6870:d154:b0:260:2528:4e30 with SMTP id 586e51a60fabf-26c64373f92mr1169315fac.7.1723241642911; Fri, 09 Aug 2024 15:14:02 -0700 (PDT)
MIME-Version: 1.0
References: <df01e0f8-1b0d-4792-be2c-89a59da7de49.ref@swbell.net> <df01e0f8-1b0d-4792-be2c-89a59da7de49@swbell.net> <CAJgLMKte1H3FaoQOhc7_No=SNdczQFo2_mp2c1FvTOqLCRFm2g@mail.gmail.com> <6e70bed7-6f84-4a4a-90f8-fec1d10a599b@swbell.net> <CAJgLMKsXHcxzu8Kbrg1pu9SDkGDH0b1bWzW__CrfpDaSv3Joog@mail.gmail.com> <CACyFTPFakaDLdTJVc6d1HiR_oaedNOV76MRQxJp=+z95uQFVZQ@mail.gmail.com>
In-Reply-To: <CACyFTPFakaDLdTJVc6d1HiR_oaedNOV76MRQxJp=+z95uQFVZQ@mail.gmail.com>
From: Ted Lemon <mellon@fugue.com>
Date: Fri, 09 Aug 2024 18:13:52 -0400
Message-ID: <CAPt1N1=rQp5U4_X=2WvCV358S9Qm+E+_+gs_mgUJHP_68dYLmg@mail.gmail.com>
To: Daryll Swer <contact=40daryllswer.com@dmarc.ietf.org>
Content-Type: multipart/alternative; boundary="000000000000fd0701061f4775d5"
Message-ID-Hash: 3EXHL3GQ56RTCZIR5JT53VLQ2CY5PE7M
X-Message-ID-Hash: 3EXHL3GQ56RTCZIR5JT53VLQ2CY5PE7M
X-MailFrom: mellon@fugue.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-v6ops.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: The Multach's <jmultach@swbell.net>, v6ops@ietf.org
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [v6ops] Re: v6ops Digest, Vol 168, Issue 29
List-Id: v6ops discussion list <v6ops.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/7scREv1x8OesqQE5n_-5hmjhcm8>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Owner: <mailto:v6ops-owner@ietf.org>
List-Post: <mailto:v6ops@ietf.org>
List-Subscribe: <mailto:v6ops-join@ietf.org>
List-Unsubscribe: <mailto:v6ops-leave@ietf.org>
In order to do this, they would have to not renew a previously assigned prefix. I think some German telecoms used to do this as a privacy message, but it was operationally very difficult because it doubled demand for prefixes. Where are you seeing this irl, and how does it happen? Op vr 9 aug 2024 om 15:08 schreef Daryll Swer <contact= 40daryllswer.com@dmarc.ietf.org> > Tim, is there something we can do to encourage not only "more than a /64", > but also encourage "static ia_pd to ensure the customer will not experience > broken IPv6 connectivity due to ever changing prefixes". > > Too many ISPs out there do dynamic IPs and breaks SLAAC on the LAN. > > I feel this draft could be a powerful tool, in the hands of the end user > to get these ISPs doing the right way of IPv6 more often. > > -- > Sent from my iPhone > > > On Fri, 9 Aug 2024 at 7:37 PM, Timothy Winters <tim@qacafe.com> wrote: > >> Yes. I've seen several instances of /64 being used for container >> networks on CPEs. >> >> ~Tim >> >> On Fri, Aug 9, 2024 at 9:38 AM The Multach's <jmultach@swbell.net> wrote: >> >>> So are these considered a LAN link prefix assignment under 7084 L2: >>> >>> - Assignment of a /64 prefix for internal IPv6 communication between a >>> primary SoC and a secondary chip (e.g., a Wi-Fi chip which uses IPv6). >>> >>> - Assignment of a /64 prefix for usage by an internal container or VM. >>> >>> >>> On 8/9/2024 7:56 AM, Timothy Winters wrote: >>> > >>> > >>> > On Thu, Aug 8, 2024 at 10:58 PM The Multach's <jmultach@swbell.net> >>> wrote: >>> > >>> > The following, while being user focused, fails to take into >>> > account that >>> > some of those prefixes may be used internally (or reserved for >>> > internal >>> > use) by the CPE or for ISP purposes and not assignable: >>> > >>> > "SHOULD" (or an elongated exception for the above) would be more >>> > appropriate. >>> > >>> > LPD-4: After LAN link prefix assignment the IPv6 CE Router MUST >>> > make the >>> > remaining IPv6 prefixes available to other routers via Prefix >>> > Delegation. >>> > >>> > I think this covers that case. After local assignment, unused >>> > prefixes MUST be made available. >>> > LPD-2: The IPv6 CE Router MUST assign a prefix from the delegated >>> > prefix as specified by L-2 [RFC7084]. >>> > >>> > 7084 >>> > L-2: The IPv6 CE router MUST assign a separate /64 from its >>> > delegated prefix(es) (and ULA prefix if configured to provide >>> > ULA addressing) for each of its LAN interfaces. >>> > >>> > >>> > _______________________________________________ >>> > v6ops mailing list -- v6ops@ietf.org >>> > To unsubscribe send an email to v6ops-leave@ietf.org >>> > >>> >> _______________________________________________ >> v6ops mailing list -- v6ops@ietf.org >> To unsubscribe send an email to v6ops-leave@ietf.org >> > [image: 45efe8dfc775213ded0fc41c7d84ccccb0d6aa20] > > _______________________________________________ > v6ops mailing list -- v6ops@ietf.org > To unsubscribe send an email to v6ops-leave@ietf.org >
- [v6ops] Re: v6ops Digest, Vol 168, Issue 29 The Multach's
- [v6ops] Re: Dynamic addresses Jatin
- [v6ops] Re: v6ops Digest, Vol 168, Issue 29 Timothy Winters
- [v6ops] Re: v6ops Digest, Vol 168, Issue 29 The Multach's
- [v6ops] Re: v6ops Digest, Vol 168, Issue 29 Timothy Winters
- [v6ops] Re: v6ops Digest, Vol 168, Issue 29 Daryll Swer
- [v6ops] Re: v6ops Digest, Vol 168, Issue 29 Ted Lemon
- [v6ops] Dynamic addresses Brian E Carpenter
- [v6ops] Re: Dynamic addresses Daryll Swer
- [v6ops] Re: Dynamic addresses Brian E Carpenter
- [v6ops] Re: Dynamic addresses The Multach's
- [v6ops] Re: Dynamic addresses Daryll Swer
- [v6ops] Re: Dynamic addresses Ted Lemon
- [v6ops] Re: Dynamic addresses Marco Moock
- [v6ops] Re: Dynamic addresses Ted Lemon
- [v6ops] Re: Dynamic addresses Daryll Swer
- [v6ops] Re: Dynamic addresses Daryll Swer
- [v6ops] Re: Dynamic addresses Ted Lemon
- [v6ops] Re: Dynamic addresses Gert Doering
- [v6ops] Re: Dynamic addresses Daryll Swer
- [v6ops] Re: Dynamic addresses David Farmer
- [v6ops] Re: Dynamic addresses Daryll Swer
- [v6ops] Re: Dynamic addresses David Farmer
- [v6ops] Re: Dynamic addresses Daryll Swer
- [v6ops] Re: Dynamic addresses Brian E Carpenter
- [v6ops] Re: Dynamic addresses Daryll Swer
- [v6ops] Re: Dynamic addresses Brian Candler
- [v6ops] Re: Dynamic addresses Daryll Swer
- [v6ops] Re: Dynamic addresses Brian Candler
- [v6ops] Re: Dynamic addresses David Farmer
- [v6ops] Re: Dynamic addresses Daryll Swer
- [v6ops] Re: Dynamic addresses Tim Chown
- [v6ops] Re: Dynamic addresses Gert Doering
- [v6ops] Re: Dynamic addresses Daryll Swer
- [v6ops] Re: Dynamic addresses Gert Doering
- [v6ops] Re: Dynamic addresses Daryll Swer
- [v6ops] Re: Dynamic addresses Erik Auerswald
- [v6ops] Re: Dynamic addresses George Michaelson
- [v6ops] Re: v6ops Digest, Vol 168, Issue 29 Daryll Swer
- [v6ops] Re: Dynamic addresses N.Leymann
- [v6ops] Re: Dynamic addresses Marco Moock
- [v6ops] Re: Dynamic addresses Brian E Carpenter
- [v6ops] Re: Dynamic addresses Daryll Swer
- [v6ops] Re: Dynamic addresses Marco Moock
- [v6ops] Re: Dynamic addresses Daryll Swer
- [v6ops] Re: Dynamic addresses Marco Moock
- [v6ops] Re: Dynamic addresses Daryll Swer
- [v6ops] Re: Dynamic addresses Tim Chown
- [v6ops] Re: Dynamic addresses Gert Doering
- [v6ops] Re: Dynamic addresses Daryll Swer
- [v6ops] Re: Dynamic addresses David Farmer
- [v6ops] Re: Dynamic addresses Marco Moock
- [v6ops] Re: Dynamic addresses David Farmer
- [v6ops] Re: Dynamic addresses Daryll Swer
- [v6ops] Re: Dynamic addresses N.Leymann
- [v6ops] Re: Dynamic addresses Daryll Swer
- [v6ops] Re: Dynamic addresses Gert Doering
- [v6ops] Re: Dynamic addresses Brian E Carpenter
- [v6ops] Re: Dynamic addresses Daryll Swer
- [v6ops] Re: Dynamic addresses Ted Lemon
- [v6ops] Re: Dynamic addresses David Farmer