Re: puck not responding

[Daniel Marks via NANOG]

We’re getting rocked by storms here in Michigan, could be related.

Sent from my iPhone

> On Feb 28, 2024, at 01:22, Hank Nussbacher  wrote:
> 
> 
> 

Re: Why are paper LOAs still used?

[Daniel Marks via NANOG]

Highly anecdotal, but we’ve always refused to provide them, and they’ve always 
set it up without an LOA.

YMMV since we negotiate larger contracts, but we’ve only ever been asked maybe 
twice? Both times they admitted they had no idea why they asked for it, so it 
just seems like some process they forgot to get rid of.

-Dan 

> On Feb 26, 2024, at 13:59, 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: IPv6 uptake (was: The Reg does 240/4)

[Daniel Marks via NANOG]

> a lot of folks
> making statements about network security on this list don't appear to
> grasp it.

If your network is secure, it isn’t even possible to “accidentally” open 
inbound ports in the first place. You either allow it to happen or you don’t 
via security policy, anything else means your “security” relies on humans not 
making a mistake, and that’s not security.

Using NAT as a “line of defense” means you implicitly don’t trust your 
authorization system, which means you don't actually have a security posture to 
begin with.

Using the same logic, you might as well go buy another firewall to put in front 
of your actual Firewall just in case you accidentally misconfigure it. Notice 
how you’re not actually securing anything, you’re putting a band aid on your 
insecure process.

-Dan

> On Feb 16, 2024, at 18:04, William Herrin  wrote:
> 
> On Fri, Feb 16, 2024 at 2:19 PM Jay R. Ashworth  wrote:
>>> 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.
> 
> Hi Jay,
> 
> Every firewall does that. What NAT does above and beyond is place
> control of what internal nodes are -addressable- from the outside in
> the hands of the people inside -- so that most of the common mistakes
> with firewall configuration don't cause the internal hosts to -become-
> accessible.
> 
> The distinction doesn't seem that subtle to me, but a lot of folks
> making statements about network security on this list don't appear to
> grasp it.
> 
> Regards,
> Bill Herrin
> 
> 
> --
> William Herrin
> b...@herrin.us
> https://bill.herrin.us/

Re: IRR information & BYOIP (Bring Your Own IP) with Cloud Providers

[Daniel Marks via NANOG]

> At least that's how the AWS offering works.


AWS allows you to broadcast your own ASN when you BYOIP: 
https://aws.amazon.com/about-aws/whats-new/2023/11/amazon-vpc-ip-address-manager-bring-your-own-asn-aws/

-Dan

> On Jan 22, 2024, at 16:37, William Herrin  wrote:
> 
> On Fri, Jan 19, 2024 at 1:55 PM Owen DeLong via NANOG  
> wrote:
>> Sounds like you’ve got a weird mix of route origination. Why wouldn’t you 
>> advertise to Google via BGP and have your prefix originate from your own ASN?
> 
> Big Cloud byoip doesn't generally work that way. You register the
> addresses in their portal and they handle everything else with the
> expectation that their AS is the sole origin for the prefix in
> question. At least that's how the AWS offering works. I presume GCP is
> the same. They're not acting as a general-purpose ISP.
> 
> Regards,
> Bill Herrin
> 
> --
> William Herrin
> b...@herrin.us
> https://bill.herrin.us/

Re: Contact at GoDaddy domains

[Daniel Marks via NANOG]

Sending a letter to their legal department has always worked to get any issue solved for us, that’s pretty much the only success we’ve ever had with escalations before we promptly move the domain as far away from them as possible.Sent from my iPhoneOn Jan 15, 2024, at 11:08, Greg Joosse - MySupport IT  wrote:Hoping someone has a contact at GoDaddy (Domains) as I have a big client with a clientHold 30 day suspension and their support doesn't seem to know what this means.Have spend 7hrs and have got nowhere. Failing this, is it possible to transfer a domain with this status?Cheers,Greg


This electronic message together with any attachments is for exclusive and confidential use of the intended recipient(s).  If you are not the intended recipient, any use, disclosure or copying of this material is unauthorised and prohibited. If you have received this message in error, please notify i...@mysupport.com.au by return e-mail immediately and delete the message from your computer without making any copies.

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

[Daniel Marks via NANOG]

