Re: CGNAT

[Owen DeLong via NANOG]

That’s provably not true if the IPv4AAS implementation is done carefully.

Owen


> On Feb 19, 2021, at 12:11 PM, Tony Wicks  wrote:
> 
> Because then a large part of the Internet won't work
> 
> From: NANOG  on behalf of Mark 
> Andrews 
> Sent: Saturday, 20 February 2021, 9:04 am
> To: Steve Saner
> Cc: nanog@nanog.org
> Subject: Re: CGNAT
> 
> Why not go whole hog and provide IPv4 as a service? That way you are not 
> waiting for your customers to turn up IPv6 to take the load off your NAT box.
> 
> Yes, you can do it dual stack but you have waited so long you may as well 
> miss that step along the deployment path.
> -- 
> Mark Andrews
> 
>> On 20 Feb 2021, at 01:55, Steve Saner  wrote:
>> 
>> 
>> We are starting to look at CGNAT solutions. The primary motivation at the 
>> moment is to extend current IPv4 resources, but IPv6 migration is also a 
>> factor.
>> 
>> We've been in touch with A10. Just wondering if there are some alternative 
>> vendors that anyone would recommend. We'd probably be looking at a solution 
>> to support 5k to 15k customers and bandwidth up to around 30-40 gig as a 
>> starting point. A solution that is as transparent to user experience as 
>> possible is a priority.
>> 
>> Thanks
>> 
>> -- 
>> Steve Saner
>> ideatek HUMAN AT OUR VERY FIBER
>> This email transmission, and any documents, files or previous email messages 
>> attached to it may contain confidential information. If the reader of this 
>> message is not the intended recipient or the employee or agent responsible 
>> for delivering the message to the intended recipient, you are hereby 
>> notified that any dissemination, distribution or copying of this 
>> communication is strictly prohibited. If you are not, or believe you may not 
>> be, the intended recipient, please advise the sender immediately by return 
>> email or by calling 620.543.5026 . Then take all steps 
>> necessary to permanently delete the email and all attachments from your 
>> computer system.
>> 
> 

Re: CGNAT

[Owen DeLong via NANOG]

> On Feb 22, 2021, at 6:44 AM, na...@jima.us wrote:
> 
> While I don't doubt the accuracy of Lee's presentation at the time, at least 
> two base factors have changed since then:
> 
> - Greater deployment of IPv6 content (necessitating less CGN capacity per 
> user)

This is only true if the ISP in question is implementing IPv6 along side their 
CGN deployment and only if they get a significant uptake of IPv6 capability by 
their end users.

> - Increased price of Legacy IP space on the secondary market (changing the 
> formula) -- strictly speaking, this presentation was still in "primary 
> market" era for LACNIC/ARIN/AFRINIC

While that’s true, even at current prices, IPv4 addresses are cheaper to buy 
and/or lease than CGN.

> IPv6 migration is not generally aided by CGNAT, but CGNAT deployment is 
> generally aided by IPv6 deployment; to reiterate the earlier point, any ISPs 
> deploying CGNAT without first deploying IPv6 are burning cash.

Yep.

I still think that implementing CGN is a good way to burn cash vs. the 
alternatives, but YMMV.

Owen

> 
> - Jima
> 
> From: NANOG On Behalf Of Owen DeLong
> Sent: Sunday, February 21, 2021 16:59
> To: Steve Saner
> Cc: nanog@nanog.org
> Subject: Re: CGNAT
> 
> 
> On Feb 18, 2021, at 8:38 AM, Steve Saner wrote:
> 
>> We are starting to look at CGNAT solutions. The primary motivation at the 
>> moment is to extend current IPv4 resources, but IPv6 migration is also a 
>> factor.
> 
> IPv6 Migration is generally not aided by CGNAT.
> 
> In general, the economics today still work out to make purchasing or leasing 
> addresses more favorable than CGNAT.
> 
> It’s a bit dated by now, but still very relevant, see Lee Howard’s excellent 
> research presented at the 2012 Rocky
> mountain v6 task force meeting:
> 
> https://www.rmv6tf.org/wp-content/uploads/2012/11/TCO-of-CGN1.pdf
> 
> Owen
> 
> 
> We've been in touch with A10. Just wondering if there are some alternative 
> vendors that anyone would recommend. We'd probably be looking at a solution 
> to support 5k to 15k customers and bandwidth up to around 30-40 gig as a 
> starting point. A solution that is as transparent to user experience as 
> possible is a priority.
> 
> Thanks
> 
> -- 
> Steve Saner
> ideatek HUMAN AT OUR VERY FIBER
> This email transmission, and any documents, files or previous email messages 
> attached to it may contain confidential information. If the reader of this 
> message is not the intended recipient or the employee or agent responsible 
> for delivering the message to the intended recipient, you are hereby notified 
> that any dissemination, distribution or copying of this communication is 
> strictly prohibited. If you are not, or believe you may not be, the intended 
> recipient, please advise the sender immediately by return email or by calling 
> tel:620.543.5026. Then take all steps necessary to permanently delete the 
> email and all attachments from your computer system.
> 

Re: DOD prefixes and AS8003 / GRSCORP

[Owen DeLong via NANOG]

According to the timeline posted to this list (by you, Siyuan), Globl Resource 
Systems, LLC was registered in Delaware on September 8, 2020.
Your timeline also shows the resources being issued to GRS by ARIN on September 
11, september 14, 2020
It looks to me like they subsequently registered the corporation in Florida and 
moved the company address there.

I don’t see anything suspicious here based on your own statements, so I’m a bit 
confused what you are on about.

Owen

> On Mar 12, 2021, at 03:34 , Siyuan Miao  wrote:
> 
> Hi John,
> 
> My biggest concern is why the AS8003 was assigned to the company (GLOBAL 
> RESOURCE SYSTEMS, LLC) even before its existence.
> 
> When we were requesting resources or transfers, ARIN always asked us to 
> provide a Certificate of Good Standing and we had to pay the state to order 
> it.
> 
> However, it appears that a Certificate of Good Standing is not required or 
> ARIN didn't validate it in this case. 
> 
> Regards,
> Siyuan
> 
> On Fri, Mar 12, 2021 at 7:17 PM John Curran  > wrote:
> On 11 Mar 2021, at 7:56 AM, Siyuan Miao  > wrote:
>> 
>> Hi Folks,
>> 
>> Just noticed that almost all DOD prefixes (7.0.0.0/8,11.0.0.0/8,22.0.0.0/8 
>>  and bunch of /22s)  are now 
>> announced under AS8003 (GRSCORP) which was just formed a few months ago.
>> 
>> It looks so suspicious. Does anyone know if it's authorized?
> 
> Siyuan - 
> 
> If you have concerns, you can confirm whether these IP address blocks are 
> being routed as intended by verification with their listed technical contacts 
> - e.g. https://search.arin.net/rdap/?query=22.0.0.0 
>   
> 
> As I noted on this list several weeks back - "lack of routing history is not 
> at all a reliable indicator of the potential for valid routing of a given 
> IPv4 block in the future, so best practice suggest that allocated address 
> space should not be blocked by others without specific cause. Doing otherwise 
> opens one up to unexpected surprises when issued space suddenly becomes more 
> active in routing and is yet is inexplicably unreachable for some 
> destinations."
> 
> Thanks!
> /John
> 
> John Curran
> President and CEO
> American Registry for Internet Numbers
> 

Re: DOD prefixes and AS8003 / GRSCORP

[Owen DeLong via NANOG]

> On Mar 15, 2021, at 15:07 , Tom Beecher  wrote:
> 
> I think it’s a general matter of public interest how this reassignment of a 
> massive government-owned block of well over sixteen million IP addresses 
> happened. Even if not fraudulent, the public has a right to know who is 
> behind this huge transfer of wealth.
> 
> Don’t you?

> On Mon, Mar 15, 2021 at 3:35 PM Mel Beckman  <mailto:m...@beckman.org>> wrote:
> Owen,
> 
> I think one cause for concern is why “almost all DOD prefixes 
> (7.0.0.0/8,11.0.0.0/8,22.0.0.0/8 <http://7.0.0.0/8,11.0.0.0/8,22.0.0.0/8> and 
> bunch of /22s) are now announced under AS8003 <> (GRSCORP) which was just 
> formed a few months ago,” which, according to ARIN WHOIS, had a source 
> registry of “DoD Network Information Center”. 

Somehow, I’m of the impression that DoD is quite capable of defending their own 
property if necessary. I’m also not of the same belief as you that GRSCORP was 
just formed a few months ago. It seems to have bounced back and forth between 
Florida and Delaware one or more times, but that’s not all that uncommon for a 
corporation physically located in Florida. Corporations change their state of 
incorporation somewhat regularly for a variety of legal forum shopping 
purposes, including but not limited to tax advantages, court jurisdictional 
advantages, etc.


> I think it’s a general matter of public interest how this reassignment of a 
> massive government-owned block of well over sixteen million IP addresses 
> happened. Even if not fraudulent, the public has a right to know who is 
> behind this huge transfer of wealth.

I don’t see a transfer of wealth. I see DOD finally having a contractor 
originate their prefixes in order to make life more difficult for squatters, 
hijackers, and other miscreants. About time, if you ask me. I mean, I’m sure 
that in order to provide that level of sink-hole, GRSCORP is having to pay some 
hefty transit bills and maintain some significant infrastructure and likely 
passing all that cost along to DoD at a hefty markup, so I suppose that’s some 
level of transfer of wealth, but as DoD contracts go, I somehow don’t think 
this one would be regarded as “significant”.

Owen

