Re: Can an IXP sell IP transit?

[Tom Beecher]

>
> Over the coming years, I expect exchange points to do some strangely
> interesting things, as the towel of revenue continues to get tighter and
> tighter to squeeze.
>
> Especially so if a few of the large content providers continue to pull
> back from route servers and such.


Content providers aren't leaving IXP's completely. They're still there,
still paying monthly for ports and XCs. Still doing bilateral peering over
the IX. There's no revenue hit to an IXP for a CDN to de-peer off the route
servers.


On Mon, Nov 4, 2024 at 10:20 PM Mark Tinka  wrote:

>
>
>
> On 11/5/24 02:56, William Herrin wrote:
>
> Of course they can sell transit. The reason they don't is that it has
> the potential to create a conflict of interest. When your customer is
> also a competitor and your customer suffers an outage that's your
> fault... Well, you see where this is going.
>
>
> Over the coming years, I expect exchange points to do some strangely
> interesting things, as the towel of revenue continues to get tighter and
> tighter to squeeze.
>
> Especially so if a few of the large content providers continue to pull
> back from route servers and such.
>
> Mark.
>

Re: IEEE MACsec

[Tom Beecher]

>
> Regarding speed, the first few pages I hit made a comment that it was
> slower because of packet overhead. I'm reading more and that is less of
> a concern.
>

There's certainly a penalty paid for the extra time encrypting and
decrypting , which of course can aggregate over a large number of protected
links.

But unless you're trying to manage latency budgets in the microseconds
range it's not likely to be an issue.

On Mon, Oct 21, 2024 at 3:01 PM John Schiel  wrote:

>
> Thanks.
>
> I threw this out there not knowing how fast someone would respond.
>
> I only heard about this recently and am surprised it as as old as it is.
>
> Regarding speed, the first few pages I hit made a comment that it was
> slower because of packet overhead. I'm reading more and that is less of
> a concern.
>
> --jas
>
> On 10/21/24 12:28 PM, Saku Ytti wrote:
> > On Mon, 21 Oct 2024 at 20:34, John Schiel  wrote:
> >
> >>   1) May not work over wireless LAN devices?
> > I guess it depends on wireless technology, but 802.11xyzzy comes with
> > an encryption solution already so isn't really a target of interest.
> >
> >>   2) Needs a centralized key server.
> > Not really, implementation detail.
> >
> >>   3) May not be supportable on all devices?
> > Definitely not supported on all devices, you tend to pay extra, but
> > getting an increasingly small premium to pay. May become essentially
> > free, depending on demand.
> >
> >> Purported to be faster on the LAN than IPsec because MACsec is on layer
> 2.
> > Speed doesn't have anything to do with layer2 or layer3, you may be
> > assuming that ipsec is software and macsec is hardware which may be
> > true, but is implementation detail. For example Juniper Trio can do
> > some forms of IPSEC on the same hardware as MACSEC at the same
> > performance profile.
> >
> >
> > It is not exactly new technology, these devices have existed for +decade
> now?
> >
>
>

Re: Frustration with increasing information demands from Network Vendors

[Tom Beecher]

Sample here of a publicly accessible support contract :
https://support.juniper.net/support/pdf/guidelines/juniper-care-service-description-document.pdf

Section 3.2 is the relevant portion. In part :

During the term of the Juniper Networks Service Contract, Juniper Networks
> shall make available the Supported Updates (as defined below) to End User
> solely for support of the End User’s Supported Juniper Product, subject to
> the terms and conditions set forth below:
>


What is the applicable part in the contract that you commonly
> need to remind Juniper about and helps you in procuring software
> updates?
>

I disagree with the premise here. I never said I 'commonly need to remind
Juniper' about anything in relation to software updates. I was
simply stating to the OP that if he had a support contract, and he's
getting the runaround on access, reminding them of their contractual
requirements may help move things along.



On Sat, Oct 12, 2024 at 1:55 AM Saku Ytti  wrote:

> On Fri, 11 Oct 2024 at 23:02, Tom Beecher  wrote:
>
> > Just standard contract law is all I was referring too.
>
> More specifically, were you referring to the support contract Juniper
> wrote? What is the applicable part in the contract that you commonly
> need to remind Juniper about and helps you in procuring software
> updates?
>
> >> On Fri, 11 Oct 2024 at 16:36, Tom Beecher  wrote:
> >> > If you purchased a support contract with the switch, they are legally
> required to provide you access to software updates. You may wish to remind
> them of that fact.
>
>
>
>
> --
>   ++ytti
>

Re: Frustration with increasing information demands from Network Vendors

[Tom Beecher]

>
> Not disputing, just curious. I assume you are talking about federal
> law in the US, can you be specific about what the law says?
>

Just standard contract law is all I was referring too.

On Fri, Oct 11, 2024 at 9:55 AM Saku Ytti  wrote:

> On Fri, 11 Oct 2024 at 16:36, Tom Beecher  wrote:
>
> > If you purchased a support contract with the switch, they are legally
> required to provide you access to software updates. You may wish to remind
> them of that fact.
>
> Not disputing, just curious. I assume you are talking about federal
> law in the US, can you be specific about what the law says?
>
> --
>   ++ytti
>

Re: Frustration with increasing information demands from Network Vendors

[Tom Beecher]

>
> I really really really find it disgusting that companies have no problem
> asking for this kind of information!! Its not only Juniper but also other
> major brands.
>

Pretty standard capitalism feature. Everyone wants to know what else they
might be able to sell you.

I just bought a single switch and I can't update it without sharing all
> this information.
>

If you purchased a support contract with the switch, they are legally
required to provide you access to software updates. You may wish to remind
them of that fact.

If you didn't , you're technically not entitled to software updates
anyways. But just make something up for those fields, or create a new
account from scratch.


On Fri, Oct 11, 2024 at 5:28 AM chiel via NANOG  wrote:

> Hi,
>
> I have an handful of Juniper devices (mx204 / QFX5100). I recently bought
> a new QFX5110 switch I want to update to a newer software release.
>
> My account on the Juniper website seems to be disabled and therefor I send
> an email to customer care. They replied with a form that I have to fill in.
> A couple of of the questions are "*$ Revenue Range*", "*# of Sales Reps*",
> "*# of Office Locations*". "*Details of potential opportunities in
> progress (also Provide)*".
>
> I only filled in the form with my own details (name, email address, etc..)
> and said I refused to give information about the other questions. Juniper
> (customer care) replied with "*Please note we need these details to
> reinstate the account. We can not proceed if the form is incomplete*. "
>
> I really really really find it disgusting that companies have no problem
> asking for this kind of information!! Its not only Juniper but also other
> major brands.
>
> I just bought a single switch and I can't update it without sharing all
> this information.
>
> I'm I do only one that feels this strongly about this?
>

Re: Third Party VoIP Over Xfinity

[Tom Beecher]

>
> How can such a large company have something so simple as SIP
> registration mangled up?
>

Very little incentive to fix it. The number of customers that are able to
switch providers when something like this doesn't work is a fractional
percentage of overall customer churn.

The MBAs say it's cheaper to ignore it, so that's how it goes.

On Wed, Sep 11, 2024 at 10:38 AM Matt Hoppes <
mattli...@rivervalleyinternet.net> wrote:

> How can such a large company have something so simple as SIP
> registration mangled up?
>
> On 9/10/24 5:22 PM, Mike Hammett wrote:
> > We've just moved to tunneling anything VoIP if on Comcast's network.
> >
> >
> >
> > -
> > Mike Hammett
> > Intelligent Computing Solutions 
> > <
> https://plus.google.com/+IntelligentComputingSolutionsDeKalb><
> https://www.linkedin.com/company/intelligent-computing-solutions><
> https://twitter.com/ICSIL>
> > Midwest Internet Exchange 
> > <
> https://www.linkedin.com/company/midwest-internet-exchange><
> https://twitter.com/mdwestix>
> > The Brothers WISP 
> > <
> https://www.youtube.com/channel/UCXSdfxQv7SpoRQYNyLwntZg>
> > 
> > *From: *"Matt Hoppes" 
> > *To: *nanog@nanog.org
> > *Sent: *Tuesday, September 10, 2024 2:17:37 PM
> > *Subject: *Third Party VoIP Over Xfinity
> >
> > I have an employee who has recently switched to Xfinity cable service.
> > Ever since they switched their internet service their work phones will
> > not stay registered for more than about 3 minutes.
> >
> > These same phones have been used on many ISPs without issues.  The same
> > config has been used behind multiple levels of NAT without issues.
> >
> > She was fine, until she switched to XFinity.
> >
> > Of course, XFinity support is absolutely worthless.
> >
> > Anyone from XFinity Tier 3 or such that might be able to offer
> assistance?
> >
> > I suspect it's something stupid with either NAT overload in the modem or
> > the modem not keeping the SIP channels open.
> >
> > I've tried playing around with registration times without any success.
> > And again, we've never had issues with these phones or this setup with
> > any other ISP.
> >
> >
> >
>

Re: Seeking IANA ccTLD contact

[Tom Beecher]

Not really an escalation point above the registrar level.

https://www.icann.org/resources/pages/about-icann-faqs-2019-02-25-en

Q: Does ICANN help with domain ownership or registration disputes?
>
> A: *No*, ICANN does not get involved in disputes regarding domain
> ownership or registration. ICANN's role is at the policy level, in
> ensuring that registries and registrars comply with policies related to
> those issues, developed through a bottom-up, consensus-based
> multistakeholder process.
>

 https://www.about.us/policies

https://www.about.us/documents/policies/usTLD_Dispute_Resolution_Policy_(usDRP).pdf



On Fri, Sep 6, 2024 at 9:35 AM Chad Dailey  wrote:

> At some point during or after Neustar .us bits were assigned to GoDaddy,
> we lost administrative control over some $govtdayjob namespace, and it is
> claimed to now be held by the registry.  Fast forward, we have a need to
> get things properly aligned.  Have been trying to get things sorted out in
> good faith but the process is dragging on, and we are getting the side-eye
> from leadership because we're not getting a related issue resolved.  I have
> a case number and supporting documentation, for what it's worth.  Next step
> is legal, and I'd really like to avoid that mess.
>
> If you're an authoritative person that can help get this sorted, or have
> contact information for that person or persons, please reach out to me.
>
> Thank you,
> Chad D
>

Re: Apple Geolocation contact?

[Tom Beecher]

>
> I've been fighting a similar issue. I'd like to throw in, a lot of mobile
> devices are geolocation dependent for time, and may completely disregard
> DHCP timezone and instead rely entirely on GeoLocation *even if it is
> woefully inaccurate, or unobtainable*.
>

1. RFC4833 *presumes* that the DHCP server KNOWS where the client IS to
begin with.
2. RFC4833 provides no mechanisms for the client to validate that the time
information sent to it is valid for its current location, or hasn't been
tampered with.

This is a pretty simple chicken / egg problem. If you need to know where
the client is to give it the right time zone, by definition something has
to know where the client is, so why not just use THAT for your location?

It's also massively insecure , especially these days, to just trust that
whatever TZ you got sent in DHCP is correct and wasn't manipulated or
spoofed. Using that as an indicator for *location* is . yeah

On Thu, Aug 29, 2024 at 7:32 PM Riley O via NANOG  wrote:

>
> Greetings from up the mountain (Lee Hill),
>
> I've been fighting a similar issue. I'd like to throw in, a lot of mobile
> devices are geolocation dependent for time, and may completely disregard
> DHCP timezone and instead rely entirely on GeoLocation *even if it is
> woefully inaccurate, or unobtainable*.
>
> The room being shielded from cellular and GPS, I would imagine removes the
> primary mechanism most devices use to locate themselves. In those cases,
> most devices won't fail back to normal timesetting standard practices, but
> instead just 'send it' and set the time to some obscure default based on
> zeroed location or hardcoded internals.
>
> Our issue at our house has been a total lack of cellular coverage and odd
> dynamics of GPS in a forest/valley leading to our mobiles falling back to
> obscure manufacturer default timezones when they reboot up here. If my cell
> phone goes dead, it will ignore the internal RTC on power up, and briefly
> show 00:00 before syncing with a timeserver and settings it's timezone to
> EST, regardless of what it was set to before or what DHCP says is correct.
>
>
> It's a real shame given our proximity to the NIST office. There are some
> really bright time folks over there, it might be worth your time to reach
> out to someone there. Surely someone at CU will know the right person :)
>
> Thanks,
> Riley C. O'Connor
> ColoradoColo - AS17139
> 307.438.9253 - m...@cubit.sh
>
>
> On Wednesday, August 28th, 2024 at 5:40 PM, J.R. Raith <
> rait...@jila.colorado.edu> wrote:
>
> >
>
> >
>
> > Hi All,
> >
>
> > I have a laboratory in my department which thinks it's in central Russia
> > when using Apple Maps on macOS and iOS devices. (I've also seen it in
> > Google Maps on macOS, which I assume is GMaps getting its location from
> > the OS). The lab has also reported Bhutan, Malta, and the equally exotic
> > Ohio. This room is a shielded from GPS and cellular signals, but may
> > pick up neighboring Access Points. Step outside of that specific room
> > and you're back in Colorado.
> >
>
> > Phones and laptops keep setting their timezone wildly wrong and we're
> > having graduate students and faculty missing classes/meetings.
> >
>
> > I've tried swapping out the Access Point in the lab. I've tried dropping
> > a pin in Apple Maps and reporting the location as incorrect, repeatedly
> > and with separate devices.
> >
>
> > I started looking at geolocatemuch, but I'm not sure that's the problem
> > in this instance. The NAT IP we come from shows proper location in
> > infosniper.
> >
>
> > I'd love to chat with an Apple person about how to solve it.
> >
>
> > Wish I could get frequent flyer miles for this...
> >
>
> > Thanks,
> > J.R. Raith
> > _
> > Network Administration & Desktop Support
> > JILA Computing - University of Colorado, Boulder

Re: Wi-Fi Calling in a corporate environment

[Tom Beecher]

My understanding has been that generally, if the cellular network signal
was above a certain threshold, phones won't even attempt to use wifi
calling. Some carriers used to let you flip a switch to force the phone to
prefer wifi over cellular, but some have removed that. ( Verizon for
example. )

In my experience some years ago in a similar environment, that
cellular threshold to switch was set so low that it was useless. I could be
standing in a spot with barely tickling the bottom bar, and nothing. If I
flipped to airplane mode, was able to wifi call instantly.

On Fri, Aug 2, 2024 at 11:11 AM  wrote:

> Hey all,
>
>
>
>Question if anyone knows about cell phone wi-fi calling in
> US.  Googling isn’t finding what I’m looking for.  We have a corporate site
> in US where users have BYOD capability, and use their phones with wi-fi
> calling enabled.  Site uses a single NAT address (IPv4) for BYOD access.
> Recently the site reported wi-fi calling had stopped working for all user
> phones, Apple and Android, all about the same time.  The guest network did
> have some bandwidth limitation applied and they had overuse.  That was
> since resolved, we upped the bandwidth.  But the phones all still avoided
> wi-fi calling.  It’s a manufacturing site with known cell signal issues, so
> most users had no signal via carrier.  I did not get a packet capture yet
> to see what could be going on, we’re 99% sure we’re not blocking traffic.
> I’m wondering if the phones have an algorithm to test wi-fi signal, and
> perhaps the carriers will blacklist public IPs with known wi-fi calling
> issues to avoid cases where an emergency call can’t be made because of
> intermittent bad performance?  It seems odd that even when no bandwidth
> issues exist, it’s not attempted.
>
>
>
> Thoughts?
>
>
>
> Thanks,
>
>
>
> Chuck Church
>

Re: Digicert revoking certain certs failing CNAME validation

[Tom Beecher]

Not shocked. At least one company got a TRO preventing the 24h revocation.

Honestly I think it's the right thing anyway. It doesn't make a ton of
sense to punish everyone else because the CA itself screwed up
and *created* a circumstance that happens to meet one of the 24h / no
extension conditions.

On Wed, Jul 31, 2024 at 12:14 AM Peter Fisher  wrote:

> Actually it looks like they have updated their incident page (
> https://status.digicert.com/incidents/3sccz3v31lc9) with a new revocation
> date depending on if you get an exception. Also more details can be found
> here(https://bugzilla.mozilla.org/show_bug.cgi?id=1910322#c5).
>
> On Tue, Jul 30, 2024 at 12:45 PM Peter Fisher  wrote:
>
>> I have not noticed any revocation yet for my affected certificates. Has
>> anyone had their affected certificates revoked yet?
>>
>> On Tue, Jul 30, 2024 at 12:35 PM Innocent Obi 
>> wrote:
>>
>>> Luckily it seems my org has since mitigated this, but it would be
>>> interesting to know the broader impacts/who is broadly impacted.
>>>
>>> On Tue, Jul 30, 2024 at 12:20 PM Tom Beecher  wrote:
>>>
>>>> If you're only getting this now, you're probably in trouble, because
>>>> they're revoking affected certs in about 15 mins.
>>>>
>>>> On Tue, Jul 30, 2024 at 2:53 PM Innocent Obi 
>>>> wrote:
>>>>
>>>>> Just in-case this hasn't made its way around:
>>>>> https://www.digicert.com/support/certificate-revocation-incident.
>>>>>
>>>>>

Re: Digicert revoking certain certs failing CNAME validation

[Tom Beecher]

If you're only getting this now, you're probably in trouble, because
they're revoking affected certs in about 15 mins.

On Tue, Jul 30, 2024 at 2:53 PM Innocent Obi 
wrote:

> Just in-case this hasn't made its way around:
> https://www.digicert.com/support/certificate-revocation-incident.
>
>

Re: lots of internet starting at ~3 a.m. cst

[Tom Beecher]

No, because there's no set schedule for these things.

Some publishers / consoles get content/patches up in advance to allow user
to pre-load. This can smooth out the bandwidth hits, but only if the users
enable the pre-load feature. Many don't. Other publishers just enable the
updates at once for everybody, and you see a big spike when they do.

The time of day is also not always the same either.

On Tue, Jul 23, 2024 at 10:09 AM Aaron Gould  wrote:

> thanks Peter, et al.  Is there some sort of website, traffic stats, gaming
> update schedule page for me to proactively see if/when this type of thing
> will occur?  I mean, this is a significant uptick on all 3 of my internet
> uplinks... would be nice to know beforehand
>
> -Aaron
>
>
> On 7/23/2024 9:02 AM, Peter Potvin wrote:
>
> Considering at least the top 4 IPs you've listed are CDN providers (Edgio
> and Fastly), this definitely sounds like game updates or something of the
> sort. Nothing unusual really for 3am on a weekday morning especially for an
> eyeball network.
>
> Kind regards,
> Peter
>
>
> On Tue, Jul 23, 2024 at 9:57 AM Aaron Gould  wrote:
>
>> Thanks Jason, updates for what?  I was hoping any other eyeball network 
>> operators may have been seeing "lots of internet" usage like me and may be 
>> able to share what they know.  I'm always suspicious about the typical game 
>> update that tends to cause something like this.  someone unicasted me a 
>> response that it might be related to F1 Manager 2024 for video game consoles 
>> released today
>>
>>
>> i grabbed my netflow data for the last few hours for any source ip that has 
>> sent more than 5 GB of data...
>>
>> Top 100 Src IP Addr ordered by bytes:
>> Date first seen  Duration Proto   Src IP AddrFlows(%) 
>> Packets(%)   Bytes(%) pps  bps   bpp
>> 2024-07-23 04:37:29.600 14860.800 any  93.184.215.240   557558( 0.6)  
>> 108.5 M( 9.2)  162.6 G(12.9) 7302   87.5 M  1497
>> 2024-07-23 04:42:07.616 14577.664 any72.21.81.240   361240( 0.4)   
>> 64.5 M( 5.5)   96.6 G( 7.7) 4426   53.0 M  1497
>> 2024-07-23 06:52:08.192  6781.696 any 151.101.162.172   270298( 0.3)   
>> 36.9 M( 3.1)   55.0 G( 4.4) 5445   64.9 M  1489
>> 2024-07-23 04:23:08.160 15722.240 any 151.101.150.1721.0 M( 1.0)   
>> 31.2 M( 2.6)   46.4 G( 3.7) 1985   23.6 M  1486
>> 2024-07-23 04:42:47.552 14542.592 any  146.75.106.172   238287( 0.2)   
>> 22.9 M( 1.9)   33.9 G( 2.7) 1575   18.7 M  1480
>> 2024-07-23 03:40:11.776 18298.880 any 199.232.214.172   135793( 0.1)   
>> 19.1 M( 1.6)   28.4 G( 2.3) 1043   12.4 M  1486
>> 2024-07-23 03:48:59.392 17769.728 any 199.232.210.172   135811( 0.1)   
>> 18.8 M( 1.6)   27.9 G( 2.2) 1057   12.6 M  1486
>> 2024-07-23 04:22:05.184 15783.680 any  199.232.70.172   923350( 0.9)   
>> 18.5 M( 1.6)   27.5 G( 2.2) 1169   14.0 M  1491
>> 2024-07-23 04:36:40.704 14909.696 any   146.75.42.172   138813( 0.1)
>> 5.6 M( 0.5)8.3 G( 0.7)  3744.5 M  1492
>> 2024-07-22 22:50:26.048 35683.840 any  199.232.70.252   112323( 0.1)
>> 5.4 M( 0.5)8.0 G( 0.6)  1501.8 M  1485
>> 2024-07-23 06:52:06.656  6783.488 any   146.75.10.17274859( 0.1)
>> 4.6 M( 0.4)6.8 G( 0.5)  6768.1 M  1489
>> 2024-07-23 02:38:16.704 22011.392 any 151.101.160.204 6114( 0.0)
>> 4.1 M( 0.3)6.2 G( 0.5)  1872.2 M  1489
>> 2024-07-23 01:34:17.728 25851.136 any 151.101.161.19044001( 0.0)
>> 4.1 M( 0.3)6.1 G( 0.5)  1571.9 M  1489
>> 2024-07-22 22:17:50.464 37638.912 any 199.232.154.25269420( 0.1)
>> 3.6 M( 0.3)5.4 G( 0.4)   961.1 M  1483
>>
>> -Aaron
>>
>>
>>
>> On 7/23/2024 8:19 AM, Peter Potvin wrote:
>>
>> Do you have *any* sort of additional information about this? Which
>> source and destination ASNs, how much "a lot" is, etc? This sounds like a
>> typical game update release cycle though without any information not a
>> whole lot of networks would be able to confirm anything.
>>
>> Kind regards,
>> Peter
>>
>>
>> On Tue, Jul 23, 2024 at 9:07 AM Aaron Gould  wrote:
>>
>>> Anyone else see a lot of Internet traffic starting at 3 a.m. and
>>> continuing even now?  Seems to be spiky tcp.
>>>
>>> --
>>> -Aaron
>>>
>>> --
>> -Aaron
>>
>> --
> -Aaron
>
>

Re: 600,000 routers bricked

[Tom Beecher]

>
> Lumen’s Black Lotus Labs detected the event; the post answers all of your
> concerns.
>

The source document from Black Lotus details the behavior of the malware
used to brick the equipment. It does NOT make any statements or claims that
the targeted devices were being used in botnet activity, which is the
accusation made by Mr. Perens in his post.

On Mon, Jun 3, 2024 at 9:27 AM Howard, Lee 
wrote:

> In the second paragraph, he cites his source:
> https://blog.lumen.com/the-pumpkin-eclipse/
>
>
>
> Lumen’s Black Lotus Labs detected the event; the post answers all of your
> concerns. Further, they remark that this was an especially sophisticated
> infection, that hid its tracks well.
>
>
>
> Lee
>
>
>
> *From:* NANOG  *On
> Behalf Of *Tom Beecher
> *Sent:* Sunday, June 2, 2024 4:23 PM
> *To:* Dave Taht 
> *Cc:* NANOG 
> *Subject:* Re: 600,000 routers bricked
>
>
>
> *This message is from an EXTERNAL SENDER - be CAUTIOUS, particularly with
> links and attachments.*
>
>
>
> That post from Mr. Perens about this is honestly really shitty.
>
>
>
> 1. Is he right that Lumen has to shoulder blame for not keeping CPE
> updated with exploit free software? Certainly.
>
> 2. Making a claim that all 600k of these routers were being used as botnet
> zombies without any supporting evidence is really poor form.
>
> 3. Even if we assert that 50% of these devices were exploited for botnet
> activity, that means 50% WEREN'T.  We shouldn't be applauding 300k
> people/businesses that just had their internet connectivity yeeted away
> from them through zero fault or their own.
>
> 4. "I've never heard of these router manufactures" is exceptionally
> ignorant. ActionTec has been around since the early 90s. Sagemcom wasn't
> someone I've heard of before , but so what.
>
>
>
> Yes, CPE provided by ISPs can be a problem. But applauding asshats who
> bricked all this stuff as some noble event that should be "applauded" as he
> says is really, really stupid. It's not going to meaningfully move the
> needle with how ISPs handle this stuff, and all it did was inconvenience a
> LOT of end users.
>
>
>
> On Sun, Jun 2, 2024 at 4:04 PM Dave Taht  wrote:
>
>
>
>
>
>
> https://www.linkedin.com/pulse/60-families-using-one-internet-provider-have-routers-bruce-perens-geedc/
>
>
>
>
> --
>
> https://www.youtube.com/watch?v=BVFWSyMp3xg&t=1098s Waves Podcast
>
> Dave Täht CSO, LibreQos
>
>

Re: 600,000 routers bricked

[Tom Beecher]

That post from Mr. Perens about this is honestly really shitty.

1. Is he right that Lumen has to shoulder blame for not keeping CPE updated
with exploit free software? Certainly.
2. Making a claim that all 600k of these routers were being used as botnet
zombies without any supporting evidence is really poor form.
3. Even if we assert that 50% of these devices were exploited for botnet
activity, that means 50% WEREN'T.  We shouldn't be applauding 300k
people/businesses that just had their internet connectivity yeeted away
from them through zero fault or their own.
4. "I've never heard of these router manufactures" is exceptionally
ignorant. ActionTec has been around since the early 90s. Sagemcom wasn't
someone I've heard of before , but so what.

Yes, CPE provided by ISPs can be a problem. But applauding asshats who
bricked all this stuff as some noble event that should be "applauded" as he
says is really, really stupid. It's not going to meaningfully move the
needle with how ISPs handle this stuff, and all it did was inconvenience a
LOT of end users.

On Sun, Jun 2, 2024 at 4:04 PM Dave Taht  wrote:

>
>
>
> https://www.linkedin.com/pulse/60-families-using-one-internet-provider-have-routers-bruce-perens-geedc/
>
>
> --
> https://www.youtube.com/watch?v=BVFWSyMp3xg&t=1098s Waves Podcast
> Dave Täht CSO, LibreQos
>

Re: Should FCC look at SS7 vulnerabilities or BGP vulnerabilities

[Tom Beecher]

https://blog.cloudflare.com/how-verizon-and-a-bgp-optimizer-knocked-large-parts-of-the-internet-offline-today

Keep mind rpki only solves misorigination.
>

I'm very well aware that RPKI only solves misorigination. But
misorigination is a significant problem, so that's a good problem to be
solved.

Not engaging with RPKI because it doesn't perfectly solve every
BGP-adjacent issue is a poor argument.

On Fri, May 17, 2024 at 7:24 PM Ca By  wrote:

>
>
> On Fri, May 17, 2024 at 4:20 PM Tom Beecher  wrote:
>
>> RPKI is not a good solution for all networks, especially those that are
>>> non-transit in nature and take reasonable mitigation actions like IRR
>>> prefix lists.
>>>
>>
>> Some of the largest , most impactful route leaks have come from
>> non-transit networks reliant on IRR managed prefix lists.
>>
>
> Can you be more specific?
>
> Was it malicious?
>
> Who in the usa was impacted ?
>
> Keep mind rpki only solves misorigination.
>
>
>> On Fri, May 17, 2024 at 5:21 PM Ca By  wrote:
>>
>>>
>>>
>>> On Fri, May 17, 2024 at 2:02 PM Sean Donelan  wrote:
>>>
>>>>
>>>> Sigh, industry hasn't solved spoofing and routing insecurity in two
>>>> decades.  If it was easy, everyone would have fixed it by now.
>>>>
>>>> Industry has been saying 'don't regulate us' for decades.
>>>
>>>
>>> I hope the regulations are more outcome focused.
>>>
>>> RPKI is not a good solution for all networks, especially those that are
>>> non-transit in nature and take reasonable mitigation actions like IRR
>>> prefix lists.
>>>
>>>
>>>
>>>>

Re: Should FCC look at SS7 vulnerabilities or BGP vulnerabilities

[Tom Beecher]

>
> RPKI is not a good solution for all networks, especially those that are
> non-transit in nature and take reasonable mitigation actions like IRR
> prefix lists.
>

Some of the largest , most impactful route leaks have come from non-transit
networks reliant on IRR managed prefix lists.

On Fri, May 17, 2024 at 5:21 PM Ca By  wrote:

>
>
> On Fri, May 17, 2024 at 2:02 PM Sean Donelan  wrote:
>
>>
>> Sigh, industry hasn't solved spoofing and routing insecurity in two
>> decades.  If it was easy, everyone would have fixed it by now.
>>
>> Industry has been saying 'don't regulate us' for decades.
>
>
> I hope the regulations are more outcome focused.
>
> RPKI is not a good solution for all networks, especially those that are
> non-transit in nature and take reasonable mitigation actions like IRR
> prefix lists.
>
>
>
>>

Re: Should FCC look at SS7 vulnerabilities or BGP vulnerabilities

[Tom Beecher]

>
> Just because they were presented with the information doesn't mean they
> understand.


It's our job as operators to get involved and help them understand as best
as can be done, so that the proposals are as well informed as possible.


> Just because they understand doesn't mean they execute based on that
> information.
>

No set of rules will ever be perfectly executed or implemented. Doesn't
matter if it's a government regulation or internal company rule. You try to
start from a good place, learn what works and what doesn't, and adjust
accordingly.


On Fri, May 17, 2024 at 11:11 AM Mike Hammett  wrote:

> Just because they were presented with the information doesn't mean they
> understand.
> Just because they understand doesn't mean they execute based on that
> information.
>
>
>
> -
> Mike Hammett
> Intelligent Computing Solutions
> http://www.ics-il.com
>
> Midwest-IX
> http://www.midwest-ix.com
>
> --
> *From: *"Job Snijders via NANOG" 
> *To: *"Josh Luthman" 
> *Cc: *"NANOG [nanog@nanog.org]" 
> *Sent: *Thursday, May 16, 2024 3:20:54 PM
> *Subject: *Re: Should FCC look at SS7 vulnerabilities or BGP
> vulnerabilities
>
> On Thu, May 16, 2024 at 04:05:21PM -0400, Josh Luthman wrote:
> > Now do you think they're going to properly understand what an SS7 or
> > vulnerability is?
>
> The FCC organised several sessions (private and public) where they
> invited knowledgeable people from this community to help edifice them on
> what BGP is and what risks exist.
>
> https://www.fcc.gov/news-events/events/2023/07/bgp-security-workshop
>
> Watch https://www.youtube.com/watch?v=VQhoNX2Q0aM to see our very own
> Tony Tauber looking sharp in a nice suit! :-)
>
> FCC staff attended NANOG & IETF meetings to further explore and discuss
> the problem space in the hallway track. If anything, I think the FCC
> made a proper effort to connect with various stakeholders and learn from
> them.
>
> Kind regards,
>
> Job
>
>

