From contact@daryllswer.com Mon Dec 11 11:55:54 2023 Return-Path: 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 ; 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 ; 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 ; Mon, 11 Dec 2023 11:55:25 -0800 (PST) Received: by mail-pg1-x52f.google.com with SMTP id 41be03b00d2f7-5c65ca2e1eeso2499876a12.2 for ; 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 (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 ; 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: <16354BB1-EB7A-4C80-921C-265A3A2FBA10@apnic.net> <968F3FB9-9DBC-4B87-A0F7-E9D91EB33492@massar.ch> <981F68FF-C61C-49E6-9E02-E9390142C263@delong.com> <09AAEFDB-C4A0-447B-844F-7DC9A099D7F1@delong.com> In-Reply-To: <09AAEFDB-C4A0-447B-844F-7DC9A099D7F1@delong.com> From: Daryll Swer Date: Tue, 12 Dec 2023 01:24:43 +0530 X-Gmail-Original-Message-ID: Message-ID: To: "owen@Delong.com" Cc: "owen@Delong.com" , list Content-Type: multipart/alternative; boundary="00000000000083706a060c4150ec" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Dec 2023 19:55:55 -0000 --00000000000083706a060c4150ec Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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=E2=80=93100 years from now will probably have some o= ther 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=E2=80=99t 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=E2=80=99s 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-h= otting-up-as-jio-airtel-eye-high-arpu-home-segment/104342552 > APNIC=E2=80=99s fees are (IMHO) steep, but in APNIC, you=E2=80=99ve chose= n 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 . A lot of APAC related mailing list are more silent than outer space=E2=80= =A6 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=E2=80=99s 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 On Tue, 12 Dec 2023 at 00:41, owen@Delong.com wrote: > > And again, back to IPv4 think. Why not /48 per customer site whether > enterprise, residential, or mobile? > > And that=E2=80=99s 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 fro= m > their PA as well. > > > Well, HE will, FWIW. > Mine wouldn=E2=80=99t either, so I went to ARIN instead. > > But in reality, a /48 for everybody =3D 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=E2=80=99t. > > 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=E2=80=99s assume an average residential customer is US$30/month or eq= uivalent. > That=E2=80=99s $360/year. Let=E2=80=99s assume that $359 of that goes to = circuit > maintenance, backbone, and other costs leaving just $1/year/customer to > cover RIR fees. > > Further, let=E2=80=99s assume that your network structure doesn=E2=80=99t= 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 yo= u > have 16 times that many customers and need a /28, then you=E2=80=99ll be = paying > $8,000/year to cover 524,288 customers =3D $0.016/customer/year (rounded = up > from 0.0152587890625). > > APNIC=E2=80=99s fees are (IMHO) steep, but in APNIC, you=E2=80=99ve chose= n 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 anythin= g > larger. For example, in India, transport circuits+IP Transits etc alone a= re > 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 minim= um > on wireline services, end-users simply don't care, which disincentivize t= he > ISP from investing any additional money into RIR fees for larger blocks t= o > 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 f= or > everybody simply just doesn't work, financially. > > > Unfortunately, there=E2=80=99s 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 mode= l > 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 a= s > well, including (but not limited to) AFRINIC-covered economies, reference > . > > > Don=E2=80=99t get me started on the incredible corruption tax in AFRINIC. > > Owen > > > --00000000000083706a060c4150ec Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Owen

> Well, HE wil= l, 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=E2=80=93100 years from now w= ill probably have some other protocol or addressing technology that would s= upersede IPv6 for various possible reasons in the far future. Like Ed Horle= y, did suggest earlier, hard to predict the far future.

> Mine wouldn=E2=80=99t 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).

&= gt;=C2=A0Let=E2=80=99s assume an average residential customer is US$30/mont= h or equivalent.
I'll stop right here. This is clearly an Am= erican=C2=A0model and potentially European as well (I'm not aware of th= e facts and figures for Europe, but it's likely). These numbers make no= sense for a lot of non-American economies.