> 
> Don’t you?
> 
>  -mel beckman
> 
>> On Mar 15, 2021, at 12:23 PM, Owen DeLong via NANOG > <mailto:nanog@nanog.org>> wrote:
>> 
>>  According to the timeline posted to this list (by you, Siyuan), Globl 
>> Resource Systems, LLC was registered in Delaware on September 8, 2020.
>> Your timeline also shows the resources being issued to GRS by ARIN on 
>> September 11, september 14, 2020
>> It looks to me like they subsequently registered the corporation in Florida 
>> and moved the company address there.
>> 
>> I don’t see anything suspicious here based on your own statements, so I’m a 
>> bit confused what you are on about.
>> 
>> Owen
>> 
>>> On Mar 12, 2021, at 03:34 , Siyuan Miao >> <mailto:avel...@misaka.io>> wrote:
>>> 
>>> Hi John,
>>> 
>>> My biggest concern is why the AS8003 was assigned to the company (GLOBAL 
>>> RESOURCE SYSTEMS, LLC) even before its existence.
>>> 
>>> When we were requesting resources or transfers, ARIN always asked us to 
>>> provide a Certificate of Good Standing and we had to pay the state to order 
>>> it.
>>> 
>>> However, it appears that a Certificate of Good Standing is not required or 
>>> ARIN didn't validate it in this case. 
>>> 
>>> Regards,
>>> Siyuan
>>> 
>>> On Fri, Mar 12, 2021 at 7:17 PM John Curran >> <mailto:jcur...@arin.net>> wrote:
>>> On 11 Mar 2021, at 7:56 AM, Siyuan Miao >> <mailto:avel...@misaka.io>> wrote:
>>>> 
>>>> Hi Folks,
>>>> 
>>>> Just noticed that almost all DOD prefixes (7.0.0.0/8,11.0.0.0/8,22.0.0.0/8 
>>>> <http://7.0.0.0/8,11.0.0.0/8,22.0.0.0/8> and bunch of /22s)  are now 
>>>> announced under AS8003 (GRSCORP) which was just formed a few months ago.
>>>> 
>>>> It looks so suspicious. Does anyone know if it's authorized?
>>> 
>>> Siyuan - 
>>> 
>>> If you have concerns, you can confirm whether these IP address blocks are 
>>> being routed as intended by verification with their listed technical 
>>> contacts - e.g. https://search.arin.net/rdap/?query=22.0.0.0 
>>> <https://search.arin.net/rdap/?query=22.0.0.0>  
>>> 
>>> As I noted on this list several weeks back - "lack of routing history is 
>>> not at all a reliable indicator of the potential for valid routing of a 
>>> given IPv4 block in the future, so best practice suggest that allocated 
>>> address space should not be blocked by others without specific cause. Doing 
>>> otherwise opens one up to unexpected surprises when issued space suddenly 
>>> becomes more active in routing and is yet is inexplicably unreachable for 
>>> some destinations."
>>> 
>>> Thanks!
>>> /John
>>> 
>>> John Curran
>>> President and CEO
>>> American Registry for Internet Numbers
>>> 
>> 

Re: DoD IP Space

[Owen DeLong via NANOG]

> On Apr 24, 2021, at 16:34 , Jason Biel  wrote:
> 
> The internet that is subsidized by that same Government….

Uh, s/is/was/

There’s really no subsidy any more.

Owen

Re: New minimum speed for US broadband connections

[Owen DeLong via NANOG]

> On May 28, 2021, at 06:56 , Mike Hammett  wrote:
> 
> "Bad connection" measures way more than throughput.
> 
> What about WFH or telehealth doesn't work on 25/3?

Pretty much everything if you have, say, 3+ people in your house trying to do 
it at once…

A decent Zoom call requires ~750Kbps of upstream bandwidth. When you get two
kids doing remote school and mom and dad each doing $DAYJOB via teleconferences,
that 3Mbps gets spread pretty thin, especially if you’ve got any other 
significant use
of your upstream connection (e.g. kids posting to Tik Tok, etc.)

Sure, for a single individual, 25/3 might be fine. For a household that has the 
industry
standard 2.53 people, it might even still work, but barely. Much above that 
average
and things degrade rapidly and not very gracefully.

Owen

> 
> 
> 
> -
> Mike Hammett
> Intelligent Computing Solutions
> http://www.ics-il.com 
> 
> Midwest-IX
> http://www.midwest-ix.com 
> 
> From: "Abhi Devireddy" 
> To: nanog@nanog.org, "Jason Canady" 
> Sent: Friday, May 28, 2021 8:07:34 AM
> Subject: Re: New minimum speed for US broadband connections
> 
> Don't think it needs to change? From 25/3? Telehealth and WFH would like to 
> talk with you.
> 
> There's very few things more draining than a conference call with someone 
> who's got a bad connection. 
> Abhi
> 
> Abhi Devireddy
> 
> From: NANOG  on behalf of Jason 
> Canady 
> Sent: Friday, May 28, 2021 7:39:14 AM
> To: nanog@nanog.org 
> Subject: Re: New minimum speed for US broadband connections
>  
> I second Mike.
> 
> On 5/28/21 8:37 AM, Mike Hammett wrote:
> I don't think it needs to change.
> 
> 
> 
> -
> Mike Hammett
> Intelligent Computing Solutions
> http://www.ics-il.com 
> 
> Midwest-IX
> http://www.midwest-ix.com 
> 
> From: "Sean Donelan"  
> To: nanog@nanog.org 
> Sent: Thursday, May 27, 2021 7:29:08 PM
> Subject: New minimum speed for US broadband connections
> 
> 
> What should be the new minimum speed for "broadband" in the U.S.?
> 
> 
> This is the list of past minimum broadband speed definitions by year
> 
> year  speed
> 
> 1999  200 kbps in both directions (this was chosen as faster than 
> dialup/ISDN speeds)
> 
> 2000  200 kbps in at least one direction (changed because too many service 
> providers had 128 kbps upload)
> 
> 2010   4 mbps down / 1 mbps up
> 
> 2015   25 Mbps down / 3 Mbps up (wired)
>  5 Mbps down / 1 Mbps up (wireless)
> 
> 2021   ??? / ??? (some Senators propose 100/100 mbps)
> 
> Not only in major cities, but also rural areas
> 
> Note, the official broadband definition only means service providers can't 
> advertise it as "broadband" or qualify for subsidies; not that they must 
> deliver better service.

Re: New minimum speed for US broadband connections

[Owen DeLong via NANOG]

My USF dollars at work… You’re welcome.

I’d also appreciate it if we didn’t structure the subsidies such that it 
doesn’t make any economic sense to provide services to the middle-density 
market.

Owen


> On May 30, 2021, at 13:56 , Blake Dunlap  wrote:
> 
> The co op electric serving my families house in bfe tn that doesn't have 
> either sewer or cable managed to run hard fiber for dirt cheap to all their 
> subscribers. Its clear from that the problem isnt can't, it's won't. Setting 
> the bar so low that podunk wifi 300k links that barely have more backhaul 
> meet it only serves to limit the interest in fixing the problem correctly so 
> Darryl's wifi and plumbing doesn't have to invest more than 50 bucks for few 
> more years. We shouldn't be subsidizing ancient copper plants that are barely 
> maintained as it is simply because established companies want to collect the 
> gov'ment dole while doing bare minimum to zero work to actually make anything 
> better because it's better for their bottom line to keep everyone's 
> expectations firmly in the 90s or even 80s.
> 
> On Sun, May 30, 2021, 12:54 Baldur Norddahl  > wrote:
> 
> 
> søn. 30. maj 2021 15.29 skrev Mike Hammett  >:
> What can you do with 100 megs that you can't do with 25 megs and why should 
> anyone care?
> 
> That is really the wrong question. People want 100 Mbps over 25 Mbps and 
> therefore it becomes a need for rural communities. Doesn't matter that 
> someone believes these people could do with less.
> 
> The year is 2021 and perceived good internet is minimum 100 Mbps. 
> 
> Regards 
> 
> Baldur 
> 
> 

Re: New minimum speed for US broadband connections

[Owen DeLong via NANOG]

Josh,

A city can build a competitive service that is revenue neutral or even a source 
of income for the city without causing
the earth to shift on its axis. Often, in fact, government is in a position to 
make large up-front capital investments in
infrastructure that don’t have a fast enough pay-out to attract profit-oriented 
investors. Quite often, such cities
are not subsidizing the network as you assume here. Most of these tend to be 
revenue neutral and pay back the
capital investment over a ~15-20 year period. Some even end up contributing to 
the city over time.

Frankly, I wish City of San Jose would do a Fiber to Everyone Layer-1 only 
competitive access fiber infrastructure
project here.

Owen


> On May 31, 2021, at 10:57 , Josh Luthman  wrote:
> 
> I think it's hilarious when a governmental entity funded by the taxpayers 
> thinks they have an answer to broadband.  If you're collecting funds from 
> customers, why do you need the City of Sherwood to support your network?
> 
> Josh Luthman
> 24/7 Help Desk: 937-552-2340
> Direct: 937-552-2343
> 1100 Wayne St
> Suite 1337
> Troy, OH 45373
> 
> 
> On Fri, May 28, 2021 at 6:22 PM Brandon Price  > wrote:
> 100/100 minimum for sure.
> 
> In our small neck of the woods, we are currently doing 250/250 for $45 and 
> 1000/1000 for $60 no data caps.
> 
> We have lost some grants on rural builds because "someone" in the census 
> block claims they provide broadband.. Not hard to put an AP up on a tower and 
> hit the current definition's upload speed.
> 
> I get a chuckle when the providers tell the customer what they "need"...  
> 
> 
> Brandon Price
> Senior Network Engineer
> City of Sherwood, Sherwood Broadband
> 
> 
> 
> -Original Message-
> From: NANOG  > On Behalf Of Sean Donelan
> Sent: Thursday, May 27, 2021 5:33 PM
> To: NANOG Operators' Group mailto:nanog@nanog.org>>
> Subject: Re: New minimum speed for US broadband connections
> 
> CAUTION: This email originated from outside of the organization. Do not click 
> links or open attachments unless you are expecting this email and/or know the 
> content is safe.
> 
> 
> On Thu, 27 May 2021, Lady Benjamin Cannon of Glencoe, ASCE wrote:
> > At least 100/100.
> >
> > We don’t like selling slower than 10g anymore, that’s what I’d start 
> > everyone at if I could.
> 
> 
> At $50/month or less?
> 
> Maximize number of households of all demographic groups.
> 

Re: New minimum speed for US broadband connections

[Owen DeLong via NANOG]

> On Jun 2, 2021, at 01:33 , Mark Tinka  wrote:
> 
> 
> 
> On 6/2/21 05:50, Haudy Kazemi via NANOG wrote:
> 
>> I'd love to see connection 'Nutrition Facts' type labeling.
>> 
>> Include: Typical downstream bandwidth, typical upstream bandwidth, median 
>> latency and packet loss rates (both measured from CPE in advertised ZIP code 
>> to the top 10 websites), data cap info, and bottom line price including all 
>> unavoidable fees.
> 
> For average Jane, it would be as useful as the water company running you 
> through the process of cleaning and treating the water that arrives at your 
> tap (faucet, for the Americans).

I disagree… If it could be forced into a standardized format using a 
standardized approach to data acquisition and reliable comparable results 
across providers, it could be a very useful adjunct to real competition.

Owen

Re: FreeBSD's ping Integrates IPv6

[Owen DeLong via NANOG]

Linux did this quite some time ago. I guess BSD is just now catching up.

Owen


> On Jul 2, 2021, at 7:30 AM, Mark Tinka  wrote:
> 
> 
> 
> On 7/2/21 16:22, Niels Bakker wrote:
> 
>> 
>> Yes, this broke some of my home network monitoring. Sadly there is no 
>> 'ping4' in the system, you have to add -4 to the commandline to return to 
>> the common BSD behaviour.
> 
> This is a good point, as it's the same reason I discovered this today. A 
> transient IPv6 issue on a specific host broke NTP, and when I tried to ping 
> the NTP time servers during troubleshooting, it hang for a while because IPv6 
> was broken.
> 
> Mark.

Re: Anycast but for egress

[Owen DeLong via NANOG]

> On Jul 27, 2021, at 10:54 , Vimal  wrote:
> 
> (Unsure if this is the right forum to ask this question, but here goes:)
> 
> From what I understand, IP Anycast can be used to steer traffic into a server 
> that's close to the client.
> 
> I am curious if anyone here has/encountered a setup where they use anycast IP 
> on their gateways... to have a predictable egress IP for their traffic, 
> regardless of where they are located?

> For example, a search engine crawler could in principle have the same IP 
> advertised all over the world, but it looks like they don't...  I wonder why?

Because there’s no good/reliable way to get the replies back to the correct 
initiating host.

Owen

Re: A crazy idea

[Owen DeLong via NANOG]

> On Jul 19, 2021, at 06:04 , Stephen Satchell  wrote:
> 
> On 7/19/21 5:41 AM, Feldman, Mark wrote:
>> What you propose is not outlandish; some ISPs have been dual stack
>> and providing some combination of these services for years.  They
>> already provide IPv6 ip6.arpa delegations should their business
>> customers want them.  Some even provide at least a /56 so customers
>> can have multiple /64 subnets.  And we, I mean they, can also provide
>> RFC2317 in-addr.arpa delegations for those smaller IPv4 blocks.
> 
> The part that is missing isn't the "some ISPs", it's "all ISPs".  Also, I 
> don't know of any DNS service provider that offers a product to handle 
> delegations from the IN-ADDR.ARPA and IP6.ARPA trees.

I believe he.net does.

https://dns.he.net

To the best of my knowledge, so does Cloudflare.

Finally, it’s really not rocket science to stand up an authoritative server 
these days.

> I'm focusing on the SOHO customer market with my proposal.
> 
> The allocation of IPv6 space with prefixes shorter than /64 is indeed a 
> consideration for bigger administrative domains like country governments, but 
> on the other end, SOHO customers would be happy with /96, /104 or even /112 
> allocations if they could get them.  (Just how many light bulbs, fridges, 
> toasters, doorbells, phones, &c does SOHOs have?)  I would *not* like to see 
> "us" make the same mistake with IPv6 that was made with IPv4, handing out 
> large blocks of space like so many pieces of M&M or Skittles candy.

SOHO customers should be getting PD for /48s too. The most egregiously backward 
providers that I know of are still issuing at least /60. It’s utterly and 
completely illogical to issue anything longer than /64 and reflects fundamental 
misunderstanding of the design and intended deployment of IPv6. Yes, you can 
technically do it, but it remains a really bad idea.

The point in IPv6 is to stop worrying about host counts. Let’s talk about your 
Candy analogy for a moment.

If you took every almond M&M ever manufactured, you probably couldn’t fill the 
great lakes.

If you converted every IPv6 /64 prefix in the entire ::/0 to almond M&Ms, you 
would, in fact, fill the great lakes.

And that’s the number of /64 sized subnets. You don’t have to count hosts 
because with a /64 subnet, you run out of table space in your devices well 
before you run out of host numbers.

There are enough /48s to give 1,000 to every single person on the planet today 
and still have 4,000 per person left over in the first /3 (Technically, there 
are more than 5026 IPv6 /48s in 2000::/3 for each person currently living).

We’re simply NOT going to run out of /48s by issuing them to SOHO users, no 
matter how hard we try.

Consider this… I discussed this topic at length with JJB (COMCAST at the time) 
and pushed hard on why they don’t give /48s to their residential customers. His 
answer was that if they did so, they would need to get a /12 from their RIR 
(ARIN). My question to him in response to that was “so?”.

COMCAST is one of the largest providers in North America and serves more than 
31 million subscribers. There are maybe 50 residential ISPs of this size 
worldwide. Giving each of them a /12 would leave us with a remaining 462 /12s 
in 2000:/3.

Even if I’m absolutely wrong about all of this, consider that if we use a 
profligate allocation policy in the beginning of IPv6 to speed and simplify 
deployment and maintenance and we do run out of 2000::/3, then we can implement 
a more restrictive set of policies for the next 6 tries and still have a safety 
net when we’re forced to start allocating out of blocks with odd reservations 
(::/3 and e000::/3).

Fear of the “IPv4” mistake is utter nonsense. The error in IPv4 wasn’t issuing 
large blocks. The error in IPv4 was making the integer too few bits.

Owen

Re: A crazy idea

[Owen DeLong via NANOG]

> On Jul 29, 2021, at 22:23, Frank Habicht  wrote:
> 
> Hi,
> 
> On 30/07/2021 07:58, Owen DeLong via NANOG wrote:> ...
>> Consider this… I discussed this topic at length with JJB (COMCAST at
>> the time) and pushed hard on why they don’t give /48s to their
>> residential customers. His answer was that if they did so, they would
>> need to get a /12 from their RIR (ARIN). My question to him in
>> response to that was “so?”.
> 
> 
> I recently got this "so?" question asked [1] and I believe I follow you
> and see the point.
> 
> My response was along the line:
> - today (at least here in AfriNIC-land - sorry to get out of "NA")
>  the RIR charges membership fee depending on size of IPv4 allocations.
> - Will the RIR charge membership fee depending on IPv6 allocation size
>  in 5 years from now?
> 

I believe all RIRs charge by size for LIRs in some form or other. ARIN is by 
max_fee(IPv4,IPv6). 

In the case in question (COMCAST), they are already in the maximum fee 
category, so expanding their v6 allocation to /12 would not increase their 
fees. 

I would argue that since (at least in ARIN), you get 16x as much address space 
for 2x the fee, revenues from the expanded customer base should easily dwarf 
the cost of additional addresses to issue proper /48s to every customer. 

> And it's a genuine question.
> Does anyone know what the intentions or likelihood of options are?

I think COMCAST intends to continue subjugating their customers with limited 
address blocks for the foreseeable future. 

I am hoping that other IPSs will be more rational and eventually market 
pressure will bring about ubiquitous /48s. 

Owen

> Really interested.
> 
> Thanks,
> Frank
> 
> [1]
> by staff member asking why we don't replace the existing v6 /32 with
> something bigger.

Re: A crazy idea

[Owen DeLong via NANOG]

> On Jul 29, 2021, at 14:06 , Joe Maimon  wrote:
> 
> 
> 
> t...@pelican.org wrote:
>> On Monday, 19 July, 2021 14:04, "Stephen Satchell"  said:
>> 
>>> The allocation of IPv6 space with prefixes shorter than /64 is indeed a
>>> consideration for bigger administrative domains like country
>>> governments, but on the other end, SOHO customers would be happy with
>>> /96, /104 or even /112 allocations if they could get them.  (Just how
>>> many light bulbs, fridges, toasters, doorbells, phones, &c does SOHOs
>>> have?)  I would *not* like to see "us" make the same mistake with IPv6
>>> that was made with IPv4, handing out large blocks of space like so many
>>> pieces of M&M or Skittles candy.
>> Nay, nay, and thrice nay.  Don't think in terms of addresses for IPv6, think 
>> in terms of subnets.  I can't stress this enough, it's the big v4 to v6 
>> paradigm shift - don't think about "how many hosts on this net", think about 
>> "how many nets".
> 
> Think of how many large ISP's a /3 of ipv6 effectively holds, assuming that 
> /48 per customer is the norm, and /24 up to /12 assignments for those ISP's 
> is also.
> 
> In those terms IPv6 isnt that much bigger.


Let’s say an average “large” ISP burns a /11 of IPv4 serving their ~2M 
customers with a single IPv4 address each.
IPv4 supports a maximum of 2,048 such ISPs without regard to space for 
multicast, class E, etc. (which reduce this number).

Let’s say that we give each of them enough space to issue 16M /48s (an IPv6 
/24).

That means we have 2^21 IPv6 large ISPs serving 8x as many customers with /48s.

That’s 2 million large ISPs covered in the first /3.

Since each of them is serving around 2M customers, that’s 4,000,000,000,000 
customers.
For comparison, the world population is less than8,000,000,000.

Tell me again how IPv6 is not that much larger, Joe?

Owen

Re: A crazy idea

[Owen DeLong via NANOG]

> On Jul 29, 2021, at 14:14 , Daniel Corbe  wrote:
> 
> 
> 
>> On Jul 29, 2021, at 16:06, Joe Maimon  wrote:
>> 
>> 
>> 
>> t...@pelican.org wrote:
>>> On Monday, 19 July, 2021 14:04, "Stephen Satchell"  said:
>>> 
 The allocation of IPv6 space with prefixes shorter than /64 is indeed a
 consideration for bigger administrative domains like country
 governments, but on the other end, SOHO customers would be happy with
 /96, /104 or even /112 allocations if they could get them.  (Just how
 many light bulbs, fridges, toasters, doorbells, phones, &c does SOHOs
 have?)  I would *not* like to see "us" make the same mistake with IPv6
 that was made with IPv4, handing out large blocks of space like so many
 pieces of M&M or Skittles candy.
>>> Nay, nay, and thrice nay.  Don't think in terms of addresses for IPv6, 
>>> think in terms of subnets.  I can't stress this enough, it's the big v4 to 
>>> v6 paradigm shift - don't think about "how many hosts on this net", think 
>>> about "how many nets".
>> 
>> Think of how many large ISP's a /3 of ipv6 effectively holds, assuming that 
>> /48 per customer is the norm, and /24 up to /12 assignments for those ISP's 
>> is also.
>> 
>> In those terms IPv6 isnt that much bigger.
> 
> I haven’t seen evidence that any RIR has allocated an entire /12 to an ISP.  
> Even a large one.  

I haven’t seen any evidence that an ISP has requested a /12 from an RIR. How 
would an RIR issue a block that hasn’t been requested?

Owen

Re: FYI - Proposed process change at ARIN for some request tickets (was: Fwd: [ARIN-consult] Consultation on Retiring the Officer Attestation Requirement)

[Owen DeLong via NANOG]

> On Aug 3, 2021, at 05:56 , John Curran  wrote:
> 
> NANOGers - 
> 
> The following process change is being proposed in order to simplify customer 
> request tickers for new number resources and improve overall service. 
> 
> If you have strong feelings one way or the other, thenplease join the 
> arin-consult list and make them known.  (Note - the arin-consult mailing list 
> is open to all in accordance with ARIN’s Mailing List AUP and Standards of 
> Behavior.)
> 
> Thanks! 
> /John
> 
> John Curran
> President and CEO
> American Registry for Internet Numbers
> 
>> Begin forwarded message:
>> 
>> From: ARIN mailto:i...@arin.net>>
>> Subject: [ARIN-consult] Consultation on Retiring the Officer Attestation 
>> Requirement
>> Date: 3 August 2021 at 8:13:53 AM EDT
>> To: mailto:arin-cons...@arin.net>>
>> 
>> ARIN regularly reviews existing processes as part of our continual 
>> improvement efforts to be more responsive and improve the service our 
>> customers receive from ARIN. Recently ARIN reviewed the Officer Attestation 
>> process and as a result of that review have determined the Officer 
>> Attestation process is no longer necessary for achievement of its original 
>> goals and should be retired. The purpose of this consultation is to review 
>> this proposed change with the community prior to its implementation.
>> 
>> The Officer Attestation was introduced in 2007 in preparation for the 
>> depletion of IPv4 addresses. Currently, ARIN requires an Officer Attestation 
>> for all requests that involve a needs analysis (which today consist of 
>> waiting list requests, NRPM 4.4 micro-allocations, NRPM 4.10 IPv6 
>> transition, IPv6 requests, and transfer recipient requests.)
>> 
>> However, conditions have changed since this requirement was established, and 
>> ARIN believes that the Officer Attestation for resource request tickets is 
>> no longer necessary for the following reasons:
>> 
>> - Today IPv4 resources are issued by ARIN predominantly via the Waitlist 
>> policy, and this policy has been revised to only allow one small request per 
>> party (thus avoiding the original risk of “hoarding” via large suspect 
>> requests prior to runout).

Correct me if I am wrong, John, but I believe this is one small request per 
party at a time, not for all time. (e.g. unlike APNIC’s original final /22 per 
member policy for their last /8, ARIN does allow an organization to apply to 
the waitlist, receive addresses, then upon utilization of those addresses apply 
to the waitlist again).

>> - With regard to transfers of IPv4 resources obtained via the transfer 
>> market, the inherent costs for large transfers ensures organizational 
>> officers are “in the know”.
>> - Given IPv6 availability, officer attestation of need for IPv6 resources is 
>> not necessary.

Interesting reversal. I argued when officer attestation was first introduced 
that applying it to IPv6 was silly and you were among those expressing 
skepticism. What brings about this change of heart? IPv6 is certainly no more 
plentiful today than it was back then.

>> The review identified that at this point in time the Officer Attestation 
>> process is problematic for many customers, predominantly posing an 
>> administrative burden that does not materially improve policy implementation 
>> and resulting in numerous complaints and adding unnecessary delay (varying 
>> between two days and an entire week) to completion of resource request 
>> tickets.

It’s a small administrative burden, but despite processing requests for many 
clients of a variety of sizes and assisting many other clients of significant 
size in handling their own requests, I have not encountered a single 
environment where I would call it “problematic”.

I have always felt that it did not materially improve policy implementation 
with regard to IPv6 and I stand by that sentiment.

I remain unconvinced that it is unimportant for IPv4, despite the escalating 
costs of IPv4 addresses.

>> In light of the administrative burden to customers and undefined benefit, 
>> ARIN proposes dropping the Officer Attestation requirement – note that this 
>> specifically does not change documentation requirements related organization 
>> recovery of IP number resources or related anti-fraud measures that ARIN has 
>> implemented.

I think removing this requirement for IPv4 is premature at best.

I think removing this requirement for IPv6 is long overdue as it has never 
served a policy purpose.

Owen

>> 
>> This consultation will remain open for 10 days.
>> 
>> Please provide comments to arin-cons...@arin.net 
>> . You can subscribe to this mailing list at: 
>> http://lists.arin.net/mailman/listinfo/arin-consult 
>> .
>> 
>> Discussion on arin-cons...@arin.net  will 
>> close on 13 August 2021.
>> 
>> Regards,
>> 
>> John Curran
>> President and CEO
>> American Registry for Int

Re: Where to get IPv4 block these day

[Owen DeLong via NANOG]

The single biggest problem with IPv4 is NAT. The primary cause of NAT is 
address shortage. As such, I’d argue that IPv6 solves the two biggest problems 
with IPv4. 

Problem is that those who want to wait until everyone else moves forward before 
they do are a sufficient mass to severely hamper forward progress. 

Owen


> On Aug 6, 2021, at 08:10, Fred Baker  wrote:
> 
> 
> 
>> On Aug 6, 2021, at 6:48 AM, Josh Luthman  wrote:
>> 
>> v6 isn't a solution today for v4 problems.
> 
> I don't know that IPv6 was ever intended to be a solution to IPv4 problems 
> per se. It was intended to be an IPv4 replacement to provide connectivity.

Re: Amazon Prime Video IP reputation

[Owen DeLong via NANOG]

That’s probably going to be a common theme with CGN and is a really good reason 
to make IPv6 available to as many of your customers as possible.

Owen


> On Aug 17, 2021, at 16:30 , Eric C. Miller  wrote:
> 
> Does anybody know which IP reputation service Amazon uses for Prime video? 
> Within the last couple of hours several of our CGNAT publics are showing up 
> as VPN or proxy when someone tries to watch Amazon video.
> 
> Any help would be appreciated!
> 
> Thank you!
> Eric

Re: Newbie Questions: How-to monitor/control unauthorized uses of our IPs and DNS zones?

[Owen DeLong via NANOG]

> On Aug 19, 2021, at 12:34 , Adam Thompson  wrote:
> 
> I just had a conversation with John Curran (of ARIN) about this, in fact...
> 
> You don't own IP addresses.  But you also don't rent IP addresses, either.

True, but you can rent the registration of an IP address, or, you can acquire a 
registration that you pay a monthly maintenance fee for.

In the former case, you are obtaining the registration from an LIR or possibly 
an end user (though unlikely and not permitted in all RIRs). The LIR takes care 
of registering your temporary possession of all or part (usually part) of their 
registration in the appropriate shared database(s) and the rental fee is either 
included with your connectivity bill or billed separately, depending on the 
LIR’s particular business practices. Some LIRs don’t provide connectivity 
services, while most do. Some include address registration in their 
connectivity price, others do not.

In the latter case, you are going directly to one of the five RIRs and 
obtaining an allocation or assignment. The registration of a unique set of 
numbers specifically to your entity is recorded by the RIR in their database(s) 
and published for all the world to see.

> IP addresses are not a thing, good, or object, not even an intangible good.  
> They are an address, or an index, if you will.  (You might think of an IP 
> address as the index on a giant, internet-wide, shared array... that we call 
> "the routing table".)

That analogy breaks down very quickly as the routing table is built out of 
prefixes and not addresses, but as oversimplifications go, it’s not entirely 
terrible.

> Your annual fee purchases registration services, specifically, the service of 
> ARIN entering your IP addresses into their master copy of a database that 
> other people use.  (And some ancillary services that ARIN provides to you.)  
> That's it.

That depends on who you are paying your fee to, but if you’ve gone directly to 
an RIR, specifically ARIN, yes, that’s the case.

> The closest analogy I have are either phone numbers or street addresses.  You 
> don't own either of those things, nor do you rent them.  In the case of phone 
> numbers, the phone company isn't renting you the phone#, they're renting you 
> the POTS service that gives you the ability to make outgoing, and answer 
> incoming, calls.  Your ILEC also typically adds your name and # into a phone 
> book, as part of the service.  (Yeah, VoIP providers have mangled this 
> analogy beyond recognition.)  They can (and have) changed your phone number 
> at will.  At least ARIN doesn't do that.

It’s actually a lot more like license plates. You don’t own the license plate 
or the license plate number, but you pay a registration fee every year for DMV 
(or your jurisdiction’s equivalent) for the privilege of them telling police 
officers who that plate points to whenever they ask. The car is like your 
routers and network… You own that, but you don’t own the numbers you got from 
DMV to label each piece of equipment. However, the numbers do uniquely point to 
the fact that the equipment is yours.

> Here's the problematic part: there's absolutely nothing saying you have to 
> register your addreses with an RIR to get them into the global routing table. 
>  You could probably find an ISP somewhere willing to overlook all the rules 
> and conventions and advertise new address space that just happens to overlap 
> with someone else's registered addresses, or maybe you found some that aren't 
> currently advertised.  In fact, I'd say it's 100% possible to do so.

Fortunately, over time, this is actually getting harder. Between improved IRR 
filtering and other tools, combined with a tendency to de-peer networks that 
habitually announce prefixes on behalf of people they are not registered to, 
the situation has somewhat improved.

OTOH, RPKI, especially with AS0 ROAs radically alters this trust model in that 
it provides an avenue for an RIR that becomes a bad actor to do great and 
immediate damage to entities it chooses to attack. I’m not saying there are any 
RIRs that would abuse this power, but I’m also not as confident as I used to be 
that none of them would.

> However, nearly everyone agrees to play by a common set of rules, in order 
> that the Internet, well... works.  As expected.  Almost 100% of the time, 
> taken as a whole.  Those rules include requiring you to register with an RIR, 
> to ensure there are no overlaps, and law enforcement can find you if 
> necessary.

It’s also important to note that the RIRs have rules they are supposed to play 
by which are developed through their respective policy development processes. 
To date, they’ve generally made a pretty strong effort to do so. There is one 
RIR that is unfortunately a glaring exception at the moment.

> Again, you aren't buying or renting IP addresses - you're paying an admission 
> fee of sorts, in order to play in the global routing table.  The fact your 
> RIR assig

Re: An update on the AfriNIC situation

[Owen DeLong via NANOG]

There are two sides to every story…

On Fri, 27 Aug 2021 at 09:44, Lu Heng mailto:h...@anytimechinese.com>h 
.l...@anytimechinese.com> wrote:
> 
> Dear John:
> 
> The statements you made are very misleading.
> 
> Here are some clarifications:
> 
> Cloud Innovation is disputing AFRINIC’s claim that Cloud Innovation is
> in breach of the agreement. Cloud Innovation maintains that we are a
> compliant member.
> 
> 1. While I make no comment regarding the justification of our
> resources. we have rights just like any other registrant to keep our
> justification material confidential. We would like to share some
> public data here:
> Cloud innovation accounts for 80% of all AFRINIC whois updates in 2021
> to date and in AFRINIC whois,  over 10  million (roughly 10% of all
> AFRINIC space) IP addresses whois information has not been updated in
> more than 10 years. 40million (roughly 40%) IP addresses have not been
> updated in more than 5 years. Have all of them been required to
> provide re-justification while they don’t bother to update whois?
> 313 out of 1800 members have not made a single assignment in their
> allocations more than a year after receiving. 641 member registered
> show less than 50% utilization, while AFRINIC’s CPM 5.5.1.9 requires
> at least 50% utilization. All of those member are in violation,
> including several major telecoms.
> However according to one press we saw, AFRINIC only audited 15 member
> and terminated 5 of them,  Cloud Innovation being the most compliant
> member in terms of whois update and utilization data provided to
> AFRINIC as data shows above.
> 
> 2. I did go to ARIN for resource, ARIN requested customer personal
> information down to street names, personal address, all of which we do
> not collect in our business from end users due to data privacy
> concerns. I have mentioned in one of ARIN’s meeting and received a
> consistent answer that it must be provided before the resources can be
> allocated. While I later understood it is part of ARIN policy, I still
> believe that it is an unwise policy which puts ARIN in possession of a
> large collection of personally identifying information (PII).
> So abandoning our ARIN application for resources after RIPE ran out,
> was a legitimate business decision and IMHO, a morally correct one
> made in order to protect the privacy of our customer’s.
> John's statement is misleading at best. John himself has repeatedly
> stated that ARIN does not deny requests, but that applicant’s often
> abandon requests when they are unwilling or unable to provide the
> requested data. That’s exactly what happened here. Contrary to John’s
> claim, that ARIN refused the application in question, the actual facts
> of the matter are that Outside Heaven chose to abandon its request
> rather than compromise the confidentiality of its customers and trust
> ARIN with such a significant amount of customer PII.
> 
> 4. Cloud Innovation's utilization is global, roughly 30% Asia and 30%
> US, with rest equally spread throughout Europe, AFRICA, and Latin
> America. There is nothing in AFRINIC policy manual which restricts
> usage of resource anywhere. And it is also common practice of several
> large US firms to use ARIN space either globally or across multiple
> regions at least.
> 
> 5. Unless ARIN admits it has been given the justification submitted to
> AFRINIC by Cloud Innovation in past years, we don't think it is within
> ARIN’s mandate to comment whether it is being used for the same
> purpose or not. John, please clarify, have you  received the
> justification material we submitted to AFRINIC? Do you have any inside
> knowledge about it? We would be very keen to know if AFRINIC has
> disclosed our private data to a third party in this process in
> violation of the very agreement they (unjustly) accuse us of
> breaching.
> 
> 6. We find your discussion of the RIR stability fund most interesting…
> Please correct us if we misunderstand, but our understanding is that
> the fund requires the unanimous consent of all 5 RIR CEOs in order to
> be utilized. As such, it appears you are attempting to mislead the
> community by making a 20% promise as if it were a 100% assurance.
> 
> For the above reasons, we think that Mr. Curran has not provided a
> balanced or fully accurate representation of the facts to the ARIN
> community here and we hope that the above clarification will help
> members of the community come to a more fully informed opinion.
> 
> Finally, while we realize that this is inappropriate for PPML, as it
> does not really touch on any ARIN policy discussion, we believe that
> Mr. Curran’s post could not be allowed to stand without rebuttal.
> Since he chose to make such a non-policy post to PPML, we felt that
> our posting of the rebuttal here was justified.
> 
> Unless Mr. Curran or other ARIN staff member(s) choose to further
> engage on this topic here, this will be our only post on the matter to
> this list. W

Re: [EXTERNAL] An update on the AfriNIC situation

[Owen DeLong via NANOG]

Two reasons:

1.  They don’t have an AS0 ROA policy currently.

2.  It would violate a court order.

Owen


> On Aug 27, 2021, at 09:45 , Compton, Rich A  wrote:
> 
> Can't AfriNIC just create ROAs for the prefixes and point them to AS0?  That 
> would pretty much make the prefixes unusable since most tier 1's are doing 
> ROV now.
> 
> -Rich
> 
> On 8/27/21, 10:20 AM, "NANOG on behalf of Aaron Wendel" 
>  aa...@wholesaleinternet.net> wrote:
> 
>CAUTION: The e-mail below is from an external source. Please exercise 
> caution before opening attachments, clicking links, or following guidance.
> 
>I suppose people who wanted to take a side could also block traffic to 
>and from Cloud Innovations IP blocks.
> 
> 
>On 8/27/2021 10:36 AM, Bill Woodcock wrote:
>> As many of you are aware, AfriNIC is under legal attack by Heng Lu / “Cloud 
>> Innovation.”
>> 
>> John Curran just posted an excellent summary of the current state of affairs 
>> here:
>> 
>>
>> https://teamarin.net/2021/08/27/afrinic-and-the-stability-of-the-internet-number-registry-system/
>> 
>> If, like me, you feel like chipping in a little bit of money to help AfriNIC 
>> make payroll despite Heng having gotten their bank accounts frozen, some of 
>> the African ISP associations have put together a fund, which you can donate 
>> to here:
>> 
>>https://www.tespok.co.ke/?page_id=14001
>> 
>> It’s an unfortunate situation, but the African Internet community has really 
>> pulled together to defend themselves, and they’ve got a lot less resources 
>> than most of us do.
>> 
>>-Bill
> 
> 
> E-MAIL CONFIDENTIALITY NOTICE: 
> The contents of this e-mail message and any attachments are intended solely 
> for the addressee(s) and may contain confidential and/or legally privileged 
> information. If you are not the intended recipient of this message or if this 
> message has been addressed to you in error, please immediately alert the 
> sender by reply e-mail and then delete this message and any attachments. If 
> you are not the intended recipient, you are notified that any use, 
> dissemination, distribution, copying, or storage of this message or any 
> attachment is strictly prohibited.

Re: An update on the AfriNIC situation

[Owen DeLong via NANOG]

> On Aug 28, 2021, at 10:02 , Masataka Ohta  
> wrote:
> 
> John Curran wrote:
> 
>> Indeterminate at this time, since a “Freezing Order" issued via ex
>> party hearing doesn’t actually test the strength of the arguments, as
>> the affected party is not present to respond.  It is only when the
>> case for the validation of the order is heard that the strength of
>> the arguments could possibly be assessed.  Note - the full list of
>> cases filed are here > > for reference.

I believe John is referring to the original ex parte order. However, this
ignores that AFRINIC got a hearing on the merits when they sought a
variance to the order. As AFRINIC announced, they did not get the
variance they sought, though the judge did grant them access to some
limited funds on a one time exceptional basis. Therefore, the implication
that the merits have not been evaluated is not entirely true.

> Then, several years will be lost if we wait Mauritius court
> settle the issue.
> 
> A quick fix for the international internet community can be to
> abandon AfriNIC and establish, outside of Mauritius, a new entity,
> which may employ current AfriNIC employers, recognized by the international 
> internet community.

I think this would be complicated and that the Mauritius court might take
a dim view of the assets fo AFRINIC trying to leave the country in the
dead of night to avoid court proceedings.

Owen

Re: An update on the AfriNIC situation

[Owen DeLong via NANOG]

> On Aug 29, 2021, at 12:48 , Jay Hennigan  wrote:
> 
> On 8/29/21 11:42, Constantine A. Murenin wrote:
> 
>> It would seem reasonable to leave the whole issue up to the courts,
>> instead of engaging in contempt of foreign courts, and to stop the
>> vigilante justice against any of the parties, especially the end users
>> who are not even a party to this whole dispute.
> 
> The end users are an indirect party.
> 
> Assume someone were in the business of stealing cars, forging their titles, 
> and selling them to innocent third parties. A police officer pulling someone 
> over for speeding might compare the VIN on the title to that on the car and 
> discover that it was stolen. The stolen property would be returned to its 
> owner and the end user purchaser would be out of luck other than having 
> recourse against the thief.
> 
> The same principle applies to someone who innocently accepts counterfeit 
> money.

Sure, but that’s not exactly what happened here. There’s a limit to what I can 
say, but the already public facts show
that:

AFRINIC started this fight by threatening to revoke Cloud Innovations address 
space.

Cloud Innovation is disputing this revocation on the basis that it has not 
violated the RSA, CPM, or Bylaws as they are written.

AFRINIC has a history of making up process as they go along and violating their 
own rules whenever it suits them.

AFRINIC has violated court orders and acted in bad faith at virtually every 
opportunity in this process.

As such, I think vigilante action and/or trying this case here on NANOG is 
probably not the best idea. I realize it’s easy to sympathize with John and he 
puts forth a good story, but there is more to the story than what John has 
represented here.

Owen

Re: An update on the AfriNIC situation

[Owen DeLong via NANOG]

> On Aug 29, 2021, at 17:41 , Masataka Ohta  
> wrote:
> 
> John Levine wrote:
> 
>> I would be astonished if ICANN had a position. For one thing, they
>> have no provision for dealing with competing IP registries since the
>> issue has never come up
> 
> As
> 
>   ICP-2: Criteria for Establishment of New Regional
>   Internet Registries
>   https://www.icann.org/resources/pages/new-rirs-criteria-2012-02-25-en
>   2) The new RIR must demonstrate that it has the broad
>   support of the LIRs (ISP community) in the proposed region
> 
> if overwhelming majority, which means there is no competition,
> of LIRs in AfriNIC region request to abandon AfriNIC and to
> have an alternate RIR, ICANN should honor the request.

ICANN _MIGHT_ be able (under ICP-2) to honor the request to accredit
a new RIR if one is created. ICANN has no authority under ICP-2 to do
anything about any RIR once it is accredited. There is no process for
revoking an RIR’s accreditation and there is no mechanism for any entity
to do so that I am aware of.

>> For another, they are extremely allergic to
>> anything that might even possibly involve them in a lawsuit.
> ICANN was established to protect governance structure (including
> RIRs, of course) of the Internet free from government (especially
> USG) interventions. As such, ICANN is expected to work to isolate
> African RIR operations from existing lawsuit.

I think you have that somewhat wrong. Regardless of what you or anyone
else may think ICANN was established for, the simple reality is that ICANN’s
only ability to engage on any of this is that granted to it by the various IANA
functions contracts from the empowered communities (IETF, NRO/ASO/RIRs,
and various Domain-Related organizations). (No, I don’t have all the exact
details spelled out correctly here, it’s almost impossible to identify them).

ICANN does not have any ability to isolate African RIR operations from an
existing lawsuit. If you think I’m wrong, please identify the authority and
mechanism by which they could possibly do so.

Owen

Re: An update on the AfriNIC situation

[Owen DeLong via NANOG]

> On Aug 30, 2021, at 06:30, Rubens Kuhl  wrote:
> 
> On Mon, Aug 30, 2021 at 3:39 AM Owen DeLong via NANOG  
> wrote:
>> 
>> 
>> 
>>>> On Aug 29, 2021, at 12:48 , Jay Hennigan  wrote:
>>> 
>>>> On 8/29/21 11:42, Constantine A. Murenin wrote:
>>> 
>>>> It would seem reasonable to leave the whole issue up to the courts,
>>>> instead of engaging in contempt of foreign courts, and to stop the
>>>> vigilante justice against any of the parties, especially the end users
>>>> who are not even a party to this whole dispute.
>>> 
>>> The end users are an indirect party.
>>> 
>>> Assume someone were in the business of stealing cars, forging their titles, 
>>> and selling them to innocent third parties. A police officer pulling 
>>> someone over for speeding might compare the VIN on the title to that on the 
>>> car and discover that it was stolen. The stolen property would be returned 
>>> to its owner and the end user purchaser would be out of luck other than 
>>> having recourse against the thief.
>>> 
>>> The same principle applies to someone who innocently accepts counterfeit 
>>> money.
>> 
>> Sure, but that’s not exactly what happened here. There’s a limit to what I 
>> can say, but the already public facts show
>> that:
>> 
>> AFRINIC started this fight by threatening to revoke Cloud Innovations 
>> address space.
>> 
>> Cloud Innovation is disputing this revocation on the basis that it has not 
>> violated the RSA, CPM, or Bylaws as they are written.
>> 
>> AFRINIC has a history of making up process as they go along and violating 
>> their own rules whenever it suits them.
> 
> Are you saying that there was no AFRINIC policy at allocation time
> that prevented usage outside Africa ?