Re: Mailing list SPF Failure

[Tom Beecher]

Same, this address for me is also gmail.

This is what Gmail shows me from earlier today, when the SPF record was not
present :

Message ID <
bff409fd0177c9caf1461e2439691...@polarismail--com.w.emailarray.com>
Created at: Thu, May 16, 2024 at 11:59 AM (Delivered after 77 seconds)
From: "Scott Q."  Using Group-Office
To: Michael Thomas , nanog@nanog.org
Subject: Re: Mailing list SPF Failure
SPF: NONE with IP 50.31.151.76 Learn more


Message ID <74b33cf0-b7c4-46ac-8154-1cfca082e...@mtcc.com>
Created at: Thu, May 16, 2024 at 2:13 PM (Delivered after 85 seconds)
From: Michael Thomas 
To: "Scott Q." , nanog@nanog.org
Subject: Re: Mailing list SPF Failure
SPF: NONE with IP 50.31.151.76 Learn more
DKIM: 'PASS' with domain mtcc.com Learn more


Message ID <20240516190341.beb6f8b53...@ary.qy>
Created at: Thu, May 16, 2024 at 3:03 PM (Delivered after 79 seconds)
From: John Levine 
To: nanog@nanog.org
Subject: Re: Mailing list SPF Failure
SPF: NONE with IP 2001:1838:2001:8:0:0:0:20 Learn more
DKIM: 'FAIL' with domain iecc.com Learn more
DMARC: 'FAIL' Learn more

All 3 of these messages were delivered to my inbox as normal. The messages
from Scott and John provided warnings when hovering over the icon that the
user was not authenticated.


After the SPF record was fixed :

Message ID 
Created at: Thu, May 16, 2024 at 10:36 PM (Delivered after 68 seconds)
From: "John R. Levine" 
To: "Scott Q." 
Subject: Re: Mailing list SPF Failure
SPF: PASS with IP 50.31.151.76 Learn more
DKIM: 'PASS' with domain iecc.com Learn more
DMARC: 'PASS' Learn more

Message ID <
e47a1819deae8e7c8f592ab653c42...@polarismail--com.w.emailarray.com>
Created at: Thu, May 16, 2024 at 10:23 PM (Delivered after 180 seconds)
From: "Scott Q."  Using Group-Office
To: "John R. Levine" , William Herrin 
Subject: Re: Mailing list SPF Failure
SPF: PASS with IP 50.31.151.76 Learn more

The warnings were not present on these messages .

Google's support page if you click on those warnings it here :

https://support.google.com/mail/answer/180707

Where it states the following :

Check if a message is authenticated
>
> Important: Messages that aren't authenticated aren't necessarily spam.
> Sometimes authentication doesn't work for real organizations who send mail
> to big groups, like messages sent to mailing lists.
>

On Thu, May 16, 2024 at 10:46 PM Michael Thomas  wrote:

>
> On 5/16/24 7:36 PM, John R. Levine wrote:
> > I think a lot of us have nanog whitelisted or otherwise special cased.
>
> I don't and gmail is my backend. That's trivial falsification that lack
> of an SPF records alone will cause gmail rejects.
>
> Mike
>
> >
> > Also, it's been pumping out list mail for decades and I expect has a
> > close to zero complaint rate so even without the SPF ths IPs it sends
> > from have a good reputation.
> >
> > On Thu, 16 May 2024, Scott Q. wrote:
> >
> >> I'm surprised nobody noticed for close to 10 days. I was away
> >> from work and upon coming back I saw the little discussion there was ,
> >> in my Spam folder.
> >>
> >> On Thursday, 16/05/2024 at 18:56 John R. Levine wrote:
> >>
> >> On Thu, 16 May 2024, William Herrin wrote:
> >>> The message content (including the message headers) is theoretically
> >>> not used for SPF validation. In practice, some SPF validators don't
> >>> have direct access to the SMTP session so they rely on the SMTP
> >>> session placing the envelope sender in the Return-path header.
> >>
> >> But that wasn't the problem here, the SPF record was just
> >> gone.  Oops.
> >>
> >> I see that the SPF record is back and seems have the correct addresses
> >> so we can now return to our previously scheduled flamage.
>

Re: Mailing list SPF Failure

[Tom Beecher]

>
> I'm surprised nobody noticed for close to 10 days.


Probably because it wasn't 10 days.

On Thu, May 16, 2024 at 10:26 PM Scott Q.  wrote:

> I'm surprised nobody noticed for close to 10 days. I was away from work
> and upon coming back I saw the little discussion there was , in my Spam
> folder.
>
> On Thursday, 16/05/2024 at 18:56 John R. Levine wrote:
>
> On Thu, 16 May 2024, William Herrin wrote:
> > The message content (including the message headers) is theoretically
> > not used for SPF validation. In practice, some SPF validators don't
> > have direct access to the SMTP session so they rely on the SMTP
> > session placing the envelope sender in the Return-path header.
>
> But that wasn't the problem here, the SPF record was just gone.  Oops.
>
> I see that the SPF record is back and seems have the correct addresses so
> we can now return to our previously scheduled flamage.
>
> Regards,
> John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for
> Dummies",
> Please consider the environment before reading this e-mail. https://jl.ly
>
>

Re: On consistency and 192.0.0.0/24

[Tom Beecher]

>
> That means that some IP addresses in the block 192.0.0.0/24 may be
> routable.
>
> So, I would not make this a bogon.
>

This ignores note 2 on the IANA definitions page, next to 192.0.0.0/24 :

> [2]
>
> Not useable unless by virtue of a more specific reservation.
>
>  Which then lists the more specific reservations, of which SOME are
forwardable , and some are not.

The categorization as 'bogon' or not would really be determined by
individual operator use cases, and where/how such a bogon filter is
applied.



On Tue, May 14, 2024 at 12:23 PM Jakob Heitz (jheitz) via NANOG <
nanog@nanog.org> wrote:

> RFC 5736 was obsoleted by RFC 6890.
>
> It says in part:
>
>
>
> 2.2.1.  Information Requirements
>
>
>
>The IPv4 and IPv6 Special-Purpose Address Registries maintain the
>
>following information regarding each entry:
>
> …
>
>o  Forwardable - A boolean value indicating whether a router may
>
>   forward an IP datagram whose destination address is drawn from the
>
>   allocated special-purpose address block between external
>
>   interfaces.
>
> …
>
>
>
> That means that some IP addresses in the block 192.0.0.0/24 may be
> routable.
>
> So, I would not make this a bogon.
>
>
>
> A better way to filter IP routes is by policy, for example based upon
>
> IRR and RPKI records.
>
>
>
> Kind Regards,
>
> Jakob
>
>
>
> -- Original message --
>
> Date: Tue, 14 May 2024 12:00:15 +0200 (CEST)
> From: b...@uu3.net
>
>
> [10] 192.0.0.0/24 reserved for IANA IPv4 Special Purpose Address Registry
> [RFC5736]. Complete registration details for 192.0.0.0/24 are found in
> [IANA registry iana-ipv4-special-registry].
>
> Was RFC5736 obsoleted? I think not, so I would treat it as bogon.
>
> Its a nice tiny subnet for special purposes. I personaly use it
> as my Internal VM Net on my desktop for example.
>
>
> -- Original message --
>
> From: John Kristoff 
> To: NANOG 
> Subject: On consistency and 192.0.0.0/24
> Date: Mon, 13 May 2024 16:18:47 -0500
>
> As one to never let a good academic question go unasked... what is it
> about 192.0.0.0/24 that is or isn't a bogon. This doesn't seem so
> straightforward an answer to me, at least in theory.  Although in
> practice it may already be decided whether one likes the answer or not.
>
> 192.0.0.0/24 was originally assigned to IANA for "protocol assignments"
> in IETF RFC 5736, and later added to the list of reserved / special use
> addresses in IETF RFC 6890 (aka BCP 153).   There is a corresponding
> IPv6 block (2001::/23), but it has a significantly different history.
>
> Team Cymru's bogon list includes the v4 prefix.  NLNOG's bogon
> filtering guide does not.  When I asked Job about NLNOG's position he
> said:
>
>   "I was unsure what this prefix??s future plans would be and erred on
>   the side of caution and didn??t include this prefix in the NLNOG bogon
>   list recommendations."
>
> The /24 as specified is not for "global" use, but some of the more
> specific assignments are or can be.  See:
> <
> https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml
> >.
>
> From my cursory examination I can't find cases where the v4 prefix or
> more specifics have been publicly announced to any significant degree.
> This however is not the case for the IPv6 prefix (e.g., the AS112
> project, Teredo).
>
> Maybe you'd say the /24 should be filtered, but not the more specifics
> that are deemed available for global use.  That might be reasonable,
> except many reasonable people will filter small prefixes.
>
> IANA's language may have put any "do not filter" camp in a relatively
> weak position:
>
>   "Address prefixes listed in the Special-Purpose Address Registry are
>   not guaranteed routability in any particular local or global context."
>
> I can't remember hearing anyone complaining about bogon-related
> reachability problems with the aggregate IANA prefixes generally.  Is
> there a strong case to make that ops should not bogon filter any
> addresses in these prefixes?  At least with IPv4?  What about for IPv6?
>
> John
>
>

Re: Help with removing DNS shinkhole FP from Charter/Spectrum

[Tom Beecher]

Validin, made an interesting observation on this. I am also a Spectrum
residential customer,  none of their equipment, run my own DNS server
(pihole).

My DHCP Assigned DNS servers are

2001:1998:f00:1::1
2001:1998:f00:2::1

bash-3.2$ dig -x 2001:1998:f00:1::1 +short
dns-cac-lb-01.rr.com.
bash-3.2$ dig -x 2001:1998:f00:2::1 +short
dns-cac-lb-02.rr.com.
bash-3.2$


bash-3.2$ dig dns-cac-lb-01.rr.com +short
209.18.47.61
bash-3.2$ dig dns-cac-lb-02.rr.com +short
209.18.47.62
bash-3.2$

bash-3.2$ dig @209.18.47.61 validin.com +short
157.245.112.183
137.184.54.107
bash-3.2$ dig @209.18.47.62 validin.com +short
157.245.112.183
137.184.54.107
bash-3.2$

bash-3.2$ dig @2001:1998:f00:1::1 validin.com +short
127.0.0.54
bash-3.2$

bash-3.2$ dig @2001:1998:f00:2::1 validin.com +short
127.0.0.54
bash-3.2$

Same servers on V4 were returning correct info, but on V6 were not.

However, a few minutes later :

bash-3.2$ dig @2001:1998:f00:1::1 validin.com +short
157.245.112.183
137.184.54.107
bash-3.2$ dig @2001:1998:f00:2::1 validin.com +short
157.245.112.183
137.184.54.107
bash-3.2$

Deltas :

bash-3.2$ dig @2001:1998:f00:1::1  validin.com

; <<>> DiG 9.10.6 <<>> @2001:1998:f00:1::1 validin.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42329
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;validin.com.   IN  A

;; ANSWER SECTION:
validin.com.60  IN  A   127.0.0.54

;; Query time: 37 msec
;; SERVER: 2001:1998:f00:1::1#53(2001:1998:f00:1::1)
;; WHEN: Tue Apr 23 13:50:03 EDT 2024
;; MSG SIZE  rcvd: 45

bash-3.2$

bash-3.2$ dig @2001:1998:f00:1::1 validin.com

; <<>> DiG 9.10.6 <<>> @2001:1998:f00:1::1 validin.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 9667
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;validin.com.   IN  A

;; ANSWER SECTION:
validin.com.600 IN  A   157.245.112.183
validin.com.600 IN  A   137.184.54.107

;; Query time: 157 msec
;; SERVER: 2001:1998:f00:1::1#53(2001:1998:f00:1::1)
;; WHEN: Tue Apr 23 14:19:20 EDT 2024
;; MSG SIZE  rcvd: 72

bash-3.2$

Seems like quite possibly they are intermittently caching bunk data from
something.


On Tue, Apr 23, 2024 at 1:39 PM Validin Axon  wrote:

> Hi Jason,
>
> > I suspect what’s happened is an incorrect assumption that DNS is even
> the issue here. Because you mentioned Spectrum Shield, I suspect it is not.
>
> I appreciate the response and links. However, I've been told repeatedly by
> Spectrum that they're not blocking with Spectrum Shield. Despite these
> assurances, I've filled out a removal request through their published
> removal process several times, and the response I received stated that
> we're not being blocked. This check agrees with that:
> https://www.spectrum.net/support/forms/verify_url_security
>
> "Security Shield Is Not Blocking This Site
> The URL provided is not being blocked by Spectrum Security Shield
> The URL you entered should be accessible."
>
> Further, checking Spectrum DNS servers on the Spectrum network show that
> my company's main domain and all subdomains resolve to 127.0.0.54. So, if
> CujoAI/Spectrum Shield are not using DNS query responses to control access,
> then it's not CujoAI/Spectrum Shield that is responsible for the incorrect
> DNS response. Using a different recursive resolve, I can resolve our
> domains just fine. I can also resolve other domains that point to the same
> IPs as the sinkholed domain just fine. However, many people use the
> Spectrum default DNS servers and cannot access my website because of this.
>
> > You should contact Charter/Spectrum to have them investigate what their
> system might be blocking this content.
>
> I have tried, for months, including spending many hours on chat and phone
> support, to reach someone within Spectrum support who is capable of both
> understanding and directing me to someone who can fix the problem, but it
> hasn't happened yet. I've asked to talk to someone on the DNS team and was
> given a flat "No." I've posted here hoping that someone in the
> ISP-connected world knows SOMEONE at Spectrum, Akamai, or whichever company
> is actually responsible for the Spectrum DNS servers who can provide a
> remediation path.
>
> Regards,
>
> Kenneth
>
> On Tue, Apr 23, 2024 at 12:59 PM 'Livingood, Jason' via axon <
> a...@validin.com> wrote:
>
>> > However, there's no correction process for Spectrum's DNS sinkhole
>>
>> > But back to the topic: someone mentioned to me that Spectrum may not be
>> the direct providers for the DNS services they provide to their customers.
>> If anyone knows anything about how I might discover and reach out to the
>> people responsible, please let me know.
>>
>

Re: constant FEC errors juniper mpc10e 400g

[Tom Beecher]

I'm being sloppy with my verbiage, it's just been a long time since
I thought about this in detail, sorry.

The MAC layer hands bits to the Media Independent Interface, which connects
the MAC to the PHY. The PHY converts the digital 1/0 into the form required
by the media transmission type; the 'what goes over the wire' L1 stuff. The
method of encoding will always add SOME number of bits as overhead. Ex,
64b/66b means that for every 64 bits of data to transmit, 2 bits are added,
so 66 actual bits are transmitted. This encoding overhead is what I meant
when I said 'ethernet control frame juju'. This starts getting into the
weeds on symbol/baud rates and stuff as well, which I dont want to do now
cause I'm even rustier there.

When FEC is enabled, the number of overhead bits added to the transmission
increases. For 400G-FR4 for example, you start with 256b/257b , which is
doubled to 512b/514b for ($reason I cannot remember), then RS-FEC(544,514)
is applied, adding 30 more bits for FEC. Following the example, this means
544 bits are transmitted for every 512 bits of payload data. So , more
overhead. Those additional bits can correct up to 15 corrupted bits of the
payload.

All of these overhead bits are added in the PHY on the way out, and removed
on the way in. So you'll never see them on a packet capture unless you're
using something that's actually grabbing the bits off the wire.

( Pretty sure this is right, anyone please correct me if I munged any of it
up.)


On Thu, Apr 18, 2024 at 2:45 PM Aaron Gould  wrote:

> Thanks.  What "all the ethernet control frame juju" might you be referring
> to?  I don't recall Ethernet, in and of itself, just sending stuff back and
> forth.  Does anyone know if this FEC stuff I see concurring is actually
> contained in Ethernet Frames?  If so, please send a link to show the
> ethernet frame structure as it pertains to this 400g fec stuff.  If so, I'd
> really like to know the header format, etc.
>
> -Aaron
> On 4/18/2024 1:17 PM, Tom Beecher wrote:
>
> FEC is occurring at the PHY , below the PCS.
>
> Even if you're not sending any traffic, all the ethernet control frame
> juju is still going back and forth, which FEC may have to correct.
>
> I *think* (but not 100% sure) that for anything that by spec requires FEC,
> there is a default RS-FEC type that will be used, which *may* be able to be
> changed by the device. Could be fixed though, I honestly cannot remember.
>
> On Thu, Apr 18, 2024 at 1:35 PM Aaron Gould  wrote:
>
>> Not to belabor this, but so interesting... I need a FEC-for-Dummies or 
>> FEC-for-IP/Ethernet-Engineers...
>>
>> Shown below, my 400g interface with NO config at all... Interface has no 
>> traffic at all, no packets at all  BUT, lots of FEC hits.  Interesting 
>> this FEC-thing.  I'd love to have a fiber splitter and see if wireshark 
>> could read it and show me what FEC looks like...but something tells me i 
>> would need a 400g sniffer to read it, lol
>>
>> It's like FEC (fec119 in this case) is this automatic thing running between 
>> interfaces (hardware i guess), with no protocols and nothing needed at all 
>> in order to function.
>>
>> -Aaron
>>
>>
>> {master}
>> me@mx960> show configuration interfaces et-7/1/4 | display set
>>
>> {master}
>> me@mx960>
>>
>> {master}
>> me@mx960> clear interfaces statistics et-7/1/4
>>
>> {master}
>> me@mx960> show interfaces et-7/1/4 | grep packet
>> Input packets : 0
>> Output packets: 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 | grep rror
>>   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 Errors28209
>> FEC Uncorrected Errors  0
>> FEC Corrected Errors Rate2347
>> FEC Uncorrected Errors Rate 0
>>
>> {master}
>> me@mx960> show interfaces et-7/1/4 | grep packet
>> Input packets : 0
>> Output packets: 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)
>>
>> 

Re: constant FEC errors juniper mpc10e 400g

[Tom Beecher]

FEC is occurring at the PHY , below the PCS.

Even if you're not sending any traffic, all the ethernet control frame juju
is still going back and forth, which FEC may have to correct.

I *think* (but not 100% sure) that for anything that by spec requires FEC,
there is a default RS-FEC type that will be used, which *may* be able to be
changed by the device. Could be fixed though, I honestly cannot remember.

On Thu, Apr 18, 2024 at 1:35 PM Aaron Gould  wrote:

> Not to belabor this, but so interesting... I need a FEC-for-Dummies or 
> FEC-for-IP/Ethernet-Engineers...
>
> Shown below, my 400g interface with NO config at all... Interface has no 
> traffic at all, no packets at all  BUT, lots of FEC hits.  Interesting 
> this FEC-thing.  I'd love to have a fiber splitter and see if wireshark could 
> read it and show me what FEC looks like...but something tells me i would need 
> a 400g sniffer to read it, lol
>
> It's like FEC (fec119 in this case) is this automatic thing running between 
> interfaces (hardware i guess), with no protocols and nothing needed at all in 
> order to function.
>
> -Aaron
>
>
> {master}
> me@mx960> show configuration interfaces et-7/1/4 | display set
>
> {master}
> me@mx960>
>
> {master}
> me@mx960> clear interfaces statistics et-7/1/4
>
> {master}
> me@mx960> show interfaces et-7/1/4 | grep packet
> Input packets : 0
> Output packets: 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 | grep rror
>   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 Errors28209
> FEC Uncorrected Errors  0
> FEC Corrected Errors Rate2347
> FEC Uncorrected Errors Rate 0
>
> {master}
> me@mx960> show interfaces et-7/1/4 | grep packet
> Input packets : 0
> Output packets: 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 | grep rror
>   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 Errors45153
> FEC Uncorrected Errors  0
> FEC Corrected Errors Rate  29
> FEC Uncorrected Errors Rate 0
>
> {master}
> me@mx960> show interfaces et-7/1/4 | grep packet
> Input packets : 0
> Output packets: 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 | grep rror
>   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 Errors57339
> FEC Uncorrected Errors  0
> FEC Corrected Errors Rate2378
> FEC Uncorrected Errors Rate 0
>
> {master}
> me@mx960>
>
>
> On 4/18/2024 7:13 AM, Mark Tinka wrote:
>
>
>
> On 4/17/24 23:24, Aaron Gould wrote:
>
> Well JTAC just said that it seems ok, and that 400g is going to show 4x
> more than 100g "This is due to having to synchronize much more to support
> higher data."
>
>
> We've seen the same between Juniper and Arista boxes in the same rack
> running at 100G, despite cleaning fibres, swapping optics, moving ports,
> moving line cards, e.t.c. TAC said it's a non-issue, and to be expected,
> and shared the same KB's.
>
> It's a bit disconcerting when you plot the data on your NMS, but it's not
> material.
>
> Mark.
>
> --
> -Aaron
>
>

Re: constant FEC errors juniper mpc10e 400g

[Tom Beecher]

>
> We've seen the same between Juniper and Arista boxes in the same rack
> running at 100G, despite cleaning fibres, swapping optics, moving ports,
> moving line cards, e.t.c. TAC said it's a non-issue, and to be expected,
> and shared the same KB's.
>
>
 Just for extra clarity off those KB, probably has nothing to do with
vendor interop as implied in at least one of those.

You will see some volume of FEC corrected on 400G FR4 with the same router
hardware and transceiver vendor on both ends, with a 3m patch. Short of
duct taping the transceivers together, not going to get much more optimal
than that.

As far as I can suss out from my reading and what Smart People have told
me, certain combinations of modulation and lamda are just more susceptible
to transmission noise, so for those FEC is required by the standard. PAM4
modulation does seem to be a common thread, but there are some PAM2/NRZs
that FEC is also required for. ( 100GBASE-CWDM4 for example. )



On Thu, Apr 18, 2024 at 8:15 AM Mark Tinka  wrote:

>
>
> On 4/17/24 23:24, Aaron Gould wrote:
>
> > Well JTAC just said that it seems ok, and that 400g is going to show
> > 4x more than 100g "This is due to having to synchronize much more to
> > support higher data."
> >
>
> We've seen the same between Juniper and Arista boxes in the same rack
> running at 100G, despite cleaning fibres, swapping optics, moving ports,
> moving line cards, e.t.c. TAC said it's a non-issue, and to be expected,
> and shared the same KB's.
>
> It's a bit disconcerting when you plot the data on your NMS, but it's
> not material.
>
> Mark.
>

Re: constant FEC errors juniper mpc10e 400g

[Tom Beecher]

Notes I found that I took from smart optical people :

"PAM4 runs at much lower SNRs than NRZ, because you're trying to read 4
distinct voltage levels instead of 2.Even the cleanest system will have
some of that, so the only way to make it usable is to have FEC in place."



On Wed, Apr 17, 2024 at 4:01 PM Fredrik Holmqvist / I2B 
wrote:

> Hi.
>
> Looks like normal behavior:
>
>
> https://supportportal.juniper.net/s/article/PTX-FEC-corrected-errors-increasing-on-link-between-QSFP-100GBASE-SR4-740-058734-and-QSFP-100G-SR4-T2-740-061405?language=en_US
>
> "An incrementing FEC Corrected Errors counter is normal for a link that
> is running FEC. It just indicates that the errored bits have been
> corrected by FEC. "
>
> "Therefore, the incrementing FEC Corrected Errors counter might only be
> indicating an interoperability issue between the optics from .."
>
> ---
> Fredrik Holmqvist
> I2B & BBTA tjänster AB
> 08-590 90 000
>
> On 2024-04-17 21:36, 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  

Re: constant FEC errors juniper mpc10e 400g

[Tom Beecher]

Isn't FEC required by the 400G spec?

On Wed, Apr 17, 2024 at 3:45 PM Aaron Gould  wrote:

> i did.  Usually my NANOG and J-NSP email list gets me a quicker solution
> than JTAC.
>
> -Aaron
> On 4/17/2024 2:37 PM, Dominik Dobrowolski wrote:
>
> Open a JTAC case,
> That looks like a work for them
>
>
> Kind Regards,
> Dominik
>
> W dniu śr., 17.04.2024 o 21:36 Aaron Gould  napisał(a):
>
>> 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

Re: Whitebox Routers Beyond the Datasheet

[Tom Beecher]

Agreed.

I think as a practical matter, the large majority of operators probably
only care about time from last update / EoRIB -> FIBs forwarding working.
As long as that time delta is acceptable for their environment and
circumstances, that's 'good enough'. Definitely some edge cases and
circumstances that can factor in.

Those of us in the massive scale part of the world certainly have our own
unique problems with this stuff. :)

On Sat, Apr 13, 2024 at 11:58 AM Jared Mauch  wrote:

>
>
> > On Apr 13, 2024, at 12:15 AM, 7ri...@gmail.com wrote:
> >
> >
> >> I feel like this shouldn't be listed on a data sheet for just the
> whitebox hardware. The software running on it would be the gating factor.
> > There would be two things ... BGP convergence, and then the time
> required to get routes from the RIB into the hardware forwarding tables.
> These are completely separate things. Both are gated on software for the
> most part, and it would be hard to measure them unless you know a lot more
> about the environment. Even then it would be a bit of a guess.
> >
> > Contact me off list if you're interested in prior experience in this
> area.
> >
> > :-) /r
>
>
> Yeah, I think the question is coming from the wrong direction, which is
> what route scale do you need then match it to the hardware.  You can load a
> variety of software on these devices, including putting something like cRPD
> on top of it so you have the Juniper software and policy language, or roll
> your own with FRR, BIRD or something else.
>
> The kernel -> FIB (hardware) download performance will vary as will the
> way the TCAM is carved up into the various routes and profiles.
>
> It also depends on what you download to the FIB vs what you have in your
> RIB, for example a fib-filter in Juniper parlance may give you the ability
> to carry a full routing table but just a default and your local stub routes
> depending on the device role.  (Connected/static + local iBGP+eBGP learned)
>
> - Jared

Re: Whitebox Routers Beyond the Datasheet

[Tom Beecher]

>
> Also, BGP convergence isn't listed (nor do I rarely ever see it talked
> about in such sheets).


I feel like this shouldn't be listed on a data sheet for just the whitebox
hardware. The software running on it would be the gating factor.

On Fri, Apr 12, 2024 at 9:05 AM Mike Hammett  wrote:

> I'm looking at the suitability of whitebox routers for high through, low
> port count, fast BGP performance applications. Power efficiency is
> important as well.
>
> What I've kind of come down to (based on little more than spec sheets) are
> the EdgeCore AGR400 and the UfiSpace S9600-30DX. They can both accommodate
> at least three directions of 400G for linking to other parts of my network
> and then have enough 100G or slower ports to connect to transit, peers, and
> customers as appropriate. Any other suggestions for platforms similar to
> those would be appreciated.
>
> They both appear to carry buffers large enough to accommodate buffering
> differences in port capacities, which is an issue I've seen with boxes more
> targeted to cloud\datacenter switching.
>
> What isn't in the spec sheets is BGP-related information. They don't
> mention how many routes they can hold, just that they have additional TCAM
> to handle more routes and features. That's wonderful and all, but does it
> take it from 64k routes to 512k routes, or does it take it from 256k routes
> up to the millions of routes? Also, BGP convergence isn't listed (nor do I
> rarely ever see it talked about in such sheets). I know that software-based
> routers can now load a full table in 30 seconds or less. I know that
> getting the FIB  updated takes a little bit longer. I know that withdrawing
> a route takes a little bit longer. However, often, that performance is
> CPU-based. An underpowered CPU may take a minute or more to load that table
> and may take minutes to handle route churn. Can anyone speak to these
> routers (or routers like these) ability to handle modern route table
> activity?
>
> My deployment locations and philosophies simply won't have me in an
> environment where I need the density of dozens of 400G\100G ports. That the
> routers that seem to be more marketed to the use case are designed for.
>
>
>
> -
> Mike Hammett
> Intelligent Computing Solutions
> http://www.ics-il.com
>
> Midwest-IX
> http://www.midwest-ix.com
>
>

Re: N91 Women mixer on Sunday?

[Tom Beecher]

I don't think anything is 'easily fixed' on this topic.

I do however hope that everyone accepts at face value that the board,
staff, and PC are *trying* to do the right things here. Doesn't mean that
it *will* always be the right thing, or even that a majority of people can
agree on what the right thing actually is.

On Fri, Mar 29, 2024 at 1:05 AM Eric Parsonage  wrote:

> It's easily fixed by having a mixer at the same time for the other half of
> the gathering population thus showing all the population gathering matters
> equally.
>
>
>
> On 29 March 2024 2:50:19 pm ACDT, Ren Provo  wrote:
>
>> I beg to differ here and second Ilissa’s comments.  I miss WiT.  Lunch
>> during the meeting worked.  Giving up more of the weekend to travel does
>> not show half the population gathering matters.
>>
>>
>> On Thu, Mar 28, 2024 at 15:16 Morris, Tina via NANOG 
>> wrote:
>>
>>> Illissa,
>>> The mixer is at 5pm Sunday, this allows people to network and prepare
>>> for the week. Sunday also has a hackathon, registration, and often a
>>> welcome social. NANOG has a very compressed schedule and another time would
>>> actually mean that the women participating would have to pick between this
>>> event and another event or talk  that may be critical to their job
>>> function, which is also unfair.
>>>
>>> We are advertising this mixer to make sure all are aware and can attend,
>>> and the mixers will  be on the schedule at the same approximate time at
>>> each meeting going forward.
>>>
>>> I hope we will see you there.
>>>
>>> Tina Morris
>>>
>>>
>>> On Mar 28, 2024, at 14:12, Thomas Scott 
>>> wrote:
>>>
>>> 
>>>
>>> *CAUTION*: This email originated from outside of the organization. Do
>>> not click links or open attachments unless you can confirm the sender and
>>> know the content is safe.
>>>
>>> > While the times are changing, women continue to remain primary
>>> caregivers for families and this will require them to desert their families
>>> a day early.  I find it offensive personally and feel like you may have
>>> missed the mark.
>>>
>>> The hackathon has for (as far as I’ve known about it) been on Sunday. I
>>> don’t work on Sundays - it’s a day for my family (unless the almighty pager
>>> goes off), so I’ve never gone - even though it’s one of the parts of NANOG
>>> I’d enjoy, and would benefit from the most.
>>>
>>> There are tradeoffs for everything - perhaps the idea was to keep the
>>> women’s mixer separate from the other evening events, so that those who
>>> wish to participate, can do all of the evening events, and not have to give
>>> up anything, at the cost of the extra day. That being said, I agree, moving
>>> more to Sunday is not an acceptable answer to me.
>>>
>>> Best Regards,
>>> -Thomas Scott
>>>
>>> On Mar 28, 2024 at 1:45:07 PM, Ilissa Miller 
>>> wrote:
>>>
 For those that know me, I rarely provide constructive input about NANOG
 matters due to my past affiliation, however, I just saw that NANOG
 announced the Women mixer on Sunday before NANOG 91 and am outraged for all
 of the young professional women
 ZjQcmQRYFpfptBannerStart
 This Message Is From an Untrusted Sender
 You have not previously corresponded with this sender.

 ZjQcmQRYFpfptBannerEnd

>>> For those that know me, I rarely provide constructive input about NANOG
 matters due to my past affiliation, however, I just saw that NANOG
 announced the Women mixer on Sunday before NANOG 91 and am outraged for all
 of the young professional women who would like to participate in NANOG.
 While the times are changing, women continue to remain primary caregivers
 for families and this will require them to desert their families a day
 early.  I find it offensive personally and feel like you may have missed
 the mark.

 The amount of times I hear people complain about having to leave their
 families is one of the reasons this industry has a problem keeping young
 people - especially women.

 Does anyone else feel the same?



 --
 *Ilissa Miller*
 *CEO, iMiller Public Relations
 *

Re: N91 Women mixer on Sunday?

[Tom Beecher]

>
> My memory is a little fuzzy, but I think I recall one of the early WiT
> lunches hosted at NANOG that was women-only, where some men were upset
> for being "left out". Whether that was good or bad is less important
> than understanding what the outcome of a women-only activity is for
> women, especially for those for whom it may not be immediately obvious.
>

My recollection is that every WiT lunch was always open to all. Happy to be
corrected if any were that I don't recall.

There were definitely a few meetings during my PC years that someone
complained that men were not allowed to attend. If my memory serves me
correctly, we at one point were asking session moderators to remind people
of this in general session for a while too. For some meetings, a few of us
were standing at the doors telling people who asked that men were allowed
to attend that if they would like.




On Fri, Mar 29, 2024 at 1:34 AM Mark Tinka  wrote:

>
>
> On 3/29/24 07:03, Eric Parsonage wrote:
>
> > It's easily fixed by having a mixer at the same time for the other
> > half of the gathering population thus showing all the population
> > gathering matters equally.
>
> My memory is a little fuzzy, but I think I recall one of the early WiT
> lunches hosted at NANOG that was women-only, where some men were upset
> for being "left out". Whether that was good or bad is less important
> than understanding what the outcome of a women-only activity is for
> women, especially for those for whom it may not be immediately obvious.
>
> While equal access to opportunity between the genders is the most
> effective policy, I think there is utility in women having their own
> session, given that they face unique challenges in an industry where
> they are the minority operators.
>
> Mark.
>

Re: N91 Women mixer on Sunday?

[Tom Beecher]

There was a Women in Tech Mixer on Sunday in Charlotte as well. As I recall
there was a pretty decent attendance.

During my time on the PC, we always got a lot of feedback about Sunday when
the topic came up. Some members were strongly opposed to anything on Sunday
and didn't even like the Hackathon there. Others wanted expansion, and more
things slotted in. There certainly wasn't anything remotely close to a
consensus. Sometimes people can make it in early on Sunday. Sometimes they
can't. There's no one size fits all answer.

I'm not sure people realize how much crap that staff and the PC get *every
meeting* about the agenda. There's always someone unhappy because this
event wasn't the same, or why was it in this room over here, or OMG Wed
afternoon, etc. Having seen how that sausage gets made, they don't get
enough credit.

In my opinion, they found a spot that they had room for, and if people can
make it with their schedules, then great. If not, hopefully a future slot
can work.

On Thu, Mar 28, 2024 at 1:46 PM Ilissa Miller  wrote:

> For those that know me, I rarely provide constructive input about NANOG
> matters due to my past affiliation, however, I just saw that NANOG
> announced the Women mixer on Sunday before NANOG 91 and am outraged for all
> of the young professional women who would like to participate in NANOG.
> While the times are changing, women continue to remain primary caregivers
> for families and this will require them to desert their families a day
> early.  I find it offensive personally and feel like you may have missed
> the mark.
>
> The amount of times I hear people complain about having to leave their
> families is one of the reasons this industry has a problem keeping young
> people - especially women.
>
> Does anyone else feel the same?
>
>
>
> --
> *Ilissa Miller*
> *CEO, iMiller Public Relations *
>
>
>
>

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

[Tom Beecher]

Yeah, cost to implement dst_as_path lookups far outweighs the usefulness
IMO. If you really want that it's much better to get it via BMP. ( Same
with communities and localpref in the extended gateway definition of
sflow.  )

Fundamentally I've always disagreed with how sFlow aggregates flow data
with network state data. IMO you collect the two things separately, and
join them off-device should you need to for analysis.

On Thu, Mar 28, 2024 at 1:50 PM Saku Ytti  wrote:

> Hey,
>
> On Thu, 28 Mar 2024 at 17:49, Peter Phaal  wrote:
>
> > sFlow was mentioned because I believe Brian's routers support the
> feature and may well export the as-path data directly via sFlow (I am not
> aware that it is a feature widely supported in vendor NetFlow/IPFIX
> implementations?).
>
> Exporting AS information is wire-format agnostic feature, if it's
> supported or not, it can equally be injected into sFlow, NetflowV5
> (src and dst only), NetflowV9 and IPFIX. The cost is that you need to
> program in FIB entries the information, so that the information
> becomes available at look-up time for record creation.
>
> In OP's case (IOS-XR) this means enabling 'attribute-download' for
> BGP, and I believe IOS-XR will never download any other asn but src
> and dst, therefore full information cannot be injected into any
> emitted wire-format.
> --
>   ++ytti
>

Re: AWS Web Application Firewall blocks ISP ranges?

[Tom Beecher]

Lots of people are encountering this, yes.

You can try opening a case yourself, and hope it gets to someone with a
clue. If you don't have a support contract with them, your chances are
almost 0. If you do, your chances are slightly higher, but not by much.
most likely they will just tell you to 'contact the owner of the thing
you're trying to access and have them customize their WAF rules'.

AWS is doing some REALLY dumb things. For example, if your ASN announces a
single prefix that a 3rd party provider classifies as 'hosting provider' ,
AWS will flag EVERY prefix from that ASN as 'hosting provider', which are
all blocked in the default managed WAF rules. They also won't tell you in
any circumstance (even if you're a customer who is paying for support)  who
that 3rd party provider IS.

Expect a lot of hassle to get this fixed, if you ever can.

On Thu, Mar 21, 2024 at 1:26 PM Jonathan Kalbfeld via NANOG 
wrote:

> Hi All,
>
> I just became aware that AWS has a list of hosting IP providers and that
> list is blocked by their WAF? (!?!?).  None of my VM or colo customers
> can reach anything in AWS, such as Docker, Twilio, etc.  I confirmed
> through source routing that when I access it using one of my peering
> partners as a source IP it is reachable, but using one of my net blocks, it
> is not reachable and times out.  Checked all of my routing tables and those
> AWS blocks are definitely visible.  Also confirmed from looking glass that
> my IP ranges are showing up.
>
> Has anyone else encountered that? If so, is there a way to get removed
> from that list? I have a very curated list of clients and I know all of
> them personally and none of them have been abusing AWS, so I was wondering
> if it was some kind of blanket ban?
>
> If you're internal to AWS, my ASN is 54380, IP ranges affected are
> 199.33.244.0/24, 199.79.202.0/24, 199.188.96.0/22, 45.59.144.0/22 and
> 206.197.110.0/24
>
> Feel free to reach out off-list.
>
> Thanks,
>
> Jonathan Kalbfeld
>
> Jonathan Kalbfeld
>
> office: +1 310 317 7933 <%28310%29%20317-7933>
> fax:+1 310 317 7901 <%28310%29%20317-7901>
> home:   +1 310 317 7909 <%28310%29%20317-7909>
> mobile: +1 310 227 1662 <%28310%29%20227-1662>
>
> ThoughtWave Technologies, Inc.
> Studio City, CA 91604
> https://thoughtwave.com
>
> View our network at
> https://bgp.he.net/AS54380
>
> +1 844 42-LINUX
>
>

Re: Best TAC Services from Equipment Vendors

[Tom Beecher]

>
> It may be a pain in the butt to get Cisco equipment, but their TAC is
> sublime.  If something is critical enough, and you push hard enough, Cisco
> will move heaven and earth to solve your issue.
>

This was an amazing laugh on a Monday morning. Thanks!

On Thu, Mar 7, 2024 at 2:47 PM Joel Esler  wrote:

> It may be a pain in the butt to get Cisco equipment, but their TAC is
> sublime.  If something is critical enough, and you push hard enough, Cisco
> will move heaven and earth to solve your issue.
> —
> Sent from my iPhone
>
> On Mar 6, 2024, at 13:42, Pascal Masha  wrote:
>
> 
> For us this has been the experience to a point where 100s of nodes( from
> vendor x) had to be swapped out because no one had the patience anymore…
>
> On Wed, 6 Mar 2024 at 21:29,  wrote:
>
>> Interesting, this has never been my experience even with Cisco or
>> Juniper, have always been able to escalate quickly to engineering. I wonder
>> if it was related to the size of my accounts.
>>
>> Shane
>>
>> > On Mar 6, 2024, at 1:27 PM, Pascal Masha  wrote:
>> >
>> > Thought about it but so far I believe companies from China provide
>> better and fast TAC responses to their customers than the likes of Cisco
>> and perhaps that’s why some companies(where there are no
>> restrictions)prefer them for critical services.
>> >
>> > For a short period in TAC call you can have over 10 R&D engineers and
>> solutions provided in a matter of hours even if it involves software
>> changes.. while these other companies even before you get in a call with a
>> TAC engineer it’s hours and when they join you hear something like “my
>> shift ended 15 minutes ago, hold let me look for another engineer”. WHY?
>> Thoughts
>>
>

Re: [External] Fiber aggregators and such

[Tom Beecher]

>
>  I think there is
> a very careful attitude around making sure not just anyone can get
> this information, especially after the Nashville bombing on Christmas
> Day 2020.
>

Keeping fiber location info close to the vest is nothing new. I'm not now
sure why/how you feel like this connects to the Nashville incident.

On Mon, Mar 4, 2024 at 1:00 PM Hunter Fuller via NANOG 
wrote:

> On Mon, Mar 4, 2024 at 11:23 AM Jared Mauch  wrote:
> >
> > With all the $ being spent expanding fiber in the last mile, I’ve got a
> theory that a lot of new and diverse fiber routes are being built between
> locations.
> >
> > There’s a few places I know that roll up some of this information, but
> I’m wondering if there’s anyone rolling this all up either publicly or
> privately.
>
>
> Jared,
>
> In the North Alabama area, you are certainly correct. And as a
> well-known central entity in that region, we have sort of
> unintentionally become one of the arbiters of this subject. So of
> course internally we are aggregating all the information.
>
> The problem is that, at least half the time I learn of this
> information, either the other entities aren't willing to disclose the
> real details, or they disclose the details to me but it's expected
> that I not share them outside of my own organization. I think there is
> a very careful attitude around making sure not just anyone can get
> this information, especially after the Nashville bombing on Christmas
> Day 2020.
>
> Maybe there could be a public aggregator of those who aggregate the
> information privately...?? Not sure what the answer is here.
>
> --
> Hunter Fuller (they)
> Router Jockey
> VBH M-1C
> +1 256 824 5331
>
> Office of Information Technology
> The University of Alabama in Huntsville
> Network Engineering
>

Re: Any info on AT&T Wireless Outage?

[Tom Beecher]

>
> Erik Prince was on the PBD podcast saying he has a 70% chance in his head
> it was China.
>

Why do we care what his (almost certainly uninformed) opinion is?

On Thu, Feb 29, 2024 at 2:56 PM Javier J  wrote:

> Where did you see this? Erik Prince was on the PBD podcast saying he has a
> 70% chance in his head it was China. I tend to learn towards human error
> from my experience in the IT biz.
>
> - J
>
> On Wed, Feb 28, 2024 at 10:58 AM  wrote:
>
>> I read it as “someone pushed an ACL that wasn’t properly reviewed and it
>> really screwed things up."
>>
>> On Feb 27, 2024, at 21:41, Mark Seiden  wrote:
>>
>> aside from the official pablum that was released about an “incorrect
>> process used”
>> (which says exactly nothing) does anyone actually know anything accurate
>> and
>> more specific about the root cause?
>>
>> (and why it took 11 hours to recover?)
>>
>> On Feb 22, 2024, at 11:15 AM, John Councilman 
>> wrote:
>>
>> From what I've read, they lost their database of SIM cards.  I could be
>> wrong of course.
>>
>> On Thu, Feb 22, 2024 at 2:02 PM Dorn Hetzel  wrote:
>>
>>> As widespread as it seemed to be, it feels like it would be quite a
>>> trick if it were a single piece of hardware.  Firmware load that ended
>>> badly, I wonder?
>>>
>>>
>>> On Thu, Feb 22, 2024 at 1:51 PM Leato, Gary via NANOG 
>>> wrote:
>>>
 Do you have the ability to expand on this at all? Do you mean a
 hardware failure of some kind IE router, optitcs, etc?



 *From:* NANOG  *On
 Behalf Of *R. Leigh Hennig
 *Sent:* Thursday, February 22, 2024 8:17 AM
 *To:* Robert DeVita 
 *Cc:* nanog@nanog.org
 *Subject:* Re: Any info on AT&T Wireless Outage?



 Word around the campfire is that it’s a Cisco issue.



 On Feb 22, 2024, at 8:03 AM, Robert DeVita 
 wrote:



 Reports have it starting at 4:30 a.m.. SOS on all phones..







 *Robert DeVita**​**​**​**​*

 *CEO and Founder*

 t: (469) 581-2160 <(469)%20581-2160>

  |

 m: (469) 441-8864 <(469)%20441-8864>

 e: radev...@mejeticks.com

  |

 w: mejeticks.com 

 a:

 2323 N Akard Street

 ,

 Dallas

 ,

 75201

 

 

 

 




 The risk of trading futures and options can be substantial. All
 information, publications, and material used and distributed by Advance
 Trading Inc. shall be construed as a solicitation. ATI does not maintain an
 independent research department as defined in CFTC Regulation 1.71.
 Information obtained from third-party sources is believed to be reliable,
 but its accuracy is not guaranteed by Advance Trading Inc. Past performance
 is not necessarily indicative of future results.

>>>
>>
>>

Re: Why are paper LOAs still used?

[Tom Beecher]

Perhaps the provider only had a single person maintaining the tooling they
used to interact with the IRR records, that person left/was laid off, and
it broke. Perhaps they don't have anyone else that can make it work again,
and they don't want to hire someone else, so they fell back to paper.

Perhaps they have a legal reason to require a paper trail and not rely on
IRR records.

Plenty of possibilities, all plausible.

On Mon, Feb 26, 2024 at 1: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: AWS WAF list

[Tom Beecher]

>
> and it's affecting our customers' access to various ===>> websites.<<===
>


On Tue, Feb 20, 2024 at 6:15 PM Pui Ee Luun Edylie  wrote:

> There must be a reason why the web site chooses the WAF list to block out
> the victim? If so why not the victim to contact the website to request them
> to talk to the waf list provider to remove victim ip block?
>
>
>
> Edy
>
>
>
> *From:* NANOG  *On Behalf Of *Owen
> DeLong via NANOG
> *Sent:* Wednesday, 21 February 2024 7:04 am
> *To:* j...@joelesler.net
> *Cc:* NANOG 
> *Subject:* Re: AWS WAF list
>
>
>
> Unfortunately, the victim doesn’t chose the WAF list, the web site that is
> causing the victim grief chooses the WAF list.
>
>
>
> Owen
>
>
>
>
>
> On Feb 20, 2024, at 14:15, j...@joelesler.net wrote:
>
>
>
> There are other WAF lists available on AWS besides their native one.  Ones
> that have support.
>
>
>
> On Feb 20, 2024, at 16:18, George Herbert 
> wrote:
>
>
>
> This is terrible advice, but you might need another netblock for the
> eyeballs.  Possibly a small one with enterprise NAT, but something outside
> the AWS list ranges...
>
>
>
>
>
> -George
>
>
>
> On Mon, Feb 19, 2024 at 7:35 PM Justin H.  wrote:
>
> That matches my experience with these types of problems in the past.
> Especially when the end-users don't have a process for white-listing.
> We actually got a response from one WAF user to "connect to another
> network to log in, then you should be able to use the site, because it's
> just the login page that's protected".
>
> I am working with someone off-list, so I have hope this can be resolved
> without account gymnastics. :)
>
> Justin H.
>
> Owen DeLong wrote:
> > The whole situation with these WAF as a service setups is a nightmare
> for the affected (afflicted) parties.
> >
> > I saw this problem from both sides when I was at Akamai. It’s not great
> from the service provider side, but it’s an absolute shit show for anyone
> on the wrong side of a block. There’s no accountability or process for
> redress of errors whatsoever. The impacted party isn’t a customer of the
> WAF publisher, so they cant get any traction there. The WAF subscriber
> blindly applies the WAF and it’s virtually impossible to track down anyone
> there who even knows that they subscribe to such a thing, let alone get
> them to take useful action.
> >
> > Best of luck.  The only thing I saw that worked while I was at Akamai
> was a few entities subscribed to the WAF service and then complained about
> getting blocked from their own web sites. Since they were then Akamai WAF
> customers, they could get Akamai to take action.
> >
> > Crazy.
> >
> > Owen
> >
> >
> >> On Feb 16, 2024, at 09:19, Justin H.  wrote:
> >>
> >> Justin H. wrote:
> >>> Hello,
> >>>
> >>> We found out recently that we are on the HostingProviderIPList (found
> here
> https://docs.aws.amazon.com/waf/latest/developerguide/aws-managed-rule-groups-ip-rep.html)
> at AWS and it's affecting our customers' access to various websites.  We
> are a datacenter, and a hosting provider, but we have plenty of enterprise
> customers with eyeballs.
> >>>
> >>> We're finding it difficult to find a technical contact that we can
> reach since we're not an AWS customer.  Does anyone have a contact or
> advice on a solution?
> >> Sadly we're not getting any traction from standard AWS support, and end
> users of the WAF list like Reddit and Eventbrite are refusing to whitelist
> anyone.  Does anyone have any AWS contacts that might be able to assist?
> Our enterprise customers are becoming more and more impacted.
> >>
> >> Justin H.
>
>
>
>
> --
>
> -george william herbert
> george.herb...@gmail.com
>
>
>
>
>

Re: IPv6 uptake

[Tom Beecher]

>
> I'm not going to participate in the security conversation, but we do
> absolutely need something to fill the role of NAT in v6. If it's already
> there or not, I don't know. Use case: Joe's Taco Shop. Joe doesn't want a
> down Internet connection to prevent transactions from completing, so he
> purchases two diverse broadband connections, say a cable connection and a
> DSL connection. When ISP fails, traffic will have to exit ISP B. He's not
> getting a /48, LOA, BGP, etc. to do it on his own, he's just going to do
> simple NAT.


If you are asserting that the business is just taking the
dynamic allocations from ISP A and ISP B, and NAT'ing internal stuff to
those , then sure, that works, until ISP A goes down, and the NAT device
must detect that so it no longer uses those addresses until it comes back
up. Which is of course doable, but is no longer 'simple' NAT.

On Mon, Feb 19, 2024 at 9:53 AM Mike Hammett  wrote:

> "We can seriously lose NAT for v6 and not lose
> anything of worth."
>
> I'm not going to participate in the security conversation, but we do
> absolutely need something to fill the role of NAT in v6. If it's already
> there or not, I don't know. Use case: Joe's Taco Shop. Joe doesn't want a
> down Internet connection to prevent transactions from completing, so he
> purchases two diverse broadband connections, say a cable connection and a
> DSL connection. When ISP fails, traffic will have to exit ISP B. He's not
> getting a /48, LOA, BGP, etc. to do it on his own, he's just going to do
> simple NAT.
>
>
>
> -
> Mike Hammett
> Intelligent Computing Solutions
> http://www.ics-il.com
>
> Midwest-IX
> http://www.midwest-ix.com
>
> --
> *From: *"Michael Thomas" 
> *To: *nanog@nanog.org
> *Sent: *Saturday, February 17, 2024 12:50:46 PM
> *Subject: *Re: IPv6 uptake
>
>
> On 2/17/24 10:26 AM, Owen DeLong via NANOG wrote:
> >
> >> On Feb 16, 2024, at 14:20, Jay R. Ashworth  wrote:
> >>
> >> - Original Message -
> >>> From: "Justin Streiner" 
> >>> 4. Getting people to unlearn the "NAT=Security" mindset that we were
> forced
> >>> to accept in the v4 world.
> >> NAT doesn't "equal" security.
> >>
> >> But it is certainly a *component* of security, placing control of what
> internal
> >> nodes are accessible from the outside in the hands of the people inside.
> > Uh, no… no it is not. Stateful inspection (which the kind of NAT
> (actually NAPT) you are assuming here depends on) is a component of
> security. You can do stateful inspection without mutilating the header and
> have all the same security benefits without losing or complicating the
> audit trail.
>
> Exactly. As I said elsewhere, the security properties of NAT were a
> post-hoc rationalization. In the mean time, it has taken on its own life
> as if not NAT'ing (but still having stateful firewalls) would end the
> known security universe. We can seriously lose NAT for v6 and not lose
> anything of worth.
>
> Mike
>
>
>
>

Re: IPv6 uptake (was: The Reg does 240/4)

[Tom Beecher]

>
> Any given layer of security can be breached with expense and effort.
> Breaching every layer of security at the same time is more challenging
> than breaching any particular one of them. The use of NAT adds a layer
> of security to the system that is not otherwise there.
>
>
> Think of it like this: you have a guard, you have a fence and you have
> barbed wire on top of the fence. Can you secure the place without the
> barbed wire? Of course. Can an intruder defeat the barbed wire? Of
> course. Is it more secure -with- the barbed wire? Obviously.
>

Bill-

In a security context, NAT/PAT only provides *obfuscation* of the internal
numbering and source ports of the networks on the inside of the NAT/PAT
device. "Security by obscurity" is a well debunked maxim by now. Any
perceived benefits that obscurity provides are gone as soon as the
information attempting to be hidden can be discovered, or the methods by
which it functions are known. It may slightly deter the lazy, but
techniques to discover the otherwise 'hidden' numbering and port usage have
existed for decades.


On Fri, Feb 16, 2024 at 10:28 PM William Herrin  wrote:

> On Fri, Feb 16, 2024 at 7:10 PM John Levine  wrote:
> > If you configure your firewall wrong, bad things will happen.  I have
> both
> > IPv6 and NAT IPv4 on my network here and I haven't found it particularly
> > hard to get the config correct for IPv6.
>
> Hi John,
>
> That it's possible to implement network security well without using
> NAT does not contradict the claim that NAT enhances network security.
>
> That it's possible to breach the layer of security added by NAT does
> not contradict the claim that NAT enhances network security.
>
> Any given layer of security can be breached with expense and effort.
> Breaching every layer of security at the same time is more challenging
> than breaching any particular one of them. The use of NAT adds a layer
> of security to the system that is not otherwise there.
>
>
> Think of it like this: you have a guard, you have a fence and you have
> barbed wire on top of the fence. Can you secure the place without the
> barbed wire? Of course. Can an intruder defeat the barbed wire? Of
> course. Is it more secure -with- the barbed wire? Obviously.
>
> Regards,
> Bill Herrin
>
> --
> William Herrin
> b...@herrin.us
> https://bill.herrin.us/
>

Re: The Reg does 240/4

[Tom Beecher]

$/IPv4 address peaked in 2021, and has been declining since.

On Thu, Feb 15, 2024 at 16:05 Brian Knight via NANOG 
wrote:

> On 2024-02-15 13:10, Lyndon Nerenberg (VE7TFX/VE6BBM) wrote:
> > I've said it before, and I'll say it again:
> >
> >   The only thing stopping global IPv6 deployment is
> >   Netflix continuing to offer services over IPv4.
> >
> > If Netflix dropped IPv4, you would see IPv6 available *everywhere*
> > within a month.
>
> As others have noted, and to paraphrase a long-ago quote from this
> mailing list, I'm sure all of Netflix's competitors hope Netflix does
> that.
>
> I remain hopeful that the climbing price of unique, available IPv4
> addresses eventually forces migration to v6. From my armchair, only
> through economics will this situation will be resolved.
>
> > --lyndon
>
> -Brian
>

Re: The Reg does 240/4

[Tom Beecher]

>
> This is the first time we've presented this case so I'm uncertain as to
> how you've come to the conclusion that I've "presented [my] case numerous
> times" and that we "continue to persist".


This may be the first time your group has presented your opinions on 240/4,
but you are not the first. It's been brought up at IETF multiple times,
multiple drafts submitted, multiple debates / convos / arguments had.

At the end of the day, the following is still true.

1. Per RFC2860, IANA maintains the registry of IPv4 allocations to RIRs,
and the IPv4 Special Address Space Registry.
2. The IPv4 Special Address Space Registry records 240.0.0.0/4 as Reserved
, per RFC1112, Section 4.
3. Any changes to the IPv4 Special Address Space Registry require IETF
Review , RFC7249, Section 2.2.
4. IETF Review is defined in RFC5226.

In summation, the status of 240/4 CAN ONLY be changed IF the IETF process
results in an RFC that DIRECTS IANA to update the IPv4 Special Address
Space Registry. To date, the IETF process has not done so.

Making the case on mailing lists , forums, or media outlets may try to win
hearts and minds, but unless the IETF process is engaged with, nothing will
change. Of course, some will want to reply that 'the IETF are meanies and
don't want to do what we want'. All I'd say to that is , welcome to the
process of making / changing internet standards.  :)



