Re: Geolocation IP help

> There is always talk to the local politician route so it gets raised > in the state legislature. this is illinois/chicago. you slip them a $100 bill under youe drivers' license

Re: Geolocation IP help

> You could try publishing Geo loc data per RFC8805 > https://datatracker.ietf.org/doc/html/rfc8805 or, more specifically, 9092 randy

Re: Announcing N91 Monday Keynote + New on NANOG TV: "Community Deep Dive"

> *Abstract: *Once upon a time it was unthinkable to have a company > meaningfully more complicated than a local florist that didn't have a > network engineer on staff, or at least retainer. Today the world is > vastly different... folk interested in this might find

Re: Q: is RFC3531 still applicable?

> The minimum addressable on a LAN is a /64. not really randy

Re: NOAA Space Weather Prediction Center issued a Severe (G4) Geomagnetic Storm Watch

> (Low but distinct possibility of effects to radio and transmission > systems) no one will notice as we will all be outside looking at the aurora! randy

Re: 2600:: No longer pings

> Wonderful news, this has now been fixed :) > Thank you to Cogent for fixing this indee. otoh, i still can not resist https://www.kame.net/ randy

Re: Anyone got a contact at OpenAI. They have a spider problem.

> Amazon's spider got stuck there a month or two ago but fortunately I was > able to find someone to pass the word and it stopped. Got any contacts > at OpenAI? why? you are doing a societal good by ensnaring them. dig a deeper hole. randy

Re: N91 Women mixer on Sunday?

> I'm sure that your time was better spent gathering the "credentials" > in your signature, but I checked the last 20 or so NANOG meetings and > didn't see a single registration from you, so perhaps stay out of > things you know literally nothing about. https://en.wikipedia.org/wiki/Ad_hominem

Re: N91 Women mixer on Sunday?

we definitely need more men's opinions on what women should want and do randy

Re: NANOG 90 Attendance?

> We actually had an IETF "Help Desk" at NANOG 63 (San Antonio, 2015) and > NANOG 64 or 65 ― > https://www.internetsociety.org/blog/2015/01/chris-grundemann-nanog-63-talking-bcop-ietf-and-more/ > and > https://www.internetsociety.org/blog/2014/11/operators-and-the-ietf-update-from-ietf-91/ > > We

Re: Ongoing ARIN consultation on Resource Public Key Infrastructure/BGP intelligence

john: > I’d tend to agree with you, but ARIN already once attempted to rollout > such functionality – alas, with overly ambitious scope that not only > provided increased visibility after potentially affected routes but > functionality that also created default linkage to matching IRR > objects

Re: Ongoing ARIN consultation on Resource Public Key Infrastructure/BGP intelligence

john, > Read the full text of the consultation at: > https://www.arin.net/participate/community/acsp/consultations/2024/2024-1/ please explain the need for bureaucrazy to do what RPKI CAs have been doing since dirt was invented. randy

Re: ru tld down?

> For taking care of referrals and delegations, ietf has started > preliminary work. More info here - > > https://mailarchive.ietf.org/arch/msg/dd/srNtevzS-jrPzMxYv1nATCY5JkM/ dns is not complex enough that folk have assured careers. need to make it more complex. randy

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

>     My apologies! For an uninitiated, I misread your message as if > IPv6 was originally designed with a plan to assure smooth transition > from IPv4. i'll try again there was a transition plan; it was dual stack. i did not say it was a *good* transition plan. the plan's fatal flaw was that

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

> Some of us still use pine… i thought most pine users had moved to mutt randy, who uses wanderlust under emacs :)

Re: IPv4 address block

>> If you limit each requesting organization to a /22 per year, we can >> keep the internet mostly functional for decades to come, > > at least in the ripe ncc service region, all this proved was that if > the cost of registering a company (or LIR) and applying for an > allocation was lower than

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

interesting side note: when iij was deploying the v6 backbone in '97, commercial routers did not support dual stack. so it was a parallel backbone built on netbsd with the kame stack, which was developed in iij lab. we remember itojun. randy

okta probing

can someone explain what some child out there hopes to gain by repeatedly failing to authenticate to okta in my accound name? a couple of times a day, i have to take 40 seconds to unlock the account the kiddie has triggered. seems silly as they do not have the 2fa. it's -3c here, so i guess the

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

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

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

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

Re: 202401100645.AYC Re: IPv4 address block

>>> We don't need to extend IPv4, we need to figure out why we are in this >>> dual-stack mess, which was never intended, and how to get out of it. >> >> it was intended. it was the original transition plan. like many things >> about ipv6, it could have been a bit better thought out. > > What