Not only then, but now as well. The only such policy in the CPM is enshrined 
within the soft landing policy and applies only to registrations made after 
exhaustion phase 1 started. 

>> AFRINIC has violated court orders and acted in bad faith at virtually every 
>> opportunity in this process.
> 
> Nope, see Tom's message right before this one.

The court ordered AFRINIC to reinstate cloud innovation on the 13th. They 
deliberately delayed until the 15th hoping to win a hearing that morning. They 
did not get what they wanted, instead being admonished by the judge.

>> As such, I think vigilante action and/or trying this case here on NANOG is 
>> probably not the best idea. I realize it’s easy to sympathize with John and 
>> he puts forth a good story, but there is more to the story than what John 
>> has represented here.
> 
> It's not just John as you have seen by now. And besides the case
> merits, the main issue is CI trying to win by suffocation. And that's
> why carpet bombing those IP blocks might be needed so the next scumbag
> doesn't try the same trick with someone else.

This is neither a fair nor accurate portrayal of the situation. Further, by 
acting as it had, AFRINIC was the one which tried to suffocate CI first.

You may not like Lu and/or his business model. I’m not a fan of his business 
model myself, but it is technically permitted under existing policy. If the 
community doesn’t like that fact, there is a process to change the policies. 
Terminating a member based on rules which don’t actually exist, on the other 
hand sets a very dangerous and corrupt precedent and is a threat to the trust 
we all want to have in the RIR system. 

Owen

Re: An update on the AfriNIC situation

[Owen DeLong via NANOG]

> On Aug 30, 2021, at 07:44 , Mark Tinka  wrote:
> 
> 
> 
> On 8/30/21 16:19, Owen DeLong via NANOG wrote:
> 
>> You may not like Lu and/or his business model. I’m not a fan of his business 
>> model myself, but it is technically permitted under existing policy.
> 
> And yet you continue to work for and support him in this capacity.

Yes… Because it is permitted by the rules as they exist.

Just as I would fight for the rights of those I disagree with to express their 
views in the US under the first amendment rights granted by the US Constitution.

If one is to believe in the rule of law, one must not attempt to distort the 
law to punish those you do not like if they are compliant with the law. 
Instead, work through the legitimate processes as they exist to change the laws.

There are a variety of possible ways in which the AFRINIC community could 
develop legitimate policies which would be problematic for the business model 
of Cloud Innovation (or at least require some changes to their business 
practices). However, no such policy has yet come to consensus and attempting to 
inflict policies which don’t exist on any resource member and revoke that 
member’s resources according to said non-existent policies is just plain wrong. 
As I have stated before, I think that AFRINIC’s willing to engage in practices 
not supported by the bylaws, CPM, or RSA is the greater threat to the RIR 
system, so I oppose AFRINIC on that basis. Quite literally, IMHO, in the 
interests of this very community.

I get that it’s popular to dislike Lu. He’s not a particularly likable guy at 
first blush. He’s arrogant, profit focused, and comes from a non-technical 
business background. But this isn’t a popularity contest. This is about the 
very soul of the AFRINIC and whether we want an organization that operates 
according to its governing documents, or one which substitutes the ideology and 
judgment of its staff in place of the guidance from the community in order to 
carry out a vendetta against a member that is unpopular.

So yes, I continue to work for and support Lu in this capacity because in this 
case, I believe AFRINIC has overstepped its mandate and acted contrary to its 
own policies and bylaws as they are written. I am standing up for what I 
believe to be right, even though I don’t particularly like the side that puts 
me on in this case. I tried my best to make this clear before things escalated. 
I did everything I could to avert this escalation, but I faced even more 
problematic egos on the AFRINIC side than on the Cloud Innovation side.

I am here doing what I am doing because I have ethics and morals. Because even 
though I often disagree with Lu, in this case, he happens to be right and 
AFRINIC must not be allowed to act so irresponsibly in this matter.

Owen

Re: An update on the AfriNIC situation

[Owen DeLong via NANOG]

Um, Mike, no… That’s neither a fair nor accurate characterization of the current
situation.

AFRINIC has been given access to the equivalent of two months of operating costs
from their bank accounts in a recent court ruling, so they are nowhere close to 
shut
down. All of the chicken littles running around claiming otherwise 
notwithstanding,
no, AFRINIC was never actually shut down.

Further, the registries are not engaged in the daily operations of the 
internet. They
come into play for adds and changes, primarily and those transactions while 
important
are not generally urgent. Were AFRINIC unable to staff its offices for some 
period of
time, I’m quite certain that the other RIRs would be able to take up those key 
functions,
either by loaning personnel to AFRINIC or by taking over those necessary roles 
as
needed either temporarily or permanently.

So while having the system react strongly to such a threat would be 
understandable,
that’s a very overblown and inaccurate characterization of the threat in 
question.

Owen


> On Aug 30, 2021, at 11:00 , Mike Hale  wrote:
> 
> But to be clear, if this was a simple court case I don't think anyone
> on this list would have an issue with simply sitting back and letting
> the court decide.
> 
> You have to remember though that CI in this case has essentially
> forced one of the major registrars to virtually shut down.  That's a
> direct attack on the system that is of fundamental importance to the
> proper running of the Internet.  Having the system react strongly to
> such a threat is entirely understandable.
> 
> On Mon, Aug 30, 2021 at 10:40 AM Sabri Berisha  wrote:
>> 
>> - On Aug 30, 2021, at 6:29 AM, Rubens Kuhl rube...@gmail.com wrote:
>> 
>>> And that's why carpet bombing those IP blocks might be needed so the next
>> 
>> entity that ends up with those IP addresses long after CI has gone into
>> oblivion will have its engineers debug odd routing issues for years. We all
>> know that people regularly fail to update their manually entered filters on
>> at least a few of their routers.
>> 
>> The learned people on this list do not strike me as the kind of person to
>> go out and engage in vigilante justice if a court decides against them. The
>> very fabric of our civilized society depends on us resolving our conflicts
>> in court, not out on the (virtual) streets. You may disagree with a ruling
>> but I implore you to respect it.
>> 
>> Rules... Without them we'd live with the animals.*
>> 
>> Thanks,
>> 
>> Sabri
>> 
>> *(c) John Wick
> 
> 
> 
> -- 
> 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0

Re: An update on the AfriNIC situation

[Owen DeLong via NANOG]

> On Aug 30, 2021, at 16:19 , Noah  wrote:
> 
> 
> Owen,
> 
> On Tue, 31 Aug 2021, 02:10 Owen DeLong via NANOG,  <mailto:nanog@nanog.org>> wrote:
> 
> 
> > On Aug 30, 2021, at 07:44 , Mark Tinka  wrote:
> > 
> > 
> > 
> > On 8/30/21 16:19, Owen DeLong via NANOG wrote:
> > 
> >> You may not like Lu and/or his business model. I’m not a fan of his 
> >> business model myself, but it is technically permitted under existing 
> >> policy.
> > 
> > And yet you continue to work for and support him in this capacity.
> 
> Yes… Because it is permitted by the rules as they exist.
> 
> Cloud Innovation your employer is in the business of leasing IPv4 addresses 
> in Asia, USA and Europe etc.

Not my employer, my client.

> AFRINIC has never permitted this and Ashil from AFRINIC publicly stated as 
> such in the below archived thread.

Yet their policies do not prohibit it. If you can find someplace where it is 
actually documented as a violation of policy, then by
all means, provide that, but you have so far failed to do so despite repeatedly 
bringing up this argument.

It’s simply not sufficient to say “they never allowed this” if it’s not 
prohibited by actual policy.

> https://lists.afrinic.net/pipermail/community-discuss/2021-February/003907.html
>  
> <https://lists.afrinic.net/pipermail/community-discuss/2021-February/003907.html>
> 
> You always claim policy blah blah blah in your defence of Cloud Innovation 
> Ltd and Larus business model.
> 
> But there it is. AFRINIC has never approved any IPv4 space for purposes of 
> leasing them for money as through they were a product.

Except that they have and do every day… ISPs all lease IPv4 space for money. 
That’s what they do with them. They certainly don’t use
them exclusively on their own networks… They lease them to their customers.

The key difference between the majority of them and Cloud Innovation is that 
most of them also include connectivity service in the lease
and/or provide the lease in conjunction with some form of connectivity service. 
However, there’s nothing in the policy manual or the bylaws
to support a requirement that leasing and connectivity be tied to each other.

Owen

Re: An update on the AfriNIC situation

[Owen DeLong via NANOG]

> On Aug 30, 2021, at 16:32 , Noah  wrote:
> 
> 
> Owen 
> 
> On Tue, 31 Aug 2021, 02:10 Owen DeLong via NANOG,  <mailto:nanog@nanog.org>> wrote:
> 
> So yes, I continue to work for and support Lu in this capacity because in 
> this case, I believe AFRINIC has overstepped its mandate
> 
> If you believe, then we leave it at that. Its beliefs.

Sigh… I’m not sure why so many on your side get wrapped up in this word believe 
as if it is somehow exclusive to religion.

Pick whichever of the following leading works for you:

I am convinced that:
It is my opinion that:
The facts show that:
A plaintext reading of the AFRINIC governing documents shows that:
[]:
AFRINIC has overstepped its mandate and acted contrary to its own 
policies and bylaws as they are written.

> AFRINIC has never approved IPv4 for the purpose of leasing them as some 
> product in the manner in which your employer Larus/CIL does.

You continue to call Cloud Innovation my employer… They are my Client, not my 
employer.

AFRINIC approves IPv4 for the purpose of leasing every day. It’s what ISPs do. 
It’s the definition of an LIR.

Yes, most LIRs are also in the connectivity business and provide addresses 
(mostly/exclusively) to customers of their connectivity services.

However, there’s no such policy requirement in the AFRINIC governing documents.

Owen

Re: An update on the AfriNIC situation

[Owen DeLong via NANOG]

> On Aug 30, 2021, at 18:00 , Rubens Kuhl  wrote:
> 
>> AFRINIC approves IPv4 for the purpose of leasing every day. It’s what ISPs 
>> do. It’s the definition of an LIR.
>> 
>> Yes, most LIRs are also in the connectivity business and provide addresses 
>> (mostly/exclusively) to customers of their connectivity services.
> 
> Which is why CI informed AfriNIC in their request that they were going
> to have no network and provide connectivity-less services to CI
> customers, right ?
> 
>> However, there’s no such policy requirement in the AFRINIC governing 
>> documents.
> 
> All RIRs were subject to RFC 2050, now RFC 7020, which states:
> "1)  Allocation Pool Management: Due to the fixed lengths of IP
>   addresses and AS numbers, the pools from which these resources
>   are allocated are finite.  As such, allocations must be made in
>   accordance with the operational needs of those running the
>   networks that make use of these number resources and by taking
>   into consideration pool limitations at the time of allocation."
> 
> If there is no network, there is no use of such number resources.
> 

This is a clear misreading of RFC-2050 and later RFC-7020.

No RIR is subject to them. They are purported to, I quote:

   This document provides information about the current Internet Numbers
   Registry System used in the distribution of globally unique Internet
   Protocol (IP) address space and autonomous system (AS) numbers.

   This document also provides information about the processes for
   further evolution of the Internet Numbers Registry System.

   This document replaces RFC 2050 
.

   This document does not propose any changes to the current Internet
   Numbers Registry System.  Rather, it documents the Internet Numbers
   Registry System as it works today.

As such, errata notwithstanding (for example, it misleadingly claims that 
multi-regional entities interact
with multiple RIRs which is only sometimes true), RFC-7020 can’t be cited as 
imposing any rules
upon RIRs and any case where its content differs from current reality 
represents errata in the RFC and
not misconduct by the RIR or its members or customers.

Owen

Re: An update on the AfriNIC situation

[Owen DeLong via NANOG]

> On Aug 30, 2021, at 19:06 , John Kristoff  wrote:
> 
> On Mon, 30 Aug 2021 16:29:48 -0700
> Owen DeLong via NANOG  wrote:
> 
>> Further, the registries are not engaged in the daily operations of the 
>> internet.
> 
> Hi Owen,
> 
> Your statement above I have to insist is simply incorrect.  In addition
> to the traditional services that are relied upon in a variety of daily
> operations (e.g. WHOIS, IRR, DNS reverse delegations), the increasingly
> important RPKI TAs/PPs services are of utmost importance in the daily
> operations of an increasing number of networks within and outside their
> region.  They are just a different kind of infrastructure service
> operator than we may be commonly thing of when it comes to network
> operations.

Yes, but those services continue even if the registry isn’t open for a couple 
of days.

We can agree to disagree about how useful it is to have a cryptographically 
signed
indication of what to prepend to your spoofing.

My point is that if an RIR itself closes for a few days, its an event that, 
well, happens
pretty much every weekend. After a brief time without the RIR there to make 
changes,
the operations performed by that RIR will almost certainly be taken up either 
temporarily
or permanently by the other RIRs.

Owen

Re: An update on the AfriNIC situation

[Owen DeLong via NANOG]

> On Aug 30, 2021, at 22:06 , Mark Tinka  wrote:
> 
> 
> 
> On 8/31/21 01:29, Owen DeLong via NANOG wrote:
> 
>> Um, Mike, no… That’s neither a fair nor accurate characterization of the 
>> current
>> situation.
>> 
>> AFRINIC has been given access to the equivalent of two months of operating 
>> costs
>> from their bank accounts in a recent court ruling, so they are nowhere close 
>> to shut
>> down. All of the chicken littles running around claiming otherwise 
>> notwithstanding,
>> no, AFRINIC was never actually shut down.
> 
> Wow. Problem solved.
> 
> Mark.

I guess that depends on whether or not AFRINIC is willing to engage in a 
reasonable
settlement effort within the next 2 months or not.

I guess we’ll see what they do.

Owen

Re: An update on the AfriNIC situation

[Owen DeLong via NANOG]

> On Aug 30, 2021, at 22:21 , Mark Tinka  wrote:
> 
> 
> 
> On 8/31/21 07:16, Owen DeLong wrote:
> 
>> I guess that depends on whether or not AFRINIC is willing to engage in a 
>> reasonable
>> settlement effort within the next 2 months or not.
>> 
>> I guess we’ll see what they do.
> 
> Lots of guessing...
> 
> Mark.

Yes… AFRINIC’s actions of late are so illogical that when it comes to 
predicting them, all I can do is guess.

Owen

Re: An update on the AfriNIC situation

[Owen DeLong via NANOG]

> On Aug 31, 2021, at 00:44 , Noah  wrote:
> 
> 
> 
> On Tue, 31 Aug 2021, 03:08 Owen DeLong,  <mailto:o...@delong.com>> wrote:
> 
> 
>> On Aug 30, 2021, at 16:19 , Noah mailto:n...@neo.co.tz>> 
>> wrote:
>> 
>> 
>> Owen,
>> 
>> On Tue, 31 Aug 2021, 02:10 Owen DeLong via NANOG, > <mailto:nanog@nanog.org>> wrote:
>> 
>> 
>> > On Aug 30, 2021, at 07:44 , Mark Tinka > > <mailto:mark@tinka.africa>> wrote:
>> > 
>> > 
>> > 
>> > On 8/30/21 16:19, Owen DeLong via NANOG wrote:
>> > 
>> >> You may not like Lu and/or his business model. I’m not a fan of his 
>> >> business model myself, but it is technically permitted under existing 
>> >> policy.
>> > 
>> > And yet you continue to work for and support him in this capacity.
>> 
>> Yes… Because it is permitted by the rules as they exist.
>> 
>> Cloud Innovation your employer is in the business of leasing IPv4 addresses 
>> in Asia, USA and Europe etc.
> 
> Not my employer, my client.
> 
>> AFRINIC has never permitted this and Ashil from AFRINIC publicly stated as 
>> such in the below archived thread.
> 
> Yet their policies do not prohibit it.
> 
> AFRINIC policies are developed by the community in-line with AFRINIC 
> constitution and related RSA is signed by resource members in-line with the 
> AFRINIC constitution which enshrines the objectives of AFRINIC as the RIR for 
> Africa region.

Yes.

And currently, those policies do not prohibit or place any limitations on out 
of region use except those enshrined in the soft landing policy.

An attempt was made to create a policy several years ago to prohibit or 
restrict out of region use. That proposal did not receive general support from 
the community and was eventually withdrawn by the author.

> If you can find someplace where it is actually documented as a violation of 
> policy, then by
> all means, provide that, but you have so far failed to do so despite 
> repeatedly bringing up this argument.
> 
> I will quote from the AFRINIC bylaws (constution) here 
> https://afrinic.net/bylaws/ <https://afrinic.net/bylaws/>
> 3.4) The Company shall have, both within and outside the Republic of 
> Mauritius, full capacity to carry and/or undertake any business or activity, 
> including but not limited to the following objects:
> 
> to provide the service of allocating and registering Internet resources for 
> the purposes of enabling communications via open system network protocols and 
> to assist in the development and growth of the Internet in the African region;
> to promote the representation of AFRINIC membership and the Internet 
> community of the African region by ensuring open and transparent 
> communication and consensus-driven decision-making processes;
> to promote responsible management of Internet resources throughout the 
> African region, as well as the responsible development and operation of 
> Internet infrastructures;   

Yes: 

> 
> to provide the service of allocating and registering Internet resources for 
> the purposes of enabling communications via open system network protocols
Which covers what Cloud Innovation is doing, so is allowed by the bylaws…
> and to assist in the development and growth of the Internet in the African 
> region;
This creates an additional capability for AFRINIC, but in no way imposes a 
restriction on its members.

The same can be said of clauses 2 and 3. As written, this section of the bylaws 
is clearly written to define the key obligations and responsibilities of the 
company (AFRINIC). Other than possibly the first item, as covered above, there 
is nothing here which restricts or inhibits the conduct of AFRINIC’s members.

> 
> It’s simply not sufficient to say “they never allowed this” if it’s not 
> prohibited by actual policy.
> 
> 
> Allocation policies are such that resource members abide by the AFRINIC 
> constitution.

Yes… Which Cloud Innovation has done.

> See above section 3.4 and the relevant subsections that refer to management 
> of number resource in reference to Africa region.

As I have shown, section 3.4 does not impose the restrictions you appear to 
think it does. The plain text reading of the language in section 3.4 is the 
obligations and/or duties imposed on AFRINIC. It does not extend those 
obligations or duties to AFRINIC’s members.


>> https://lists.afrinic.net/pipermail/community-discuss/2021-February/003907.html
>>  
>> <https://lists.afrinic.net/pipermail/community-discuss/2021-February/003907.html>
>> 
>> You always claim policy blah blah blah in your defence of Cloud Innovation 
>

Re: Operational need for IP address space (Re: An update on the AfriNIC situation)

[Owen DeLong via NANOG]

> Do we have parties who postulate their operational need based on entirely 
> internal services, or services that live within virtual devices in a data 
> center?   Sure…  and some of these are indeed legitimate and fulfilled per 
> policy.  We also have folks who get creative and make similar requests for 
> purposes of obtaining address blocks from ARIN – absent any bona fide 
> networking need –for subsequent monetization and these reviewed, revoked, and 
> can be referred to criminal fraud proceedings.   

Yes, but in the ARIN region, you have also made it very clear that if needs 
change, ARIN will not attempt to revoke or reclaim space based on that change 
in need.

> For those who need IP address blocks for their network operation, it’s really 
> not complicated – you can call, email, or chat with the ARIN Helpdesk and 
> we’ll work you through it.   I don’t know about the policy in the other 
> region, but can state unequivocally that if you call with the need for IP 
> address space for an actual operational networking situation, we’ll do our 
> best to help you with your request and get it approved based on whatever the 
> policies allow.   I can also say that if one's purported operational need for 
> address space is "for reassignment to customers but completely absent any 
> networking service”, then don’t bother applying to ARIN – the policies do not 
> provide for issuance under such circumstances and have never in the ARIN 
> region.

OTOH, a GRE tunnel is sufficient to qualify as “networking service” in the ARIN 
region, so all one needs is the tiniest of fig leaves in front of ones lease to 
make it work.

Owen

Re: Reminder: Never connect a generator to home wiring without transfer switch

[Owen DeLong via NANOG]

> On Aug 31, 2021, at 03:36 , Mark Tinka  wrote:
> 
> 
> 
> On 8/31/21 12:26, Forrest Christian (List Account) wrote:
> 
>> Yes.   Or any other furnace where the electricity is only used for 
>> circulation of the heat.  Gas fired Hot water furnaces would be another 
>> example where there is minimal electricity used to run the furnace controls 
>> and circulate the hot water.
> 
> Gas-fired furnaces or heaters should not have an impact because the only 
> electrical requirement is to fire up the pilot light.

Depends… Forced air gas-fired furnaces (as in most central heating systems) 
also need something to run the squirrel-cage blower.

Most gas furnaces that are not forced air these days do require some 
electricity to run the thermostat, but that’s usually generated from the pilot 
light (very low current 24VAC for the “C” wire).

Don’t get me started on the whole mess that is the C-Wire and the various hacks 
to accommodate legacy systems that don’t have one.

> But fully-electric heating has a much higher impact on energy sources (heat 
> pumps being the least).

Yep.

> I believe typical electric central furnaces are anywhere between 10kW - 15kW 
> systems. Would a standard 4kVA - 8kVA generator for average Jane cut it? Not 
> sure.

15kW is 1.5kVA in a simple radiant electric heat application. (it’s a simple 
resistive load with no power factor weirdness). Whether you could do this with 
4-8kVA depends on what else you’re trying to run.

If you’ve got 3 teenagers all trying to run blow-driers at the same time and 
you also want to run your electric clothes dryer, you’re probably SOL.

If you’re trying to charge a cellphone, a laptop, and run a mostly closed 
refrigerator/freezer, you’re probably OK.

> Then again, I live in a more forgiving climate, so I have a very limited need 
> to understand this better.

Louisiana actually mostly doesn’t get all that cold. In fact, AC is a more 
likely issue in Louisiana than heating.
In the winter, Tennessee gets down to ~9.4C on average (49F), which is still 
well within human tolerance with blankets/coats/sleeping bags.
This time of year, it still tends to be fairly warm there, similar to Louisiana 
(in fact, today’s temperatures in both states are nearly identical).

> But I can understand why the code has not caught up to this yet, and insists 
> on hard-wiring the devices... because the majority of home and buildings will 
> still be using all-electric equipment that require plenty of energy, where 
> things can go wrong if you allow Jane to just run her suicide cord any way 
> she may like. Yes, there may be more folk moving over to other energy sources 
> that eliminate or reduce the need for electricity, but the code has to cater 
> for the wider demographic.

There are a multitude of reasons that a suicide cord is a bad idea beyond just 
the load planning issues and the lack of understanding
of load planning by the average consumer. The average consumer probably doesn’t 
understand that it’s a bad idea to feed 100A
of current through a “heavy duty” 20A extension cord into a 15A outlet to 
back-feed 200A panel through a 15A breaker.


Owen

Re: Reminder: Never connect a generator to home wiring without transfer switch

[Owen DeLong via NANOG]

> On Aug 31, 2021, at 07:15 , Mark Tinka  wrote:
> 
> 
> 
> On 8/31/21 16:06, Mel Beckman wrote:
> 
>> I think you’re forgetting about the all-important blower fan in a gas-fired 
>> furnace.
> 
> Well, I was referring to a pure electric furnace, not one that uses a blower 
> over a gas-fired one :-).
> 
> In that case, the blower is not a major draw on power.
> 
> But again, we don't have those things here, so :-).
> 
> 
>> That said, the reason the code requires furnaces to be hardwired is to 
>> ensure that the blower interlock system can’t be bypassed. An electrical 
>> interlock ties a heat recover ventilator to circulation air blower operation 
>> of a forced-air furnace system. This ensure that the blower circulates 
>> supply and return air within the structure. A plug-in power source leads to 
>> the possibility that this interlock could be accidentally defeated, 
>> resulting in an overheat within the flame box.
> 
> Makes sense.
> 
> Does this, then, mean that if the blower itself were to fail, the gas burner 
> would not light?

Yes… Sort of.

In most cases, the burner lights off ever so slightly before the blower starts 
up (if you’ve ever tried to light a campfire in high wind, you’ll understand 
why).

However, if the blower fails to start producing wind on demand, the gas to the 
burner will be shutoff and the system will go into an error mode requiring a 
reboot or service intervention.

Of course a reboot without correcting the blower issue probably results in a 
repeat of the process.

Owen

Re: Reminder: Never connect a generator to home wiring without transfer switch

[Owen DeLong via NANOG]

> On Aug 31, 2021, at 07:41 , Mel Beckman  wrote:
> 
> Mark,
> 
> But you said “Gas-fired furnaces or heaters should not have an impact because 
> the only electrical requirement is to fire up the pilot light.” There is no 
> gas-fired furnace I know of that doesn’t require a blower fan. How else does 
> the heat get out of the furnace?

For central heating, you’re absolutely correct. However, there used to be 
(don’t know if they are still sold in the US) wall-mounted single and/or 
double-sided gas radiant heaters that distributed hot air out of the top via 
convection and radiated heat from a vertical heat exchanger as well.

> To answer your question, you need to understand that this safety system has 
> two components. The first component, the furnace interlock relay, is designed 
> to interlock the blower with the forced-air system, which also includes an 
> outside air supply valve. When the blower is energized, a circuit inside the 
> furnace gets power. The blower and furnace operate continuously when this 
> circuit is energized, and the supply valve opens and closes as needed to 
> ensure the air doesn’t get stale.

I have no such valve (external air) in my house. I suspect this is applicable 
primarily in industrial/commercial HVAC.

The blower interlock is also slightly different in how it operates on my system.

When the thermostat calls for heat, the electronic ignition starts up. When it 
reaches ignition temperature, the gas solenoid is activated and the burner 
lights off. If ignition is not detected within a set period of time, the 
safeties will shut the system down to error mode.
Assuming ignition is detected, the blower is engaged. If the blower fails to 
start or the temperature in the flame box exceeds a certain value, then the 
safeties will shut the system down to error mode.

