Re: [v6ops] How was a /16 of IPv6 asigned from ARIN to non large network?
Daryll Swer <contact@daryllswer.com> Mon, 11 December 2023 19:55 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 F1CA5C151081 for <v6ops@ietfa.amsl.com>; Mon, 11 Dec 2023 11:55:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.094
X-Spam-Level:
X-Spam-Status: No, score=-2.094 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, LOTS_OF_MONEY=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_MONEY_PERCENT=0.01, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable 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 jEdGGB9AvjJd for <v6ops@ietfa.amsl.com>; Mon, 11 Dec 2023 11:55:50 -0800 (PST)
Received: from mail-pg1-x52f.google.com (mail-pg1-x52f.google.com [IPv6:2607:f8b0:4864:20::52f]) (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 D614FC14F747 for <v6ops@ietf.org>; Mon, 11 Dec 2023 11:55:25 -0800 (PST)
Received: by mail-pg1-x52f.google.com with SMTP id 41be03b00d2f7-5c65ca2e1eeso2499876a12.2 for <v6ops@ietf.org>; Mon, 11 Dec 2023 11:55:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=daryllswer.com; s=google; t=1702324524; x=1702929324; 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=b84sBSG0uxZuGCPAm8/ya2xNfz3JlK0DQEDE6n389vw=; b=iTkMrqKOPTYJWeKKVLwwMUNhPaGtlv/Nt3UrHcziwD6gVHurRbvzEO3Y9H8KYzzSLP BeAp7+IlEFyAceLgD5/XlWyxLQMOoNYyfdKGF7Zx56mtZUBNGG0zOyQLwUmjdmUxkjyX OV9QuH1vZon7dDbVi4/vPjQ80yNwCLAYogj2Lo2l0HXyH0MlEmBBUcJHTDjkXNm84++k +2YiHBOAFW4Oy+HuY53JfpUOLfZICUXVjXrhCJGuZ4ZNeT/lnrVYfMnbyLv0wbJySVNQ MnB6Tngs67pzTs9tAmyEvQPp2aWDzz3KA4dnFu9R9T7tM4ZiiALwJDqRU1PvN1zV9yDJ IYjw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1702324524; x=1702929324; 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=b84sBSG0uxZuGCPAm8/ya2xNfz3JlK0DQEDE6n389vw=; b=DN3ACe43n1gH7F1MqYm5Aejx8TmhTmp3n9P8u3BH+YHRRUstydLT+IF6BhooESfv0K bqiXOymiKxLvDmSwd4G+GP2kMr5ht7FbjdEuvFoZ/AlgAMYyQgL9Ck2ITApdo/WUoGt/ Xn/KXJ/JKoUm93q9/bUqyXQ5R7mFgsvvAbaXTvwsq7d2yd/BHEfe6v0ff1ueH/R67Xqb /IUe51W/0/TiuNMcOTwZMKa2cEIyX4rwRFKoenzxFOeYLBUuO2pkDFWBUYWDPfBVLwEn RJyROGA9Sl5/ysclV/WeQqeJvQJJgdvM11O8wgocUFIb93JOcD1wgvdL9XyyLP8N5yGZ CMVw==
X-Gm-Message-State: AOJu0YxT1T0aRj/clwLc3wB8fvIPZ58SyNUu2S214/JMlsCUx5K7woJt Pe0WB+VDZaYeIxDHE0/6gwuk3P7kxDYUKKUfBmVq0g==
X-Google-Smtp-Source: AGHT+IENJ01bSDMAVl1KDnk/KmJ8sK7iSbmypKkMIPXGNeLIPSAKljKGcO3xZgAJ7KNjAQ76lfASCg==
X-Received: by 2002:a05:6a20:431a:b0:18f:97c:5b82 with SMTP id h26-20020a056a20431a00b0018f097c5b82mr2522015pzk.80.1702324524126; Mon, 11 Dec 2023 11:55:24 -0800 (PST)
Received: from mail-pj1-f54.google.com (mail-pj1-f54.google.com. [209.85.216.54]) by smtp.gmail.com with ESMTPSA id y7-20020a17090322c700b001cfb14a09a4sm7029720plg.126.2023.12.11.11.55.23 for <v6ops@ietf.org> (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 11 Dec 2023 11:55:23 -0800 (PST)
Received: by mail-pj1-f54.google.com with SMTP id 98e67ed59e1d1-2868605fa4aso3681210a91.0 for <v6ops@ietf.org>; Mon, 11 Dec 2023 11:55:23 -0800 (PST)
X-Received: by 2002:a17:90b:1d0d:b0:286:6cc0:b912 with SMTP id on13-20020a17090b1d0d00b002866cc0b912mr1873744pjb.73.1702324523460; Mon, 11 Dec 2023 11:55:23 -0800 (PST)
MIME-Version: 1.0
References: <CAD9w2qYxwSUEkzkiHspJH4bn9_Tu6YxFqbfv_6tGFYQbPDUUSg@mail.gmail.com> <16354BB1-EB7A-4C80-921C-265A3A2FBA10@apnic.net> <968F3FB9-9DBC-4B87-A0F7-E9D91EB33492@massar.ch> <CAD9w2qYwq2a=V=rKVYzazXKhwQMJJ=BJ35yWtJ=ndAVW8MkvxQ@mail.gmail.com> <EBFAD1EB-0C9D-43B7-BE7D-332CAA369384@delong.com> <CACyFTPFQ2LfgsCwEPW4vCQETJaG6AgUt9JzLbYCy4sMLOvkCpg@mail.gmail.com> <981F68FF-C61C-49E6-9E02-E9390142C263@delong.com> <CACyFTPFV+VAu6u4Ywj79-azuNkTx=txL5POOMUoNDbKOi8+Zvw@mail.gmail.com> <09AAEFDB-C4A0-447B-844F-7DC9A099D7F1@delong.com>
In-Reply-To: <09AAEFDB-C4A0-447B-844F-7DC9A099D7F1@delong.com>
From: Daryll Swer <contact@daryllswer.com>
Date: Tue, 12 Dec 2023 01:24:43 +0530
X-Gmail-Original-Message-ID: <CACyFTPFpY7R5-=v9Ki1ECncwVa8tWC353ATmYsX+J-CoYrgeRw@mail.gmail.com>
Message-ID: <CACyFTPFpY7R5-=v9Ki1ECncwVa8tWC353ATmYsX+J-CoYrgeRw@mail.gmail.com>
To: "owen@Delong.com" <owen=40delong.com@dmarc.ietf.org>
Cc: "owen@Delong.com" <owen@delong.com>, list <v6ops@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000083706a060c4150ec"
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/2uSTprxg63d9_fpLy8dtTicQEc4>
Subject: Re: [v6ops] How was a /16 of IPv6 asigned from ARIN to non large network?
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 11 Dec 2023 19:55:55 -0000
Owen > Well, HE will, FWIW. Ah, HE, yes, a good example regarding /16, even they managed with non-/16 (from what I can see in the public info), to give /48s for everybody (globally too, not just USA). Anyhow, I suppose the single /16 is okay, even if it was not, 50–100 years from now will probably have some other protocol or addressing technology that would supersede IPv6 for various possible reasons in the far future. Like Ed Horley, did suggest earlier, hard to predict the far future. > Mine wouldn’t either, so I went to ARIN instead. Ah yes, I too opted for my own pool via APNIC. You can forget about /56, ISPs here believe a single /64 works with SLAAC across multiple VLANs (yes, they said that. No, I'm not exaggerating). > Let’s assume an average residential customer is US$30/month or equivalent. I'll stop right here. This is clearly an American model and potentially European as well (I'm not aware of the facts and figures for Europe, but it's likely). These numbers make no sense for a lot of non-American economies. I quote myself again, below: > Not all orgs have American-oriented financial power to justify paying for larger RIR allocations. Some sources for reference for ARPU in India (it'll probably blow your mind!): - https://telecom.economictimes.indiatimes.com/news/industry/jio-beats-q4-arpu-estimates-on-home-broadband-growth/99745267 - https://telecom.economictimes.indiatimes.com/news/industry/competition-hotting-up-as-jio-airtel-eye-high-arpu-home-segment/104342552 > APNIC’s fees are (IMHO) steep, but in APNIC, you’ve chosen a governance model that allows the largest ISPs to dominate by having a huge voting status where the large players (mostly government run NIRs) get 64 votes vs. most smaller players only getting 1 vote. This antidemocratic system creates many barriers to good customer practices. > Unfortunately, those in power are loathe to change the system, because it keeps them in power. Unfortunately, in APAC, a lot of people, seemingly are happy, to just accept the status quo. A good piece was written on this issue from an Indian lens here <https://anuragbhatia.com/2022/05/my-views/challenges-of-building-a-world-class-nog/>. A lot of APAC related mailing list are more silent than outer space… Including my own country's NOG, a waste of time and efforts to try to change the status quo unless folks unite and work together, I was very active in the Indian space, but gave up (the linked piece explains most of the reasons) on wasting my time. > Unfortunately, there’s little that can be done for unsustainable business models where the ARPU is insufficient for the costs of providing the service. Further, I think that the way APNIC has structured its cost model is horrible. India does have an NIR, not sure if that can be helpful for this or not. Oh no, please don't get started on the NIR in India. They, in fact, encourage outside nibble-bit boundary allocations (APNIC folks know this, I know this, most Indian operators know this, but nobody does anything), all the way from their top leadership/management. *Side Note:Owen, if you're interested in further discussion. Perhaps we both should take this conversation off the mailing list, since we're moving more towards layer 8 specific issues and less to do with IPv6 ops. I do have more inputs on the financial aspect, APAC specific issue aspect and NIR aspect but probably best off-list.* Thanks everyone for the inputs, good to see various perspective on the topic of large IPv6 allocations. I'm hopping off this thread now. *--* Best Regards Daryll Swer Website: daryllswer.com <https://mailtrack.io/link/c59e1ebc9d876516e3f1ed5c45d4e9d52ab80f9e?url=https%3A%2F%2Fwww.daryllswer.com&userId=2153471&signature=ecffe8191c1bd80b> On Tue, 12 Dec 2023 at 00:41, owen@Delong.com <owen= 40delong.com@dmarc.ietf.org> wrote: > > And again, back to IPv4 think. Why not /48 per customer site whether > enterprise, residential, or mobile? > > And that’s unfortunate for your customers and their customers. > > This isn't due to IPv4 thinking, yes a /48 per customer site for all > customers is awesome, I fully endorse this idea, in theory only. I would > love my residential ISP in my small home town to give me a /48 routed from > their PA as well. > > > Well, HE will, FWIW. > Mine wouldn’t either, so I went to ARIN instead. > > But in reality, a /48 for everybody = massive RIR Fees for larger > allocations that simply, financially, is not justifiable for a lot of > network operators in a lot of economies, the financial numbers just don't > make sense. > > > It really doesn’t. > > A /48 standalone is $250/year from ARIN. > You get 16x that for 2x the fees at every higher level, so a /44 is $500, > a /40 is $1,000, 36 is $2,000, 32 is $4,000, > > Let’s assume an average residential customer is US$30/month or equivalent. > That’s $360/year. Let’s assume that $359 of that goes to circuit > maintenance, backbone, and other costs leaving just $1/year/customer to > cover RIR fees. > > Further, let’s assume that your network structure doesn’t allow you to do > any better than 50% density in your /48 assignments overall. That gives > you 32,768 customers per /32. > > At that rate, you only need $0.125/customer/year to cover that /32. If you > have 16 times that many customers and need a /28, then you’ll be paying > $8,000/year to cover 524,288 customers = $0.016/customer/year (rounded up > from 0.0152587890625). > > APNIC’s fees are (IMHO) steep, but in APNIC, you’ve chosen a governance > model that allows the largest ISPs to dominate by having a huge voting > status where the large players (mostly government run NIRs) get 64 votes > vs. most smaller players only getting 1 vote. This antidemocratic system > creates many barriers to good customer practices. > > Unfortunately, those in power are loathe to change the system, because it > keeps them in power. > > Not all orgs have American-oriented financial power to justify paying for > larger RIR allocations. I know many ISPs with tens of thousands of > customers, they can't justify paying for large allocations to support the > /48 idea, many of them even struggle to afford two /32s let alone anything > larger. For example, in India, transport circuits+IP Transits etc alone are > super expensive, way too expensive for the tiny ARPU over here to justify. > And unfortunately, even though I at the very least advocate for /56 minimum > on wireline services, end-users simply don't care, which disincentivize the > ISP from investing any additional money into RIR fees for larger blocks to > grant /48s. For additional context, many ISPs out there struggle to even > purchase a router with decent FIB capacity for full tables, some struggle > to even deploy layer 3 PE routers for the last-mile and still use some > cheap Chinese OEM layer 2 switches with STP etc. So you can see why /48 for > everybody simply just doesn't work, financially. > > > Unfortunately, there’s little that can be done for unsustainable business > models where the ARPU is insufficient for the costs of providing the > service. Further, I think that the way APNIC has structured its cost model > is horrible. India does have an NIR, not sure if that can be helpful for > this or not. > > Some other folks from the industry have shared this dilemma in the past as > well, including (but not limited to) AFRINIC-covered economies, reference > <https://x.com/stubarea51/status/1571887490188955648>. > > > Don’t get me started on the incredible corruption tax in AFRINIC. > > Owen > > >
- [v6ops] How was a /16 of IPv6 asigned from ARIN t… Momoka Yamamoto
- Re: [v6ops] How was a /16 of IPv6 asigned from AR… Nick Buraglio
- Re: [v6ops] How was a /16 of IPv6 asigned from AR… Ed Horley
- Re: [v6ops] How was a /16 of IPv6 asigned from AR… Momoka Yamamoto
- [v6ops] I think that a /20 is enough for the new … Gábor LENCSE
- Re: [v6ops] How was a /16 of IPv6 asigned from AR… Daryll Swer
- Re: [v6ops] How was a /16 of IPv6 asigned from AR… Gert Doering
- Re: [v6ops] How was a /16 of IPv6 asigned from AR… Daryll Swer
- Re: [v6ops] How was a /16 of IPv6 asigned from AR… Owen DeLong
- Re: [v6ops] How was a /16 of IPv6 asigned from AR… Daryll Swer
- Re: [v6ops] How was a /16 of IPv6 asigned from AR… Brian E Carpenter
- Re: [v6ops] How was a /16 of IPv6 asigned from AR… David Farmer
- Re: [v6ops] How was a /16 of IPv6 asigned from AR… Owen DeLong
- Re: [v6ops] How was a /16 of IPv6 asigned from AR… Owen DeLong
- Re: [v6ops] How was a /16 of IPv6 asigned from AR… Owen DeLong
- Re: [v6ops] How was a /16 of IPv6 asigned from AR… Geoff Huston
- Re: [v6ops] How was a /16 of IPv6 asigned from AR… Jeroen Massar
- Re: [v6ops] How was a /16 of IPv6 asigned from AR… Momoka Yamamoto
- Re: [v6ops] How was a /16 of IPv6 asigned from AR… Owen DeLong
- Re: [v6ops] How was a /16 of IPv6 asigned from AR… Daryll Swer
- Re: [v6ops] How was a /16 of IPv6 asigned from AR… Ed Horley
- Re: [v6ops] How was a /16 of IPv6 asigned from AR… owen@Delong.com
- Re: [v6ops] How was a /16 of IPv6 asigned from AR… Daryll Swer
- Re: [v6ops] How was a /16 of IPv6 asigned from AR… owen@Delong.com
- Re: [v6ops] How was a /16 of IPv6 asigned from AR… Daryll Swer
- Re: [v6ops] How was a /16 of IPv6 asigned from AR… David Farmer
- Re: [v6ops] How was a /16 of IPv6 asigned from AR… owen@Delong.com