Re: 202401100645.AYC Re: IPv4 address block

> We don't need to extend IPv4, we need to figure out why we are in this > dual-stack mess, which was never intended, and how to get out of it. it was intended. it was the original transition plan. like many things about ipv6, it could have been a bit better thought out. randy

Re: swedish dns zone enumerator

> I might be reading this wrong, but I don't think the point Randy was > trying to make was 'NS queries are an attack', 'UDP packets are an > attack' or 'IP packets are an attack' . I base this on the list of > queries Randy decided to include as relevant to the thesis Randy was > trying to make,

Re: swedish dns zone enumerator

ya, right, and at a whole bunch of other cctld servers from a network called domaincrawler-hosting shall we smoke another? /home/randy> sudo tcpdump -pni vtnet0 -c 500 port 53 and net 193.235.141 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on vtnet0,

swedish dns zone enumerator

i have blocked a zone enumerator, though i guess they will be a whack-a-mole others have reported them as well /home/randy> sudo tcpdump -pni vtnet0 -c 10 port 53 and net 193.235.141 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on vtnet0, link-type EN10MB

itojun

this day in 2007 dr jun-ichiro (itojun) hagino died. a gentle soul, an engineer's engineer, the ipv6 samurai, iab member, and fiat 500 lover. the v6 stack you're running could have descended from his netbsd one. http://www.itojun.org/ randy

Re: emily postnews

> wish this was included with every subscription to internet services > you did not get it with your AOL CD? ask for a refund. as a bonus, https://neal.fun/internet-artifacts/ randy

emily postnews

another old dog doing a search wrote to tell me they really appreciated that i still had some antique advice up. i had long forgotten this one. but found it amusing and still more relevant than i might wish. https://psg.com/emily.html randy

Re: RPKI unknown for superprefixes of existing ROA ?

> Believe it or not, Job, there are parts of the internet that exchange > traffic and move packets that are not IXPs. in fact, measurements had shown that the majority of inter-domain traffic is over pnis randy

remembering abha

another tragic october death was that of abha ahuja, researcher, operator, and amazing person, this day in 2001. worth a search. jake's http://www.neebu.net/~khuon/abha/ is a start. randy

Re: Acceptance of RPKI unknown in ROV

>> has arin not made it easier, lowering the legal insanity, for legacy >> holders to obtain services? > Yes but they need to jump now if they want to take advantage of it, as > I understand it. arin has deep expertise in hurdles randy

Re: Acceptance of RPKI unknown in ROV

> For legacy resource holders it is a problem but then it’s a > bureaucratic issue rather technical and technology has a solution > called SLURM. has arin not made it easier, lowering the legal insanity, for legacy holders to obtain services? randy

Re: jon postel

> I wonder if he knew it would have become what it is today. one of my favorite postel quotes It's perfectly appropriate to be upset. I thought of it in a slightly different way--like a space that we were exploring and, in the early days, we figured out this consistent path through

jon postel

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: ARIN whois contact abuse from ipv4depot aka Silicon Desert International Inc

i received an arin board electioneering "vote for me" today. i guess now i have to go vote against then. randy

Re: constraining RPKI Trust Anchors

> So while each RP should be able to make policy decisions based on its > own local criteria, managing a default set of constraints is something > that is best done centralized. Who do you envision should manage these > lists? RP software maintainers? RIRs? Others? and how will this

Re: Using RFC1918 on Global table as Loopbacks

> I have recently encountered some operational differences at my new > organization that are not what I have been exposed to before, where > the loopback of the core network devices is being set from RFC1918 > while on the global routing table. I'm sure this is not a major issue > but I have

Re: maximum ipv4 bgp prefix length of /24 ?

> About 60% of the table is /24 routes. > Just going to /25 will probably double the table size. or maybe just add 60%, not 100%. and it would take time. agree it would be quite painful. would rather not go there. sad to say, i suspect some degree of lengthening is inevitable. we have

Re: So what do you think about the scuttlebutt of Musk interfering in Ukraine?

perhaps this is not a nanog operational topic

Re: Lossy cogent p2p experiences?

i am going to be foolish and comment, as i have not seen this raised if i am running a lag, i can not resist adding a bit of resilience by having it spread across line cards. surprise! line cards from vendor do not have uniform hashing or rotating algorithms. randy

Re: Guest Column: Kentik's Doug Madory, Last Call for Upcoming ISOC Course + More

> It is totally possible to turn off the spyware in MailChimp. You just > need to buy an actual commercial account rather than using their > "free" service. To save $13 or $20 per month, you are instead selling > the privacy of every recipient of your emails. See: > >