> The safety second component is the limit switch, which primarily turns the 
> blower fan on and off, but also has a safety role. When the temperature in 
> the air supply plenum gets too hot, the limit switch turns off the furnace 
> burner (or boiler, in a water-based system) to prevent damage, and possibly a 
> fire, from overheating.
> 
> The actual state mechanics are thus not as simple as “if the blower fails the 
> furnace won’t light”. And it’s because of these complex state mechanics that 
> furnace electricity is hard wired.
> 
> Without AC power, no furnace can operate in a power outage. So that’s 
> certainly not “no impact” from a utility failure. But the many thousands of 
> deaths that occurred in homes and offices before these safety systems were 
> put into the code is why you need a generator transfer switch if you want 
> heat (or A/C) in your home during an outage.

Yep… Unless you have an old-fashioned fireplace, in which case, you can have 
heat without electricity.

Owen

Re: Reminder: Never connect a generator to home wiring without transfer switch

[Owen DeLong via NANOG]

Here’s an example of the type I was describing in my previous post:

https://diy.stackexchange.com/questions/23330/how-can-i-retrofit-this-existing-wall-heater-with-an-external-thermostat

(Primarily for the image, not the subject matter of the page)

Re: An update on the AfriNIC situation

[Owen DeLong via NANOG]

> On Aug 31, 2021, at 08:40 , Jon Lewis  wrote:
> 
> On Mon, 30 Aug 2021, Owen DeLong via NANOG wrote:
> 
>> 
>>  On Aug 30, 2021, at 18:00 , Rubens Kuhl  wrote:
>> 
>>  AFRINIC approves IPv4 for the purpose of leasing every day. It’s what 
>> ISPs do. It’s the definition of an LIR.
>> 
>>  Yes, most LIRs are also in the connectivity business and provide 
>> addresses (mostly/exclusively) to customers of their connectivity services.
>> Which is why CI informed AfriNIC in their request that they were going
>> to have no network and provide connectivity-less services to CI
>> customers, right ?
>> 
>>  However, there’s no such policy requirement in the AFRINIC governing 
>> documents.
> 
> Sorry...I haven't been keeping up with all the messages in this thread, but 
> assuming it's not already been brought up, what about this, which has been in 
> the AfriNIC CPM since v0.1 (i.e. the beginning):
> 
> "5.4.6.2 AFRINIC resources are for AFRINIC service region and any use outside 
> the region should be solely in support of connectivity back to the AFRINIC 
> region."

That’s part of the soft landing policy and applies only to prefixes issued by 
AFRINIC after the beginning of exhaustion phase 1.

It has been in the CPM since its first version, but the CPM is a relatively 
recent phenomenon at AFRINIC, having had scattered policy documents containing 
each adopted policy prior to that.

> I ran into issues years ago, trying to do an additional allocation request 
> with ARIN, only to be told that usage of ARIN-allocated resources 
> out-of-region did not count toward utilization due to some very vague 
> language in the NRPM section 2.2 leading to the "invention" of unwritten 
> policy.  The issue with out of region use of ARIN-allocated resources was 
> eventually resolved with a NRPM section being added explicitly allowing it.

Correct.

> AfriNIC's policy is not at all vague on the matter that their resources are 
> to be used in or to support connectivity in the AFRINIC region.

Try again. AFRINIC’s soft landing policy is not at all vague about prefixes 
issued after soft landing exhaustion phase 1 began. This does not apply to any 
of the prefixes issued to Cloud Innovation.

>> From what I've read, Cloud Innovation primarily uses their AfriNIC IP 
> resources out of region.  How they managed to get a couple of /11s and /12s 
> from AfriNIC seems to be a massive failure on the part of AfriNIC's staff, or 
> did their business model radically change after so much space had been 
> allocated?

Their business model has had to radically change to adapt to radically changing 
circumstances in the marketplace where they started.

Owen

Re: Reminder: Never connect a generator to home wiring without transfer switch

[Owen DeLong via NANOG]

> On Aug 31, 2021, at 09:23 , Sabri Berisha  wrote:
> 
> - On Aug 31, 2021, at 2:11 AM, Forrest Christian (List Account) 
> li...@packetflux.com wrote:
> 
> Hi,
> 
>> I just wish the electrical code would permit or require certain low cost 
>> things
>> which make temporary generator connections more likely to be safe.
> 
>> For example, code requires most furnaces to be hardwired. But a furnace is 
>> one
>> of the first things you want on a generator in an extended winter power 
>> outage.
>> If instead of hardwired, the code required plug and socket connections at 
>> each
>> 120v furnace then Joe homeowner would be more likely to run an extension cord
>> from his generator to his furnace instead of trying to rig up his generator
>> with a suicide cord.
> 
> Now I'm wondering which jurisdiction you're talking about. I live in 
> California
> in a home which was finalized in 2019. As I'm the first owner, I was there 
> when
> the inspector went up into the attic and checked my HVAC. My HVAC has a plug 
> in
> power cord running into a regular household socket (all in the attic). The 
> inspector didn't say a word about it and issued the occupancy permit.
> 
> My electrically powered oven is hardwired, but I guess that's because it 
> requires
> two 50amp breakers?

It only sort of looks like two 50amp breakers… In reality, it’s a “ganged” 
breaker that is
50A on both sides of a 220V circuit so that if either side of the circuit 
exceeds 50A,
it will trip both breakers and shut down both sides.

A 220V circuit in the US (or 215/230/240, varies widely from utility to utility 
and for
other reasons) is both hot sides. The three wires coming into your house from 
the
utility are the two hots from opposite ends of the secondary winding in the 
utility
stepdown transformer along with a center-tapped “neutral”. The neutral is (or 
at least should be) tied to earth ground at exactly one place in your home 
(usually
inside the main breaker panel). The two “hot” sides each provide a 
110V(approximately)
AC source relative to the reference (0V Neutral and Ground), but they provide 
that
at a phase difference of 180º. This means that the potential between the two
hot lines is (nominally) 220VAC.

Owen

Re: The great Netflix vpn debacle!

[Owen DeLong via NANOG]

> On Aug 31, 2021, at 11:16 , Bryan Holloway  wrote:
> 
> So I've made some progress, but not on the HBO front. (Hulu and Netflix have 
> been responsive so far.)
> 
> Tried the e-mail address on Mike Hammett and Co.'s handy web-page, but got no 
> response after several days. Ironically we were able to get through to the 
> "closed-captioning" department, but this isn't particularly useful.
> 
> Does anyone have another possible contact for HBO folks to get some prefixes 
> unflagged as "VPN"?

Try insulting them on Facebook. I did that several years ago in regards to 
wanting to be able to purchase HBO on-line without having to subscribe to it 
through a cable operator and shortly after, they launched a service to do just 
that.

(No, I’m not convinced that my insulting them on facebook had a causal effect, 
but it’s at least an amusing thought).

> To be clear, this is not a geolocate issue. At least according to the error 
> our users are getting.

Geolocate and VPN or Not are often kind of tied to the same kinds of reporting 
services and it may well be that whatever provider HBO is using for one is also 
being used for the other.

Owen

Re: Operational need for IP address space (Re: An update on the AfriNIC situation)

[Owen DeLong via NANOG]

> On Aug 31, 2021, at 12:17 , John Curran  wrote:
> 
> On 31 Aug 2021, at 2:23 PM, Owen DeLong  > wrote:
>> 
>>> Do we have parties who postulate their operational need based on entirely 
>>> internal services, or services that live within virtual devices in a data 
>>> center?   Sure…  and some of these are indeed legitimate and fulfilled per 
>>> policy.  We also have folks who get creative and make similar requests for 
>>> purposes of obtaining address blocks from ARIN – absent any bona fide 
>>> networking need –for subsequent monetization and these reviewed, revoked, 
>>> and can be referred to criminal fraud proceedings.   
>> 
>> Yes, but in the ARIN region, you have also made it very clear that if needs 
>> change, ARIN will not attempt to revoke or reclaim space based on that 
>> change in need.
> 
> Owen - 
> 
> ARIN has full authority to revoke number resources based on breach of our 
> Registration Services Agreement (RSA) by a customer. We do exercise that 
> authority with significant caution, but will do so when the situation 
> warrants – and I would expect any other RIR to do the same in enforcing the 
> particular terms of their own RSA agreement. 

Agreed. Nonetheless, you have repeatedly stood in front of the community and 
stated that if the only violation of ARIN policy is insufficient utilization, 
ARIN will not take action against the organization to revoke or reclaim the 
resources.

> As I understand it, AFRINIC has initiated a rather small number of resource 
> reviews after completion of its most recent database audit – one might argue 
> that they should have initiated more/fewer/none-at-all, but one cannot 
> logically assert that AFRINIC lacks the right to enforce the plain language 
> of their RSA agreement when a review indicates that a breach of that 
> agreement has occurred. 

Depending on your definition of rather small. I hear it’s ≥ 1% of all resource 
holders so far and climbing.

> You also may not like that the AFRINIC RSA has recipients acknowledging that 
> they are 'bestowed with an exclusive right of use of those number resources 
> within the ambit of the “need” which it has justified in its application and 
> for no other purpose during the currency of the present agreement’,  but 
> please recognize that "your client” apparently liked that provision well 
> enough to agree to it in order to receive the address blocks – so there’s 
> really not much more to be said in this regard. 

Please also note that there is a provision further down in the agreement for 
dealing with modifications as they come up.

Whether my client did or did not comply with that provision is a matter for the 
courts at this point and I can’t comment on the exact nature of that particular 
issue as a result. However, I think there is adequate public information 
available to show that there is at least some legitimate dispute as to the 
facts of whether my client is is or is not in compliance with the RSA. I look 
forward to the courts decision on the matter as once that comes, I will be able 
to talk more freely regardless of the outcome.

Owen

Re: An update on the AfriNIC situation

[Owen DeLong via NANOG]

> On Aug 31, 2021, at 13:53 , Jon Lewis  wrote:
> 
> On Tue, 31 Aug 2021, Sabri Berisha wrote:
> 
>> - On Aug 31, 2021, at 8:40 AM, Jon Lewis jle...@lewis.org wrote:
>> 
>> Hi,
>> 
>> [ I'm not affiliated with CI in any way, just playing the Devil's Advocate ]
>> 
>>> "5.4.6.2 AFRINIC resources are for AFRINIC service region and any use
>>> outside the region should be solely in support of connectivity back to the
>>> AFRINIC region."
>> 
>>> AfriNIC's policy is not at all vague on the matter that their resources
>>> are to be used in or to support connectivity in the AFRINIC region.
>> 
>> In all fairness, that is as ambiguous as it can be. What constitutes "support
>> of connectivity back to the AfriNIC region"?
>> 
>> It's easy to argue that CI is in full compliance with that since their
>> assignment supports connectivity between users in Africa and their clients'
>> services. In that case, only IP space used outside of Africa not advertised
>> to the internet would be in violation.
> 
> I think any reasonable person would argue "in support of connectivity back to 
> the AFRINIC region." would cover things like providing IP addressing for a 
> network that extends into the AfriNIC region, and not to leasing IPs to 
> random orgs outside the AfriNIC region for use on networks that don't extend 
> into the AfriNIC region.
> 
> Regardless, I gather from other messages, the issue is CI claims this is a 
> misapplication of policy (or AfriNIC f'd up writing the CPM) and CI claims 
> 5.4.6.2 doesn't apply because their allocations pre-date AfriNIC being down 
> to their final /8.
> 
> It sure looks to me like this was a major oversight, as 5.4.6.2 doesn't 
> appear to have anything to do with soft landing, but is under the soft 
> landing section of the CPM (which says "This section describes how AFRINIC 
> shall assign...resources during the "Exhaustion Phase""

I was present for many of the debates over the soft landing policy. 5.4.6.2 is 
language that came from that policy proposal and was quite clearly and 
deliberately intended to be part of that policy and be applied once exhaustion 
phase 1 was activated. It is not an oversight and it is not an error that it is 
part of that policy.

One might argue that the lack of a more general policy regarding out of region 
use was an oversight once upon a time, but an effort was made by one community 
member to get such a policy adopted. There was much vocal opposition and the 
policy did not achieve consensus in the community. It was ultimately withdrawn 
by the author per the AFRINIC PDP.

Owen

Re: An update on the AfriNIC situation

[Owen DeLong via NANOG]

>> I regret the true human cost that Mark pointed out, yet I am fascinated
>> by the case and the arguments on both sides. The court will have their
>> work cut out for them.
> 
> That human cost came not from disagreement on the policies and
> contract provisions, but from a vengeful action of financial bullying.

Not to put too fine a point on this, but what human cost?

There were exactly 3 employees that AFRINIC wasn’t able to pay in July, 
including
the CEO (who is one of the major protagonists in creating this problem in the 
first
place). I don’t know who the other two were.

Everyone else got paid for July.

AFRINIC has received clearance of enough money to cover their normal expenses
for August and September. As such, there shouldn’t be any problems with salaries
or “human cost” in those months. Hopefully given that reprieve, cooler heads at
AFRINIC can prevail and some form of settlement can be achieved before they run
out of money from that reprieve.

> I saw my quota of questionable court decisions to automatically agree
> with whatever is decided in this case, even if CI loses, but the
> arguments from both sides will indeed be very interesting and useful
> to close out loopholes in the system.

Only if they are ever able to be made public, which is a little iffy given the 
Mauritian
court system. It may well be that only the final ruling is able to be made 
public.

Owen

Re: The great Netflix vpn debacle!

[Owen DeLong via NANOG]

You just broke 99% of the smart television sets in people’s homes, 
unfortunately.

That will resolve itself over time, of course, as sets are replaced, but anyone 
with
a set that is more than ~3 years old is mostly unlikely to have IPv6 support in 
it and
the vendors are ALL universally terrible about updating firmware.

As much as I like the idea (and that if a sufficient number of providers were 
willing
to do so, it might just serve as a forcing function to get firmware updates 
done),
I wouldn’t hold my breath and I suspect where there are competitive 
alternatives,
such a notice would be a boon to the competition.

Owen


> On Aug 31, 2021, at 15:15 , Mark Andrews  wrote:
> 
> Force the traffic to these companies to use IPv6.  Advise your customers that
> you are doing this, why you are doing this and what steps they need to take
> to enable IPv6 on their equipment. Your customers can’t be in a worse 
> position.
> 
> "Dear customer,
>  if you want to reach … you will need to enable IPv6 support in
> your home network.  The world ran out of enough IPv4 for everyone several 
> years
> back and we have been sharing IPv4 between customers to allow you to reach 
> IPv4
> only sites.  The afore mentioned companies are now blocking IPv4 connections 
> from
> ISPs that have to share IPv4 addresses.  To give you a better service we are
> blocking IPv4 connections to these companies so you will get a more reliable 
> service
> over IPv6.
> 
> For instructions on how to enable IPv6 connectivity on you home router see 
> this
> page ….
> 
> If your home router does not support IPv6 you will need to upgrade it to one 
> that does."
> 
>> On 1 Sep 2021, at 06:36, Bryan Holloway  wrote:
>> 
>> Thanks, Owen ... good point.
>> 
>> Now hearing reports for these same prefixes with Disney+ too.
>> 
>> So the common denominators are:
>> 
>> HBO
>> Hulu
>> Netflix
>> Amazon Prime
>> Disney+
>> 
>> ... there has _got_ to be some new-fangled DB somewhere. This all started in 
>> the last month or so.
>> 
>> All of our RR objects, whois, DNS is solid ... dehr?
>> 
>> Fun times.
>> 
>> 
>> On 8/31/21 9:16 PM, Owen DeLong wrote:
>> 
>> [snip]
>> 
>>> Geolocate and VPN or Not are often kind of tied to the same kinds of 
>>> reporting services and it may well be that whatever provider HBO is using 
>>> for one is also being used for the other.
>>> Owen
> 
> -- 
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org
> 

Re: The great Netflix vpn debacle! (geofeeds)

[Owen DeLong via NANOG]

> On Aug 31, 2021, at 16:32 , Jeroen Massar  wrote:
> 
> On 2021-09-01 01:13, Owen DeLong via NANOG wrote:
>> You just broke 99% of the smart television sets in people’s homes, 
>> unfortunately.
> 
> If only everybody would not get a separate box, be that a AppleTV, a 
> Playstation, a XBox, Chromecast, ... or many other options.
> 
> Fun part being that it is hard to get a Dumb TV... though that is primarily 
> simply because of all the tracking non-sense in them that makes them 
> 'cheaper'... (still wonder how well that tracking stuff complies with GDPR, I 
> am thinking it does not ... Schrems anyone? :) )

Interestingly, no, it’s easy to get a “dumb TV” these days… We just call them 
“monitors”. I have two of them (one on either side) of my iMAC as I write this. 
(Makes for great X-Plane flying visuals.

On the other hand, the last time I went looking for a 27” monitor, I ended up 
buying a 44” smart television because it was a cheaper HDMI 4K monitor than the 
27” alternatives that weren’t televisions. (It also ended up being cheaper than 
the 27” televisions which didn’t do 4K only 1080p, but I digress).

> 
>> That will resolve itself over time, of course, as sets are replaced, but 
>> anyone with
>> a set that is more than ~3 years old is mostly unlikely to have IPv6 support 
>> in it and
>> the vendors are ALL universally terrible about updating firmware.
> 
> Quite a bit of Android TV out there too and we all know how well that 
> supports DHCPv6... ;)

Does DHCPv6 really matter in a home? Really? I mean, I understand the NAC 
argument in the
corporate LAN environment, but the average household user can’t even spell NAC, 
let alone
implement an 802.1X stack.

> Btw, geofeeds are getting fetched by some entities.

I presume geofeeds are getting fetched by many entities, but I’m not sure what 
the point of that is.

> I've seen at least Dataprovider.com and DB-IP, others that fetch the CSV 
> don't bother to set UA to something unique, thus one sees curl + axios coming 
> by for instance, which does not tell much; but apparently we have to give up 
> on UAs anyway, even though they are great for things like bots where one can 
> have a wee bit of contact details in the line.

Yeah, Safari can now be trained to lie about it’s UA in developer mode easily. 
I presume this is true in Crome, Firefox, and just about anything else as well. 
It’s behind the drop-down panel to keep the adults out of the VCR, but it’s 
easily visible to any kid that would know how to program a VCR.


> For instance DB-IP does regular updates of their code (r) and fetches 
> quite often:
> 
> 2a00:18a8:6:40:dcad:beff:feef:100 - - [23/Aug/2021:09:32:09 +] "GET 
> /geofeed.csv HTTP/1.0" 200 827 "-" "db-ip geofeed updater r6499"
> 2a00:18a8:6:40:dcad:beff:feef:100 - - [23/Aug/2021:09:02:14 +] "GET 
> /geofeed.csv HTTP/1.0" 200 827 "-" "db-ip geofeed updater r6499"
> 2a00:18a8:6:40:dcad:beff:feef:100 - - [24/Aug/2021:09:11:11 +] "GET 
> /geofeed.csv HTTP/1.0" 200 827 "-" "db-ip geofeed updater r6500"
> 2a00:18a8:6:40:dcad:beff:feef:100 - - [24/Aug/2021:09:42:15 +] "GET 
> /geofeed.csv HTTP/1.0" 200 827 "-" "db-ip geofeed updater r6500"
> 2a00:18a8:6:40:dcad:beff:feef:100 - - [24/Aug/2021:21:59:46 +] "GET 
> /geofeed.csv HTTP/1.0" 200 827 "-" "db-ip geofeed updater r6501"
> 2a00:18a8:6:40:dcad:beff:feef:100 - - [25/Aug/2021:01:24:28 +] "GET 
> /geofeed.csv HTTP/1.0" 200 827 "-" "db-ip geofeed updater r6501"
> 2a00:18a8:6:40:dcad:beff:feef:100 - - [25/Aug/2021:04:43:01 +] "GET 
> /geofeed.csv HTTP/1.0" 200 827 "-" "db-ip geofeed updater r6501"
> 2a00:18a8:6:40:dcad:beff:feef:100 - - [25/Aug/2021:05:11:05 +] "GET 
> /geofeed.csv HTTP/1.0" 200 827 "-" "db-ip geofeed updater r6501"
> 2a00:18a8:6:40:dcad:beff:feef:100 - - [26/Aug/2021:05:23:18 +] "GET 
> /geofeed.csv HTTP/1.0" 200 827 "-" "db-ip geofeed updater r6502"
> 2a00:18a8:6:40:dcad:beff:feef:100 - - [26/Aug/2021:02:49:59 +] "GET 
> /geofeed.csv HTTP/1.0" 200 827 "-" "db-ip geofeed updater r6502"
> 2a00:18a8:6:40:dcad:beff:feef:100 - - [27/Aug/2021:03:22:23 +] "GET 
> /geofeed.csv HTTP/1.0" 200 827 "-" "db-ip geofeed updater r6504"
> 2a00:18a8:6:40:dcad:beff:feef:100 - - [27/Aug/2021:03:55:04 +] "GET 
> /geofeed.csv HTTP/1.0" 200 827 "-" "db-ip geofeed updater r6504"
> 2a00:18a8:6:40:dcad:beff:feef:100 - - [28/Aug/2021:03:21:26 +] "GET 
> /geofe

Re: The great Netflix vpn debacle! (geofeeds)

[Owen DeLong via NANOG]

> On Aug 31, 2021, at 17:51 , Michael Thomas  wrote:
> 
> 
> On 8/31/21 5:13 PM, Jay Hennigan wrote:
>> On 8/31/21 16:32, Jeroen Massar via NANOG wrote:
>> 
>>> Fun part being that it is hard to get a Dumb TV... though that is primarily 
>>> simply because of all the tracking non-sense in them that makes them 
>>> 'cheaper'... (still wonder how well that tracking stuff complies with GDPR, 
>>> I am thinking it does not ... Schrems anyone? :) )
>> 
>> Just get a "smart" TV, don't connect it to the Internet, and use its HDMI 
>> ports for your cable box, Apple TV, etc. and/or antenna input for local 
>> off-air reception.
>> 
> 
> Yeah, until TV manufacturers actually start incorporating, oh say, Google tv 
> (which is just a form of Android) they are always going to be inferior. 
> Having the TV just be a monitor is a feature, not a bug. It's a lot cheaper 
> to upgrade a $50 hdmi based dongle than the whole TV, doubly so since 
> manufacturers have a bad reputation  for not supporting upgrades beyond the 
> sell date. I have no idea whether any of the external ones support v6 though.

Apple TV supports IPv6, but does not allow the user to set a static IPv6 
address and it uses rotating privacy addresses, so the security implications 
are “interesting”. OTOH, it does appear to support DHCPv6 and if you set M+O, 
it looks like you can collect the DUID and give it a fixed DHCP address.

Android and by extension Google’s HDMI dongles/devices have some IPv6 support, 
but of course don’t work with DHCPv6 because of Lorenzo’s religious problems.

> One thing that might be nice is for routers to internally number using v6 in 
> preference to v4 and NAT that (if needed). Then you can easily tell what is 
> still a laggard. My wifi cams might be poorly supported, but they don't need 
> to interoperate with much on the Internet.

I actually have had an idea for a long time of producing a router-on-a-stick 
kind of device which would be a small linux SBC with two ethernet ports and 
some LEDs.

