Re: Cogent-TATA peering dispute?

[Joe via NANOG]

Perhaps Cogent is permitted to operate a root server's infrastructure as an 
on-going, real-time disaster scenario - demonstrating what happens to critical 
DNS infrastructure when there's considerable routing loss.

Not much, it seems. 

-joe

On 5/17/2024 at 5:06 PM, "William Herrin"  wrote:
>
>I don't understand why Cogent is allowed to operate one of the root
>servers. Doesn't ICANN do any kind of technical background check on
>companies when letting the contract?

Re: constant FEC errors juniper mpc10e 400g

[Joe Antkowiak]

Corrected FEC errors are pretty normal for 400G FR4

On Wednesday, April 17th, 2024 at 3:36 PM, Aaron Gould  wrote:

> We recently added MPC10E-15C-MRATE cards to our MX960's to upgrade our core 
> to 400g.  During initial testing of the 400g interface (400GBASE-FR4), I see 
> constant FEC errors.  FEC is new to me.  Anyone know why this is occurring?  
> Shown below, is an interface with no traffic, but seeing constant FEC errors. 
>  This is (2) MX960's cabled directly, no dwdm or anything between them... 
> just a fiber patch cable.
>
> {master}
> me@mx960> clear interfaces statistics et-7/1/4
>
> {master}
> me@mx960> show interfaces et-7/1/4 | grep rror | refresh 2
> ---(refreshed at 2024-04-17 14:18:53 CDT)---
>   Link-level type: Ethernet, MTU: 1514, MRU: 1522, Speed: 400Gbps, BPDU 
> Error: None, Loop Detect PDU Error: None, Loopback: Disabled, Source 
> filtering: Disabled,
> Bit errors 0
> Errored blocks 0
>   Ethernet FEC statistics  Errors
> FEC Corrected Errors0
> FEC Uncorrected Errors  0
> FEC Corrected Errors Rate   0
> FEC Uncorrected Errors Rate 0
> ---(refreshed at 2024-04-17 14:18:55 CDT)---
>   Link-level type: Ethernet, MTU: 1514, MRU: 1522, Speed: 400Gbps, BPDU 
> Error: None, Loop Detect PDU Error: None, Loopback: Disabled, Source 
> filtering: Disabled,
> Bit errors 0
> Errored blocks 0
>   Ethernet FEC statistics  Errors
> FEC Corrected Errors 4302
> FEC Uncorrected Errors  0
> FEC Corrected Errors Rate   8
> FEC Uncorrected Errors Rate 0
> ---(refreshed at 2024-04-17 14:18:57 CDT)---
>   Link-level type: Ethernet, MTU: 1514, MRU: 1522, Speed: 400Gbps, BPDU 
> Error: None, Loop Detect PDU Error: None, Loopback: Disabled, Source 
> filtering: Disabled,
> Bit errors 0
> Errored blocks 0
>   Ethernet FEC statistics  Errors
> FEC Corrected Errors 8796
> FEC Uncorrected Errors  0
> FEC Corrected Errors Rate 146
> FEC Uncorrected Errors Rate 0
> ---(refreshed at 2024-04-17 14:18:59 CDT)---
>   Link-level type: Ethernet, MTU: 1514, MRU: 1522, Speed: 400Gbps, BPDU 
> Error: None, Loop Detect PDU Error: None, Loopback: Disabled, Source 
> filtering: Disabled,
> Bit errors 0
> Errored blocks 0
>   Ethernet FEC statistics  Errors
> FEC Corrected Errors15582
> FEC Uncorrected Errors  0
> FEC Corrected Errors Rate 111
> FEC Uncorrected Errors Rate 0
> ---(refreshed at 2024-04-17 14:19:01 CDT)---
>   Link-level type: Ethernet, MTU: 1514, MRU: 1522, Speed: 400Gbps, BPDU 
> Error: None, Loop Detect PDU Error: None, Loopback: Disabled, Source 
> filtering: Disabled,
> Bit errors 0
> Errored blocks 0
>   Ethernet FEC statistics  Errors
> FEC Corrected Errors20342
> FEC Uncorrected Errors  0
> FEC Corrected Errors Rate 256
> FEC Uncorrected Errors Rate 0
>
> {master}
> me@mx960> show interfaces et-7/1/4 | grep "put rate"
>   Input rate : 0 bps (0 pps)
>   Output rate: 0 bps (0 pps)
>
> {master}
> me@mx960> show interfaces et-7/1/4
> Physical interface: et-7/1/4, Enabled, Physical link is Up
>   Interface index: 226, SNMP ifIndex: 800
>   Link-level type: Ethernet, MTU: 1514, MRU: 1522, Speed: 400Gbps, BPDU 
> Error: None, Loop Detect PDU Error: None, Loopback: Disabled, Source 
> filtering: Disabled,
>   Flow control: Enabled
>   Pad to minimum frame size: Disabled
>   Device flags   : Present Running
>   Interface flags: SNMP-Traps Internal: 0x4000
>   Link flags : None
>   CoS queues : 8 supported, 8 maximum usable queues
>   Schedulers : 0
>   Last flapped   : 2024-04-17 13:55:28 CDT (00:36:19 ago)
>   Input rate : 0 bps (0 pps)
>   Output rate: 0 bps (0 pps)
>   Active alarms  : None
>   Active defects : None
>   PCS statistics  Seconds
> Bit errors 0
> Errored blocks 0
>   Ethernet FEC Mode  : FEC119
>   Ethernet FEC statistics  Errors
> FEC Corrected Errors   801787
> FEC Uncorrected Errors  0
> FEC Corrected Errors Rate2054
> FEC Uncorrected Errors Rate 0
>   Link Degrade :
> Link Monitoring   :  Disable
>   Interface transmit statistics: Disabled
>
>   Logical interface et-7/1/4.0 (Index 420) (SNMP ifIndex 815)
> Flags: Up SNMP-Traps 0x4004000 Encapsulation: 

network simulator for service provider

[aun Joe]

  is there anysi  network simulator for carrier networks ?

   well,   from 2023 to 2024 there happes so many carrier network outage caused 
by network operation.

   to my limited knowledge ,   SP guru  from riverbed could simulate carrier 
network. but  I just checked
 riverbed website,  SP guru  stop updating in 2014.

 joe

Re: SRI's Dan Lynch dies

[Joe Klein]

Wow, I have not spoken to Dan Lynch in 8 years. He was brilliant!

Raise glass for Dan!

Joe Klein

"inveniet viam, aut faciet" --- Seneca's Hercules Furens (Act II, Scene 1)
"*I skate to where the puck is going to be, not to where it has been."
-- *Wayne
Gretzky
"I never lose. I either win or learn" - Nelson Mandela


On Mon, Apr 1, 2024 at 6:06 PM joe hess  wrote:

> Thanks for sharing this, too.Lynch was really underrated for what he
> did.  He basically made certain that people made their dreams work
> together, or at least that is what I saw.
>
> Too, when you asked any questions in the Internet’s early days, all the
> answers eventually seemed to wind back to Dan.
>
> I only knew him by remote interaction, and I have often felt cheated that
> I didn’t get to know him better.
>
>
>
> > On Apr 1, 2024, at 11:12 AM, Sajit Bhaskaran 
> wrote:
> >
> > RIP Dan Lynch. It is worth adding that he was also the founder of the
> Interop shows in the mid 80s which achieved a great deal in terms of
> advancing TCP/IP adoption, and inter-operability testing was a big deal
> back then when the future of TCP/IP was also not at all certain, as it was
> in competition then with the ISO/OSI protocol suite. Dan's efforts and
> passion as an entrepreneur created an exponentially growing community of
> users and vendors all over the world that made the TCP/IP protocol suite
> the de facto standard. Thanks very much for sharing. Today we take the
> Internet for granted. It could have been very different.
> >
> > On 3/31/2024 12:19 PM, Jay R. Ashworth wrote:
> >> >From Lauren Weinstein @ PRIVACY Digest:
> >>
> >> """
> >> Dan Lynch, one of the key people involved in building the Internet and
> >> ARPANET before it, has died.
> >>
> >> Dan was director of computing facilities at SRI International, where
> >> ARPANET node #2 was located and he worked on development of TCP/IP, and
> >> where the first packets were received from our site at UCLA node #1 to
> >> SRI, and later at USC-ISI led the team that made the transition from the
> >> original ARPANET NCP protocols to TCP/IP for the Internet. And much
> more.
> >>
> >> Peace. -L
> >> """
> >>
> >> He was well written up across the web, but here's a 2021 piece for those
> >> who aren't as familiar with his background:
> >>
> >>
> https://www.internethalloffame.org/2021/04/19/dan-lynchs-love-brilliant-complexity-fuels-early-internet-development-growth/
> >>
> >> And his IHoF induction speech:
> >>
> >> http://opentranscripts.org/transcript/dan-lynch-ihof-2019-speech/
> >>
> >> I would note his age here, as obits usually do, but it seems unusually
> difficult
> >> to learn.
> >>
> >> Happy landings, Mr Lynch.
> >>
> >> Cheers,
> >> -- jra
>
>

Re: SRI's Dan Lynch dies

[joe hess]

Thanks for sharing this, too.Lynch was really underrated for what he did.  
He basically made certain that people made their dreams work together, or at 
least that is what I saw.

Too, when you asked any questions in the Internet’s early days, all the answers 
eventually seemed to wind back to Dan.   

I only knew him by remote interaction, and I have often felt cheated that I 
didn’t get to know him better.



> On Apr 1, 2024, at 11:12 AM, Sajit Bhaskaran  wrote:
> 
> RIP Dan Lynch. It is worth adding that he was also the founder of the Interop 
> shows in the mid 80s which achieved a great deal in terms of advancing TCP/IP 
> adoption, and inter-operability testing was a big deal back then when the 
> future of TCP/IP was also not at all certain, as it was in competition then 
> with the ISO/OSI protocol suite. Dan's efforts and passion as an entrepreneur 
> created an exponentially growing community of users and vendors all over the 
> world that made the TCP/IP protocol suite the de facto standard. Thanks very 
> much for sharing. Today we take the Internet for granted. It could have been 
> very different.
> 
> On 3/31/2024 12:19 PM, Jay R. Ashworth wrote:
>> >From Lauren Weinstein @ PRIVACY Digest:
>> 
>> """
>> Dan Lynch, one of the key people involved in building the Internet and
>> ARPANET before it, has died.
>> 
>> Dan was director of computing facilities at SRI International, where
>> ARPANET node #2 was located and he worked on development of TCP/IP, and
>> where the first packets were received from our site at UCLA node #1 to
>> SRI, and later at USC-ISI led the team that made the transition from the
>> original ARPANET NCP protocols to TCP/IP for the Internet. And much more.
>> 
>> Peace. -L
>> """
>> 
>> He was well written up across the web, but here's a 2021 piece for those
>> who aren't as familiar with his background:
>> 
>> https://www.internethalloffame.org/2021/04/19/dan-lynchs-love-brilliant-complexity-fuels-early-internet-development-growth/
>> 
>> And his IHoF induction speech:
>> 
>> http://opentranscripts.org/transcript/dan-lynch-ihof-2019-speech/
>> 
>> I would note his age here, as obits usually do, but it seems unusually 
>> difficult
>> to learn.
>> 
>> Happy landings, Mr Lynch.
>> 
>> Cheers,
>> -- jra

Re: Open source Netflow analysis for monitoring AS-to-AS traffic

[Joe Loiacono]

Try FlowViewer http://flowviewer.net

Free, complete, graphical netflow analysis tool.

Developed for NASA. Runs on top of SiLK, a powerful open-source netflow 
capture and analysis tool developed by Carnegie-Mellon for DoD. Supports 
IPFIX, netflow v5, sflow, IPv6. Text reports, graphing and long-term 
tracking via graphs. Automatic storage control capability.


In general, as you probably know, it's amazing what you can get from 
netflow.


Best,

Joe

On 3/26/2024 8:04 PM, Brian Knight via NANOG wrote:

What's presently the most commonly used open source toolset for 
monitoring AS-to-AS traffic?


I want to see with which ASes I am exchanging the most traffic across 
my transits and IX links. I want to look for opportunities to peer so 
I can better sell expansion of peering to upper management.

Our routers are mostly $VENDOR_C_XR so Netflow support is key.

In the past, I've used AS-Stats 
<https://github.com/manuelkasper/AS-Stats> for this purpose. However, 
it is particularly CPU and disk IO intensive. Also, it has not been 
actively maintained since 2017.


InfluxDB wants to sell me 
<https://www.influxdata.com/what-are-netflow-and-sflow/> on Telegraf + 
InfluxDB + Chronograf + Kapacitor, but I can't find any clear guide on 
what hardware I would need for that, never mind how to set up the 
software. It does appear to have an open source option, however.
pmacct seems to be good at gathering Netflow, but doesn't seem to 
analyze data. I don't see any concise howto guides for setting this up 
for my purpose, however.
I'm aware Kentik does this very well, but I have no budget at the 
moment, my testing window is longer than the 30 day trial, and we are 
not prepared to share our Netflow data with a third party.
Elastiflow <https://www.elastiflow.com/> appears to have been open 
source <https://github.com/robcowart/elastiflow?tab=readme-ov-file> at 
one time in the past, but no longer. Since it too appears to be 
hosted, I have the same objections as I do with Kentik above.

On-list and off-list replies are welcome.
Thanks,
-Brian

Re: Why are paper LOAs still used?

[Joe via NANOG]

One thing that I recently read on this mailing list, is that at least in the 
US, a transmitting a fraudulent LOA is a federal crime - wire fraud. [0]

Being able to hopefully charge and convict someone performing fraud is a useful 
deterrent.

-joe

[0] - 
https://pc.nanog.org/static/published/meetings/NANOG77/2108/20191028_Elverson_Your_As_Is_v1.pdf,
 page 13.


On 2/26/2024 at 12:58 PM, "Seth Mattinen via NANOG"  wrote:
>
>Why do companies still insist on, or deploy new systems that rely 
>on 
>paper LOA for IP and ASN resources? How can this be considered 
>more 
>trustworthy than RIR based IRR records?
>
>And I'm not even talking about old companies, I have a situation 
>right 
>now where a VPS provider I'm using will no longer use IRR and only 
>accepts new paper LOAs. In the year 2024. I don't understand how 
>anyone 
>can go backwards like that.
>
>~Seth

Re: RIP Dave Mills

[Joe Hamelin]

The one protocol that keeps us on our toes.

Godspeed, Dr. Dave.

On Sat, Jan 27, 2024 at 7:10 PM Jay Ashworth  wrote:

> The inventor of NTP, in the late 1970s, and recipient of the 2013 IEEE
> Internet Award “for significant leadership and sustained contributions in
> the research, development, standardization, and deployment of quality time
> synchronization capabilities for the Internet”, Dr. David Lennox Mills died
> in Delaware on January 17, at 85.
>
> Rarely have I more wanted to say "perhaps we'll see him again later".
>
> Cheerss,
> -- jra
> --
> Sent from my Android device with K-9 Mail. Please excuse my brevity.
>


-- 
--
Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474

Re: The rise and fall of the 90's telecom bubble

[Joe Hamelin]

Mike asked:  Well, and "better" for what purpose?

Pull string?

--
Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474

Re: [NNagain] The rise and fall of the 90's telecom bubble

[Joe Hamelin]

I started my TCP life (moving from broadcast engineering) back in about
'94ish.  I was in Yakima, WA and took care of the 9 working modems for
Wolfe.net after being on connected.com and teleport.com (Portland, OR).  My
girlfriend  (later my wife), who I met online via the unix talk command got
hired with me by Wolfe and moved to Seattle.  We worked with them for a few
years during the dial-up days and moved on to one of their customers where
we had massive growth and 2.5Gb/s of pipe in 1998 (yes, it was pr0n.) Then
I went to AMZN and got their first netblock after haggling with ARIN at a
BOF at NANOG 19 in Atlanta. See back then, AMZN could only justify a /22
since we were just a website.  Many years later I landed in corporate
aerospace and will likely die here at my keyboard.

Anyway, now when the youngins ask me technical TCP/IP questions I like to
start off with, "Well, back when we were building the Internet..."

On Sun, Nov 12, 2023 at 7:49 AM Dave Taht via Nnagain <
nnag...@lists.bufferbloat.net> wrote:

> Aside from me pinning the start of the bubble closer to 1992 when
> commercial activity was allowed, and M for ISPs at insane valuations
> per subscriber by 1995 (I had co-founded an ISP in 93, but try as I
> might I cannot remember if it peaked at 50 or 60x1 by 1996 (?) and
> crashed by 97 (?)), this was a whacking good read, seems accurate, and
> moves to comparing it across that to the present day AI bubble.
>
> https://www.fabricatedknowledge.com/p/lessons-from-history-the-rise-and
>
> In the end we sold (my ISP, founded 93) icanect for 3 cents on the
> dollar in 99, and I lost my shirt (not for the first time) on it, only
> to move into embedded Linux (Montavista) after the enormous pop
> redhat's IPO had had in 99. The company I was part of slightly prior
> (Mediaplex) went public December 12, 1999 and cracked 100/share, only
> to crash by march, 2000 to half the IPO price (around $7 as I recall),
> wiping out everyone that had not vested yet. I lost my shirt again on
> that and Montavista too and decided I would avoid VCs henceforth.
>
> I am always interested in anecdotal reports of personal events in this
> increasingly murky past, and in trying to fact check the above link.
>
> So much fiber got laid by 2000 that it is often claimed that it was at
> least a decade before it was used up, (the article says only 2.7% was
> in use by 2002) and I have always wondered how much dark, broken,
> inaccessible fiber remains that nobody knows where it even is anymore
> due to many lost databases. I hear horror stories...
>
> The article also focuses solely on the us sector, and I am wondering
> what it looked like worldwide.
>
> I believed in the 90s we were seeing major productivity gains. The
> present expansion of the internet in my mind should not be much
> associated with "productivity gains", as, imho, reducing the general
> population to two thumbs and a 4 inch screen strikes me as an enormous
> step backwards.
>
> (I have a bad habit of cross posting my mails to where older denizens
> of the internet reside, sorry! If you end up posting to one of my
> lists I will add a sender allows filter for you)
> --
> :( My old R campus is up for sale: https://tinyurl.com/yurtlab
> Dave Täht CSO, LibreQos
> ___
> Nnagain mailing list
> nnag...@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/nnagain
>


-- 
--
Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474

Re: 165 Halsey recurring power issues

[Joe Maimon]

Willing to bet that there was slicing on both sides of that conversation 
and this is what I will now refer to as the expected and resulting razor 
burn.


Babak Pasdar wrote:

Thanks James,

At signup we asked for N+1 power, two circuits to different UPS units. 
I think they sliced it thin by connecting us to two battery packs on 
the same UPS. When the UPS controller crashed both battery packs went 
down.  Which now raises the question -- is it reasonable to have to 
specify and expect that two UPS units means that they do not share any 
common points of failure.


Is the UPS the battery or the battery and controller combined?

Babak



On 10/23/23 15:16, James Jun wrote:

On Mon, Oct 23, 2023 at 10:38:09AM -0400, Babak Pasdar wrote:

I wanted to get some feedback as to what is considered standard A/B
power setup when data centers sell redundant power.?? It has always 
been
my understanding that A/B power means individually unique and 
preferably

alternate path connections to disparate UPS units.
Generally speaking, the definition of A/B has become muddied in 
recent decades.  It has almost become an inaccurate marketing term.


Most sane people have the opinion (myself included) that when "A/B" 
power is offered, it is at minimum offererd as 2N UPS (different 
building entrance and MSBs and even physically separate UPS rooms are 
also desired on a true 2N A/B, but may not always be available).  
Some data center operators go even further and architect load 
switching within their distribution, thereby preventing 
single-side/one-leg power outages for customers during most of their 
power maintenance activities


Some data center operators treat "A/B" as convenience for them to 
undertake maintenance and offload uptime responsibilities to their 
own customers, and require them to either undertake their own 
transfer switching and/or dual-cord every equipment, so that they can 
keep taking one side of the power system down for repeated 
maintenance.  This does not scale well for retail colo, as not every 
customer is going to be good at maintaining two PSUs for every single 
piece of equipment.


Some data centers also view "N+1" system deployment at the UPS as an 
acceptable form of A/B protection, as long as customer circuits are 
on different PDUs.


Long story short, whether you're receiving N+1 or 2N or 1N, it's 
important to inquire about how your power circuits will be 
architected and delivered by the data center, and either have that 
codified in the contract or reflected appropriately in SLA offering.  
There is nothing wrong with the data center providing N+1 or 1N 
power, as long as they're transparent about it and that it is what 
you're willing to accept for the right terms. However, simply 
accepting "we are providing you A/B power" or "we've never had 
primary power failure" are not sufficient to meet proper due 
diligence during a site selection process, unless you can accept the 
site outage occurring from time to time, or you're deploying your own 
power plant (i.e. DC power and batteries) to supplant data center's 
own power protection scheme.


James

Re: 165 Halsey recurring power issues

[Joe Maimon]

The building itself got into the action and their goal was to make a top 
notch facility focusing on central patch panel fiber cross connects. 
They started with half of the 9th floor originally called MMR-2 and 
continued with multiple spaces each bigger as it was quite successful. 
No raised floors, properly positioned chillers, ample power, basic but 
standard and roomy cabinets, one time fee per cross connect (plus 
initial cabling and panel setup OTC) and they have been very succesfull 
by all appearances.


Staff reflected their initial goals and I have always interacted well 
with them.


Original mmr where each xcon was actualy pulled space to space was quite 
a sight with multiple cable conduits and trays running from the tops of 
the cabs to the ceiling, all full. New space adopted modern approaches 
and looked it.


Joe

Sean Donelan wrote:

ine tume
165 Halsey (and most of its tenant) data centers is an older facility. 
Data center practices have changed over the decades, and terminlogy 
wasn't standardized until recently.



The biggest FUBAR in telco and data centers is the difference between 
"redundancy" and "diversity."


Redundant A/B power feeds are often multiple cables from the same 
power source.


Diverse A/B power feeds are cables from different backup power sources 
(within limits).  1-utility, 2 battery strings or backup generators. 
Often routed through in same conduits/cable trays. But both may be out 
of service for scheduled maintenance and some kinds of faults.


Add a spare A/B power feed.  Generally a N+1 backup power source and 
some additional power switching capability.


Fault tolerant A/B power.  Everything from utility to rack is diverse 
and redudant (cables, conduit/cable trays, switching equipment and 
backup sources).  Maintenance can be performed on one of the power 
feeds without affecting the other feeds.  Does not include redundant 
utility feed (not redundant substation, utility).


Cost increase 2x, 5x, 10x

I haven't toured 165 Halsey for 10+ years, so I don't know its current 
state.  It has multiple tenant data centers, so some may be better 
than others.



On Mon, 23 Oct 2023, Babak Pasdar wrote:

Hello,

I wanted to get some feedback as to what is considered standard A/B 
power setup when data centers sell redundant power.  It has always 
been my understanding that A/B power means individually unique and 
preferably alternate path connections to disparate UPS units.


A few months ago, 165 Halsey took us down for several hours. They 
claimed that a UPS failed causing this issue.  Our natural reaction 
was that we have A/B redundant power so a failed UPS on the A circuit 
should not take down the cabinet. Joe the facility manager claimed 
that industry standard A/B power means two circuits to the same UPS, 
which makes no sense to me.


They committed to move us to A/B power with redundant circuits to 
disparate UPS units.  However, we had a multi-hour outage again in 
that site this weekend. At first glance it seems to be the same problem.


We have checked with all of our other data center providers who have 
confirmed A/B power is in fact individually unique connections to 
disparate UPS units. 165 Halsey's definition of what constitutes 
redundant power seems unique. Why would anyone pay extra for a second 
connection to the same UPS?  However, I wanted to get feedback to see 
if I am taking crazy pills here 


None-the-less, we have lost all confidence in this facility.

Best Regards,

Babak

Re: Low to Mid Range DWDM Platforms

[Joe Freeman]

I have several of the Smart Optics DCP-M40’s in place. If you are using 
coherent 100G DWDM optics, you can push the M40-ZR’s to 100-120km. The exact 
reach depends, of course, on the quality of the fiber plant in use.


From: NANOG  on behalf of Dave Bell 

Date: Friday, October 6, 2023 at 9:54 AM
To: Mark Tinka 
Cc: nanog@nanog.org 
Subject: Re: Low to Mid Range DWDM Platforms
Smartoptics?

https://smartoptics.com/

Regards,
Dave

On Fri, 6 Oct 2023 at 14:43, Mark Tinka  wrote:


On 10/6/23 15:07, Mike Hammett wrote:

> I've been using various forms of passive WDM for years. I have a couple 
> different projects on my plate that require me to look at the next level of 
> platform.
>
> In some projects, I'll be looking for needing to have someone long distances 
> of glass without any electronics. Some spans could be over 60 miles.
>
> In some projects, I'll need to transport multiple 100-gig waves.
>
> What is the landscape like between basic passive and something like a 30 
> terabit Ciena? I know of multiple vendors in that space, but I like to learn 
> more about what features I need and what features I don't need from somewhere 
> other than the vendor's mouth. Obviously, the most reliability at the least 
> cost as well.

400G-ZR pluggables will get you 400Gbps on a p2p dark fibre over 80km -
100km. So your main cost there will be routers that will support.

The smallest DCI solution from the leading DWDM vendors is likely to be
your cheapest option. Alternatively, if you are willing to look at the
open market, you can find gear based on older CMOS (40nm, for example),
which will now be EoL for any large scale optical network, but cost next
to nothing for a start-up with considerable capacity value.

There is a DWDM vendor that showed up on the scene back in 2008 or
thereabouts. They were selling a very cheap, 1U box that had a different
approach to DWDM from other vendors at the time. I, for the life of me,
cannot remember their name - but I do know that Randy introduced them to
me back then. Maybe he can remember :-). Not sure if they are still in
business.