Re: Guest Column: Kentik's Doug Madory, Last Call for Upcoming ISOC Course + More

> *READ MORE > Last can we please get URLs without all the invasive tracking? randy

Re: it's mailman time again

> Mail in transit is mostly TLS transport these days, yep. mostly. opsec folk are not fond of 'mostly.' > BUT mail in storage and idle state isn't always secured. I'm sure > that most any of us could find a public s3 bucket with an mbox file on > it if we cared to look. sigh randy

it's mailman time again

and i just have to wonder about sending passords over the net in cleartext in 2023. really? randy

Re: v6 route mess frm AS266970

> We saw no impact to v6 traffic during the leak (and we have quite a > lot of v6 traffic). I guess testament that RPKI works? the packetviz (props massimo) reports i received would seem to indicate that the blast radius was mostly contained to america latina collectors. yes, likely due to route

v6 route mess frm AS266970

is a massive route leak not even menntioned when it is only ipv6? the guess i heard was it looked like a classic config reorigination disaster. randy

Re: Internet Exchange Visualization

> actually, i am amazed by the extent of "remote peering." if one > measures rtt to all the peers on the six, for example, the curve goes > out to well over 200ms. the six has seen remote peers from the gulf > states, and i do not mean louisiana. > > graph below is one way to visualize ix

Re: Internet Exchange Visualization

> You might instead be thinking of "how are different participants in a > single internet exchange cross-connected to each other?" -- in which > case the answer is "through in-building wiring that often even the > building owner isn't entirely aware of what path the connections are > taking."

Re: Dodgy AS327933 ...?

> We are seeing some weird routing from them, and the AS2 they are > attached to (University of Delaware) seems odd. classic microtik prepend syntax confusion? randy

Re: malware warning

i did not think i was special, and assumed everybody is getting them. but i figured that if i kept one or three people from falling for the trap it was worth the pollution. randy

Re: My first ARIN Experience but probably not the last, unfortunately..

> #define SOAPBOX > > Please remember ARIN covers more than just the relatively prosperous > United States. There are places like Jamaica, which are also in the > ARIN region, where the average annual income is $2,337. indeed i find this thread to be depressing. the economics you mention, of

Re: whois server

> the memo: > https://web.archive.org/web/20230523204911/http://www.geektools.com/ 404

whois server

``` % host whois.geektools.com Host whois.geektools.com not found: 3(NXDOMAIN) ``` i guess i missed the memo :( randy

Re: [Attendee] Welcome to NANOG 88 - Sunday Edition

let's get to the protein. where is the most reasonable parking near the venue? randy, who will soon start driving up from portland

Re: BGP routing ARIN space in APNIC region

> Everyone should check out Massimo Candela's presentation "Geolocation > problems: Do we have a solution?" for how to provide your own > geolocation data... > > https://www.netnod.se/sites/default/files/2023-03/Massimo_Webpage.pdf > > I've seen it at recent RIPE and LACNIC conferences.

Re: 128/9 cite

thanks aftab i remember a bit more. the hidden command was there to help debug CEF, which was new at the time. the CEFlapods wanted a large blob of prefixes to push the FIB. it kinda pushed the operational FIBs a bit too far :) randy

128/9 cite

doug madory is asking me for a cite for the exciting 1997/8 128/9 bgp event. my memory as reported to doug is soon after the 7007 incident, an engineer in a UUNET lab, not realizing they were connected to the real internet, used the hidden bgp test command to generate 128/9 chopped

Re: Soliciting suggestions and experiences from the community for RPKI-invalid filtering deployment

> some ASes may perform RPKI-invalid filtering only at partial > interfaces (e.g., provider interfaces, customer interfaces, and peer > interfaces). i have heard it said that "my customer pays me to propagate their announcement, so i do not apply rov. let my peers filter it." randy

Re: Standard DC rack rail distance, front to back question

> It's super annoying, and somewhat terrifying to be banging on a rack > containing a bunch of spinning rust, but all too often it's necessary we just moved a rack's content from the westin to komo plaza [0] and only had one questionable drive. terrifying is the right word. randy [0] - we may

Re: Standard DC rack rail distance, front to back question

> "small mounting shelf" we use mounting shelves for all sorts of recalcitrant devices randy

Re: Reverse DNS for eyeballs?

> I would say the absence of reverse DNS tells useful info to receiving > MTAs - to preferably not accept. yep

Re: Spamhaus flags any IP announced by our ASN as a criminal network

this company(s) is in the business of spam. they're just trying to game nanog. discussing further a waste of pixels. ranady

Re: Spamhaus flags any IP announced by our ASN as a criminal network