The OS would go on a micro-SD card and it would literally be a single-device 
NAT64 setup so that the IPv4-only device on the downstream side could work with 
the IPv6-only LAN (which might further have a NAT64 gateway to deal with the 
IPv4-only legacy portions of the world outside.

Ideally, the upstream ethernet port would be PoE to power the device (and the 
device would be sold with a small, cheap PoE injector in case needed).

> Mike, Google TV has been pretty nice since the Amazon feud finally ended 
> though I hate that the protocol is still pretty proprietary

To the best of my knowledge, the FireTV and its ilk still can’t spell IPv6.

Owen

Re: The great Netflix vpn debacle! (geofeeds)

[Owen DeLong via NANOG]

> On Aug 31, 2021, at 18:01 , Michael Thomas  wrote:
> 
> 
> On 8/31/21 4:40 PM, Owen DeLong via NANOG wrote:
>> On the other hand, the last time I went looking for a 27” monitor, I ended 
>> up buying a 44” smart television because it was a cheaper HDMI 4K monitor 
>> than the 27” alternatives that weren’t televisions. (It also ended up being 
>> cheaper than the 27” televisions which didn’t do 4K only 1080p, but I 
>> digress).
> 
> Back when 4k just came out and they were really expensive, I found a "TV" by 
> an obscure brand called Seiki which was super cheap. It was a 39" model. It's 
> just a monitor to me, but I have gotten really used to its size and not 
> needing two different monitors (and the gfx card to support it). What's 
> distressing is that I was looking at what would happen if I needed to replace 
> it and there is this gigantic gap where there are 30" monitors (= expensive) 
> and 50" TV's which are relatively cheap. The problem is that 40" is sort of 
> Goldielocks with 4k where 50" is way too big and 30" is too small. Thankfully 
> it's going on 10 years old and still working fine.

Costco stocks several 44” 4K TV models (like the one I got) that are relatively 
cheap. It’s a little larger than your 40” goldilocks, but I think still within 
range.

Owen

Re: An update on the AfriNIC situation

[Owen DeLong via NANOG]

> On Sep 1, 2021, at 04:21 , Tom Beecher  wrote:
> 
> AFRINIC has received clearance of enough money to cover their normal expenses
> for August and September. As such, there shouldn’t be any problems with 
> salaries
> or “human cost” in those months. Hopefully given that reprieve, cooler heads 
> at
> AFRINIC can prevail and some form of settlement can be achieved before they 
> run
> out of money from that reprieve.
> 
> It's good that people are still being paid.
> 
> That being said, while some may have the opinion that AFRINIC's actions have 
> been 'objectionable' , others have the opinion that their actions were 
> justified and proper. Does it not concern you at all that AFRINIC may be 
> forced into a 'settlement' because they cannot access their funds due to a 
> very dubious claim of damages? 

I don’t think AFRINIC is being forced into anything. They attacked a member on 
the basis of violations of rules that don’t actually exist. The company 
retaliated by obtaining an injunction. AFRINIC managed to get the injunction 
temporarily lifted on a technicality (largely of AFRINIC’s making) and took an 
opportunity to make an existential attack on the member during that brief 
window of opportunity. AFRINIC then deliberately dragged their feet on 
complying with a court order restoring the injunction.

As such, no, I’m really not concerned about AFRINIC’s ability to avoid settling 
and I utterly reject the idea that the claim of damages is at all dubious.

> There are enough challenges with the internet in Africa to work through 
> already. We shouldn't encourage more difficulties by endorsing strongarm 
> tactics that prevent issues from being properly adjudicated in courts.

Agreed. Please review the recent conduct of the AFRINIC board in detail in this 
context.

Owen

> 
> On Tue, Aug 31, 2021 at 6:59 PM Owen DeLong via NANOG  <mailto:nanog@nanog.org>> wrote:
> >> I regret the true human cost that Mark pointed out, yet I am fascinated
> >> by the case and the arguments on both sides. The court will have their
> >> work cut out for them.
> > 
> > That human cost came not from disagreement on the policies and
> > contract provisions, but from a vengeful action of financial bullying.
> 
> Not to put too fine a point on this, but what human cost?
> 
> There were exactly 3 employees that AFRINIC wasn’t able to pay in July, 
> including
> the CEO (who is one of the major protagonists in creating this problem in the 
> first
> place). I don’t know who the other two were.
> 
> Everyone else got paid for July.
> 
> AFRINIC has received clearance of enough money to cover their normal expenses
> for August and September. As such, there shouldn’t be any problems with 
> salaries
> or “human cost” in those months. Hopefully given that reprieve, cooler heads 
> at
> AFRINIC can prevail and some form of settlement can be achieved before they 
> run
> out of money from that reprieve.
> 
> > I saw my quota of questionable court decisions to automatically agree
> > with whatever is decided in this case, even if CI loses, but the
> > arguments from both sides will indeed be very interesting and useful
> > to close out loopholes in the system.
> 
> Only if they are ever able to be made public, which is a little iffy given 
> the Mauritian
> court system. It may well be that only the final ruling is able to be made 
> public.
> 
> Owen
> 

Re: An update on the AfriNIC situation

[Owen DeLong via NANOG]

> On Sep 1, 2021, at 04:48 , Mark Tinka  wrote:
> 
> 
> 
> On 9/1/21 00:56, Owen DeLong via NANOG wrote:
> 
>> Not to put too fine a point on this, but what human cost?
>> 
>> There were exactly 3 employees that AFRINIC wasn’t able to pay in July, 
>> including
>> the CEO (who is one of the major protagonists in creating this problem in 
>> the first
>> place). I don’t know who the other two were.
>> 
>> Everyone else got paid for July.
>> 
>> AFRINIC has received clearance of enough money to cover their normal expenses
>> for August and September. As such, there shouldn’t be any problems with 
>> salaries
>> or “human cost” in those months. Hopefully given that reprieve, cooler heads 
>> at
>> AFRINIC can prevail and some form of settlement can be achieved before they 
>> run
>> out of money from that reprieve.
> 
> This is rich!
> 
> Of course, one should expect people to be mentally settled and do good work 
> when they have no security or clarity about whether they will get paid at the 
> end of each month.
> 
> These aren't robots, mate. People have real thoughts and real feelings.
> 
> Stress is not intangible... it releases cortisol, which delivers a number of 
> physiological side effects that work against good health. Financial 
> insecurity is just about the worst stress anyone has to deal with.
> 
> None of us would sleep well if we knew that our source of income is not 
> guaranteed, despite what some may say about "As such, there shouldn't be any 
> problems with salaries..."
> 
> Mark.

Well… I don’t see you calling out the stress and cortisol actions for the 
various staff and customers of Cloud Innovation or Larus in your postings when 
AFRINIC first issued an existential threat to their business based on made-up 
policies that don’t actually exist.

As such, I’d argue that AFRINIC attacked a much larger population first. The 
fact that (at least so far), AFRINIC’s attacks have been less successful than 
Cloud Innovation’s counter-attacks doesn’t change the fact that if you want to 
call it out that way, there’s a greater human cost on the other side.

Owen

Re: The great Netflix vpn debacle! (geofeeds)

[Owen DeLong via NANOG]

Where possible vote with your dollars by selecting providers that do.

Where there are multiple providers and none support v6, make it clear to all 
that the first one to support
v6 will get your business and that subsequently, the best v6 support will win.

Where there are not multiple providers, lobby your regulators to eliminate 
vertical integration (stop allowing
those that own the natural monopoly in layer 1 to leverage that into a monopoly 
over higher layer services).

Owen


> On Sep 1, 2021, at 10:59 , Nimrod Levy  wrote:
> 
> All this chatter about IPv6 support on devices is fun and all, but there are 
> providers still not on board. 
> They operate in my neighborhood and they know who they are...
> 
> Nimrod
> 
> 

Re: The great Netflix vpn debacle! (geofeeds)

[Owen DeLong via NANOG]

> On Sep 1, 2021, at 11:25 , b...@theworld.com wrote:
> 
> 
> Every time I've read a thread about using TVs for monitors several
> people who'd tried would say don't do it. I think the gist was that
> the image processors in the TVs would fuzz text or something like
> that. That it was usable but they were unhappy with their attempts, it
> was tiring on the eyes.

That was definitely true of 480 TVs and older 1080p units, but modern sets
are almost designed to be monitors first and everything else second.

> Maybe that's changed or maybe people happy with this don't do a lot of
> text? Or maybe there are settings involved they weren't aware of, or
> some TVs (other than superficial specs like 4K vs 720p) are better for
> this than others so some will say they're happy and others not so
> much?

There are some tradeoffs… For example, sitting normal computer monitor
distance from a 44” 4K screen, you can damn near see the individual pixels
and that can make text look fuzzy, especially if your GPU or OS are stupid
enough to use a technique called anti-aliasing on text (which is the most
probable source of the fuzziness in your originally quoted complaint).

Older TVs would try to smooth some aspects of the analog signal they were
using through anti-aliasing pixels that occurred on the edge of a change in
the color signal to “smooth” the image. (The extent of this action was what
was controlled by the “Sharpness” knob back in the analog days).

Turning off this capability (Sharpness to the left most or lowest setting) would
often improve things greatly.

> Or maybe the unhappy ones were all trolls/sockpuppets from companies
> manufacturing/selling $500+ 24" **GAMING** monitors.

Possible, but unlikely.

Owen

> 
> On September 1, 2021 at 09:48 nanog@nanog.org (Owen DeLong via NANOG) wrote:
>> 
>> 
>>> On Aug 31, 2021, at 18:01 , Michael Thomas  wrote:
>>> 
>>> 
>>> On 8/31/21 4:40 PM, Owen DeLong via NANOG wrote:
>>>> On the other hand, the last time I went looking for a 27” monitor, I ended 
>>>> up buying a 44” smart television because it was a cheaper HDMI 4K monitor 
>>>> than the 27” alternatives that weren’t televisions. (It also ended up 
>>>> being cheaper than the 27” televisions which didn’t do 4K only 1080p, but 
>>>> I digress).
>>> 
>>> Back when 4k just came out and they were really expensive, I found a "TV" 
>>> by an obscure brand called Seiki which was super cheap. It was a 39" model. 
>>> It's just a monitor to me, but I have gotten really used to its size and 
>>> not needing two different monitors (and the gfx card to support it). What's 
>>> distressing is that I was looking at what would happen if I needed to 
>>> replace it and there is this gigantic gap where there are 30" monitors (= 
>>> expensive) and 50" TV's which are relatively cheap. The problem is that 40" 
>>> is sort of Goldielocks with 4k where 50" is way too big and 30" is too 
>>> small. Thankfully it's going on 10 years old and still working fine.
>> 
>> Costco stocks several 44” 4K TV models (like the one I got) that are 
>> relatively cheap. It’s a little larger than your 40” goldilocks, but I think 
>> still within range.
>> 
>> Owen
>> 
> 
> -- 
>-Barry Shein
> 
> Software Tool & Die| b...@theworld.com | 
> http://www.TheWorld.com
> Purveyors to the Trade | Voice: +1 617-STD-WRLD   | 800-THE-WRLD
> The World: Since 1989  | A Public Information Utility | *oo*

Re: An update on the AfriNIC situation

[Owen DeLong via NANOG]

> On Sep 1, 2021, at 13:30 , Tom Beecher  wrote:
> 
>  They attacked a member on the basis of violations of rules that don’t 
> actually exist.
> 
> You continually refer to AFRINIC's actions as an 'attack'. However, that 
> would seem to be an open question of law , which AFRINIC cannot litigate 
> because they're have no access to their money. 

Apparently this isn’t an issue for them as they are, in fact, litigating it and 
have managed to hire the most expensive law firm in Mauritius to do so.

Until they went looking for other excuses, their attack was based primarily on 
accusations that out of region use was not permitted.

All of the resources in question were issued prior to activation of the Soft 
Landing (5.4) policy, so 5.4.6.2 does not apply.

If you can find some other place in the CPM that prohibits such, then by all 
means, let me know. If you cannot, then I think the openness of that question 
is rather limited.

Owen

> 
> On Wed, Sep 1, 2021 at 3:40 PM Owen DeLong  <mailto:o...@delong.com>> wrote:
> 
> 
>> On Sep 1, 2021, at 04:21 , Tom Beecher > <mailto:beec...@beecher.cc>> wrote:
>> 
>> AFRINIC has received clearance of enough money to cover their normal expenses
>> for August and September. As such, there shouldn’t be any problems with 
>> salaries
>> or “human cost” in those months. Hopefully given that reprieve, cooler heads 
>> at
>> AFRINIC can prevail and some form of settlement can be achieved before they 
>> run
>> out of money from that reprieve.
>> 
>> It's good that people are still being paid.
>> 
>> That being said, while some may have the opinion that AFRINIC's actions have 
>> been 'objectionable' , others have the opinion that their actions were 
>> justified and proper. Does it not concern you at all that AFRINIC may be 
>> forced into a 'settlement' because they cannot access their funds due to a 
>> very dubious claim of damages? 
> 
> I don’t think AFRINIC is being forced into anything. They attacked a member 
> on the basis of violations of rules that don’t actually exist. The company 
> retaliated by obtaining an injunction. AFRINIC managed to get the injunction 
> temporarily lifted on a technicality (largely of AFRINIC’s making) and took 
> an opportunity to make an existential attack on the member during that brief 
> window of opportunity. AFRINIC then deliberately dragged their feet on 
> complying with a court order restoring the injunction.
> 
> As such, no, I’m really not concerned about AFRINIC’s ability to avoid 
> settling and I utterly reject the idea that the claim of damages is at all 
> dubious.
> 
>> There are enough challenges with the internet in Africa to work through 
>> already. We shouldn't encourage more difficulties by endorsing strongarm 
>> tactics that prevent issues from being properly adjudicated in courts.
> 
> Agreed. Please review the recent conduct of the AFRINIC board in detail in 
> this context.
> 
> Owen
> 
>> 
>> On Tue, Aug 31, 2021 at 6:59 PM Owen DeLong via NANOG > <mailto:nanog@nanog.org>> wrote:
>> >> I regret the true human cost that Mark pointed out, yet I am fascinated
>> >> by the case and the arguments on both sides. The court will have their
>> >> work cut out for them.
>> > 
>> > That human cost came not from disagreement on the policies and
>> > contract provisions, but from a vengeful action of financial bullying.
>> 
>> Not to put too fine a point on this, but what human cost?
>> 
>> There were exactly 3 employees that AFRINIC wasn’t able to pay in July, 
>> including
>> the CEO (who is one of the major protagonists in creating this problem in 
>> the first
>> place). I don’t know who the other two were.
>> 
>> Everyone else got paid for July.
>> 
>> AFRINIC has received clearance of enough money to cover their normal expenses
>> for August and September. As such, there shouldn’t be any problems with 
>> salaries
>> or “human cost” in those months. Hopefully given that reprieve, cooler heads 
>> at
>> AFRINIC can prevail and some form of settlement can be achieved before they 
>> run
>> out of money from that reprieve.
>> 
>> > I saw my quota of questionable court decisions to automatically agree
>> > with whatever is decided in this case, even if CI loses, but the
>> > arguments from both sides will indeed be very interesting and useful
>> > to close out loopholes in the system.
>> 
>> Only if they are ever able to be made public, which is a little iffy given 
>> the Mauritian
>> court system. It may well be that only the final ruling is able to be made 
>> public.
>> 
>> Owen
>> 
> 

Re: The great Netflix vpn debacle! (geofeeds)

[Owen DeLong via NANOG]

> On Sep 1, 2021, at 15:17 , Warren Kumari  wrote:
> 
> 
> 
> On Wed, Sep 1, 2021 at 2:28 PM mailto:b...@theworld.com>> 
> wrote:
> 
> Every time I've read a thread about using TVs for monitors several
> people who'd tried would say don't do it.
> 
> And everytime I see an email thread about the difference or not between 
> monitors and TVs I'm taken over by an all consuming rage...
> I have a **monitor** I purchased it from Dell, and it clearly said 
> "monitor" on the box, it identifies itself somewhere display settings as a 
> "monitor", and even says "monitor" in small letters somewhere on the back 
> It's a MONITOR dagnabit... but, for some unfathomable reason it has some tiny 
> little speakers in it, and every time I connect it via HDMI to my Mac laptop, 
> the machine decides to completely ignore the fact that I've told it that I 
> want to use a specific sound output, and starts playing all audio though the 
> monitors speakers. Oh, and because this is HDMI, and Apple apparently follows 
> the HDMI spec, the Mac volume controls won't work ("This device has no audio 
> level control" or something...) and I have to go scrummaging around in some 
> horrendous on-screen monitor menu to make it less obnoxiously loud...

Yes, it’s not clear why Apple doesn’t implement more of the HDMI spec and send 
it CEC commands to control the volume when it’s connected to an HDMI device 
with sound output.

Interestingly, my Apple TV does implement that part of the spec and my Amp that 
it is connected to dutifully obeys and everything works as expected… Display on 
the monitor (TV if you prefer), sound from the 7.1 speakers through the amp as 
expected, and control of the playback through the Apple TV all from the single 
elegant Apple TV Remote. So clearly, Apple has mastered the skills necessary to 
make this possible. Why they don’t bring them to MacOS yet remains a mystery to 
me.

> All attempts to get this less stupid result in Apple pointing at the HDMI 
> spec and saying that if a device advertises audio capabilites they list it as 
> an output device, and Dell pointing out that they simply advirtise the fact 
> that the device has a speaker, and, well, shrug, not thier issue if things 
> try and use it.

Listing it as an output device doesn’t require them to auto switch to that 
output device upon connection… You might want to point out to Apple that an 
ability to override this less than desirable behavior would be sufficient to 
cure your issue without violating the HDMI spec.

It pains me to say this, but Dell is right. The HDMI spec doesn’t allow for 
them to have a (useful) implementation of a speaker (or speakers) in an HDMI 
monitor that can some how say “I have a speaker, but don’t use it unless the 
user specifically tells you to.”. OTOH, Dell could (and I’ve seen monitors and 
even televisions that do) add a user control to “Disable HDMI audio 
negotiations” or something to that effect.

> There used to be a good webpage that had some instructions along the lines of:
> Step 1: Open 
> /System/Library/Extensions/AMDRadeonX6000HWServices.kext/Contents/PlugIns/AMDRadeonX6300HWLibs.kext
>  in a hex editor
> Step 2: Change the byte at offset 931 to 0xED, offset 12323 to 0xFD, offset 
> 94 to 0x00 and offset 42 to 0x03. 
> Step 3: ???
> Step 4: The HDMI capabilities parser no longer understands the audio 
> capability message, and so the Mac will never try to use HDMI audio ever 
> again well, until you upgrade... oh, this is perfectly safe, trust us, 
> nothing could possibly go wrong here...
> 
> Unfortunately this was only for a specific version of a specific kext on a 
> specific model of Macbook, but it did work... 

I suppose, if you’re willing to never have the ability to use HDMI Audio Output 
from your laptop (which wouldn’t work well for me).

I will say that it’s annoying to have to do it each time you connect to the 
monitor, but it is relatively trivial to change the audio output back after the 
monitor and laptop finish their whole HDMI negotiation and the various auto 
switches have finished screwing up your system settings.

System Preferences->Audio->Output — Select the output you want instead of the 
HDMI monitor.

> All I want is to be able to reliably inform my computer that the thingie on 
> my desk is "just" a monitor and not a TV/HiFi system/similar... is that too 
> much to ask!?!!?!!?!??!! 

I’m reminded of a certain advertising slogan…
“Dude! You got [stuck with] a Dell.”

> (Actually, this used to annoy me enough that I purchased one of bunnie 
> Huang's NeTV (https://www.bunniestudios.com/blog/?cat=17 
> ) devices, which allows taking in 
> HDMI, munging it and sending it out (e.g to do text overlays). My plan was to 
> repurpose it as a straight data passthrough, but overriding the HDMI profile 
> info, but as with most of these sorts of projects I got sidetracked into 
> playing with the build environment in

Re: IPv6 woes - RFC

[Owen DeLong via NANOG]

> On Sep 6, 2021, at 12:27 AM, Saku Ytti  wrote:
> 
> On Mon, 6 Sept 2021 at 10:20, Bjørn Mork  wrote:
> 
>> Adding new access infrastructure of any sort (Fixed Wireless is the
>> hype...)?  Why would you want to continue being stupid even if you
>> implemented dual-stack for all your fibre, hfc and dsl customers?  You
>> can save a lot by dropping dual-stack complexities in PGWs and FWA CPEs,
>> even if we assume most of the fibre/hfc/dsl value chain is reused.
> 
> Can you? You need to offer IPv4 anyhow and all the complexities
> related to that, i.e. some stateful box. Why would I offer in addition
> to that IPv6, which is not being requested by anyone. And by anyone I
> mean anyone I want as customer, as those who request it, are probably
> going to be expensive to support and I need to subsidise those with my
> regular customers, so I'd rather not cater to those.

You don’t necessarily have to carry IPv4 across your network with all the
complexities involved in that. You can do IPv4 at the edges with all IPv6
in the middle through a variety of techniques which are relatively trivial
to implement these days.

Hopefully this idea that “you need to do IPv4 anyhow” will die some day soon.

Unfortunately, nobody wants to lead because it comes with certain negative
commercial implications. Perverse incentives remain a problem.

The race is on:

Will we get IPv6 deployed before our similar failures with regard
to climate change (for amusingly similar perverse incentive reasons)
render the planet uninhabitable?

Owen

Re: IPv6 woes - RFC

[Owen DeLong via NANOG]

> On Sep 6, 2021, at 3:55 PM, Matt Palmer  wrote:
> 
> On Mon, Sep 06, 2021 at 08:38:44AM +0200, Xavier Beaudouin via NANOG wrote:
>> Hello,
>> 
>> 
>>> I absolutely HATE testing, developing and supporting IPv4+IPv6, more
>>> than doubling my time, adding 3rd stack would actually not increase
>>> cost that much, it's the 1=>2 which is fantastically expensive. And
>>> costs are transferred to customers.
>> 
>> Dual stack is doubling dev time ? Ok... this is quite strange...
> 
> Nope, entirely normal and expected.  Coding for one case is very
> straightforward:
> 
> Do thing
> Do other thing
> Do this as well
> 
> Coding for two cases involves identifying each step which needs to be done
> differently for the two cases and coding up the things to be done
> differently:
> 
> if case1:
>  Do thing this way
> elif case2:
>  Do same thing this other way
> Do other thing the same way regardless
> if case1:
>  Do this as well
> elif case2:
>  Don't do anything

Sure, but most of this can be obviated with IPV6_V6ONLY=false.

From that point on, your software doesn’t need to know or care whether the 
connection is IPv4 or IPv6, everything looks like IPv6.

Owen

Re: if not v6, what?

[Owen DeLong via NANOG]

> On Sep 7, 2021, at 19:51 , Masataka Ohta  
> wrote:
> 
> Niels Bakker wrote:
> 
>>> As for well known port, we can specify non-default port numbers
>>> in URLs (I'm not sure whether it works for mailto: or not) or.
>>> in the future, things like DNS SRV RRs should be helpful.
>> This absolutely doesn't work.
> 
> Thank you very much for your emotional and unfounded
> comment.

It’s neither. There’s no support for SRV RRs in virtually any of the software
that would need it in order for this to be a viable solution and it does not 
appear
to be coming any time soon.

That’s a fact. Not unfounded and not emotional.

You, yourself admit that mailto: URLs don’t have space for a port number (though
you express uncertainty, I assure you that they don’t).


>> And DNS SRV RRs have roughly zero uptake for stuff that matters (web, email).
> 
> I know SRV and other similar proposals so far are not
> very compatible with URL syntax and should better be
> simplified.

I think the bigger problem is that SRV just hasn’t really caught on and I 
suspect isn’t
likely to.

In reality, the effort to modify all the code to support SRV wouldn’t be 
significantly less
than what is required to do IPv6 which would (mostly) obviate the need for SRV 
as
service-specific IP addresses would be easy to assign. The significant problem 
here,
no matter how many different ways we attempt to hack around it is address 
shortage.
The solution to that is more addresses (i.e. IPv6).

>>> Then, to run servers at home, we only need some not-well-known
>>> ports forwarded, which can be default or value added service of
>>> your local ISP, just like fixed IP addresses today.
> 
>> Oh and we need to work around the whole IP reputation system that governs 
>> email today.
> IP reputation system must evolve to be IP+port reputation
> system, which is not my problem.

ROFLMAO — as if that’s at all likely to happen.

Further, you have the problem that the port side where this matters is ephemeral
meaning that multiple systems (which need different reputations) share the same
source address+port combination, so it doesn’t really help.

No, IP reputation system must evolve to support 128 bit addresses and some level
of heuristic determination of how many of those 128 bits should be applied to a 
given
reputation (probably defaulting to 64 and working left from there).

Owen

Re: IPv6 woes - RFC

[Owen DeLong via NANOG]

> On Sep 7, 2021, at 23:50 , Saku Ytti  wrote:
> 
> On Tue, 7 Sept 2021 at 19:51, Owen DeLong  wrote:
> 
>> Hopefully this idea that “you need to do IPv4 anyhow” will die some day soon.
> 
> Fully agreed, I just don't see the driver. But I can imagine a

$$

IPv4 continues to increase in cost. Surely, there is a point where organizations
start to cry uncle.

Surely there is a point where we move from but you have to do IPv4 anyhow
to but you have to do IPv6 to support most new things because newcomers
don’t want to pay $150/address to get on the legacy network.

(Yeah, I know it’s only $50 today, but it was $10 a few years ago and $30
last year).

> different timeline where in 2000 several tier1 signed mutual binding
> contracts to drop IPv4 at the edge in 2020. And no one opposed,

That would have been nice, but that opportunity was missed. I’m thinking that
the most hope for this to happen realistically is for eyeball providers to start
charging extra to provide IPv4AAS to their customers that need it. I think
an announcement from one or two of the major ones would serve as an
extreme motivation for the lagging content providers (Are you listening here
Amazon? Skype? Google Cloud? AWS? (global load balancing)) to get their
shit together. Once they do, there’s really not much “you have to support
IPv4 anyway” left, then the eyeballs can shut it off for customers that don’t
pay extra and voila… Little incentive remains to continue maintaining
IPv4 infrastructure.

> because 20 years before was 1980, and 20 years in the future IPv4
> wont' anymore be a thing, it's clear due to exponential growth.
> 
> And we'd all be enjoying a much simplified stack and lower costs all
> around (vendor, us, customers).

Yep.

> Why is this not possible now? Why would we not sign this mutual
> agreement for 2040? Otherwise we'll be having this same discussion in
> 2040.

Because markets (and people) are bad at transition and we live in a world of 
markets
and perverse incentives. It’s part of the reason climate change is so hard to 
address
also.

Owen

Re: IPv6 woes - RFC

[Owen DeLong via NANOG]

> On Sep 8, 2021, at 00:49 , Mark Tinka  wrote:
> 
> 
> 
> On 9/8/21 09:40, Etienne-Victor Depasquale wrote:
> 
>> Membership fees can be painful, that's for sure.
>> They do have positive aspects, though :)
> 
> I encourage other operators (especially the "major" ones - but really, 
> everyone) to seriously consider supporting this idea, and begin to circulate, 
> within your organizations, whether you can receive purchase for this 
> initiative internally, so we put this discussion about IPv6 to bed, in the 
> next 10 years.
> 
> Just a simple piece of feedback about basic support back to this list would 
> help kick things off, I feel.
> 
> Mark.

I think the tipping point would be to get the major eyeball providers on board. 
If you can get them to agree (even if they just agree to surcharge IPv4 support 
by that time or even in 5 years), that will serve as a really strong forcing 
function for the content providers.

Comcast is well positioned to be able to do this, many of their customers have 
no viable alternative anyway, so not like they lose business almost no matter 
what they do. (They’ve proven this repeatedly). They’ve also already got full 
or nearly full IPv6 enablement for all of their customers (albeit it with 
ridiculously small prefixes for most of them).

The reality is that if we get content dual-stacked and stop requiring IPv4 for 
new eyeball installations, that’s the biggest initial win.

Owen

Re: IPv6 woes - RFC

[Owen DeLong via NANOG]

> But you don't have to look far before you hit snags like this:
> https://www.norid.no/en/om-domenenavn/regelverk-for-no/vedlegg-f/

I just sent the following to them:

I’m writing about your name server requirements page:

https://www.norid.no/en/om-domenenavn/regelverk-for-no/vedlegg-f/

I think that requirement 4:

Accessible name servers 
Name servers must be permanently connected to the Internet, and must have a 
permanently assigned (fixed) IPv4 address. The name servers may also have an 
IPv6 address, and this too must be permanently assigned as required for the 
IPv4 address. The name servers must be connected to a stable and reliable 
infrastructure.

is somewhat out of date relevant to current best internet practices…

At the very least, IPv6 should no longer be options.

Ideally, IPv4 should be optional.

Suggest you send something similar.

Owen

Re: IPv6 woes - RFC

[Owen DeLong via NANOG]

> On Sep 8, 2021, at 11:57 , Niels Bakker  wrote:
> 
> * Owen DeLong via NANOG [Wed 08 Sep 2021, 20:35 CEST]:
>> IPv4 continues to increase in cost. Surely, there is a point where 
>> organizations start to cry uncle.
> 
> In most western countries there isn't much growth in the total number of 
> connections. It's mostly churn between providers. IPv4 addresses aren't 
> wasted once a customer leaves (unlike for mobile numbers there is no mandated 
> number portability for IP addresses), they can be reused for the next 
> customer, they don't deteriorate when kept in stock, and they can likely be 
> sold for more, later, eventually.
> 
> (As long as you buy, not rent, that is, and LIR fees don't significantly 
> increase.)
> 
> 
>   -- Niels.

The addresses aren’t the major cost of providing IPv4 services.

CGN boxes, support calls, increasing size of routing table = buying new 
routers, etc.

Increased cost of developers having to work around NAT and NAT becoming ever 
more complex with multiple layers, etc.

All of these are the things driving the ever increasing cost of IPv4 services, 
not just the cost of the addresses.

Owen

Re: IPv6 woes - RFC

[Owen DeLong via NANOG]