On Thu, Feb 15, 2024 at 6:29 AM Christopher Hawker 
wrote:

> Owen,
>
> This is the first time we've presented this case so I'm uncertain as to
> how you've come to the conclusion that I've "presented [my] case numerous
> times" and that we "continue to persist".
>
> I also don't know how us diverting energy from 240/4 towards IPv6
> deployment in privately-owned networks will help. People cannot be made to
> adopt IPv6 (although IMO they should) and until they are ready to do so we
> must continue to support IPv4, for new and existing networks. While we can
> encourage and help people move towards IPv6 we can't force adoption through
> prevention of access to IPv4.
>
> Regards,
> Christopher Hawker
> --
> *From:* Owen DeLong 
> *Sent:* Thursday, February 15, 2024 4:23 AM
> *To:* Christopher Hawker 
> *Cc:* Tom Beecher ; North American Operators' Group <
> nanog@nanog.org>
> *Subject:* Re: The Reg does 240/4
>
> This gift from the bad idea fairy just keeps on giving. You’ve presented
> your case numerous times. The IETF has repeatedly found no consensus for it
> and yet you persist.
>
> Think how many more sites could have IPv6 capability already if this
> wasted effort had been put into that, instead.
>
> Owen
>
>
> On Feb 13, 2024, at 14:16, Christopher Hawker 
> wrote:
>
> 
> Hi Tom,
>
> We aren't trying to have a debate on this. All we can do is present our
> case, explain our reasons and hope that we can gain a consensus from the
> community.
>
> I understand that some peers don't like the idea of this happening and yes
> we understand the technical work behind getting this across the line. It's
> easy enough for us to say "this will never happen" or to put it into the
> "too hard" basket, however, the one thing I can guarantee is that will
> never happen, if nothing is done.
>
> Let's not think about ourselves for a moment, and think about the
> potential positive impact that this could bring.
>
> Regards,
> Christopher Hawker
> --
> *From:* Tom Beecher 
> *Sent:* Wednesday, February 14, 2024 1:23 AM
> *To:* Christopher Hawker 
> *Cc:* North American Operators' Group ;
> aus...@lists.ausnog.net ; Christopher Hawker via
> sanog ; apnic-t...@lists.apnic.net <
> apnic-t...@lists.apnic.net>
> *Subject:* Re: The Reg does 240/4
>
>
> Now, we know there's definitely going to be some pushback on this. This
> won't be easy to accomplish and it will take some time.
>
>
>  It won't ever be 'accomplished' by trying to debate this in the media.
>
> On Tue, Feb 13, 2024 at 5:05 AM Christopher Hawker 
> wrote:
>
> Hello all,
>
> [Note: I have cross-posted this reply to a thread from NANOG on AusNOG,
> SANOG and APNIC-Talk in order to invite more peers to engage in the
> discussion on their respective forums.]
>
> Just to shed some light on the article and our involvement...
>
> Since September 1981, 240/4 has been reserved for future use, see
> https://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xhtml.
> This space has always been reserved for future use and given the global
> shortage of available space for

Re: NANOG 90 Attendance?

[Tom Beecher]

> Maybe this should have gone to the members mailing list, but I couldn’t
> find one.
>
>
>

memb...@nanog.org

On Thu, Feb 15, 2024 at 10:31 AM Howard, Lee via NANOG 
wrote:

> I’m jumping on an earlier part of the thread.
>
>
>
> Based on what I heard at the Members Meeting and several follow up hallway
> conversations, I think:
>
>- NANOG needs a focus group on attendees. A survey won’t do it, we
>need a deep dive into roles, interests, career level, and why they attend.
>- Somebody or somebodies should be specifically tasked with following
>up with every one of the 120 newcomer attendees to ask what it would take
>to get them to come back. Our conversion rate to repeat attendee is a key
>performance indicator. There’s a great Newcomer Orientation just before
>conference opening; let’s have a Newcomer Lessons Learned at the end.
>- Poll attendees on relative importance of location, registration fee,
>programming, side meeting space. Iterate based on comments (location =
>airport? Hotel? Nearby amenities? Proximity to home?)
>- Survey sponsors. I give feedback to staff and occasional board
>members, but there’s no clear way to gather information.
>- These should be sent to the Members in advance of a Members Meeting
>to discuss. Needs more than 20 minutes of a 45 minute meeting before main
>programming.
>- Consider empaneling a Mission Committee to review NANOG’s mission
>and how to fulfill it.
>
>
>
> Other thoughts, which I couldn’t submit in a survey or find another way to
> send to the board or staff:
>
>- I suggested in San Diego and now bring to the list: the last item on
>the agenda should be 15-30 minutes of “What are you taking home from this
>NANOG?”
>   - Helps remind people what value they got
>   - Lets us know what people found most valuable (Specific sessions?
>   deals done? Trends in hallway topics?)
>   - Solidifies for people what they can offer their boss as the value
>   of sending them to NANOG
>- We should look into cooperating with other network organizations for
>meetings. WISPAmerica, NRECA, NTCA, Fiber Connect, SCTE, IETF
>- ARIN has a help desk in the main hall. Allow other sponsors to put
>up a Help Desk. Put up a sign showing which company will be there for which
>half-day increment. I think a lot of attendees would find value in the
>ability to sit down with a senior sales engineer at their favorite router,
>optical, or intelligence vendor to say, “Here’s my problem,” even if many
>of those conversations resulted in “Let’s schedule time to discuss in more
>depth.”
>   - Price it like BnG—you’re getting ½ day of visibility, less
>   distraction than meal/break sponsors
>   - Require swag to be incidentals like pens and stickers—if you’re
>   getting a mad rush of people, you’re missing the point
>
>
>
>
>
> This can’t all be done in time for Kansas City, but maybe some of it can
> be. Given that hotel contracts are negotiated two years in advance, I
> figure we have about two years to get this right before it’s too late to
> steer the ship away from the rocks.
>
>
>
> Let me close with: I think we have an excellent board, all of whom love
> this community and have spent years thinking about this. The lack of a CEO
> is a problem soon to be resolved, and that will help support the already
> excellent staff. There are themes we’ve been hearing for several meetings
> in a row, and I know the board is giving them a lot of thought, and I’m
> just trying to support those efforts from outside the board.
>
>
>
> Maybe this should have gone to the members mailing list, but I couldn’t
> find one.
>
>
>
> Lee
>
>
>
>
>
> *From:* NANOG  *On
> Behalf Of *Warren Kumari
> *Sent:* Sunday, February 11, 2024 2:50 PM
> *To:* Mike Hammett 
> *Cc:* nanog 
> *Subject:* Re: NANOG 90 Attendance?
>
>
>
> You don't often get email from war...@kumari.net. Learn why this is
> important 
>
> *This message is from an EXTERNAL SENDER - be CAUTIOUS, particularly with
> links and attachments.*
>
>
>
>
>
>
>
>
>
>
>
> On Sun, Feb 11, 2024 at 8:31 AM, Mike Hammett  wrote:
>
> I haven't been to a NANOG meeting in a while. While going through the
> attendee list for NANOG 90 to try to book meetings with people, I noticed a
> lack of (or extremely minimal) attendance by several organizations that
> have traditionally had several employees attend. I've also noticed that
> some organizations I had an interest in were only sending sales people, not
> technical people.
>
>
>
>
>
> There have been a few changes - part of this is driven by post-pandemic
> decreased travel budget in many organizations, part by industry changes and
> consolidation, but also a fair bit seems to be because the tone of NANOG
> has changed and become much more of a polished, sales-y feeling event than
> it used to be….
>
>
>
> Here is the curren

Re: The Reg does 240/4

[Tom Beecher]

>
> All we can do is educate people on the importance of IPv6 uptake, we can
> not force people to adopt it.
>

At this stage of the game, networks and products that don't support V6
aren't likely to do so unless there is a forcing function to make them do
it. Meaning money.



On Wed, Feb 14, 2024 at 6:35 PM Christopher Hawker 
wrote:

> John,
>
> If you feel that it is wasted time, you are welcome to not partake in the
> discussion. Your remarks have been noted.
>
> It's all well and good to say that "more sites could have IPv6 if time
> wasn't being wasted on 240/4" however we can only do so much regarding the
> deployment of v6 within networks we manage. All we can do is educate people
> on the importance of IPv6 uptake, we can not force people to adopt it. The
> only way to rapidly accelerate the uptake of IPv6 is for networks is to
> either offer better rates for v6 transit, or disable v4 connectivity
> completely.
>
> Otherwise v6 connectivity is going to dawdle at the current rate it is.
>
> Regards,
> Christopher Hawker
> --
> *From:* NANOG  on behalf of
> John Levine 
> *Sent:* Thursday, February 15, 2024 10:11 AM
> *To:* nanog@nanog.org 
> *Subject:* Re: The Reg does 240/4
>
> It appears that William Herrin  said:
> >On Wed, Feb 14, 2024 at 9:23 AM Owen DeLong via NANOG 
> wrote:
> >> Think how many more sites could have IPv6 capability already if this
> wasted effort had been put into that, instead.
> >
> >"Zero-sum bias is a cognitive bias towards zero-sum thinking;
>
> Well, OK, think how many more sites could hav IPv6 if people weren't
> wasting time arguing about this nonsense.
>
> R's,
> John
>
>
>

Re: NANOG 90 Attendance?

[Tom Beecher]

None of the conversation was about COVID protocols.

Lowered in person attendance because of *individual concerns about health
risks* was mentioned. The conversation then went sideways into public
health policy and definitions, which absolutely doesn't belong on the list.

On Wed, Feb 14, 2024 at 7:06 PM Paul Ebersman 
wrote:

> mhammett> This seems more ideological and not overly appropriate for
> mhammett> NANOG.
>
> No, covid protocols are something that every conference that is serious
> about inclusion should be *very* concerned with.
>
> Saying that NANOG doesn't care about this says that NANOG can't be
> bothered to make an effort to make the conference safe for more folks.
>
> There's a reason I'm not there in person, even though I've attended for
> years, spoken there, and volunteered for multiple rounds on committees.
>
>

Re: NANOG 90 Attendance?

[Tom Beecher]

>
> Except we aren't really "post-pandemic" despite the claims that we are.
>

"post-pandemic" the way that I used it was to mean "after the COVID
lockdowns,  with close to normal travel gatherings".

It certainly wasn't intended to be commentary on the current state of
COVID, if it's referred to as 'pandemic' or 'endemic' , etc. Nor does that
sort of convo really belong anywhere near this list.

On Tue, Feb 13, 2024 at 7:58 PM Glen A. Pearce  wrote:

> On 11/02/2024 7:56 a.m., Tom Beecher wrote:
> > Yup. Post pandemic, the unfortunate hotel situation, and a non-zero
> > number of companies still have tight travel budgets.
> >
> > It's been slowly creeping back though.
>
> Except we aren't really "post-pandemic" despite the claims that we are.
>
> As long as COVID exists and we don't reach eradication there are going to
> be a number of people who might have otherwise participated in these
> types of events that will opt not to if they have the choice. Unfortunately
> I don't see us eradicating COVID as long as governments succeed at
> convincing people that it's not a problem anymore because that's easier
> than taking on the people that throw a fit if pandemic control measures
> inconvenience them.
>
> Info on what a problem COVID still is from some of the few people that
> still write about it:
> https://www.okdoomer.io/its-that-bad/
>
> https://www.textise.net/showText.aspx?strURL=https%253A//www.normalcyfugitive.com/p/the-pandemic-isnt-over
>
> Now I know I can't tell people what to do but I can share what I know
> if it might help some people.  This pandemic has been one failure after
> another with the virus being underestimated at every turn.  I have
> thoughts on what I think should be done to get us to eradication
> but that gets political and probably too off topic for NANOG.
>
> So back to the topic, because of this situation there will always be some
> people opting out of gatherings wherever possible as long as this drags
> on and we won't ever be fully back to "normal" as much as many
> people try to fake normal.  (I think Jessica at okdoomer had it nailed
> when she used the term "cosplaying 2019".)  It may be a little less
> obvious as most of the people opting out aren't really being vocal
> about why, they just aren't showing up.
>
> As for why the sales people are still showing up...
> ...detachment from reality has long been a big part of "sales culture".
> (Whereas it's not an inherent into "techy culture".)
>
> --
> Glen A. Pearce
> g...@ve4.ca
> Network Manager, Webmaster, Bookkeeper, Fashion Model and Shipping Clerk.
> Very Eager 4 Tees
> http://www.ve4.ca
> ARIN Handle VET-17
>
>

Re: The Reg does 240/4

[Tom Beecher]

>
> We aren't trying to have a debate on this. All we can do is present our
> case, explain our reasons and hope that we can gain a consensus from the
> community.


Respectfully, if you're just putting your case out there and hoping that
people come around to your position, it's never going to happen.

On Tue, Feb 13, 2024 at 5:15 PM Christopher Hawker 
wrote:

> Hi Tom,
>
> We aren't trying to have a debate on this. All we can do is present our
> case, explain our reasons and hope that we can gain a consensus from the
> community.
>
> I understand that some peers don't like the idea of this happening and yes
> we understand the technical work behind getting this across the line. It's
> easy enough for us to say "this will never happen" or to put it into the
> "too hard" basket, however, the one thing I can guarantee is that will
> never happen, if nothing is done.
>
> Let's not think about ourselves for a moment, and think about the
> potential positive impact that this could bring.
>
> Regards,
> Christopher Hawker
> --
> *From:* Tom Beecher 
> *Sent:* Wednesday, February 14, 2024 1:23 AM
> *To:* Christopher Hawker 
> *Cc:* North American Operators' Group ;
> aus...@lists.ausnog.net ; Christopher Hawker via
> sanog ; apnic-t...@lists.apnic.net <
> apnic-t...@lists.apnic.net>
> *Subject:* Re: The Reg does 240/4
>
>
> Now, we know there's definitely going to be some pushback on this. This
> won't be easy to accomplish and it will take some time.
>
>
>  It won't ever be 'accomplished' by trying to debate this in the media.
>
> On Tue, Feb 13, 2024 at 5:05 AM Christopher Hawker 
> wrote:
>
> Hello all,
>
> [Note: I have cross-posted this reply to a thread from NANOG on AusNOG,
> SANOG and APNIC-Talk in order to invite more peers to engage in the
> discussion on their respective forums.]
>
> Just to shed some light on the article and our involvement...
>
> Since September 1981, 240/4 has been reserved for future use, see
> https://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xhtml.
> This space has always been reserved for future use and given the global
> shortage of available space for new network operators we feel it is
> appropriate for this space to be reclassified as Unicast space available
> for delegation by IANA/PTI to RIRs on behalf of ICANN.
>
> At present, the IP space currently available for RIRs to delegate to new
> members is minimal, if any at all. The primary goal of our call for change
> is to afford smaller players who are wanting to enter the industry the
> opportunity to do so without having to shell out the big dollars for space.
> Although I do not agree with IP space being treated as a commodity (as this
> was not what it was intended to be), those who can afford to purchase space
> may do so and those who cannot should be able to obtain space from their
> respective RIR without having to wait over a year in some cases just to
> obtain space. It's not intended to flood the market with resources that can
> be sold off to the highest bidder, and this can very well be a way for
> network operators to plan to properly roll out IPv6. At this point in time,
> the uptake and implementation of IPv6 is far too low (only 37% according to
> https://stats.labs.apnic.net/ipv6) for new networks to deploy IPv6
> single-stack, meaning that we need to continue supporting IPv4 deployments.
>
> The reallocation of IPv4 space marked as Future Use would not restrict or
> inhibit the deployment of IPv6, if anything, in our view it will help the
> deployment through allowing these networks to service a greater number of
> customers than what a single /24 v4 prefix will allow. Entire regions of an
> economy have the potential to be serviced by a single /23 IPv4 prefix when
> used in conjunction with IPv6 space.
>
> Now, some have argued that we should not do anything with IPv4 and simply
> let it die out. IPv4 will be around for the foreseeable future and while it
> is, we need to allow new operators to continue deploying networks. It is
> unfair of us to say "Let's all move towards IPv6 and just let IPv4 die"
> however the reality of the situation is that while we continue to treat it
> as a commodity and allow v6 uptake to progress as slowly as it is, we need
> to continue supporting it v4. Some have also argued that networks use this
> space internally within their infrastructure. 240/4 was always marked as
> Reserved for Future Use and if network operators elect to squat on reserved
> space instead of electing to deploy v6 across their internal networks then
> that is an issue they need 

Re: The Reg does 240/4

[Tom Beecher]

>
> PS: I know this because it will take 98 years of process before the
> RIRs can start allocating it.
>

Intense optimism detected!

On Tue, Feb 13, 2024 at 4:27 PM John Levine  wrote:

> It appears that Lyndon Nerenberg (VE7TFX/VE6BBM)  said:
> >And what are they going to do when 240/4 runs out?
>
> That will be a hundred years from now, so who cares?
>
> R's,
> John
>
> PS: I know this because it will take 98 years of process before the
> RIRs can start allocating it.
>
>
>
>

Re: The Reg does 240/4

[Tom Beecher]

>
> Now, we know there's definitely going to be some pushback on this. This
> won't be easy to accomplish and it will take some time.


 It won't ever be 'accomplished' by trying to debate this in the media.

On Tue, Feb 13, 2024 at 5:05 AM Christopher Hawker 
wrote:

> Hello all,
>
> [Note: I have cross-posted this reply to a thread from NANOG on AusNOG,
> SANOG and APNIC-Talk in order to invite more peers to engage in the
> discussion on their respective forums.]
>
> Just to shed some light on the article and our involvement...
>
> Since September 1981, 240/4 has been reserved for future use, see
> https://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xhtml.
> This space has always been reserved for future use and given the global
> shortage of available space for new network operators we feel it is
> appropriate for this space to be reclassified as Unicast space available
> for delegation by IANA/PTI to RIRs on behalf of ICANN.
>
> At present, the IP space currently available for RIRs to delegate to new
> members is minimal, if any at all. The primary goal of our call for change
> is to afford smaller players who are wanting to enter the industry the
> opportunity to do so without having to shell out the big dollars for space.
> Although I do not agree with IP space being treated as a commodity (as this
> was not what it was intended to be), those who can afford to purchase space
> may do so and those who cannot should be able to obtain space from their
> respective RIR without having to wait over a year in some cases just to
> obtain space. It's not intended to flood the market with resources that can
> be sold off to the highest bidder, and this can very well be a way for
> network operators to plan to properly roll out IPv6. At this point in time,
> the uptake and implementation of IPv6 is far too low (only 37% according to
> https://stats.labs.apnic.net/ipv6) for new networks to deploy IPv6
> single-stack, meaning that we need to continue supporting IPv4 deployments.
>
> The reallocation of IPv4 space marked as Future Use would not restrict or
> inhibit the deployment of IPv6, if anything, in our view it will help the
> deployment through allowing these networks to service a greater number of
> customers than what a single /24 v4 prefix will allow. Entire regions of an
> economy have the potential to be serviced by a single /23 IPv4 prefix when
> used in conjunction with IPv6 space.
>
> Now, some have argued that we should not do anything with IPv4 and simply
> let it die out. IPv4 will be around for the foreseeable future and while it
> is, we need to allow new operators to continue deploying networks. It is
> unfair of us to say "Let's all move towards IPv6 and just let IPv4 die"
> however the reality of the situation is that while we continue to treat it
> as a commodity and allow v6 uptake to progress as slowly as it is, we need
> to continue supporting it v4. Some have also argued that networks use this
> space internally within their infrastructure. 240/4 was always marked as
> Reserved for Future Use and if network operators elect to squat on reserved
> space instead of electing to deploy v6 across their internal networks then
> that is an issue they need to resolve, and it should not affect how it is
> reallocated. It goes against the bottom-up approach of policy development
> by allowing larger network operators to state that this space cannot be
> made unicast because they are using it internally (even though it's not
> listed in RFC1918), and its reallocation would affect their networks.
>
> In the APNIC region, there is a policy which only allows for a maximum of
> a /23 IPv4 prefix to be allocated/assigned to new members and any more
> space required must be acquired through other means. If (as an example)
> APNIC were to receive 3 x /8 prefixes from the 240/4 space this would allow
> for delegations to be made for approximately the next ~50 years whereas if
> policy was changed to allow for delegations up to and including a /22 this
> would extend the current pool by well over 20 years, based on current
> exhaustion rates and allowing for pool levels to return to pre-2010 levels.
>
> Now, we know there's definitely going to be some pushback on this. This
> won't be easy to accomplish and it will take some time. However, if we do
> nothing then nothing will happen. The currently available pool has reached
> severe exhaustion levels yet we have a block representing about 6% of the
> total possible IP space which may not seem like a lot yet it can go a long
> way.
>
> This call for change is not about making space available for existing
> networks. It is about new networks emerging into and on the internet. While
> we do work towards IPv6 being the primary addressing method we need to
> continue allow those who may not be able to deploy IPv6 to connect to the
> internet.
>
> Regards,
> Christopher Hawker
>
> --
> *From:* NANOG  on behalf of
> J

Re: NANOG 90 Attendance?

[Tom Beecher]

Yup. Post pandemic, the unfortunate hotel situation, and a non-zero number
of companies still have tight travel budgets.

It's been slowly creeping back though.

On Sun, Feb 11, 2024 at 8:44 AM Ryan Hamel  wrote:

> Mike,
>
> The numbers have not bounced back to pre-pandemic levels, and it doesn't
> help that NANOG 90 has had some hotel issues.
>
> Ryan
>
> --
> *From:* NANOG  on behalf of
> Mike Hammett 
> *Sent:* Sunday, February 11, 2024 5:31:02 AM
> *To:* nanog 
> *Subject:* NANOG 90 Attendance?
>
> Caution: This is an external email and may be malicious. Please take care
> when clicking links or opening attachments.
>
> I haven't been to a NANOG meeting in a while. While going through the
> attendee list for NANOG 90 to try to book meetings with people, I noticed a
> lack of (or extremely minimal) attendance by several organizations that
> have traditionally had several employees attend. I've also noticed that
> some organizations I had an interest in were only sending sales people, not
> technical people.
>
> How long has this been a thing? I remember when I attended years ago that
> there simply wasn't enough time to meet with technical people from all of
> the organizations I wanted to meet with. Now the calendar is looking a bit
> dry.
>
>
>
> -
> Mike Hammett
> Intelligent Computing Solutions
> http://www.ics-il.com
>
> Midwest-IX
> http://www.midwest-ix.com
>
>

Re: If I announce 192.0.2.0/24, do I need a discard route? (Looking for a reference…)

[Tom Beecher]

>
>
> This sounded perfect, and I could beat my friend around the head with
> it… but reading further reveals:
> "Route aggregation and information reduction techniques (see
> Section 9.2.2.1) may optionally be applied.
>
>  Any local policy that results in routes being added to an Adj-RIB-Out
> without also being added to the local BGP speaker's forwarding table is
> outside the scope of this document."
>
>
I had to go into the weeds of the datatracker, but this thread discusses
the wording and meaning.

https://mailarchive.ietf.org/arch/msg/idr/JDPRPNUB0YhcZ5SqGHlg3jH8xGE/

Specifically this specific :
https://mailarchive.ietf.org/arch/msg/idr/1RglrwAgw5VIZSMxai-3fQRogzE/

The clause is saying 'A BGP route can validly be in Adj-RIB-Out, even if
it's not actually being used for forwarding.'  (Personally I think they
chose one of the clunkiest wordings suggested, but what do I know. :) )

FIB :
- Static route to D, next-hop FOO
- IGP route to BAR, next-hop BAZ
Loc-RIB : BGP route to D, next-hop BAR
Adj-RIB-Out : BGP route to D, next-hop BAR

The BGP route to D is permitted to be in Adj-RIB-Out because the
destination D AND next-hop BAR are both resolvable in the FIB. However, the
actual route *used* by the FIB is the static route to FOO because of admin
distance.




> I was initially excited by Tom's pointing at RFC4271, Sec 9.1.3, which
> states:
> "A route SHALL NOT be installed in the Adj-Rib-Out unless the
> destination, and NEXT_HOP described by this route, may be forwarded
> appropriately by the Routing Table."
>
> This sounded perfect, and I could beat my friend around the head with
> it… but reading further reveals:
> "Route aggregation and information reduction techniques (see
> Section 9.2.2.1) may optionally be applied.
>
>  Any local policy that results in routes being added to an Adj-RIB-Out
> without also being added to the local BGP speaker's forwarding table is
> outside the scope of this document."
>




On Thu, Feb 1, 2024 at 5:22 PM Warren Kumari  wrote:

>
>
>
>
> On Wed, Jan 31, 2024 at 5:56 PM, Owen DeLong  wrote:
>
>> On Jan 31, 2024, at 13:46, Warren Kumari  wrote:
>>
>>
>>
>>
>>
>> On Wed, Jan 31, 2024 at 3:56 PM, William Herrin  wrote:
>>
>>> On Wed, Jan 31, 2024 at 12:30 PM Warren Kumari 
>>> wrote:
>>>
>>> So, let's say I'm announcing some address space (e.g 192.0.2.0/24), but
>>> I'm only using part of it internally (e.g 192.0.2.0/25). I've always
>>> understood that it's best practice[0] to have a discard route (eg static to
>>> null0/discard or similar[1]) for what I'm announcing.
>>>
>>> Hi Warren,
>>>
>>> Your router won't announce 192.0.2.0/24 unless it knows a route to
>>> 192.0.2.0/24 or has been configured to aggregate any internal routes
>>> inside 192.0.2.0/24 to 192.0.2.0/24.
>>>
>>
>> It that always true? I'd started off thinking that, but a friend of mine
>> (yes, the same one that started this  argument) convinced me that
>> some forms of BGP summarization/aggregation don't always generate a "local"
>> route…
>>
>>
>> It’s not ALWAYS true. For example, aggregate-address commands and
>> equivalent on many platforms will cause the route to be announced if any
>> component prefixes are present in the RIB on some platforms.
>>
>> There are also some cases where “auto-summary” (does anyone actually use
>> this? EVER?) will have a similar effect.
>>
>> There are also some implementations where disabling synchronization or in
>> many cases where synchronization has simply been deprecated by the
>> implementor where any bap “network” statement (or equivalent) will result
>> in announcement regardless of what’s in the RIB.
>>
>> I'd also thought that I'd seen this when redistributing an IGP into BGP,
>> and using that as a contributor to 'aggregate-address' on Cisco devices.
>> This is from a long time ago, and really hazy now, but I'd thought that any
>> contributor would cause that the aggregate-address route to be announced,
>> and a local hold down not to be created.  It's possible that a: I'm just
>> wrong b: this is not longer true, c: both of the above.
>>
>>
>> Redistributing an IGP into BGP is almost always a bad idea. However, that
>> aside, yes, as mentioned above, exactly what you are saying here is true
>> with or without the redistribution on most platforms IIRC.
>>
>> a: you are not wrong
>> b: it’s still true on many platforms at least (though may be
>> implementation dependent)
>> c: no, but it’s certainly not best practice to behave in this way or
>> depend on either of these behaviors for the other original reason you
>> stated among other reasons.
>>
>> With BGP, you really want to have a deterministic clean definition of
>> what your router will do. As a general rule, if your peer is reachable, you
>> usually want to advertise your originated routes to them and make damn sure
>> your router can reach those some how no matter what.
>>
>
>
> Yah, agreed…. This seems "obvious", but is there actually anything that
> states this? I'm not really sure where 

Re: route: 0.0.0.0/32 in LEVEL3 IRR

[Tom Beecher]

Yes, absolutely. That's part of the technical risk that you take if you
decide to do such things.