>> I don't think any ISP would reject an IP that is on the Spamhaus >> list. > you, clearly, have been living under several rocks for a very long > time. we reject automagically on spamhaus, mail-abuse.org, and sorbs. really appreciate their services. randy

Re: BGP Engines with support to "RTFilter address-family"

> RFC4364 ... I believe - Arccus has implemented it (Keyur to confirm) i am not keyur and do not play one on the net, but ...

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

> It was assumed that IPng would include a standard straightforward > technological solution to support communication with IPv4 hosts – this > was a defined hard requirement. > > This transition mechanism wasn’t available at the time of the > selection of IPng, and instead was left as a future

Re: Geoip database update

> > darn shame there is no general automatable mechanism for this too many folk have written to ask. here is the clue by four https://www.rfc-archive.org/getrfc?rfc=9092 and note that massimo has a collio toolset https://github.com/massimocandela/geofeed-finder randy

Re: Geoip database update

darn shame there is no general automatable mechanism for this randy

Re: AS3356 Announcing 2000::/12

> I know of a few people in a Discord that filter out anything bigger > than /16 routes, would this be wise to implement as a best practice? once upon a time, a very large provider took two /8s and announced as a /7. a vendor who thought a /8 was as short as they would ever see had routers fall

Re: AS3356 Announcing 2000::/12

while i think the announcement is, shall we say, embarrassing, i do not see how it would be damaging. real/correct announcements would be for longer prefixes, yes? randy

Re: Newbie Concern: (BGP) AS-Path Oscillation

[ i would have written privately except the damned dmark crap obscured your email address. gr. ] > On one of our prefixes, we are detecting continuous “BGP AS-Path > Changes” in the order of 1,000 announcements per hour---practically > one every 3-4 seconds. where is this being

afrinic rpki issue

From: PacketVis Date: Sun, 20 Nov 2022 04:30:44 + Possible TA malfunction or incomplete VRP file: 73.95% of the ROAs disappeared from afrinic See more details about the event:

Re: Why do ROV-ASes announce some invalid route?

> ROV belongs on the input path, let's not ROV on the output towards > customers / route collectors. 8893 randy

Re: Why do ROV-ASes announce some invalid route?

aside from technical reasons for an ROV-supporting AS (RAS) to announce an ROV invalid prefix, there is an administrative one. the RAS's customers *pay* RAS to announce the customers' prefixes. so RAS is configured to propagate their customers' announcements without dropping invalids. randy

Re: Understanding impact of RPKI and ROA on existing advertisements

for the 312th time. origin validation was never designed to stop attacks. it was designed to ameliorate mistakes. if you want to use the rpki to reduce attacks, use bgpsec. randy

Re: Understanding impact of RPKI and ROA on existing advertisements

> Thanks everyone for your inputs. So bottomline setup RPKI and setup ROA's > for all our subnets being advertised. if the BGP advertisements are correct, then mirror them in ROAs. most, if not all, CA UIs make that easy. randy

itojun

and the third giant to have died in october, itojun hagino died on this day in 2007. ipv6 owes a great debt to itojun; as do a bunch of other technoogies and many people. a wise and gentle soul. i dread october. randy http://www.itojun.org/itojun.html http://www.itojun.org/personal.html

abha

abha ahuja died 21 years ago today; a force in routing, ops, and trying to liberate the culture. fort hose who want to pull threads, http://www.neebu.net/~khuon/abha/ https://archive.nanog.org/resources/scholarships/abha_ahuja there are others here who will have much better cites (hint

Re: jon postel

ess space is ungood? -- Randy Bush Routing unallocated address space is ungood! -- Jon Postel randy

Re: jon postel

my favorite is It's perfectly appropriate to be upset. I thought of it in a slightly different way--like a space that we were exploring and, in the early days, we figured out this consistent path through the space: IP, TCP, and so on. What's been happening over the last few years is that the

jon postel

it's been 24 years, and we still live in his shadow and stand on his shoulders. we try not to stand on his toes. randy

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

< rant > there once used to be 'swamp' space, down in the low 190s where /24s were expected. and folk/rirs tried to keep shorter aggregates, e.g. /19s, as the norm above swamp (negotiated at ietf/danvers). in those days, one could actually filter above swamp on /19. for a while, one could even

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

> we're thinking to deny all /24s to save the memory i recommend this to all my competitors randy

Re: ARIN RPA updated (again) to address TAL distribution (Re: ARIN RPKI services terms/conditions - Change to Management of the Trust Anchor Locator for ARINʼs RPKI Service)