> On Sep 8, 2021, at 18:55 , Valdis Klētnieks  wrote:
> 
> On Wed, 08 Sep 2021 11:39:50 -0700, Owen DeLong via NANOG said:
> 
>> The reality is that if we get content dual-stacked and stop requiring IPv4
>> for new eyeball installations, that’s the biggest initial win.
> 
> The problem is "get content dual-stacked".
> 
> Somebody made this handy page of the IPv6 status for the Alexa Top 500.
> 
> http://www.delong.com/ipv6_alexa500.html
> 
> Awful lot of red spots even in the top 100.  Hell, even amazon.com
> isn't IPv6 yet.  And the long tail is going to be the death of a thousand
> cuts for the call center unless you have a way to deal with those sites.

This is my point… That is why I think an announcement of “On X date,
we will begin charging extra for IPv4 services and define Internet Access
to be IPv6” by a couple of the larger eyeball ISPs would light a pretty
big fire under those laggards.

Think about it… Amazon doesn’t want to lose access to Comcast, T-Mobile,
Verizon Wireless, and/or AT&T eyeballs any more than those ISPs want
to deal with the call center consequences if they turn off IPv4 before those
content providers are ready.

If they put that date, say, 5 years out, perhaps January 15, 2027 for
example, so that it doesn’t happen during the retail cash cow season,
I suspect it would drive that long tail to shorten. Right now, it’s costing
Amazon (amazon.com, not AWS) nothing to ignore IPv6 and continue
lagging, they’re able to externalize all of those costs onto the eyeball ISPs.

> And the devil is in the details.  cnn.com itself has a quad-A. But looking
> at Chrome loading it with the IPvFoo extension, I see that of the 145
> addresses it hits, only 38 are IPv6, the rest are IPv4.

You don’t think they’d be motivated by a drop-dead date agreed upon
by the eyeball ISPs? I think they would.

> On the other hand, looking at *who* are the IPv4, they seem to be
> overwhelmingly ad servers and analytics sites - so maybe hitting cnn.com as
> IPv6-only is a win for the consumer.  I rather suspect that the CFO of CNN
> would see it differently though

I rather suspect that an announcement of a drop-dead date 5 years out by
a select group of major eyeball providers would get the situation corrected
likely well short of 5 years.

> (Eerily reminiscent of the factoid that 60% of the cost of a long distance
> phone call before the AT&T breakup was keeping the accounting records
> so they could bill the customer)

Yes… IIRC, After the breakup, that jumped to more like 80% until things finally
got to the point that everyone recognized that eliminating the billing records
for such things saved tons of money.

Owen

Re: IPv6 woes - RFC

[Owen DeLong via NANOG]

> On Sep 10, 2021, at 01:39 , Jeroen Massar  wrote:
> 
> 
> 
>> On 20210909, at 21:55, Owen DeLong via NANOG  wrote:
>>> [..]
>>> Awful lot of red spots even in the top 100.  Hell, even amazon.com
>>> isn't IPv6 yet.  And the long tail is going to be the death of a thousand
>>> cuts for the call center unless you have a way to deal with those sites.
>> 
>> This is my point… That is why I think an announcement of “On X date,
>> we will begin charging extra for IPv4 services and define Internet Access
>> to be IPv6” by a couple of the larger eyeball ISPs would light a pretty
>> big fire under those laggards.
> 
> You mean like: https://docs.hetzner.com/general/others/ipv4-pricing/ ?
> 
> yes, a /24 was 0 setup, now now close to 5000 of currency and the monthly 
> fee also doubled.
> Noting that 20 for an IPv4 IP is effectively quite cheap with current prices 
> going towards 50+...
> 
> There are thus already a few places that are doing the squish
> 
> Greets,
> Jeroen
> 

Yes, but it needs to come from a major eyeball ISP to be the motivating
factor that we need here. A minor virtual server host isn’t going to do it.

Owen

Re: Voice Middleware

[Owen DeLong via NANOG]

I don’t know the current state, but I believe Asterisk was going down that road 
for a while.

Owen


> On Sep 10, 2021, at 05:26 , Mike Hammett  wrote:
> 
> Before we build something from scratch, are there platforms that do the heavy 
> lifting of talking to the Metaswitch API, Peerless's API, various LSR APIs, 
> etc.?
> 
> I mean this for provisioning purposes.
> 
> 
> 
> -
> Mike Hammett
> Intelligent Computing Solutions
> http://www.ics-il.com 
> 
> Midwest-IX
> http://www.midwest-ix.com 

Re: Xfi Advances Security (comcast)

[Owen DeLong via NANOG]

First thing I do with any cable modem is convert it to bridge mode.

The fewer “smarts” in the cable modem doing odd things to my traffic, the 
better.

Owen


> On Sep 10, 2021, at 10:40 , Eric Kuhnke  wrote:
> 
> I know this is not a solution to your problem, but I have found myself more 
> often running the public interface of openvpn systems on port 443. Any 
> sufficiently advanced DPI setup will be able to tell that it's not quite 
> normal https traffic. 
> 
> But 99% of the time it seems to serve the purpose of defeating 
> heavily-restricted "free" wifi in airports, hotels, random guest/amenity wifi 
> stuff, which obviously can't block https/443 to the world these days.
> 
> On Fri, Sep 10, 2021 at 11:08 AM Jason Kuehl  > wrote:
> This is an SSL VPN that is being blocked. This is what failure looks like. 
> Curl is the same.
> 
> Once we disable the Xfi  Advanced Security everyone can connect.
> 
> 
> 
> On Fri, Sep 10, 2021 at 11:01 AM Jim Popovitch via NANOG  > wrote:
> On Fri, 2021-09-10 at 10:31 -0400, Jason Kuehl wrote:
> > For whatever reason Comcast Xfinity is blocking my VPN URL. 
> 
> Not certain that this applies, but Concast Advanced Security (setup in
> your Comcast gateway) only allows outbound VPN connections to UDP ports
> 500, 4500, and 62515 and TCP port 1723.
> 
> -Jim P.
> 
> 
> 
> -- 
> Sincerely,
>  
> Jason W Kuehl
> Cell 920-419-8983
> jason.w.ku...@gmail.com 

Re: Voice Middleware

[Owen DeLong via NANOG]

That’s probably not the full extent of it, but yes, that looks like a good 
starting point.

On closer look, the fact that he’s looking for something to abstract their 
provisioning APIs rather than an
interconnected for them at the call switching level, Asterisk probably doesn’t 
address the problem he’s
looking to solve.

Owen


> On Sep 10, 2021, at 13:07 , james jones  wrote:
> 
> Owen,
> 
> Do you mean this 
> https://www.voip-info.org/asterisk-how-to-connect-to-metaswitch/ 
> <https://www.voip-info.org/asterisk-how-to-connect-to-metaswitch/>?
> I am not sure that is what he is looking for, but it could be. It has been a 
> while for me as well :)
> 
> Mike,
> 
> Could you give a little more context in what you are trying to do? Are you 
> looking for something that can manage all those devices via their web APIs?
> 
> -James
> 
> On Fri, Sep 10, 2021 at 12:39 PM Owen DeLong via NANOG  <mailto:nanog@nanog.org>> wrote:
> I don’t know the current state, but I believe Asterisk was going down that 
> road for a while.
> 
> Owen
> 
> 
>> On Sep 10, 2021, at 05:26 , Mike Hammett > <mailto:na...@ics-il.net>> wrote:
>> 
>> Before we build something from scratch, are there platforms that do the 
>> heavy lifting of talking to the Metaswitch API, Peerless's API, various LSR 
>> APIs, etc.?
>> 
>> I mean this for provisioning purposes.
>> 
>> 
>> 
>> -
>> Mike Hammett
>> Intelligent Computing Solutions
>> http://www.ics-il.com <http://www.ics-il.com/>
>> 
>> Midwest-IX
>> http://www.midwest-ix.com <http://www.midwest-ix.com/>

Re: IPv6 woes - RFC

[Owen DeLong via NANOG]

> On Sep 10, 2021, at 13:22 , John Levine  wrote:
> 
> It appears that Owen DeLong via NANOG  said:
>> This is my point… That is why I think an announcement of “On X date,
>> we will begin charging extra for IPv4 services and define Internet Access
>> to be IPv6” by a couple of the larger eyeball ISPs would light a pretty
>> big fire under those laggards.
> 
> Indeed.  They would send postcards to all their customers saying
> "Comcast has said they will cut off your access to Netflix on April 1,
> Call their president's office at 1-800-xxx- and tell them what you think."

Nope… Netflix is fully available on IPv6 and actually looks forward to ISPs
doing this.

Now Amazon might send post cards saying “Comcast has said that they
will cut off your access to our store…”, but I suspect that the cost of such
a campaign and the collateral damage would be well in excess of the
cost of just adding IPv6 to their service.

Owen

Re: IPv6 woes - RFC

[Owen DeLong via NANOG]

> On Sep 10, 2021, at 14:17 , Jeroen Massar  wrote:
> 
> On 2021-09-10 18:27, Owen DeLong wrote:
>>> On Sep 10, 2021, at 01:39 , Jeroen Massar  wrote:
>>> 
>>> 
>>> 
>>>> On 20210909, at 21:55, Owen DeLong via NANOG  wrote:
>>>>> [..]
>>>>> Awful lot of red spots even in the top 100.  Hell, even amazon.com
>>>>> isn't IPv6 yet.  And the long tail is going to be the death of a thousand
>>>>> cuts for the call center unless you have a way to deal with those sites.
>>>> 
>>>> This is my point… That is why I think an announcement of “On X date,
>>>> we will begin charging extra for IPv4 services and define Internet Access
>>>> to be IPv6” by a couple of the larger eyeball ISPs would light a pretty
>>>> big fire under those laggards.
>>> 
>>> You mean like: https://docs.hetzner.com/general/others/ipv4-pricing/ ?
>>> 
>>> yes, a /24 was 0 setup, now now close to 5000 of currency and the 
>>> monthly fee also doubled.
>>> Noting that 20 for an IPv4 IP is effectively quite cheap with current 
>>> prices going towards 50+...
>>> 
>>> There are thus already a few places that are doing the squish
>>> 
>>> Greets,
>>> Jeroen
>>> 
>> Yes, but it needs to come from a major eyeball ISP to be the motivating
>> factor that we need here. A minor virtual server host isn’t going to do it.
> 
> "minor virtual server host". I think you are underestimating things...
> 
> https://bgp.he.net/AS24940 + AS213230
> 
> That is not a toy network... but hey, I guess 'everything is bigger' on the 
> other side of the big old lake eh.

Not everything, but compare to (e.g. 15169, 16509).

Also, the key here is more that we need large eyeballs, such as 7922, 21928, 
6167, 6298, etc.).

I wasn’t meaning to disparage Hetzner in any way, but they’re a cloud host, not 
an eyeball provider. While they’re not a toy network, I also wouldn’t call them 
a major cloud provider in the same league with (e.g. AWS, Azure, Google Cloud).

> I am sure, considering the news and rumors, that that pricing change made, 
> that it made an impact at a lot of companies, that things are changing, and 
> that is a win for IPv6...

Agreed… I’m glad to see what they’ve done, but I’m advocating for someone like 
Comcast to follow suit in hopes that it will drive other large content 
providers to make the move.

Owen

Re: Xfi Advances Security (comcast)

[Owen DeLong via NANOG]

Yes, I own my own modem even though comcast now charges me $5/month more than 
if I rented their equipment for this privilege.

Owen


> On Sep 10, 2021, at 15:49 , Eric Kuhnke  wrote:
> 
> Ideally being your own customer owned cable modem that meets specs (Comcast 
> does allow this in some regions) that will function as a layer 2 bridge. 
> 
> On Fri, Sep 10, 2021, 1:46 PM Owen DeLong  > wrote:
> First thing I do with any cable modem is convert it to bridge mode.
> 
> The fewer “smarts” in the cable modem doing odd things to my traffic, the 
> better.
> 
> Owen
> 
> 
>> On Sep 10, 2021, at 10:40 , Eric Kuhnke > > wrote:
>> 
>> I know this is not a solution to your problem, but I have found myself more 
>> often running the public interface of openvpn systems on port 443. Any 
>> sufficiently advanced DPI setup will be able to tell that it's not quite 
>> normal https traffic. 
>> 
>> But 99% of the time it seems to serve the purpose of defeating 
>> heavily-restricted "free" wifi in airports, hotels, random guest/amenity 
>> wifi stuff, which obviously can't block https/443 to the world these days.
>> 
>> On Fri, Sep 10, 2021 at 11:08 AM Jason Kuehl > > wrote:
>> This is an SSL VPN that is being blocked. This is what failure looks like. 
>> Curl is the same.
>> 
>> Once we disable the Xfi  Advanced Security everyone can connect.
>> 
>> 
>> 
>> On Fri, Sep 10, 2021 at 11:01 AM Jim Popovitch via NANOG > > wrote:
>> On Fri, 2021-09-10 at 10:31 -0400, Jason Kuehl wrote:
>> > For whatever reason Comcast Xfinity is blocking my VPN URL. 
>> 
>> Not certain that this applies, but Concast Advanced Security (setup in
>> your Comcast gateway) only allows outbound VPN connections to UDP ports
>> 500, 4500, and 62515 and TCP port 1723.
>> 
>> -Jim P.
>> 
>> 
>> 
>> -- 
>> Sincerely,
>>  
>> Jason W Kuehl
>> Cell 920-419-8983
>> jason.w.ku...@gmail.com 

Re: IPv6 woes - RFC

[Owen DeLong via NANOG]

> On Sep 12, 2021, at 11:35 , Brian Johnson  wrote:
> 
> 
> 
>> On Sep 11, 2021, at 9:04 PM, Fred Baker  wrote:
>> 
>> 
>> Sent using a machine that autocorrects in interesting ways...
>> 
>>> On Sep 8, 2021, at 1:31 AM, Saku Ytti  wrote:
>>> 
>>> If the mid size eyeballs knew ipv4 is going away in 10, 15, 20 years
>>> whichever it is, then they'd of course have to start moving too,
>>> because no upstream.
>> 
>> And they would fight it tooth and nail, just like they do now, and if they 
>> found an address they could NAT to, they would argue that that one address 
>> gave them the ability to avoid the transition -just like they do now.
> 
> Speaking for the smaller providers, there is enough of the Internet that is 
> only accessible via IPv4 out there that CGN solutions are a reasonable way to 
> manage the situation. There is also enough legacy equipment out there that 
> doesn’t accommodate IPv6 that this process will still take several decades.
> 
> Edicts never work. More carrot, less stick.

They did with ATSC.

Owen

Re: IPv6 woes - RFC

[Owen DeLong via NANOG]

> On Sep 13, 2021, at 05:17 , Mark Tinka  wrote:
> 
> 
> 
> On 9/13/21 01:00, Michael Thomas wrote:
> 
>> 
>> If vendors actually cared they could make the CGNAT's and other hacks 
>> ridiculously buggy and really expensive to deploy and maintain. I doubt many 
>> vendors were chomping at the bit to support CGNAT and are probably wondering 
>> what fresh hell is next to keep ipv4 limping along.
>> 
> 
> 10's of millions of dollars being spent by African mobile operators, every 
> year, in CG-NAT hardware and licenses, with the vendors.
> 
> They will make sure that code is bug-free :-).

ROFLMAO

100s of millions of dollars are spent every year on major backbone router kit. 
That code has never been bug free.

Your assertion is provably false.

Owen

Re: Xfi Advances Security (comcast)

[Owen DeLong via NANOG]

> On Sep 13, 2021, at 07:56 , Livingood, Jason via NANOG  
> wrote:
> 
> On 9/10/21, 10:58, "NANOG on behalf of Chris Boyd" 
>  cb...@gizmopartners.com> wrote:
> 
>> Why is Comcast blocking things? That seems like it’s out of scope for an ISP.
> 
> For Internet access, sure. But ISPs also have value added protection services 
> and this part of an optional content filtering service that is integrated 
> into the leased Comcast gateways. Users can turn on things like parental 
> controls, including time limit and time-of-day boundaries for certain devices 
> (e.g. cut off kid's game console Internet access at midnight on school 
> nights). See 
> https://www.xfinity.com/support/articles/using-xfinity-xfi-advanced-security
> 
> Jason
> 
> 

Yes, but it’s tragically opt-out instead of opt-in as it should be. That means 
that anyone whose site happens to get miscategorized by them gets the added 
costs of dealing with the user complaints instead of Comcast having to bear the 
costs of their error.

It’s a classic example of the toxic polluter business model. Do something 
stupid while making sure that the costs of your errors fall on someone else.

Owen

Re: IPv6 woes - RFC

[Owen DeLong via NANOG]

> On Sep 14, 2021, at 12:58 , Michael Thomas  wrote:
> 
> 
> 
> On 9/14/21 5:37 AM, Eliot Lear wrote:
>> 8+8 came MUCH later than that, and really wasn't ready for prime time.  The 
>> reason we know that is that work was the basis of LISP and ILNP.  Yes, 
>> standing on the shoulders of giants.  And there certainly were poor design 
>> decisions in IPv6, bundling IPsec being one.  But the idea that operators 
>> were ignored?  Feh.
>> 
> I wasn't there at actual meetings at the time but I find the notion that 
> operators were ignored pretty preposterous too. There was a significant 
> amount of bleed over between the two as I recall from going to Interop's. 
> What incentive do vendors have to ignore their customers? Vendors have 
> incentive to listen to customer requirements and abstract them to take into 
> account things can't see on the outside, but to actually give the finger to 
> them? And given how small the internet community was back while this was 
> happening, I find it even more unlikely. 
> 

You’d be surprised… Vendors often get well down a path before exposing enough 
information to the community to get the negative feedback their solution so 
richly deserves. At that point, they have rather strong incentives to push for 
the IETF adopting their solution over customer objections because of entrenched 
code-base and a desire not to go back and explain to management that the idea 
they’ve been working on for the last 6 months is stillborn.

Owen

Re: IPv6 woes - RFC

[Owen DeLong via NANOG]

> On Sep 14, 2021, at 13:51 , Michael Thomas  wrote:
> 
> 
> 
> On 9/14/21 1:06 PM, Owen DeLong wrote:
>> 
>> 
>>> On Sep 14, 2021, at 12:58 , Michael Thomas >> > wrote:
>>> 
>>> 
>>> 
>>> On 9/14/21 5:37 AM, Eliot Lear wrote:
 8+8 came MUCH later than that, and really wasn't ready for prime time.  
 The reason we know that is that work was the basis of LISP and ILNP.  Yes, 
 standing on the shoulders of giants.  And there certainly were poor design 
 decisions in IPv6, bundling IPsec being one.  But the idea that operators 
 were ignored?  Feh.
 
>>> I wasn't there at actual meetings at the time but I find the notion that 
>>> operators were ignored pretty preposterous too. There was a significant 
>>> amount of bleed over between the two as I recall from going to Interop's. 
>>> What incentive do vendors have to ignore their customers? Vendors have 
>>> incentive to listen to customer requirements and abstract them to take into 
>>> account things can't see on the outside, but to actually give the finger to 
>>> them? And given how small the internet community was back while this was 
>>> happening, I find it even more unlikely. 
>>> 
>> 
>> You’d be surprised… Vendors often get well down a path before exposing 
>> enough information to the community to get the negative feedback their 
>> solution so richly deserves. At that point, they have rather strong 
>> incentives to push for the IETF adopting their solution over customer 
>> objections because of entrenched code-base and a desire not to go back and 
>> explain to management that the idea they’ve been working on for the last 6 
>> months is stillborn.
>> 
> But we're talking almost 30 years ago when the internet was tiny. And it's 
> not like operators were some fount of experience and wisdom back then: 
> everybody was making it up along the way including operators which barely 
> even existed back then. I mean, we're talking about the netcom days here. 
> That's why this stinks of revisionist history to me.
> 

I was there for parts of it. Even then, the vendors were entrenched in their 
views and dominated many of the conversations.

Owen

Re: IPv6 woes - RFC

[Owen DeLong via NANOG]

> On Sep 14, 2021, at 14:20 , Michael Thomas  wrote:
> 
> 
> On 9/14/21 2:07 PM, Owen DeLong wrote:
>> You’d be surprised… Vendors often get well down a path before exposing 
>> enough information to the community to get the negative feedback their 
>> solution so richly deserves. At that point, they have rather strong 
>> incentives to push for the IETF adopting their solution over customer 
>> objections because of entrenched code-base and a desire not to go back and 
>> explain to management that the idea they’ve been working on for the last 6 
>> months is stillborn.
 
>>> But we're talking almost 30 years ago when the internet was tiny. And it's 
>>> not like operators were some fount of experience and wisdom back then: 
>>> everybody was making it up along the way including operators which barely 
>>> even existed back then. I mean, we're talking about the netcom days here. 
>>> That's why this stinks of revisionist history to me.
>>> 
>> 
>> I was there for parts of it. Even then, the vendors were entrenched in their 
>> views and dominated many of the conversations.
>> 
> Vendors have to be able to implement things so of course there is going to be 
> push back when it's not technically feasible or far more expensive. Nobody 
> expects customers putting out the actual $$$ to be up to speed on the 
> intricacies of TCAM's and other such considerations so there is always going 
> to be back and forth.

Back and forth is one thing, but the reality is that they put a lot of 
development effort into things in a vacuum and then expected us to take what 
they built and standardize it. They often seemed utterly surprised when the 
practical realities of deploying it in an operational network didn’t agree with 
their idea of an “elegant” solution.

> And none of this alters that nobody has given a scenario where their 
> $SOLUTION would have fared any better than ipv6.

That’s probably fair criticism to some extent.

Owen

Re: IPv6 woes - RFC

[Owen DeLong via NANOG]

> On Sep 15, 2021, at 09:31 , Masataka Ohta  
> wrote:
> 
> Baldur Norddahl wrote:
> 
 But in fact with local number portability, you cannot rely on the county
> 
 code to tell you where to route a telephone call anymore.
>>> 
>>> Not. With geographical aggregation, you may route a call
>>> *anywhere* in the destination country.
> 
>> You mean anywhere in the world. Calls to my number reach my cell phone no
>> matter where I go.
> 
> You are confusing number portability and call forwarding.
> 
>   Masataka Ohta

Not exactly… He is confusing number portability and roaming.

Owen

Re: IPv6 woes - RFC

[Owen DeLong via NANOG]

> On Sep 15, 2021, at 16:20 , Michael Thomas  wrote:
> 
> 
> 
> On 9/14/21 12:44 AM, Eliot Lear wrote:
>> 
>> There were four proposals for the IPng:
>> 
>> NIMROD, PIP, SIP, and TUBA
>> SIP was the one that was chosen, supported by endpoint manufacturers such as 
>> Sun and SGI, and it was the MOST compatible.  Operators and router 
>> manufacturers at the time pushed TUBA, which was considerably less 
>> compatible with the concepts used in v4 because of variable length 
>> addressing.   If we endpoints had some notion that v6 would take as long as 
>> it has to diffuse, perhaps we all might have thought differently.  I don't 
>> know.
>> 
>> 
> So I'm beginning to think that the reason ipv6 didn't take off is one simple 
> thing: time. All of the infighting took years and by then that ship had long 
> sailed. The basic mechanisms for v6 for hosts were not complicated and all of 
> the second system syndrome fluff could be mostly be ignored or implemented 
> when it actually made sense. If this had been settled within a year instead 
> of five, there may have been a chance especially since specialized hardware 
> was either nonexistent or just coming on the scene. I mean, Kalpana was still 
> pretty new when a lot of this was being first discussed from what I can tell. 
> Maybe somebody else knows when hardware routing came on the scene but there 
> was still lots of software forwarding planes when I started at Cisco in 1998 
> just as broadband was starting to flow.
> 
Most of it was settled fairly quickly, actually. The bigger delays were 
software vendors, network infrastructure product vendors (DSLAMs and the like), 
etc. who even after it was well settled simply didn’t feel a need to 
incorporate it into their products until about a year after IANA runout.
> The IETF was a victim of its own dysfunction, film at 11 and now we're having 
> a 30 year reunion.
> 
I’m not sure we can put all (or even most) of the blame on IETF dysfunction 
here. Don’t get me wrong, IMHO there’s plenty of IETF dysfunction and it is 
partially responsible. However, I suspect that if IETF had rolled out the model 
of perfection and an ideal protocol 1 month after the IPNG working group 
started, we’d still be pretty much where we are today because of the 
procrastination model of addressing major transitions that is baked into human 
nature.

Owen

Re: IPv6 woes - RFC

[Owen DeLong via NANOG]

> On Sep 16, 2021, at 06:35 , Jared Mauch  wrote:
> 
> 
> 
>> On Sep 16, 2021, at 9:23 AM, Ca By  wrote:
>> 
>> 
>> 
>> 
>> This has nothing to do with IPv6, of course, other than that modern phones 
>> use
>> VoLTE so within a mobile carrier's network your voice call is probably 
>> handled
>> using IPv6 transport.
>> 
>> Good point John. 
>> 
>> A lot of folks missed that ipv6 absorbed the scale growth in mobile, and 
>> mobile is what most eyeballs and be big content consider the internet to be. 
>> And, yes, mobile voice is called VoLTE and is most commonly deployed in the 
>> usa with ipv6. 
>> 
>> And most internet is called youtube / fb, and that is ipv6 too. 
>> 
>> This is where i live and work , 87% of mobiles on v6, voice and data
>> 
>> https://www.worldipv6launch.org/apps/ipv6week/measurement/images/graphs/CombinedUSMobileCarriers.png
>> 
>> This is where nanog seems to be (old man yells at cloud meme)
>> 
>> https://static.wikia.nocookie.net/memepediadankmemes/images/0/01/297.jpg/revision/latest?cb=20180908193511
>> 
>> I don’t see the failure of ipv6 in 2021. It is globally deployed, providing 
>> global address, to billions of things and PB/s of content 
>> 
>> There are laggards in adopting v6, but they have not stopped the frontier of 
>> internet to reaching billions of people and things. 
>> 
> 
> 
> Yeah, I think this is the thing that I see people most often missing.  Yes 
> your provider may not be doing IPv6, but many applications and providers may 
> yet be IPv6 internally or IPv6 to the popular content. 
> 
> I also say the number of people who store an IP as integer in a 
> mysql(mariadb) backend is not to be underestimated.  

Nothing wrong with this as long as it’s a 128 bit integer. ;-)

> I still see some people doing the split up the IPv6 to store it in multiple 
> columns thing even in 2021 which is disappointing as it shows this 
> backwards/legacy thinking.

UGH… I haven’t seen that in a while, sad to hear it’s still going on.

Owen

Re: IPv6 woes - RFC

[Owen DeLong via NANOG]