I quot= e myself again, below:
> Not all orgs have American-oriented f= inancial power to justify paying for larger RIR allocations.

=
Some sources for reference for ARPU in India (it'll probably= blow your mind!):
> APNIC=E2=80=99s fees are (IMHO) steep, but in APNIC, you=E2=80=99ve = chosen a governance model that allows the largest ISPs to dominate by havin= g a huge voting status where the large players (mostly government run NIRs)= get 64 votes vs. most smaller players only getting 1 vote. This antidemocr= atic 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,=C2=A0in= 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. A lot of APAC related mailing list are more silent tha= n outer space=E2=80=A6 Including my own country's NOG, a waste of time = and efforts to try to change the status quo unless folks unite and work tog= ether, 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=E2=80=99s little that can be done for unsustaina= ble business models where the ARPU is insufficient for the costs of providi= ng 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 star= ted on the NIR in India. They, in fact, encourage outside nibble-bit bounda= ry allocations (APNIC folks know this, I know this, most Indian operators k= now=C2=A0this, but nobody does anything), all the way from their top leader= ship/management.

Side Note:
Owen, if you'= ;re interested in further discussion. Perhaps we both should take this conv= ersation 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 be= st off-list.

Thanks everyone for the inputs, g= ood to see various perspective on the topic of large IPv6 allocations. I= 9;m hopping off this thread now.

--
Best Regards
Daryll Swer


3D""
On Tue, 12 Dec 2023 at 00:41, owen@Delong.com <owen=3D40delong.com= @dmarc.ietf.org> wrote:
> And again, back to IPv4 think. Why not /48 pe= r customer site whether enterprise, residential, or mobile?
> And t= hat=E2=80=99s unfortunate for your customers and their customers.
<= br>
This isn't due to IPv4 thinking, yes a /48 per customer s= ite 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 ro= uted from their PA as well.
=
Well, HE will, FWIW.
Mine wouldn=E2=80=99t either, so I= went to ARIN instead.

But in reality, a /48 for everybody = =3D massive RIR Fees for larger allocations=C2=A0that simply, financially, = is not justifiable for a lot of network operators in a lot of economies, th= e financial numbers just don't make sense.

It really doesn=E2=80=99t.

A /48 standalone is $250/year from ARIN.
You get 16x that f= or 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,=C2=A0

Let=E2=80=99s assu= me an average residential customer is US$30/month or equivalent. That=E2=80= =99s $360/year. Let=E2=80=99s assume that $359 of that goes to circuit main= tenance, backbone, and other costs leaving just $1/year/customer to cover R= IR fees.

Further, let=E2=80=99s assume that your n= etwork structure doesn=E2=80=99t allow you to do any better than 50% =C2=A0= density in your /48 assignments overall. That gives you 32,768 customers pe= r /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=E2=80=99ll be paying $8,000/year to cover 524,288 customers= =3D $0.016/customer/year (rounded up from 0.0152587890625).

=
APNIC=E2=80=99s fees are (IMHO) steep, but in APNIC, you=E2=80= =99ve 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 anti= democratic system creates many barriers to good customer practices.

Unfortunately, those in power are loathe to change the sy= stem, because it keeps them in power.

Not all orgs= have American-oriented financial power to justify paying for larger RIR al= locations. I know many ISPs with tens of thousands of customers, they can&#= 39;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 exampl= e, 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 serv= ices, end-users simply don't care, which disincentivize the ISP from in= vesting any additional money into RIR fees for larger blocks to grant /48s.= For additional context, many ISPs out there struggle to even purchase a ro= uter 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=E2=80=99s little that can be done fo= r unsustainable business models where the ARPU is insufficient for the cost= s of providing the service. Further, I think that the way APNIC has structu= red its cost model is horrible. India does have an NIR, not sure if that ca= n be helpful for this or not.

=
Some other folks from the indus= try have shared this dilemma=C2=A0in the past as well, including (but not l= imited to) AFRINIC-covered economies, reference.

Don=E2=80=99t get me started on= the incredible corruption tax in AFRINIC.

Owen


--00000000000083706a060c4150ec--