Mark.

Re: U.S. test of national alerts on Oct. 4 at 2:20pm EDT (1820 UTC)

[Joe Klein]

Received it twice on the smartphone. Did not trigger the emergency weather
system, nor impact stream on TV in NCR.

Joe Klein

"inveniet viam, aut faciet" --- Seneca's Hercules Furens (Act II, Scene 1)
"*I skate to where the puck is going to be, not to where it has been."
-- *Wayne
Gretzky
"I never lose. I either win or learn" - Nelson Mandela


On Wed, Oct 4, 2023 at 2:35 PM Ryan A. Krenzischek via NANOG <
nanog@nanog.org> wrote:

> I've only gotten the alert now ...9 times.
>
> Ryan
>

Re: maximum ipv4 bgp prefix length of /24 ?

[Joe Hamelin]

Wasn't it about 1997 or so when we ran into deployed Cisco gear (5500s back
then) running out of memory for BGP routes?  Been there, done that. -Joe

On Thu, Sep 28, 2023 at 7:41 PM Jon Lewis  wrote:

> On Fri, 29 Sep 2023, VOLKAN SALİH wrote:
>
> > I believe, ISPs should also allow ipv4 prefixes with length between
> /25-/27 instead of limiting maximum length to /24..
> >
> > I also believe that RIRs and LIRs should allocate /27s which has 32 IPv4
> address. considering IPv4 world is now mostly NAT'ed, 32 IPv4s are
> sufficient for most of the
> > small and medium sized organizations and also home office workers like
> youtubers, and professional gamers and webmasters!
> >
> > It is because BGP research and experiment networks can not get /24 due
> to high IPv4 prices, but they have to get an IPv4 prefix to learn BGP in
> IPv4 world.
> >
> > What do you think about this?
>
> Not going to happen any time soon (if at all).
>
> #show ip route summary | i Source|---|bgp
> Route SourceNumber Of Routes
> - -
> bgp   925809
>
> Think about how much network gear is out there that is straining under the
> current size of the global table.  Opening the flood gates to many more
> prefixes with /25-/27 routes in the global table would mean lots of gear
> needs to be upgraded/replaced sooner rather than later.
>
> --
>   Jon Lewis, MCP :)   |  I route
>   StackPath, Sr. Neteng   |  therefore you are
> _ http://www.lewis.org/~jlewis/pgp for PGP public key_
>


-- 
--
Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474

Re: JunOS config yacc grammar?

[Joe Snyder]

I agree with the yang approach. I would probably convert to using Yang and
download the yang files for whatever code version you are running. For
every code version you can download the yang files.
Then you have a choice to decide, either right a yang to yacc conversion
tool or find one, or think about switching to a netconf approach or
ODL/restconf -> netconf style approach depending on how you are using the
yacc files today as that will auto check and verify basics and reject non
compliant configs to some level.


On Tue, Aug 22, 2023 at 9:36 AM Diogo Montagner 
wrote:

> I would first try to understand what you are trying to achieve. JUNOS is
> very flexible on this front and I am wondering why you think yacc is the
> right way to achieve what you are trying to do.
>
> If no one (or very few) these days is using yacc grammar for parsing
> router configs, that should be a good indication whether you are on the
> right path or not.
>
> As already pointed out, navigating the XML trees or JSON structures
> would be much easier than writing a yacc grammar parser.
>
> Alternatively, I would look into the YANG files:
> https://github.com/Juniper/yang
>
> But without understanding what you are trying to do, this is just another
> suggestion.
>
> ./diogo -montagner
> JNCIE-SP 0x41A
>
>
> On Tue, 22 Aug 2023 at 09:53, Lyndon Nerenberg (VE7TFX/VE6BBM) <
> lyn...@orthanc.ca> wrote:
>
>> Nick Hilliard writes:
>>
>> > No need to reinvent that wheel:
>> >
>> > root@foo> show configuration | display xml
>> > root@foo> show configuration | display json
>>
>> That doesn't quite work for this scenario.  It would mean ssh-ing
>> to the switch to grab it, and that's pretty locked down.  We already
>> have cron jobs running on the switches that tftp the config file
>> to a server, and I'd prefer to leverage off that.
>>
>> Also, the yacc parser would let me do some validation checks
>> before we push new configs.
>>
>> --lyndon
>>
>

Re: Request for assistance with Verizon FIOS connection

[Joe Loiacono]

I dunno ... I had to turn Verizon's FiOS IPv6 off because it wasn't 
playing well with my Pulse VPN. So they are providing it now (maybe not 
supporting it ;-)


On 7/15/2023 12:05 PM, Joe Klein wrote:
As from a consumers standpoint, Verizon FIOS has published an IPv6 
website, created a discussion forum, and stated they would soon 
support. That was 14 years ago.


Joe Klein

On Sat, Jul 15, 2023, 3:46 AM Mel Beckman  wrote:

Matt,

I missed where the OP indicated they've tried both a direct laptop
connection as well as another router. I think you may have seen my
reply suggesting that and thought that was the OP stating he'd
done it.

-mel

*From:* Matt Corallo 
*Sent:* Friday, July 14, 2023 9:44 PM
*To:* Mel Beckman ; Neil Hanlon ;
nanog@nanog.org 
*Subject:* Re: Request for assistance with Verizon FIOS connection
OP indicated they've tried both a direct laptop connection as well
as another router. That seems to
meet the requirement for having ruled out his home-made router,
though obviously I agree one should
attempt to rule out any possible errors by doing transparent
packet sniffing analyzing the problem
carefully before escalating an issue. Hopefully everyone on this
list knows the value of the tech on
the other end of the line's time :)

Matt

On 7/14/23 9:07 PM, Mel Beckman wrote:
> Getting the FCC involved seems premature, since the OP hasn't
yet ruled out a problem with his home
> made router. Not that there's anything wrong with making your
own router, but it seems there is a
> burden of proof on the end user to demonstrate the problem isn't
at with the CPE. Even a test as
> simple as connecting a laptop up for a day and running pings
would rule out the CPE.
>
>    -mel
>


> *From:* NANOG  on
behalf of Matt Corallo 
> *Sent:* Friday, July 14, 2023 5:46 PM
> *To:* Neil Hanlon ; nanog@nanog.org 
> *Subject:* Re: Request for assistance with Verizon FIOS connection
> I've always had good luck with
https://consumercomplaints.fcc.gov/hc/en-us
> <https://consumercomplaints.fcc.gov/hc/en-us>. This tends to
result in
> a higher-level tech getting assigned to your ticket at least at
larger providers. Depending on where
> you are, your local government may have a similar process (e.g.
in NYC the city has a similar
> process that tends to get very high priority tech attention as
city council members will rake
> providers over the coals on individual complaints come
contract-renewal time).
>
> Matt
>
> On 7/14/23 8:01 AM, Neil Hanlon wrote:
>> Hi all - I apoligize for the not-necessarily-on-topic post, but
I've been struggling with this issue
>> for the past two
>> weeks and am about out of ideas and options other than ask here.
>>
>> The short version is I recently got FIOS at my (new) house, and
plugged in my router (SFF PC running
>> Vyos). Initially,
>> all was fine, however, some time later, connectivity to the
gateway given by the DHCP server is
>> completely lost. If I
>> force a renewal, the gateway (sometimes) comes back--sometimes
not. When it doesn't work, the
>> DHCPDISCOVER process has
>> to start over again and I often recive a lease in a completely
different subnet--which isn't really
>> the problem, but
>> seems to be symptomatic of whatever is happening upstream of me.
>>
>> The problem, from my perspective, is that the IPv4 gateway
given to me in my DHCP lease goes away
>> before my lease
>> expires--leading to broken v4 connectivity until either 1. the
system goes to renew the lease and
>> fails, starting over;
>> or 2. A watchdog notices and renews the lease (This is what I
have attempted to implement, without
>> much success).
>>
>> As a note, IPv6 connectivity (dhcpv6-pd, receiving a /56) is
entirely unaffected when IPv4
>> connectivity breaks.
>>
>> For the past week, I have been monitoring to various IPv4 and
IPv6 endpoints over ICMP and TCP, and
>> have been able to
>> chart the outages over that period. More or less, every two
hours, shortly after a lease is renewed,
>> the gateway
>> disappears. I'm happy to share more details and graphs/logs
with anyone who might be able to help.
>>
>> I have attempted to contact FIOS support several times and even
had a trouble ti

Re: Request for assistance with Verizon FIOS connection

[Joe Klein]

As from a consumers standpoint, Verizon FIOS has published an IPv6 website,
created a discussion forum, and stated they would soon support. That was 14
years ago.

Joe Klein

On Sat, Jul 15, 2023, 3:46 AM Mel Beckman  wrote:

> Matt,
>
> I missed where the OP indicated they've tried both a direct laptop
> connection as well as another router. I think you may have seen my reply
> suggesting that and thought that was the OP stating he'd done it.
>
> -mel
> --
> *From:* Matt Corallo 
> *Sent:* Friday, July 14, 2023 9:44 PM
> *To:* Mel Beckman ; Neil Hanlon ;
> nanog@nanog.org 
> *Subject:* Re: Request for assistance with Verizon FIOS connection
>
> OP indicated they've tried both a direct laptop connection as well as
> another router. That seems to
> meet the requirement for having ruled out his home-made router, though
> obviously I agree one should
> attempt to rule out any possible errors by doing transparent packet
> sniffing analyzing the problem
> carefully before escalating an issue. Hopefully everyone on this list
> knows the value of the tech on
> the other end of the line's time :)
>
> Matt
>
> On 7/14/23 9:07 PM, Mel Beckman wrote:
> > Getting the FCC involved seems premature, since the OP hasn't yet ruled
> out a problem with his home
> > made router. Not that there's anything wrong with making your own
> router, but it seems there is a
> > burden of proof on the end user to demonstrate the problem isn't at with
> the CPE. Even a test as
> > simple as connecting a laptop up for a day and running pings would rule
> out the CPE.
> >
> >-mel
> >
> 
> > *From:* NANOG  on behalf of
> Matt Corallo 
> > *Sent:* Friday, July 14, 2023 5:46 PM
> > *To:* Neil Hanlon ; nanog@nanog.org 
> > *Subject:* Re: Request for assistance with Verizon FIOS connection
> > I've always had good luck with
> https://consumercomplaints.fcc.gov/hc/en-us
> > <https://consumercomplaints.fcc.gov/hc/en-us>. This tends to result in
> > a higher-level tech getting assigned to your ticket at least at larger
> providers. Depending on where
> > you are, your local government may have a similar process (e.g. in NYC
> the city has a similar
> > process that tends to get very high priority tech attention as city
> council members will rake
> > providers over the coals on individual complaints come contract-renewal
> time).
> >
> > Matt
> >
> > On 7/14/23 8:01 AM, Neil Hanlon wrote:
> >> Hi all - I apoligize for the not-necessarily-on-topic post, but I've
> been struggling with this issue
> >> for the past two
> >> weeks and am about out of ideas and options other than ask here.
> >>
> >> The short version is I recently got FIOS at my (new) house, and plugged
> in my router (SFF PC running
> >> Vyos). Initially,
> >> all was fine, however, some time later, connectivity to the gateway
> given by the DHCP server is
> >> completely lost. If I
> >> force a renewal, the gateway (sometimes) comes back--sometimes not.
> When it doesn't work, the
> >> DHCPDISCOVER process has
> >> to start over again and I often recive a lease in a completely
> different subnet--which isn't really
> >> the problem, but
> >> seems to be symptomatic of whatever is happening upstream of me.
> >>
> >> The problem, from my perspective, is that the IPv4 gateway given to me
> in my DHCP lease goes away
> >> before my lease
> >> expires--leading to broken v4 connectivity until either 1. the system
> goes to renew the lease and
> >> fails, starting over;
> >> or 2. A watchdog notices and renews the lease (This is what I have
> attempted to implement, without
> >> much success).
> >>
> >> As a note, IPv6 connectivity (dhcpv6-pd, receiving a /56) is entirely
> unaffected when IPv4
> >> connectivity breaks.
> >>
> >> For the past week, I have been monitoring to various IPv4 and IPv6
> endpoints over ICMP and TCP, and
> >> have been able to
> >> chart the outages over that period. More or less, every two hours,
> shortly after a lease is renewed,
> >> the gateway
> >> disappears. I'm happy to share more details and graphs/logs with anyone
> who might be able to help.
> >>
> >> I have attempted to contact FIOS support several times and even had a
> trouble ticket opened at one
> >> point--though this
> >> has been closed as they cannot apparently find any issue with the ONT.
> >>
> >> I'm at my wit's end with this issue and would really appreciate any and
> all help. Please contact me
> >> off list if you need
> >> additional details--I can provide ticket numbers/conversation IDs/etc,
> as well as graphs/logs/etc.
> >>
> >> Best,
> >> Neil Hanlon
>

Re: 10G CPE w/VXLAN - vendors?

[Joe Freeman]

I think you’re probably overthinking this a bit.

Why do you need to extend your vxlan/evpn to the customer premise? There are a 
number of 1G/10G even 100G CPE demarc devices out there that push/pop tags, 
even q-in-q, or 802.1ad. Assuming you have some type of aggregation node you 
bring these back to, tie those tags to the appropriate EVPN instance at the 
aggregation point. Don’t extend anything but a management tag and an S-tag 
essentially to the device at the customer premise.

You can even put that management tagged vlan in it’s own L3 segment, or a 
larger L3 network and impose security. This way you’re not exposing your whole 
service infrastructure to a bad actor that might unplug your cpe device and 
plug into your network directly.



From: NANOG  on behalf of Adam 
Thompson 
Date: Wednesday, June 14, 2023 at 2:52 PM
To: nanog 
Subject: 10G CPE w/VXLAN - vendors?
Hello, all.
I’m having difficulty finding vendors, never mind products, that fit my need.

We have a small but growing number of L2 (bridged) customers that have diverse 
fiber paths available, and, naturally, want to make use of them.
We have a solution for this: we extend the edge of our EVPN VXLAN fabric right 
to the customer premise.  The customer-prem device needs 4x10G SFP+ cages (2 
redundant paths, plus LAG to customer), and the switches we currently use, 
Arista 7020Rs, are quite expensive if I’m deploying one one per customer.  
(Nice switches, but overkill here – I don’t need 40/100G, and I don’t need 24 
SFP+ ports.  And they still take forever to ship.)

We use RFC7438 §6.3 “vlan-aware-bundle” mode, not §6.1 “vlan-based” mode, which 
limits our choices somewhat.  I might be willing to entertain spinning up a 
separate VXLAN mesh using RFC7438 §6.1 (“vlan-based”) and static VTEPs if it 
saves me a lot of pain.

However, I’m having trouble finding small & cheaper 1U (or even 
desktop/wallmount) devices that have 4 SFP+ cages, and can do VXLAN, in the 
first place.
Who even makes CPE gear with SFP+ ports?  (Other than Mikrotik CRS309-1G-8S+IN 
/ CRS317-1G-16S+RM, which are nice, but our policy requires vendor support 
contracts, so… no-go.)

Vendors?  Model#s, if you happen to know any?

Reply here or privately, whatever floats your boat – any pointers appreciated!

Adam Thompson
Consultant, Infrastructure Services
[[MERLIN logo]]
100 - 135 Innovation Drive
Winnipeg, MB R3T 6A8
(204) 977-6824 or 1-800-430-6404 (MB only)
https://www.merlin.mb.ca
[cid:image002.png@01D99EC2.B891B0A0]Chat with me on 
Teams

Re: 365 Datacenters Tampa AC Failure

[Joe Hamelin]

Is this the building with the lizard mural?

On Mon, Jun 12, 2023 at 4:03 PM Nick Olsen  wrote:

> Just a heads up to anyone else colo'd at 365 TPA1/TAMSFLDE. Currently
> seeing floor temps of ~105F as reported by equipment. Started yesterday at
> ~5:30PM eastern. 2nd AC failure in the last 30 days. They have not sent any
> advisory notices as of yet.
>


-- 
--
Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474

Re: Backup DC power standardization with Photovoltiac battery systems?

[Joe Greco]

On Fri, Apr 14, 2023 at 07:17:23PM -0400, Sean Donelan wrote:
> All these darn wall warts are almost, but slightly different (5v, 12v, 
> 24v).  No -48v CPE?

Ubiquiti EdgeRouter PoE 5 can use 48VDC.

... JG
-- 
Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net
"The strain of anti-intellectualism has been a constant thread winding its way
through our political and cultural life, nurtured by the false notion that
democracy means that 'my ignorance is just as good as your knowledge.'"-Asimov

Re: Verizon/Qwest single end-user difficulty vs Xfinity

[Joe]

You mentioned using a non-standard port for your ssh/rsync, have you tried
changing that to something other than what your using?
Keep in mind some of these providers might be blocking non-standard ports
as this is a common method to abuse others and might be a cheaper
alternative to dealing with the constant pile of abuse complaints.

Maybe not just a thought.

-Joe


On Sat, Mar 18, 2023 at 2:51 PM Jeff Woolsey  wrote:

> Verizon 5G Internet Support is not at a high-enough pay grade to assess
> this problem...  So I'm turning to y'all.
>
> I'm trying to save $$$ and increase speed, using Verizon 5G Home
> Internet to replace XFinity, even though they gave me a faster modem a
> few weeks ago.  I run both of the modems in Bridge/Passthrough mode.
>
> A friend of mine is nice enough to offer some offsite backup space, and
> I use rsync over ssh to get there.  He's 1500 miles away.  He uses a
> non-standard ssh port (keeps the doorknob twisters away).   This sort of
> thing has been working without difficulty over Xfinity (my end) for
> years.  He also changed his connection almost a month ago now, to Qwest,
> I believe.
>
> I try the same thing over Verizon [1] and ssh always times out, no
> response.  We are also NTP peers, and that doesn't work well over
> Verizon either. ICMP traceroutes and pings succeed.  UDP traceroutes do
> not get any further than 207.109.3.78 (last hop before destination) .
> Not every traceroute offers TCP, but MacOS does, and nothing responds to
> any of that, even at the usual ssh port.  UDP traceroutes to either port
> behave like an ordinary one, which it is.
>
> Since I can get there via xfinity, I can traceroute, ping, but not ssh
> back through Verizon.
>
> I also set up an incoming (xfinity) port from the same non-standard ssh
> port forwarding to regular ssh on a different system on my LAN, and when
> I ssh -p   that from Verizon (even cellphone data),  I get that
> other system, and that works fine.  The 207... router is not in that path.
>
> I can also ping the Verizon connection from Xfinity (and vice versa).
>
> Go figure.
>
> [1] This same difficulty occurs in Verizon's Looking Glass, from several
> different places, and other Looking Glasses (e.g. Cogent, Equinix).  It
> also occurs on my Verizon phone data connection (not WiFi).  If he were
> serving more stuff out of his home, this would be a bigger problem.
>
>
> --
> Jeff Woolsey {woolsey,jlw}@{jlw,jxh}.com first.last@{gmail,jlw}.com
> Spum bad keming.
> Nature abhors a straight antenna, a clean lens, and empty storage.
> "Delete! Delete! OK!" -Dr. Bronner on disk space management
> "Card sorting, Joel." -me, re Solitaire
>
>

Re: SDN Internet Router (sir)

[Joe Maimon]

And here is another interesting approach Ive left open in my browser 
window for who knows how long


https://inog.net/files/iNOG14v_oliver_sourcerouting.pdf

The problem with BGP is that local actors can exact global costs 
trivially by consuming as many routing slots as they can get away with, 
add together BGP path decisions and Most Specific traffic-engineering is 
the goto knob. Sometimes you just want to say this is the route, do not 
accept any more specifics, unless this route is no longer the route. But 
you want that done automatically and correctly, reliably.


This is also why all the multi-homing approaches that do not involve 
global routing havent really taken off in any way to blunt table growth. 
And likely wont.


See the aggregation factor in the routing report for how bad this is.

There have been lots of BGP protocol and feature updates, but unless 
your going to uniformly run new systems and enterprise systems that 
support all of them, its hard to decide to build your entire routing 
strategy around them.


That BGP unlike EIGRP never tried to tie together performance indicators 
with routing metrics feature or misdesign, you could debate that but it 
was always intentional. And opex has pretty much fallen down on the side 
of against IGP->BGP redistribution of prefixes, let alone performance 
metrics.


That eBGP prefix has no good reliable way of indicating that an 
advertised route sucks so bad that you should never attempt to use it 
unless as last resort, thats why we have AS-paths wrapping screen lines.


"finish IPv6 migration"? Letting IPv6 migration state factor as decision 
input on anything not directly related to IPv6 migration was never 
logical, just naively optimistic, and should be stamped out wherever 
encountered. If its good, use it now and Ipv6 will adopt it as well. If 
it isnt, why wait to find out?


Joe

Mel Beckman wrote:

Mike,

Thanks for that useful example. On a side note, Netflix is a thorn in 
all our sides :) You could put a localpref filter route to override 
the default for Netflix prefixes, but this impacts resilience. Since 
you peer with Netflix, I suspect we probably agree that Netflix’s 
ideas on traffic engineering are pretty one sided.


I think it’s safe to say that BGP, which has scaled amazingly well, 
didn’t anticipate some of the big gorilla content systems. I don’t 
really see, though, how injecting FIB entries helps more than other 
methods. And as others have pointed out, the risk of creating routing 
loops is significant.


Perhaps it is time to migrate to a new version of BGP.  Projects like 
MBGP and FP-7‘s 4WARD are working on new follow-on routing models, but 
nothing is on the immediate horizon. I think we all thought we should 
finish IPv6 migration first :)


-mel via cell


On Jan 5, 2023, at 1:11 PM, Mike Hammett  wrote:


I hesitated to get too specific in examples because someone is going 
to drag the conversation into the weeds.


Let's take the the Dallas - New Orleans - Atlanta example where I 
have a connection from New Orleans to Dallas and a connection from 
New Orleans to Atlanta.


Let's say I peer with Netflix in both markets. Netflix chooses to 
serve me out of Atlanta, for whatever reason. Say my default route 
sends my traffic to Dallas. That's not where Netflix wanted it, so 
now I have to go from Dallas to Atlanta, whether that's my circuit or 
across the public Internet. Potentially, it's on MPLS and it rides 
back through the New Orleans router to get back to Atlanta. That's a 
long trip when I already had a better path, the less-than-full-fib 
router just didn't know about it. Given that Netflix is a sizable 
amount of traffic in an eyeball ISP, that's a lot of traffic to be 
going the wrong way. If the website for Viktor's Arctic Plunge in 
Siberia was hosted in Atlanta, I wouldn't give two craps that the 
traffic went the wrong way because A), I'll probably never go there 
and B) when someone does, it won't be meaningfully enough traffic to 
accommodate.


Someone's going to tell me to put a full-table router in New Orleans. 
Maybe I should. Okay, so maybe I have a POP in Ashford, Alabama. It 
has transport to New Orleans and Atlanta. There aren't enough grains 
of sugar in Ashford, Alabama to justify a current-generation, full 
table router. Now I'm even closer to Atlanta, but default may point 
to New Orleans.




-
Mike Hammett
Intelligent Computing Solutions <http://www.ics-il.com/>
<https://www.facebook.com/ICSIL><https://plus.google.com/+IntelligentComputingSolutionsDeKalb><https://www.linkedin.com/company/intelligent-computing-solutions><https://twitter.com/ICSIL>
Midwest Internet Exchange <http://www.midwest-ix.com/>
<https://www.facebook.com/mdwestix><https://www.linkedin.com/company/midwest-internet-exchange><https://twitter.com/mdwestix>
The Brothers WISP <http://www.thebrotherswisp.com/>
<https://www.facebook.c

Re: SDN Internet Router (sir)

[Joe Maimon]

This is not a green grass problem space.

https://www.cisco.com/c/en/us/products/ios-nx-os-software/performance-routing-pfr/index.html

And you could probably envision how you could create your own internal 
scheme of route reflectors/servers, community tags, probers and updaters 
to achieve something similar.


Most likely Mike is referring to the sub-optimal result where a large 
percentage of a router's traffic is taking extra internal hops or worse, 
maybe even egressing from the AS into a less than optimal path, not 
because the AS does not have the correct route for the most likely as 
perceived by BGP optimal path, but that the traffic handling device was 
not able to be configured to accept any such routes, because doing such 
statically is not likely to achieve the results and more likely to 
result in crashed routers one unexpected fine morning.


Nanogers pointed me at this some time back, I think its germaine

https://blog.google/products/google-cloud/making-google-cloud-faster-more-available-and-cost-effective-extending-sdn-public-internet-espresso/

RIB/FIB static configuration limitation tip:

Apply the same logic on all similar capacity devices to cut down on the 
RIBFIB, because thats the best way to minimize loops. And a guaranteed 
loop free path for the default route. Policy or tag tunnel or whatever.


Joe


Mel Beckman wrote:

Mike,

I’m not sure I understand what you mean by “suboptimal“ routing. Even 
though the Internet uses AS path length for routing,  many of those 
path lengths are bogus, and don’t really represent any kind of path 
performance value. For example, a single AS might hide many hops in an 
MPLS network as a single hop, obscuring asymmetric routing and other 
uglies. Prepending also occurs when destinations are trying to enforce 
their own engineering  policies, which often conflict with yours or mine.


So what do you mean by “suboptimal“? Are you thinking that the “best” 
path in BGP tables actually meant you were getting a performance 
benefit? Because that’s definitely not the case in today’s Internet. 
Were were you thinking that you would be going along less congested 
paths? That’s really at the mercy of the traffic engineering of 
backbone providers over which we have no control.


I generally populate local router FIBs to merel choose an exit point 
for purposes of load balancing, and nothing more.


 -mel


On Jan 5, 2023, at 12:38 PM, Mike Hammett  wrote:


I guess I wasn't around for those days.

As far as running out, again, assuming the tooling works correctly, 
I'd think to target fewer routes than you could hold. Maybe 1k routes 
is all one would need to get a significant percent of the traffic. A 
lot of room to mess up if you can hold 100k, 500k routes.




-
Mike Hammett
Intelligent Computing Solutions <http://www.ics-il.com/>
<https://www.facebook.com/ICSIL><https://plus.google.com/+IntelligentComputingSolutionsDeKalb><https://www.linkedin.com/company/intelligent-computing-solutions><https://twitter.com/ICSIL>
Midwest Internet Exchange <http://www.midwest-ix.com/>
<https://www.facebook.com/mdwestix><https://www.linkedin.com/company/midwest-internet-exchange><https://twitter.com/mdwestix>
The Brothers WISP <http://www.thebrotherswisp.com/>
<https://www.facebook.com/thebrotherswisp><https://www.youtube.com/channel/UCXSdfxQv7SpoRQYNyLwntZg>
--------
*From: *"Joe Maimon" 
*To: *"Mike Hammett" , "Christopher Morrow" 


*Cc: *"NANOG" 
*Sent: *Thursday, January 5, 2023 2:30:40 PM
*Subject: *Re: SDN Internet Router (sir)



Mike Hammett wrote:
> I'm not concerned with which technology or buzzword gets the job done,
> only that the job is done.
>
>
>
> Looking briefly at the couple of things out there, they're evaluating
> the top X prefixes in terms of traffic reported by s-flow, where X is
> the number I define, and those get pushed into the FIB. One
> recalculates every hour, one does so more quickly. How much is
> appropriate? I'm not sure. I can't imagine it would *NEED* to be done
> all of that often, given the traffic/prefix density an eyeball network
> will have. Default routes carry the rest. Default routes could be
> handled outside of this process, such that if this process fails, you
> just get some sub-optimal routing until repaired. Maybe it doesn't
> filter properly and sends a bunch of routes. Then just have a prefix
> limit set on the box. Maybe it sends the wrong prefixes. No harm, no
> foul. If you're routing sub-optimally internally, when it does hit a
> real router with a full FIB, it gets handled appropriately.

Unless it loops.

The rest sounds nice. But flow caching got a bad rap back in the early
worm days. But thats because the situation was a little worse back then.
Cache the wrong rout

southeast asia phillipines hong king singapore region inter-network vendor expert

[Joe Maimon]

Looking to consult with someone who has in depth knowledge and 
experience with the way things work over in the corner, trying to round 
the bases on a solution and not hit it out of the ballpark.


Contact direct for less public details and arrangements, of course 
anything of legit public networking interest belongs right here.


Joe

Re: SDN Internet Router (sir)

[Joe Maimon]

Mike Hammett wrote:
I'm not concerned with which technology or buzzword gets the job done, 
only that the job is done.




Looking briefly at the couple of things out there, they're evaluating 
the top X prefixes in terms of traffic reported by s-flow, where X is 
the number I define, and those get pushed into the FIB. One 
recalculates every hour, one does so more quickly. How much is 
appropriate? I'm not sure. I can't imagine it would *NEED* to be done 
all of that often, given the traffic/prefix density an eyeball network 
will have. Default routes carry the rest. Default routes could be 
handled outside of this process, such that if this process fails, you 
just get some sub-optimal routing until repaired. Maybe it doesn't 
filter properly and sends a bunch of routes. Then just have a prefix 
limit set on the box. Maybe it sends the wrong prefixes. No harm, no 
foul. If you're routing sub-optimally internally, when it does hit a 
real router with a full FIB, it gets handled appropriately.


Unless it loops.

The rest sounds nice. But flow caching got a bad rap back in the early 
worm days. But thats because the situation was a little worse back then. 
Cache the wrong routes or run out of cache, router dies. So long as 
thats not the case automating optimization is an extremely valuable goal.





I would just be looking for solutions that influence what's in the FIB 
and let the rest of the router work as the rest of the router would.


The problem comes when the router wont work at all without the FIB 
routes, like in the olden days.




-
Mike Hammett
Intelligent Computing Solutions 

Midwest Internet Exchange 

The Brothers WISP 


*From: *"Christopher Morrow" 
*To: *"Mike Hammett" 
*Cc: *"Tom Beecher" , "NANOG" 
*Sent: *Thursday, January 5, 2023 12:27:08 PM
*Subject: *Re: SDN Internet Router (sir)



On Thu, Jan 5, 2023 at 11:18 AM Mike Hammett > wrote:


Initially, my thought was to use community filtering to push just
IXes, customers, and defaults throughout the network, but that's
obviously still sub-optimal.

I'd be surprised if a last mile network had a ton of traffic going
to any more than a few hundred prefixes.


I think in a low-fib box at the edge of your network your choices are:
  "the easy choice, get default, follow that"

  "send some limited set of prefixes to the device, and default, so 
you MAY choose better for the initial hop away"


you certainly can do the second with communities, or route-filters 
(prefix-list) on the senders, or
you can choose what prefixes make the cut (get the community(ies)) 
based on traffic volumes or expected destination locality:

   "do not go east to go west!"

these things will introduce toil and SOME suboptimal routing in some 
instances... perhaps it's better than per flow choosing left/right 
though and the support calls related to that choice.


In your NOLA / DFW / ATL example it's totally possible that the 
networks in question do something like:
  "low fib box in tier-2 city (NOLA), dfz capable/core devices in 
tier-1 city (DFW/ATL), and send default from left/right to NOLA"


Could they send more prefixes than default? sure... do they want to 
deal with the toil that induces? (probably not says your example).


SDN isn't really an answer to this, though.. I don't think. Unless you 
envision that to lower the toil ?

Re: SDN Internet Router (sir)

[Joe Maimon]

Lots of 1M tcam fib limits in older gear...

So yeah, its the same problem, bigger numbers and still not solved in 
any sort of non-painful or expensive way.


I think Ill explore the google path and paper on it again.

Joe

Mike Hammett wrote:

Then please bless the world with the right way.

You acknowledge that not every router in a network needs to be fully 
DFZ capable, but then crap on my desire to have more than a default 
route in one.




-
Mike Hammett
Intelligent Computing Solutions <http://www.ics-il.com/>
<https://www.facebook.com/ICSIL><https://plus.google.com/+IntelligentComputingSolutionsDeKalb><https://www.linkedin.com/company/intelligent-computing-solutions><https://twitter.com/ICSIL>
Midwest Internet Exchange <http://www.midwest-ix.com/>
<https://www.facebook.com/mdwestix><https://www.linkedin.com/company/midwest-internet-exchange><https://twitter.com/mdwestix>
The Brothers WISP <http://www.thebrotherswisp.com/>
<https://www.facebook.com/thebrotherswisp><https://www.youtube.com/channel/UCXSdfxQv7SpoRQYNyLwntZg>

*From: *"Tom Beecher" 
*To: *"Mike Hammett" 
*Cc: *"Mel Beckman" , "NANOG" 
*Sent: *Thursday, January 5, 2023 9:55:38 AM
*Subject: *Re: SDN Internet Router (sir)

"The right tool for the job" gets into a religious argument in
assuming that one's way to do the job is the only reasonable way
to do the job


I disagree that it's religious. I completely agree there are locations 
in networks that having full DFZ capable routers doesn't make 
technical or economic sense. But there have long been different 
products for those different use cases.