Yea I’d like to see mandated IPv6 if ISPs want government money, around here an 
IPv4 only ISP won a government contract a while back for res fiber deployment 
and the last I heard from an acquaintance I spoke to over there they are 
planning to stuff the entire city behind a /24 with no upcoming plans to enable 
v6 (but of course you can get your own IP if you pay more).

I’m not a conspiracy theorist but sometimes it feels like some smaller ISPs are 
intentionally not deploying v6 so they can get customers to upgrade to more 
expensive plans for the luxury of *checks notes* not getting rate limited. 

Sent from my iPhone

> On Dec 1, 2023, at 15:41, William Herrin  wrote:
> 
> On Thu, Nov 30, 2023 at 4:55 PM Dave Taht  wrote:
>> https://docs.google.com/document/d/19ADByjakzQXCj9Re_pUvrb5Qe5OK-QmhlYRLMBY4vH4/edit
>> 
>> Comments (and cites) welcomed also! The text is still somewhat in flux...
> 
> Hi Dave,
> 
> You start off with a decent thesis - beyond 100mbps there really isn't
> any difference in capability, not for residential use. Just a
> difference in how quickly some tasks complete. It's not like the
> difference between 768kbps and 10 mbps where one does streaming video
> and conferencing while the other does not.
> 
> But then you get lost in latency. Latency is important but it's only
> one in a laundry list of things that make the difference between
> quality and trash in Internet services.
> 
> * Packet loss.
> 
> * Service outages. I have a buddy whose phone line has been out for
> days four times this year. His ILEC neither wants to maintain the
> copper lines nor install fiber that deep in the woods, so they keep
> doing mediocre repairs to the infrastructure that don't hold up.
> 
> * Incomplete connectivity (e.g. Cogent and IPv6).
> 
> Personally, I'd love to see rulemaking to the effect that only folks
> with -open- peering policies are eligible for government funds and
> contracts. But that's my pet peeve, like latency is yours. And if I
> pitch that, it'll rightly be seen as a pet issue.
> 
> Regards,
> Bill Herrin
> 
> 
> 
> --
> William Herrin
> b...@herrin.us
> https://bill.herrin.us/

Re: DoD contact

[Daniel Marks via NANOG]

Might not be helpful to everyone here, but if you are American you can go through your US representative. I’ve escalated an issue with a US gov network exactly once for a v6 issue through my senator and I got an email back from the correct team 2 days later, so YMMV.-Dan MarksOn Nov 21, 2023, at 10:08, Scott Q.  wrote:



Can anyone recommend a preferred method for contacting the network folks at the DoD ?It seems they blanket banned large swaths of our upstream provider ( Aptum AS 13768 ) which includes all of our subnets as well.We can't connect to any IP that they manage which includes DNS resolution for .mil , mail service, etc.I tried reaching out ( and Aptum as well ) to disa.columbus.ns.mbx.hostmaster-dod-...@mail.mil  from an external address and although the e-mail didn't bounce, we also didn't receive any answer for a few days now.Is there another way to get in touch with them ?Thanks!Scott

Re: Any interpol contact

[Daniel Marks via NANOG]

Interpol will never reach out to you, your local federal police liaison will 
contact you (in the US, that’s your regional FBI office) and ask you to contact 
them directly or by calling the main number and giving them a case number from 
the email.

https://www.interpol.int/en/What-you-can-do/Stay-safe/Beware-of-scams-using-INTERPOL-s-name
Beware of scams using INTERPOL’s name
interpol.int


> On Oct 30, 2023, at 08:23, Lu Heng  wrote:
> 
> Hi
> 
> We receive some network abuse request allegedly from Interpol, any contact 
> from Interpol would be appreciated.

Re: jon postel

[Daniel Marks via NANOG]

I wasn’t even born yet when he died, but as humans we are lucky to have had 
someone like him, along with a great many other folks along side him. One of my 
professors at Michigan (his name eludes me for some reason) always had a great 
many stories about him and other folks in that time period, must have been a 
crazy thing to watch unfold in real time. I wonder if he knew it would have 
become what it is today.

> On Oct 16, 2023, at 17:13, Randy Bush  wrote:
> 
> 25 years ago, jon postel died.  we stand on the shoulders of jon and
> others, a number of whom died in october.  not a cheering month for
> old timers.
> 
> randy

Re: AT Business Center completely broken for months - is it the norm?

[Daniel Marks via NANOG]