> On Sep 11, 2021, at 13:17 , John R. Levine  wrote:
> 
>>> Indeed.  They would send postcards to all their customers saying
>>> "Comcast has said they will cut off your access to Netflix on April 1,
>>> Call their president's office at 1-800-xxx- and tell them what you 
>>> think."
>> 
>> Nope… Netflix is fully available on IPv6 and actually looks forward to ISPs
>> doing this.
> 
> OK, then Disney+ or Hulu or whoever.  Peering wars never end well.  Don't 
> even need postcards, just stick the flyer in with the bill.

Is that really cheaper and easier than deploying IPv6? Really?

>> Now Amazon might send post cards saying “Comcast has said that they
>> will cut off your access to our store…”, but I suspect that the cost of such
>> a campaign and the collateral damage would be well in excess of the
>> cost of just adding IPv6 to their service.
> 
> AWS has perfectly good support for IPv6 so they must have business reasons to 
> stick with v4.  But I expect the cost of putting up banners on the homepage 
> saying to call your ISP, for people coming through the relevant ISP, would be 
> pretty cheap, and Amazon's customers appear to like their accounts and their 
> Prime quite a lot.  Again, peering wars never end well.

This isn’t really the same as a peering war, however. They can’t really claim 
Comcast is going to cut you off. They’d have to admit that Comcast is going to 
start charging more for…

Remember, I didn’t suggest that Comcast turn off IPv4… I suggested that Comcast 
start passing along some of the added expense of maintaining IPv4 connectivity 
to the customers that want it.

> This ignores the question of what the advantage to the ISP would be other 
> than bloody-mindedness.  The world is not going to abandon IPv4 any time soon 
> and the last time I looked, the cost of routing packets is the same 
> regardless of which header they have.

You haven’t looked in depth, then. The cost of routing packets is the same. The 
cost of dealing with address shortages and supporting/maintaining the various 
hacks and workarounds intended to help mitigate that issue continues to 
increase.

As I have repeatedly stated, the perverse incentive here that drives things is 
that those who lag aren’t bearing most of the costs. Instead, like toxic 
polluters, they are able to externalize those costs to developers, eyeball 
ISPs, CDNs, and others while continuing the status quo.

The flyer in the bill thing works both ways. Comcast could just as easily put 
in a flyer that points out the facts of the situation:

1.  There is a flaw in the addressing scheme currently in use in that it 
doesn’t have enough addresses for everyone.
2.  There is a new-iso addressing scheme that has been in use for more than 
20 years now.
3.  Many services are available through either addressing scheme today.
4.  The cost of preserving connectivity to the old addressing scheme is 
continuing to increase.
5.  As a result, starting on , we will be passing 
some of those costs on to customers who still
want to use the old addressing scheme in the form of an “IPv4 
Surcharge”.
6.  For more details and to see a list of popular services that do and 
don’t currently work with the new addressing scheme,
check here.

If the surcharge starts out at something silly like $2/month or even $5/month, 
I bet most customers just pay it.

Large chunks of the world (those that have IPv6 deployed) would love to abandon 
or mostly abandon IPv4 as soon
as possible. That possibility isn’t defined as “when everybody has IPv6”. It’s 
defined (for at least eyeball ISPs) as
“When enough of the content providers our customers care about are on IPv6 that 
the business we lose by turning
off IPv4 costs less than maintaining IPv4 for all of our customers.”

That day may not be today, but it is coming and I don’t think it’s as far off 
as you imagine.

The soft way for eyeball ISPs to approach that is to start passing along some 
of those costs to their customers by
making IPv4 an opt-in add-on to their Internet Service with a nominal charge. 
Sort of like the fee I used to pay when
I had cable TV service where they charged me ~$5 every month for “access to 
local sports” which I didn’t want
and repeatedly asked them to stop.

Owen

Re: IPv6 woes - RFC

[Owen DeLong via NANOG]

> On Sep 17, 2021, at 21:03 , John R. Levine  wrote:
> 
>>> OK, then Disney+ or Hulu or whoever.  Peering wars never end well.  Don't 
>>> even need postcards, just stick the flyer in with the bill.
>> 
>> Is that really cheaper and easier than deploying IPv6? Really?
> 
> The cost of putting flyers in the bills rounds to zero, so yes, really. I 
> expect these companies all have plans to support v6 eventually, someday, once 
> they're retired and replaced all of the old junk that handles v6 poorly or 
> not at all, but you know about accountants and depreciation.

Unless their infrastructure runs significantly on hardware and software 
pre-2004 (unlikely), so does the cost of adding IPv6 to their content servers. 
Especially if they’re using a CDN such as Akamai.
> 
>> Remember, I didn’t suggest that Comcast turn off IPv4… I suggested that 
>> Comcast start passing along some of the added expense of maintaining IPv4 
>> connectivity to the customers that want it.
> 
> Ah, so they should start adding a gratuitous charge for a feature they have 
> always provided as part of the basic service.  How many milliseconds do you 
> think it'll take for the Congress to haul their CEO in front of a committee?

I doubt that their CEO would get hauled in at all. Even if he did, I would 
think this would be one of the easiest hearings ever for them as literally, 
they could easily show the increased costs of continuing to provide IPv4 
services and note that they didn’t want to jack up everyone’s bills to support 
the customers that need IPv4, so they’ve made IPv4 an opt-in value added 
service instead of punishing customers that don’t patronize laggards. (I’m sure 
their lawyers would say it better, I’m blunt).

>> That day may not be today, but it is coming and I don’t think it’s as far 
>> off as you imagine.
> 
> Nothing personal, but people have been saying exactly that for about 25 years 
> now.  Please forgive me if I continue not to hold my breath.

Nope… People have been saying that IPv4 would stop being the lingua franca of 
the internet for 25+ years. There’s still hope for that, but I agree it’s been 
disappointingly and tragically slow.

OTOH, the idea of doing cost-recovery on the additional nuisance that is IPv4 
is relatively novel and hasn’t been floated that I’m aware of more than 3 or 4 
years ago.

Bottom line is that IPv4 continues to increase costs for eyeball providers. 
They’ll need to recover that cost. At some point, the cost will be enough of a 
differentiator that customers willing to accept v6-only service will get a 
break.

If they don’t do it as an IPv4 surcharge, they could do it as an IPv6-only 
discount… That might even be better. Either way, the net effect is the same… 
Suddenly, customers have a monetary advantage to push their content providers 
toward providing v6.

Owen

Re: IPv6 woes - RFC

[Owen DeLong via NANOG]

> On Sep 18, 2021, at 11:37 , John Levine  wrote:
> 
> It appears that Owen DeLong via NANOG  said:
>>> The cost of putting flyers in the bills rounds to zero, so yes, really. I 
>>> expect these companies all have plans
>> to support v6 eventually, someday, once they're retired and replaced all of 
>> the old junk that handles v6 poorly or
>> not at all, but you know about accountants and depreciation.
>> 
>> Unless their infrastructure runs significantly on hardware and software 
>> pre-2004 (unlikely), so does the cost of
>> adding IPv6 to their content servers. Especially if they’re using a CDN such 
>> as Akamai.
> 
> I wasn't talking about switches and routers.  I was talking about every 
> single piece of software and equipment that
> they use for support and marketing and customer service and all the other 
> stuff that big companies do.

That doesn’t all have to change in order to make their services available on 
IPv6 also.

IPv6 is not an all-or-nothing thing.

If your backend is all IPv4 all the time and you want to keep it that way, more 
power to you. I encourage my competitors to try that.

However, if your customer-facing services are IPv4-only, that’s not hard to fix 
in most cases and it’s really obnoxious not to do so.

> As I may have said once or twice, eventuallly it'll all be replaced so it 
> works on IPv6 but we're not holding our breath.

I’m not holding my breath, but I’m also trying to argue reasonable approaches 
and realistic solutions here.

You seem to be looking for excuses to claim the problem that needs to be solved 
is harder than it is to justify not solving it.

Owen

Re: IPv6 woes - RFC

[Owen DeLong via NANOG]

> On Sep 18, 2021, at 12:34 , Victor Kuarsingh  wrote:
> 
> 
> 
> On Sat, Sep 18, 2021 at 2:39 PM John Levine  <mailto:jo...@iecc.com>> wrote:
> It appears that Owen DeLong via NANOG  <mailto:o...@delong.com>> said:
> >> The cost of putting flyers in the bills rounds to zero, so yes, really. I 
> >> expect these companies all have plans
> >to support v6 eventually, someday, once they're retired and replaced all of 
> >the old junk that handles v6 poorly or
> >not at all, but you know about accountants and depreciation.
> >
> >Unless their infrastructure runs significantly on hardware and software 
> >pre-2004 (unlikely), so does the cost of
> >adding IPv6 to their content servers. Especially if they’re using a CDN such 
> >as Akamai.
> 
> I wasn't talking about switches and routers.  I was talking about every 
> single piece of software and equipment that
> they use for support and marketing and customer service and all the other 
> stuff that big companies do.
> 
> As I may have said once or twice, eventuallly it'll all be replaced so it 
> works on IPv6 but we're not holding our breath.
> 
> Glad you noted this.  Thinking this was/is purely a hardware cycle problem 
> related to normal/forced upgrade strategies.  On that point, most hardware I 
> know of from 2004 in larger networks is long fully depreciated and sweating 
> assets 15+ years can happen, but I don't personally think this is the biggest 
> issue.

It’s certainly not purely hardware, but it also doesn’t require solving the 
entire problem across the entire backend.

What is urgently needed is to fix the customer-facing front end so that it 
speaks both protocols (or at least speaks IPv6).

> As you noted John, its the plethora of software, support systems, tooling, 
> and most important in many environments - legacy customer management and 
> provisioning systems that can be the limiting factor.  I recall looking back 
> when leading IPv6 turn-up, those were the biger problems to solve for.  Often 
> such systems are extremely expensive to touch and working on them required 
> prioritization against direct revenue generating projects (opportunity cost) 
> .  Replacing routers was just a money problem.

Why do those systems have to be updated in order to deliver the service to the 
customer in both protocols?

I mean sure, you’ll probably need to fix some logging databases that think that 
a customers address can be logged as a uint32_t, but that’s a relatively small 
number of systems that need to be updated in that case and it’s not like 
expanding the field to uint128_t in the database is incompatible with the old 
software during the upgrade process.

> I am by far not saying I agree with choices made by hold-outs, but I also 
> understand this is for many, not just an engineering problem to solve. 

I agree there are some systems that may make this more complex in some 
environments, but I don’t agree that it’s
impossible (or even particularly difficult) for a content provider to deliver 
their content on both protocols today even
if they don’t upgrade their back-end systems.

Owen

Re: IPv6 woes - RFC

[Owen DeLong via NANOG]

> On Sep 18, 2021, at 13:25 , John R. Levine  wrote:
> 
>> As you noted John, its the plethora of software, support systems, tooling,
>> and most important in many environments - legacy customer management and
>> provisioning systems that can be the limiting factor. ...
> 
> Just looking around my office, I have a Cisco SPA112 two-port ATA.  It's been 
> discontinued but Cisco says they will support it through 2025 and they 
> shipped a firmware update in 2019.  It works fine on IPv4 behind a NAT. It 
> has no v6 support at all and never will.  Multiply that by a zillion and you 
> can see that IPv4 isn't going away any time soon.

This isn’t about removing IPv4 from every last corner of the internet. It’s 
about adding IPv6 to the content providers that are blocking the ability to 
build new eyeball networks v6 only.

Owen

Re: IPv6 woes - RFC

[Owen DeLong via NANOG]

I haven’t tried the PTR thing yet, but I do have a small business client that 
has AT&T business internet and they were able to get a static /56 (For some 
reason, AT&T refused to do a /48, but we did push them on it.)

If it turns out they won’t do PTR or more likely NS for our ip6.arpa zone, then 
we’ll probably start looking for an alternative provider or get an HE /48 over 
a tunnel which will do PTR or NS records appropriately.

Owen


> On Sep 18, 2021, at 14:19 , Stephen Satchell  wrote:
> 
> I concur that the problem is not a routing hardware problem.  It's a 
> perception problem with the various ISPs.  I have fiber service with AT&T.
> 
> My little server farm endpoints all have IPv6 addresses, including the edge 
> router.  I also have a plan to allocate IPv6 addresses to my LAN devices, and 
> to protect the LAN devices from outside interference by rules in the NFTABLES 
> firewall that include connection tracking on outbound requests.  (IPv4 will 
> still use NAT to keep nefarious people from probing my internals.)
> 
> Specifically, when I was doing my mail server refresh (moving from Red Hat to 
> Canonical) I decided it was time to offer IPv6 connectivity in the mail 
> server to "future proof" my setup.  That included adding  records in my 
> DNS zone files.  Failure!  The issues:
> 
> 1.  I learned that there are no "static addresses" in IPv6, as far as AT&T 
> was concerned.  By all appearances, though, the IPv6 /64 is relatively 
> static, for now, similar to the way that early cable modem deployments kept 
> the same IPv4 addresses.  (Until the cable people started forcing changes on 
> DHCP lease renewal, that is.)
> 
> 2.  My request for PTR records was denied, which means I can't satisfy Best 
> Practices for a mail server in the IPv6 space.  No PTR records, no 
> redirection of ip6.apra space, nothing.  I include AT&T's refusal below.
> 
> 3.  I don't know how to get an IPv6 allocation from ARIN, how to request AT&T 
> to route it, or how to deal with the DNS server issues.  Oh, I know how to 
> configure BIND9; I would prefer using a 24/7/365 provider.  For example, my 
> master zone files are with Register.com, so if my circuit goes down the name 
> resolution still happens.  Register.com appears not to provide reverse-DNS 
> PTR zone support (in6.arpa).  A Google search turned up NOTHING for in6.arpa 
> hosting.
> 
> That tells me that IPv6 is not "Internet Ready" for small users.  Given the 
> level of FU responses I get trying to work with it, I will stop banging my 
> head against the wall.
> 
> So I stick with IPv4, because that will be the "standard" until the day I 
> die, as far as I can tell.
> 
> (I removed the  record, so as not to confuse mail server that DO operate 
> IPv6.)
> 
>> Subject: RE: Need IPv6 PTR record for my IPv6 mail server
>> Date: Mon, 19 Jul 2021 12:52:53 +
>> From: Prov-DNS 
>> To: Prov-DNS , a...@satchell.net 
>> Hello We don't process DNS request on IPv6 addresses. We only process DNS
>> request on IPv4 static assigned addresses.  If you would like us to
>> process a DNS request for you on a IPv4 address please provide the
>> following information.
>> IPv4 address you would like the record created for Host name you would > 
>> like that IP address pointed to 
> >
>> Thanks
>> Michael AT&T Prov-DNS
>> -Original Message-
>> From: Stephen Satchell 
>> Sent: Friday, July 16, 2021 5:42 PM
>> To: DNSUpdates cB 
>> Subject: Need IPv6 PTR record for my IPv6 mail server
>> Here is the record I need inserted into your ip6.arpa DNS zone:
> 2.3.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.c.d.d.0.b.9.7.0.0.7.1.0.0.6.2.ip6.arpa. 0 
> IN PTR smtp.satchell.net.
>> This is the result from the question section of a dig(1) request for the PTR 
>> record for my IPv6 address 2600:1700:79b0:ddc0::32, and the fully-qualified 
>> domain name of the server.
>> You can verify the information using dig smtp.satchell.net  and checking 
>> the reverse.
>> This is the only server in my collection that needs the IPv6 pointer.

Re: IPv6 woes - RFC

[Owen DeLong via NANOG]

> On Sep 18, 2021, at 23:20 , Masataka Ohta  
> wrote:
> 
> John Levine wrote:
> 
>>> Unless their infrastructure runs significantly on hardware and
>>> software pre-2004 (unlikely), so does the cost of adding IPv6 to
>>> their content servers. Especially if they’re using a CDN such as
>>> Akamai.
>> I wasn't talking about switches and routers.
> 
> But, on routers, IPv6 costs four times more than IPv4 to
> look up routing table with TCAM or Patricia tree.
> 
> It is not a problem yet, merely because full routing table of
> IPv6 is a lot smaller than that of IPv4, which means most
> small ISPs and multihomed sites do not support IPv6.

Well, it’s a combination. Even with full v6 adoption, the routing table in v6 
should be substantially smaller.

Compare AS6939 v4 vs. v6:

+   6939 is probably the most v6 fully implemented ASN on the planet.
+   6939 announces 4 of their own prefixes in v6 (They do originate 19 
prefixes on behalf of customers)
+   6939 announces at least 41 of their own prefixes in v4 and originates 
myriad customer prefixes in v4.

That’s more than 10x the prefixes in v4 for the same network fully dual-stacked 
vs. what is announced in v6.

v4 is so thoroughly fragmented and v6 is a lot less likely to become so.

> 
> 
> Mark Andrews wrote:
> 
> > There is nothing at the protocol level stopping AT&T offering a
> > similar level of service.
> 
> Setting up reverse DNS lookup for 16B address is annoying,
> which may stop AT&T offering it.

Why would one need to do that? For customers with a static prefix that want 
reverse DNS capabilities,
offer to point the NS records for their prefix wherever they want and let them 
run their own DNS servers.

> 
> > Don’t equate poor implementation with the protocol being broken.
> 
> IPv6 is broken in several ways. One of the worst thing is its
> address length.

Why do you think 128 bits isn’t enough?

Owen

Re: IPv6 woes - RFC

[Owen DeLong via NANOG]

> On Sep 10, 2021, at 00:21 , Bjørn Mork  wrote:
> 
> Owen DeLong via NANOG  writes:
> 
>> The addresses aren’t the major cost of providing IPv4 services.
>> 
>> CGN boxes, support calls, increasing size of routing table = buying new 
>> routers, etc.
> 
> You're counting dual-stack costs as if IPv4 was the optional protocol.
> That's a fantasy world.  Time to get out of la-la land now.

No, I’m counting them as if they are the increasing cost of continuing to 
support IPv4.

> Your edge routers can do CGN for all connected users just fine. Yes,
> there is still a cost both in resources and management, but you'll have
> to weigh that against the cost of doing dual-stack on the same box.  I'm
> not convinced dual-stack wins.

It does. At least in my environments.

> Don't know what you're thinking of wrt support calls, but dual-stack has
> some failure modes which are difficult to understand for both end users
> and support.  NAT is pretty well understood in comparison.

Single layer NAT, sure. But double-layer NAT has some oddities that you
might not have encountered yet…

1.  Products which are built on really strange assumptions about everyone
having the same NAT environment.

For example, Philips Hue makes an assumption that if you are in the
same household, your Hue Gateway and your phones and laptops will
all have the same public IP address.

This has two unexpected ramifications:

1.  You cannot actually complete their registration process for 
their
cloud services if you don’t NAT everything to the same address
or proxy it all through a common proxy address.

2.  If you are behind CGN, you and your neighbors are going to be
considered a single household (at least everyone behind the
same CGN address). Of course, this assumes that you get a
consistent single public CGN address for everything in your
house. If you don’t, then you get a combination of this problem
with problem 1 above and life gets very interesting.

2.  NAT Traversal technologies that don’t cope well with an added layer.

3.  Added and inconsistent latency through CGN boxes degrading
several online experiences, including voice, interactive video,
and most of all several types of gaming.

There are many more and each of them generates additional support calls
to the ISP about “The internet is broken”.

> Your routing tables won't grow with IPv4 or CGN.  They grow when you add
> IPv6.

Um, please review the IPv4 routing table report over the past few years
and tell me that again.

For your convenience: 
https://www.cidr-report.org/cgi-bin/plota?file=%2fvar%2fdata%2fbgp%2fas2.0%2fbgp%2dactive%2etxt&descr=Active%20BGP%20entries%20%28FIB%29&ylabel=Active%20BGP%20entries%20%28FIB%29&with=step


> 
>> Increased cost of developers having to work around NAT and NAT
>> becoming ever more complex with multiple layers, etc.
> 
> And this can be avoided by reconfiguring the local network somehow?  Or
> are we talking about an Internet without IPv4?  This is even more
> fantastic than the idea that IPv4 is optional in the local network.

We are talking about internet where IPv4 prevalence continues to drop. Whether
it can be avoided or not, however, it is a factor in the ever increasing cost 
of IPv4.

> 
>> All of these are the things driving the ever increasing cost of IPv4
>> services, not just the cost of the addresses.
> 
> Yes, the cost of addresses is not prohibitive, and there is no
> indication it will be.

Agreed… But the other costs are also continuing to increase. None of these
costs exist in IPv6 save a one-time deployment cost.

> The consolidation of hosting services have reduced the need for globally
> routable addresses.  You don't host your own mail server and web server
> anymore, even if you're a large organisation.

Lots do, actually.

>  Most ISPs haven't yet
> taken advantage of this.  They are still giving globally routable IPv4
> addresses to customers which have no need for that.  These addresses can
> be re-allocated for CGN if there is a need. This is obviously still not
> free, but it does limit the price of fresh IPv4 addresses.

Lots of things you don’t expect break when you stop giving at least one IPv4 GUA
to your customers.

> The other costs you list will not affect an IPv4 only shop at all.

This simply isn’t true.

Owen

Re: The great Netflix vpn debacle!

[Owen DeLong via NANOG]

In general, my experience with IP Geolocation has been that it’s slightly worse 
than a bad idea, yet that ship has sailed and like Windows, there are way too 
many entrenched applications using it for logic to ever prevail.

I believe Amazon runs their own detection service for this and IIRC, they do 
sell it. I forget the name under which it is marked, but it may well be that 
they are the common denominator culprit for all 5 you show there.

The good news is if you can get any one of them to fix it, it will likely 
resolve them all.

Owen


> On Aug 31, 2021, at 13:36 , Bryan Holloway  wrote:
> 
> Thanks, Owen ... good point.
> 
> Now hearing reports for these same prefixes with Disney+ too.
> 
> So the common denominators are:
> 
> HBO
> Hulu
> Netflix
> Amazon Prime
> Disney+
> 
> ... there has _got_ to be some new-fangled DB somewhere. This all started in 
> the last month or so.
> 
> All of our RR objects, whois, DNS is solid ... dehr?
> 
> Fun times.
> 
> 
> On 8/31/21 9:16 PM, Owen DeLong wrote:
> 
> [snip]
> 
>> Geolocate and VPN or Not are often kind of tied to the same kinds of 
>> reporting services and it may well be that whatever provider HBO is using 
>> for one is also being used for the other.
>> Owen

Re: IPv6 woes - RFC

[Owen DeLong via NANOG]

> On Sep 19, 2021, at 16:17 , Victor Kuarsingh  wrote:
> 
> Owen,
> 
> 
> On Sat, Sep 18, 2021 at 23:51 Owen DeLong  <mailto:o...@delong.com>> wrote:
>> On Sep 18, 2021, at 12:34 , Victor Kuarsingh > <mailto:vic...@jvknet.com>> wrote:
>> 
>> On Sat, Sep 18, 2021 at 2:39 PM John Levine > <mailto:jo...@iecc.com>> wrote:
>> It appears that Owen DeLong via NANOG > <mailto:o...@delong.com>> said:
>> 
>> 
>> Glad you noted this.  Thinking this was/is purely a hardware cycle problem 
>> related to normal/forced upgrade strategies.  On that point, most hardware I 
>> know of from 2004 in larger networks is long fully depreciated and sweating 
>> assets 15+ years can happen, but I don't personally think this is the 
>> biggest issue.
> 
> It’s certainly not purely hardware, but it also doesn’t require solving the 
> entire problem across the entire backend.
> 
> What is urgently needed is to fix the customer-facing front end so that it 
> speaks both protocols (or at least speaks IPv6).
> 
> This is a great question.  So when we approached this (going back a while 
> now) this is what I thought too.  But I was responsible to solve this end to 
> end.  So just updating front end (CPEs, network routers, DHCP, provisioning, 
> IP address planning, security, peering/transit, staff training, test 
> harnesses/plans, etc) was not sufficient to turn on IPv6. 
> 
> The high cost and time challenge issues were not upgrading backend servers to 
> IPv6, but backend provisioning systems, tools, customer support tools, their 
> training, and related items.  These systems were far more complex and costly 
> to address (especially when considering opportunity cost).   Without all of 
> this in place, we could not actually deploy IPv6 for production use (it’s not 
> just Turing it on, its our ability to operate it down to the person answer 
> the phone, the technician that installs and/or fixes/replaces items in home). 

This sounds like an eyeball environment… Note that my question was in the 
context of the laggard content providers.

Eyeball providers are going to have to do something eventually whether they 
like it or not and I’m a whole lot less worried about a forcing function for 
them.

The major eyeball providers have basically completed this. Hopefully that means 
that the vendors you’re using have been forced to upgrade their code and such 
to accommodate by now.

> Also at that time vendor CPE hardware was not as far along on IPv6 readiness 
> (approx mid-decade 2000s).  Getting reliable code at that time was hard with 
> a lot of brokenness (which also could not go into production until it was 
> reliable).  Perhaps this a non-issue today, but it certainly was not a 
> something that was “ready to go” even 10-15 years.   This (IPv6 readiness in 
> CPE code) was also competing with other priorities often blowing up timelines 
> which meant it had to wait as not releasing code into production on a strict 
> timeline was not an option for business reasons.

Sure, but a lot of that has gotten better in the recent years, largely driven 
by some of the major eyeball ISPs.

> All said and done, we got it completed, but it far most costly than we first 
> thought, and IPv4 costs did not go away after we were completed.  Sure it’s 
> possible to reduce those costs with an aggressive program, but it is not as 
> simple as many think.

Agreed… IPv4 costs for you, as an eyeball provider, can’t really go away until 
you can start doing one or more of the following:
1.  Raising your overall rates and providing a discount to 
IPv6-only customers
2.  Adding a surcharge to your billing for customers still 
requiring IPv4 services
3.  Turning off or reducing availability of IPv4 native services 
and moving more towards IPv4AAS
4.  Turning off IPv4 services outright

All of those basically depend on moving a few key laggard content providers 
forward.

>> As you noted John, its the plethora of software, support systems, tooling, 
>> and most important in many environments - legacy customer management and 
>> provisioning systems that can be the limiting factor.  I recall looking back 
>> when leading IPv6 turn-up, those were the biger problems to solve for.  
>> Often such systems are extremely expensive to touch and working on them 
>> required prioritization against direct revenue generating projects 
>> (opportunity cost) .  Replacing routers was just a money problem.
> 
> Why do those systems have to be updated in order to deliver the service to 
> the customer in both protocols?
> 
> Addressed in above comment.  

Eyeball… Now think about it in the context of a content provider… Especially 

Re: IPv6 woes - RFC

[Owen DeLong via NANOG]