To perhaps explain my viewpoint better,(and perhaps I didn't properly 
comprehend the problem you're aiming to solve) :


If you are trying to use SDN stuff to shuffle routes on and off a box 
because you have the wrong sized routers in place, then I would argue 
you're doing it wrong.


If you are trying to use SDN stuff to (as Christopher mentioned) make 
decisions that are not strictly LPM, and the equipment you have cannot 
do that, then that's different and entirely reasonable.


If the second use case is more of what you were asking, then I 
apologize for misunderstanding.



On Thu, Jan 5, 2023 at 9:57 AM Mike Hammett <mailto:na...@ics-il.net>> wrote:


"The right tool for the job" gets into a religious argument in
assuming that one's way to do the job is the only reasonable way
to do the job.

Large networks historically have a very poor (IMO) model of
gigantic iron in a few locations, which results in sub-optimal
routing for the rest of their network between those large POPs.
I've heard time and time again that someone buying service from a
major network in say New Orleans has a first hop of Dallas or
Atlanta. I agree that full-route capable routers need to be in the
large, central locations, but it isn't cost effective to have them
at every POP, especially if you're a last-mile provider.

I'd go into more examples of where it doesn't make sense to have
full-route routers everywhere, but I'm afraid that the Internet
would then focus on the examples instead of the core idea of
intelligently putting routes into the FIBs of low-FIB routers
throughout my network.



-
Mike Hammett
Intelligent Computing Solutions <http://www.ics-il.com/>

<https://www.facebook.com/ICSIL><https://plus.google.com/+IntelligentComputingSolutionsDeKalb><https://www.linkedin.com/company/intelligent-computing-solutions><https://twitter.com/ICSIL>
Midwest Internet Exchange <http://www.midwest-ix.com/>

<https://www.facebook.com/mdwestix><https://www.linkedin.com/company/midwest-internet-exchange><https://twitter.com/mdwestix>
The Brothers WISP <http://www.thebrotherswisp.com/>

<https://www.facebook.com/thebrotherswisp><https://www.youtube.com/channel/UCXSdfxQv7SpoRQYNyLwntZg>

*From: *"Tom Beecher" mailto:beec...@beecher.cc>>
*To: *"Mike Hammett" mailto:na...@ics-il.net>>
*Cc: *"Mel Beckman" mailto:m...@beckman.org>>,
"NANOG" mailto:nanog@nanog.org>>
*Sent: *Wednesday, January 4, 2023 7:36:58 AM
*Subject: *Re: SDN Internet Router (sir)

Disagree that it’s a line in the sand. It’s use the right tool for
the job.

If a device is low FIB, it’s that way for a reason. There are
plenty of ways to massage that with policy and software, depending
on capabilities , but at the end of the day, trying to sort 10
pounds of shit to store in a 5 pound bag is eventually going to
end up

Re: Alternative Re: ipv4/25s and above Re: 202211201009.AYC

[Joe Maimon]

John Curran wrote:



On Nov 22, 2022, at 9:09 AM, John Curran  wrote:
...
Interoperability isn’t insurmountable, but does take some investment 
of effort.  One can imagine any number of techniques (e.g.  flag day 
after which “production devices” on the Internet must support 240/4, 
or DNS resolver hacks that fail to return “A” records with 240/4 
addresses unless a flag is set that says “we’re in the 240/4 routable 
Internet” [ick], etc., etc.)  It doesn’t seem particularly hard to 
come up with some approaches to solve the interoperability problem, 
but completely ignoring it is not an answer (and makes it rather 
difficult to take your proposal seriously…)


Joe -

By the way, you shouldn’t feel particularly bad about skipping out on 
the interoperability requirement – anything involving interworking 
with the installed Internet is hard, and this is the same lesson that 
the IPv6 folks found out the hard way…   I will confess that I was a 
member of the IETF's IPng Directorate and thus inherently complicit in 
that particular fiasco –


John,

Flags days on the internet of today have proven to be of limited value.

Suppose complete interoperability is never actually solved. Why does 
240/4 utilitarian value have to be binary? I think we should be trying 
to discover these things instead of using them to handwave away any attempt.


The part I feel bad about is that I am actually un-involved in much of 
anyway with the 240/4 or other ideas, my sole input has been to attempt 
to encourage serious consideration and to rebut  naysaying.


Yes, a standards update is only the beginning of a real effort, although 
plenty has changed even without that.


Yes, there may and likely will be a large extent of interoperability and 
usability challenges for quite some time, perhaps even enough time that 
the issue becomes moot.


Yes, it may be insurmountable.

Yes, it may render 240/4 unusable and undesirable to the extent that it 
has little contributory effect on IPv4.


However it may not and discouraging serious consideration is actually a 
contributing factor preventing any such potential.


And to the extent that you and others have discussed and aired various 
points of views and insights, I think I have had some success with my 
efforts thus far.





With IPv6, the first answer to interoperability was “let’s do tunnels 
between IPng islands”; i.e. helpful for lab environments but useless 
otherwise.  We then declared that transition was a problem “to be 
solved later” but that shouldn’t get in the way of the declaration of 
IPng as the new IPv6.  Finally, after failing to solve the problem, we 
reverted to “ships in the night”; i.e. IPv4 and IPv6 running in 
parallel on the same infrastructure – it works, but defeats the entire 
idea of IPv6 as a functional substitute for IPv4 for connecting new 
customers and infrastructure to the existing IPv4-based Internet 
(Luckily, the service provider industry that was growing most rapidly 
realized that they really needed IPv6, and they really needed 
transition solutions that allowed IPv6 to interoperate for IPv4 for 
new connections, and so we eventually saw real solutions such 
as 464xlat, ds-lite, etc.)


I feel there is some value for the internet record to contain as much as 
possible real debate and consideration instead of group think, 
short-sightedness, idealouges and top down approaches which may not look 
pretty in hindsight. Such as contained in the much larger details of 
your brief recap and that you and others have expanded upon here and 
elsewhere in the past.


In other words, a loyal opposition.



Maintaining interoperability with the existing base is hard - far 
harder than just “updating the standard” -
Without a standard update, there is a bit of a chicken and egg problem 
with pursuing interoperability with any seriousness.


I think 100.64/10 was a missed opportunity to incentivize the industry 
to pursue interoperability.


but is absolutely essential if you want viable reuse of 240/4.  Of 
course, it does raise the question of whether the total effort will be 
worth the purported gain, but that really can’t be assessed until 
there's some specification of the proposed solution for 
interoperability with the existing deployed devices that don’t know 
about the 240/4 change.


Thanks,
/John

p.s.  Disclaimer(s): my views alone. Warning: may cause dizziness, 
headaches, or nausea.



Best,

Joe

Re: Alternative Re: ipv4/25s and above

[Joe Maimon]

Jay Hennigan wrote:

On 11/21/22 16:30, Joe Maimon wrote:





IMNSHO, if such a proposal were to gain traction, by the time that 
gear capable of using 240/4 as unicast were to be widely deployed, 
IPv6-capable gear would be much more widely deployed.


Considering that is already the situation, whats your point?



META: Can whoever is doing so please stop creating new time-stamped 
subject lines for the same topic? It makes things hard to follow.

Re: Alternative Re: ipv4/25s and above Re: 202211201009.AYC

[Joe Maimon]

David Conrad wrote:
How trivial would the change be in a product by a company that no 
longer exists or a product line that is no longer supported? Will 
Microsoft update all previous versions of Windows? Will the myriad of 
deployed embedded systems sitting forgotten in closets be updated? And 
if you’re going to the trouble to update those systems (in most cases, 
by simply throwing them away), why not upgrade to IPv6+IPv4aaS?

Especially as we have examples of what that type of effort might look like.

Again, the issue isn’t fixing a bit of code in a known source tree. It is 
getting all the instantiations of that bit of code implemented, tested, and 
deployed across all the myriad supported and unsupported systems (both 
operational and management) that support 5 billion+ Internet users globally in 
a timeframe and for a cost that makes business sense.

Regards,
-drc



Lets agree to stop conflating the issue of products under active support 
and refresh cycles with the issue of those that are obsolete and only 
subject to attrition.


Two different problems areas entirely.

The former, yes it is trivial. An update in standards could yield rapid 
results here.


The latter takes time. An update in standards could take years to bear 
enough fruit. All the more reason it should have happened then, all the 
more reason to let it happen now.


Joe

Re: Alternative Re: ipv4/25s and above Re: 202211201009.AYC

[Joe Maimon]

David Conrad wrote:

Barry,

On Nov 21, 2022, at 3:01 PM, b...@theworld.com wrote:
We've been trying to get people to adopt IPv6 widely for 30 years 
with very limited success


According to https://www.google.com/intl/en/ipv6/statistics.html, it 
looks like we’ve gone from ~0% to ~40% in 12 years. 
https://stats.labs.apnic.net/ipv6 has it around 30%. Given an Internet 
population of about 5B, this can (simplistically and wrongly) argued 
to mean 1.5-2B people are using IPv6. For a transition to a technology 
that the vast majority of people who pay the bills will neither notice 
nor care about, and for which the business case typically needs 
projection way past the normal quarterly focus of shareholders, that 
seems pretty successful to me.


But back to the latest proposal to rearrange deck chairs on the IPv4 
Titanic, the fundamental and obvious flaw is the assertion of 
"commenting out one line code”. There isn’t “one line of code”. There 
are literally _billions_ of instances of “one line of code”, the vast 
majority of which need to be changed/deployed/tested with absolutely 
no business case to do so that isn’t better met with deploying 
IPv6+IPv4aaS. I believe this has been pointed out numerous times, but 
it falls on deaf ears, so the discussion gets a bit tedious.


Regards,
-drc

Re-replying. Changing the standards is not what is intended to drive 
vendor changes. Userbase requests and projected needs do that.


The standards are not responsible for the business case. However, they 
should not unreasonably impede it.


Joe

Re: Alternative Re: ipv4/25s and above Re: 202211210951.AYC

[Joe Maimon]

Lincoln Dale wrote:
On Tue, Nov 22, 2022 at 11:20 AM Joe Maimon <mailto:jmai...@jmaimon.com>> wrote:


Indeed that is exactly what has been happening since the initial
proposals regarding 240/4. To the extent that it is now largely
supported or available across a wide variety of gear, much of it not
even modern in any way.


As someone who has been involved in the deployment of network gear 
into class E space (extensively, for our own internal reasons, which 
doesn't preclude public use of class E), "largely supported" != 
"universally supported".


There remains hardware devices that blackhole class E traffic, for 
which there is no fix. https://seclists.org/nanog/2021/Nov/272 is 
where I list one of them. There are many, many other devices where we 
have seen interesting behavior, some of which has been fixed, some of 
which has not.



cheers,

lincoln.




And I am sure you would agree that un-reserving a decade ago would have 
more than likely resulted in a greatly improved situation now. Along the 
lines that doing so now could still result in a greatly improved 
situation a decade hence. Should we still need it.


Joe

Re: Alternative Re: ipv4/25s and above Re: 202211210951.AYC

[Joe Maimon]

Eric Kuhnke wrote:

Assume the following theoretical scenario:

You have a large number of existing RIPE, ARIN, APNIC ASes which will 
take any ipv4 resources they can get. They're all on waiting lists or 
have been informed no new blocks will be forthcoming.


240/4 is something like 256 million IPs.

Let's say that the global benevolent ipv4 dictator decides that each 
ISP, MNO or other waiting list entity gets a single /16, one time only.


That's 64,000 IPs per corporate entity. Not actually very large at all 
on the scale of regional mid sized operators with 300,000 last mile 
broadband subscribers, or mobile network operators, nevermind 
top-10-size DOCSIS3/GPON/DSL last mile operators that have many dozens 
of millions of customers. One /16 is a tiny drop in the bucket 
compared to the demand for IP space for indivudual-customer DHCP pool 
usage by an ISP the size of Astound or a South Korean GPON operator or 
similar.


That's 4000 entities which each get their one time /16 and then 240/4 
is entirely exhausted.


Unrealistic?  Halve it so that each network operator waiting for IP 
space reources gets one/ 17, one time only, I would still bet good 
money that there's 8000 ASes out there that right now would happily 
take their "free "single /17 , and you'd still have immediate complete 
exhaustion of 240/8.



Right now the IPv4 scarcity is a barrier of entry to new entities and a 
major speedbump in basic growth to small entities.


So my constraint has much wider, lasting and meaningful impact than 
either of your thought exercises which essentially involve how to enable 
existing entities to resume business as usual for some amount of time. I 
am sure there many other much more meaningful ways to consider using 
240/4 than that.


New IPv4 resources to go towards addressing customers in the same 
fashion as was done ten years ago, I wouldn't bother with 240/4 for that 
either.


Best,

Joe

Re: Alternative Re: ipv4/25s and above Re: 202211210951.AYC

[Joe Maimon]

John Curran wrote:



On Nov 21, 2022, at 7:18 PM, Joe Maimon  wrote:
… Further, presentment of options in this fashion presumes that we 
have some ability to control or decide how engineering efforts across 
the entirety of the internet should be spent.


Joe -

In the snippet above you allude to a very important aspect of the 
Internet that is rather germane to this discussion – ii.e. that we 
really don’t really have any "ability to control or decide how 
engineering efforts across the entirety of the internet should be 
spent” –, but then you don’t really work through what that fact means 
for realistic outcomes of class E space re-utilization…



True



As you alluded to, we really don’t have any "ability to control or 
decide how engineering efforts across the entirety of the internet 
should be spent”, and the practical implications of this fact is that 
there will always be many devices out there in production that will 
not pass IP packets with class E addresses in them…   (just as there’s 
always going to be some devices, somewhere that don’t know about IPv6.)
To what extent will this be? And to what extent could it have been had 
this been seriously considered dozen+ years ago? We wont really know 
until we can get serious about it.


Of course, the difference is that with IPv6 we can attempt a 
connection and then fall back to IPv4, and further that devices out 
there either support and are configured for IPv6 routing, or they are 
not - networks rather quickly learn not to announce (via routing & 
DNS) IPv6 connectivity for devices without it actually being in place 
and operational or having solid IPv4 fall-back and relying fast 
fallback/happy eyeballs.


This is a very fair point. Or perhaps we can have reverse happy eyeballs 
for IPv4 fallling back to sub-optimal auto-tunneled IPv6?


With your using repurposed class E address space in the headers, your 
customers with such addresses are rather unlikely to ever know why a 
connection won’t establish – or why existing connections sometime fail 
mid-stream – as it only takes a single non-conforming device along the 
ever-changing path through any number of network operators to 
resulting in the silent drop of that packet.


I am not that sure about silent, presumably traceroute will be just as 
(un)usable.


That may (or may not) lead to you experiencing what you consider 
reasonable support costs for your customers, but as we all know, 
everyone else has customers who are the other ends of those 
connections who will call their ISP’s customer support line trying to 
figure out why they can’t get your customer (or can only get there 
intermittently) – so it appears that your proposed use of de-reserved 
and repurposed class E space has some real interesting implications 
about imputed support burdens on everyone else – if indeed the 
intended use case is includes providing connectivity to the public 
Internet.


If you’re not proposing public Internet use, and rather just within 
your own administrative domain, then feel free to do – talk to your 
vendors, get them to support it, and turn it on. As you already noted, 
we really don’t centrally decide how everyone runs their own network – 
so using it locally is fine since it doesn’t presume others will 
diagnose connection problems with your customer traffic that quite 
reasonably is categorized as invalid.


Thanks,
/John

p.s. Disclaimer:  my views alone. Note: contents may be hot - use 
caution when opening.





Right now the gossiped growing use of 240/4 in private and non 
standardized fashions jeopardizes any potential use of it just as much 
as the factors you describe.


In either event, my main point of contention is in the lack of 
willingness for serious and prudent consideration. Such as along the 
lines of what you have brought up.


So thank you.

Best,

Joe

Re: Alternative Re: ipv4/25s and above Re: 202211210951.AYC

[Joe Maimon]

Eric Kuhnke wrote:
In a theoretical scenario where somebody was global benevolent 
dictator of ipv4 space, even applying a policy which limited block 
size to a few /14 per ISP, it would be possible to exhaust 240/4/in 
one week/ if they handed out /14 sized pieces to every existing last 
mile LTE network operator with 5+ million customers globally. It is 
not a long term solution or even a good medium term solution.


To to the LM LTE Operator with 5+ mill. customer globally, it is not. 
Agreed. Also, I think they have already sorted themselves out 
sufficiently in a variety of ways. I am not concerned with them, at all.


Which is why I did not offer that as an example of useful constraint. 
Re-run your projections with what I actually discussed, I think you will 
have a different conclusion.


Joe

Re: Alternative Re: ipv4/25s and above Re: 202211201009.AYC

[Joe Maimon]

David Conrad wrote:

Barry,

On Nov 21, 2022, at 3:01 PM, b...@theworld.com wrote:
We've been trying to get people to adopt IPv6 widely for 30 years 
with very limited success


According to https://www.google.com/intl/en/ipv6/statistics.html, it 
looks like we’ve gone from ~0% to ~40% in 12 years. 
https://stats.labs.apnic.net/ipv6 has it around 30%. Given an Internet 
population of about 5B, this can (simplistically and wrongly) argued 
to mean 1.5-2B people are using IPv6. For a transition to a technology 
that the vast majority of people who pay the bills will neither notice 
nor care about, and for which the business case typically needs 
projection way past the normal quarterly focus of shareholders, that 
seems pretty successful to me.


But back to the latest proposal to rearrange deck chairs on the IPv4 
Titanic, the fundamental and obvious flaw is the assertion of 
"commenting out one line code”. There isn’t “one line of code”. There 
are literally _billions_ of instances of “one line of code”, the vast 
majority of which need to be changed/deployed/tested with absolutely 
no business case to do so that isn’t better met with deploying 
IPv6+IPv4aaS. I believe this has been pointed out numerous times, but 
it falls on deaf ears, so the discussion gets a bit tedious.


Regards,
-drc

Had the titanic stayed afloat some hours more, many more would have 
survived and been rescued when assistance eventually arrived. So that 
makes this a debate over whether this is deck chair re-arrangement or 
something more meaningful.


As I and others have pointed out, it depends on how it is used. And 
perhaps the attempt should be made regardless of knowing in advance 
which it will be.


You assertion needs some back of the envelope numbers, which once 
provided, I suspect will render your estimate grossly incorrect.


You can hardly attempt to convince anybody that 240/4 as unicast would 
not be the more trivial change made in any of these products natural 
life cycle points.


Especially as we have examples of what that type of effort might look 
like. IGTFY and here


https://lore.kernel.org/lkml/20080108011057.ga21...@cisco.com/

The burdensome position is ridiculous even more so when stated with a 
straight face.


Joe

Re: Alternative Re: ipv4/25s and above Re: 202211210951.AYC

[Joe Maimon]

Eric,

I appreciate your willingness to actual consider this rationally.

Every facet of this debate has been fully aired on this forum (and 
others), numerous times.


Allow me to pick it apart again. Apologies to those who are ad nausem.

Eric Kuhnke wrote:
Option A) Spend engineering time and equipment purchases to implement 
240/4 as unicast globally. At present consumption rates and based on 
the number of entities in ARIN, RIPE, APNIC regions that could 
*immediately* take /18 to /16 sized blocks of it, please quantify 
exactly how many years this amount of "new" IP space you predict to be 
useful before once again reaching ipv4 exhaustion. End result: Problem 
not solved. Thus my analogy of building a sand castle while the tide 
is coming in.


Option B) Spend engineering time and equipment purchases (yes, very 
possibly much more time and more costly) to implement ipv6.


This is know a false dichotomy. There is no actual reason to believe 
that any effort on option A detracts from available effort of option B. 
And when you purchase your new gear, or update the software, with its 
many many lines of code changes, it is not unreasonable to expect that 
at least some might be IPv4 related and that the removal of restriction 
on 240/4 would be the more trivial of those.


Indeed that is exactly what has been happening since the initial 
proposals regarding 240/4. To the extent that it is now largely 
supported or available across a wide variety of gear, much of it not 
even modern in any way.


Further, presentment of options in this fashion presumes that we have 
some ability to control or decide how engineering efforts across the 
entirety of the internet should be spent.


Respectively, amusing and alarming.

To be clear, the only thing preventing the Internet in freely organizing 
its own efforts is the unwillingness of curmudgeons to remove the 
reserved status in this particular instance.


As no-one is requesting that you (or others of this persuasion) lend 
their personal efforts, your concern on the budgeting of efforts is out 
of place and worse, of dictatorial bend.


For the sake of argument, ignoring above, presuming our control over the 
internet engineering efforts et al.


Were I to propose to you that 240/4 be utilized only for new or existing 
organizations with less than /20 total resources or some other useful 
constraint, it would be easy to see that 240/4 would last a very long 
time and potentially have quite a significant impact.


Earlier in this thread I contrasted a reduction from 12 to 1 of ip 
address consumption per new customer, depending on the practices 
employed by the service provider. As you can see, consumption rate is 
actually quite flexible, even now, today.


So the answer to your question is it depends how freely it is handed 
out. Certainly not very long if it is business as usual prior to runout. 
Potentially much longer if not.


And in a nod to your concern over effort expenditure, but even more so, 
conscious of 240/4 being the 32bit space last big easy gasp, I would be 
a strong proponent that it NOT be.


However, even if it were, what exactly are we saving it for, if not for 
use by those who need it?


Or is it to be a hedge over some eventuality where IPv6 has failed to 
the point of abandonment? I might actually respect that position, even 
as I doubt (and fear and hope against) such an eventualities actual 
occurrence.


The more galling aspect of the 240/4 wars is that "it will take too long 
and then Ipv6 will be deployed" crowd that managed to stifle it 
initially continue to reuse that line again, in essence blase self 
perpetuation.


Its only taking that long because of this attitude.

Joe

Re: Alternative Re: ipv4/25s and above Re: 202211210951.AYC

[Joe Maimon]

Eric Kuhnke wrote:
Quite simply, expecting the vast amount of legacy ipv4-only equipment 
out there in the world that is 10, 15, 20 years old to magically 
become compatible with the use of 240/4 in the global routing table is 
a non viable solution. It is not a financial reality for many small to 
medium sized ISPs in lower income countries.


The amount of time and effort that would be required to implement your 
proposal is much better spent on ipv6 implementation and various forms 
of improved cgnat.


In specific focus on 240/4

Simultaneously claiming that enabling 240/4 as unicast involves 
difficulty that in comparison makes IPv6 (and then you add in CGNAT!) 
somehow more achievable is ridiculous.


Regardless of the exact scenario.

Joe

Re: ipv4/25s and above

[Joe Maimon]

Mark Tinka wrote:



On 11/17/22 19:55, Joe Maimon wrote:



You could instead use a /31.


We could, but many of our DIA customers have all manner of CPE's that 
may or may not support this. Having unique designs per customer does 
not scale well.


its almost 2023. /31 support is easily mandatory. You should make it 
mandatory.


How many customer addressing designs does that total, 2? So that would 
be 1 more than you have already? Dont buy it.


Its 2023, your folk should be able to handle addressing more advanced 
than from the 90s. And your betting the future on IPv6?






Or private/enterprise-private


Yeah, don't like that, although I understand why some operators use it.


The only issue with it is traceroute although that isnt necessarily a 
problem.


And the CPE sourced traffic should either be all internal or sourced 
from the loopback.


OTOH CoPP protection becomes a lot easier when fewer of the CP 
addressing is globally routed.





or unnumbered and route them the single /32 to use for their NAT on 
say a loopback interface.


Same as the CPE issue I described above.


Truth is the real issue isnt CPE support, its user support. Most 
users(even their "IT" folk) really cant wrap their brain around more 
than the bare basic concepts, if that much.


And you can simply say, IPv4 is limited, this is the base model 
addressing included with the service, if your inabilities are preventing 
you from using networking techniques that have been standardized and 
usable for decades, then feel free to pony up for either for your 
comfort level or for support of your inabilities.




To be honest, we'll keep using IPv4 for as long as we have it, and for 
as long as we can get it from AFRINIC. But it's not where we are 
betting the farm - that is for IPv6.


This is the crux. So long as you can obtain more, justifiable 
consumption is rewarded with additional resources, dis-incentivizing any 
addressing efficiency progress from the ancient /30 p2p + /29(or larger) 
routed block.


You may wish to lay groundwork to nibble backwards when runout occurs 
for you.


Its on Afrinic to try and preserve their pool if they wish to by doing 
things such as getting it across that progress in addressing efficiency 
is an important consideration in fulfilling requests for additional 
resources.





Your sales people are right. Since you can deliver quite usable 
service that enables them to operate just as they have before with a 
single /32, and with technical advantages to yourself, all the extra 
wasted integers should be bringing in value.


At the risk of using IP addresses to prop uo sales numbers, and then 
you run out sooner because one customer decided to pay lots of $$ for 
a /22, even when they don't need it.


If they need more, they pay more and they get more. Most of the rest of 
the world is operating or moving to operate in that fashion.


You would still require them to submit a formal request documenting 
their need. And paying more is likely to mean that its a more honest 
request.


But see the crux above. If your RiR isnt frowning on such behavior then 
its poor strategy to implement it.


Although, if you can get away with it, allocating the /30 + /29 and 
implementing it in an easy-to-clawback approach might be a good strategy.


Not the kind of potato I want to taste, because we have seen that 
proposed far too many times to know it will become a reality when the 
commissions are due.


Mark.


Thats a question of internal discipline without motivating external 
factors. Odds are those factors will arrive and I would advise 
preparedness for them.


Joe

Re: ipv4/25s and above

[Joe Maimon]

Mark Tinka wrote:


For our DIA/Enterprise business, we offer customers a /30 for p2p 
link, and a /29 as initial standard for onward assignment within their 
LAN.


You could instead use a /31. Or private/enterprise-private or unnumbered 
and route them the single /32 to use for their NAT on say a loopback 
interface. And the /29 ? I would reserve it but not assign it without a 
formal request.


Interestingly, most customers will NAT on the p2p address space, and 
barely use the onward assignment. In such cases, link migrations cause 
issues, because customers bake their internal configurations against 
those p2p IP addresses, which are pegged to specific edge routers on 
our side that can't move due to our need to minimize the iBGP 
footprint in the network. It's not a major issue in absolute terms, 
but a headache nonetheless.



See above.

We can offer customers up to a /24 maximum (i.e., we will let the /29 
expand into a /24), and no more. 


Either you have lots of fallow ground or very few customers. I dont see 
how this strategy would work elsewhere.



If they need more than a /24, time to speak to AFRINIC.

We don't charge for address space. Our Sales people want us to, but we 
don't feel it makes sense. It's not a big-enough deterrent for us to 
keep IPv4 stock. And when we do run out of IPv4 space, it will be like 
having billions of $$ on a deserted island.


Mark.

Your sales people are right. Since you can deliver quite usable service 
that enables them to operate just as they have before with a single /32, 
and with technical advantages to yourself, all the extra wasted integers 
should be bringing in value.


And since its quite nice to assign a loopback to every CPE anyways, two 
birds, one stone. Carry that in your iBGP.


Best,

Joe

Re: any dangers of filtering every /24 on full internet table to preserve FIB space ?

[Joe Provo]

On Wed, Oct 12, 2022 at 11:51:13AM -0400, Jon Lewis wrote:
[snip]
> And just for the record, despite having been bitten by it more than 
> once, I'm very much in the camp of "if you advertise a covering 
> aggregate, you're offering to get packets there, regardless of whether or 
> not more specifics exist."  You have no business demanding what routes 
> someone else's network receives/accepts.  All you can reasonably control 
> is what you advertise and what you accept.
 
This. People will come up with all sorts of creative 
topologies, and as long as they are *internal* that's
A-OK. The distance outside of one's AS one can expect
"interesting" TE to travel is equivalent to the reach
of your $s and/or contracts.

Cheers,

Joe

-- 
Posted from my personal account - see X-Disclaimer header.
Joe Provo / Gweep / Earthling 

Re: Facebook down?

[Joe Loiacono]

Well, makes sense. According to Schrodinger it's both up and down.

On 8/11/2022 5:16 PM, Michael Thomas wrote:


On 8/11/22 2:12 PM, Mel Beckman wrote:

According to Heisenberg, it’s up :)


It's still having problems serving up images. Thankfully their ad 
images are not affected :/


Mike



-mel via cell


On Aug 11, 2022, at 1:44 PM, Michael Thomas  wrote:

And of course the act of sending this mail caused the wave function 
to collapse and it seems to be up again, at least for me.


Mike


On 8/11/22 1:37 PM, Michael Thomas wrote:
They haven't been serving up images for like an hour or so and now 
it's showing their fail whale. Not sure if it's a (internal) 
network problem or not.


I'm in California fwiw.

Mike