This has been the case with most AT systems I’ve had to use in the past 5 
years, FirstNet is even worse. As others suggested in trying different 
browsers, I found that a lot of (especially older) corporate firewalls just 
seem to hate AT websites and flipping on a VPN to  tends to 
resolve most of my issues.

-Dan

> On Oct 9, 2023, at 23:41, Mirai Azayaka  wrote:
> 
> Hi NANOG,
> 
> Maybe this topic is better suited for the complaint department of AT
> but I just want to confirm if it's just me or it's just AT
> 
> So I'm a new customer of AT's DIA network and I haven't been able to
> make a payment since day one. (And it has been several months.) Just
> wondering if a completely broken internal billing system is normal...
> I only have limited experience with Hurricane Electric and Equinix
> before. Wondering if Verizon or Comcast is also broken like AT Here
> are the issues I had with their system:
> - Clicking random links around the portal will give you HTTP 400
> errors, sometimes.
> - I'm unable to add payment methods even after following the payment
> tutorial exactly. The portal consistently gives HTTP 413 errors.
> - Live chat doesn't work at all. Clicking the button returns HTTP 404
> in my debugging console.
> - Extremely slow for some tasks which may result in a HTTP 408.
> 
> The system feels like a collection of HTTP error codes... How can it
> be so broken? Are other ISP's internal billing systems broken like
> this? Looking for anecdotes / experiences.
> 
> Azayaka

Re: MX204 Virtual Chassis Setup

[Daniel Marks via NANOG]

(Enterprise AS for context)

This hasn’t been my experience in the US, however we mostly deal in tier 2 
markets (I.e. Detroit, Miami, Dallas, etc…) and we have plenty of 40G private 
interconnects. I don’t doubt 40G is going away, I’ve just never had trouble 
using it around here.

The only time we’ve been asked to run something other than 40G was because we 
like to run our ports very hot (latency insensitive traffic) and some networks 
do not tolerate consistently high utilization of their ports.

Different story in Japan, it’s 100G+ or nothing. You just have to find someone 
willing to peer with you in the first place…

Sent from my iPhone

> On Aug 27, 2023, at 23:43, Mark Tinka  wrote:
>  
> 
> On 8/28/23 03:05, Mike Hammett wrote:
>> Well, or they simply found a potential deal on hardware that came with 40 
>> gig ports. 40 gigs is still a lot of bits to a lot of people.
> 
> For internal use, sure.
> 
> But when connecting to another AS, the chances of them supporting 40Gbps in 
> one or more places is inconsistent to slim.
> 
> Exchange points may be an exception.
> 
> Mark.


smime.p7s
Description: S/MIME cryptographic signature

Re: AWS hosted sites like slack unreachable

[Daniel Marks via NANOG]

You didn’t specify anything that would be useful to narrow down the issue (i.e. 
location, asn, error codes, etc) - We had a somewhat similar issue at DET-IX 
with routes to us-east-1 and us-east-2 seeing a lot of packet loss, but AWS 
eventually just de-peered the exchange entirely since it was an issue with 
their equipment.

> On Jul 20, 2023, at 5:17 PM, Margi Varia via NANOG  wrote:
> 
> Hi Nanog,
> 
> We are seeing this weird issue in one part of the network. Customers in one 
> public subnet are not able to reach certain websites suddenly which are 
> hosted in AWS like slack.com , bill.com 
> ..
> 
> We changed the subnet to new one and issue resolved, after 48 hours, we have 
> the same issue again. We are not AWS customer, so can't call them, but what 
> are our options? 
> 
> Thanks,
> Margi



smime.p7s
Description: S/MIME cryptographic signature

Re: 1299 capacity constraints

[Daniel Marks via NANOG]

Same in the continental US via Chicago, no widespread issues here but we egress 
less than 100gbps via 1299 so we’re small potatoes. We sometimes notice QUIC 
streams to 7018 having trouble, but nothing worth complaining about yet.

Sent from my iPhone

> On Jul 14, 2023, at 12:15, Mark Tinka  wrote:
> 
>  
> 
>> On 7/14/23 13:55, Drew Weaver wrote:
>> 
>> Has anyone else been having near constant issues with traffic transiting AS 
>> 1299 being lost due to their links being oversubscribed?
> 
> We pick them up in London, so we haven't seen that. But we also have a 
> healthy mix of transit providers + peering, so we may not be as exposed.
> 
> YMMV based on where you pick them up and what other options you have.
> 
> Mark.