If it's a "good" choice or not is entirely situational. Some organizations
are fine with kicking that tech debt down the road, others like to double
down and create a house of cards.

On Thu, Feb 1, 2024 at 2:21 AM Frank Habicht  wrote:

> On 01/02/2024 01:45, Tom Beecher wrote:
> > Seems a bit dramatic. Companies all over the world have been using other
> > people's public IPs internally for decades. I worked at a place 20 odd
> > years ago that had an odd numbering scheme internally, and it was
> > someone else's public space. When I asked why, the guy who built it said
> > "Well I just liked the pattern."
> >
> > If you're not announcing someone else's space into the DFZ, or
> > otherwise trying to do anything shady, the three letter agencies aren't
> > likely to come knocking. Doesn't mean anyone SHOULD be doing it, but
> still.
>
> Well...
>
> If you're using 20.20.20.0/24 which is not "yours" (as I've seen
> happen), then certainly your customers can't get to the real 20.20.20.x
> And even if that's not announced and used /today/ - this can change
> quickly...
>
> Frank
>

Re: route: 0.0.0.0/32 in LEVEL3 IRR

[Tom Beecher]

>
> Even though it is very risky to steal resources from an organization
> that can deploy a black helicopter or a nuclear warhead over you
>

Seems a bit dramatic. Companies all over the world have been using other
people's public IPs internally for decades. I worked at a place 20 odd
years ago that had an odd numbering scheme internally, and it was someone
else's public space. When I asked why, the guy who built it said "Well I
just liked the pattern."

If you're not announcing someone else's space into the DFZ, or
otherwise trying to do anything shady, the three letter agencies aren't
likely to come knocking. Doesn't mean anyone SHOULD be doing it, but
still.

On Wed, Jan 31, 2024 at 12:49 AM Rubens Kuhl  wrote:

> DoD's /8s are usually squatted by networks that run out of private IPv4
> space.
> Even though it is very risky to steal resources from an organization
> that can deploy a black helicopter or a nuclear warhead over you, for
> some reason like it not appearing in the DFZ people seem to like it.
>
>
> Rubens
>
> On Tue, Jan 30, 2024 at 11:40 PM Dave Taht  wrote:
> >
> > That's pretty cool, actually. I keep wondering when someone will offer
> > up a 0.0.0.0/8...
> >
> > https://www.ietf.org/archive/id/draft-schoen-intarea-unicast-0-00.html
> >
> > There must be more people out there than just amazon and google that
> > ran out of 10/8.
> >
> > On Tue, Jan 30, 2024 at 11:29 AM Frank Habicht 
> wrote:
> > >
> > > Hi,
> > >
> > > I got 2 bounces for the email addresses seen below for an email similar
> > > to the below...
> > >
> > > Anyone want to remove this IRR entry before anyone notices...???   ;-)
> > >
> > > Frank
> > >
> > >
> > > I believe that the entry of
> > > route:  0.0.0.0/32
> > >
> > > does not serve any good purpose?
> > >
> > > I was surprised to see it in a list of prefixes from bgpq4 and the very
> > > good https://irrexplorer.nlnog.net/prefix/0.0.0.0 guided me that it's
> in
> > > "Level3".
> > >
> > > I'm wondering how many auto-generated filters contain this unnecessary
> > > prefix
> > >
> > > PS: Oh, just seen - it's from TODAY. Maybe remove before anyone sees
> it...?
> > >
> > > Thanks for looking into this,
> > > Frank
> > >
> > >
> > > [frank@fisi ~]$ whois -h rr.level3.com 0.0.0.0/32
> > > [Querying rr.level3.com]
> > > [rr.level3.com]
> > > route:  0.0.0.0/32
> > > origin: AS10753
> > > mnt-by: TCCGlobalNV-MNT
> > > changed:ankita.gre...@lumen.com
> > > source: LEVEL3
> > > last-modified:  2024-01-30T11:04:49Z
> > >
> > >
> > > [frank@fisi ~]$ whois -h rr.level3.com TCCGlobalNV-MNT
> > > [Querying rr.level3.com]
> > > [rr.level3.com]
> > > mntner: TCCGlobalNV-MNT
> > > descr:  TCC Global N.V.
> > > auth:   CRYPT-PW DummyValue  # Filtered for security
> > > upd-to: ripehostmas...@eu.centurylink.net
> > > tech-c: LTHM
> > > admin-c:LTHM
> > > mnt-by: TCCGlobalNV-MNT
> > > changed:ankita.gre...@lumen.com
> > > source: LEVEL3
> > > last-modified:  2024-01-30T11:01:52Z
> > >
> >
> >
> > --
> > 40 years of net history, a couple songs:
> > https://www.youtube.com/watch?v=D9RGX6QFm5E
> > Dave Täht CSO, LibreQos
>

Re: SOVC - BGp RPKI

[Tom Beecher]

>
> I see it mentioned in this doc:
>
> https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/iproute_bgp/configuration/15-s/irg-15-s-book/irg-origin-as.pdf


You see SOVC mentioned, yes. But you don't see the word 'stale'.


Please don't just paste what ChatGPT says. It's not an authoritative
source.  I can find no Cisco document stating what the acronym MEANS. But
the context they use it seems to imply the word 'stale' isn't appropriate.


A prefix or prefix range and the origin-AS corresponding to it are
> considered an SOVC record. Overlapping prefix ranges are allowed. An SOVC
> table containing three records might look like this:



>  Valid—Indicates the prefix and AS pair are found in the SOVC table.


If more than one RPKI server is configured, the router will connect to all
> configured servers and download prefix information from all of them. The
> SOVC table will be made of the union of all the records received from the
> different servers.




>  In the following example, the router is configured to connect to two
> RPKI servers, from which it will receive SOVC records of BGP prefixes and
> AS numbers.


On Wed, Jan 31, 2024 at 3:34 PM Compton, Rich via NANOG 
wrote:

> ChatGPT says:
>
> SOVC in the context of RPKI (Resource Public Key Infrastructure) on a
> Cisco router stands for "Stale Origin Validation Cache". RPKI is a security
> framework designed to secure the Internet's routing infrastructure,
> primarily through route origin validation. It ensures that the Internet
> number resources (like IP addresses and AS numbers) are used by the
> legitimate owners or authorized AS (Autonomous System).
>
> In RPKI, Route Origin Authorizations (ROAs) are used to define which AS is
> authorized to announce a specific IP address block. Network devices, like
> Cisco routers, use these ROAs to validate the authenticity of BGP (Border
> Gateway Protocol) route announcements.
>
> The term "stale" in SOVC refers to a situation where the router's
> RPKI-to-Router protocol client has lost its connection to the RPKI server,
> or when the RPKI cache data is outdated and not refreshed for some reason.
> This can happen due to network issues, configuration errors, or problems
> with the RPKI server itself. When the RPKI cache is stale, the router
> cannot reliably validate BGP route announcements against the latest ROA
> data, potentially affecting routing decisions.
>
> In a network security context, maintaining an up-to-date RPKI cache is
> crucial for ensuring that the network only accepts legitimate routing
> announcements, thereby reducing the risk of routing hijacks or
> misconfigurations. As a network security engineer, managing and monitoring
> the RPKI status on routers is an important aspect of ensuring network
> security and integrity.
>
>
>
>
>
>
>
> I see it mentioned in this doc:
>
>
> https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/iproute_bgp/configuration/15-s/irg-15-s-book/irg-origin-as.pdf
>
>
>
>
>
> *From: *NANOG  on
> behalf of Mohammad Khalil 
> *Date: *Wednesday, January 31, 2024 at 10:35 AM
> *To: *NANOG list 
> *Subject: *SOVC - BGp RPKI
>
> Greetings Am have tried to find out what is the abbreviation for SOVC with
> no luck. #sh bgp ipv4 unicast rpki servers  BGP SOVC neighbor is X. X. X.
> 47/323 connected to port 323 Anyone have encountered this? Thanks! ‍ ‍ ‍ ‍
> ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍
>
> Greetings
>
> Am have tried to find out what is the abbreviation for SOVC with no luck.
>
>
>
> #sh bgp ipv4 unicast rpki servers
>
> BGP SOVC neighbor is X.X.X.47/323 connected to port 323
>
>
>
> Anyone have encountered this?
>
>
>
> Thanks!
>

Re: If I announce 192.0.2.0/24, do I need a discard route? (Looking for a reference…)

[Tom Beecher]

>
> It that always true? I'd started off thinking that, but a friend of mine
> (yes, the same one that started this  argument) convinced me that
> some forms of BGP summarization/aggregation don't always generate a "local"
> route…
>
> I'd also thought that I'd seen this when redistributing an IGP into BGP,
> and using that as a contributor to 'aggregate-address' on Cisco devices.
> This is from a long time ago, and really hazy now, but I'd thought that any
> contributor would cause that the aggregate-address route to be announced,
> and a local hold down not to be created.  It's possible that a: I'm just
> wrong b: this is not longer true, c: both of the above.
>

By spec, a route cannot be put into Adj-RIB-Out and announced to a peer
UNLESS that route exists in Loc-RIB, with a resolvable next-hop. ( RFC
4721, 9.1.3 . Your friend may need this :) )

It's certainly possible that a BGP implementation exists that violates this
rule, or hides the fact that it's doing this, but if it's standards
compliant this is what should be happening.

On Wed, Jan 31, 2024 at 4:47 PM Warren Kumari  wrote:

>
>
>
>
> On Wed, Jan 31, 2024 at 3:56 PM, William Herrin  wrote:
>
>> On Wed, Jan 31, 2024 at 12:30 PM Warren Kumari 
>> wrote:
>>
>> So, let's say I'm announcing some address space (e.g 192.0.2.0/24), but
>> I'm only using part of it internally (e.g 192.0.2.0/25). I've always
>> understood that it's best practice[0] to have a discard route (eg static to
>> null0/discard or similar[1]) for what I'm announcing.
>>
>> Hi Warren,
>>
>> Your router won't announce 192.0.2.0/24 unless it knows a route to
>> 192.0.2.0/24 or has been configured to aggregate any internal routes
>> inside 192.0.2.0/24 to 192.0.2.0/24.
>>
>
> It that always true? I'd started off thinking that, but a friend of mine
> (yes, the same one that started this  argument) convinced me that
> some forms of BGP summarization/aggregation don't always generate a "local"
> route…
>
> I'd also thought that I'd seen this when redistributing an IGP into BGP,
> and using that as a contributor to 'aggregate-address' on Cisco devices.
> This is from a long time ago, and really hazy now, but I'd thought that any
> contributor would cause that the aggregate-address route to be announced,
> and a local hold down not to be created.  It's possible that a: I'm just
> wrong b: this is not longer true, c: both of the above.
>
> There are also some more inventive ways of getting routes into BGP, like
> using ExaBGP as an example.
>
> W
>
>
>
> 192.0.2.0/25 doesn't count; it needs to know a route to 192.0.2.0/24.
>> Sending 192.0.2.0/24 to discard guarantees that the router has a route
>> to 192.0.2.0/24.
>>
>> Historically, folks would put 192.0.2.0/24 on the ethernet port. Then,
>> when carrier was lost on the ethernet port for a moment, the router would
>> no longer have a route to 192.0.2.0/24, so it'd withdraw the
>> announcement for 192.0.2.0/24. This is a bad idea for obvious reasons,
>> so best practice was to put a low priority route to discard as a fall-back
>> if the ethernet port briefly lost carrier.
>>
>> Regards,
>> Bill Herrin
>>
>> --
>> William Herrin
>> b...@herrin.us
>> https://bill.herrin.us/
>>
>
>

Re: Networks ignoring prepends?

[Tom Beecher]

>
> Unless overridden, BGP takes -distance- into account where distance =
> AS path length.
>

An AS_PATH length of 10 could be a physical distance of 1 mile.

An AS_PATH length of 1 could be a physical distance of 1000 miles.

BGP TE communities exist to provide signalling in the event that the
standards implemented by a provider don't align with the desires of an ASN.
They are certainly imperfect, but they are a very useful tool in the
toolbox that can solve problems exactly as you are experiencing.

If you chose not to even attempt to use them, for whatever your reasons may
be, I guess that's all there is to say at this point.


On Tue, Jan 23, 2024 at 5:29 PM William Herrin  wrote:

> On Tue, Jan 23, 2024 at 12:34 PM Niels Bakker 
> wrote:
> > BGP, while a distance vector protocol, famously does not take
> > latency into account when making routing decisions.
>
> Unless overridden, BGP takes -distance- into account where distance =
> AS path length.
>
> Centurylink has overridden that with a localpref so that it DOES NOT
> take distance into account. Which rather defeats the function of a
> distance vector protocol.
>
> Regards,
> Bill Herrin
>
>
> --
> William Herrin
> b...@herrin.us
> https://bill.herrin.us/
>

Re: Networks ignoring prepends?

[Tom Beecher]

>
> Because big operators think it reasonable to localpref distance routes
> ahead of nearby ones so long as the distant routes arrive from
> customers. I'll remember that the next time folks complain about the
> size of the routing table. This one you did to yourselves.
>

That has absolutely nothing to do with it, at all.

3356 is following common practice : Use customer routes before peer routes.
This is not some Illuminati based conspiracy , it's pretty standard stuff.
Nobody at 3356 is doing some magic latency based twerking to mess with you.
You kinda have a lousy upstream IMO.

It just so happens that their customer ( 47787 ) happens to takes a
*physical* pathway that is less performant than you'd prefer.

Two people ( myself and Andrew Hoyos ) went and looked , and found that the
upstream you use ( 53356 ) provides TE communities that you can use to
prevent your advertisement from being sent to 47787, thus avoiding that
poorly performing pathway, and hopefully using someone else better. Again,
for reference ( https://docs.freerangecloud.com/en/bgp/communities ).

You can:
1. Experiment with 53356's TE communities to prevent them from announcing
to upstreams that give you poor performance to 3356.
2. See if 47787 will talk to you about their path to 3356.  ( Doubtful,
since you aren't a direct customer of theirs.)
3. Pick an upstream that has better / more direct connectivity to 3356, use
them instead of /in parallel with 53356.
4. Get yourself connected to 3356 directly.
5. Keep yelling at the clouds about 3356 , even though they are doing the
same thing that (to the best of my knowledge) every large transit provider
does.


On Tue, Jan 23, 2024 at 3:02 PM William Herrin  wrote:

> On Tue, Jan 23, 2024 at 11:45 AM Owen DeLong via NANOG 
> wrote:
> > The catch to all of that, however, is that he’s not directly peered with
> 3356 and many AS operators strip communities.
>
> And even if I didn't, the problem isn't just one ISP localprefing to
> prefer distant routes. Centurylink most directly impacts me, but as
> others have pointed out: many ISPs do the same darn thing. The only
> workable solution available to me appears to be tripling my presence
> in the DFZ tables.
>
> Because big operators think it reasonable to localpref distance routes
> ahead of nearby ones so long as the distant routes arrive from
> customers. I'll remember that the next time folks complain about the
> size of the routing table. This one you did to yourselves.
>
> Regards,
> Bill
>
>
> --
> William Herrin
> b...@herrin.us
> https://bill.herrin.us/
>

Re: Networks ignoring prepends?

[Tom Beecher]

>
> Apparently there is a conflict between what you want and what 47787 wants.
> As you both seem to be paying customers, you should probably ask 3356 to
> resolve that instead of us random internet folks.
>

Calling 3356 and saying "I know your global routing policy is to prefer a
customer learned route over a peer route, but can you change that for me
please?" probably won't see much success.



On Tue, Jan 23, 2024 at 8:39 AM Alex Le Heux  wrote:

>
> >> Packets don't have customers, ISPs do. And in this case you're not a
> customer of the ISP making the routing decision
> >
> > Incorrect. I am a customer of 3356. A residential customer, not a BGP
> > customer. I'm paying them to route my packets too, and they're routing
> > them poorly.
>
> Oh, you should have said that right away, or perhaps I missed it.
>
> In that case it’s simple: Stop giving them money for bad service. By
> continuing to give them money you’re incentivizing them to continue
> breaking your internet, making you the architect of your own misery ;)
>
> > Also incorrect: every packet in your network is linked to either one
> > or two customers. Never more. Never less. Routing my packet via 47787
> > in this case serves neither of us: my Internet access is severely
> > degraded and 47787 is charged money for a packet they need not have
> > handled.
>
> Nonsense. 47787 is clearly telling 3356 they *want* to handle that traffic
> and even paying for the privilege. Apparently there is a conflict between
> what you want and what 47787 wants. As you both seem to be paying
> customers, you should probably ask 3356 to resolve that instead of us
> random internet folks.
>
> >> Fact is that all prepending does it provide a vague hint to other
> >> networks about what you would like them to do.
> >
> > Until they tamper with it using localpref, BGP's default behavior with
> > prepends does exactly the right thing, at least in my situation.
>
> Try giving your money to someone who runs BGP with just its default
> settings and no policies, see how well that works out.
>
> Cheers,
>
> Alex
>
>
> > Regards,
> > Bill Herrin
> >
> > --
> > William Herrin
> > b...@herrin.us
> > https://bill.herrin.us/
>

Re: Networks ignoring prepends?

[Tom Beecher]

>
> I feel your pain Bill, but from a slightly different angle.  For years the
> large CDNs have been disregarding prepends.  When a source AS disregards
> BGP best path selection rules, it sets off a chain reaction of silliness
> not attributable to the transit AS's.  At the terminus of that chain are
> destination / eyeball AS's now compelled to do undesirable things out of
> necessity such as:
>   1) Advertise specifics towards select peers - i.e. inconsistent edge
> routing policy & littering global table
>   2) Continuing to prepending a ridiculous amount anyway
> Gotta wonder how things would be if everyone just abided by the rules.
>

What 'rule' are you asserting is being broken here?



On Mon, Jan 22, 2024 at 9:56 PM Jeff Behrns via NANOG 
wrote:

> > > William Herrin  wrote:
> Until they tamper with it using localpref, BGP's default behavior with
> prepends does exactly the right thing, at least in my situation.
>
> I feel your pain Bill, but from a slightly different angle.  For years the
> large CDNs have been disregarding prepends.  When a source AS disregards
> BGP best path selection rules, it sets off a chain reaction of silliness
> not attributable to the transit AS's.  At the terminus of that chain are
> destination / eyeball AS's now compelled to do undesirable things out of
> necessity such as:
>   1) Advertise specifics towards select peers - i.e. inconsistent edge
> routing policy & littering global table
>   2) Continuing to prepending a ridiculous amount anyway
> Gotta wonder how things would be if everyone just abided by the rules.
>
>

Re: Networks ignoring prepends?

[Tom Beecher]

>
> As I already explained, neither the primary nor any of the backup
> providers directly peer with Centurylink, thus have no communities for
> controlling announcements to Centurylink.


No, but they do have an option to not announce to 47787.

https://docs.freerangecloud.com/en/bgp/communities

53356:19014 would deny to 47787 , which would seem to be the 'problematic'
intermediate ASN in your case, You could try that and see what other
upstream paths are taken , and see if that gets you over an upstream that
lines up more with your performance expectations.

Otherwise, you either have to deal with more specifics, or try to get
better connected to 3356 some other way.

3356 isn't doing anything wrong here, as much as you seem to want to
believe that to be true. This is all pretty standard customer / peer
preference handling.

On Mon, Jan 22, 2024 at 7:26 PM William Herrin  wrote:

> On Mon, Jan 22, 2024 at 4:16 PM Alex Le Heux  wrote:
> > > On Jan 23, 2024, at 00:43, William Herrin  wrote:
> > > Every packet has two customers: the one sending it and the one
> > > receiving it. 3356 is providing a service to its customers. ALL of its
> > > customers. Not just 47787. Sending the packet an extra 5,000 miles
> > > harms every one of 3356's customers -except for- 47787.
> > >
> > > In this case, I am the customer on both ends. 3356's choice to route
> > > my packet via 47787 serves me poorly.
> >
> > Packets don't have customers, ISPs do. And in this case you're not a
> customer of the ISP making the routing decision
>
> Incorrect. I am a customer of 3356. A residential customer, not a BGP
> customer. I'm paying them to route my packets too, and they're routing
> them poorly.
>
> Also incorrect: every packet in your network is linked to either one
> or two customers. Never more. Never less. Routing my packet via 47787
> in this case serves neither of us: my Internet access is severely
> degraded and 47787 is charged money for a packet they need not have
> handled.
>
> Charging your customers to make their service worse doesn't seem like
> a good business model to me, but maybe that's why I'm not a CEO.
>
>
> > Fact is that all prepending does it provide a vague hint to other
> > networks about what you would like them to do.
>
> Until they tamper with it using localpref, BGP's default behavior with
> prepends does exactly the right thing, at least in my situation.
>
> Regards,
> Bill Herrin
>
> --
> William Herrin
> b...@herrin.us
> https://bill.herrin.us/
>

Re: Networks ignoring prepends?

[Tom Beecher]

>
> I’d bet that 47787 is a paying century link customer. As such, despite the
> ugliness of the path, CL probably local prefs everything advertised by them
> higher than any non-paying link. I’m willing to bet 1299 is peered and not
> paying CL.
>

It's almost as if you've done this before. :)

Community : 3356:3 3356:22 3356:100 ==> 3356:123 <++ 3356:575
3356:903 3356:2011 3356:11918 47787:1020
47787:3090 47787:3690 47787:3
Cluster : 0.0.7.15 0.0.7.19
Originator Id : 4.69.181.14 Peer Router Id : 4.69.130.10
Fwd Class : None Priority : None
Flags : Used Valid Best IGP Group-Best
Route Source : Internal
AS-Path : 47787 47787 47787 47787 53356 11875 11875 11875

3356:123 = Customer


On Mon, Jan 22, 2024 at 5:45 PM Owen DeLong via NANOG 
wrote:

> I’d bet that 47787 is a paying century link customer. As such, despite the
> ugliness of the path, CL probably local prefs everything advertised by them
> higher than any non-paying link. I’m willing to bet 1299 is peered and not
> paying CL.
>
> Sending bits for revenue is almost always preferable to sending bits for
> free, so…
>
> Owen
>
>
> > On Jan 22, 2024, at 12:37, William Herrin  wrote:
> >
> > On Mon, Jan 22, 2024 at 10:19 AM James Jun 
> wrote:
> >> So, as a customer, you actually SHOULD be demanding your ISPs
> >> to positively identify and categorize their routes using local-pref
> >> and communities.
> >
> > Hi James,
> >
> > The best path to me from Centurylink is: 3356 1299 20473 11875
> >
> > The path Centurylink chose is: 3356 47787 47787 47787 47787 53356
> > 11875 11875 11875
> >
> > Do you want to tell me again how that's a reasonable path selection,
> > or how I'm supposed to pass communities to either 20473 or 53356 which
> > tell 3356 to behave itself?
> >
> > Regards,
> > Bill Herrin
> >
> >
> > --
> > William Herrin
> > b...@herrin.us
> > https://bill.herrin.us/
>
>

Re: "Hypothetical" Datacenter Overheating

[Tom Beecher]

>
> t's certainly one of many possible root causes which someone doing an
> AAR on an event like this should be thinking about, and looking for in
> their
> evaluation of the data they see.
>

And I'm sure they are and will.

By the time that post was made, the vendor had shared multiple updates
about what the actual cause seemed to be, which were very plausible. An
unaffiliated 3rd party stating 'maybe an attack!' when there has been no
observation or information shared that even remotely points to that simply
spreads FUD for no reason.

I respectfully disagree.



On Sun, Jan 21, 2024 at 1:22 AM Jay R. Ashworth  wrote:

> ----- Original Message -
> > From: "Tom Beecher" 
> > To: "Lamar Owen" 
> > Cc: nanog@nanog.org
> > Sent: Wednesday, January 17, 2024 8:06:07 PM
> > Subject: Re: "Hypothetical" Datacenter Overheating
>
> >> If these chillers are connected to BACnet or similar network, then I
> >> wouldn't rule out the possibility of an attack.
> >
> > Don't insinuate something like this without evidence. Completely
> > unreasonable and inappropriate.
>
> WADR, horsecrap.
>
> It's certainly one of many possible root causes which someone doing an
> AAR on an event like this should be thinking about, and looking for in
> their
> evaluation of the data they see.
>
> He didn't *accuse* anyone, which would be out of bounds.
>
> Cheers,
> -- jra
> --
> Jay R. Ashworth  Baylink
> j...@baylink.com
> Designer The Things I Think   RFC
> 2100
> Ashworth & Associates   http://www.bcp38.info  2000 Land
> Rover DII
> St Petersburg FL USA  BCP38: Ask For It By Name!   +1 727 647
> 1274
>

Re: Stealthy Overlay Network Re: 202401100645.AYC Re: IPv4 address block

[Tom Beecher]

>
> Because people keep responding.
>

Doesn't really make any difference. Mr. Chen filed his first draft in Dec
2016.  He finds a reason to talk about it on every mailing list and forum
he can find, but doesn't spend any time engaging in the standards
processes, other than renewing his draft every 6 months.

I do agree it's better to just block him and ignore. He's still not going
to stop though.



On Sat, Jan 20, 2024 at 12:51 PM Chris Adams  wrote:

> Once upon a time, sro...@ronan-online.com  said:
> > I am curious if anyone has ever given you positive feedback on this
> idea? So far
> > all I’ve seen is the entire community thinking it’s a bad idea. Why do
> you
> > insist this is a good solution?
>
> Because people keep responding.
> --
> Chris Adams 
>

Re: "Hypothetical" Datacenter Overheating

[Tom Beecher]

>
> Well right, which came well after the question was posited here.


Wasn't poo pooing the question, just sharing the information as I didn't
see that cited otherwise in this thread.

On Thu, Jan 18, 2024 at 10:15 AM Mike Hammett  wrote:

> Well right, which came well after the question was posited here.
>
>
>
> -
> 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: *sro...@ronan-online.com, "NANOG" 
> *Sent: *Thursday, January 18, 2024 9:00:34 AM
> *Subject: *Re: "Hypothetical" Datacenter Overheating
>
> and none in the other two facilities you operate in that same building had
>> any failures.
>
>
> Quoting directly from their outage ticket updates :
>
> CH2 does not have chillers, cooling arrangement is DX CRACs manufactured
>> by another company. CH3 has Smart chillers but are water cooled not air
>> cooled so not susceptible to cold ambient air temps as they are indoor
>> chillers.
>
>
>
>
> On Mon, Jan 15, 2024 at 10:19 AM Mike Hammett  wrote:
>
>> and none in the other two facilities you operate in that same building
>> had any failures.
>>
>>
>>
>> -
>> 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: *sro...@ronan-online.com
>> *To: *"Mike Hammett" 
>> *Cc: *"NANOG" 
>> *Sent: *Monday, January 15, 2024 9:14:49 AM
>> *Subject: *Re: "Hypothetical" Datacenter Overheating
>>
>> I’m more interested in how you lose six chillers all at once.
>>
>> Shane
>>
>> On Jan 15, 2024, at 9:11 AM, Mike Hammett  wrote:
>>
>> 
>> Let's say that hypothetically, a datacenter you're in had a cooling
>> failure and escalated to an average of 120 degrees before mitigations
>> started having an effect. What are normal QA procedures on your behalf?
>> What is the facility likely to be doing? What  should be expected in the
>> aftermath?
>>
>>
>>
>> -
>> 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>
>>
>>
>>
>

Re: "Hypothetical" Datacenter Overheating

[Tom Beecher]

>
> and none in the other two facilities you operate in that same building had
> any failures.


Quoting directly from their outage ticket updates :

CH2 does not have chillers, cooling arrangement is DX CRACs manufactured by
> another company. CH3 has Smart chillers but are water cooled not air cooled
> so not susceptible to cold ambient air temps as they are indoor chillers.




On Mon, Jan 15, 2024 at 10:19 AM Mike Hammett  wrote:

> and none in the other two facilities you operate in that same building had
> any failures.
>
>
>
> -
> Mike Hammett
> Intelligent Computing Solutions 
> 
> 
> 
> 
> Midwest Internet Exchange 
> 
> 
> 
> The Brothers WISP 
> 
> 
> --
> *From: *sro...@ronan-online.com
> *To: *"Mike Hammett" 
> *Cc: *"NANOG" 
> *Sent: *Monday, January 15, 2024 9:14:49 AM
> *Subject: *Re: "Hypothetical" Datacenter Overheating
>
> I’m more interested in how you lose six chillers all at once.
>
> Shane
>
> On Jan 15, 2024, at 9:11 AM, Mike Hammett  wrote:
>
> 
> Let's say that hypothetically, a datacenter you're in had a cooling
> failure and escalated to an average of 120 degrees before mitigations
> started having an effect. What are normal QA procedures on your behalf?
> What is the facility likely to be doing? What  should be expected in the
> aftermath?
>
>
>
> -
> Mike Hammett
> Intelligent Computing Solutions 
> 
> 
> 
> 
> Midwest Internet Exchange 
> 
> 
> 
> The Brothers WISP 
> 
> 
>
>
>