Re: Scanning the Internet for Vulnerabilities

[Joe Maimon]

Matt Palmer wrote:

On Mon, Jun 20, 2022 at 02:18:30AM +, Mel Beckman wrote:

When researchers, or whoever, claim their scanning an altruistic service,
I ask them if they would mind someone coming to their home and trying to
open all the doors and windows every night.

If there were a few hundred people with nefarious intent trying to open your
doors and windows every night, someone doing the same thing with altruistic
intent might not be such a bad thing.

- Matt



Yall seem to be saying the same thing.

So long as it blends into the general IPv4 background radiation, all good.

Joe

Re: Congrats to AS701

[Joe Loiacono]

FiOS from Maryland (anonymized):

enp3s0: flags=4163  mtu 1500
    inet 192.168.1.164  netmask 255.255.255.0  broadcast 192.168.1.255
    inet6 fe80::b104:8f4d:e5b2:e13b  prefixlen 64  scopeid 0x20
    inet6 2600:4040:b27f:cb00:a9b1:5f59::  prefixlen 64  
scopeid 0x0
    inet6 2600:4040:b27f:cb00:24a8:7b31::  prefixlen 64  
scopeid 0x0
    inet6 2600:4040:b27f:cb00:e1b6:8b83::  prefixlen 64  
scopeid 0x0

    ether d0:67:e5:23:ec:fe  txqueuelen 1000  (Ethernet)
    RX packets 2518066  bytes 1448982813 (1.4 GB)
    RX errors 0  dropped 0  overruns 0  frame 0
    TX packets 2157395  bytes 260073952 (260.0 MB)
    TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

a@b:~$ ping 2607:f8b0:4004:c09::6a
PING 2607:f8b0:4004:c09::6a(2607:f8b0:4004:c09::6a) 56 data bytes
64 bytes from 2607:f8b0:4004:c09::6a: icmp_seq=1 ttl=59 time=24.0 ms
64 bytes from 2607:f8b0:4004:c09::6a: icmp_seq=2 ttl=59 time=17.6 ms
64 bytes from 2607:f8b0:4004:c09::6a: icmp_seq=3 ttl=59 time=20.4 ms
64 bytes from 2607:f8b0:4004:c09::6a: icmp_seq=4 ttl=59 time=23.4 ms
^C
--- 2607:f8b0:4004:c09::6a ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 17.618/21.351/23.983/2.555 ms


On 6/12/2022 1:55 PM, Christopher Morrow wrote:



On Sat, Jun 11, 2022 at 11:03 PM Darrel Lewis (darlewis) 
 wrote:


I, for one, am having a hard time finding the proper words to
express the joy that I am feeling at this momentous moment!


It's quite amazing, I think... that it's taken so long to get to 
deployment you can actually see on the fios plant :)
I'd note I can't see the below on my homestead, but I can at a 
relative's (where the ifconfig data is from).


I also can't tell if the upstream will PD a block to the downstream... 
and the VZ CPE is 'not something I want to fiddle with',
because everytime I have tried at my house I've just taken it out 
behind the woodshed with a maul... and replaced it with
something I CAN configure successfully. (plus.. don't want that TR 069 
in my home...)


-chris

-Darrel


On Jun 11, 2022, at 7:05 PM, Christopher Morrow
 wrote:



Looks like FIOS customers may be getting ipv6 deployed toward
them, finally:

ifconfig snippet from local machine:
        inet6 2600:4040:2001:2200:73d2:6bcc:1e6b:43a1  prefixlen
64  scopeid 0x0
        inet6 2600:4040:2001:2200:e87:bf36:b6cb:6ce1  prefixlen
64  scopeid 0x0

ping attempt:
  64 bytes from bh-in-f106.1e100.net
 (2607:f8b0:4004:c09::6a):
icmp_seq=1 ttl=59 time=8.71 ms

8ms from mclean, va to ashburn, va isn't wondrous, but at least
it's ipv6 (and marginally faster than ipv4)

Congrats to the 701 folk for deploying more widely!
  (note: I don't know exactly when this started, nor how wide it
really is, but progress here is welcomed by myself at least :) )
-chris

Re: Free-ish Linux Netflow collector/analyser options

[Joe Loiacono]

Try FlowViewer (analyzing, graphing, tending software) + SiLK (robust, 
high-performance capture software from Carnegie-Mellon).


Pretty full netflow analysis package; free.

See: http://flowviewer.net

Joe

On 5/16/2022 2:34 PM, Matthew Crocker wrote:


I’m looking for a free-ish Linux open sources Netflow 
collector/analyser.  I have 5 Juniper MX routers that will send IPFIX 
flows to for an ISP network.    I’m hoping it is something I can run 
in AWS/EC2 as I don’t want to worry about storage again in my 
lifetime.  Does anyone have any recommendations?


For reporting I would like to generate basic  usage reports to/from 
IP/Subnet/ASN.  It would be great if it could also detect DDoS and 
activate flowspec back into my core routers but that isn’t a requirement


Thanks

-Matt

Court orders for blocking of streaming services

[Joe Greco]

Greetings -

Recently, a court issued a troubling set of rulings in a default decision
against "Israel.TV" and some other sites.

https://storage.courtlistener.com/recap/gov.uscourts.nysd.572373/gov.uscourts.nysd.572373.49.0.pdf

https://storage.courtlistener.com/recap/gov.uscourts.nysd.572374/gov.uscourts.nysd.572374.49.0.pdf

https://storage.courtlistener.com/recap/gov.uscourts.nysd.572375/gov.uscourts.nysd.572375.53.0.pdf

While the issue of domains being confiscated and being handed over to a
prevailing plaintiff for an international domain with no obvious nexus
to the United States by a United States court via orders to companies
that happen to be in the United States is a bit of a concerning issue,
that's not operationally relevant.

What's more concerning is that the ruling includes an expansive clause
B, "Against Internet Service Providers (ISPs):"

IT IS FURTHER ORDERED that all ISPs (including without
limitation those set forth in Exhibit B hereto) and any
other ISPs providing services in the United States shall
block access to the Website at any domain address known
today (including but not limited to those set forth in
Exhibit A hereto) or to be used in the future by the
Defendants (.Newly-Detected Websites.) by any technological
means available on the ISPs. systems. The domain addresses
and any NewlyDetected Websites shall be channeled in such
a way that users will be unable to connect and/or use the
Website, and will be diverted by the ISPs. DNS servers
to a landing page operated and controlled by Plaintiffs
(the .Landing Page.) which can be reached as follows:

This expansive clause basically demands that ISP's implement a
DNS override in recursers, which may be dubiously effective given
things such as DNSSEC and DNS-over-HTTPS complications.  This is
not an insignificant amount of work to implement, and since they
have not limited the list to big players, that means us small guys
would need to do this too.

Perhaps more worryingly is the clause "by any technological means
available," which seems like it could be opening the door to 
mandatory DPI filtering of port 53 traffic, an expensive and dicey
proposition, or filtering at the CPE for those who run dnsmasq on
busybox based CPE, etc., etc.

This seems to be transferring the expense of complying to third
parties who had nothing to do with the pirate sites.

Complying with random court orders where there isn't even a formal
notice that there's been a court order is problematic.  I would
guess that the 96 ISP's listed in the order are going to receive a
formal notice, but by what mechanism does the court think that a
small service provider would even be aware of such an order?

What happens with respect to the "Newly Detected Websites"?  What
mechanism exists here?

Who is going to pay for the costs?

And how is this practical when this scales to hundreds or thousands
of such rulings?

It seems to me like the court overstepped here and issued a ruling
that contained a lot of wishful thinking that doesn't reflect the
ability of miscreants on the Internet to just rapidly register a new
domain name with a new fake credit card.  Certainly it is trivial
to host the actual websites well out of legal reach of US courts, 
and with domain registrars without US presence.  This leaves those
of us in the network operations community in the position of
shouldering costs to comply with a court order, but without a clear
mechanism to continue to be in compliance.  This could become a full
time job, if the defendants want to play the game right.  "israel.tv"?
"1srael.tv" (with a "1" or "L" for the first letter, etc).

Is anybody here considering recovering compliance costs from the
plaintiffs?

... JG
-- 
Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net
"The strain of anti-intellectualism has been a constant thread winding its way
through our political and cultural life, nurtured by the false notion that
democracy means that 'my ignorance is just as good as your knowledge.'"-Asimov

Comcast/Florida

[Joe Carroll]

Anyone have insight into what’s happening with Comcast in Florida today?
Massive outages…

Re: Any sign of supply chain returning to normal?

[Joe Freeman]

Basically, anything that uses Broadcom or other commodity silicon is
currently 55+ weeks out according to most of the vendors I work with.
Custom Silicon is a bit better or so I'm told, but I've not had to order
much gear with custom silicon lately, so I've not got a clear read on lead
times there.

I wouldn't be surprised to see some recent gear go End of Sales early just
because of component shortages and fabs moving to produce the more
in-demand parts over older less profitable parts.



On Fri, Apr 22, 2022 at 8:25 AM Drew Weaver  wrote:

> I’m not sure if this is the right place for this discussion but I can’t
> think of anywhere better to ask.
>
>
>
> Has anyone seen any progress whatsoever on supply chain issues with
> networking hardware?
>
>
>
> I’ve noticed that primary market lead times have been increasing and at
> the same time secondary market pricing has also been going higher at the
> same time, still.
>
>
>
> What have you seen?
>
>
>
>
>
>
>

Re: V6 still not supported

[Joe Maimon]

Jared Brown wrote:

JORDI PALET MARTINEZ via NANOG wrote:

If I'm a gamer, and one of my possible ISPs is using CGN, and from time to time 
stops working, and another ISP is providing me a public and/or static IPv4 
address, always working, and there is not too much price difference, what I 
will do?

Changing providers only works in a competitive market, but even there a little 
bit of market segmentation isn't necessarily a bad thing.

The main thing is that ISPs should not be so accommodating to these 
malfeasants, who via their practices make a bad situation worse. Sony et al. 
are externalizing costs and that shouldn't be accepted.


- Jared


Like most things of this nature, there is a tipping point. Where exactly 
it is, either individually or communally, and whether it is ever reached 
is typically only viewable via hindsight.


Service providers tend to be on  the "make it work" side of things, 
whether due to historical reasons or their users expectations or the 
nature of any technology centered business. Usually its more efficient 
and even cost effective to just fix it if you can. And yes, that is a 
self-reinforcing cycle.


But everything has its limits.

Increasing NAT, IPv4 re-use, IPv6 is likely to push the point away from 
Network-Address-as-Customer-Identity from being the service provider's 
responsibility.


Joe

Re: V6 still not supported

[Joe Greco]

On Mon, Apr 04, 2022 at 04:24:49PM +0200, JORDI PALET MARTINEZ via NANOG wrote:
> Related to the LEA agencies and CGN:
> 
> https://www.europol.europa.eu/media-press/newsroom/news/are-you-sharing-same-ip-address-criminal-law-enforcement-call-for-end-of-carrier-grade-nat-cgn-to-increase-accountability-online

And how is this really horribly different than all the Napster crap
where the "owner" of an ISP account got blamed for the activities of
a family member or guest?

Maybe the LEA agencies need some better clue.  I'm fine with them
advocating for IPv6, but I have a suspicion that IPv6 is just another
can of worms, because when you have "an IPv4 internets worth of
internets" (64 bits) available as the host portion of an IPv6 address,
and stuff like RFC 4941, they're going to continue to mistarget the
account owner even in the absence of CG-NAT.

Finding a law enforcement compatible method of who generated traffic
currently ends up being an exercise in keeping detailed logs.  Which
could be done with CG-NAT.  Which makes the referenced article an
example of a failure to understand the true (and horrifying) nature
of the problem of traffic attribution.

Doesn't even begin to touch on pwnage issues.

... JG
-- 
Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net
"The strain of anti-intellectualism has been a constant thread winding its way
through our political and cultural life, nurtured by the false notion that
democracy means that 'my ignorance is just as good as your knowledge.'"-Asimov

Re: V6 still not supported

[Joe Maimon]

JORDI PALET MARTINEZ via NANOG wrote:

No, isn't only a Sony problem, becomes a problem for every ISP that has customers using 
Sony PSN and have CGN (NAT444), their IP blocks are black-listed when they are detected 
as used CGN. This blocking is "forever" (I'm not aware of anyone that has been 
able to convince PSN to unblock them). Then the ISP will rotate the addresses that are in 
the CGN (which means some work renumbering other parts of the network).

You do this with all your IPv4 blocks, and at some point, you don't have any "not 
black-listed" block. Then you need to transfer more addresses.

So realistically, in many cases, for residential ISPs it makes a lot of sense 
to analyze if you have a relevant number of customers using PSN and make your 
numbers about if it makes sense or not to buy CGN vs transfer IPv4 addresses vs 
the real long term solution, which is IPv6 even if you need to invest in 
replacing the customer CPEs.


Regards,
Jordi
@jordipalet
  


I would expect the trend to become that ISP's refuse to accommodate 3rd 
party vendors shenanigans to the point where it hampers their operations 
or to the point where it cost them more to do so.


Likely, they would sooner tell the customer that their vendor (whom they 
pay money) is blocking the ISP and that there must a) deal with their 
vendor and/or b) pay/use a dedicated static IP


Because as you point out, its impossible to support this trend after a 
certain point, and really, why should you?


With enough of that attitude, the trend reverses and vendors will have 
to start using other mechanisms, perhaps even ones where cooperation 
with the SP is a possibility.


Joe

Re: Let's Focus on Moving Forward Re: V6 still not supported re: 202203261833.AYC

[Joe Maimon]

Owen DeLong wrote:


Yep… He’s absolutely right… We need to find a way to get the networks that 
aren’t deploying IPv6 to
get off the dime and stop holding the rest of the world hostage in the IPv4 
backwater.

Owen




You keep championing that approach, essentially unchanged for the past 
20 years with an impressive record of partial success and much failure 
and I will fully support and applaud your efforts in doing so. I will 
also hope that it doesnt take another 20 to finally succeed, because as 
you point out, you require an extremely high level of participation 
before its Mission Accomplished.


And its not unreasonable to expect that until that approach succeeds, 
that others' efforts to work on the ongoing problem receive the same 
support and encouragement.


IPv6 uber-alles adherents had more than enough time to claim it was 
going to solve the problem without any need for anything else and to 
"request" (quite strongly and wrongly so in my opinion) that everyone 
rally their efforts around that.


Now its time for those adherents to reciprocate.

And here is a little bit of constructive criticism to the Evangelical 
approach. Essentially, you need to pivot from how their efforts can save 
the world into how their efforts can benefit themselves.


You want more people to use IPv6? Make it worth their while. Lower the 
barriers the cost the risks and increase the bennies.


The early adopters, the activists, those who define themselves by their 
altruism you already got.


Dont be surprised when so many balk at doing things they have no 
particular defined need or interest in doing when the primary 
beneficiaries arent themselves, but the primary cost carriers are.


Or we can just wait and see how the natural course of events eventually 
plays out. Still looks likely that IPv6 will eventually take over the 
internet, but it sure would be nice if IPv4 did not become completely 
unusable before that manages to occur.


Joe

Re: DMARC ViolationAS21299 - 46.42.196.0/24 ASN prepending 255 times

[Joe Maimon]

Matthew Petach wrote:




Unfortunately, the reason crazy-long prepends actually propagate so
widely in the internet core is because most of those decisions to prefer
your peer's customers are done using a relatively big and heavy hammer.


IOW if your peer or customer has prepended 5 times or more, dont 
LOCAL_PREF or maybe even de-LOCAL_PREF it





For the most part--if you think LOCAL_PREF is the right knob to use 
for moving
traffic, it probably means you need to go back and rethink your 
traffic engineering

approach.   ^_^;

Matt


I think more and perhaps different knobs were and still are needed.

Here is an idea, as part of the all extra processing updates have to go 
through nowadays, how about a long call back to each AS in the path 
using some sort of standardized service, perhaps published via DNS, sort 
of an automated looking glass results compared to update-out. And then 
the receiver, however many AS's away starts to get a much clearer 
picture of the intent all the through and maybe perhaps some much better 
intelligent automated properly reactive internet wide traffic 
engineering standards will emerge.


Until then I think a slew of standardized communities that elicit near 
universal and predictable standard reactions is probably the best bet. 
The problem is that shifting too much control to the advertiser makes it 
a non-starter from the point of view of the receiver, and then you can 
forget about deployment.


Would be nice to be able to publish your community scheme as simply 
conforming with RFCX and the to configure peers with process-rfcX 
statement and be mostly done.


Joe

Re: Let's Focus on Moving Forward Re: V6 still not supported re: 202203261833.AYC

[Joe Maimon]

Matthew Petach wrote:



In short, at the moment, you *can't* deploy IPv6 without also having IPv4
somewhere in your network.  IPv6 hasn't solved the problem of IPv4
address shortage, because you can't functionally deploy IPv6 without
also having at least some IPv4 addresses to act as endpoints.

For the people who already have IPv4 addresses to say "hey, that's
not a problem for us" to everyone who can't get IPv4 addresses is
exactly the problem warned against in section 6 of 
https://datatracker.ietf.org/doc/html/rfc7282:


"
6 <https://datatracker.ietf.org/doc/html/rfc7282#section-6>. One 
hundred people for and five people against might not be rough

consensus

Section 3 <https://datatracker.ietf.org/doc/html/rfc7282#section-3>  
discussed the idea of consensus being achieved when
objections had been addressed (that is, properly considered, and
accommodated if necessary).  Because of this, using rough consensus
avoids a major pitfall of a straight vote: If there is a minority of
folks who have a valid technical objection, that objection must be
dealt with before consensus can be declared. "
The point at which we have parity between IPv4 and IPv6 connectivity 
is the point
at which we can start to talk about sunsetting IPv4 and declaring it 
historic, and
no longer concern ourselves with address exhaustion.  Until then, so 
long as
being able to obtain IPv4 addresses is a mandatory step in being 
functional on
the internet, it is unreasonable to say that the address exhaustion 
problem is

"solved."

Matt



I dont know how many ways and times this needs to be said, but you said 
it quite well.


Joe

Re: DMARC ViolationAS21299 - 46.42.196.0/24 ASN prepending 255 times

[Joe Maimon]

Joe Provo wrote:

On Fri, Mar 25, 2022 at 11:08:01AM +0300, Paschal Masha wrote:

:) probably the longest prepend in the world.

A thought though, is it breaking any standard or best practice procedures?


That said, prepending pretty much anything more than your current view
of the Internet's diameter in ASNs is useless in practice. Cascading
effects are considered in
https://datatracker.ietf.org/doc/draft-ietf-grow-as-path-prepending/
where a decent low number (5) is propsed.

Chers,

Joe
  


So is there a good way to signal along with a BGP route that the 
originator of the route wants you to know that this route has very high 
suckage factor and even if you normally prefer your peers customers 
whatever, you should perhaps think twice about that for this route, 
cause its really last resort.


Because as-path is an overloaded multimeaning traffic influencing hammer 
that has imprecise and frequently undesirable results. And if that were 
not the case, than discussions of its relative size compared to internet 
diameter would be much more relevant.


Joe

Re: Cogent ...

[Joe Greco]

On Thu, Mar 31, 2022 at 03:38:15PM +, Laura Smith via NANOG wrote:
> However, perhaps someone would care to elaborate (either on or off-
> list) what the deal is with the requirement to sign NDAs with Cogent 
> before they'll discuss things like why they still charge for BGP, or 
> indeed any other technical or pricing matters. Seems weird ?!?

Because they know that the sillier bits will be poked fun at on NANOG
if they allow them to be disclosed?

Because if you can't talk about your pricing, then they aren't as 
likely to be facing customers who know how cheap it was sold to some
other party?

... JG
-- 
Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net
"The strain of anti-intellectualism has been a constant thread winding its way
through our political and cultural life, nurtured by the false notion that
democracy means that 'my ignorance is just as good as your knowledge.'"-Asimov

Re: Let's Focus on Moving Forward Re: V6 still not supported re: 202203261833.AYC

[Joe Maimon]

Tom Beecher wrote:


If the IETF has really been unable to achieve consensus on properly
supporting the currently still dominant internet protocol, that is
seriously problematic and a huge process failure.


That is not an accurate statement.

The IETF has achieved consensus on this topic. It's explained here by 
Brian Carpenter.


https://mailarchive.ietf.org/arch/msg/int-area/qWaHXBKT8BOx208SbwWILDXyAUA/


As I have explained with my newly introduced consensus standards, there 
is no such consensus.


To reiterate my consensus standards, consensus is only to be considered 
as amongst stakeholders and IPv6 specific related stakes are not 
relevant to IPv4. If you consider the reverse to be true as well, I 
think my version of consensus would achieve a much wider and diverse 
consensus than the the stated IETF's consensus.


Once a consensus has been proven invalid its beyond obnoxious to cling 
to it as though it maintains its own reality field.




He expressly states with many +1s that if something IPv4 related needs 
to get worked on , it will be worked on,


IPv4 still needs address exhaustion solutions.

but the consensus solution to V4 address exhaustion was IPng that 
became IPv6, so that is considered a solved problem.


IPv6 is not a solution. Its a replacement that does not have the same 
problem. Which could be a solution to the problem, but only if the 
replacement happens on schedule. However, so long as the replacement 
hasnt happened, we still are dealing with the problem.


The IETF made a stupendously bad bet that IPv6 would happen in time. 
That is the kind of bet that you better be right about. They were a 
decade+ wrong. That they have the audacity and temerity to continue 
doubling down on that would be funny if it wasnt so outrageous, wrong 
and harmful.


Let us re-examine the premise. When did it become acceptable to quash 
work on one protocol because of the existence of another one that is 
preferred by the quashers?


Or in other words, the way you are framing things makes it seem as if 
the IETF has with intent and malice chosen to extend or at the very 
least ignore exhaustion issues for actual internet users so as to rig 
the system for their preferred outcome.




Some folks don't LIKE the solution, as is their right to do.