smime.p7s
Description: S/MIME cryptographic signature

Re: 429 Too Many Requests

[Daniel Marks via NANOG]

Have you reached out to Fastly? They’re pretty quick to throttle in my experience.Sent from my iPhoneOn Jun 23, 2023, at 00:13, Joshua Pool via NANOG  wrote:Anyone ever had to deal with etsy.com returning 429 for all subnets? We have very little traffic going to etsy at any given moment but every prefix we have returns a 429 Too Many Requests error when trying to get to etsy.com. Regards,               Josh


smime.p7s
Description: S/MIME cryptographic signature

Re: Treasurydirect.gov unreachable over IPv6?

[Daniel Marks via NANOG]

You can utilize online (i.e. https://dnstools.ws/) or ISP looking glass 
tools to check for routing issues.


It's up for us via AS12129

On 5/17/2023 2:30 PM, holow29 wrote:
Is anyone able to reach treasurydirect.gov  
over IPv6? Unable to do so over Verizon Fios, and I'm not sure if it 
is a routing issue or an issue on Treasury's end.

Re: Spectrum networks IPv6 access issue

[Daniel Marks via NANOG]

My issue was just trying to convince Spectrum to look into the problem in the 
first place, I brought the Atlas probe receipts because it’s such a helpful 
tool, but wasn’t able to get through to anyone helpful (acct mgr, noc email, 
even the escalation list) until I started lighting fires filing FCC complaints 
and using social media (which thankfully worked).

Not sure how accurate it is (I hope it isn’t), but some of the techs I spoke to 
said a lot of the internal tooling for troubleshooting is incapable of dealing 
with IPv6, so they weren’t able to do things like run traceroutes to confirm 
what I was seeing. My guess is that this issue was caught in a catch-22 where 
they needed impossible to obtain proof on their end to escalate to a team who 
can actually deal with the issue.

Sucks for us folk who went all in on v6 only to find out not even the ISP can 
help us. 

-Daniel Marks

> On May 2, 2023, at 15:36, Jared Mauch  wrote:
> 
> 
> 
>> On May 2, 2023, at 2:43 PM, Daniel Marks via NANOG  wrote:
>> 
>> This has been “resolved", I finally got through to some awesome engineer at 
>> Spectrum who has rerouted traffic while they work with their hardware vendor 
>> (thanks Jake):
> 
> 
> One of the tools that I’ve used in the past is the RIPE Atlas service to 
> measure these things.  It’s helped me isolate IP space reachability issues 
> for new announcements, because you can get enough of a random sample of hosts 
> to isolate things, and enough data about that endpoint to launch follow-up 
> measurements.
> 
> - Jared


smime.p7s
Description: S/MIME cryptographic signature

Re: Spectrum networks IPv6 access issue

[Daniel Marks via NANOG]

This has been “resolved", I finally got through to some awesome engineer at 
Spectrum who has rerouted traffic while they work with their hardware vendor 
(thanks Jake):

 1  2605:6000:0:8::f:7acc (2605:6000:0:8::f:7acc)  0.372 ms  0.323 ms  0.282 ms
 2  ae15.ARTNTXAF02H.chtrse.com (2605:6000:0:4::f:87e9)  4.002 ms  3.977 ms  
10.884 ms
 3  * * *
 4  lag-23.mcr11dllbtxlb.netops.charter.com (2605:6000:0:4::2:1e)  1.464 ms  
1.574 ms  1.560 ms
 5  * * *
 6  * *
lag-26.hstqtx0209w-bcr00.netops.charter.com (2001:1998:0:4::528)  6.351 ms
 7  * * *
 8  lag-0.pr2.atl20.netops.charter.com (2001:1998:0:4::51f)  18.577 ms  18.572 
ms  18.428 ms
 9  * * *
10  e0-36.core2.bna1.he.net (2001:470:0:429::2)  32.553 ms  32.720 ms  32.563 ms
11  * * *
12  * * *
13  equinix-ix.dfw2.packet.net (2001:504:0:5:0:5:4825:1)  24.591 ms  24.553 ms  
24.604 ms
14  * * *
15  * * *
16  dfw.source.kernel.org (2604:1380:4641:c500::1)  24.423 ms  26.020 ms  
24.415 ms

> On Apr 28, 2023, at 11:35 AM, Sam Thomas  wrote:
> 
> Actual data from a Spectrum residential customer in DFW.
> 
> First, IPv4:
> 
>  trace dfw.source.kernel.org
> traceroute to dfw.source.kernel.org (139.178.84.217), 64 hops max, 40
> byte packets
> 1  my.router  0.389 ms  0.350 ms  0.292 ms
> 2  142-254-130-077.inf.spectrum.com (142.254.130.77)  8.423 ms  8.408
> ms  8.080 ms
> 3  lag-63.artrtx2801h.netops.charter.com (24.28.88.17)  27.167 ms
> 25.065 ms  21.977 ms
> 4  lag-22.artntxaf01r.netops.charter.com (24.175.49.233)  10.718 ms
> 10.083 ms  15.886 ms
> 5  lag-23.mcr11crtntxjt.netops.charter.com (24.175.36.224)  13.386 ms
> 11.560 ms  11.297 ms
> 6  lag-21.rcr01dllatx37.netops.charter.com (24.175.49.0)  11.339 ms
>lag-28.rcr01dllatx37.netops.charter.com (24.175.33.246)  11.904 ms
> 128.186 ms
> 7  lag-414.dllstx976iw-bcr00.netops.charter.com (66.109.6.52)  12.603 ms
>lag-14.dllstx976iw-bcr00.netops.charter.com (66.109.6.88)  12.172 ms
>lag-414.dllstx976iw-bcr00.netops.charter.com (66.109.6.52)  12.299 ms
> 8  lag-302.pr3.dfw10.netops.charter.com (209.18.43.77)  21.570 ms
>lag-0.pr3.dfw10.netops.charter.com (66.109.5.121)  11.763 ms
>lag-302.pr3.dfw10.netops.charter.com (209.18.43.77)  12.182 ms
> 9  dls-b23-link.ip.twelve99.net (62.115.156.208)  11.515 ms *  11.706 ms
> 10  packethost-ic-369414.ip.twelve99-cust.net (213.248.72.3)  11.870
> ms  30.246 ms  18.199 ms
> 11  * * *
> 12  * * *
> 13  dfw.source.kernel.org (139.178.84.217)  12.021 ms  12.076 ms  11.922 ms
> 
> ping dfw.source.kernel.org
> PING dfw.source.kernel.org (139.178.84.217): 56 data bytes
> 64 bytes from 139.178.84.217: icmp_seq=0 ttl=50 time=11.590 ms
> 64 bytes from 139.178.84.217: icmp_seq=1 ttl=50 time=11.785 ms
> 
> IPv6:
> 
>  trace6 dfw.source.kernel.org
> traceroute6 to dfw.source.kernel.org (2604:1380:4641:c500::1) from
> 2603:8080:REDACTED, 64 hops max, 20 byte packets
> 1  2603-8080-REDACTED.res6.spectrum.com  0.404 ms  0.340 ms  0.322 ms
> 2  2603-90c5-0003-000e----0001.inf6.spectrum.com  10.308
> ms  7.901 ms  9.902 ms
> 3  lag-63.artrtx2801h.netops.charter.com  17.008 ms  10.523 ms  11.077 ms
> 4  lag-22.artntxaf01r.netops.charter.com  14.638 ms * *
> 5  lag-23.mcr11crtntxjt.netops.charter.com  11.090 ms  11.612 ms  12.234 ms
> 6  * * *
> 7  lag-414.dllstx976iw-bcr00.netops.charter.com  12.572 ms *
>lag-24.dllstx976iw-bcr00.netops.charter.com  12.160 ms
> 8  * * *
> 9  * * *
> 10  * * *
> 11  * * *
> 12  * * *
> 13  * * *
> 14  * * *
> 15  * * *
> 16  * * *
> 17  * * *
> 18  * * *
> 19  *^C
> 
> ping6 dfw.source.kernel.org
> PING6(56=40+8+8 bytes) 2603:8080:REDACTED --> 2604:1380:4641:c500::1
> ^C
> --- dfw.source.kernel.org ping6 statistics ---
> 5 packets transmitted, 0 packets received, 100.0% packet loss
> 
> I have a Linode VM in Dallas that I also can't get to via IPv6.
> Traffic appears to take the same path for IPv4.
> 
> On Wed, Apr 26, 2023 at 10:50 AM Tom Rini  wrote:
>> 
>> Hey all,
>> 
>> I'm posting this here in hopes of getting the attention of someone that
>> can get this issue resolved, or at least an internal ticket filed. I've
>> tried the customer-facing tech support and not been able to get such a
>> thing done.
>> 
>> In short, from within Spectrum's US IPv6 network (verified in both North
>> Carolina and Ohio), dfw.source.kernel.org (2604:1380:4641:c500::1) is
>> unreachable and connections time out. This site is otherwise fine and
>> globally accessible via IPv6, tested on both Qwest and T-Mobile hosted
>> systems.  This is a regression from some time in early April this year.
>> 
>> --
>> Tom