> On Sep 20, 2021, at 05:15 , Masataka Ohta  
> wrote:
> 
> Owen DeLong wrote:
> 
>>> But, on routers, IPv6 costs four times more than IPv4 to look up
>>> routing table with TCAM or Patricia tree.
>>> It is not a problem yet, merely because full routing table of IPv6
>>> is a lot smaller than that of IPv4, which means most small ISPs and
>>> multihomed sites do not support IPv6.
>> Well, it’s a combination. Even with full v6 adoption, the routing
>> table in v6 should be substantially smaller.
> 
> Not at all.
> 
>> Compare AS6939 v4 vs. v6:
> 
> That is not a meaningful comparison.
> 
> As mergers of ASes increases the number of announcements
> and IPv4 addresses were allocated a lot earlier than those
> of IPv6, comparing the current numbers of announcements is
> not meaningful.

Mergers of ASes does not increase announcements in IPv4 nearly as much as 
slow-start
and repeated expanding requests for additional IPv4 space have.

> As a result, size of global routing table will keep
> increasing unless there are other factors to limit it.

Sure, but it’s very clear that the rate of increase for IPv6 appears to be 
roughly 1/8th that of
IPv4, so even if IPv6 was 4x as expensive, the growth rate in cost would still 
be 1/2 that of
IPv4.

> An important factor is that, for IPv4 with globally
> routable /24, the absolute upper limit is merely 16M,
> to be looked up by a single memory access of conventional
> SRAM without needing TCAM. OTOH, IPv6 is hopeless.

The reality is that IPv4 will never be completely disaggregated into /24s and 
IPv6 will never
be completely disaggregated into /48s, so this is actually meaningless and not 
predictive
in any way.

> Another favorite factor for IPv4 is that, though most of
> routing table entries are generated from small entities
> having a /24 assuming NAT, if such entities are merged,
> renumbering is not so much a pain and they are motivated
> to rely on a single /24 and sell others. OTOH, there is
> no such motivation for IPv6.

There is no need for such motivation in IPv6 and better yet, since the two 
organizations
have fully globally unique addresses deployed throughout their network, there’s 
no risk
of collisions in RFC-1918 space necessitating large renumbering projects to 
merge the
networks. Indeed, all you need to do is turn on forwarding between the two 
networks
and you’re basically done.

As such, no, that’s an advantage that clearly goes to IPv6, not IPv4.

> 
>> v4 is so thoroughly fragmented and v6 is a lot less likely to become
>> so.
> 
> It is true that fragmentation is a problem. However, it merely
> means that IPv6 address space will also be fragmented and that
> IPv4 can but IPv6 can't be deployed at full scale,

Why would IPv6 become fragmented? When a provider the size of HE can
easily get a /24 from ARIN, what need is there for fragmentation. Sure, they
started with a /32 and they’re keeping that, but the equivalent growth in IPv4
would have resulted in a /20 + /19 + /18 + /17 + /16 + /15 + /14 + /13 and 
likely
an additional /12 eventually. So you get 7-8 prefixes for the same factor of 
growth
as 2 prefixes in IPv4.

It simply doesn’t make sense to claim that fragmentation in v6 will be nearly 
as bad
as it is in v4 because we don’t have the problems of slow start and we’re no 
longer
trying to balance scarcity against aggregation.

Owen

Re: IPv6 woes - RFC

[Owen DeLong via NANOG]

> On Sep 20, 2021, at 06:48 , Brian Turnbow via NANOG  wrote:
> 
> Hi,
> 
>>> v4 is so thoroughly fragmented and v6 is a lot less likely to become
>>> so.
>> 
>> It is true that fragmentation is a problem. However, it merely means that 
>> IPv6
>> address space will also be fragmented and that
>> IPv4 can but IPv6 can't be deployed at full scale,
> 
> Just this week We had our first customer asking if we can setup BGP to route 
> the /48 they received from the headquarters in the states.
> They are asking us to provide a few v4 addresses , but to use their own v6 
> block.
> Yes they are a large conglomerate with their own AS and a large v6 
> allocation, so not a common customer, but they have hundreds of offices 
> everywhere in the world where they are doing this... 
> I can just see the Cxx presenting their solution at some event and it 
> becoming the new thing to do
> What you are still using your providers addresses? You must be crazy... We 
> assign our own it's much better...
> A couple hundred corporations like this and the v6 table would surpass v4...

In such a case, I’m not convinced that’s a bad thing.

Owen

Re: IRR Upstream\Downstream

[Owen DeLong via NANOG]

Generally, you’ll need an export and import policy for each peer AS.

Export should describe what you send to them.
Import should describe what you will accept from them.

In the case of upstreams, that’s usually “to X export MYAS[+customer_AS list]” 
and “from X import ANY”.

In the case of downstream customers, that’s usually “to Y export ANY” and “from 
Y import Y”.

Obviously, if your customer has downstream ASs, that import policy will expand.

Owen


> On Sep 20, 2021, at 17:06 , Mike Hammett  wrote:
> 
> I'm trying to firm up my grasp of how I define my neighbor ASes in my IRR 
> entries.
> 
> https://bgp.he.net/AS40764#_irr 
> 
> In my aut-num, I've defined my two upstreams (Intercarrier and Cogent). I've 
> used their AS-Set or just their AS and used that in the export lines.
> 
> I'd assume I'd do the reverse in the import fields for any downstream 
> customers.
> 
> I realized after looking at this that I need to add an export to IX and other 
> peering connections.
> 
> What else do I need to change?
> 
> 
> 
> 
> Yes, I realized that I just asked NANOG to criticize me. Hopefully, I get 
> more help than flames.  ;-)
> 
> 
> 
> -
> Mike Hammett
> Intelligent Computing Solutions
> http://www.ics-il.com 
> 
> Midwest-IX
> http://www.midwest-ix.com 

Re: IPv6 woes - RFC

[Owen DeLong via NANOG]

> On Sep 22, 2021, at 07:47 , Masataka Ohta  
> wrote:
> 
> Owen DeLong wrote:
> 
>>> As mergers of ASes increases the number of announcements and IPv4
>>> addresses were allocated a lot earlier than those of IPv6,
>>> comparing the current numbers of announcements is not meaningful.
>> Mergers of ASes does not increase announcements in IPv4 nearly as
>> much as slow-start and repeated expanding requests for additional
>> IPv4 space have.
> 
> That *was* a factor, when increased number of subscribers
> meant more free addresses.

It’s still a factor as many providers are purchasing addresses rather than 
deploy CGN
because they don’t want the expensive phone calls CGN causes.

> Today, as /24 can afford hundreds of thousands of subscribers
> by NAT, only very large retail ISPs need more than one
> announcement for IPv4.

I fail to grasp this desire to move the majority of users from second class 
citizens of the
network to third class all in the interests of forestalling the inevitable.

> 
>>> As a result, size of global routing table will keep increasing
>>> unless there are other factors to limit it.
>> Sure, but it’s very clear that the rate of increase for IPv6 appears
>> to be roughly 1/8th that of IPv4,
> 
> It merely means IPv6 is not deployed at all by small ISPs
> and multihomed sites.

Not true. Judging by the number of /48s in the table, IPv6 is relatively
widely deployed by multi homed end sites and judging by the number
of /32 to /40 prefixes, also widely deployed by small-iso ISPs.

> 
> > The reality is that IPv4 will never be completely disaggregated into
> > /24s
> 
> You are so optimistic.

Yes, I’ll be surprised if (e.g. Apple, HP) part out their /8s in to /24s.

I’ll be surprised if a bunch of large organizations fully part out
their /16s and such.

I doubt any major eyeball ISPs will be significantly disbursing or
disaggregating any of their large blocks any time soon.

I suppose you can call that optimism. I call it realism.

Frankly, the faster IPv4 fully fragments, the better because that only
serves to make continuing to carry it all the more expensive, further
making the case for IPv6.

> 
> > and IPv6 will never be completely disaggregated into /48s, so
> > this is actually meaningless and not predictive in any way.
> 
> That IPv6 will be disaggregated into /40 or even /32 is disastrous.

Which it won’t.

It’s unlikely we will fully deploy 2000::/3 in the lifetime of anyone
on this list today.

>> There is no need for such motivation in IPv6 and better yet,
> 
> Then, in a long run, IPv6 will be disaggregated into /32 or /40.

Not likely… Too many providers and large organizations getting
/20s and /24s for that to happen.

>> since
>> the two organizations have fully globally unique addresses deployed
>> throughout their network, there's no risk of collisions in RFC-1918
>> space necessitating large renumbering projects to merge the networks.
> 
> You fully misunderstand why NAT is so popular today defeating IPv6.

Maybe… I certainly don’t understand why it is popular. It’s simply awful.

> Even if two organizations are merged, sites of the organizations
> are, in general, not merged.

Seems rather pointless and counterproductive.

> As private address space behind NAT is used by each site
> independently, there is no renumbering occur for the private
> addresses.

Well, as GUA would be globally unique to each site, there would be
a full ability to merge the sites _AND_ no renumbering cost.

Can you explain any way in which NAT is somehow better?

Owen

Re: DNS & IP address management

[Owen DeLong via NANOG]

Many organizations will use their in-addr.arpa zone(s) as an alternative form 
of poor-man’s IPAM.

It looks like you’ve come across some such organizations.

Likely those are simply the free (unassigned) addresses within the 
organization. Likely there are other similar host names in other /24s in the 
same organization if they have more than a /24 of total address space.

OTOH, organizations which do this tend to be relatively small as it doesn’t 
scale well to multiple administrators managing the same free pool.

Owen


> On Sep 22, 2021, at 07:12 , Joel Sommers  wrote:
> 
> Hello all -
> 
> I am a researcher at Colgate University, working with colleagues at the 
> University of Wisconsin and Boston University on studying aspects of the DNS.
> 
> We're wondering if anyone here would be willing to share some insight into an 
> apparent IP address management practice we have observed that is evident 
> through the DNS.  In particular, we've seen a number of organizations that 
> have a fairly large number of IPv4 addresses (typically all within the same 
> /24 aggregate or similar) all associated with a single FQDN, where the name 
> is typically something like "reserved.52net.example.tld".  Besides the common 
> "reserved" keyword in the FQDN, we also see names like 
> "not-in-use.example.tld", again with quite a few addresses all mapped to that 
> one name.  The naming appears to suggest that this is an on-the-cheap IP 
> address management practice, but we are wondering if there are other 
> operational reasons that might be behind what we observe.
> 
> Thank you for any insights you have -- please feel free to respond off-list.
> 
> Regards,
> Joel Sommers

Re: IPv6 woes - RFC

[Owen DeLong via NANOG]

> There are real issues with dual-stack, as this thread started out with.
> I don't think there is a need neither to invent IPv6 problems, nor to
> promote IPv6 advantages.  What we need is a way out of dual-stack-hell.

I don’t disagree, but a reversion to IPv4-only certainly won’t do it.

I think the only way out is through. Unfortunately, the IPv6 resistant forces
are making that hard for everyone else.

Owen

Re: IPv6 woes - RFC

[Owen DeLong via NANOG]

> On Sep 23, 2021, at 12:50 , Brian Johnson  wrote:
> 
> Side question on this thread…
> 
> Is it everyones current expectation that if a provider were to switch to IPv6 
> and drop IPv4 that the customers would all be just fine with that? I believe 
> that there are several applications used by some of the the loudest customers 
> (typically gamers and network gurus), not to mention some business 
> applications that would break or be sub-optimal at best. I see CGN as the 
> band aid to this issue, not the cure to the problem.

Today? no.

At some point when a relatively small number of remaining laggards among major 
content providers move forward? Yes.

Do you really think that those applications/vendors wouldn’t move quickly if a 
couple of major eyeball providers announced “Effective X date”, we’re going to 
start offering a $X/month discount to any customer(s) who are willing to stop 
using IPv4.

You an only cover an arterial bleed with a band-aid for so long before it 
becomes silly, septic even. If you’re wondering how quick that point is coming 
up, I suggest you check your mirrors.

Owen

> 
> Discuss…?
> 
> - Brian
> 
>> On Sep 23, 2021, at 10:46 AM, Owen DeLong via NANOG  wrote:
>> 
>>> There are real issues with dual-stack, as this thread started out with.
>>> I don't think there is a need neither to invent IPv6 problems, nor to
>>> promote IPv6 advantages.  What we need is a way out of dual-stack-hell.
>> 
>> I don’t disagree, but a reversion to IPv4-only certainly won’t do it.
>> 
>> I think the only way out is through. Unfortunately, the IPv6 resistant forces
>> are making that hard for everyone else.
>> 
>> Owen
>> 
> 

Re: IPv6 woes - RFC

[Owen DeLong via NANOG]

> On Sep 23, 2021, at 13:26 , Joe Maimon  wrote:
> 
> 
> 
> Owen DeLong via NANOG wrote:
>>> There are real issues with dual-stack, as this thread started out with.
>>> I don't think there is a need neither to invent IPv6 problems, nor to
>>> promote IPv6 advantages.  What we need is a way out of dual-stack-hell.
>> I don’t disagree, but a reversion to IPv4-only certainly won’t do it.
> 
> For everyone who does have enough IPv4 addresses, it does. This is the 
> problem in a nutshell. If that starts trending, IPv6 is done

This is virtually no-one with any growth. That’s why Azure, AWS, and Google 
have been snapping up every large prefix that comes on
the market as fast as they can. I don’t see how this can possibly trend long 
enough to matter before it hits that brick wall.
.
>> I think the only way out is through.
> 
> I hope not, both for IPv6 sake and for the network users. We dont know how 
> much longer the goal will take, there is materializing a real possibility we 
> will never quite reach it, and the potholes on the way are pretty rough.

By “the only way out is through” I meant that the only way we can get back to 
anything resembling mono-stack is, in fact, to complete the transition to IPv6.

> And as the trip winds on, the landscape is changing, not necessarily for the 
> better.

The IPv4 landscape will continue to get worse and worse. It cannot possibly get 
better, there just aren’t enough addresses for that.

> One more "any decade now" and another IPv4 replacement/extension might just 
> happen on the scene and catch on, rendering IPv6 the most wasteful global 
> technical debacle to date.

If that’s what it takes to move forward with a protocol that has enough 
addresses, then so be it. I’m not attached to IPv6 particularly, but I 
recognize that IPv4 can’t keep up. As such, IPv6 is just the best current 
candidate. If someone offers a better choice, I’m all for it.

>>  Unfortunately, the IPv6 resistant forces
>> are making that hard for everyone else.
>> 
>> Owen
> 
> You say that as if it was a surprise, when it should not have been, and you 
> say that as if something can be done about it, which we should know by now 
> cannot be the primary focus, since it cannot be done in any timely fashion. 
> If at all.

It’s not a surprise, but it is a tragedy.

There are things that can be done about it, but nobody currently wants to do 
them.

> Its time to throw mud on the wall and see what sticks. Dual stack and wait is 
> an ongoing failure slouching to disaster.

IPv4 is an ongoing failure slouching to disaster, but the IPv6-resistant among 
us remain in denial about that.

At some point, we are going to have to make a choice about how much longer we 
want to keep letting them hold us back. It will not be an easy choice, it will 
not be convenient, and it will not be simple.

The question is how much more pain an dhow much longer will it take before the 
choice becomes less difficult than the wait?

Owen

Re: IPv6 woes - RFC

[Owen DeLong via NANOG]

> On Sep 23, 2021, at 18:48 , Brian Johnson  wrote:
> 
> 
> 
>> On Sep 23, 2021, at 6:49 PM, Owen DeLong  wrote:
>> 
>> 
>> 
>>> On Sep 23, 2021, at 12:50 , Brian Johnson  wrote:
>>> 
>>> Side question on this thread…
>>> 
>>> Is it everyones current expectation that if a provider were to switch to 
>>> IPv6 and drop IPv4 that the customers would all be just fine with that? I 
>>> believe that there are several applications used by some of the the loudest 
>>> customers (typically gamers and network gurus), not to mention some 
>>> business applications that would break or be sub-optimal at best. I see CGN 
>>> as the band aid to this issue, not the cure to the problem.
>> 
>> Today? no.
>> 
>> At some point when a relatively small number of remaining laggards among 
>> major content providers move forward? Yes.
> 
> So do we just bleed out in the mean time?

Well, you can turn off IPv4 on your network whenever you choose to do so.

Unfortunately, I suspect you’re in the same boat I am there, yes, continuing to 
bleed until the laggards on the content side get their acts together.

>> Do you really think that those applications/vendors wouldn’t move quickly if 
>> a couple of major eyeball providers announced “Effective X date”, we’re 
>> going to start offering a $X/month discount to any customer(s) who are 
>> willing to stop using IPv4.
> 
> I’d be happy to suggest this to my clients, but it’s not a real thing yet. 
> Plus, the average human (even the average CSR at a small regional provider 
> network) has no idea what this means.

Yeah, it doesn’t mean anything there. For it to mean something, it would have 
to be somebody like Comcast, Cox, etc. and they’d have to put it like 2 years 
out, but make a big point of it with the content providers.

Another thing they could do if so inclined (the really big eyeball providers) 
is they could start doing settlement free IPv6-only PNIs for content providers.

>> You an only cover an arterial bleed with a band-aid for so long before it 
>> becomes silly, septic even. If you’re wondering how quick that point is 
>> coming up, I suggest you check your mirrors.
> 
> Triage suggests that you assist in succession of the current bleeding before 
> being concerned about the next time you are cut. I have BGN deployments that 
> have been in place for 4+ years with little customer knowledge. It has 
> allowed clients to avoid the IPv4 market issues, and in some instances, 
> become a source for others to help compensate for the initial CGN expense.

I hear you. I’m not sure there’s a viable alternative, but in my experience, 
CGN pisses off online gamers something fierce and if you’re an eyeball ISP, I 
don’t envy you the phone calls that’s going to create, especially as games get 
more and more network-oriented.

Sony already categorizes NAT into various categories and basically when it 
detects CGN it can’t easily penetrate or circumvent, it tells you to call your 
ISP and complain.

> I totally agree with you in spirit, but I am working on the problem of now, 
> not the problem of some point in the future. The cost of CGN is becoming less 
> expensive than IPv4 space acquisition. I wish this weren’t true.

Yeah, but it’s far from zero and that’s more because IPv4 is getting more 
expensive than because CGN is getting cheaper.

There’s only so far you can go with CGN before the user experience turns 
universally bad. It turns bad for a lot of customers well before that point.

I don’t envy you.

Owen

> 
>> 
>> Owen
>> 
>>> 
>>> Discuss…?
>>> 
>>> - Brian
>>> 
>>>> On Sep 23, 2021, at 10:46 AM, Owen DeLong via NANOG  
>>>> wrote:
>>>> 
>>>>> There are real issues with dual-stack, as this thread started out with.
>>>>> I don't think there is a need neither to invent IPv6 problems, nor to
>>>>> promote IPv6 advantages.  What we need is a way out of dual-stack-hell.
>>>> 
>>>> I don’t disagree, but a reversion to IPv4-only certainly won’t do it.
>>>> 
>>>> I think the only way out is through. Unfortunately, the IPv6 resistant 
>>>> forces
>>>> are making that hard for everyone else.
>>>> 
>>>> Owen
>>>> 
>>> 
>> 
> 

Re: IPv6 woes - RFC

[Owen DeLong via NANOG]

> On Sep 24, 2021, at 2:01 AM, b...@uu3.net wrote:
> 
> Oh yeah, it would be very funny if this will really happen (new protocol).
> Im not happy with IPv6, and it seems many others too.
> 
> This is short list how my ideal IPv6 proto looks like:
> - 64bit address space
>  more is not always better

Perhaps, but the benefits of a 128 bit address space with a convenient
near universal network/host boundary has benefits. What would be the
perceived benefit of 64-bit addressing over 128?

> - loopback 0:0:0:1/48

Why dedicate a /48 to loopback?

> - soft LL 0:0:1-:0/32 (Link Local)

Having trouble understanding that expression… Wouldn’t it overlap loopback, 
since
0:0::/32 and 0:0:0::/48 would be overlapping prefixes?

> - RFC1918 address space 0:1-:0:0/16

Why repeat this mistake?

> - keep ARPs, ND wasnt great idea after all?

I don’t see a significant difference (pro or con) to ND vs. ARP.

> - NAT support (because its everywhere these days)

That’s a tragedy of IPv4, I don’t see a benefit to inflicting it on a new 
protocol.

> - IPv6 -> IPv4 interop (oneway)
>  we can put customers on IPv6, while keeping services dualstack

That requires the services to be dual stack which is kind of the problem we have
with IPv6 today… Enough services that matter aren’t dual stack.

> - correct DHCP support (SLAAC wasnt great idea after all?)
>  I think its already in IPv6, but was an issue at the begining

Depends on your definition of “correct”. I disagree about SLAAC not being a 
great
idea. It might not fit every need, but it’s certainly a low-overhead highly 
useful
mechanism in a lot of deployments.

> If there are some weird requirements from others, put them into layer up.
> L3 needs to be simple (KISS concept), so its easy to implement and less
> prone to bugs.
> 
> And that IPv6 I would love to see and addapt right away :)

Well.. Present your working prototype on at least two different systems. ;-)

Owen

> 
> 
> -- Original message --
> 
> From: Joe Maimon 
> To: Owen DeLong , Bjrn Mork 
> Cc: nanog@nanog.org
> Subject: Re: IPv6 woes - RFC
> Date: Thu, 23 Sep 2021 16:26:17 -0400
> 
> 
> 
> Owen DeLong via NANOG wrote:
>>> There are real issues with dual-stack, as this thread started out with.
>>> I don't think there is a need neither to invent IPv6 problems, nor to
>>> promote IPv6 advantages.  What we need is a way out of dual-stack-hell.
>> I dont disagree, but a reversion to IPv4-only certainly wont do it.
> 
> For everyone who does have enough IPv4 addresses, it does. This is the problem
> in a nutshell. If that starts trending, IPv6 is done.
> 
>> I think the only way out is through.
> 
> I hope not, both for IPv6 sake and for the network users. We dont know how 
> much
> longer the goal will take, there is materializing a real possibility we will
> never quite reach it, and the potholes on the way are pretty rough.
> 
> And as the trip winds on, the landscape is changing, not necessarily for the
> better.
> 
> One more "any decade now" and another IPv4 replacement/extension might just
> happen on the scene and catch on, rendering IPv6 the most wasteful global
> technical debacle to date.
> 
> 
>>  Unfortunately, the IPv6 resistant forces
>> are making that hard for everyone else.
>> 
>> Owen
> 
> You say that as if it was a surprise, when it should not have been, and you 
> say
> that as if something can be done about it, which we should know by now cannot 
> be
> the primary focus, since it cannot be done in any timely fashion. If at all.
> 
> Its time to throw mud on the wall and see what sticks. Dual stack and wait is 
> an
> ongoing failure slouching to disaster.
> 
> Joe
> 
> 
> 
> 

Re: IPv6 woes - RFC

[Owen DeLong via NANOG]

> On Sep 24, 2021, at 9:56 AM, Joe Maimon  wrote:
> 
> 
> 
> Owen DeLong wrote:
>> 
>>> On Sep 23, 2021, at 13:26 , Joe Maimon  wrote:
>>> 
>>> 
>>> I hope not, both for IPv6 sake and for the network users. We dont know how 
>>> much longer the goal will take, there is materializing a real possibility 
>>> we will never quite reach it, and the potholes on the way are pretty rough.
>> By “the only way out is through” I meant that the only way we can get back 
>> to anything resembling mono-stack is, in fact, to complete the transition to 
>> IPv6.
> 
> The question is how? Waiting for everyone or nearly everyone to dual stack, 
> the current strategy, is awful. Like pulling gum off a shoe.

Agreed, so the question boils down to what can be done to motivate the laggard 
content providers to get off the dime.

>>> And as the trip winds on, the landscape is changing, not necessarily for 
>>> the better.
>> The IPv4 landscape will continue to get worse and worse. It cannot possibly 
>> get better, there just aren’t enough addresses for that.
> 
> I was referring to the more general network landscape, the governance system, 
> the end of p2p, balkanization, etc, all trends and shifts that become more 
> likely and entrenched the longer IPv6 lags and the scarcer IPv4 becomes.
> 
>> 
>>> One more "any decade now" and another IPv4 replacement/extension might just 
>>> happen on the scene and catch on, rendering IPv6 the most wasteful global 
>>> technical debacle to date.
>> If that’s what it takes to move forward with a protocol that has enough 
>> addresses, then so be it. I’m not attached to IPv6 particularly, but I 
>> recognize that IPv4 can’t keep up. As such, IPv6 is just the best current 
>> candidate. If someone offers a better choice, I’m all for it.
> 
> Whose to say it would be a proper p2p system? I know you believe strongly in 
> that and want it fully restored, at least on the protocol level.

There are so many potential useful things we could do with a restored e2e 
system that are simply not proactical today that yes, I consider that vital.

For one thing, I’m really tired of vendor cloud locking just because products 
need rendezvous hosts with public addresses.

  Unfortunately, the IPv6 resistant forces
 are making that hard for everyone else.
 
 Owen
>>> You say that as if it was a surprise, when it should not have been, and you 
>>> say that as if something can be done about it, which we should know by now 
>>> cannot be the primary focus, since it cannot be done in any timely fashion. 
>>> If at all.
>> It’s not a surprise, but it is a tragedy.
>> 
>> There are things that can be done about it, but nobody currently wants to do 
>> them.
> 
> So lets make the conversation revolve around what can be done to actually 
> advance IPv6, and what we should know by now is that convincing or coercing 
> deployment with the current state of affairs does not have enough horsepower 
> to get IPv6 anywhere far anytime soon.

I’m open to alternatives if you have any to offer.

>>> Its time to throw mud on the wall and see what sticks. Dual stack and wait 
>>> is an ongoing failure slouching to disaster.
>> IPv4 is an ongoing failure slouching to disaster, but the IPv6-resistant 
>> among us remain in denial about that.
> 
> Who is this "us"? Anybody even discussing IPv6 in a public forum is well 
> ahead of the curve. Unfortunately. All early adopters. Real Early.

Everybody using the internet, but more importantly, the content providers that 
are resisting IPv6 deployment on their content are probably the biggest problem 
at this time.

>> At some point, we are going to have to make a choice about how much longer 
>> we want to keep letting them hold us back. It will not be an easy choice, it 
>> will not be convenient, and it will not be simple.
>> 
>> The question is how much more pain an dhow much longer will it take before 
>> the choice becomes less difficult than the wait?
>> 
>> Owen
>> 
> Exactly what does this choice look like? Turn off IPv4 when its fully 
> functional? Only the have-nots may make the choice not to deploy IPv4 
> sometime in the future, and for them, its not going to be a real choice.

IPv4 hasn’t been fully functional for more than a decade. At some point, the 
pain of continuing to wait for the laggards will become sufficient that those 
who have been running dual-stack will simply turn off IPv4 and leave the 
laggards behind. It might tragically not happen in my lifetime, but it has to 
happen at some point.

Owen