Re: Shared cache servers on an island's IXP

[Tom Beecher]

Many CDNs have hardware options for self hosted caches. I think there would
likely be concerns about <20G of connectivity to those caches though. With
an incorrect setup, you could end up maxing out those links just with cache
fill traffic itself.


On Thu, Jan 18, 2024 at 6:54 AM Jérôme Nicolle  wrote:

> Hello,
>
> I'm trying to find out the best way to consolidate connectivity on an
> island.
>
> The current issues are :
> - Low redundancy of old cables (2)
> - Low system capacity of said cables (<=20Gbps)
> - Total service loss when both cables are down because of congestion on
> satelite backups
> - Sheer price of bandwidth
>
> On the plus side, there are over 5 AS on the island, an IXP and
> small-ish collocation capacity (approx 10kW available, could be
> upgraded, second site available later this year).
>
> We'd like to host cache servers and/or VMs on the IXP, with an option to
> anycast many services - without hijacking them, that goes without saying
> - such as quad-whatever DNS resolvers, NTP servers and whatever else
> could be useful for weather-induced disaster-recovery and/or offload
> cables.
>
> Do you think most CDNs, stream services and CSPs could accommodate a
> scenario where we'd host their gear or provide VMs for them to announce
> on the local route-servers ? If not, what could be a reasonable
> technical arrangement ?
>
> Thanks !
>
> --
> Jérôme Nicolle
> +33 6 19 31 27 14
>

Re: "Hypothetical" Datacenter Overheating

[Tom Beecher]

>
> If these chillers are connected to BACnet or similar network, then I
> wouldn't rule out the possibility of an attack.
>

Don't insinuate something like this without evidence. Completely
unreasonable and inappropriate.

On Wed, Jan 17, 2024 at 8:31 AM Lamar Owen  wrote:

> >This sort of mass failure seems to point
> >towards either design issues (like equipment >selection/configuration vs
> >temperature range for the location), systemic maintenance issues, or
> >some sort of single failure point that could take all the chillers out,
> >none of which I'd be happy to see in a data center.
>
>
>
> If these chillers are connected to BACnet or similar network, then I
> wouldn't rule out the possibility of an attack.
>

Re: Any clue as to when bgp.he.net will be back?

[Tom Beecher]

It only applies if you are purchasing their monitoring services. Not just
to use the site for info.

On Tue, Jan 16, 2024 at 5:04 PM scott via NANOG  wrote:

>
>
> On 1/16/24 2:44 PM, Ian Chilton wrote:
>
> > Not a direct answer to your question, but if you're not aware of it,
> > https://bgp.tools/  is a great tool and shows the
> > same info.
> --
>
> They need to fix their page regarding cost.
>
> Originates less than a /15 - 25 pounds/month
>
> Originates more than a /15 - 200 pounds/month.
>
> What if someone originates a /15?  That's one of the prefix sizes we
> originate.  They need a 'less than or equal to' thingie in there.
>
> scott
>

Re: Stealthy Overlay Network Re: 202401100645.AYC Re: IPv4 address block

[Tom Beecher]

>
> If "EzIP" is about using 240/4 as CGNAT space, let's call it what it is,
> not rename something that already exists and attempt to claim it as a new
> idea.
>

Yes he is essentially re-creating NAT/CGNAT, but in a worse way.

If you ignore all the multitude of technical issues, if you grabbed an
"EZIP packet" in flight from the DFZ, you would STILL see SRC and DST as
normal IPv4 addresses, just with extra stuff in the options field.
Translations still happen at what he calls 'SPRs' , just differently.


On Mon, Jan 15, 2024 at 6:35 PM Christopher Hawker 
wrote:

> If "EzIP" is about using 240/4 as CGNAT space, let's call it what it is,
> not rename something that already exists and attempt to claim it as a new
> idea.
>
> It is completely unnecessary to use 240/4 as CGNAT space. Here are a few
> reasons why:
>
>1. There are 4,194,304 IPv4 addresses in a /10 prefix. Allowing for a
>/24 from this to be used for CGNAT gateways, load balancing, etc. this
>still allows for 4,194,048 usable addresses for CPE. When performing NAT,
>you would need to allocate each subscriber approximately 1000 ports for NAT
>to work successfully. The entire /10 (less the /24) would require the
>equivalent of a /16 public IPv4 prefix to use the entire 100.64/10 space in
>one region. To put this into comparison, you would use the entire 100.64/10
>space in a city the size of New York or Los Angeles allowing for one
>internet service per 4 or 2 people respectively. It's not practical.
>2. Multiple CGNAT regions that are at capacity would not have a need
>for uniquely routable IP space between them. It's heavily designed for
>traffic from the user to the wider internet, not for inter-region routing.
>Carriers already have systems in place where subscribers can request a
>public address if they need it (such as working from home with advanced
>corporate networks, etc).
>
> 100.64/10 is not public IP space, because it is not usable in the DFZ. I
> don't believe there is any confusion or ambiguity about this space because
> if you do a Whois lookup on 100.64.0.0/10 at any one of the five RIRs, it
> reflects that it is IANA shared address space for service providers.
> Footnote 6 on the page you referenced reads "100.64.0.0/10 reserved for
> Shared Address Space". It has not been delegated to ARIN. Rather clear as
> to its use case.
>
> I don't think you quite grasp the concept that OpenWRT is not compatible
> with devices that do not support it. It would only work on routers for
> which it is compatible and it would not be appropriate to expect every
> device vendor to support it. To add-on to this, why would vendors need to
> enable 240/4 CGNAT support when their customers don't have a need for it?
>
> You've provided a link to a D-Link managed switch, not a router. Just
> because it can support L2 routing, doesn't make it a router.
>
> I'm all for discussing ideas and suggestions and working towards proper
> IPv6 deployment. It certainly appears to be the case that the community
> does not support your proposed "EzIP" solution. If you are recommending
> that 240/4 space be used for CGNAT space under RFC6598, then call it as it
> is instead of inventing new terminology.
>
> Regards,
> Christopher Hawker
>
> On Tue, 16 Jan 2024 at 03:27, Abraham Y. Chen  wrote:
>
>> Hi, Christopher:
>>
>> 1)" Hang on... So EzIP is now about using 240/4 as CGNAT space? Wait,
>> I'm lost...   ":
>>
>> Correct. This is one way to visualize the EzIP deployment. This
>> configuration is so far the most concise manner to describe the the EzIP
>> building block, RAN (Regional Area Network). The nice thing about this
>> approach is that everything exists and is already working daily in each
>> CG-NAT cluster. All needed to expand its capability is a larger netblock.
>> Since 240/4 is fundamentally not an outlier in the overall IPv4 address
>> pool, except being classified as "Reserved" for a long time, enabling it to
>> work in a CG-NAT should not be any big challenge.
>> 2)"   ... There is no such thing as "semi-private" space in the world
>> of CGNAT, ... ":
>>
>> Correct. However, not distinguishing 100.64/10 netblock from the
>> common public and private parts of the IPv4 space made it vague as which
>> function does it provide. That is, in terms of re-usability for each
>> isolated geographical area, it is like another RFC1918 private netblock. On
>> the other hand, CG-NAT is clearly used in geographically public areas. So,
>> 100.64/10 should be classified as "public". In addition, 100.64/10 is
>> listed according to "IANA IPv4 Address Space Registry" as part of the 100/8
>> netblock under ARIN, but now used by everyone worldwide. To avoid similar
>> ambiguity that leads to confusions, we decided to call 240/4 as
>> "semi-public" to more explicitly convey the concept. (Actually, we
>> initially called 240/4 "semi-private" thinking that it could be the fourth
>> RFC1918 netblock

Re: How threading works (was Re: Root Cause Re: 202401102221.AYC Re: Streamline The CG-NAT Re: 202401100645.AYC Re: IPv4 address block)

[Tom Beecher]

>
> Gmail is therefore in violation of the RFC5822.  It's quite clear how it
> should work per the RFC appendix.
>

Well, no. Asterisks added for emphasis.

 This specification is intended as a definition of what message
>content format is to be passed between systems.  Though some message
>systems locally store messages in this format (which eliminates the
>need for translation between formats) and others use formats that
>differ from the one specified in this specification, local storage is
>outside of the scope of this specification.
>
>   Note: This specification is not intended to dictate the internal
>   formats used by sites, the specific message system features that
>   they are expected to support, *** or any of the characteristics of
>   user interface programs that create or read messages. ***  In
>   addition, this document does not specify an encoding of the
>   characters for either transport or storage; that is, it does not
>   specify the number of bits used or how those bits are specifically
>   transferred over the wire or stored on disk.
>
> 5822 defines the structure and syntax of the data. Not how mail agents
should work with it.



On Sun, Jan 14, 2024 at 3:55 AM Bryan Fields  wrote:

> On 1/14/24 1:01 AM, William Herrin wrote:
> > Respectfully, your MUA is not the only MUA. Others work differently.
>
> Bill, I use multiple MUA's, among them Thunderbird, mutt, kmail and even
> the
> zimbra web interface.  All follow and implement RFC5822 as it pertains to
> threading.
>
> Note, threading works fine in the list archives too, but only displays two
> levels deep.
>
> > GMail, for example, follows the message IDs as you say but assumes
> > that if you change the subject line in your reply (more than adding
> > "Re:") then you intend to start a new thread from that point in the
> > discussion. It groups messages accordingly.
>
> Gmail is therefore in violation of the RFC5822.  It's quite clear how it
> should work per the RFC appendix.
>
> > This is not an unreasonable expectation: if you merely want to
> > continue the current conversation without going off on a new tangent
> > then there's no need for a different subject line.
>
> I think it's quite unreasonable to expect others to compensate for an MUA
> which doesn't implement 25+ year old standards properly.
> --
> Bryan Fields
>
> 727-409-1194 - Voice
> http://bryanfields.net
>

Re: Vint Cerf Re: Backward Compatibility Re: IPv4 address block

[Tom Beecher]

gt; sounds like *eZIP* is basically an *overlay* network.
>
>  *v*
>
>  On Mon, Oct 18, 2021 at 8:33 AM Abraham Y. Chen via InternetPolicy <
> internetpol...@elists.isoc.org> wrote:
>
> Hi, Scott:
>
>  0)Thanks for your research.
>
>  1)Both SCION (based on my best understanding) and our work named EzIP
> (phonetic for Easy IPv4) are technical solutions for improving the Internet
> from its foundation level (the architecture). There are many implications
> with such schemes including social and legal if one looks into them.
>
>  2)As I responded to Gene's questions (See my eMail with subject line
> tag: "202110171756.AYC"), the SCION approach implements certain
> restrictions ..
>
> 
>
> 2)Prior to the above, we were quite unsure about what our team was
> doing. So, I purposely avoided having any contact with Vint. We had been
> describing the EzIP's RANs (Regional Area Networks) as "kites floating in
> the air over an geographic area anchored by an IPv4 address based cord".
> Although visually clear, it was too wordy. By using one concise word,
> *overlay*, Vint eloquently classified the EzIP network in terminology
> sense. It opened our eyes about what were the implications of EzIP and what
> could be the interactions with respect to the existing Internet, because
> EzIP was a non-interfering enhancement to an existing system which was a
> text book case of systems engineering.
>
> Hope the above clears the air.
>
>
> Regards,
>
>
> Abe (2024-01-13 07:34)
>
>
> On 2024-01-12 19:24, Tom Beecher wrote:
>
> I go into my cave to finish the todo list for the week, and I come out to
> see Mr. Chen :
> - Telling Randy Bush he should "read some history" on IPv6
> - Implying that Vint Cerf ever said anything about EzIP
>
> Fairly impressive sequence of self ownage.
>
> On Fri, Jan 12, 2024 at 5:46 PM Randy Bush  wrote:
>
>
>
>
> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient>
> Virus-free.www.avast.com
> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient>
> <#m_9068981657915465318_m_898116838406432442_m_-7063806684299367540_m_-462970855676450446_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>

Re: Stealthy Overlay Network Re: 202401100645.AYC Re: IPv4 address block

[Tom Beecher]

Fair enough, I misunderstood your question.

I still think it's basically not knowable.

On Fri, Jan 12, 2024 at 3:16 PM Mike Hammett  wrote:

> I'm not talking about global, public use, only private use.
>
>
>
> -
> 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: *"Ryan Hamel" , "Abraham Y. Chen" <
> ayc...@alum.mit.edu>, nanog@nanog.org
> *Sent: *Friday, January 12, 2024 2:06:32 PM
> *Subject: *Re: Stealthy Overlay Network Re: 202401100645.AYC Re: IPv4
> address block
>
> You don't need everything in the world to support it, just the things
>> "you" use.
>
>
> You run an ISP, let me posit something.
>
> Stipulate your entire network infra, services, and applications support
> 240/4, and that it's approved for global , public use tomorrow. Some
> company gets a block in there, stands up some website. Here are some
> absolutely plausible scenarios that you might have to deal with.
>
> - Some of your customers are running operating systems / network gear that
> doesn't support 240/4.
> - Some of your customers may be using 3rd party DNS resolvers that don't
> support 240/4.
> - Some network in between you and the dest missed a few bogon ACLs ,
> dropping your customer's traffic.
>
> All of this becomes support issues you have to deal with.
>
> On Fri, Jan 12, 2024 at 2:21 PM Mike Hammett  wrote:
>
>> I wouldn't say it's unknowable, just that no one with a sufficient enough
>> interest in the cause has been loud enough with the research they've done,
>> assuming some research has been done..
>>
>> You don't need everything in the world to support it, just the things
>> "you" use.
>>
>>
>>
>> -
>> 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: *"Ryan Hamel" , "Abraham Y. Chen" <
>> ayc...@alum.mit.edu>, nanog@nanog.org
>> *Sent: *Friday, January 12, 2024 1:16:53 PM
>> *Subject: *Re: Stealthy Overlay Network Re: 202401100645.AYC Re: IPv4
>> address block
>>
>> How far are we from that, in reality? I don't have any intention on using
>>> the space, but I would like to put some definition to this boogey man.
>>
>>
>> It's unknowable really.
>>
>> Lots of network software works just fine today with it. Some don't. To my
>> knowledge some NOS vendors have outright refused to support 240/4 unless
>> it's reclassified. Beyond network equipment, there is an unknowable number
>> of software packages , drivers, etc out in the world which 240/4 is still
>> hardcoded not to work. It's been unfortunate to see this fact handwaved
>> away in many discussions on the subject.
>>
>> The Mirai worm surfaced in 2016. The software vulnerabilities used in its
>> attack vectors are still unpatched and present in massive numbers
>> across the internet; there are countless variants that still use the same
>> methods, 8 years later. Other vulnerabilities still exist after
>> multiple decades. But we somehow think devices will be pa

Re: Backward Compatibility Re: 202401100645.AYC Re: IPv4 address block

[Tom Beecher]

I go into my cave to finish the todo list for the week, and I come out to
see Mr. Chen :
- Telling Randy Bush he should "read some history" on IPv6
- Implying that Vint Cerf ever said anything about EzIP

Fairly impressive sequence of self ownage.

On Fri, Jan 12, 2024 at 5:46 PM Randy Bush  wrote:

> > Perhaps you are too young to realize that the original IPv6 plan was
> > not designed to be backward compatible to IPv4, and Dual-Stack was
> > developed (through some iterations) to bridge the transition between
> > IPv4 and IPv6? You may want to spend a few moments to read some
> > history on this.
>
> ROFL!!!  if there is anything you can do to make me that young, you
> could have a very lucrative career outside of the internet.
>
> hint: unfortunately i already had grey hair in the '90s and was in the
> room for all this, and spent a few decades managing to get some of the
> worst stupidities (TLA, NLA, ...) pulled out of the spec.  at iij, we
> rolled ipv6 on the backbone in 1997.
>
> randy
>

Re: Stealthy Overlay Network Re: 202401100645.AYC Re: IPv4 address block

[Tom Beecher]

>
> You don't need everything in the world to support it, just the things
> "you" use.


You run an ISP, let me posit something.

Stipulate your entire network infra, services, and applications support
240/4, and that it's approved for global , public use tomorrow. Some
company gets a block in there, stands up some website. Here are some
absolutely plausible scenarios that you might have to deal with.

- Some of your customers are running operating systems / network gear that
doesn't support 240/4.
- Some of your customers may be using 3rd party DNS resolvers that don't
support 240/4.
- Some network in between you and the dest missed a few bogon ACLs ,
dropping your customer's traffic.

All of this becomes support issues you have to deal with.

On Fri, Jan 12, 2024 at 2:21 PM Mike Hammett  wrote:

> I wouldn't say it's unknowable, just that no one with a sufficient enough
> interest in the cause has been loud enough with the research they've done,
> assuming some research has been done..
>
> You don't need everything in the world to support it, just the things
> "you" use.
>
>
>
> -
> 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: *"Ryan Hamel" , "Abraham Y. Chen" <
> ayc...@alum.mit.edu>, nanog@nanog.org
> *Sent: *Friday, January 12, 2024 1:16:53 PM
> *Subject: *Re: Stealthy Overlay Network Re: 202401100645.AYC Re: IPv4
> address block
>
> How far are we from that, in reality? I don't have any intention on using
>> the space, but I would like to put some definition to this boogey man.
>
>
> It's unknowable really.
>
> Lots of network software works just fine today with it. Some don't. To my
> knowledge some NOS vendors have outright refused to support 240/4 unless
> it's reclassified. Beyond network equipment, there is an unknowable number
> of software packages , drivers, etc out in the world which 240/4 is still
> hardcoded not to work. It's been unfortunate to see this fact handwaved
> away in many discussions on the subject.
>
> The Mirai worm surfaced in 2016. The software vulnerabilities used in its
> attack vectors are still unpatched and present in massive numbers
> across the internet; there are countless variants that still use the same
> methods, 8 years later. Other vulnerabilities still exist after
> multiple decades. But we somehow think devices will be patched to support
> 240/4 quickly?
>
> It's just unrealistic.
>
> On Fri, Jan 12, 2024 at 1:03 PM Mike Hammett  wrote:
>
>> " every networking vendor, hardware vendor, and OS vendor"
>>
>> How far are we from that, in reality? I don't have any intention on using
>> the space, but I would like to put some definition to this boogey man.
>>
>>
>>
>> -
>> 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: *"Ryan Hamel" 
>> *To: *"Abraham Y. Chen" , "Vasilenko Eduard" <
>> vasilenko.edu...@huawei.com>
>> *Cc: *"Abraham Y. Chen" , nanog@nanog.org
>> *Sent: *Thursday, January 11, 2024 11:04:31 PM
>> *Subject: *Re: Stealthy Overlay Network Re: 202401100645.AYC Re: IPv4
>> address block
&

Re: Stealthy Overlay Network Re: 202401100645.AYC Re: IPv4 address block

[Tom Beecher]

>
> How far are we from that, in reality? I don't have any intention on using
> the space, but I would like to put some definition to this boogey man.


It's unknowable really.

Lots of network software works just fine today with it. Some don't. To my
knowledge some NOS vendors have outright refused to support 240/4 unless
it's reclassified. Beyond network equipment, there is an unknowable number
of software packages , drivers, etc out in the world which 240/4 is still
hardcoded not to work. It's been unfortunate to see this fact handwaved
away in many discussions on the subject.

The Mirai worm surfaced in 2016. The software vulnerabilities used in its
attack vectors are still unpatched and present in massive numbers
across the internet; there are countless variants that still use the same
methods, 8 years later. Other vulnerabilities still exist after
multiple decades. But we somehow think devices will be patched to support
240/4 quickly?

It's just unrealistic.

On Fri, Jan 12, 2024 at 1:03 PM Mike Hammett  wrote:

> " every networking vendor, hardware vendor, and OS vendor"
>
> How far are we from that, in reality? I don't have any intention on using
> the space, but I would like to put some definition to this boogey man.
>
>
>
> -
> Mike Hammett
> Intelligent Computing Solutions 
> 
> 
> 
> 
> Midwest Internet Exchange 
> 
> 
> 
> The Brothers WISP 
> 
> 
> --
> *From: *"Ryan Hamel" 
> *To: *"Abraham Y. Chen" , "Vasilenko Eduard" <
> vasilenko.edu...@huawei.com>
> *Cc: *"Abraham Y. Chen" , nanog@nanog.org
> *Sent: *Thursday, January 11, 2024 11:04:31 PM
> *Subject: *Re: Stealthy Overlay Network Re: 202401100645.AYC Re: IPv4
> address block
>
> Abraham,
>
> You may not need permission from the IETF, but you effectively need it
> from every networking vendor, hardware vendor, and OS vendor. If you do not
> have buy in from key stakeholders, it's dead-on arrival.
>
> Ryan
> --
> *From:* NANOG  on behalf of
> Abraham Y. Chen 
> *Sent:* Thursday, January 11, 2024 6:38:52 PM
> *To:* Vasilenko Eduard 
> *Cc:* Chen, Abraham Y. ; nanog@nanog.org <
> nanog@nanog.org>
> *Subject:* Stealthy Overlay Network Re: 202401100645.AYC Re: IPv4 address
> block
>
> Caution: This is an external email and may be malicious. Please take care
> when clicking links or opening attachments.
>
> Hi, Vasilenko:
>
> 1)... These “multi-national conglo” has enough influence on the IETF
> to not permit it.":
>
> As classified by Vint Cerf, 240/4 enabled EzIP is an overlay network
> that may be deployed stealthily (just like the events reported by the
> RIPE-LAB). So, EzIP deployment does not need permission from the IETF.
>
> Regards,
>
>
> Abe (2024-01-11 21:38 EST)
>
>
>
>
> On 2024-01-11 01:17, Vasilenko Eduard wrote:
>
> > It has been known that multi-national conglomerates have been using it
> without announcement.
>
> This is an assurance that 240/4 would never be permitted for Public
> Internet. These “multi-national conglo” has enough influence on the IETF
> to not permit it.
>
> Ed/
>
> *From:* NANOG [mailto:nanog-bounces+vasilenko.eduard=huawei@nanog.org
> ] *On Behalf Of *Abraham
> Y. Chen
> *Sent:* Wednesday, January 10, 2024 3:35 PM
> *To:* KARIM MEKKAOUI  
> *Cc:* nanog@nanog.org; Chen, Abraham Y. 
> 
> *Subject:* 202401100645.AYC Re: IPv4 address block
> *Importance:* High
>
>
>
> Hi, Karim:
>
>
>
> 1)If you have control of your own equipment (I presume that your
> business includes IAP - Internet Access Provider, since you are asking to
> buy IPv4 blocks.), you can get a large block of reserved IPv4 address *for
> free* by *disabling* the program codes in your current facility that has
> been *disabling* the use of 240/4 netblock. Please have a look at the
> below whitepaper. Utilized according to the outlined disciplines, this is a
> practically unlimited resources. It has been known that multi-national
> conglomerates have been using it without announcement. So, you can do so
> stealthily according to the proposed mechanism which establishes uniform
> practices, just as well.
>
>
>
> https://www.avinta.com/phoenix-1/home/RevampTheInternet.pdf
>
>
>
> 2)Being an unorthodox solution, if not controversial, please follow up
> with me offline. Unless, other NANOGers express their interests.
>
>
>
>
>
> Regards,
>
>
>
>
>
> Abe (2024-01-10 07:34 EST)
>
>
>
>
>
>
>
> On 2024-01-07 22:46, KARIM MEKKAOUI wrote:
>
> Hi Nanog Community
>
>
>
> Any idea please 

Re: Burn Rate? Re: 202401100645.AYC Re: IPv4 address block

[Tom Beecher]

>
> EzIP proposes


EzIP is a concept that has zero interest in the field , aside from Mr. Chen
himself. It's been discussed and analysed. Legitimate issues have been
raised, and Mr. Chen simply handwaves them away.

The only IETF actions on it has been Mr. Chen refreshing the draft every 6
months.

There's really no point in talking about what it is , or what it wants to
do, when it has the same force and effect as the legendary IPv10 draft, and
April Fools RFCs.

On Fri, Jan 12, 2024 at 7:08 AM Abraham Y. Chen  wrote:

> Hi, Owen:
>
> 1)"... it seemed the 240/4 lasting a year was an optimistic count.   ":
>
> EzIP proposes that 240/4 be used like 10.64/10 in CG-NAT. which is
> reusable for each isolated geographical area. Thus, there is no "Burn-rate"
> to talk about.
>
> Regards,
>
>
> Abe (2024-01-12 07:07)
>
>
> On 2024-01-11 19:10, Owen DeLong wrote:
>
> At the time this was being considered, ARIN, APNIC, and RIPE NCC were each
> burning approximately 6 /8s per year. 240/4 is 16x/8, so with an RIR burn
> rate of 18 /8s per year (not counting LACNIC and AFRINIC which each
> accounted for <1 per year IIRC), it seemed the 240/4 lasting a year was an
> optimistic count.
>
> Owen
>
>
> On Jan 11, 2024, at 13:15, Christopher Hawker 
>  wrote:
>
> Hi Tom,
>
> I'm not too sure I understand where the idea came from that 2 x /8 would
> only last one year. APNIC received their final allocation of the 103/8
> prefix from ICANN/IANA on 03 February 2011, and commenced delegating space
> from the prefix on 18 April 2011. With the right policies in place, it can
> be well and truly extended.
>
> Looking at an APNIC Blog article authored by Guangliang Pan on 09 October
> 2023 (https://blog.apnic.net/2023/10/09/nearing-the-end-of-103-8/), as of
> the time the article was written there were 121 available /24 prefixes from
> the 103/8 pool still available. Not a great deal in the grand scheme of
> things, however, it demonstrates that policy works in preserving what
> finite resources we have left, and that a 2 x /8 will last a lot longer
> than one year.
>
> I could say the same, that 2 x /8 lasting a little more than a year is an
> extremely remote and highly unlikely assumption. Bear in mind that APNIC
> policy was changed 1/2 way through to drop 103/8 delegations from a /22 to
> a /23. Based on this, 65,536 x /23 delegations can be made to new members
> and as Peter said, if post-exhaustion policy is applied to 240/4 it'll go
> an extremely long way.
>
> Regards,
> Christopher Hawker
>
>
>
> On Fri, 12 Jan 2024 at 04:26, Tom Beecher  wrote:
>
>> Christopher-
>>
>> Reclassifying this space, would add 10+ years onto the free pool for each
>>> RIR. Looking at the APNIC free pool, I would estimate there is about 1/6th
>>> of a /8 pool available for delegation, another 1/6th reserved.
>>> Reclassification would see available pool volumes return to pre-2010 levels.
>>>
>>
>> Citing Nick Hilliard from another reply, this is an incorrect statement.
>>
>> on this point: prior to RIR depletion, the annual global run-rate on /8s
>>> measured by IANA was ~13 per annum. So that suggests that 240/4 would
>>> provide a little more than 1Y of consumption, assuming no demand
>>> back-pressure, which seems an unlikely assumption.
>>>
>>
>> I share Dave's views, I would like to see 240/4 reclassified as unicast
>>> space and 2 x /8s delegated to each RIR with the /8s for AFRINIC to be held
>>> until their issues have been resolved.
>>>
>>
>> This has been discussed at great length at IETF. The consensus on the
>> question has been consistent for many years now; doing work to free up
>> 12-ish months of space doesn't make much sense when IPv6 exists, along with
>> plenty of transition/translation mechanisms. Unless someone is able to
>> present new arguments that change the current consensus, it's not going to
>> happen.
>>
>> On Thu, Jan 11, 2024 at 5:54 AM Christopher Hawker 
>> wrote:
>>
>>> There really is no reason for 240/4 to remain "reserved". I share Dave's
>>> views, I would like to see 240/4 reclassified as unicast space and 2 x /8s
>>> delegated to each RIR with the /8s for AFRINIC to be held until their
>>> issues have been resolved.
>>>
>>> Reclassifying this space, would add 10+ years onto the free pool for
>>> each RIR. Looking at the APNIC free pool, I would estimate there is about
>>> 1/6th of a /8 pool available for delegation, another 1/6th reserved.
>

Re: 202401100645.AYC Re: IPv4 address block

[Tom Beecher]

>
> Thought that 12 month argument was purest BS in light of all the
> events since 2011. We have been "out" of IPv4 space for many years
> now, and there is a functioning market for IPv4 space that seems to be
> serving the purpose. 240/4 is only marginally useful today, but useful
> it is.
>


Sure, because even though direct allocations from RIRs are exhausted, there
are still TONS of non-RFC1918 IPv4 addresses out there not actually being
used at all. We all know that years ago it wasn't that difficult to get way
more than you needed, and there was never any real pressure or incentive to
give anything back. Once exhaustion got on people's radars, hoarding
begin in earnest because it wasn't difficult to predict that there would
prob be a way to monetize it later. A former employer of mine is still
sitting on around a /12 worth that we had accumulated through some
acquisitions. We never NEEDED more than a /19. I left more than a decade
ago, and he's been subsidizing the long , slow decline of the primary
business by selling off chunks of that space here and there. Certainly not
a unique circumstance. We know there are companies out there that
categorize IP addresses as an appreciable investment asset.

The fact that $/IP peaked about 3 years ago, and has steadily been in
decline since is instructive that demand for v4 space is decreasing, which
tends to toss a wrench in the story that 240/4 is *needed*.

There are rumblings far outside the realm of the ietf.
>

AFAIK, at this point IANA will only change the designation of a V4 block if
the IETF process decides they should. So I'm not sure why other rumblings
matter all that much.


> Instead, bigcos like google and amazon have been able to squat on
> 240/4 and take advantage of it for 5+ years now. I do kind of hope
> others are using it up in the same ways they are.
>

I know a lot of places that are not those companies that are using 240/4
internally. Some are many orders of magnitude smaller.

I would disagree with it being referred to as 'squatting'. Today, nobody's
usage of 240/4 internally impacts anyone else.




On Thu, Jan 11, 2024 at 12:37 PM Dave Taht  wrote:

> On Thu, Jan 11, 2024 at 12:26 PM Tom Beecher  wrote:
> >
> > Christopher-
> >
> >> Reclassifying this space, would add 10+ years onto the free pool for
> each RIR. Looking at the APNIC free pool, I would estimate there is about
> 1/6th of a /8 pool available for delegation, another 1/6th reserved.
> Reclassification would see available pool volumes return to pre-2010 levels.
> >
> >
> > Citing Nick Hilliard from another reply, this is an incorrect statement.
> >
> >> on this point: prior to RIR depletion, the annual global run-rate on /8s
> >> measured by IANA was ~13 per annum. So that suggests that 240/4 would
> >> provide a little more than 1Y of consumption, assuming no demand
> >> back-pressure, which seems an unlikely assumption.
> >
> >
> >> I share Dave's views, I would like to see 240/4 reclassified as unicast
> space and 2 x /8s delegated to each RIR with the /8s for AFRINIC to be held
> until their issues have been resolved.
> >
> >
> > This has been discussed at great length at IETF. The consensus on the
> question has been consistent for many years now; doing work to free up
> 12-ish months of space doesn't make much sense
>
> Thought that 12 month argument was purest BS in light of all the
> events since 2011. We have been "out" of IPv4 space for many years
> now, and there is a functioning market for IPv4 space that seems to be
> serving the purpose. 240/4 is only marginally useful today, but useful
> it is.
>
> > when IPv6 exists, along with plenty of transition/translation
> mechanisms. Unless someone is able to present new arguments that change the
> current consensus, it's not going to happen.
>
> Instead, bigcos like google and amazon have been able to squat on
> 240/4 and take advantage of it for 5+ years now. I do kind of hope
> others are using it up in the same ways they are.
>
> Consensus, no. Just the few, like my team, that looked clearly at the
> future internet's needs getting shouted down by those in power over
> there. We cited many other arguments in favor of opening it up. There
> are rumblings far outside the realm of the ietf.
>
> I was once naive enough to consider the internet a vast, global,
> shared, and beloved space with resources that needed to be conserved
> and spread to and for all mankind. And while I still do feel that, our
> existing bureaucracies and gatekeepers have seemingly infinite power
> to say no, to even simple improvements to how the internet could work.
>
> There is no reason wha

Re: 202401100645.AYC Re: IPv4 address block

[Tom Beecher]

Christopher-

Reclassifying this space, would add 10+ years onto the free pool for each
> RIR. Looking at the APNIC free pool, I would estimate there is about 1/6th
> of a /8 pool available for delegation, another 1/6th reserved.
> Reclassification would see available pool volumes return to pre-2010 levels.
>

Citing Nick Hilliard from another reply, this is an incorrect statement.

on this point: prior to RIR depletion, the annual global run-rate on /8s
> measured by IANA was ~13 per annum. So that suggests that 240/4 would
> provide a little more than 1Y of consumption, assuming no demand
> back-pressure, which seems an unlikely assumption.
>

I share Dave's views, I would like to see 240/4 reclassified as unicast
> space and 2 x /8s delegated to each RIR with the /8s for AFRINIC to be held
> until their issues have been resolved.
>

This has been discussed at great length at IETF. The consensus on the
question has been consistent for many years now; doing work to free up
12-ish months of space doesn't make much sense when IPv6 exists, along with
plenty of transition/translation mechanisms. Unless someone is able to
present new arguments that change the current consensus, it's not going to
happen.

On Thu, Jan 11, 2024 at 5:54 AM Christopher Hawker 
wrote:

> There really is no reason for 240/4 to remain "reserved". I share Dave's
> views, I would like to see 240/4 reclassified as unicast space and 2 x /8s
> delegated to each RIR with the /8s for AFRINIC to be held until their
> issues have been resolved.
>
> Reclassifying this space, would add 10+ years onto the free pool for each
> RIR. Looking at the APNIC free pool, I would estimate there is about 1/6th
> of a /8 pool available for delegation, another 1/6th reserved.
> Reclassification would see available pool volumes return to pre-2010 levels.
>
> https://www.apnic.net/manage-ip/ipv4-exhaustion/
>
> In the IETF draft that was co-authored by Dave as part of the IPv4 Unicast
> Extensions Project, a very strong case was presented to convert this space.
>
> https://www.ietf.org/archive/id/draft-schoen-intarea-unicast-240-00.html
>
> Regards,
> Christopher Hawker
>
> On Thu, 11 Jan 2024 at 20:40, Dave Taht  wrote:
>
>> On Wed, Jan 10, 2024 at 11:06 AM Tom Beecher  wrote:
>> >>
>> >> There's a whole bunch of software out there that makes certain
>> >> assumptions about allowable ranges. That is, they've been compiled with
>> >> a header that defines ..
>> >
>> >
>> > Of course correct. It really depends on the vendor / software /
>> versions in an environment. A lot of vendors removed that years ago,
>> because frankly a lot of large networks have been using 240/4 as pseudo
>> RFC1918 for years. Others have worked with smaller vendors and open source
>> projects to do the same.
>> >
>> > It's consistently a topic in the debates about 240/4 reclassification.
>>
>> There's debates still? I gave up. After making 240/4 and 0/8 work
>> across all of linux and BSD and all the daemons besides bird (which
>> refused the patch , I took so much flack that I decided I would just
>> work on other things. So much of that flack was BS - like if you kill
>> the checks in the OS the world will end - that didn't happen. Linux
>> has had these two address ranges just work for over 5 years now.
>>
>> 240/4 is intensely routable and actually used in routers along hops
>> inside multiple networks today, but less so as a destination.
>>
>> I would really like, one day, to see it move from reserved to unicast
>> status, officially. I would have loved it if 0/8 was used by a space
>> RIR, behind CGNAT, for starters, but with a plan towards making it
>> routable. I am not holding my breath.
>>
>> The principal accomplishment of the whole unicast extensions project
>> was to save a nanosecond across all the servers in the world on every
>> packet by killing the useless 0/8 check. That patch paid for itself
>> the first weekend after that linux kernel deployed. It is the
>> simplest, most elegant, and most controversial patch I have ever
>> written.
>>
>> https://news.ycombinator.com/item?id=20430096
>>
>>
>> >
>> > On Wed, Jan 10, 2024 at 10:45 AM Michael Butler <
>> i...@protected-networks.net> wrote:
>> >>
>> >> On 1/10/24 10:12, Tom Beecher wrote:
>> >> > Karim-
>> >> >
>> >> > Please be cautious about this advice, and understand the full
>> context.
>> >> >
>> >> > 240/4 is still classified as RESERVED space. While you

Re: 202401102221.AYC Re: Streamline The CG-NAT Re: 202401100645.AYC Re: IPv4 address block

[Tom Beecher]

>
> 1)Your caution advice to Karim is professional. With a lot of
> convoluted topics behind it, however, the net result is basically
> discouraging the listener from investigating the possibilities.


No, it is not.

The original question from Karim was about acquiring some IPv4 space. We
can absolutely infer he wanted that space to be publically routable *today*.

The facts are that *today* :

1. 240/4 is not space that will provide expected internet connectivity
2. There are no plans or timelines in place that would change #1.

You stated to Karim that there was a way he could get IPs for free , and
implied if he reached out to you off list , you could help him make it
work. That was intentionally misleading, and frankly doesn't reflect very
well on you at all.


On Wed, Jan 10, 2024 at 11:09 PM Abraham Y. Chen  wrote:

> Hi, Tom:
>
> 1)Your caution advice to Karim is professional. With a lot of
> convoluted topics behind it, however, the net result is basically
> discouraging the listener from investigating the possibilities. Since this
> is rather philosophical, it can distract us from the essence unless we
> carry on a lengthy debate. Instead, I would like to address below only one
> aspect that you brought up.
>
> 2)"... an operator clearly looking to acquire *publicly routable*
> space without being clear that this suggestion wouldn't meet their needs.
> ":
>
> Since 240/4 has 256M addresses while 100.64/10 has only 4M, a current
> CG-NAT cluster can be expanded 64 fold once the 240/4 is used. Looking from
> another angle, an IAP will then be able to expand the subscriber set 64
> fold with still the original one publicly routable IPv4 address.
>
> 3)This 64 fold scaling factor is critical because it allows one CG-NAT
> cluster to serve a geographical area that becomes sufficient to cover a
> significant political territory. For example, if we assign two 240/4
> addresses to each subscriber, one for stationary applications, one for
> mobile devices. And, each 240/4 address can be expanded by RFC1918
> netblocks (total about 17.6M each). Each CG-NAT can now serve a country
> with population up to 128M. It turns out that population of over 90+ % of
> countries are fewer than this. So, each of them needs only one publicly
> routable IPv4 address. Then, the demand for IPv4 address is drastically
> reduced.
>
> 4)In brief, the 240/4 is to substitute that of 100.64/10. So that the
> need for the publicly routable IPv4 addresses is significantly reduced.
>
> Regards,
>
>
> Abe (2024-01-10 23:08 EST)
>
>
> On 2024-01-10 10:12, Tom Beecher wrote:
>
> Karim-
>
> Please be cautious about this advice, and understand the full context.
>
> 240/4 is still classified as RESERVED space. While you would certainly be
> able to use it on internal networks if your equipment supports it, you
> cannot use it as publicly routable space. There have been many proposals
> over the years to reclassify 240/4, but that has not happened, and is
> unlikely to at any point in the foreseeable future.
>
> Mr. Chen-
>
> I understand your perspective surrounding 240/4, and respect your
> position, even though I disagree. That being said, it's pretty dirty pool
> to toss this idea to an operator clearly looking to acquire *publicaly
> routable* space without being clear that this suggestion wouldn't meet
> their needs.
>
> ( Unless people are transferring RFC1918 space these days, in which case
> who wants to make me an offer for 10/8? )
>
> On Wed, Jan 10, 2024 at 9:48 AM KARIM MEKKAOUI 
> wrote:
>
>> Interesting and thank you for sharing.
>>
>>
>>
>> KARIM
>>
>>
>>
>> *From:* Abraham Y. Chen 
>> *Sent:* January 10, 2024 7:35 AM
>> *To:* KARIM MEKKAOUI 
>> *Cc:* nanog@nanog.org; Chen, Abraham Y. 
>> *Subject:* 202401100645.AYC Re: IPv4 address block
>> *Importance:* High
>>
>>
>>
>> Hi, Karim:
>>
>>
>>
>> 1)If you have control of your own equipment (I presume that your
>> business includes IAP - Internet Access Provider, since you are asking to
>> buy IPv4 blocks.), you can get a large block of reserved IPv4 address *for
>> free* by *disabling* the program codes in your current facility that has
>> been *disabling* the use of 240/4 netblock. Please have a look at the
>> below whitepaper. Utilized according to the outlined disciplines, this is a
>> practically unlimited resources. It has been known that multi-national
>> conglomerates have been using it without announcement. So, you can do so
>> stealthily according to the proposed mechanism which establishes uniform
>> practices, just as w

Re: 202401100645.AYC Re: IPv4 address block

[Tom Beecher]

>
> There's a whole bunch of software out there that makes certain
> assumptions about allowable ranges. That is, they've been compiled with
> a header that defines ..
>

Of course correct. It really depends on the vendor / software / versions in
an environment. A lot of vendors removed that years ago, because frankly a
lot of large networks have been using 240/4 as pseudo RFC1918 for years.
Others have worked with smaller vendors and open source projects to do the
same.

It's consistently a topic in the debates about 240/4 reclassification.


On Wed, Jan 10, 2024 at 10:45 AM Michael Butler 
wrote:

> On 1/10/24 10:12, Tom Beecher wrote:
> > Karim-
> >
> > Please be cautious about this advice, and understand the full context.
> >
> > 240/4 is still classified as RESERVED space. While you would certainly
> > be able to use it on internal networks if your equipment supports it,
> > you cannot use it as publicly routable space. There have been many
> > proposals over the years to reclassify 240/4, but that has not happened,
> > and is unlikely to at any point in the foreseeable future.
>
> While you may be able to get packets from point A to B in a private
> setting, using them might also be .. a challenge.
>
> There's a whole bunch of software out there that makes certain
> assumptions about allowable ranges. That is, they've been compiled with
> a header that defines ..
>
> #define IN_BADCLASS(i)  (((in_addr_t)(i) & 0xf000) == 0xf000)
>
> Michael
>
>

Re: 202401100645.AYC Re: IPv4 address block

[Tom Beecher]

Karim-

Please be cautious about this advice, and understand the full context.

240/4 is still classified as RESERVED space. While you would certainly be
able to use it on internal networks if your equipment supports it, you
cannot use it as publicly routable space. There have been many proposals
over the years to reclassify 240/4, but that has not happened, and is
unlikely to at any point in the foreseeable future.

Mr. Chen-

I understand your perspective surrounding 240/4, and respect your position,
even though I disagree. That being said, it's pretty dirty pool to toss
this idea to an operator clearly looking to acquire *publicaly routable*
space without being clear that this suggestion wouldn't meet their needs.

( Unless people are transferring RFC1918 space these days, in which case
who wants to make me an offer for 10/8? )

On Wed, Jan 10, 2024 at 9:48 AM KARIM MEKKAOUI  wrote:

> Interesting and thank you for sharing.
>
>
>
> KARIM
>
>
>
> *From:* Abraham Y. Chen 
> *Sent:* January 10, 2024 7:35 AM
> *To:* KARIM MEKKAOUI 
> *Cc:* nanog@nanog.org; Chen, Abraham Y. 
> *Subject:* 202401100645.AYC Re: IPv4 address block
> *Importance:* High
>
>
>
> Hi, Karim:
>
>
>
> 1)If you have control of your own equipment (I presume that your
> business includes IAP - Internet Access Provider, since you are asking to
> buy IPv4 blocks.), you can get a large block of reserved IPv4 address *for
> free* by *disabling* the program codes in your current facility that has
> been *disabling* the use of 240/4 netblock. Please have a look at the
> below whitepaper. Utilized according to the outlined disciplines, this is a
> practically unlimited resources. It has been known that multi-national
> conglomerates have been using it without announcement. So, you can do so
> stealthily according to the proposed mechanism which establishes uniform
> practices, just as well.
>
>
>
> https://www.avinta.com/phoenix-1/home/RevampTheInternet.pdf
>
>
>
> 2)Being an unorthodox solution, if not controversial, please follow up
> with me offline. Unless, other NANOGers express their interests.
>
>
>
>
>
> Regards,
>
>
>
>
>
> Abe (2024-01-10 07:34 EST)
>
>
>
>
>
>
>
> On 2024-01-07 22:46, KARIM MEKKAOUI wrote:
>
> Hi Nanog Community
>
>
>
> Any idea please on the best way to buy IPv4 blocs and what is the price?
>
>
>
> Thank you
>
>
>
> KARIM
>
>
>
>
>
>
>
>
> 
>
> Virus-free.www.avast.com
> 
>
>
>

Re: Arista “IP-SLA” / Active Probing

[Tom Beecher]

>
> I did some research on this and it seems like perhaps the on-boot event
> handler launching a python daemon to do this active probing out each isp
> circuit and then making config changes in response to transit failures
> might be the best option available to us.
>

Pretty much, yes. They don't have any functionality like IP-SLA in EOS, but
you can roll your own.

Ex:

https://github.com/arista-eosext/PingCheck



On Wed, Dec 20, 2023 at 1:44 PM Alex Buie  wrote:

> Hello all,
>
> We find ourselves trying to solve a requirement where we would like to
> test the viability of our paths to the internet and tear down the bgp
> session if it is determined to be faulty. We had an issue recently where we
> did not lose link or bgp but the carrier lost the ability to route traffic
> to the internet for us and our existing automatic detection and remediation
> strategies failed to detect this condition and we lost customer packets.
>
> Conceptually, we have a pair of DCS7050-QX landing a fiber each from two
> ISPs with default routes on BGP at a dozen POPs around the US.
>
> One of the ISPs is our primary transit, and one is predominantly for
> peered customers, but we can use it for transit during issues with the
> primary circuits.
>
> I did some research on this and it seems like perhaps the on-boot event
> handler launching a python daemon to do this active probing out each isp
> circuit and then making config changes in response to transit failures
> might be the best option available to us.
>
> However, I thought I’d reach out to the broader community to see if
> there’s a better way to solve this, has an example script, or if anyone has
> recommendations for methods of active monitoring for protecting against
> this sort of failure.
>
> Thanks in advance for any insight and time.
>
>
>
>
> *Alex Buie*Senior Cloud Operations Engineer
>
> 450 Century Pkwy # 100 Allen, TX 75013
> 
> D: 469-884-0225 | www.cytracom.com
>

Re: Interesting Ali Express web server behavior...

[Tom Beecher]

>
> But why would AliExpress be redirecting to DDN space? Is this legitimate?
> Ali hoping to get away with squatting, or something else?


I've seen a large number of cases that a company was  using someone else's
non-RFC1918 space for some reason, and that was accidentally exposed via
application communication when some process / procedure they were using to
fix that up didn't work. This feels like that to me.

On Sun, Dec 10, 2023 at 12:57 AM Owen DeLong via NANOG 
wrote:

> So I’m having trouble connecting to the Ali Express web server this
> evening and decided to investigate a little.
>
> What I found surprised me…
>
> owen@odmbpro3-3 ~ % openssl s_client -connect www.aliexpress.com:443
>
> CONNECTED(0005)
>
> depth=2 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert
> Global Root CA
>
> verify return:1
>
> depth=1 C = US, O = DigiCert Inc, CN = DigiCert TLS RSA SHA256 2020 CA1
>
> verify return:1
>
> depth=0 C = CN, ST = \E6\B5\99\E6\B1\9F\E7\9C\81, L =
> \E6\9D\AD\E5\B7\9E\E5\B8\82, O = Alibaba Cloud Computing Ltd., CN =
> ae01.alicdn.com
>
> verify return:1
> … certificate stuff, blah blah from Akamai, routine…
>
> SSL-Session:
>
> Protocol  : TLSv1.3
>
> Cipher: AEAD-CHACHA20-POLY1305-SHA256
>
> Session-ID:
>
> Session-ID-ctx:
>
> Master-Key:
>
> Start Time: 1702187128
>
> Timeout   : 7200 (sec)
>
> Verify return code: 0 (ok)
>
> ---
>
> read R BLOCK
>
> read R BLOCK
>
> GET / HTTP/1.1
>
> Host: www.aliexpress.com
>
>
> HTTP/1.1 302 Moved Temporarily
>
> Content-Type: text/html
>
> Content-Length: 258
>
> Location: http://33.3.37.57/
>
> Access-Control-Allow-Origin: https://hz.aliexpress.com
>
> Server: Tengine/Aserver
>
> EagleEye-TraceId: 2103253917021871367418570ec8e3
>
> Strict-Transport-Security: max-age=31536000
>
> Timing-Allow-Origin: *
>
> Date: Sun, 10 Dec 2023 05:45:36 GMT
>
> Connection: keep-alive
>
> Set-Cookie: ali_apache_id=33.3.37.57.1702187136742.612980.2; path=/;
> domain=.aliexpress.com; expires=Wed, 30-Nov-2084 01:01:01 GMT
>
> Server-Timing: cdn-cache; desc=MISS
>
> Server-Timing: edge; dur=65
>
> Server-Timing: origin; dur=3
>
> Server-Timing: ak_p;
> desc="1702187128314_400069768_2521981097_6837_5323_25_43_-";dur=1
>
>
> 
>
> 
>
> 302 Found
>
> 
>
> 302 Found
>
> The requested resource resides temporarily under a different URI.
>
> Powered by Tengine
>
> 
> … OK, so far so good, though the hard coded IP redirect is a bit odd.
> Especially when you consider this:
>
> NetRange:   33.0.0.0 - 33.255.255.255
>
> CIDR:   33.0.0.0/8
>
> NetName:DISN-IP-LEGACY
>
> NetHandle:  NET-33-0-0-0-1
>
> Parent:  ()
>
> NetType:Direct Allocation
>
> OriginAS:
>
> Organization:   DoD Network Information Center (DNIC)
>
> RegDate:1991-01-01
>
> Updated:2013-09-11
>
> Ref:https://rdap.arin.net/registry/ip/33.0.0.0
>
>
>
> OrgName:DoD Network Information Center
>
> OrgId:  DNIC
>
> Address:3990 E. Broad Street
>
> City:   Columbus
>
> StateProv:  OH
>
> PostalCode: 43218
>
> Country:US
>
> RegDate:
>
> Updated:2011-08-17
>
> Ref:https://rdap.arin.net/registry/entity/DNIC
>
>
>
> OrgTechHandle: REGIS10-ARIN
>
> OrgTechName:   Registration
>
> OrgTechPhone:  +1-844-347-2457
>
> OrgTechEmail:  disa.columbus.ns.mbx.arin-registrati...@mail.mil
>
> OrgTechRef:https://rdap.arin.net/registry/entity/REGIS10-ARIN
>
>
> OrgAbuseHandle: REGIS10-ARIN
>
> OrgAbuseName:   Registration
>
> OrgAbusePhone:  +1-844-347-2457
>
> OrgAbuseEmail:  disa.columbus.ns.mbx.arin-registrati...@mail.mil
>
> OrgAbuseRef:https://rdap.arin.net/registry/entity/REGIS10-ARIN
>
>
> OrgTechHandle: MIL-HSTMST-ARIN
>
> OrgTechName:   Network DoD
>
> OrgTechPhone:  +1-844-347-2457
>
> OrgTechEmail:  disa.columbus.ns.mbx.hostmaster-dod-...@mail.mil
>
> OrgTechRef:https://rdap.arin.net/registry/entity/MIL-HSTMST-ARIN
>
> Which seems in line with the announcement of that address I’m seeing:
>
> owen@delong-fmt2-mx-01> show route 33.3.37.57
>
>
> inet.0: 947480 destinations, 2018685 routes (947480 active, 0 holddown, 0
> hidden)
>
> + = Active Route, - = Last Active, * = Both
>
>
> 33.0.0.0/8 *[BGP/170] 1w6d 05:39:58, localpref 2000
>
>   AS path: 6939 3356 749 I, validation-state:
> unverified
>
> >  to 64.71.131.26 via ge-2/0/0.0
>
> [BGP/170] 1w6d 05:35:29, localpref 100, from
> 192.124.40.252
>
>   AS path: 36236 2914 3356 749 I, validation-state:
> unverified
>
> >  via gr-2/3/0.70
>
> (AS749 is also DISA/DDI)
>
> But why would AliExpress be redirecting to DDN space? Is this legitimate?
> Ali hoping to get away with squatting, or something else?
>
> Owen
>
>

Re: Any comprehensive listing of where Google's IPs originate from?

[Tom Beecher]

>
> i would expect that google announces the /16 at least from 'everywhere',
> yes.
>

I see the specific /18s Drew asked about initially. Didn't check for the
covering /16.

On Tue, Dec 5, 2023 at 1:29 PM Christopher Morrow 
wrote:

> On Tue, Dec 5, 2023 at 11:06 AM Tom Beecher  wrote:
> >
> > From my observations, all us-east-5 IPs are announced via transit and
> peering at all of my locations Chicago and east.
> >
>
> i would expect that google announces the /16 at least from 'everywhere',
> yes.
>
> > On Mon, Dec 4, 2023 at 9:11 AM Drew Weaver 
> wrote:
> >>
> >> Hello,
> >>
> >>
> >>
> >> We are trying to reduce latency to a region in Google Cloud which we
> are in the same city of. Latency is currently about 22ms rt for the traffic
> to go 9 miles.
> >>
> >>
> >>
> >> I am having the hardest time finding any comprehensive list of what
> exchanges, transit, etc their IP addresses are being announced over.
> >>
>
> 100% chance the best option is peeringdb (I'm betting closest to
> drew is chicago-land-ix-ville)
>
> >>
> >>
> >> Specifically trying to get closer to addresses in these prefixes:
> >>
> >>
> >>
> >> 34.162.192.0/18
> >>
> >> 34.162.64.0/18
> >>
> >>
> >>
> >> Any info is greatly appreciated.
> >>
> >>
> >>
> >> Thanks,
> >>
> >> -Drew
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
>

Re: Any comprehensive listing of where Google's IPs originate from?

[Tom Beecher]

>From my observations, all us-east-5 IPs are announced via transit and
peering at all of my locations Chicago and east.

On Mon, Dec 4, 2023 at 9:11 AM Drew Weaver  wrote:

> Hello,
>
>
>
> We are trying to reduce latency to a region in Google Cloud which we are
> in the same city of. Latency is currently about 22ms rt for the traffic to
> go 9 miles.
>
>
>
> I am having the hardest time finding any comprehensive list of what
> exchanges, transit, etc their IP addresses are being announced over.
>
>
>
> Specifically trying to get closer to addresses in these prefixes:
>
>
>
> 34.162.192.0/18
>
> 34.162.64.0/18
>
>
>
> Any info is greatly appreciated.
>
>
>
> Thanks,
>
> -Drew
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>

Re: What are these Google IPs hammering on my DNS server?

[Tom Beecher]

172.253.X.X are Google DNS : https://www.gstatic.com/ipranges/publicdns.json


172.71.X.X are Cloudflare : https://www.cloudflare.com/ips-v4/#

On Sun, Dec 3, 2023 at 1:49 PM John Levine  wrote:

> At contacts.abuse.net, I have a little stunt DNS server that provides
> domain contact info, e.g.:
>
> $ host -t txt comcast.net.contacts.abuse.net
> comcast.net.contacts.abuse.net descriptive text "ab...@comcast.net"
>
> $ host -t hinfo comcast.net.contacts.abuse.net
> comcast.net.contacts.abuse.net host information "lookup" "comcast.net"
>
> Every once in a while someone decides to look up every domain in the
> world and DoS'es it until I update my packet filters. This week it's
> been this set of IPs that belong to Google. I don't think they're
> 8.8.8.8. Any idea what they are? Random Google Cloud customers? A
> secret DNS mapping project?
>
>  172.253.1.133
>  172.253.206.36
>  172.253.1.130
>  172.253.206.37
>  172.253.13.196
>  172.253.255.36
>  172.253.13.197
>  172.253.1.131
>  172.253.255.35
>  172.253.255.37
>  172.253.1.132
>  172.253.13.193
>  172.253.1.129
>  172.253.255.33
>  172.253.206.35
>  172.253.255.34
>  172.253.206.33
>  172.253.206.34
>  172.253.13.194
>  172.253.13.195
>  172.71.125.63
>  172.71.117.60
>  172.71.133.51
>
> R's,
> John
>

Re: sigs wanted for a response to the fcc's NOI for faster broadband speeds

[Tom Beecher]

Trying to put technical requirements like this into law and public policy
is an extremely terrible idea. This letter should never be sent.

The regulatory agencies today don't have the manpower or expertise to
adequately enforce the more generic broadband deployment rules. What
fantasy world exists where they have the manpower or expertise to monitor
for and enforce something like this? Hell, there are constant , legitimate
technical discussions between experts on HOW to *properly* monitor things
just like this. We want to have someone at the FCC deciding what that
should look like?

4.4 What the hell? The regulatory agencies should be allocating spectrum,
and making sure it's not used improperly with the rules of allocation.
Making it work 'better' is OUR job in the technical community. Not an FCC
rulemaker.

4.8 There are zero scenarios there should ever be regulatory rules about
device software. In our space (non-ISP) , TONS of people run older versions
of vendor code. Why? The shit DOESN'T WORK RIGHT YET and it causes other
problems. You suggest that regulatory bodies be involved in dictating
anything about this?

The bufferbloat work belongs in the technical area, full stop. Nowhere near
regulatory / legal.

On Thu, Nov 30, 2023 at 7:57 PM Dave Taht  wrote:

> Over here:
>
>
> https://docs.google.com/document/d/19ADByjakzQXCj9Re_pUvrb5Qe5OK-QmhlYRLMBY4vH4/edit
>
> Us bufferbloat folk have been putting together a response to the FCC's
> NOI (notice of inquiry) asking for feedback as to increasing the
> broadband speeds beyond 100/20 Mbit.
>
> "Calls for further bandwidth increases are analogous to calling for
> cars to have top speeds of 100, 200, or 500 miles per hour. Without
> calling also for better airbags, bumpers, brakes, or steering wheels,
> (or roads designed to minimize travel delay), these initiatives will
> fail (and are failing) to meet the needs of present and future users
> of the internet."
>
> Comments (and cites) welcomed also! The text is still somewhat in flux...
>
>
> --
> :( My old R&D campus is up for sale: https://tinyurl.com/yurtlab
> Dave Täht CSO, LibreQos
>

Re: Advantages and disadvantages of legacy assets

[Tom Beecher]

>
> Are you sure? The way I read it, that policy applies to -customer-
> announced routes, not broad Internet routes received from peers and
> transit.
>

You are reading it correctly.

On Wed, Nov 22, 2023 at 3:15 PM William Herrin  wrote:

> On Wed, Nov 22, 2023 at 11:22 AM o...@delong.com  wrote:
> > > On Nov 21, 2023, at 01:38, William Herrin  wrote:
> > > Disadvantages: Expensive IRR. No RPKI. No vote in ARIN elections. No
> > > legal clarity regarding the status of your resources.
> >
> > Expensive IRR? ALTDB is free?
>
> I don't know anything about ALTDB. RADB is pricey.
>
>
> On Wed, Nov 22, 2023 at 11:16 AM owen--- via NANOG 
> wrote:
> > Apparently, Tata is rejecting routes that have neither RPKI nor an
> RIR-based IRR record created after 1993.
>
> Are you sure? The way I read it, that policy applies to -customer-
> announced routes, not broad Internet routes received from peers and
> transit.
>
> It still seems unwise, but not entirely insane.
>
> Regards,
> Bill Herrin
>
> --
> William Herrin
> b...@herrin.us
> https://bill.herrin.us/
>

Re: BGP-iSec: Improved Security of Internet Routing Against Post-ROV Attacks

[Tom Beecher]

Amir-

I have to take some issue with one comment you made in response to Job.

BGP-iSec, at this point, is just an academic study studying some new ideas
> and evaluating their impact in specific configurations, under specific
> assumptions etc.; hopefully, this may provide some help to the community in
> improving BGP security.
>

When reviewing the paper , it feels as if BGP-iSec is being presented as a
working solution, not just ideas and theoretical analysis. Care should be
taken not to oversell the status of a thing; that just leads to confusion
and issues later.

Also, as an aside, when most network engineers read statements that
something is "relatively easy to implement", large red lights start going
off in our brains; If we had $1 for every time we heard that and it turned
out to be false, we'd all pretty much be retired. :)








On Mon, Nov 20, 2023 at 10:45 AM Amir Herzberg  wrote:

> Lancheng, thanks for your comment.
>
> About ProConi (and ASPA): so, we're aware it's more challenging than ASPA
> and have evaluated the effort required - it actually doesn't seem too bad,
> although that doesn't mean that it'll be cost effective to use it. But as
> I've mentioned in an earlier email to this list, Joel Halpern (cc:ed) has
> alerted us to an even larger problem with ProConi; the proconi list of a
> given AS may become incorrect due to certain changes in AS relationships,
> leading to possible false-positives for possibly significant time. This is
> obviously very problematic and we are editing this part of the paper to
> reflect this risk. Probably, this mechanism should not be deployed;
> luckily, we obtained good results also with the other defenses against
> leakage in the paper, for the practical case of non-eavesdropping
> adversary. In any case we see the work as the opening point, or another
> step, toward more effective defenses against path manipulations and
> intentional route leaks. More work should be done.
>
> We look forward to meeting you in NDSS; I haven't yet seen list of
> accepted papers, and it'll be great if you can share your paper. But if
> not, then we'll see it in the conference :)
>
> best, Amir
> --
> Amir Herzberg
>
> Comcast professor of Security Innovations, Computer Science and
> Engineering, University of Connecticut
> Homepage: https://sites.google.com/site/amirherzberg/home
> `Applied Introduction to Cryptography' textbook and lectures:
> https://sites.google.com/site/amirherzberg/cybersecurity
>
>
>
>
> On Mon, Nov 20, 2023 at 5:30 AM Lancheng Qin 
> wrote:
>
>> Hi Amir,
>>
>>
>>
>> I really enjoy reading this paper, and I’m interested in your design of
>> preventing attribute manipulations and route leaks.
>>
>>
>>
>> I think BGP-iSec is useful under a Global Attacker. But I have some
>> concerns about using ProConIP-list under a Full Attacker (in Sec. III-B).
>> Using ProConIP-list requires the origin AS clearly knows its provider cone,
>> which is challenging in practice. Although we can use CAIDA topology to
>> infer the provider cone of an AS, some provider-customer relationships may
>> not be discovered by CAIDA topology or other existing AS relationship
>> inference algorithms. If the ProConIP-list is not accurate or complete
>> (i.e., covering all BGP-iSec-adopting ASes in the provider cone), it may
>> cause legitimate BGP announcements to be dropped. Compared to publishing
>> the whole provider cone, ASPA requires an AS to publish its provider ASes,
>> which is easier and more feasible. Can we use BGP-iSec and ASPA together? 
>> Would
>> that be more beneficial?
>>
>>
>>
>> BTW, I will also present my new work on routing security in NDSS’2024.
>> Looking forward to discussing more with you in San Diego:)
>>
>>
>>
>> Best,
>>
>> Lancheng Qin
>>
>>
>>
>>
>>
>> -原始邮件-
>> *发件人:* "Amir Herzberg" 
>> *发送时间:* 2023-11-11 07:02:48 (星期六)
>> *收件人:* NANOG 
>> *主题:* BGP-iSec: Improved Security of Internet Routing Against Post-ROV
>> Attacks
>>
>> Hi NANOGers,
>>
>>
>> We will present our new work, titled: `BGP-iSec: Improved Security of
>> Internet Routing Against Post-ROV Attacks', in NDSS'24.
>>
>>
>> If you're interested in security of Internet routing (BGP), and want a
>> copy, see URL below, drop me a message/email - or see us in the conference
>> - or just read the final version.
>>
>>
>> Available from:
>> https://www.researchgate.net/publication/375553362_BGP-iSec_Improved_Security_of_Internet_Routing_Against_Post-ROV_Attacks
>> --
>> Amir Herzberg
>>
>> Comcast professor of Security Innovations, Computer Science and
>> Engineering, University of Connecticut
>> Homepage: https://sites.google.com/site/amirherzberg/home
>> `Applied Introduction to Cryptography' textbook and lectures:
>> https://sites.google.com/site/amirherzberg/cybersecurity
>>
>>
>>

Re: Out of ideas - Comcast issue BGP peering with Tata

[Tom Beecher]

>
> Comcast has to be the one contacting them
>

This is the correct answer. It's pretty straight forward ; Comcast needs to
get with Tata, say "hey, I'm announcing prefix FOO to you, your LGs don't
look like you're accepting it. Can we figure out why?"

On Fri, Nov 17, 2023 at 10:43 AM jim deleskie  wrote:

> I many years ago worked at Tata, responsible for their BGP, they are
> giving you the right answer, Comcast has to be the one contacting them, as
> then both sides can see what is being sent and received and can resolve
> this issue.
>
> -jim
>
> On Fri, Nov 17, 2023 at 10:04 AM Jamie Chetta via NANOG 
> wrote:
>
>> I am out of ideas on how to get this fixed.  Long story short I am a
>> customer of Comcast and am advertising my own /24 block I own through
>> them.  Comcast of course BGP peers with multiple ISPs.  Other ISPs are
>> accepting my prefix just fine, except Tata.  This is causing random
>> destinations to drop connectivity if Comcast routes it through them.
>> Comcast has confirmed they are advertising my block to Tata and that the
>> RPKI is good, however when you check the Tata looking glass you can see
>> they’re not accepting it.
>>
>>
>>
>> I’ve tried escalating within Comcast who refuses to contact Tata as
>> they’ve validated the issue is not on their end but they agree with my
>> assessment that Tata is not accepting the prefix for some reason.
>>
>>
>>
>> I’ve tried multiple email for Tata support (below), but they all circle
>> around to a helpdesk who says I do not have a circuit with them so they
>> cannot help me.
>>
>>
>>
>> Is there anyone from Tata willing to contact me off list to help sort
>> this out?  Or anyone with ideas on specifically why other ISPs are
>> accepting my route but not Tata?  It would be greatly appreciated.
>>
>>
>>
>> Emails I’ve tried
>>
>> Corporate  Helpdesk corp.helpd...@tatacommunications.com
>>
>> Tata Communications IP Service Support( AS-6453)
>> ipservicesupp...@tatacommunications.com
>>
>> IPNOC (Tata Communications - AS6453) ip...@tatacommunications.com
>>
>> l...@as6453.net
>>
>>
>> Response from Tata:
>>
>> “Acknowledge your email.
>>
>>
>>
>> However, since you are not associated with TCL we would not be in a
>> position to help you on this.
>>
>>
>>
>> Request you to contact comcast for the assistance that you are seeking
>> from us.”
>>
>>
>>
>> Response from Comcast:
>>
>> “This was sent back to me as not us. Basically, it’s not a RADB or RPKI
>> issue. This is being accepted and re-advertised to TATA but not being
>> accepted on their end. But another route that we checked off of that same
>> SUR is being advertised the same way and accepted by them off
>> pe12.350ecermak.il.ibone as an example of the TATA looking glass.  I would
>> suggest that you would probably need to work with other networks as to why
>> those that are specific ones are not accepting the block but as previously
>> mentioned it’s not a RADB or RPKI issue and as a result not a Comcast
>> issue.”
>>
>

Re: Your Input Needed: Can ROA Replace LOA? ? Short Survey (7 mins)

[Tom Beecher]

>
> Therefore, Cogent currently does not have and is not member of ARIN. It
> refuses to sign contract with ARIN and currently Cogent is not bound by
> this RUD rules and regulations.
>
> There is one downfall to not being ARIN member, Cogent cannot currently
> issue ROAs or RPKIs. They only update RIR in ROADB database for the leased
> out IP addresses.
>

Not entirely accurate.

Cogent Communications is already a General Member of ARIN. You can see that
for yourself here : https://account.arin.net/public/member-list
. *Membership* is not a prerequisite for anything RPKI.

ARIN requires an RSA or LRSA in place covering a number resource before
they will be the trust anchor for that number resource. In the design of
RPKI, this should make logical sense. Many legacy resource holders have
their own reasons on why they chose not to sign an LRSA for those
resources, so there is a chicken/egg problem here.

Cogent can participate in RPKI with any non-legacy resources without a
problem, as anything non-legacy is covered by an RSA.


On Fri, Nov 17, 2023 at 8:13 AM George Toma  wrote:

> There is IPV4 exhaustion and many ISPs lease IPV4 space from other
> entities, such as brokers and other providers. One of the biggest IPv4
> lessors is Cogent. By Cogent having legacy IP space from IANA which it
> inherited when it acquired PSInet, Cogent was not required to sign a
> contract when RIR ARIN was created.
>
> Therefore, Cogent currently does not have and is not member of ARIN. It
> refuses to sign contract with ARIN and currently Cogent is not bound by
> this RUD rules and regulations.
>
> There is one downfall to not being ARIN member, Cogent cannot currently
> issue ROAs or RPKIs. They only update RIR in ROADB database for the leased
> out IP addresses.
>
> By implicitly requiring ROA or RPKI for IPv4 space leased from Covent,
> about 70% of small ISPs that were created after IPv4 space exhaustion,
> would not be able to route their IPV4 traffic, because currently they lease
> IPv4 space from Cogent, and as we mentioned, by Cogent refusing to become
> ARIN member, it cannot issue ROAs or RPKIs, and therefore ISPs using this
> leased IPV4 space can only use LOAs for validation.
>

Re: Generally accepted BGP acceptance criteria?

[Tom Beecher]

>
> I imagine there is a some sort of coalescing industry standard out there,
> but so far I can’t find it.
>

There is not, and won't be for a long time, if ever.

There isn't a one size fits all solution.

On Thu, Nov 16, 2023 at 9:31 PM Tom Samplonius  wrote:

>
>   In the world of IRR and RPKI, BGP route acceptance criteria is important
> to get right.
>
>   DE-CIX has published a detailed flow chart documenting their acceptance
> criteria:
> https://www.de-cix.net/en/locations/frankfurt/route-server-guide
>
>   But I don’t see a lot of operators publishing their criteria.  I imagine
> there is a some sort of coalescing industry standard out there, but so far
> I can’t find it.  Of the upstreams I use, just one publishes a flowchart.
> Another is basically refusing to explain anything other than they “use” IRR
> and RPKI, ad that RPKI is “good”.
>
>   I assumed that everyone implementing RPKI validation, would skip IRR
> route object validation if the route is RPKI-valid.  I assumed that
> everyone is doing this now, or would do this when they implement RPKI
> validation.  But I spoke to an operator today, which still expects all
> routes to pass IRR as well (and while they perform RPKI-validation, they
> effectively do nothing with the result).  To me, this seems like a
> different direction than most operators are going.  Or is it?
>
>   The most surprising thing in the DE-DIX flow chart, was that they check
> that the origin AS exists in the IRR as-set, before doing RPKI, and if the
> set existence fails, they reject the route.  I don’t see a problem with
> this, as maintaining as-sets is easy, but it does prevent an eventual 100%
> RPKI future with no IRR at all.
>
>   I also thought there may be an informational RFC on this, but I couldn’t
> find anything.  Has there been anything published or any presentations
> given, on generally accepted BGP route acceptance criteria?
>
>
> Tom

Re: Your Input Needed: Can ROA Replace LOA? – Short Survey (7 mins)

[Tom Beecher]

>
> 
>

In a decade working on the SP side of the world, I worked with prob 20
different upstream carriers. I can only think of one that required LOA to
accept prefixes via BGP. Everyone else was via RIR methods, or nothing.
There are of course providers out there that do, but not nearly as many to
state it's a "primary use case", especially relative to #1 and #2 on your
list.




On Thu, Nov 16, 2023 at 11:18 AM Christopher Morrow 
wrote:

> On Thu, Nov 16, 2023 at 10:22 AM Tom Beecher  wrote:
> >>
> >> In the service provider industry, its primary use is for advertising
> address resources (IPv4/v6 and ASN)
> >
> >
> > Not really.
>
> 
>
> I would think there are a few uses of LOA in the telco/SP world, at least:
>
>   1) 'can I make this cross-connect happen?'
>   2) 'can I do some work on this link/path/fiber/conduit on behalf of
>  where the entity to be worked on is 
> infrastructure'
>   3) 'Please accept this internet number resource from 
> when the number resource is authorized for use by '
>
> I would love to see ROA take over the 3rd of those, since it's a clear
> indicator that:
>   "RIR authorizes LIR to use , LIR authorizes
> AS-OWNER to originate "
>
> and by 'clear indicator' I mean: "has some cryptographic/PKI backing
> you can follow to the RIR in an automated fashion"
> Where 'LOA' generally is a xerox of a photocopy of a fax of a
> dot-matrix printed MS-Word templated document which perhaps has an X
> on the 'signature' line...
>
> -chris
>

Re: Your Input Needed: Can ROA Replace LOA? – Short Survey (7 mins)

[Tom Beecher]

>
> In the service provider industry, its primary use is for advertising
> address resources (IPv4/v6 and ASN)


Not really.

On Thu, Nov 16, 2023 at 9:19 AM Christopher Hawker 
wrote:

> Hello everyone,
>
> Aftab Siddiqui is currently exploring the possibility of using Route
> Object Authorisations (ROAs) as a potential replacement to LOAs. Separate
> to this (and unknowing of Aftab's research), I had started a discussion on
> the RPKI Community guild on Discord (https://discord.gg/9jYcqpbdRE)
> discussing the usage of ROAs instead of LOAs.
>
> An LOA, or "Letter of Authority" / "Letter of Authorization," is a formal
> document granting permission for third parties to take specific actions
> regarding network resources or services. In the service provider industry,
> its primary use is for advertising address resources (IPv4/v6 and ASN).
> When an organization intends to announce its IP prefixes through its own or
> a transit provider's ASN to the global internet, it typically needs to
> provide an LOA to their transit provider, confirming their custodianship or
> ownership of the resources.
>
> RPKI ROA, stands for "Resource Public Key Infrastructure Route Origin
> Authorization," is part of a security framework designed to validate the
> authenticity of internet routing information. It involves a digitally
> signed object that specifies which Autonomous Systems (ASes) are permitted
> to announce specific IP address prefixes.
>
> Could you please take a moment to fill out our brief survey? Your feedback
> will play a crucial role in our understanding of this topic.
>
> Survey Link: https://www.surveymonkey.com/r/JCHLWBB
>
> Thanks,
> Christopher Hawker
>

Re: Strange IPSEC traffic

[Tom Beecher]

>
> Last week somebody on the internet started a campaign to scan and perhaps
> to exploit some zero day ipsec vulnerabilities.
>

I've seen traffic like this for the better part of at least the last 7
years, fairly consistently.

It's definitely not something new.

On Mon, Nov 13, 2023 at 12:42 PM Adrian Minta 
wrote:

> On 11/13/23 19:10, Shawn L via NANOG wrote:
>
> Is anyone else seeing a lot of 'strange' IPSEC traffic?  We started seeing
> logs of IPSEC with invalid spi on Friday.  We're seeing it on pretty much
> all of our PE routers, none of which are setup to do anything VPN related.
> Most are just routing local customer traffic.
>
>
>
> decaps: rec'd IPSEC packet has invalid spi for destaddr=X.X.X.X, prot=50,
> spi=0x9D2D(2636972032), srcaddr=211.112.195.167, input
> interface=TenGigabitEthernet0/0/11
>
>
>
> decaps: rec'd IPSEC packet has invalid spi for destaddr=Y.Y.Y.Y, prot=50,
> spi=0x1469(342425600), srcaddr=74.116.56.244, input
> interface=TenGigabitEthernet0/0/5
>
>
>
> The destination address is always one of our customer's ip addresses.  The
> source seems to be all over the place, mostly Russia, Korea, China or south
> east asia.  It's not really impacting anything at the moment, just rather
> annoying.
>
>
>
> Thanks
>
>
>
> Shawn
>
>
> Hi Shawn,
>
> we saw a lot of syslog messages like these and the targets are cisco
> devices, some of witch, according to the data sheets, are not even capable
> of ipsec.
>
> Cisco is punting some ESP traffic to control plane on ios and ios-xe
> devices, regardless of the configuration.
>
> Last week somebody on the internet started a campaign to scan and perhaps
> to exploit some zero day ipsec vulnerabilities.
>
>
> This is the list of ip addresses we saw: https://pastebin.com/vrLRai9Q
>
>
>
> --
> Best regards,
> Adrian Minta
>
>
>
>

Re: AS8003 mysteries

[Tom Beecher]

Didn't think there was much confusion about it at this point.

The DOD has the assignments for the space, they can announce it whenever
they want, even if it's from a shell ASN.

On Wed, Nov 8, 2023 at 4:52 PM Dave Taht  wrote:

> Anyone have an update as to where this effort, announcing qute a bit
> of usa government space, stands?
>
> https://www.kentik.com/blog/the-mystery-of-as8003/
> --
> Oct 30:
> https://netdevconf.info/0x17/news/the-maestro-and-the-music-bof.html
> Dave Täht CSO, LibreQos
>

Re: Charter DNS servers returning malware filtered IP addresses

[Tom Beecher]

>
> DNS isn’t the right place to attack this, IMHO.
>
...

> I’ve seen plenty of situations where the filters were just plain wrong and
> if the end user didn’t actively choose that filtration, the target site may
> be victimized without anyone knowing where to go to complain.


Not much different from IP Geolocation. Probably not the right solution to
many things, but people do it anyways., often causing problems that people
don't know where to go to complain.


On Fri, Oct 27, 2023 at 10:14 PM Owen DeLong via NANOG 
wrote:

> >> DNS isn’t the right place to attack this, IMHO.
> >
> > Why not (apart from a purity argument), and where should it happen
> instead? As others pointed out, network operators have a vested interest in
> protecting their customers from becoming victims to malware.
>
>
> Takedowns of the hostile target sites.
>
> You dismiss the purity argument, but IMHO, there’s merit to the purity
> argument.
>
> Any such DNS filtration, if provided, should be provided on an opt-in
> basis, not as a default.
>
> I’ve seen plenty of situations where the filters were just plain wrong and
> if the end user didn’t actively choose that filtration, the target site may
> be victimized without anyone knowing where to go to complain.
>
> Owen
>
>

Re: Pulling of Network Maps

[Tom Beecher]

>
> If it's too hard for me to figure out where you are, you just plain won't
> get the sale.


My experience with maps over the last decade tells me that even most
vendors don't actually know where they are. :)

On Thu, Oct 26, 2023 at 12:18 PM Mike Hammett  wrote:

> Has anyone else noticed a trend of some network operators that previously
> offered street-level detailed maps, not only upon request, but also posted
> publicly have started to only provide them upon quotes?
>
> Not even the popular online mapping services have
> current-enough-to-be-useful maps.
>
> The claim is that it's proprietary. A) It wasn't before and B) No it
> isn't. Everything you've ever done is a FOIA request or 811 design ticket
> away.
>
> I'm not sure how this helps the companies. It certainly makes it harder
> for me trying to piece networks together when they won't tell me where they
> are until I give them A and Z locations. If it's too hard for me to figure
> out where you are, you just plain won't get the sale.
>
>
>
> -
> Mike Hammett
> Intelligent Computing Solutions
> http://www.ics-il.com
>
> Midwest-IX
> http://www.midwest-ix.com
>

Re: RPKI unknown for superprefixes of existing ROA ?

[Tom Beecher]

>
> He’s announcing all 4 /24s
>

That's not what was described as the original situation.

  Operator has prefix 1.2.4/22, but announce only 1.2.5/24 and 1.2.6/24,
> with appropriate ROAs. To avoid abuse of 1.2.4/24 and 1.2.7/24, they also
> make a ROA for 1.2.4/22 with AS 0. Attacker now announces 1.2.0/20, and
> uses IPs in 1.2.4/24 and 1.2.7/24 to send spam etc.




On Tue, Oct 24, 2023 at 8:27 PM Owen DeLong  wrote:

> The covering /20 isn’t his to announce… He has a /22. He’s announcing all
> 4 /24s, and may not have a legitimate place to announce the covering /22,
> which wouldn’t help in this case anyway.
>
> So I’m not sure why you think that’s a solution.
>
> Owen
>
>
> On Oct 22, 2023, at 10:45, Tom Beecher  wrote:
>
> Look again, Tom. This is an attack vector using a LESS specific route. The
>> /22 gets discarded, but a covering /0-/21 would not.
>>
>
> Yes. And reliant on the operator doing something exceptionally not smart
> to begin with.  Relying on an AS0 ROA alone and not actually announcing the
> covering prefix as well isn't a good thing to do.
>
> On Sun, Oct 22, 2023 at 1:39 PM Owen DeLong  wrote:
>
>> Look again, Tom. This is an attack vector using a LESS specific route.
>> The /22 gets discarded, but a covering /0-/21 would not.
>>
>> Owen
>>
>> On Oct 22, 2023, at 10:06, Tom Beecher  wrote:
>>
>> 
>>
>>> And is it your belief that this addresses the described attack vector?
>>> AFAICT, it does not.
>>>
>>
>> Quoting myself :
>>
>> WITH the assertion that all routers in the routing domain are RPKI
>>> enabled, and discarding RPKI INVALIDs.
>>>
>>
>>  In the mixed RPKI / non-RPKI environment of today's internet, no it
>> doesn't. This does not mean that RPKI is deficient, or the AS 0 ROA doesn't
>> work as intended, as was stated.
>>
>>
>>
>> On Sun, Oct 22, 2023 at 12:57 PM William Herrin  wrote:
>>
>>> On Sun, Oct 22, 2023 at 9:38 AM Tom Beecher  wrote:
>>> >> He's saying that someone could come along and advertise 0.0.0.0/1 and
>>> >> 128.0.0.0/1 and by doing so they'd hijack every unrouted address
>>> block
>>> >> regardless of the block's ROA.
>>> >>
>>> >> RPKI is unable to address this attack vector.
>>> >
>>> >
>>> > https://www.rfc-editor.org/rfc/rfc6483
>>> >
>>> > Section 4
>>> >>
>>> >>
>>> >> A ROA with a subject of AS 0 (AS 0 ROA) is an attestation by the
>>> >> holder of a prefix that the prefix described in the ROA, and any more
>>> >> specific prefix, should not be used in a routing context.
>>>
>>> And is it your belief that this addresses the described attack vector?
>>> AFAICT, it does not.
>>>
>>> Regards,
>>> Bill Herrin
>>>
>>>
>>> --
>>> William Herrin
>>> b...@herrin.us
>>> https://bill.herrin.us/
>>>
>>
>

Re: RPKI unknown for superprefixes of existing ROA ?

[Tom Beecher]

>
> Basically, I guess, it means that the AS 0 solution shouldn't be used, at
> least not usually.
>

It's like everything else. Understand what the tools do and what they don't
do, and use them appropriately.

On Sun, Oct 22, 2023 at 2:21 PM Amir Herzberg  wrote:

> I agree that a good, sensible defense would be to simply announce your
> entire address block, e.g., in the example, your entire /22 (with a ROA to
> your ASN), and filter the traffic to the unused prefixes. Basically, I
> guess, it means that the AS 0 solution shouldn't be used, at least not
> usually. I wonder if anyone is using it , in fact. It would be nice to know
> if someone has the data handy.
>
> Thanks! Amir
> --
> Amir Herzberg
>
> Comcast professor of Security Innovations, Computer Science and
> Engineering, University of Connecticut
> Homepage: https://sites.google.com/site/amirherzberg/home
> `Applied Introduction to Cryptography' textbook and lectures:
> https://sites.google.com/site/amirherzberg/cybersecurity
>
>
>
>
> On Sun, Oct 22, 2023 at 1:50 PM Tom Beecher  wrote:
>
>> Look again, Tom. This is an attack vector using a LESS specific route.
>>> The /22 gets discarded, but a covering /0-/21 would not.
>>>
>>
>> Yes. And reliant on the operator doing something exceptionally not smart
>> to begin with.  Relying on an AS0 ROA alone and not actually announcing the
>> covering prefix as well isn't a good thing to do.
>>
>> On Sun, Oct 22, 2023 at 1:39 PM Owen DeLong  wrote:
>>
>>> Look again, Tom. This is an attack vector using a LESS specific route.
>>> The /22 gets discarded, but a covering /0-/21 would not.
>>>
>>> Owen
>>>
>>> On Oct 22, 2023, at 10:06, Tom Beecher  wrote:
>>>
>>> 
>>>
>>>> And is it your belief that this addresses the described attack vector?
>>>> AFAICT, it does not.
>>>>
>>>
>>> Quoting myself :
>>>
>>> WITH the assertion that all routers in the routing domain are RPKI
>>>> enabled, and discarding RPKI INVALIDs.
>>>>
>>>
>>>  In the mixed RPKI / non-RPKI environment of today's internet, no it
>>> doesn't. This does not mean that RPKI is deficient, or the AS 0 ROA doesn't
>>> work as intended, as was stated.
>>>
>>>
>>>
>>> On Sun, Oct 22, 2023 at 12:57 PM William Herrin  wrote:
>>>
>>>> On Sun, Oct 22, 2023 at 9:38 AM Tom Beecher  wrote:
>>>> >> He's saying that someone could come along and advertise 0.0.0.0/1
>>>> and
>>>> >> 128.0.0.0/1 and by doing so they'd hijack every unrouted address
>>>> block
>>>> >> regardless of the block's ROA.
>>>> >>
>>>> >> RPKI is unable to address this attack vector.
>>>> >
>>>> >
>>>> > https://www.rfc-editor.org/rfc/rfc6483
>>>> >
>>>> > Section 4
>>>> >>
>>>> >>
>>>> >> A ROA with a subject of AS 0 (AS 0 ROA) is an attestation by the
>>>> >> holder of a prefix that the prefix described in the ROA, and any more
>>>> >> specific prefix, should not be used in a routing context.
>>>>
>>>> And is it your belief that this addresses the described attack vector?
>>>> AFAICT, it does not.
>>>>
>>>> Regards,
>>>> Bill Herrin
>>>>
>>>>
>>>> --
>>>> William Herrin
>>>> b...@herrin.us
>>>> https://bill.herrin.us/
>>>>
>>>