smime.p7s
Description: S/MIME cryptographic signature

Re: Spectrum networks IPv6 access issue

[Daniel Marks via NANOG]

We’ve been having IPv6 issues for weeks in Texas on Spectrum, we have an 
Enterprise support ticket open on our IP transit circuits but I’ve seen no real 
movement.

Our issue is being tracked internally as INC26440632, but I believe it’s 
specific to the DFW area.

Daniel Marks
d...@nielmarks.com

> On Apr 26, 2023, at 11:52, Tom Rini  wrote:
> Hey all,
> 
> I'm posting this here in hopes of getting the attention of someone that
> can get this issue resolved, or at least an internal ticket filed. I've
> tried the customer-facing tech support and not been able to get such a
> thing done.
> 
> In short, from within Spectrum's US IPv6 network (verified in both North
> Carolina and Ohio), dfw.source.kernel.org (2604:1380:4641:c500::1) is
> unreachable and connections time out. This site is otherwise fine and
> globally accessible via IPv6, tested on both Qwest and T-Mobile hosted
> systems.  This is a regression from some time in early April this year.
> 
> -- 
> Tom


smime.p7s
Description: S/MIME cryptographic signature

Re: (IETF I-D): Implications of IPv6 Addressing on Security Operations (Fwd: New Version Notification for draft-gont-opsec-ipv6-addressing-00.txt)

