[v6ops] Re: Dynamic addresses

Jatin <mehtajatin@protonmail.com> Fri, 16 August 2024 13:03 UTC

Return-Path: <mehtajatin@protonmail.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 C63E5C1CAE6F for <v6ops@ietfa.amsl.com>; Fri, 16 Aug 2024 06:03:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.103
X-Spam-Level:
X-Spam-Status: No, score=-7.103 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_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, 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=protonmail.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 Jm1RXFdZANlM for <v6ops@ietfa.amsl.com>; Fri, 16 Aug 2024 06:03:12 -0700 (PDT)
Received: from mail-40140.protonmail.ch (mail-40140.protonmail.ch [185.70.40.140]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E449C1E6425 for <v6ops@ietf.org>; Fri, 16 Aug 2024 06:02:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1723813374; x=1724072574; bh=DskMbzt6h4HUeFprtRAegdUApuzMz7Q0PTBqgeI4Cw0=; h=Date:To:From:Subject:Message-ID:Feedback-ID:From:To:Cc:Date: Subject:Reply-To:Feedback-ID:Message-ID:BIMI-Selector; b=SRfIGYyh+3Vulj9/+bncNGTW0aQxeSSuLC2AFmbHpri99w8vucdfoiTpJ3qUURx6+ O9xFmSQL+kyGiVPy2ZUEaYpcDw0GvW4k3KuYwTAygCyfxOnIIsghuxfJxGL8CWxzFt Go9yRMsbxdJq+q087BSgFJ5nq/u/T39SHoFlHYV/L/4BVz3380hf6eLP+qoubGiKSr zozf9t9jAUMgI6cWqGqWEU0WQJ13WYEDbz9ORyNbZa8xplh7YurmR5AxVnZXgdJnEz 1/tjapBejAUHI0X10iWvxvAQM1Nvtn0MUftD2aofRzM01sVR9sKikKh2mtFOZe10e3 YjEgXikivpGRQ==
Date: Fri, 16 Aug 2024 13:02:48 +0000
To: "v6ops@ietf.org" <v6ops@ietf.org>
From: Jatin <mehtajatin@protonmail.com>
Message-ID: <pk11cIn2V_j4M1HDIgKOa-acaOShYMe0lTbXQ5bxJnB5_z-3dQ-R2ud96KGMN4rZEvQdEHgsBEAqcsRZ1iZiuj_Xj3HIvr0hIvWZYaxtn1c=@protonmail.com>
Feedback-ID: 94921563:user:proton
X-Pm-Message-ID: 4ec3fa56a71b65e24651a8b5c391bf5b93973edc
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="b1_XJ2i1hemOFbLPDdHCjteR7mJEhf7nC6iZFMLYSvw"
Message-ID-Hash: RCEQHA4NFXN5Z2PJLBG73NZYGLUSBOSW
X-Message-ID-Hash: RCEQHA4NFXN5Z2PJLBG73NZYGLUSBOSW
X-MailFrom: mehtajatin@protonmail.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
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/Fb6zVl3ezJmowCi7gj1Bdlt8crk>
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>

Hi,

I totally second Daryll on this.

Let’s get technical for a moment. I’m an ISP based in India, and we’ve been grappling with the intricacies of IPv6 deployment.

As we all know, SLAAC and RADVD are the workhorses of IPv6 address autoconfiguration. These protocols rely on timers for renewing parameters. The default values for these timers can range from a few minutes to hours, depending on the implementation. For instance, the preferred lifetime for a router advertisement can be set to 604800 seconds (7 days) by default.

The problem arises when the underlying connection (PPPoE, IPoE, etc.) is disrupted. The CPE receives a new IPv6 prefix, but the LAN devices, configured via SLAAC/RADVD, hold onto their old addresses until the timers expire. This results in an outage until the devices reconfigure themselves.

To circumvent this, we've been assigning fixed IPv6 PD pools, specifically /56s, to our CPEs. This aligns with BCOP 690 recommendations and ensures a stable IPv6 environment. While it adds a layer of complexity to network management, it’s a necessary evil to maintain a seamless user experience.

To further optimize our IPv6 infrastructure, we're aggregating prefixes at the BNG level, allocating /44s as needed. This approach provides flexibility while maintaining a stable IPv6 environment. We believe larger ISPs can benefit from similar strategies to improve overall network efficiency.

Now, let’s talk economics. IPv6 is abundant. It’s like having an infinite supply of gold. Charging customers for a static IPv6 PD pool is akin to charging for the air they breathe. It's a basic service, not a premium feature. Even as a relatively small ISP in India, we provide static IPv6 PD at no extra cost.

I understand the desire for revenue generation, but let's focus on providing value-added services. Charging for advanced features, premium speeds, or static IPv4 addresses is justifiable. However, monetizing the foundation of IPv6 is counterproductive and harms the overall adoption of the protocol.

Let's be smart here. Larger ISPs should reconsider their stance on IPv6 pricing. We need collaborate to create a robust IPv6 ecosystem that benefits everyone(not just the profiteering ISPs). This includes working with OEMs and software vendors to develop BNG platforms that prioritize stable IPv6 prefix delegation.

Best regards,Jatin Mehta