> Randy, did you sign the RPA? you're kidding, right? > I did not sign the RPA. > Am I allowed to use rpki software like this? > And am I in any way restricted in the use of the produced work below > from this RP software? i am not a lawyer and do not play one on the net randy

Re: ARIN RPA updated (again) to address TAL distribution (Re: ARIN RPKI services terms/conditions - Change to Management of the Trust Anchor Locator for ARINʼs RPKI Service)

>> may i include the arin tal in my software product with neither i nor >> the user of the product being encumbered, signing anything, ... as >> with the other RIRs? > Yes. excellent. thank you. [ and arin might ask itself why and how it took O(decade) to come to this simple position;

Re: ARIN RPA updated (again) to address TAL distribution (Re: ARIN RPKI services terms/conditions - Change to Management of the Trust Anchor Locator for ARIN’s RPKI Service)

> However, your point is taken and ARIN shall endeavor to make terms and > conditions for use of the TAL and the ARIN repository clearer in this > regard. > > As alluded to above, the attached ARIN announcement from today notes > that the ARIN RPA has now been updated (again) specifically to

Re: Article: DoD, DoJ press FCC for industry-wide BGP security standard

> Does another barrier to entry make sense? ROV's ROA creation is a barrier to entry in north america, as discussed in another thread or see https://scholarship.law.upenn.edu/faculty_scholarship/2035/ there are other cultures where isp operational security is taken more seriously than power

Re: Article: DoD, DoJ press FCC for industry-wide BGP security standard

> Way overdue! In the last 4 weeks, I've had at least 20 diff > conversations with FSI Network operators re: BGP hijacking, how to > detect and in the future, mitigate with higher levels of success. Come > on BGP RPKI/ROA adaption. I found the easiest way is via ISP pressure > to implement

Re: [External] 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 Decembe

> You could try suggesting IANA/PTI/ICANN to have a different RPKI trust > anchor and provide such services to legacy block holders. the rpki design cabal assumed the iana would be the rpki root. rir power players blocked that. so each rir is 0/0. brilliant, eh? randy

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)

> We strongly encourage all legacy resource holders who have not yet > signed an LRSA to cover their legacy resources to consult a competent lawyer before signing an LRSA randy

Re: Router ID on IPv6-Only

enke and jenny yuan cleaned this up in 6286 randy

Re: Router ID on IPv6-Only

> A question Dorian and I discussed but never answered is, how are open > collisions handled if two speakers, presumably an external AS, happen > to have the RID? the uniqueness is supposed to be on the tuple {AS,RID} so an RID 'collision' with a foreign AS should not be possible randy

Re: Router ID on IPv6-Only

> During some IPv6 numbering discussions at work today, someone had a > question that I hadn't really considered before. How to choose 32-bit > router IDs for IPv6-only routers. arbitrary 32 bit number unique in the autonomous system. even in an ipv4 world it does not need to match any

Re: End of Cogent-Sprint peering wars?

> Yes, and the new administration will force more depeering for those > that peers with Sprint but not with Cogent. So the net result will be > negative. if i was as good as you at predicting the future, i would bet on the horses not work on the internet. randy

Re: End of Cogent-Sprint peering wars?

> Is there a hotline for those of us who have Cogent and Sprint….. sighs not a pots type, but i find email to the usual addresses works well. two reputable top tier providers. been using one or t'other for decades. but it seems popular for folk with no real skin in the game to diss them.

Re: [EXTERNAL] Re: Yet another BGP hijacking towards AS16509

as a fellow researcher said the other week, ROV, ASPA, ... are intended to provide safety, not security. randy

Re: IoT - The end of the internet

new at eleven

Re: HE.net and BGP Communities

most networks prefer customers over peers. a few networks don't, some large. if they changed, customers would scream at them about the newly overloaded customer circuit. we are not required to like this :) randy

Re: [ripe-list] AFRINIC SUSPENDED CEO TRYING TO ASK GOVERNMENT TO APPOINT DIRECTORS OF RIR

> Return-path: i would have hoped that moderation of the ripe list would have kept such pathetic and disgusting racist sickenss off list. randy

Re: Scanning the Internet for Vulnerabilities

> To what extent and to whom will you authorize to do that? 100 random > college students? X number of new security firms? At some point it > will break. definitely not raging nanog vigilantes :) randy

Re: Scanning the Internet for Vulnerabilities

> For example I've gotten email in the past that some of my servers were > running ntp in a way which makes them vuln to being used for DDoS > amplification and, I believe, fixed that. I didn't mind. that was a really well done campaign. i thanked them profusely. randy

  1   2   3   4   5   6   7   8   9   10   >