[Daniel Marks via NANOG]

Anecdotal but I've seen hacked AWS accounts with Cloudformation scripts 
to create and destroy lots of tiny instances to rotate through IPv4 
addresses. Being able to rotate through IP addresses is not a new thing, 
I'm sure we all have networks in mind when we think of garbage/malicious 
traffic just over IPv4 alone.


Internally at my company (corp network that went all in on IPv6), we 
have a script that looks through logs and will ban an entire /64 for a 
period of time if it has more than a few banned IP addresses in the same 
subnet (I think ~10 /128s is a 30 minute ban, but we're still tuning it).


There are some strange implementations of IPv6 that end up having a lot 
of dissociated users grouped together in a /64 (i.e. Linode, AT 
Wireless, etc) which makes me hesitant to implement automatic /64 bans 
for 1 or 2 spammy IP addresses. At one point we accidentally banned a 
large portion of US users on AT when we banned 2600:387:f:10::/64


On 2/6/2023 10:05 PM, William Herrin wrote:

On Mon, Feb 6, 2023 at 6:43 PM Fernando Gont  wrote:

On 6/2/23 20:39, Owen DeLong wrote:

After all, they’re only collecting addresses to ban at the rate they’re 
actually being used to send packets.

Yeah, but the whole point of banning is that the banned address is
actually used by an attacker subsequently,

You both have valuable points here. Listen to each other.

On the one hand, sophisticated attackers already scatter attacks
between source addresses to evade protection software. Attackers who
don't have control over their computer's IP address do not. This is
not new and IPv6 does not really change that picture.

On the other hand, there are so many addresses in a /64 that an
attacker can literally use a fresh one for each and every probe he
sends. Without a process for advancing the /128 ban to a /64 ban (and
releasing it once activity stops), reactive firewalls are likely to
become less and less effective.

Regards,
Bill Herrin

Re: Increasing problems with geolocation/IPv4 access

[Daniel Marks via NANOG]

Even worse, some don’t even bother taking you off a list or correcting their 
records. In these cases I’ve had great luck once our lawyers get involved, but 
that really only works for US-based companies.

Pretty sure the last company who used our IP space was just wrecking the 
internet for fun, took a while to get off of some large blocklists. At least it 
was an easy business justification to rapidly deploy IPv6…

Sent from my iPhone

> On Jan 20, 2023, at 19:50, Mike Lyon  wrote:
> 
> I’ve come to the conclusion that the geo-ip feed companies don’t give a damn 
> about the legitimacy of their information and don’t research any of it. They 
> just wait for the end user to complain to make the change.
> 
> Had one today, in fact.
> 
> They’re lame.
> 
> -Mike
> 
> 
> 
>> On Jan 20, 2023, at 16:33, Jared Mauch  wrote:
>> 
>> I’ve been seeing an increasing problem with IP space not having the ability 
>> to be used due to the behaviors of either geolocation or worse, people 
>> blocking IP space after it’s been in-use for a period of time.
>> 
>> Before I go back to someone at ARIN and say “your shiny unused 4.10 IP 
>> space” is non-functional and am at a place where I need to 
>> start/restart/respawn the timer, I have a few questions for people:
>> 
>> 1) Do you see 23.138.114.0/24 in any feeds from a security provider that say 
>> it can/should be blocked?  If so, I’d love to hear from you to track this 
>> down.  Over the new year we had some local schools start to block this IP 
>> space.
>> 
>> 2) many companies have geolocation feeds and services that exist and pull in 
>> data.  The reputable people are easy to find, there are those that are 
>> problematic from time-to-time (I had a few customers leave Sling due to the 
>> issues with that service).
>> 
>> 3) Have you had similar issues?  How are you chasing all the issues?  We’ve 
>> seen things from everything works except uploading check images to banks, to 
>> other financial service companies block the space our customers are in.  If 
>> we move them to another range this solves the problem.
>> 
>> 4) We do IPv6, these places aren’t IPv6 modern at all, so that’s no help.
>> 
>> 5) IRR+geofeed are published of course.  I’m thinking that it might be 
>> worthwhile that IP space have published placeholders when it’s well 
>> understood, eg: ARIN 4.9 space, I can predict what our next allocation would 
>> be, it would be great to have it be pre-warmed. 
>> 
>> I’ve only seen a few complaints against all our IP space over time, so I 
>> don’t think there’s anything malicious coming from the IP space to justify 
>> it, but it’s also possible they didn’t make it through.
>> 
>> If you’re with the FKA Savvis side, can you also ping me, I’d like to see if 
>> you can reach out to our most recent complaint source to see if we can find 
>> who is publishing this.  Same if you’re with Merit or the Michigan Statewide 
>> Educational Network - your teachers stopped being able to post to 
>> powerschool for their students over the new year break.  They’ve fed it up 
>> to their tech people towards the ISD.  Details available off-list.
>> 
>> Any insights are welcome, and as I said, I’d like to understand where the 
>> source list is as it starts out working then gradually breaks, so someone is 
>> publishing things and they are going out further.
>> 
>> - Jared


