Re: [External] Normal ARIN registration service fees for LRSA entrants after 31 Dec 2023 (was: Fwd: [arin-announce] Availability of the Legacy Fee Cap for New LRSA Entrants Ending as of 31 December 20

> On Sep 15, 2022, at 21:09 , Rubens Kuhl wrote: > > On Fri, Sep 16, 2022 at 11:55 AM William Herrin > wrote: >> >> On Thu, Sep 15, 2022 at 8:51 PM Rubens Kuhl wrote: >>> On Fri, Sep 16, 2022 at 10:56 AM William Herrin wrote: Well, I'm one of the people who'd pub

Re: [External] Normal ARIN registration service fees for LRSA entrants after 31 Dec 2023 (was: Fwd: [arin-announce] Availability of the Legacy Fee Cap for New LRSA Entrants Ending as of 31 December 20

> On Sep 15, 2022, at 22:04 , Rubens Kuhl wrote: > > On Fri, Sep 16, 2022 at 12:45 PM William Herrin > wrote: >> >> On Thu, Sep 15, 2022 at 9:09 PM Rubens Kuhl wrote: >>> On Fri, Sep 16, 2022 at 11:55 AM William Herrin wrote: No, the best option for me right now

Re: [External] Normal ARIN registration service fees for LRSA entrants after 31 Dec 2023 (was: Fwd: [arin-announce] Availability of the Legacy Fee Cap for New LRSA Entrants Ending as of 31 December 20

> On Sep 16, 2022, at 08:53 , John Curran wrote: > > Tom - > > It’s an artifact of our formation that we are presently providing services to > any customers absent any agreement > and while ARIN continues to do so (by providing basic services to legacy > customers), the long-term direction

Re: [External] Normal ARIN registration service fees for LRSA entrants after 31 Dec 2023

> On Sep 16, 2022, at 10:12 , John Curran wrote: > > >> On 16 Sep 2022, at 12:51 PM, Steve Noble wrote: >> >> I appreciate your response, I remember all of the discussions around this >> change and the positive/negative aspects of it, but it did not correct the >> disenfranchisement of AS

Re: [External] Normal ARIN registration service fees for LRSA entrants after 31 Dec 2023

> On Sep 16, 2022, at 10:37 , William Herrin wrote: > > On Fri, Sep 16, 2022 at 10:29 AM John Curran > wrote: >>> On 16 Sep 2022, at 1:22 PM, William Herrin wrote: >>> On Fri, Sep 16, 2022 at 10:12 AM John Curran wrote: Note - if the reason that you are paying "

Re: [External] Normal ARIN registration service fees for LRSA entrants after 31 Dec 2023

> On Sep 16, 2022, at 11:49 , John Curran wrote: > > >> On 16 Sep 2022, at 2:21 PM, Aaron Wendel wrote: >> >> I'm not trying to troll, this is a serious question: >> >> Is there a formal agreement that says that all legacy resources will receive >> free registry services forever and ever

Re: [External] Normal ARIN registration service fees for LRSA entrants after 31 Dec 2023 (was: Fwd: [arin-announce] Availability of the Legacy Fee Cap for New LRSA Entrants Ending as of 31 December 20

> On Sep 17, 2022, at 08:18 , Tom Beecher wrote: > > I would honestly love it if IANA was able to say "As of X date, all LEGACY > IPv4 allocations are transferred to the RIRs . Assignees will not change, but > will now need to comply with each RIRs policies." The first part of that statement

Re: [External] Normal ARIN registration service fees for LRSA entrants after 31 Dec 2023 (was: Fwd: [arin-announce] Availability of the Legacy Fee Cap for New LRSA Entrants Ending as of 31 December 20

> On Sep 18, 2022, at 11:38 , Alex Band wrote: > > > >> On 18 Sep 2022, at 20:17, Owen DeLong via NANOG wrote: >> >> >> >>> On Sep 15, 2022, at 22:04 , Rubens Kuhl wrote: >>> >>> On Fri, Sep 16, 2022 at 12:45 PM William Herrin

Re: Normal ARIN registration service fees for LRSA entrants after 31 Dec 2023 (was: Fwd: [arin-announce] Availability of the Legacy Fee Cap for New LRSA Entrants Ending as of 31 December 2023)

> On Sep 19, 2022, at 09:50, John Curran wrote: > >  >> On 19 Sep 2022, at 12:29 PM, William Herrin wrote: >> >>> On Mon, Sep 19, 2022 at 9:21 AM Tom Beecher wrote: >>> A bit of an exaggeration there. The RSA says that you are bound >>> by all current and future policies that come from the

Re: [External] Normal ARIN registration service fees for LRSA entrants after 31 Dec 2023

An important detail in the CI case is that there was no PDP based change in the policy text, AFRINIC simply suddenly contradicted their own prior statements and began (mid)interpreting their own governing documents to say things that they don’t actually say. Owen > On Sep 19, 2022, at 19:49,

Re: [External] Normal ARIN registration service fees for LRSA entrants after 31 Dec 2023

Why not publish such a table? It shouldn’t be a particularly difficult task and could prove rather enlightening. Owen > On Sep 19, 2022, at 20:09, John Curran wrote: > >  >>> On 19 Sep 2022, at 10:48 PM, John Gilmore wrote: >>> >>> John Curran wrote: >>> [challenges by legacy registran

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

There are most definitely a number of organizations that have /24s that are not part of a larger aggregate. If you don’t have a default route to some router that takes the full table on your behalf, then you will loose connectivity to/from those entities. Owen > On Oct 10, 2022, at 07:58 , Ed

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

This situation isn’t helped by RIR policies that require you to announce the aggregate in region even if the more specifics are scattered around the world. The whole territorial exclusivity game played by some RIRs may well cause more harm than good at this point. Yes, I realize this is a reve

Re: Understanding impact of RPKI and ROA on existing advertisements

RPKI/ROA is a way to cryptographically prove what someone needs to prepend if they want to hijack your addresses. Owen > On Oct 28, 2022, at 08:00, Samuel Jackson wrote: > > Hello, > I am new to RPKI/ROA and still learning about RPKI. From all my reading on > ARIN's documents I am not able t

Re: Understanding impact of RPKI and ROA on existing advertisements

, whichever comes first. Owen > On Nov 2, 2022, at 08:30, heasley wrote: > > Tue, Nov 01, 2022 at 06:24:50PM -0700, Owen DeLong via NANOG: >> RPKI/ROA is a way to cryptographically prove what someone needs to prepend >> if they want to hijack your addresses. > > Opera

Re: ipv4/25s and above

> >> Either you have lots of fallow ground or very few customers. > > A bit of both. Regarding the former, perhaps you should return some of that to AFRINIC as required in your RSA before throwing stones at other providers in the region. Owen

Re: ipv4/25s and above

> On Nov 18, 2022, at 03:44, Joe Maimon wrote: > > > > Mark Tinka wrote: >> >> >> On 11/17/22 19:55, Joe Maimon wrote: >> >>> >>> You could instead use a /31. >> >> We could, but many of our DIA customers have all manner of CPE's that may or >> may not support this. Having unique desig

Re: Random shower thought: GBIC with LC connector...

Unless you work for Intel or DEC in which case, it’s O0 DC. Owen > On Nov 15, 2022, at 08:20, Mel Beckman wrote: > > Oh. And it’s not “OCD”. It’s “CDO”, with letters in ascending sequence. :) > > -mel via cell > >> On Nov 15, 2022, at 8:18 AM, Mel Beckman wrote: >> >> No. GBIC stands for

Re: ipv4/25s and above

>> But see the crux above. If your RiR isnt frowning on such behavior then its >> poor strategy to implement it. > > I might have missed the part where RIR's tell me how to operate. Allow me to help: https://afrinic.net/ast/pdf/services/afrinic-rsa-en-201801.pdf afrinic-rsa-en-201801 PDF Docum

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

Much of India operates this way today. Owen > On Nov 21, 2022, at 15:06, Rubens Kuhl wrote: > > (forwarded to break thread since this is a different topic) > What's the group's current thought on emergence or prevalence of > IPv6-only hosts ? Will they exist soon, in some time or in a very lon

Re: Sites blocking ISP Addresses

To make matters worse, many sites use CDNs with Web Application Firewalls. The WAF is under control of the site, but many sites blindly implement the recommendations of the WAF provider. So this allows the site to blame the CDN because they blindly implement their recommendations, while the CDN

Re: Increasing problems with geolocation/IPv4 access

I will repeat what I have been saying since the first discussions of the concept of ip geo-location some decades ago… An IP address is not tied to any of the following: Location Person An IP address may be transiently tied to a host. The definition of transient in this case can

Re: Increasing problems with geolocation/IPv4 access

> What I’m actually looking for isn’t so much a soapbox but to find where the > [bad] data is coming from so it can be updated as appropriate. I’m also fine > with telling the customer to phone the service/bank/whatnot (which is what I > did in other cases and as much as I also personally disli

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

As long as they have a reasonable expiry process, it could work. After all, they’re only collecting addresses to ban at the rate they’re actually being used to send packets. While that’s nota. Completely effective throttle, as long as your expiry process can keep up and your TTL doesn’t exceed

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

> On Feb 6, 2023, at 18:43, Fernando Gont wrote: > > Hi, Owen, > > On 6/2/23 20:39, Owen DeLong wrote: >> As long as they have a reasonable expiry process, it could work. > > What, specifically? Banning /128s? Yes. > > >> After all, they’re only collecting addresses to ban at the rate th

Re: FCC Chair Rosenworcel Proposes to Investigate Impact of Data Caps

> On Jun 16, 2023, at 11:27, Mark Tinka wrote: > > > > On 6/16/23 18:41, Michael Thomas wrote: > >> Is 1.2 TB enough for a typical cord cutter? I just looked at mine and it >> looks to be about 300GB/month, but we may not be typical for your average >> family with kids, say. > > For resi

Re: FCC Chair Rosenworcel Proposes to Investigate Impact of Data Caps

> On Jun 16, 2023, at 13:16, Michael Thomas wrote: > > > On 6/16/23 1:09 PM, Mark Tinka wrote: >> >> >> On 6/16/23 21:19, Josh Luthman wrote: >>> Mark, >>> >>> In my world I constantly see people with 0 fixed internet options. Many of >>> these locations do not even have mobile coverage.

Re: Northern Virginia has had enough with data centers

> On Jun 23, 2023, at 18:04, Michael Thomas wrote: > >  >> On 6/23/23 4:01 PM, Delong.com via NANOG wrote: >> The electric grid complaints are about the demand on the grid making the >> entire region less stable and proposed construction of new high-voltage >> tower corridors for data cente

Re: IP range for lease

Karin,Opinions regarding leasing vary throughout the industry. In my opinion, since the shift to provider assigned addresses during the CIDR efforts in the mid 1990s, the majority of addresses have been leased in one form or another. The only thing novel here is the leasing of addresses indepen

Re: IP range for lease

> On Jul 10, 2023, at 10:22, John Curran wrote: > >> On Jul 5, 2023, at 10:06 PM, Owen DeLong via NANOG wrote: >> ... >> Opinions regarding leasing vary throughout the industry. In my opinion, >> since the shift to provider assigned addresses during the CIDR eff

Re: IP range for lease

> On Jul 11, 2023, at 09:04, John Curran wrote: > > >> On Jul 11, 2023, at 11:47 AM, Owen DeLong wrote: >> >> Actually, I couldn’t find anything in the NRPM which leads me to believe >> that there is any distinction in the documentation requirements for >> reassignment/reallocation regardl

Re: IP range for lease

> On Jul 11, 2023, at 10:02, William Herrin wrote: > > On Tue, Jul 11, 2023 at 8:47 AM Owen DeLong via NANOG wrote: >>> – Leasing of IP address blocks independent of connectivity is not >>> explicitly recognized in ARIN number resource policy (i.e. there is no &

Re: IP range for lease

> On Jul 11, 2023, at 09:52, John Curran wrote: > > > >> On Jul 11, 2023, at 12:40 PM, Owen DeLong wrote: >> >> >>> On Jul 11, 2023, at 09:04, John Curran wrote: >>> >>> ... >>> >>> Of course, further policy clarity (whether to make clear that it does apply >>> to non-connectivity reas

Re: JunOS config yacc grammar?

FWIW, I find the config archival on-commit to be a very useful feature. I use it with SCP. Sadly, neither J nor C support doing this with an SSH private key on the router, you have to use a password. J at least encrypts the password if you do it right (…”URL” password “plain-text”). Cisco does n

Re: AFRINIC placed in receivership

> On Sep 15, 2023, at 06:30, Noah wrote: > > > > On Fri, 15 Sept 2023, 15:53 John Curran, > wrote: >> Noah - >> >> Indeed, that was a less than ideal situation – but I will note that the >> technical advisor was sent away by the Receiver once the Receiver was >>

Re: maximum ipv4 bgp prefix length of /24 ?

Wouldn’t /48s be a better solution to this need? Owen > On Sep 28, 2023, at 14:25, VOLKAN SALİH wrote: > > hello, > > I believe, ISPs should also allow ipv4 prefixes with length between /25-/27 > instead of limiting maximum length to /24.. > > I also believe that RIRs and LIRs should alloca

Re: maximum ipv4 bgp prefix length of /24 ?

CIDR and aggregation in the early 1990s was developed in response to AGS+ routers falling over under the strain of the global size back then. Since then, IPv4 has been a progressive loosing proposition and only gets worse every year. This proposal could certainly accelerate the rate at which it

Re: maximum ipv4 bgp prefix length of /24 ?

> On Sep 28, 2023, at 21:14, VOLKAN SALİH wrote: > > IMO, No. ipv4 is not dead yet. we need to raise it, a bit. > Agree to disagree… We need to put the final stake through its heart and move on. > EINAT solutions are OK > I presume you mean CGNAT? Otherwise, not sure what EINAT is and coul

Re: maximum ipv4 bgp prefix length of /24 ?

> > In principle, a company could make a business out of announcing a > large block from a bunch of peering points and then tunneling (vpn) > parts of it back to customers with sub-/24 assignments. With a broad > enough selection of peering points, the routing would not be too > inefficient. And i

Re: maximum ipv4 bgp prefix length of /24 ?

> On Sep 28, 2023, at 22:29, Saku Ytti wrote: > > On Fri, 29 Sept 2023 at 08:24, William Herrin wrote: > >> Maybe. That's where my comment about CPU cache starvation comes into >> play. I haven't delved into the Juniper line cards recently so I could >> easily be wrong, but if the number of

Re: maximum ipv4 bgp prefix length of /24 ?

lity to handle a 10M route table is known technology at this point, and its just a matter of the cost of the line cards. Owen > Eduard > From: NANOG [mailto:nanog-bounces+vasilenko.eduard=huawei@nanog.org] On > Behalf Of Owen DeLong via NANOG > Sent: Friday, September 29, 2023 7:11 AM &

Re: maximum ipv4 bgp prefix length of /24 ?

t; Hence, /48 proposition may become 20x worse for scale than proposed >> initially in this thread. >> Eduard >> From: NANOG [mailto:nanog-bounces+vasilenko.eduard=huawei@nanog.org] On >> Behalf Of Owen DeLong via NANOG >> Sent: Friday, September 29, 2023 7:11 AM >>

Re: maximum ipv4 bgp prefix length of /24 ?

/32s are perfectly valid in the DMS, but there is currently an IETF limit of ~500M of them (the other 3.5B are not yet released to the RIRs, only 2000::/3). Owen > On Sep 29, 2023, at 12:54, Collider wrote: > > This thread is utter amateur hour. I too would rather /32s be valid in the > DFZ

Re: maximum ipv4 bgp prefix length of /24 ?

> On Sep 29, 2023, at 13:43, William Herrin wrote: > > On Thu, Sep 28, 2023 at 10:29 PM Saku Ytti wrote: >> On Fri, 29 Sept 2023 at 08:24, William Herrin wrote: >>> Maybe. That's where my comment about CPU cache starvation comes into >>> play. I haven't delved into the Juniper line cards rec

Re: maximum ipv4 bgp prefix length of /24 ?

s/DMS/DFZ/ — Not sure how autocrrect did that without me noticing, apologies. > On Sep 29, 2023, at 14:11, Owen DeLong via NANOG wrote: > > /32s are perfectly valid in the DMS, but there is currently an IETF limit of > ~500M of them (the other 3.5B are not yet released to th

Re: maximum ipv4 bgp prefix length of /24 ?

ter > the fact > > did anyone eat the cake? was it tasty? > > > Le 29 septembre 2023 20:55:00 UTC, Owen DeLong via NANOG a > écrit : >> I have known Mike for many years. I have my disagreements with him and my >> criticisms of him. >> >> Howev

Re: maximum ipv4 bgp prefix length of /24 ?

> On Sep 29, 2023, at 14:48, William Herrin wrote: > > On Fri, Sep 29, 2023 at 2:13 PM Tom Beecher wrote: >>> My understanding of Juniper's approach to the problem is that instead >>> of employing TCAMs for next-hop lookup, they use general purpose CPUs >>> operating on a radix tree, exactly

Re: maximum ipv4 bgp prefix length of /24 ?

> On Sep 29, 2023, at 15:14, William Herrin wrote: > > On Fri, Sep 29, 2023 at 3:11 PM Owen DeLong wrote: >> You continue to assume that there is a fast SRAM cache. I’m not sure >> that is true. I think that all of the FIB RAM on the line cards is fast SRAM >> and no cache. > > Hi Owen, > >

Re: maximum ipv4 bgp prefix length of /24 ?

Not sure why you think FIB compression is a risk or will be a mess. It’s a pretty straightforward task. Owen > On Sep 30, 2023, at 00:03, Mark Tinka wrote: > >  > >> On 9/30/23 01:36, William Herrin wrote: >> >> >> If I were designing the product, I'd size the SRAM with that in mind. >

Re: maximum ipv4 bgp prefix length of /24 ?

First, no, a transient where all route disaggregating disappears from the global table is extraordinarily unlikely. Second, as I understand it, each update cycle results in rebuilding the fib from scratch rather than figuring out how to splice and dice it, so the computation required to cope w

Re: maximum ipv4 bgp prefix length of /24 ?

> On Oct 2, 2023, at 01:18, Nick Hilliard wrote: > > William Herrin wrote on 02/10/2023 08:56: >> All it means is that you have to keep an eye on your FIB >> size as well, since it's no longer the same as your RIB size. > > the point Jacob is making is is that when using FIB compression, the

Re: maximum ipv4 bgp prefix length of /24 ?

Isn’t that pretty much what Geoff Huston has done with the weekly reports William quoted earlier in this thread?Sure, that’s from a limited set of perspectives, but it probably represents the minimum achievable compression in most circumstances. OwenOn Oct 2, 2023, at 06:41, Joshua Miller wrote:S

Re: MX204 tunnel services BW

> On Oct 2, 2023, at 20:18, behrnsj...@yahoo.com wrote: > > > > -Original Message- > From: Delong.com > Sent: Monday, October 2, 2023 5:47 PM > To: behrnsj...@yahoo.com > Cc: nanog@nanog.org > Subject: Re: MX204 tunnel services BW > >> “Tunnel gets whatever bandwidth is left after

Re: MX204 tunnel services BW

You can configure tunnel bandwidth everywhere, but you can’t configure a given tunnel everywhere, you have to assign it to a particular FPC/PIC/0. For example, with: set chassis fps 2 pic 3 tunnel-services bandwidth 10g You need to create gr-2/3/0 interfaces for tunnels to use that PFE. You can

Re: ARIN email address (was cogent spamming directly from ARIN records?)

But I seem to have finally gotten Cogent trained not to spam this one, so I think I’ll leave it as is. YMMV Owen > On Oct 3, 2023, at 08:52, Bryan Fields wrote: > > On 10/2/23 11:28 AM, Mel Beckman wrote: >> I believe they got the contact information from ARIN > > I'd suggest everyone use a

Re: ARIN email address (was cogent spamming directly from ARIN records?)

I was one of the main people behind their suspension from ARIN whois for 6 months. They have not spammed me since. They’re probably afraid of another cake. Owen > On Oct 3, 2023, at 18:18, Mike Lyon wrote: > > Give it time :) > > -Mike > >> On Oct 3, 2023, at 18:0

Re: ARIN email address (was cogent spamming directly from ARIN records?)

Problem with that theory is the ratio of collateral damage to pain inflicted. Filter or deeper cogent and they don’t feel anything themselves. Their customers _might_ miss being able to reach your customers (or you), but then it is Cogent’s customers that feel the pain the most and Cogent to a

Re: maximum ipv4 bgp prefix length of /24 ?

If you maximally disaggregate to /24, you end up with about 12M fib entries. At /25 this doubles and you double it again for every bit you move right. At /24, we are on borrowed time without walking right. Also, the CPU in most routers won’t handle the churn of a 10M prefix RIB. Owen > On O

Re: maximum ipv4 bgp prefix length of /24 ?

> On Oct 4, 2023, at 03:18, Mark Tinka wrote: > >  > >> On 10/4/23 09:27, Elmar K. Bins wrote: >> >> >> Justin, >> >> I'm not sure you're not confusing scope here. >> >> Everybody and their sister accept smaller blocks from their customers; we're >> all talking about the DFZ here, not

Re: maximum ipv4 bgp prefix length of /24 ?

ble if operators push > everything out to /48 "to counter hijacks" or other misguided reasons? > > On Wed, Oct 4, 2023 at 8:14 AM Owen DeLong via NANOG <mailto:nanog@nanog.org>> wrote: >> If you maximally disaggregate to /24, you end up with about 12M fib entri

Re: maximum ipv4 bgp prefix length of /24 ?

Ratio of FIB to RIB is only part of the equation. IPv6 is NOT under the disaggregation pressure that IPv4 is under because there is no pressure (other than perhaps scarcity mentality from those that don’t properly understand IPv6) to dense-pack IPv6 assignments or undersize IPv6 allocations. L

Re: maximum ipv4 bgp prefix length of /24 ?

> On Oct 11, 2023, at 19:18, Willy Manga wrote: > > . > > On 11/10/2023 03:52, Delong.com wrote: >> [...] >>> RPKI only asserts that a specific ASN must originate a prefix. It does >>> nothing to validate the authenticity of the origination. >> Nope… It ALSO asserts (or can assert) an attri

Re: maximum ipv4 bgp prefix length of /24 ?

> On Oct 12, 2023, at 01:42, Willy Manga wrote: > > . > >> On 12/10/2023 10:00, Owen DeLong wrote: >> [...] However, IF YY is paying attention, and YY wants to advertise 2001:db8::/32 as well as allow 2001:db8:8000::/36 and 2001:db8:f000::/36, I would expect AS YY would gene

Re: ARIN whois contact abuse from ipv4depot aka Silicon Desert International Inc

> On Oct 12, 2023, at 10:59, Niels Bakker wrote: > > * Laura Smith [Thu 12 Oct 2023, 19:01 CEST]: >> I mean, most (all ?) of the registries still can't be bothered to validate >> the information the resource holders post to the database. Last time I >> asked, e.g. RIPE about it, they basica

Re: Add communities on direct routes in Juniper

I believe you need to add the communities either on the import policy which pulls in the direct route or the export policy to the neighbor(s) you want to feed the communities to. Owen > On Oct 15, 2023, at 05:51, Jason R. Rokeach via NANOG wrote: > > Hi Stanislav, > I believe this is what

Re: Amir Golestan sentenced to 5 years in prison for IP theft scheme

Sadly, probably not. AUP violations are a civil, not a criminal matter. Fraud, OTOH, is a criminal matter. In the US, at least, people don’t go to prison for civil matters. Owen > On Oct 17, 2023, at 19:19, Mel Beckman wrote: > > So ARIN DB spammers should get at least a year or two, right?

Acceptance of RPKI unknown in ROV

A question for network operators out there that implement ROV… Is anyone rejecting RPKI unknown routes at this time? I know that it’s popular to reject RPKI invalid (a ROA exists, but doesn’t match the route), but I’m wondering if anyone is currently or has any plans to start rejecting routes

Re: Acceptance of RPKI unknown in ROV

I ask because there was discussion at the ARIN meeting and Kevin Blumburg made the suggestion that “in 2024, routes will not be accepted without ROAs”. I didn’t think this was likely, but as someone with resources for which I cannot create ROAs, it is a concern. So far, I haven’t really seen a

Re: RPKI unknown for superprefixes of existing ROA ?

Actually, Job, the 1.2.0/20 would be the longest prefix announced for 1.2.4/24 and 1.2.7/24 in this case. It’s a rather clever end-run. The /20 won’t match the more specific as0 ROAs, so it gets accepted. The /24s either aren’t advertised or they get discarded as invalid. Of course, if RIRs were is

Re: RPKI unknown for superprefixes of existing ROA ?

Look again, Tom. This is an attack vector using a LESS specific route. The /22 gets discarded, but a covering /0-/21 would not. OwenOn 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 asse

Re: RPKI unknown for superprefixes of existing ROA ?

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: >

Re: RPKI unknown for superprefixes of existing ROA ?

Yes, but we weren’t talking about an IXP here. We’re talking about an ISP. Believe it or not, Job, there are parts of the internet that exchange traffic and move packets that are not IXPs. Owen > On Oct 22, 2023, at 11:48, Job Snijders via NANOG wrote: > > On Sun, 22 Oct 2023 at 20:33, Tom

Re: RPKI unknown for superprefixes of existing ROA ?

In fairness, however, there is a natural tendency for many of those PNIs to be built in locations in common with IXPs and often they start as IXP connections and with growth of traffic end up migrating to PNIs for further expansion. Owen > On Oct 24, 2023, at 18:15, Randy Bush wrote: > >> Be

Re: [EXTERNAL] Charter DNS servers returning malware filtered IP addresses

> On Oct 27, 2023, at 14:20, John Levine wrote: > > It appears that Bryan Fields said: >> -=-=-=-=-=- >> -=-=-=-=-=- >> On 10/27/23 7:49 AM, John Levine wrote: >>> But for obvious good reasons, >>> the vast majority of their customers don't >> >> I'd argue that as a service provider delibera

Re: Charter DNS servers returning malware filtered IP addresses

>> 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

Re: [EXTERNAL] Charter DNS servers returning malware filtered IP addresses

> On Oct 30, 2023, at 07:58, Livingood, Jason > wrote: > > On 10/27/23, 19:01, "NANOG on behalf of Owen DeLong wrote: > >> If it’s such a reasonable default, why don’t any of the public resolvers >> (e.g. 1.1.1.1, 8.8.8.8, 9.9.9.9, etc.) do so? >> DNS isn’t the right place to attack this, I

Am I the only one who thinks this is disconcerting?

https://dnsviz.net/d/10.159.192.in-addr.arpa/dnssec/ Seems to report a bunch of errors in the DS records for 192.in-addr.arpa held in the in-addr.arpa zone. I figured I’d wait a few days and try again the first few times I encountered this, but it’s persisted for more than two weeks now. Owe

Re: Am I the only one who thinks this is disconcerting?

It can’t be legacy space, there is no such thing in IPv6. Legacy status only refers to IPv4 blocks that were issued by the predecessors to the current registry system and have not yet been placed under RIR contract. Owen > On Nov 13, 2023, at 12:57, Matt Corallo wrote: > > I'd be very curiou

Re: ipv6 address management - documentation

Spreadsheets are terrible for IPAM regardless of address length, but I am curious to know why you think IPv6 would be particularly worse than IPv4 in such a scenario? Owen > On Nov 16, 2023, at 10:02, Aaron Gould wrote: > > For years I've used an MS Excel spreadsheet to manage my IPv4 addres

Re: Outside plant - prewire customer demarc preference

> On Nov 28, 2023, at 07:27, Brandon Martin wrote: > > On 11/27/23 18:52, owen--- via NANOG wrote: >> Why would 1” be significantly harder to get than 3/4”? Both in EMT and PVC, >> it’s readily available to the best of my knowledge. > > Most residential electrical contractors are going to us

Interesting Ali Express web server behavior...

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 = DigiC

Re: Interesting Ali Express web server behavior...

Turn my wifi off and now it works flawlessly. > > Are you using your comcast connection? > > -Mike > >> On Dec 9, 2023, at 21:17, Stephane Bortzmeyer wrote: >> >> On Sat, Dec 09, 2023 at 09:55:31PM -0800, >> Owen DeLong via NANOG wrote >> a message o

Re: Interesting Ali Express web server behavior...

quire 1,789,132 hosts to > exhaust the space. > > - Christopher H. > > On Sun, 10 Dec 2023 at 18:45, Sabri Berisha <mailto:sa...@cluecentral.net>> wrote: >> - On Dec 9, 2023, at 9:55 PM, Owen DeLong via NANOG nanog@nanog.org >> <mailto:nanog@nanog.org> wr

Re: 202401100645.AYC Re: IPv4 address block

ARIN has been gutting IPv4 free-pool based policy left and right lately… Other RIRs have not been quite as aggressive, but have done some similar things. This, if for no other reason, makes it a bad idea to suddenly restore RIR IPv4 free pools. Just my $0.02. I’ve got as little power in the IE

Re: 202401100645.AYC Re: IPv4 address block

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 opti

Re: IPv6? Re: Where to Use 240/4 Re: 202401100645.AYC Re: IPv4 address block

Frankly, I care less. No matter how you use whatever IPv4 space you attempt to cajole into whatever new form of degraded service, the simple fact remains. IPv4 is a degraded technology that only continues to get worse over time. NAT was bad. CGNAT is even worse (and tragically does nothing to elimi

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

Windows, Mac, Linux, bad are all done. Juniper, MikroTik, even Cisco are done.Most consumer routers sold in the last 2-3 years are done. Not sure what “hardware vendor” would be necessary beyond those. There are probably some little used corner cases of routers, os, etc. but for the most part, we a

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

Apologies, I failed to realize that we were still discussing the absurdity of 240/4 and thought we were talking IPv6. All my comments below apply to v6 progress. 240/4 remains in the who knows?/who cares? Category as far as I’m concerned. OwenOn Jan 12, 2024, at 22:51, Owen DeLong wrote:Windows,

Re: IPv6 Traffic Re: IPv6? Re: Where to Use 240/4 Re: 202401100645.AYC Re: IPv4 address block

> On Jan 14, 2024, at 19:50, Abraham Y. Chen wrote: > > Hi, Ryan: > > 1) " ... it accounts for 40% of the traffic at Google. ": > > Perhaps you were referring to the following? > > https://www.google.com/intl/en/ipv6/statistics.html > > 2)If so, your quotation is correct,

Re: One Can't Have It Both Ways Re: Streamline the CG-NAT Re: EzIP Re: IPv4 address block

Any host connected to a reasonably well peered ISP (e.g. NOT Cogent) with IPv6 should be able to communicate with any other such host so long as the administrative policies on both sides permit it. I have no difficulty directly reaching a variety of IPv6 hosts from the /48 in my home. However,

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

> On Jan 15, 2024, at 09:37, Abraham Y. Chen wrote: > > Hi, Christopher" > > 1)" IPv6 is designed to replace IPv4. ": > Correct. But, this is not like Ten Commandments that God gave to his > children. Even such had not worked out in most cases. In real life, technical > backward co

Re: okta probing

I think this is a new form of dDOS and it is sometimes performed by Bots. What they are achieving is annoying you. From your post, it appears to be working. It’s also possible (depending on the account name) that it’s a mistype. Owen > On Jan 12, 2024, at 17:50, Randy Bush wrote: > > can so

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

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? Owen > On Jan 19, 2024, at 02:39, kubanowy wrote: > > Hi, > We have our own prefix assignment from ARIN. We have our infrastructure in > GCP

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

> On Jan 19, 2024, at 09:21, Charles Polisher wrote: > > Owen DeLong wrote: > > > Some, but not a lot. In the case of the DTMF transition, the > > network and handsets were all under the central control of a > > single provider at a time when they could have forced the change > > if they real

Re: One Can't Have It Both Ways Re: Streamline the CG-NAT Re: EzIP Re: IPv4 address block

No. No matter how you cobble it, IPv4 doesn’t have enough addresses to restore proper end to end connectivity. OwenOn Jan 20, 2024, at 07:36, Abraham Y. Chen wrote: Hi, Owen: 1)    "  ...  IPv4 used to work before NAT made everything horrible.  ":

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

> 2)Philosophically, IPv6 and IPv4 are kind of like two religions, each > with its own believers. As long as the devotees of each focus on their > respective passion, the world will be peaceful. As soon as one camp imposes > its preference onto the other, friction starts. Unchecked, it can

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

On Jan 21, 2024, at 12:07, Christopher Morrow wrote:On Fri, Jan 19, 2024, 4:55 PM Owen DeLong via NANOG <nanog@nanog.org> 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?I think i

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

On Jan 21, 2024, at 16:10, Christopher Morrow wrote:On Sun, Jan 21, 2024, 5:39 PM Owen DeLong <o...@delong.com> wrote:On Jan 21, 2024, at 12:07, Christopher Morrow <morrowc.li...@gmail.com> wrote:On Fri, Jan 19, 2024, 4:55 PM Owen DeLong via NANOG <nanog@nanog.org> wrote:Soun

Re: Networks ignoring prepends?

And now you are faced with an object lesson as to why TE routes are so prevalent. Less specifics are your only functional alternative here. In most cases, you shouldn’t need more than 2 per prefix. Owen > On Jan 22, 2024, at 12:16, William Herrin wrote: > > On Mon, Jan 22, 2024 at 5:23 A

Re: Networks ignoring prepends?

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 s

<    1   2   3   4   5   >