I agree. I like most of IPv6 just fine. Not SLAAC, not multicast l2 
resolution, not addressing policy, not the chaos of choice of inadequate 
interoperability approaches, not the denial of features desired by 
users, not the pmtud, not the fragmentation, and many other warts. I 
dont even like the notation schemes. They require multiple vision passes.


I do like the extra bits. Just not the way they are being frittered.

The real crux of the matter is that it did not work. Address exhaustion 
has not been alleviated. For many years now and who knows how much longer.


But the problem of V4 address exhaustion is NOT the same thing as "I 
don't like the solution that they chose."


The problem of V4 address exhaustion is NOT the same thing as turn on 
IPv6 and wait for the rest of the world to do the same.


When considered in that manner the IETF's bet looks even worse.

What I dont like is that they were wrong. What I dislike even more is 
that they refuse to admit it and learn from their mistakes.


Joe

On Wed, Mar 30, 2022 at 12:18 PM Joe Maimon <mailto:jmai...@jmaimon.com>> wrote:




Owen DeLong via NANOG wrote:

>
> Well… It’s a consensus process. If your idea isn’t getting
consensus,
> then perhaps it’s simply that the group you are seeking
consensus from
> doesn’t like your idea.



Consensus processes are vulnerable to tyranny of a well positioned minority.

Joe

Re: PoE, Comcast Modems, and Service Outages

[Joe Greco]

On Wed, Mar 30, 2022 at 05:52:06PM +, Livingood, Jason wrote:
> >  Their crappy equipment needing rebooting every few weeks, not ridiculous.
> > Their purchasing gear from incompetent vendors who cannot be standards
> compliant for PoE PD negotiation, tragically plausible.
> 
> Many customers buy their own cable modem. You can lease an Xfinity 
> device as well and those function pretty nicely these days but YMMV. 
> But typically a device reboot is a way to quickly solve a few 
> different kinds of problems, which is why techs will often recommend 
> it as an initial step (you can generally assume that there's data 
> behind what occurs when any one of tens of thousands of support reps 
> suggesting something to a customer - support at scale is data-driven).

No one's doubting all of that -- support is best when data-driven, scale
or otherwise.  But that's actually the issue here.  There's no data that
I know of to suggest widespread PoE ghost current buildups, and, given
the audience here, no one else has popped up with a clear "me too".

PoE is typically negotiated by modern switches, 24v Unifi special
jobbies aside, so it's all DC on cables that are already handling
differential signalling.

> >He's got graphs showing it every 24 hours?  Liar, liar, pants on fire,
> lazy SOB is looking for an excuse to clear you off the line.
> 
> Could well be from noise ingress - lots of work goes into finding & 
> fixing ingress issues. Hard to say unless we look in detail at the 
> connection in question and the neighborhood node.

No doubt.  There's huge amounts of room for problems to be introduced
into last mile networks.  But, again, this isn't about general problems.
This is about a tech claiming it's due to PoE, and that he's seen it
often before.

I certainly have a lot of sympathy for cable techs, but that doesn't
mean I want to swallow any random garbage they want to blame issues on.
Please just tell me it's the chipmunks getting feisty and nibbling on
the copper if you want to feed me a line...

... JG
-- 
Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net
"The strain of anti-intellectualism has been a constant thread winding its way
through our political and cultural life, nurtured by the false notion that
democracy means that 'my ignorance is just as good as your knowledge.'"-Asimov

Re: Let's Focus on Moving Forward Re: V6 still not supported re: 202203261833.AYC

[Joe Maimon]

Owen DeLong via NANOG wrote:
What you’re really complaining about is that it’s been virtually 
impossible to gain consensus to move anything IPv4 related forward in 
the IETF since at least 2015.


Well… It’s a consensus process. If your idea isn’t getting consensus, 
then perhaps it’s simply that the group you are seeking consensus from 
doesn’t like your idea.


If the IETF has really been unable to achieve consensus on properly 
supporting the currently still dominant internet protocol, that is 
seriously problematic and a huge process failure.


When vendors do that sort of thing people get up in arms. When open 
source projects do that sort of thing, they get forked. When community 
grassroots governance bodies do that sort of thing, I dont want to find out.


Responsible stewardship of internet community standardization would be 
excluding IPv6 strategic concerns from considerations of consensus on 
IPv4 issues.


In other words, if the only issues you can bring to bear on any matter 
pertaining solely to IPv4 is all about IPv6, your not relevant to the 
process and should be struck from the record.


I would even go so far as to say that you are actually poisoning the 
process.




Your inability to convince the members of the various working groups 
that your idea has merit isn’t necessarily a defect in the IETF 
process… It might simply be a lack of merit in your ideas.


Owen


This part is very good advice, perhaps restated as a lack of merit in 
the idea when combined with much wider and diverse perspectives.


On the other hand, with no record and history of ideology driven 
agendas, the IETF process would be a whole lot more trustworthy.


Joe

Re: PoE, Comcast Modems, and Service Outages

[Joe Greco]

On Tue, Mar 29, 2022 at 03:42:54PM -0400, Josh Luthman wrote:
> There's a certain manufacturer of TDD radio where the CPU clock is at the
> same frequency as what Verizon's enodeB will transmit.  Even at miles away,
> it can and will cause PIM issues.  Again, don't rule it out.

I'm not ruling anything out, but on the flip side, here in this group 
of professional networkers, you'd think lots of people would have piped
up by now with "me too"'s if PoE ghosts killing cable CPE on a 24 hour
cycle were a common thing.

> Maybe he's just looking for a simple answer that 99% of callers will accept
> and it makes them happy.  When a customer of mine tells me they think it's
> something and I know it's off, I just let them believe in their statement.

I'm unclear on how this is making the caller happy.

I'm trying to envision under what circumstances a customer site that has
purchased PoE switches, presumably to power PoE gear, would be delighted
to hear that their not-directly-connected PoE gear would need to be
removed, presumably replaced, and then, what?  Run extension cords and
bricks to all the access points, IP phones, cameras, door terminals, 
and other PoE-powered gear?

> There's no reason to go after this tech and insult him, 

I'd agree it isn't sporting, but on the other hand, a poster here asked
for an evaluation.  I did not immediately blow it off, but instead
tossed out some thoughts for consideration.  Then blew it off.  But I
am still pondering the issue.

> all that's doing is making everyone miserable.

I am guessing lots of people laughed.  It's an El Reg grade tale of
woe.  I have to assume the poster who asked is frustrated but trying
to resolve a real issue.

So if you want the $100 test to eliminate PoE electrical effects, get
a pair of media converters and run fiber between them.  Put the CPE on
the far end.  Optimize as appropriate if you have SFP-capable switches.

... JG
-- 
Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net
"The strain of anti-intellectualism has been a constant thread winding its way
through our political and cultural life, nurtured by the false notion that
democracy means that 'my ignorance is just as good as your knowledge.'"-Asimov

Re: PoE, Comcast Modems, and Service Outages

[Joe Greco]

On Tue, Mar 29, 2022 at 03:07:47PM -0400, Josh Luthman wrote:
> We've routinely seen where lines not even connected to the same circuit in
> any way (ie an OTA antenna coax line and cat5 POE) cause issues with one
> another.  As much as we would all love to have a perfect line in the sand,
> there isn't.  Don't rule anything out until the issue is resolved.
> 
> As someone that sees this in the field and watches people simply hate on
> someone because there's a frustrating situation, it's worth taking a breath
> before too upset.

You can run cable lines next to A/C wiring and get problems too.  Or
ethernet lines next to A/C wiring.  That does not justify wild claims
about PoE such as what this tech was making, and until someone shows
me a graph of "PoE buildups" observable via SNMP or whatever the
cable company is using to graph trends, it seems pretty clear that
this is a bogus answer.

There's a lot of difference between "we observed this very specific kind
of interference related to PoE in a particular circumstance" and the
crazy generalizations being made by the tech.  Asking to please make sure
your switch is grounded properly?  That'd be good.  Asking for PoE to be
disabled on the port?  Yeah fine.  Suggesting separation of cables? 
Sure.  Checking for proper grounding of the ground block (on the cable
inlet)?  Sure.  There's room for things to happen.

I'm all for investigating with an open mind, but I draw the line at crazy.

Given that so much of the world works on PoE, it seems like the other
potential resolution would be to note that there's an implication here
by the tech that Comcast's hardware is standards noncompliant and ask
them what they plan to replace their cheap CPE with.

... JG
-- 
Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net
"The strain of anti-intellectualism has been a constant thread winding its way
through our political and cultural life, nurtured by the false notion that
democracy means that 'my ignorance is just as good as your knowledge.'"-Asimov

Re: PoE, Comcast Modems, and Service Outages

[Joe Greco]

hat crontab is there that would clear out
such buildups in the router's daily run?  What capacitor would store up
juice for precisely 24 hours?  What's the mechanism here?  CURIOUS MINDS
WANT TO KNOW!

Been doing PoE everywhere for years and this is the stupidest thing I've
heard this year so far in the networking category.

Next time, play dumb.  People who can, do.  People who can't, tech support.
Worth remembering.

... JG
-- 
Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net
"The strain of anti-intellectualism has been a constant thread winding its way
through our political and cultural life, nurtured by the false notion that
democracy means that 'my ignorance is just as good as your knowledge.'"-Asimov

Re: A straightforward transition plan (was: Re: V6 still not supported)

[Joe Maimon]

Philip Homburg wrote:
It should be clear that an IPv4-only host only speaks IPv4. This means 
that communication with an IPv4-only host has to be IPv4.


This did not have to be true, had there been an extension/option 
standardized at the same time as IPv6 for IPv4 packets to be gateway'd 
into IPv6 transparently and efficiently (thru any dual stacked 
host/router), than at this point we would have likely been looking at 4 
classes of nodes


- IPv4 only, legacy, requires translation to communicate directly with ipv6

- IPv4 only, extended, just needs a gateway to communicate directly with 
IPv6


- Dual Stack

- IPv6 only

Such additional functionality, could have been organically updated into 
most major OS's without any required network topology changes.


Joe

Re: Let's Focus on Moving Forward Re: V6 still not supported

[Joe Maimon]

james.cut...@consultant.com wrote:

On Mar 26, 2022, at 8:30 PM, Masataka Ohta  
wrote:

Owen DeLong via NANOG wrote:


It still looks like NAT to me.

Almost all the people, perhaps other than you, accept NAT
as is to keep IPv4 Internet or as part of transition
plan from IPv4 to IPv6.


NAT is a disgusting hack and destroys the universal peer to peer
nature of the internet in favor of a consumer/provider model.

As I repeatedly pointed out, end to end NAT is clean preserving
the universal peer to peer nature of the Internet.

https://datatracker.ietf.org/doc/html/draft-ohta-e2e-nat-00

The basic idea is to let NAT boxes perform address translations
only without adjusting check sums or translating ports and
to let end systems perform reverse address translations,
which restores correct check sums, and port number
restrictions.

Masataka Ohta

I have yet to find an economical way to manage a business merger involving two 
large rfc1918 networks where end to end peering is required and which partially 
or fully overlap. Ignoring short-sighted financial management views, the best 
long term solution is globally unique IPv6 addressing wherever possible. Local 
islands of IPv4 gatewayed or NATted with local management continue to be 
possible.


In other words, once its merger time, IPv6 fixes nothing.

Can one really incentivize an enterprise to standardize on IPv6 on the 
basis of it will make a future merger much more economical? And this is 
well before any such prospect usually exists.


Is there any activity that enterprises choose to engage in on that basis?

Joe

Re: Let's Focus on Moving Forward Re: V6 still not supported

[Joe Maimon]

John Gilmore wrote:

Tom Beecher  wrote:

*/writing/* and */deploying/* the code that will allow the use of 240/4 the
way you expect

While Mr. Chen may have considered that, he has repeatedly hand waved that
it's 'not that big a deal.', so I don't think he adequately grasps the
scale of that challenge.

>From multiple years of patching and testing, the IPv4 Unicast Extensions
Project knows that 240/4 ALREADY WORKS in a large fraction of the
Internet.


And this is without the removal of reserved status.

There is no real reason to think it would not have been practically 
universal if that had happened a decade ago.




Today Google is documenting to its cloud customers that they should use
240/4 for internal networks.  (Read draft-schoen-intarea-unicast-240 for
the citation.)  We have received inquiries from two other huge Internet
companies, which are investigating or already using 240/4 as private
IPv4 address space.


240/4 becoming a de-facto super rc1918 in its totality is actually a net-loss. Has 240/4 
been unreserved for potential global internet purposes a decade ago, much more 
constructive purposes could have been standardized as well. So all the delay is not a 
"no harm no foul" situation.


In short, we are actually making it work, and writing a spec for what
already works.  Our detractors are arguing: not that it doesn't work,
but that we should instead seek to accomplish somebody else's goals.

John


At this point, its more like you have publicly accepted all the blame 
for the current incomplete state of IPv6 by acknowledging that you chose 
to take on the daunting task of 240/4 and refused to direct yours and 
everyone you knew efforts into IPv6, which was missing only that.


Joe

Re: Let's Focus on Moving Forward Re: V6 still not supported

[Joe Maimon]

Paul Rolland wrote:

Hello,

On Sat, 26 Mar 2022 09:35:30 -0400
"Abraham Y. Chen"  wrote:


touching the hardware, by implementing the EzIP technique (*/disabling/*
the program code that has been */disabling/* the use of the 240/4
netblock), an existing CG-NAT module becomes a RAN! As to universal

Have you ever considered that this may be in fact:

*/writing/* and */deploying/* the code that will allow the use of 240/4 the
way you expect


Paul


While we cant really know, the odds are strong that there are only a few 
lines in any particular product that need to be removed or reworked. Its 
a safe expectation that its a trivial change, as far as changes go.


The bigger hurdle is deployment. All 240/4 discussions have usually 
opined that:


There is every expectation that if 240/4 reserved distinction is removed 
that any particular product still being updated would likely have such a 
change incorporated as part of its normal update process.


And that all non supported products that would not get such a change 
would over time fade away to become a very distinct minority, as they do 
normally.


There is strong evidence that this is an accurate prediction, as even 
without the removal of reserved status, mere public discussion and 
debate over the matter has been sufficient that today a large amount of 
that change has actually occurred, organically so to speak.


If IPv6 would have had such a migration strategy it would have been over 
already.


Joe

Re: V6 still not supported

[Joe Maimon]

Owen DeLong wrote:



On Mar 24, 2022, at 21:18 , James R Cutler 
mailto:james.cut...@consultant.com>> wrote:


On Mar 24, 2022, at 9:25 PM, Owen DeLong via NANOG <mailto:nanog@nanog.org>> wrote:


I think that we’re still OK on allocation policies. What I’d like to 
see is an end to the IPv4-think in large ISPs, such as Comcast’s 
continued micro allocations to their customers.


What exactly is your definition of “micro allocations”? Is a 
prefix/56 a “micro allocation”? In over nine years of being an active 
forum participant and customer of Comcast, I can not recall the usage 
of the term.


They’re issuing /60s (maximum) to residential customers.

And yes, a /56 is a micro allocation. /48 is the intended norm for 
IPv6 site assignments and is a perfectly reasonable prefix size for v6 
delegation to a site.


Owen

/48 as universal site assignments is a ridiculousness that should never 
be a norm, and unsurprisingly in the real world it isnt.


Now if your goal is to pick a number which will never change and is 
large enough to work for any assignment anywhere for any network 
topology ever, well you found it.


However, thats a solution in search of a problem. Which causes its own 
problems.


A /48 gives 16 bits of /64 subnetting for the site.

Which is the same number of bits initial default ISP /32 has. Ridiculous 
in either direction.


If you apply the same logic to ISP's that you have to end user site 
assignments (which is descended from the same logic as /64 subnets), you 
need to move left. Again. Goodbye limitless ipv6.


Or you can move right on the /64 nonsense. SLAAC does not|should not 
need /64. Or, SLAAC isnt needed at all. Chaining DHCP to SLAAC is more 
nonsense.


Joe

Re: Let's Focus on Moving Forward Re: V6 still not supported

[Joe Greco]

On Sat, Mar 26, 2022 at 12:37:59PM -0400, Tom Beecher wrote:
> >
> > Have you ever considered that this may be in fact:
> >
> > */writing/* and */deploying/* the code that will allow the use of 240/4 the
> > way you expect
> >
> 
> While Mr. Chen may have considered that, he has repeatedly hand waved that
> it's 'not that big a deal.', so I don't think he adequately grasps the
> scale of that challenge.

It seems like it should only require changes on a few billion nodes,
given the size of the IPv4 address space, right?

Oh, wait, NAT...

So I guess the question here is how do you plan to incentivize the
patching of all these devices, many of which are legacy devices with
no maintainer for the firmware/software, in roles where they may not
be accessible, and protected by firewalls that understand Class E to
be unusable space.

I am unclear on the desirability of "fixing" the IPv4 network by
touching lots of nodes, in a manner which will never be comprehensive,
in order to free up a relatively small block of space.  It's going to
be crippled, less-valuable space.  It seems to me like it'd be much
more productive, if you're going to be touching gear, to move towards
IPv6.

... JG
-- 
Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net
"The strain of anti-intellectualism has been a constant thread winding its way
through our political and cultural life, nurtured by the false notion that
democracy means that 'my ignorance is just as good as your knowledge.'"-Asimov

Re: DMARC ViolationAS21299 - 46.42.196.0/24 ASN prepending 255 times

[Joe Provo]

On Fri, Mar 25, 2022 at 11:08:01AM +0300, Paschal Masha wrote:
> :) probably the longest prepend in the world.
> 
> A thought though, is it breaking any standard or best practice procedures?

Many popular BGP implementations have historically had weaknesses 
with excessively long AS-paths. Best practice is to protect ones'
infrastructure so many networks drop paths over certain lengths
(at various times, 50 or 100 were common due to specific issues).
It is highly common for any filtering mechanism, once established,
to stay in place, so I fully expect this path to be invible to many
and fragile for the rest [see
https://blog.apnic.net/2019/07/15/excessive-bgp-as-path-prepending-is-a-self-inflicted-vulnerability/].

That said, prepending pretty much anything more than your current view
of the Internet's diameter in ASNs is useless in practice. Cascading
effects are considered in 
https://datatracker.ietf.org/doc/draft-ietf-grow-as-path-prepending/
where a decent low number (5) is propsed.

Chers,

Joe
 
-- 
Posted from my personal account - see X-Disclaimer header.
Joe Provo / Gweep / Earthling 

Re: V6 still not supported

[Joe Maimon]

Owen DeLong wrote:



You may be right about not being worth it. More importantly, you may be wrong. 
IPv6 is replete with not only a plethora of wrong predictions, but the same 
ones over and over again. To be clear, the only effort asked from the unwilling 
is to support cutting the red tape frustrating the willing. A hearty round of 
knock yourself out from the right folk in the right place and time and we dont 
have to debate this particular point ever again.

Certainly, if we continue to waste effort that is better spent deploying IPv6 
on bandaids and hacks to make v4 last just a little longer, we will continue to 
fail and further delay IPv6 reaching a level of deployment that allows us to 
start turning down IPv4 and beginning to recognize the cost savings that come 
from moving forward.


How are we to ever find out who is right if that never happens? That alone is 
enough reason for me.

The problem is that we’re not talking about parallel experiments. We’re talking 
about an optional activity which will inherently pull resources away from a 
necessary activity, thus delaying the necessary activity and becoming somewhat 
of a self-fulfilling prophecy. Hence I oppose this wasteful experiment in favor 
of doing what we all know eventually needs to be done.



I dont know what it will take to paint this nonsensical argument as any 
more patently ridiculous than has already been done. It bears no 
relationship to actual reality.


However, hypothetically, lets say thats exactly how it works.

Too Bad. You had your chance to deploy IPv6 before the pain and now you 
must tend to both protocols.


Joe

Re: V6 still not supported

[Joe Maimon]

Michael Thomas wrote:


On 3/24/22 3:13 PM, Owen DeLong wrote:



On Mar 24, 2022, at 14:46 , Michael Thomas  wrote:


On 3/24/22 1:59 PM, Owen DeLong via NANOG wrote:
Home users aren’t the long tail here. Enterprise is the long tail 
here. Android phones are,

indeed, part of the enterprise problem, but not the biggest part.

If this were a purely technical problem, we’d have been done more 
than a decade ago. The
problem is a lack of corporate “round tuits” which for each 
enterprise are in limited supply and

usually go to things that either reduce costs or increase revenue.

So long as they have public facing v6 servers is there really a 
problem? Sure you're not going to get to 100% deployment, but 
nothing is going to do that in any of our lifetimes. The object 
should be to not have to deploy tortured hacks like CGNAT. That is 
what success is IMO, and we don't from a technical standpoint.


Mike

Yes… We need them to have v6 deployed to their clients so that 
content providers can start turning off v4 where it’s costing them 
money to support it.


Well content providers could pretty easily force the issue if they 
wanted.


MIke



Content providers are rumored to dig into the single digit percentages 
of failing connections to ensure their audiences is as large as possible.


And enterprises would likely happily settle on edge solutions for v6 
only content so long as they are workable.


Joe

Re: V6 still not supported

[Joe Maimon]

Owen DeLong wrote:



On Mar 24, 2022, at 03:36 , Joe Maimon  wrote:



In my view that takes the form of a multi-pronged strategy.

Do what it takes to keep IPv4 as usable as possible for as long as possible.

I think this isn’t so much preempting the vacuum as trying to pretend we can 
survive on an hour of air for 20 years.

240/4 is way more effort than its proponents want to believe and even if it 
were reclassified effectively as GUA, it doesn’t buy all that much life for 
IPv4.


I think it should be reclassified from never going to be used into some 
part of the internet might actually do something with it. Its important 
that happens now, better late then never. Whether its GUA or not or a 
mix of whatever, whether it buys months or years will depend greatly on 
how its actually used if it is ever used.


You may be right about not being worth it. More importantly, you may be 
wrong. IPv6 is replete with not only a plethora of wrong predictions, 
but the same ones over and over again. To be clear, the only effort 
asked from the unwilling is to support cutting the red tape frustrating 
the willing. A hearty round of knock yourself out from the right folk in 
the right place and time and we dont have to debate this particular 
point ever again.


How are we to ever find out who is right if that never happens? That 
alone is enough reason for me.






Personally, that means that although I have long disliked proposals that keep 
moving to the left of the 128bit space, were I to believe it likely to increase 
deployment and momentum I would champion it in my own limited fashion much as I 
do 240/4.

Not sure what you mean by “moving to the left of the 128 bit space”.


That Ipv6 address allocation schemes and proposals tended to enlarge 
over time, using up more bits heading from right to left.




We will obviously agree to disagree about 240/4 as we long have.

Owen


To the next time then.

Joe

Re: ISP data collection from home routers

[Joe Greco]

On Thu, Mar 24, 2022 at 09:26:31AM -0400, Josh Luthman wrote:
> I'm surprised we're having this discussion about an internet device that
> the customer is using to publicize all of their information on Facebook and
> Twitter.  Consumers do not care enough about their privacy to the point
> where they are providing the information willingly.

So your theory is that just because YOU have Facebook and you're fine
sharing information (/don't care/whatever), that *I* have to suffer
that fate as well?

Perhaps you hadn't noticed, but there's a very active business in the
form of VPN's, DNS-over-HTTPS, and other privacy-enhancing technologies
that seem to indicate that people do have an interest in privacy and
limiting the amount of ISP monetization of their data that can go on.

Just because some people might be fine with their data being leaked
does not mean that everyone is fine with it.

... JG
-- 
Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net
"The strain of anti-intellectualism has been a constant thread winding its way
through our political and cultural life, nurtured by the false notion that
democracy means that 'my ignorance is just as good as your knowledge.'"-Asimov

Re: V6 still not supported

[Joe Maimon]

Mark Delany wrote:

On 23Mar22, Owen DeLong via NANOG allegedly wrote:


I would not say that IPv6 has been and continues to be a failure

Even if one might ask that question, what are the realistic alternatives?

1. Drop ipv6 and replace it with ipv4++ or ipv6-lite or whatever other protocol 
that
magically creates a better and quicker transition?

2. Drop ipv6 and extend above the network layer for the forseeable future? By 
extend I
mean things which only introduce ipv4-compatible changes: NATs, TURN, CDN 
at the edge,
application overlays and other higher layer solutions.

3. Live with ipv6 and continue to engineer simpler, better, easier and 
no-brainer
deployments?

I'll admit it risks being a "sunk cost falacy" argument to perpetuate ipv6, but 
are the
alternatives so clear that we're really ready to drop ipv6


I most assuredly hope not. However this is not actually within any 
specific bodies absolute control. The overblown representation of the 
top down nature of internet design is a significant fallacy.


If a vacuum persists and what fills that void is detrimental to IPv6 
global deployment, it would be a significant setback. But the internet 
wont care.


What you can do is try and preempt the vacuum.

In my view that takes the form of a multi-pronged strategy.

Do what it takes to keep IPv4 as usable as possible for as long as possible.

By all means, continue to evangelize users and pressure vendors. But 
thats not enough. Make IPv6 more attractive, more utilitarian, more 
useful. Address and remove barriers and hurdles. And that means doing 
and accepting things that many have significant distaste for.


Personally, that means that although I have long disliked proposals that 
keep moving to the left of the 128bit space, were I to believe it likely 
to increase deployment and momentum I would champion it in my own 
limited fashion much as I do 240/4.





so much as IPv6 has not yet achieved its goal.

As someone previously mentioned, "legacy" support can have an extremely long 
tail which
might superficially make "achieving a goal" look like a failure.


While true, thats not my concern. My concern is that continued 
dependence on functioning IPv4 by and large for the internet population 
has resulted in additional costs and constrains on the addresses 
required to utilize it. So long as that persists, so does the failure 
status of IPv6 towards the goal of alleviating it.


And thats the goal that actually matters to the internet population at 
large.


Forget ss7 and SIP, what about 100LL vs unleaded petrol or 1/2" bolts vs 13mm 
bolts? Both
must be 50 years in the making with many more years to come. The glacial grind 
of
displacing legacy tech is hardly unique to network protocols.

In the grand scheme of things, the goal of replacing ipv4 with ipv6 has really 
only had a
relatively short life-time compared to many other tech transitions. Perhaps 
it's time to
adopt the patience of the physical world?


Mark.




I agree. But that means behavioral modification towards a
much longer term outlook than has been in widespread evidence thus far.

Joe

Re: V6 still not supported

[Joe Maimon]

Mark Delany wrote:

On 24Mar22, Greg Skinner via NANOG allegedly wrote:


straightforward transition plan
in-hand working transition strategy
nor a straightforward transition

Any such "transition plan" whether "working" or "straightforward" is logically
impossible. Why anyone thinks such a mythical plan might yet be formulated some 
20+ years
after deploying any of ipv6, ipv4++ or ipv6-lite is absurd.


You are correct that there is no way to represent 128 bits inside of a 
32 bit field without modifications. Especially past the point of early 
adoption when there was still a 1:1 ratio of IPv4 and IPv6 actual 
addressing possible.


However, even transition mechanism that would have relied upon IPv4 
modifications would have had a better chance of being rolled out as part 
of normal update cycle at this point than mass deployment of IPv6 which 
requires a bit more than normal update cycle.





The logic goes: we support legacy "do nothing" ipv4 deployments forever. We 
also expect
those same deployments to invest significant effort, cost and risk to move off 
their
perfectly functioning network for no self-serving benefit.


No surprise that hasnt happened very quickly. You have that backwards. 
Legacy ipv4 do-nothing deployments have absolutely no need of support. 
IPv6 needs their support so that non-legacy deployments of IPv4 wont 
need continued support.




There be unicorns and denial of human nature.


Mark.




Human nature is that deployment of a technology when the larger benefit 
is unrealized in the short term by the party expected to expend the 
costs of the deployment is unlikely to have significant widespread 
initial momentum and is quite likely to have lingering inability to 
complete a global deployment.


As that is the case, efforts on both protocols are warranted.

Joe

Re: V6 still not supported

[Joe Maimon]

Owen DeLong wrote:


The goal of IPv6, IMHO, is to become the next lingua franca of the internet, 
eventually rendering IPv4 unnecessary except in small pockets of legacy support.

Hey Owen,

Indeed, having otherwise fallen short of the mark that is what remains.


I agree that has not yet been achieved.


Its  encouraging that progress and momentum continues, but there is no 
way to be 100% confident that IPv6 has unlimited time to obtain dominance.


It was an objective to try and reach that point prior to IPv4 address shortages 
caused real problems, but we pretty well missed that target when NAT started 
catching on.


There were still plenty of opportunities to save the day that IPv6 
global deployment missed.


I would not say that IPv6 has ben and continues to be a failure so much as IPv6 
has not yet achieved its goal. Yes, it failed the (optimistic) objective of 
achieving it’s goal prior to IPv4 shortages causing real problems, but that 
happened pretty quickly and pretty early in the lifespan of IPv6 thus far (I 
view the popularization of NAT as being the first marker of real problems in 
IPv4 due to address shortage).


There were more mile markers than NAT on the address shortage problem 
route and IPv6 failed most of those as well. Some of those happened 
early, some not so much and there are probably more to come.


While shortage might have been the main driver of development of NAT, 
provider independence and abstraction was the clear motivation for end 
users to adopt it.




  Getting IPv6 to near ubiquitous deployment in that short time would have been 
an impressive accomplishment if it had happened.

Owen


,

20 years ago it was not considered optimistic to expect that there would 
no longer be threads of this nature, it was essentially treated as 
heretical to imagine there might be. And there were concrete 
consequences to that mode of group think.


Even a naysayer as myself, back in 2004 really only expected another 
decade or so of transition to clear dominance.


I will note that a decade to make 240/4 usable was cited as a major 
opposition reason to it. And other ideas.


Joe

Re: V6 still not supported

[Joe Maimon]

John Curran wrote:
About two decades later, at the time of the IPv4 central free pool 
runout (Feb 2011), we had neither “clearly improved functionality” nor 
a straightforward transition plan for "transparent access between the 
IPv4 and IPng communities” – I do hope I was wrong about the outlook 
for IPng under such conditions, but we’ll need to wait for another few 
decades to know for sure one way or the other.


Best wishes,
/John



Well just because you were right then does not mean you cant be wrong 
now. Let us both hope so.


Best,

Joe

Re: V6 still not supported

[Joe Maimon]

james.cut...@consultant.com wrote:
On 23 Mar 2022, at 1:34 AM, Joe Maimon <mailto:jmai...@jmaimon.com>> wrote:

...
Since IPv6 was born of the effort to fix the upcoming address 
shortage visible at the time and to prevent and alleviate the 
resulting negative effects, the fact that it did not and that 
globally v4 address shortage is still a problem is a tally of 
multiple years of failure.


I noticed that no one on NANOG in the nineties predicted the 
foot-dragging and whining regarding transition from IPv4 toIPv6. 


You must not be looking hard enough. There have been many accounts of 
how Dual Stack as a transition was steamrollered on over naysayers 
objections and predictions.


My personal correspondence on NANOG doesnt date that far back but here 
are some of the earliest on-topic examples readily available.


https://archive.nanog.org/mailinglist/mailarchives/old_archive/2004-10/msg00298.html

https://archive.nanog.org/mailinglist/mailarchives/old_archive/2004-11/msg00112.html

https://archive.nanog.org/mailinglist/mailarchives/old_archive/2005-07/msg00023.html



We probably should have done so. I, for one, was busy trying to manage 
interconnects between divisions with their autonomous ref1918 worlds. 
I applauded the prospect of global unique addressing. So far the 
technical process has had rocky moments, but it ongoing failure has 
not happened.


Depends on the definition of the goal. And your definition appears to be 
some measure of forward momentum. Certainly plenty exists. And that is 
good news in and of itself. But the internet needed more and long ago 
already. And that is the bad news.




Any failure experienced is largely a failure of management/accounts to 
invest in the future for something that the media can not turn into 
sound bites and flashy images. This displays a clear lack of 
enlightened self interest.


When you build something and they dont come on schedule, you can blame 
them or you can consider what you could or should have done differently, 
especially as it may advise for the future. If you choose the former, 
there and then is the evidence of the type of thinking that tends to 
produce these outcomes.




Even in my home office, over the last nine years I have observed 
continually increasing IPv6 access for myself and my clients.  Comcast 
 has demonstrated that IPv6 has no deleterious effect on typical user 
experience. Apple and Microsoft have provided admirable support for 
IPv6 coexisting with IPv4 on end systems. I suggest that it may be 
more important to deploy solutions to BufferBloat, to the benefit of 
both IPv4 and IPv6 since it will improve the user experience, than to 
try to extend IPv4 lifetime, an effort with diminishing returns.



Yeah, I think blaming bufferbloat is another example of designers 
passing the buck and engaging. If the reality consists of large buffers, 
start engineering with them in mind.


Or better yet, fast large ram cheaply and widely available should be 
considered a welcome and valuable resource. Try to make proper use of it.


As for the rest, false dichotomy again. Do both. Or applaud both. Or 
support both. Or at least, dont oppose either.


Joe

Re: V6 still not supported

[Joe Maimon]

Michael Thomas wrote:


On 3/23/22 11:53 AM, Joe Maimon wrote:



Michael Thomas wrote:
IETF can't force people to adopt things, film at 11. They certainly 
can't control people's saltiness from something that happened 30 years 
ago. IPv6 is manifestly deployable for operators that want to. If 
others don't want to deploy it in the face of the predictable address 
crunch, that's on the operators and not anybody else. Vendors will 
build patches and hacks and other abominations if somebody is willing 
to pay for it. If you like CGN, by all means deploy it from a vendor 
standpoint. If you don't like CGN either then, well, you're sort of 
screwed. Going back and relitigating ipng is not ever going to happen.


Mike




Which is why the IETF should not engineer things under the assumption 
that they can.


Which is why the IETF should not be citing IPv6 as cause to deny efforts 
on IPv4.


Because as you say, at this point, even if you dont like CGN, the 
internet is sort of screwed.


And the reasons that IPv6 is not deployed everywhere it could or even 
should be are myriad. Perhaps unpredictable. That reasons would abound 
was predictable.


Network A deploying IPv6 does not do nearly as much to help A as it does 
when B-Z do, which is the core problem of IPv6 transition. You can 
understand then that even in the face of shortage IPv6 is only one of 
the options on the table at network A for short term alleviation. And 
usually not even the one with most bang per buck. Those who can choose 
D) all of the above, the rest prioritize based on resources and various 
locally defined assessments and analysis. Also unpredictable, but 
predictable that they would exist.


Bygones are bygones, but not if the behavior persists.

Yes, I understand referring to the IETF as an individual entity is 
grossly oversimplifying.


Joe

Re: V6 still not supported

[Joe Maimon]

John Curran wrote:


On 23 Mar 2022, at 1:34 AM, Joe Maimon <mailto:jmai...@jmaimon.com>> wrote:

...
Since IPv6 was born of the effort to fix the upcoming address 
shortage visible at the time and to prevent and alleviate the 
resulting negative effects, the fact that it did not and that 
globally v4 address shortage is still a problem is a tally of 
multiple years of failure.


Joe -

It all depends on your measure of success; i.e. the victory
conditions that one wishes to set.



Hi John,

That is the crux of my argument.


 If the victory conditions are “has displaced the previous IP4
protocol”, then we’re certainly not there (and may never achieve
at such an outcome for many decades to come…)

If the victory conditions are “provide an updated IP protocol that
the larger providers can use as an alternative for address their
continued growth requirements”, then it is indeed a success - as
proof one just has to look at major broadband and mobile network
deployments that use IPv6 to enable their continued growth…  (and
IPv4 on many of those networks is just network application shim to
a gateway service that’s present for obsolete software to use.)



I define the victory as avoiding the occurrence of the inevitable 
constraints that v4 shortage was going to have. I also include the 
negative effects and avoidable investment of time, effort and capex into 
CGN and the like in to what IPv6 was intended to avoid.


Perhaps a better statement of the failure is that the IPv6 deployment 
failed in its original objective to alleviate IPv4 address shortage 
before the effects became widespread and significant. I think that is a 
least common denominator we can mostly all agree on.



The fact that the majority of the network operators don’t use IPv6
is irrelevant under such victory conditions, so long as those who
needed to have it due to their growth requirements have had it as
a viable option.  Many of the largest networks out there (service
providers, cloud, social media) are running IPv6 as their primary
infrastructure because they prefer the long-term economics of that
architecture given their needs – so by that measure one can
consider definitely a success.



These are also the network operators who can use all the v4 not spent on 
infrastructure as well as the gobs of couch cushion v4 they have 
relative to their overall size to meet customer specific demand. So v6 
has mostly helped the large carriers, in increasing their internal 
supply of v4, in optimizing their use of CGN, in cohesive infrastructure 
addressing. Is that an overall internet success?


The end users and other network players not in similar circumstances 
have not benefited nearly as much. And they wont until IPv4 becomes 
optional. Now for many, Global IPv4 is indeed optional, we call them 
eyeballs and the loser here is the original concept of the end2end internet.




That doesn’t meant everyone has to run IPv6 – if your network
isn’t growing that much and you’ve got enough IPv4 addresses for
your needs then by all means continue to use just IPv4..



And then take the blame for why IPv6 deployment is not happening fast 
enough...



However, recognize that IPv6 deployment continues to grow, and
that means there could easily be a “tipping point” sometime in
your future – i.e. a point in time when your organization needs to
support IPv6 because of internal or external requirements  – and
it’s probably best for networking engineers to be up-to-speed &
comfortable with IPv6 by that point (or ready to do something else
for a living)

Thanks!
/John


Agreed and as you have pointed out, this is our continued hope. That 
doesnt mean victory is assured and inevitable, the longer this drags out.


Always a pleasure,

Joe

Re: V6 still not supported

[Joe Maimon]

Michael Thomas wrote:




SIP won't displace all legacy PSTN any time soon. So it's a failure by 
your definition. And by your definition IPv6 was a failure before it 
was even born because the internet became popular -- something I'll 
add that nobody knew for certain when it was being designed. There's a 
lot of sour grapes about stuff that happened 30 years ago.


Mike


The definition of failure flows from the definition of the objective, 
the goal, the desired outcome.


What is your understanding of those for IPv6?

My understanding of the goal of IPv6 was to replace IPv4 globally before 
address shortage caused real problems. If we agree on that, we must also 
agree that it has failed to do so, ergo, IPv6 as a global solution to 
IPv4 address shortage has been and thus far continues to be a failure. 
Now it will almost certainly eventually succeed, but that doesnt change 
that for all this time, it failed and there were real consequences that 
or may not carry on with us all for quite some time, and that there were 
real costs involved to real people.


Joe

Re: V6 still not supported

[Joe Maimon]

Michael Thomas wrote:


On 3/22/22 10:34 PM, Joe Maimon wrote:




There is this other side: I'm dualstack, and I simply dont notice.


Being in transition state indefinitely is not success.

The other side is when you are v6 only and you dont notice. We arent 
there yet. Thats the failure.


This is a terrible way to look at things. SIP has been gradually been 
taking over the PSTN signaling for 20 years. It has not rooted out 
every SS7 installation on the planet and probably won't until I'm long 
dead. Is that a failure? It's certainly a "transition state". After 
not paying attention for probably a decade and seeing how much it's 
penetrated I'd call that a resounding success. The same is true of 
IPv6 with all of the mobile uptake. Legacy is hard. It always has been 
hard. Calling something a failure because it doesn't instantly defeat 
legacy a terrible take. It was always going to be difficult to add 
address space to IP regardless of how it was done. All of the bagging 
on IPv6 and imagining a better ipng ignores that basic fact.


Mike


SIP wasnt formulated to save telephony. In fact sip has nearly 100% 
adoption for ip based telephony. It did displace legacy and proprietary 
protocols.


There is no comparison. IPv6 transition was intended to complete before 
run out using Dual Stack. Fail.



Joe

Re: V6 still not supported

[Joe Maimon]

George Michaelson wrote:

Thats partly why I
find a huge personal disconnect with "failure" -It hasn't failed the
way DECnet failed. Far from it.


Since IPv6 was born of the effort to fix the upcoming address shortage 
visible at the time and to prevent and alleviate the resulting negative 
effects, the fact that it did not and that globally v4 address shortage 
is still a problem is a tally of multiple years of failure.


I will give you that address shortage and resulting constraints is 
actually a spectrum, one we have not finished traveling on. I suppose we 
can date it from the time a class-c stopped being included as part of 
your leased line all the way to the hasnt happened yet point where you 
cant get v4 for any affordable amount. So yes, IPv6 will probably save 
the internet at some point before the end of that spectrum is reached, 
but the damage has already been done, and lots of it.


Now if the goal was to produce a protocol that would work eventually as 
good as IPv4 and would theoretically fix the address shortage, but only 
if the non-practical mass conversion occurred immediately, well than its 
a success and has been for some time. However, successes like that are 
not what made the internet.




There is this other side: I'm dualstack, and I simply dont notice.


Being in transition state indefinitely is not success.

The other side is when you are v6 only and you dont notice. We arent 
there yet. Thats the failure.


  
Here's my final (serious) suggestion. We aren't going to be able to

reverse course out of the current situation. Maybe the best thing, is
to engineer it, not complain about it. Engineering won't end either
right now. Betting on 4 continuance is betting on markets over
planning. Maybe thats what some people want? What I want doesn't
matter that much btw.

-G


Hope for the best and prepare for the worst. That means improving v6 and 
making it more adoptable and appealing to more diverse user populations.


It also means taking measures to prolong v4.

That means give them DHCP the way they want it, give them NAT the way 
they want it. Give them whatever you can whatever they want in v6 the 
way they want it, whether you like it or not. Just get it out there more 
and more faster and faster.  Ideological concerns had their day and its 
over. We are past deadline. Just get it done. Or get out of the way of 
those who want to. Yes, RiR's, IPv6 costing anyone any more money was a 
false start penalty.


It also means taking a real look at proposal like 240/4 and whatever 
else can be scrounged up, extended, worked around, whatever you have, 
because if the worst happens and we are still having these threads in a 
decade, we are going to need it. bad. And if the best happens, who cares 
about v4 and what was done to it anyways?


Now you can say nah, I am betting on things working out just the way 
they are now, but lets be clear about that.


Joe

Re: V6 still not supported

[Joe Maimon]

b...@theworld.com wrote:

We know we need to get rid of fossil fuel vehicles but electric cars,
at least at this point, leave quite a bit to be desired like battery
technology (materials needed, disposal, cost, electricity generation,
etc.)



Suppose syngas becomes economical.

Who said we have to get rid of ICE vehicles?

The essential problem is portable convertible efficient economical 
stable high density energy.


Joe

Re: V6 still not supported

[Joe Maimon]

Pascal Thubert (pthubert) via NANOG wrote:

Hi:

IPv4 is 40 years  old. IPv6 is 25 years old. In Internet time, both are old 
timers.


25 years to not achieve global domination opens the door to become 
obsoleted before it does. Pretty sure that would be more bad than good.



The rest of the world will follow the evolution because there's not enough IPv4 
for Africa or Asia anyway. I see the analogy with the industrial revolution, 
England stuck to coal and steam when the world that had nothing moved on.


Some weight to lend to your theory would be if Africa and Asia IPv6 
numbers are outpacing everywhere else. Google numbers suggest that is 
not at all the case, with the notable exception of Saudia Arabia and 
India and even Gabon.


Perhaps you have better or different numbers. We could use some good news.



Which side are you on?

Pascal


The "side" thing is the problem here. The objective is a stable and 
maximally usable internet, both now and in the future.


Joe

Re: Making Use of 240/4 NetBlock Re: 202203151549.AYC

[Joe Maimon]

John Levine wrote:

It appears that Abraham Y. Chen  said:

 C.Recently, we were made aware of the Int-Area activities.
Attempts to reach the Group Chairs have not received any responses.

 D.I just received an Int-Area Digest Vol 199, Issue 14
requesting IETF to reactivate the IPv4 support.

For people who don't follow the IETF lists, here's a summary of
the responses.  Mr. Chen thought it was a good idea, everyone
else, and I mean everyone, said it's a foolish idea and not
worth pursuing.

R's,
John


*ahem*
Is this is how the IETF ivory tower residents likes to try and suppress 
debate, by relegating all group think dissenters as white noise 
nobodies? And if they have succeeded in doing such on their own forums, 
its more telling about their own process problems than anything else.


I sincerely hope I am mistaken in your characterization of the many fine 
individuals who have repeatedly gone on record in support of maintaining 
IPv4 responsibly until such time as it is properly obsoleted.


While I can understand being considered a nobody, other more notable 
definitely not nobodies have even on this tired topics' nth thread made 
themselves heard and some fairly clearly.


History will continue to show that the IETF pursued the path of pain for 
the internet.


Joe

Re: "Permanent" DST

[Joe Loiacono]

Indeed. I was quite surprised to learn that an issue we were dealing 
with was a result of not having have the latest TZ file installed.


On 3/16/2022 4:47 PM, Ask Bjørn Hansen wrote:

This is a weirdly long thread, mostly unrelated to NANOG, it seems.

The work for how this will be implemented in most of our computers happens on 
the TZ list by thoughtful people with lots and lots of experience on the 
subject: https://mm.icann.org/pipermail/tz/

I believe the last change in the US was more than a decade ago, but time zone 
data changes somewhere in the world on a very very regular basis.


Ask

Re: "Permanent" DST

[Joe Greco]

On Tue, Mar 15, 2022 at 02:06:50PM -0700, Brandon Svec via NANOG wrote:
> "..rational time worldwide"?  Like all of China in one timezone and Mumbai
> :30 off center? and Arizona?  and that one county in Idaho?


The word "rational" does not belong in a sentence discussing timezones or
even general time issues.

We're taught from a young age that you wake up at, well for the sake of
argument, let's agree on 7AM.  You learn that businesses are "9AM to 5PM",
etc.  These are basically all arbitrary choices, based off hysterical
raisins that have to do with the position of the sun at noon, in an era
where there weren't better ways to synchronize clocks.

We COULD all work in UTC and un-learn the weird system of hour offsets
and timezones.  This would be convenient for people at a distance, since
it would be simply a matter of stating availability hours, rather than
giving someone hours AND a timezone and making them do the math.  If I
say that I'm available for an hour at 22:00 UTC, that works out anywhere
on the globe.  But do you know what timezone "CDT" is?  When's "17:00 CDT"?

... JG
-- 
Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net
"The strain of anti-intellectualism has been a constant thread winding its way
through our political and cultural life, nurtured by the false notion that
democracy means that 'my ignorance is just as good as your knowledge.'"-Asimov

Re: Making Use of 240/4 NetBlock

[Joe Maimon]

Christopher Morrow wrote:



On Sun, Mar 13, 2022 at 10:39 AM William Herrin <mailto:b...@herrin.us>> wrote:


On Sun, Mar 13, 2022 at 1:22 AM Joe Maimon mailto:jmai...@jmaimon.com>> wrote:
> The true dilemma is that any amelioration of IPv4 scarcity may
indeed
> contribute to further delaying mass global IPv6 adoption,
regardless of
> whose effort and time is involved.


What's the actual proposal for 240/4?
Is it: "Make this usable by me on my /intranet/?"
Is it: "Make this usable across the internet between bespoke endpoints?"
Is it: "Make this usable for any services/users on the wider internet, 
treat it like any other unicast ipv4 address?"

Is it: "Something entirely different"

The first 2 probably already work today, if you take the time to 
control the horizontal and vertical of your networking space.
The last is probably workable, given enough time to flush out all of 
the endpoints which (today) probably treat 240/4 as 'special'.


240/4 has a special problem. The problem is that the smallest bit of 
cooperation from the broader community, other than those expending 
effort on 240/4 directly is required.


Mostly so that any potential use of 240/4 continues to be standardized. 
Which in theory, is in all parties best interest.


I think the current draft pretty much wanted a word or two changed.



So.. to move forward with 240/4 on the wider internet you'd need a 
bunch of software / hardware updates, and time for those to rollout.

Then you'd need sacrificial lambs in the user and service endpoints.


Nobody is asking for any assistance with that. It will happen or not 
based upon those who wish to expend effort on it. Apparently, most if it 
has already happened.




All of this to regain ~16 /8's worth of space (presuming you could use 
255/8?).


Really, so that anything standardized can be done with it, rather than 
nothing.


This is about extending some utilization capability of IPv4, but it is 
also about preserving standard driven behavior.


I think a /8 is 'free' on the internet for about a month, so 1.5 yrs 
of new address allocations, terrific?


That was the old paradigm, in the old days. Currently a /8 goes pretty 
far and its likely to only get further.




At the end of the day, again, almost all proposals to 'add more ipv4 
space' come down to 1 month per /8.

I think part of Jordi's point is:
  "Is that 1 month really worth the effort?


All the effort requested is for all those who think its wall head 
banging to say knock yourself out, we are unopposed to changing how IPv4 
obsolete addresses are managed because we have already bet on IPv6. Take 
whatever you want. Change whatever you want. We dont care.


Thats not a whole lot of effort being requested of the unwilling in 
exchange for their continued relevance. All the rest of the efforts are 
expected to come from the willing, able and ready. Not your concern.


But perhaps you do care. Why?

  is there a reason that all of the softare/hardware uplift and time 
to deploy is not being spent on v6?"


Perhaps you think that stymieing any effort on IPv4 is important to 
marshall the worlds attention to IPv6. Which if the shoe were on the 
other foot you would find galling and obnoxious.


There are many reasons why IPv6 hasnt done that all on its own and 
pretty much most if not all of them have nothing to do with 240/4


They have to do with IPv6. And we have heard them over and over again. 
Look inwards.


In short, IPv6 apparently keep losing to the cost vs. benefits analysis 
being performed by countless people in countless situations. You can 
claim that it should not, but that is not what is happening.


You cant make IPv4 more expensive than it already is doing all by 
itself. It is wrong to try. And apparently, its not expensive enough to 
drive mass adoption of v6, with any degree of alacrity.


v6 must have costs in contexts that have been under-addressed. Its time 
to knowledge them and perhaps work to address them.




At this point in our matrix timeline it seems to me that:
  "If you were going to deploy v6, you did... if you didn't oh, well.. 
eventually you will?"


Much like Itanium vs. amd64, there are other ways this can turn out, the 
longer it drags out. I think those ways are potentially more undesirable 
than extending IPv4 use in a standardized fashion now.




I'd prefer to not have to deploy  in a rush or on timelines I can't 
cointrol if I hadn't deployed already.
Will that timeline be 'soon' anytime soon? I don't know :( I think 
Grant's "not until i'm long retired" guess

is as good as any though :(

-chris


I for one would like to say I did all the tiny amount I conceivably 
could to leave the internet a better place than I found it.


And I think that means giving IPv4 all the runway it needs to properly 
decelerate to the fullest extent possible or at least not obstr

Re: Making Use of 240/4 NetBlock

[Joe Maimon]

JORDI PALET MARTINEZ via NANOG wrote:

Because it is a single Internet, and what we do in some parts of Internet will 
affect others?

Because, at least in my case, I'm investing my efforts in what it seems to be 
the best in the long-term for the global community, not my personal preferences?


Improving IPv6? Keep up the good work and thank you.

Protesting IPv4 efforts? Not very altruistic, more like you are 
motivated by various deep-seated emotional responses to the continuation 
of the IPv4 internet.


  


El 12/3/22 9:10, "William Herrin"  escribió:


 Why are so many otherwise smart engineers so vulnerable to false
 dilemma style fallacies? There's no "either/or" here. It's not a zero
 sum game. If you don't see value in doing more with IPv4 then why
 don't you get out of the way of folks who do?

 Regards,
 Bill Herrin




The true dilemma is that any amelioration of IPv4 scarcity may indeed 
contribute to further delaying mass global IPv6 adoption, regardless of 
whose effort and time is involved.


And I find advocating for that to be wrong and perhaps to some extent, 
immoral. Unlikely to be productive. And potentially counter-productive.


Joe

Re: 202203071610.AYC Re: Making Use of 240/4 NetBlock

[Joe Maimon]

Saku Ytti wrote:
What if many/most large CDN, cloud, tier1 would commonly announce a 
plan to drop all IPv4 at their edge 20 years from now? How would that 
change our work? What would we stop doing and what would we start doing? 


I cant see how it would change or do anything IPv6-related for myself 
for at least 19 years. And I suspect most others would fall somewhere 
between that and never.


However, such an announcement would actually signal that we should do 
all those things now to IPv4 that will take 10 years to be useful, 
because then they will be useful for at least another 10 years.


Seriously, we have already had this sort of experiment play out numerous 
times, both with a governing body and without. We already know how it goes.


With a governing body: lack of progress right up until the deadline, 
gnashing of teeth ensues until deadline is extended, more often than not 
comprehensive conversion finally completes, later than scheduled.


Without: lack of progress right up to deadline, teeth gnashing, deadline 
is arbitrarily extended, nothing much changes and deadline is forgotten.


When IPv4 is properly obsoleted, we will see many of those announcements 
and some will matter and most wont. As it should be. However 
proclamations are not going to obsolete IPv4. As we have already seen.


I dont think advocating for large players to band together to form their 
own internet-ops standard body is going to save IPv6 and the internet. 
More likely it will doom both as we know it.


Here is an equally unlikely thought experiment.

What if many/most large CDN, cloud, tier1 would commonly announce a plan 
to compatibly extend IPv4, citing a lack of progress in IPv6 deployment 
and resulting IPv4 elimination as well as a stagnant stalemate on any 
such efforts within the would-be-relevant standard bodies?


Joe

Re: V6 still not supported (was Re: CC: s to Non List Members, (was Re: 202203080924.AYC Re: 202203071610.AYC Re: Making Use of 240/4, NetBlock))

[Joe Maimon]

Grant Taylor via NANOG wrote:



I believe that talking about removing IPv4 in any capacity /now/ is a 
disservice to the larger conversation.


We mostly agree. Except that there is a significant vocal portion of the 
IPv6 spectrum that would like to start obsoleting IPv4 now.


I have my doubts about getting back to a single protocol Internet 
(IPv6) in my lifetime, much less my career.


I both doubt and very much hope that it will not be quite that long, but 
even so, the fact that it can even be considered a possibility should be 
a significant wake up call.


In any event, all this underscores the reality that IPv4 requires more 
investment to carry along until that point.



And until that point, IPv6 is an optimization, not a requirement.


How long do you wait during the "optimization" window before actually 
deploying IPv6?  The 11th hour?  Why not start deploying IPv6 with new 
green field deployments at the 2nd hour?



Until you have the itch to do so, until you have a business case to do 
so, until you no longer have any excuse not to do so. The opt in 
optimization is optional.


Joe

Re: V6 still not supported (was Re: CC: s to Non List Members, (was Re: 202203080924.AYC Re: 202203071610.AYC Re: Making Use of 240/4, NetBlock))

[Joe Maimon]

Ca By wrote:




Google’s number represents how many users reach it over ipv6. Given 
Google’s ubiquity in the usa, it is a fair barometer for the usa at 
large.


Given google's popularity on handheld platforms, the users of which tend 
to be much less sensitive to IPv4 translation mechanisms and have a much 
higher penetration of native v6, I would restate that a bit more 
conservatively as


Google's statistics are likely a fair barometer for USA usage in the 
large content provider arena which have a strong mobile representation.






Reading anecdotal Nanog mails from a handful of folks concluding ipv6 
has failed will not leave the passive impartial observer with an 
accurate view.


Its incontrovertible that IPv6 has racked up a long list of failures in 
its original objectives, expectations, predictions and timelines, even 
up to this point.


I am not really convinced that IPv4 can be 
ignored/marginalized/obsoleted without penetration reaching over 90%, 
globally. And until that point, IPv6 is an optimization, not a requirement.


Perhaps it will accelerate at some percentage point. But if it drags out 
for another decade or two, all bets are off.



Joe

Re: V6 still not supported

[Joe Maimon]

b...@theworld.com wrote:

I could offer a more philosophical assessment of IPv6 deployment.

Perhaps we're there, we're doing fine. This is how it is going to go.

It's out there, it works (glitches aside), those who want it use it
tho they can't force others to use it so still need to maintain a
dual-stack if that's of importance to them. Perhaps that's a
reasonable complaint, the cost and effort of accommodating those who
haven't deployed IPv6.


If this rather healthy viewpoint was more generally pervasive IPv4 
efforts would not be met with such hysteria.



Maybe it will take 50 years (we're easily half-way there.)

Put another way, by what objective measure is IPv6 deployment seen as
failing? Other than individuals' impatience. Was there a generally
agreed upon timeline which wasn't lived up to, for example?
As a protocol and product, IPv6 is a success. It works, its deployed, 
its utilized.


As the cure and solution to address scarcity experienced by network 
users and operators, it has already failed in that goal, repetitively 
and continually.


It was supposed to do that using the additional time CIDR bequeathed to 
IPv4. Fail.


It was supposed to do that upon IANA exhaustion. Fail.

It was supposed to do that upon RiR exhaustion. Annual Fail.

It was supposed to do that prior to commercialization and 
commoditization of IPv4. Fail.


It was supposed to do that before E2E on the internet became a quaint 
historical footnote. Fail.


IPv6 has failed the Internet.

Maybe, hopefully, this is the year or decade it finally stops being the 
perennial failure, but the history of fail induced net-negatives does 
not get erased by eventual success, and worse, the future will likely 
continue to contain artifacts of those failures.


Its not impossible to envision that IPv4 does not ever go away but 
actually gets extended in such a way that it obsoletes IPv6. The longer 
this drags out the less implausible it seems.


Joe

Re: CC: s to Non List Members (was Re: 202203080924.AYC Re: 202203071610.AYC Re: Making Use of 240/4 NetBlock)

[Joe Maimon]

Tom Beecher wrote:


The only way IPv6 will ever be ubiquitous is if there comes a time 
where there is some forcing event that requires it to be.


Unless that occurs, people will continue to spend time and energy 
coming up with ways to squeeze the blood out of v4 that could have 
been used to get v6 going instead. I don't foresee anything changing 
for most of the rest of our careers, and possibly the next generation 
behind us.


I dont think it is as bad as that, but what you are implicitly saying is 
that even multi-decades efforts to prolong IPv4 have clear justification 
to begin now, if not sooner.


As for the rest of this popular meme, instead of aspirations to force a 
chosen technology down the throats of many clearly unwilling and/or 
uninterested parties whom make up a still significant percentage of the 
internet, perhaps more effort should be expended on


A) making the chosen technology more attractive, more useful, more 
deployable, more compatible, etc. Because clearly its not enough of 
those things for many, regardless of whatever personal experience or 
theories you may have on the matter.


B) Keeping the rest of the internet as functional as possible, with 
whatever tradeoffs make send, for the actual potential duration of A 
instead of pie-in-the-sky estimates. Which have a 100% track record of 
being wrong.


Persuasion, not coercion. Which even if it were possible, is wrong and 
immoral.


The internet is supposed to be about mutually beneficial cooperation, 
not hierarchical coercion.


Joe

Re: CC: s to Non List Members (was Re: 202203080924.AYC Re: 202203071610.AYC Re: Making Use of 240/4 NetBlock)

[Joe Maimon]

Owen DeLong via NANOG wrote:

One thing is for certain… If folks had put 0.10 as much effort into deploying 
IPv6 as has been put into arguing about whether or not ~17 /8s worth of IPv4 
makes a meaningful difference to the internet as a whole, IPv4 would long since 
have become irrelevant as it must eventually be.

Owen


You might have had a decent point there instead of a soundbite, except 
that you are conflating different people together, as if the ones 
arguing to extend IPv4 are conveniently the same ones whom if they 
redirected their efforts would have IPv6 deployed in a few jiffies.


Reality is quite a bit different.

Joe

Re: V6 still not supported (was Re: CC: s to Non List Members (was Re: 202203080924.AYC Re: 202203071610.AYC Re: Making Use of 240/4 NetBlock))

[Joe Greco]

On Thu, Mar 10, 2022 at 09:55:42AM +0200, Saku Ytti wrote:
> On Wed, 9 Mar 2022 at 21:00, Joe Greco  wrote:
> > I really never thought it'd be 2022 and my networks would be still
> > heavily v4.  Mind boggling.
> 
> Same. And if we don't voluntarily agree to do something to it, it'll
> be the same in 2042, we fucked up and those who come after us pay the
> price of the insane amount of work and cost dual stack causes.
> 
> It is solvable, easily and cheaply, like most problems (energy,
> climate), but not when so many poor leaders participate in decision
> making.

I am reading your response as to imply that this is somehow my fault
(for my networks) and that I am a poor leader for not having embraced
v6.  If that's not what you meant, great, because I feel like there's
been systemic issues.

There are several ASN's I run infrastructure for, on an (as you
put it) "voluntary" basis, for organizations that run critical bits
of Internet infrastructure but which aren't funded like they are
critical bits.

The problem is that I really don't have the ability to donate more
of my time, since I am already 150% booked, and I'm not willing to
hire someone just to donate their time.

I have no idea what it is I can agree to do to make something happen
here that is accomplished "easily and cheaply".  From my perspective,
IPv4+6 is many times the effort to deploy as just IPv4, somewhere
between 5x-10x as much work depending on the specifics.  I love many
of the ideas behind v6, but adoption seems tepid.  I had to fight
years ago to get IPv6 via broadband, and most common end-user gear
still does not seem to support it, or enable it by default.

Looking at the results, I think we've screwed this up.  Just like the
e-mail ecosystem was screwed up by poor design and then stupid bolt-on
fixes, so we've finally arrived at a point where people just don't 
even want to deal with the problem.  At least with e-mail, you can
plausibly outsource it if you're not masochistic.  I feel like IPv6 is
that same sort of problem, except you can't outsource it.  You can
avoid it by throwing some more IPv4 NAT and proxies into the mix
though.  And tragically, that seems to be what's happened.

... JG
-- 
Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net
"The strain of anti-intellectualism has been a constant thread winding its way
through our political and cultural life, nurtured by the false notion that
democracy means that 'my ignorance is just as good as your knowledge.'"-Asimov

Re: V6 still not supported (was Re: CC: s to Non List Members (was Re: 202203080924.AYC Re: 202203071610.AYC Re: Making Use of 240/4 NetBlock))

[Joe Greco]

On Wed, Mar 09, 2022 at 09:46:41AM -0800, David Conrad wrote:
> Tim,
> 
> On Mar 9, 2022, at 9:09 AM, Tim Howe  wrote:
> > Some of our biggest vendors who have supposedly supported
> > v6 for over a decade have rudimentary, show-stopping bugs.
> 
> Not disagreeing (and not picking on you), but despite hearing 
> this with some frequency, I haven???t seen much data to corroborate 
> these sorts of statements.

Fine.  We could start at the top, with protocols that are defective
by design, such as OSPFv3, which lack built-in authentication and 
rely on IPsec.  That's great if you have a system where this is all
tightly and neatly integrated, but smaller scale networks may be
built on Linux or BSD platforms, and this can quickly turn into a
trainwreck of loosely cooperating but separate subsystems, maintaining
IPsec with one set of tools and the routing with another.

Or ... FreeBSD's firewall has a DEFAULT_TO_DENY option for IPv4 but
not for IPv6.  Perhaps not a show-stopping bug, granted.  But, wait,
if you really want end-to-end IPv6 (without something like NAT in
between doing its "faux-firewalling") endpoints, wouldn't you really
want a firewall that defaults to deny, just in case something went
awry?  If I've got a gateway host that normally does stateful
firewalling but it fails to load due to a typo, I'd really like
it to die horribly not packet forwarding anything, because someone
will then notice that.  But if it fails open, that's pretty awful
because it may not be noticed for months or years.  So that's a
show-stopper.

As exciting as it would be to go all-in on v6, it's already quite a
bit of a challenge to build everything dual-stack and get to feature
parity.  The gratuitous differences feel like arrogant protocol
developers who know what's best for you and are going to make you 
comply with their idea of how the world should work, complexity be
damned.

I really never thought it'd be 2022 and my networks would be still
heavily v4.  Mind boggling.

... JG
-- 
Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net
"The strain of anti-intellectualism has been a constant thread winding its way
through our political and cultural life, nurtured by the false notion that
democracy means that 'my ignorance is just as good as your knowledge.'"-Asimov

Re: Is soliciting money/rewards for 'responsible' security disclosures when none is stated a thing now?

[Joe Greco]

On Fri, Mar 04, 2022 at 11:33:47PM +0200, Denys Fedoryshchenko wrote:
> This is typical "Beg bounty".
> https://www.troyhunt.com/beg-bounties/

This probably isn't even that.  I've seen a bunch of similar spam to
various role accounts, some at domains that don't even have a website,
in the last month or so.

Several contained "real names" of alleged security researchers that
did not seem to exist in the real world.

It is worth remembering that bad guys may be interested in collecting 
the e-mail addresses of people who are responsible for security within
your organization.  These could be used to target those people with
malware, or to forge legitimate-looking e-mails "from" your security
department to your other employees.

It is likely that no good can come of engaging with these.

... JG
-- 
Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net
"The strain of anti-intellectualism has been a constant thread winding its way
through our political and cultural life, nurtured by the false notion that
democracy means that 'my ignorance is just as good as your knowledge.'"-Asimov

Re: Russian aligned ASNs?

[Joe via NANOG]

Obligatory xkcd - https://xkcd.com/705/


On 2/25/2022 at 3:26 PM, "Dave Taht"  wrote:
>
>I have always viewed our job has always been to keep the network
>running, no matter what.