smime.p7s
Description: S/MIME cryptographic signature

RE: IERS ponders reverse leapsecond...

[Daniel Marks via NANOG]

This is why we've internally standardized on Leap smearing, an added benefit is 
that it keeps us in sync with Google and AWS who also smear time in the same 
way.

Daniel Marks
d...@nielmarks.com


--- Original Message ---
On Wednesday, August 3rd, 2022 at 11:33 AM, Matthew Huff  wrote:


> True,
>
> But it's hard enough to get developers to understand the need to code for 61 
> seconds in a minute, and now they would need to code for 59 seconds as well.
>
> If time systems simply skewed the time so that 60 seconds actually just took 
> 61 seconds or 59 seconds, there would be other issues, but coders wouldn't be 
> involved.
>
>
>
> -Original Message-
> From: NANOG nanog-bounces+mhuff=ox@nanog.org On Behalf Of Stephane 
> Bortzmeyer
>
> Sent: Wednesday, August 3, 2022 11:19 AM
> To: Jay Ashworth j...@baylink.com
>
> Cc: nanog@nanog.org
> Subject: Re: IERS ponders reverse leapsecond...
>
> On Wed, Aug 03, 2022 at 11:09:25AM -0400, Jay Ashworth j...@baylink.com wrote 
> a message of 32 lines which said:
>
> > General press loses its mind:
>
>
> Indeed, they seem not to know what they write about. "atomic time – the 
> universal way time is measured on Earth – may have to change" They don't even 
> know the difference between TAI and UTC.