[v6ops] Re: Dynamic addresses
Daryll Swer <contact@daryllswer.com> Tue, 13 August 2024 06:46 UTC
Return-Path: <contact@daryllswer.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 444D7C14F681 for <v6ops@ietfa.amsl.com>; Mon, 12 Aug 2024 23:46:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.107
X-Spam-Level:
X-Spam-Status: No, score=-2.107 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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=daryllswer.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 e6ayAhgsKfsi for <v6ops@ietfa.amsl.com>; Mon, 12 Aug 2024 23:46:17 -0700 (PDT)
Received: from mail-pl1-x630.google.com (mail-pl1-x630.google.com [IPv6:2607:f8b0:4864:20::630]) (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 B76E4C14F600 for <v6ops@ietf.org>; Mon, 12 Aug 2024 23:45:44 -0700 (PDT)
Received: by mail-pl1-x630.google.com with SMTP id d9443c01a7336-1fc52394c92so46978705ad.1 for <v6ops@ietf.org>; Mon, 12 Aug 2024 23:45:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=daryllswer.com; s=google; t=1723531543; x=1724136343; 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=fPrkK9il5dSjh6VZmRkdu1my8arTfCZAAQyUpWf9WUU=; b=EZIF13OB9B8NFxqRAZ30U7XE7CqAHqkoWHiPW9n4WQ/bKtBWbV8NDZWC7sTSkIZYoq 0f9N36OUCQYJsh/HmnsnfPYmNibkHhcztDOrgWYAAQJyP50DsBlcoOP/HkHEHmoTdmF7 M+LH+H1ewi5uag6fgs3Wi/xF2r+PxcwOU/3wWHuz4hwjEpCzbcqYa7935ubbTK1WI5g6 DBaRL0qu799vkz2S2cpldOANAxSSj90clmvBYOhzJXviYYld/wwtcq6W/gIoh0wDn6hw jesWjBoG/AAcJHS1gZHnBy+103+8Vjh0TGjZrW8bNz7urE3z6PD0iRDyGIkUd5KS7wfX YRTQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1723531543; x=1724136343; 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=fPrkK9il5dSjh6VZmRkdu1my8arTfCZAAQyUpWf9WUU=; b=F0Al3142+ETTnkGPfzeMoRYmQ0DnSQ4wflFB+xlVHX/K6iIogIescuHAdAjB1u51Sd DEBOF4bYJh+xAHLSptLHHYHxL2waQf/b52wDzL+3r9qap0EJKp9Qs6dy+gu+fRUgjZNV dY74dh9D7RpDjYluP8lGTKehtc/Z3LRBCkdyKRkakXLfTVBKPxra9O+UyYxU+Fz5t5LL y0PdhiszK3QkkrK+gs/+jDbp0ELCbcSjRLfFUBTbDPAqqzbjZleIJ6omL+a6AaMh2DNI ZhCxtW44r0UOKQTwoJVX26LB3vOLbcfuIyWPAnaQ7oJJh+56kGfU7dwlH8uZzMcpagO7 aTqQ==
X-Gm-Message-State: AOJu0YwKKnuDDbVvx5h1JOLW7Op81wrxzDQfe7BQOVuk1RzzEiJ21j5U nrAmfZPb34Oj24mdrKeWRG+Uo0pe5Mbli65E/HXW3pTLinDwP+hQVCCSlmUkPu8oWBzrmjLsIA3 zv4E=
X-Google-Smtp-Source: AGHT+IHByvLdJDiN/COsyL2WB9j8NLw36FJ0lQRK0z2nzssZKqyLfWlnIm/klYKA9Uvx5xAF8XW1Sg==
X-Received: by 2002:a17:902:d4c8:b0:1fd:9a23:90d5 with SMTP id d9443c01a7336-201ca173361mr32372505ad.27.1723531542953; Mon, 12 Aug 2024 23:45:42 -0700 (PDT)
Received: from mail-pj1-f52.google.com (mail-pj1-f52.google.com. [209.85.216.52]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-201cd1c8640sm6717815ad.259.2024.08.12.23.45.42 for <v6ops@ietf.org> (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 12 Aug 2024 23:45:42 -0700 (PDT)
Received: by mail-pj1-f52.google.com with SMTP id 98e67ed59e1d1-2cb5243766dso3848080a91.0 for <v6ops@ietf.org>; Mon, 12 Aug 2024 23:45:42 -0700 (PDT)
X-Received: by 2002:a17:90a:460f:b0:2c9:95c7:7521 with SMTP id 98e67ed59e1d1-2d3924d2a73mr3152373a91.1.1723531541812; Mon, 12 Aug 2024 23:45:41 -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> <CAPt1N1=rQp5U4_X=2WvCV358S9Qm+E+_+gs_mgUJHP_68dYLmg@mail.gmail.com> <d16406c6-e5d9-4aa4-a16e-7513d04d6b07@gmail.com> <DB9PR07MB777164E663505AA86537EB1DD6852@DB9PR07MB7771.eurprd07.prod.outlook.com> <20240812142831.22a4f28e@zbook> <DB9PR07MB7771D93917C01A028E30FDEED6852@DB9PR07MB7771.eurprd07.prod.outlook.com> <0d0f35a3-1493-4e4e-8b4a-08f41fac2b2c@gmail.com> <CACyFTPFPRrW5MxZ8yoNPKYWxzaGQO-HnMNpEKR3TCbVpK6hgWg@mail.gmail.com> <20240813065439.061ef59a@zbook>
In-Reply-To: <20240813065439.061ef59a@zbook>
From: Daryll Swer <contact@daryllswer.com>
Date: Tue, 13 Aug 2024 12:15:06 +0530
X-Gmail-Original-Message-ID: <CACyFTPH+dA9xkCUT98zHr7AYpGyYFuOgOaynhsPjz3iKEuseog@mail.gmail.com>
Message-ID: <CACyFTPH+dA9xkCUT98zHr7AYpGyYFuOgOaynhsPjz3iKEuseog@mail.gmail.com>
To: Marco Moock <mm@dorfdsl.de>
Content-Type: multipart/alternative; boundary="0000000000004f23b7061f8af52e"
Message-ID-Hash: 3KDKLMXMEJ2BKDKCNVN4VTITQFGLDGVG
X-Message-ID-Hash: 3KDKLMXMEJ2BKDKCNVN4VTITQFGLDGVG
X-MailFrom: contact@daryllswer.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: "v6ops@ietf.org" <v6ops@ietf.org>
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [v6ops] Re: Dynamic addresses
List-Id: v6ops discussion list <v6ops.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/IXa6-Fc6jBitadzcKauuAJru1cY>
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>
Marco What do you mean by RA prefix lifetime matching PD lease time = no problems? If ISP-side, PD lease time = 24 hours, and RA prefix lifetime = 24 hours on CE side, and the genius ISP does what it does best, and flips the prefixes within <24 hours of elapsed time for the session, either due to scripting on their systems that does PPPoE or DHCP disconnect per 6-12 hours (yes, there are many ISPs doing this globally), or as we discussed on this thread, power issues (varies wildly by environments and economies), the hosts on the LAN side of the CE will still have old prefixes with original 24 hour pref. lifetime value. > A router can also extend that to avoid connection interrupts. What do you mean by this? I have seen high number of misconfigured IPv6 in SP networks around the world. The vast majority of ISPs (in my experience as a consultant, across APAC, South America, South Africa, North America and certain parts of Europe) that DO “dynamic only” ia_pd, do not maintain the prefix to the configured lease time (we will assume 24 hours for this discussion), upon disconnect/reconnect (for ANY reason), a new prefix is shoved onto the CE. I've seen even stranger IPv6 configurations in the backbone networks (unrelated to residential wireline) that just makes no sense, from obscure IPv4-based subnetting to NAT66 because it's a “firewall”, as per some genius ISPs out there. I have personally discussed this issue (IPv6 malpractices) even with network software vendors (who sells to ISPs) and they tell me: “The customer is always right. We've been doing network programming for decades, but nope, the customer knows networking better than we do, apparently. So NAT66 it is.” There's even NIRs that encourages (I hope nobody from APAC comes at me for saying this) outside nibble-bit boundary subnetting, I recommend this <https://packetpushers.net/podcast/ipv6-buzz-129-ipv6-architecture-and-subnetting-with-daryll-swer/> for a listen. As I originally said, this (dynamic prefixes) also makes it virtually impossible for the home-user to even host basic SSH to their devices on the LAN or even the router itself. I thought we are trying to restore the end-to-end/peer-to-peer principle with IPv6, not further push down NAT66/NPTv6 to combat 24/7 renumbering of the ISP with ULAs and the like. In IPv4, changing IP /32 addresses were masked (literally) with masquerade. And surely, I hope, nobody is suggesting the folks who authored BCOP-690 didn't do their homework. The BCOP clearly explains WHY dynamic prefixes == harmful: https://www.ripe.net/publications/docs/ripe-690/#5-2--why-non-persistent-assignments-are-considered-harmful Even if we ignore ALL the technical issues with dynamic prefixes, dynamic prefixes only increases costs and complexity for law enforcement compliance on the ISP-side anyway. In short, persistent/static ia_pd is a win-win for both sides (ISP and CE owner). > Using non-persistent prefixes also means that it is necessary to have a > logging system that registers which WAN and LAN prefixes are being used at > each moment by each customer site in order to comply with legal/regulatory > requirements. > *--* Best Regards Daryll Swer Website: daryllswer.com <https://mailtrack.io/l/cab64acde34f80d638af32f078a9e082803bf040?url=https%3A%2F%2Fwww.daryllswer.com&u=2153471&signature=0f894b3511eb84b3> On Tue, 13 Aug 2024 at 10:24, Marco Moock <mm@dorfdsl.de> wrote: > Am Tue, 13 Aug 2024 06:16:22 +0530 > schrieb Daryll Swer <contact@daryllswer.com>: > > > Even if you change the values to N, you still have broken > > connectivity for N time. I am of the opinion, that no, SLAAC is > > indeed working as specified, and there are no reasons to mess with > > the values. What needs to be changed is: for ISPs to give the user > > options for either A. Dynamic ia_pd at the user's discretion with the > > downsides for SLAAC operational behaviour Or B. Static ia_pd that > > does not change (unless drastic changes occurs upstream, which also > > applies to v4 anyway). > > Can someone please explain why dynamic prefixes create a problem when > used properly? > > DHCPv6 has a lease time and the RA prefix has a lifetime too. If that > lifetime is not more than the lifetime of the DHCPv6 PD. > > A router can also extend that to avoid connection interrupts. > > By the RFC, a proper operation is possible. Some hard- and software and > some ISPs break it. > > _______________________________________________ > 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