Re: Geolocation IP help

[Randy Bush]

> 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

[Randy Bush]

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

[Randy Bush]

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

https://berthub.eu/articles/posts/cyber-security-pre-war-reality-check/

interesting

randy

Re: Q: is RFC3531 still applicable?

[Randy Bush]

> 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

[Randy Bush]

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

[Randy Bush]

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

[Randy Bush]

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

[Randy Bush]

> 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

anne has been a constructive list participant for years

randy

Re: N91 Women mixer on Sunday?

[Randy Bush]

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

randy

Re: NANOG 90 Attendance?

[Randy Bush]

> 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 hoped to answer questions such as:
> “Why should I participate in the IETF?”
> “How do I get involved in the IETF?”
> “What is the difference between an Internet-Draft and an RFC?”
> “How do I submit an idea to the IETF?”
> “What is the IETF working on in  space?”
> “How do I comment on an existing IETF document?”
> 

perhaps the internet would benefit more from the inverse, a help desk at
the ietf for "what is internet operation and how does it actually work?"

randy

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

[Randy Bush]

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

whoops!  i still code around another RIR doing that.  vendors have a
long history of thinking they know best what operators should do.  some
RIRs seem to have such hubris.

ok, i can see opening up discussion to reduce foot shooting risks.
sorry for skepticism.

randy

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

[Randy Bush]

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?

[Randy Bush]

> 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

[Randy Bush]

>     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 it assumed there was sufficient ipv4 to
be congruent until ipv6 was widely enough deplayed that the ipv4 could
be turned off.  this was in the face of very real data (props to frank
kastenholz) projecting the ipv4 run out rate.

the v6 fantasy was that ipv6 would be quickly deployed.  i guess it has
been from the perspective of geologic time.

randy

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

[Randy Bush]

> 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

[Randy Bush]

>> 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 the market rate of ipv4 addresses, then
> people would do that.
> 
> The root problem is unavoidable: ipv4 is a scarce resource with an
> inherent demand. Every policy designed to mitigate against this will
> create workarounds, and the more valuable the resource, the more
> inventive the workaround.

and complex policies lead to more complex workarounds which make the
internet crappier

> In terms of hard landings vs soft landings, what will make ipv6
> succeed is how compelling ipv6 is, rather than whether someone created
> a policy to make ipv4 less palatable. In particular, any effect from a
> hard landing compared would have been ephemeral.

amen

randy

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

[Randy Bush]

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

[Randy Bush]

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 clue level is going down as well
as the temp.

randy

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

[Randy Bush]

> 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 it sure is a change to have a n00b troll.

i was really looking forward to it making me young.  sigh.

randy

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

[Randy Bush]

> 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: 202401100645.AYC Re: IPv4 address block

[Randy Bush]

>>> 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 was not intended though was the transition period to last for 30
> years and counting… If things go reasonably well we’re gonna be dual
> stack for another 20, at least.

like many things about ipv6, it could have been a bit better thought
out.

randy

Re: 202401100645.AYC Re: IPv4 address block

[Randy Bush]

> 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

[Randy Bush]

> 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, instead of wholesale warning of IP, UDP or NS queries.

i was warning of an ndrek3 enumeration attack from the source netblock's
ip space

i am far from an expert in ndrek3 enumeration.  but i naïvely assume
that most tld rrs are ns so that is what they're after.  but, as you
say, that is beside the point.

randy

Re: swedish dns zone enumerator

[Randy Bush]

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, link-type EN10MB (Ethernet), capture size 262144 bytes
05:12:30.563268 IP 193.235.141.169.32768 > 666.42.7.11.53: 14 NS? 
cgatcity.com.cu. (33)
05:12:30.565017 IP 193.235.141.215.32768 > 666.42.7.11.53: 14 NS? 
christ-jockel.jo. (34)
05:12:30.565660 IP 193.235.141.209.32768 > 666.42.7.11.53: 14 NS? cgatcity.al. 
(29)
05:12:30.566490 IP 193.235.141.209.32768 > 666.42.7.11.53: 14 NS? 
cgatcity.org.al. (33)
05:12:30.566694 IP 193.235.141.3.32768 > 666.42.7.11.53: 14 NS? 
christian-luber-jr.net.al. (43)
05:12:30.569474 IP 193.235.141.239.32768 > 666.42.7.11.53: 14 NS? 
clearing-muenchen.eg. (38)
05:12:30.571870 IP 193.235.141.160.32768 > 666.42.7.11.53: 14 NS? 
clearing-muenchen.com.ps. (42)
05:12:30.573436 IP 193.235.141.23.32768 > 666.42.7.11.53: 14 NS? 
cofls-welt.xn--pgbs0dh. (40)
05:12:30.573914 IP 193.235.141.173.32768 > 666.42.7.11.53: 14 NS? 
club-lederwerk-neustadt.net.al. (48)
05:12:30.574608 IP 193.235.141.60.32768 > 666.42.7.11.53: 14 NS? cofls-welt.az. 
(31)
05:12:30.575203 IP 193.235.141.183.32768 > 666.42.7.11.53: 14 NS? 
cofls-welt.lb. (31)
05:12:30.575356 IP 193.235.141.215.32768 > 666.42.7.11.53: 14 NS? conomix.eg. 
(28)
05:12:30.575950 IP 193.235.141.171.32768 > 666.42.7.11.53: 14 NS? 
conomix.net.ps. (32)
05:12:30.577242 IP 193.235.141.90.32768 > 666.42.7.11.53: 14 NS? 
computercheck-online.tn. (41)
05:12:30.577800 IP 193.235.141.134.32768 > 666.42.7.11.53: 14 NS? conomix.cu. 
(28)
05:12:30.578272 IP 193.235.141.177.32768 > 666.42.7.11.53: 14 NS? 
conomix.net.lb. (32)
05:12:30.578480 IP 193.235.141.114.32768 > 666.42.7.11.53: 14 NS? cstreibel.lr. 
(30)
05:12:30.578896 IP 193.235.141.114.32768 > 666.42.7.11.53: 14 NS? 
cstreibel.org.lb. (34)
05:12:30.579060 IP 193.235.141.244.32768 > 666.42.7.11.53: 14 NS? 
cristallcard.az. (33)
05:12:30.580681 IP 193.235.141.11.32768 > 666.42.7.11.53: 14 NS? d-cypher.tn. 
(29)
05:12:30.581812 IP 193.235.141.160.32768 > 666.42.7.11.53: 14 NS? d-cypher.al. 
(29)
05:12:30.582157 IP 193.235.141.162.32768 > 666.42.7.11.53: 14 NS? 
dailycatesse.sz. (33)
05:12:30.582381 IP 193.235.141.142.32768 > 666.42.7.11.53: 14 NS? d-cypher.eg. 
(29)
05:12:30.583340 IP 193.235.141.125.32768 > 666.42.7.11.53: 14 NS? 
damensattel-duesseldorf.net.ps. (48)
05:12:30.583439 IP 193.235.141.181.32768 > 666.42.7.11.53: 14 NS? 
dailycatesse.az. (33)
05:12:30.584078 IP 193.235.141.160.32768 > 666.42.7.11.53: 14 NS? 
dailycatesse.mw. (33)
05:12:30.584330 IP 193.235.141.160.32768 > 666.42.7.11.53: 14 NS? 
dailycatesse.org.al. (37)
05:12:30.584730 IP 193.235.141.3.32768 > 666.42.7.11.53: 14 NS? 
darkroom24.net.al. (35)
05:12:30.585506 IP 193.235.141.7.32768 > 666.42.7.11.53: 14 NS? 
damensattel-duesseldorf.jo. (44)
05:12:30.585995 IP 193.235.141.127.32768 > 666.42.7.11.53: 14 NS? dassehen.lr. 
(29)
05:12:30.587759 IP 193.235.141.173.32768 > 666.42.7.11.53: 14 NS? 
darkroom24.tn. (31)
05:12:30.588076 IP 193.235.141.162.32768 > 666.42.7.11.53: 14 NS? 
dgurock.org.al. (32)
05:12:30.589055 IP 193.235.141.212.32768 > 666.42.7.11.53: 14 NS? dictys.jo. 
(27)
05:12:30.589640 IP 193.235.141.240.32768 > 666.42.7.11.53: 14 NS? dgurock.az. 
(28)
05:12:30.591432 IP 193.235.141.172.32768 > 666.42.7.11.53: 14 NS? 
dictys.com.ps. (31)
05:12:30.592608 IP 193.235.141.213.32768 > 666.42.7.11.53: 14 NS? 
disko-thema.org.al. (36)
05:12:30.593365 IP 193.235.141.247.32768 > 666.42.7.11.53: 14 NS? 
diesling-1.net.al. (35)
05:12:30.593814 IP 193.235.141.147.32768 > 666.42.7.11.53: 14 NS? 
diesling-1.ps. (31)
05:12:30.595057 IP 193.235.141.240.32768 > 666.42.7.11.53: 14 NS? 
disko-thema.net.al. (36)
05:12:30.595722 IP 193.235.141.157.32768 > 666.42.7.11.53: 14 NS? 
disko-thema.xn--mgbayh7gpa. (44)
05:12:30.596496 IP 193.235.141.135.32768 > 666.42.7.11.53: 14 NS? 
downbeat-band.com.lb. (38)
05:12:30.596898 IP 193.235.141.185.32768 > 666.42.7.11.53: 14 NS? 
dj-hc-team.sz. (31)
05:12:30.598077 IP 193.235.141.177.32768 > 666.42.7.11.53: 14 NS? 
dnd-testdomain.net.al. (39)
05:12:30.598203 IP 193.235.141.146.32768 > 666.42.7.11.53: 14 NS? 
dnd-testdomain.net.ps. (39)
05:12:30.598338 IP 193.235.141.215.32768 > 666.42.7.11.53: 14 NS? 
druck-hamster.lr. (34)
05:12:30.599224 IP 193.235.141.168.32768 > 666.42.7.11.53: 14 NS? 
druckerei-hilden.az. (37)
05:12:30.602031 IP 193.235.141.45.32768 > 666.42.7.11.53: 14 NS? 
druckerei-hilden.com.lb. (41)
05:12:30.604763 IP 193.235.141.210.32768 > 666.42.7.11.53: 14 NS? 
drumandy.xn--pgbs0dh. (38)
05:12:30.605420 IP 193.235.141.212.32768 > 666.42.7.11.53: 14 NS? 
dugehoerstmir.tz. (34)
05:12:30.607074 IP 193.235.141.142.32768 > 666.42.7.11.53: 14 NS? 
dugehoerstmir.eg. (34)
05:12:30.607465 IP 193.235.141.152.32768 > 666.42.7.11.53: 14 NS? 
dugehoerstmir.net.lb. (38)
05:12:30.608142 IP 

swedish dns zone enumerator

[Randy Bush]

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 (Ethernet), capture size 262144 bytes
22:42:39.516849 IP 193.235.141.90.32768 > 666.42.7.11.53: 14 NS? 33j4h.org.al. 
(30)
22:42:39.517640 IP 193.235.141.17.32768 > 666.42.7.11.53: 14 NS? 
33m6d.xn--mgbayh7gpa. (38)
22:42:39.519169 IP 193.235.141.17.32768 > 666.42.7.11.53: 14 NS? 33lxd.tn. (26)
22:42:39.520064 IP 193.235.141.171.32768 > 666.42.7.11.53: 14 NS? 33md6.jo. (26)
22:42:39.521081 IP 193.235.141.247.32768 > 666.42.7.11.53: 14 NS? 33lxd.lb. (26)
22:42:39.523981 IP 193.235.141.162.32768 > 666.42.7.11.53: 14 NS? 33pd2.az. (26)
22:42:39.525043 IP 193.235.141.60.32768 > 666.42.7.11.53: 14 NS? 33nc5.com.al. 
(30)
22:42:39.526185 IP 193.235.141.209.32768 > 666.42.7.11.53: 14 NS? 33nc5.sz. (26)
22:42:39.527931 IP 193.235.141.150.32768 > 666.42.7.11.53: 14 NS? 33q5p.com.al. 
(30)
22:42:39.529516 IP 193.235.141.210.32768 > 666.42.7.11.53: 14 NS? 33qbq.com.al. 
(30)
10 packets captured
124 packets received by filter
0 packets dropped by kernel

inetnum:193.235.141.0 - 193.235.141.255
netname:domaincrawler-hosting
descr:  domaincrawler hosting
org:ORG-ABUS1196-RIPE
country:SE
admin-c:VIJE1-RIPE
tech-c: VIJE1-RIPE
status: ASSIGNED PA
notify: c+1...@resilans.se
mnt-by: RESILANS-MNT
mnt-routes: ETTNET-LIR
created:2008-04-03T11:21:00Z
last-modified:  2017-04-10T12:47:06Z
source: RIPE

randy

itojun

[Randy Bush]

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

[Randy Bush]

> 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

[Randy Bush]

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 ?

[Randy Bush]

> 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

[Randy Bush]

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

[Randy Bush]

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

[Randy Bush]

> 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

[Randy Bush]

> 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 the
space: IP, TCP, and so on.  What's been happening over the last few
years is that the IETF is filling the rest of the space with every
alternative approach, not necessarily any better.  Every possible
alternative is now being written down.  And it's not useful.

think of the folk making careers complicating dns, rpki, bgp, ...

randy

jon postel

[Randy Bush]

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

[Randy Bush]

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

[Randy Bush]

> 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 pain-to-maintain list be distributed?  how do i know
a copy is authentic not an attack?

i am all for a single root of trust.  it's just that i thought it was
the iana's job.  but i am easily confused.

randy

Re: Using RFC1918 on Global table as Loopbacks

[Randy Bush]

> 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 mostly seen that ISPs use global IPs for loopbacks on
> devices that would and hold global routing.
>
> My question is, what is the most used or recommended way to do this,
> if I continue to use RFC1918 I will save some very much desired public
> address space, but would this come back to bite me in the future?

loopback addressing does not have to be used for router ids.  so
decouple that consideraton.  make up router ids; 1, 42, 3, 4, ...
whatever.  they just need to be unique within the AS.

< corner case >

you may want to have your loopbacks in real global space for routers
which are on an IX.  i have been having fun where an IX router is
sourcing packets from the IX interface, and responses can not come
back because the IX space is not announced globally.  so one wants
to tell the protocol originating those packets (ntp, dns, whatever)
to source from the loopback.  and, for replies to get back to that
loopback, it needs to be in real global space.

randy

Re: maximum ipv4 bgp prefix length of /24 ?

[Randy Bush]

> 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
ourselves to blame; but blame does not move packets.

randy, who was in the danvers cabal for the /19 agreement

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

[Randy Bush]

perhaps this is not a nanog operational topic 

Re: Lossy cogent p2p experiences?

[Randy Bush]

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

[Randy Bush]

> 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:
> 
>   https://mailchimp.com/help/enable-and-view-click-tracking/
> 
>   "Check the Track clicks box to enable click tracking, or uncheck the
>   box to disable click tracking.  ...  Mailchimp will continue to
>   redirect URLs for users with free account plans to protect against
>   malicious links.  ...  When a paid user turns off click tracking,
>   Mailchimp will continue to redirect their URLs until certain account
>   activity thresholds are met."
> 
> Don't forget to turn off the spyware 1x1 pixel "web bugs" that
> MailChimp inserts by default, too:
> 
>   https://mailchimp.com/help/about-open-tracking/

as usual, the problem is not technical.  there is no need for mailchump
at all.

nanog management has made a very intentional decision to sell my
privacy.  nanog has come a long way, not all of it  good.

randy

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

[Randy Bush]

> *READ MORE
> Last

can we please get URLs without all the invasive tracking?

randy

Re: it's mailman time again

[Randy Bush]

> 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

[Randy Bush]

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

randy

Re: v6 route mess frm AS266970

[Randy Bush]

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

randy

v6 route mess frm AS266970

[Randy Bush]

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

[Randy Bush]

> 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 connectivity, the op's
> question.

i guess the list does not like graphs.  decline of net predicted; news
at eleven.  if you care, unicast.

randy

Re: Internet Exchange Visualization

[Randy Bush]

> 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."  ^_^;

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 connectivity, the op's question.

randy

Re: Dodgy AS327933 ...?

[Randy Bush]

> 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

[Randy Bush]

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

[Randy Bush]

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

but also folk being rude, judgemental, and blaming the user for being
confused by the complex and jargon-infested bureaucrazy we have created
in the rirs.

and yes, props to the rirs for trying to document rules and processes.
but that often seems to create even more documents.  and, of course, if
you have to deal with multiple rirs, expect no parallelism, similar
nomenclature, etc.

it is very easy for a new rir user to get confused by corner cases,
terminology, quirks of history, and the detritus of our amateur policy
wonkage.

give 'em a break.  and see if we can round off the rough edges where
they got caught.

randy

---

note that i use the first person plural

Re: whois server

[Randy Bush]

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

404

whois server

[Randy Bush]

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

[Randy Bush]

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

[Randy Bush]

> 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. Supposedly all of
> the big geolocation providers support it or are planning on supporting
> it.

we're working on an small update.  see

   https://datatracker.ietf.org/doc/draft-ymbk-opsawg-9092-update/

randy

Re: 128/9 cite

[Randy Bush]

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

[Randy Bush]

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 into /24s.  took uunet
down, but not before it propagated.

does anyone have a useful cite?

randy

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

[Randy Bush]

> 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

[Randy Bush]

> 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 be the first rat off the sad westin ship

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

[Randy Bush]

> "small mounting shelf"

we use mounting shelves for all sorts of recalcitrant devices

randy

Re: Reverse DNS for eyeballs?

[Randy Bush]

> 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

[Randy Bush]

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

[Randy Bush]

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

[Randy Bush]

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

[Randy Bush]

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

three of the promises of ipng which ipv6 did not deliver
  o compatibility/transition,
  o security, and 
  o routing & renumbering

the real goal of those who made the ipv6 decision was to stop the press
from screaming about the end of the internet.  in this they succeeded.

and the ops community has paid an insane penalty ere since.

randy

Re: Geoip database update

[Randy Bush]

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

[Randy Bush]

darn shame there is no general automatable mechanism for this

randy

Re: AS3356 Announcing 2000::/12

[Randy Bush]

> 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 over in a receiving large provider.

do not hard code social theories.  remember 640k.

randy

Re: AS3356 Announcing 2000::/12

[Randy Bush]

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

[Randy Bush]

[ 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 'detected?'  i.e. from what vantage point?

is it safe to assume that your outbound announcements to your two
upstreams are stable?

of course, if you would care to divulge a prefix showing this symptom,
folk might be able to find clues.

randy

---
ra...@psg.com
`gpg --locate-external-keys --auto-key-locate wkd ra...@psg.com`
signatures are back, thanks to dmarc header butchery

afrinic rpki issue

[Randy Bush]

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:
https://packetvis.com/#/bgp/event/905ec8b7d37e89a2d7b547bca99fd57e-372b0bf3-9056-407e-9e8d-e986567155fc/4f309cb51ba9314fafa64da53d007e342faca613

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

[Randy Bush]

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

[Randy Bush]

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

[Randy Bush]

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

[Randy Bush]

> 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

[Randy Bush]

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
https://asiajin.com/blog/2007/10/jun-ichiro-itojun-hagino-dies-at-37-ipv6-developer-and-evangelist/

abha

[Randy Bush]

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

randy

Re: jon postel

[Randy Bush]

> Does anyone have any stories about working with or near John they
> would like to share with the list? It would definitely make my day
> to hear more about the early internet

somewhere around i have a protocol violation ticket he issued.

---

Who says that routing unallocated address space is ungood?  -- Randy Bush
Routing unallocated address space is ungood!  -- Jon Postel

randy

Re: jon postel

[Randy Bush]

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 IETF is filling
the rest of the space with every alternative approach, not necessarily any
better.  Every possible alternative is now being written down.  And it's not
useful.  -- Jon Postel

jon postel

[Randy Bush]

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 ?

[Randy Bush]

< 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 have classful filters in A and B space.

and a soda pop used to be a nickel or a dime.  those days are long
gone.

i expect that we will accept prefixes longer than /24 as things get
tighter.  and i doubt we can socialize constraining that fragmentation
to one section of the space.

it is a tragedy that cidr and an open market has helped us more than
ipv6 has.

randy

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

[Randy Bush]

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

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

[Randy Bush]

>>  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; just in case there are other mis-matches between
  arin's positions and community needs ]

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

> 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 improve
> its clarity regarding the ability to distribute the ARIN TAL.

so carefully worded

the following is a binary question.  yes or no, please

  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?

randy

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

[Randy Bush]

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

> Do we trust the FCC to come up with an industry wide fool proof
> (whatever that means) security standard?

note that the DHS funded the development of both dns and routing
security technology.  otoh, as other cultures, clue is not evenly
distributed.

the first step is said to be admitting one has a problem.

randy

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

[Randy Bush]

> 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 dropping invalid routes.

to remind, ROV is a safety mechanism, not a security mechanism.  it is
proving, as intended, to mitigate mistakes.  which is very cool.  but it
does not mitigate attacks of any sophistication.

randy

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

[Randy Bush]

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

[Randy Bush]

> 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

[Randy Bush]

enke and jenny yuan cleaned this up in 6286

randy

Re: Router ID on IPv6-Only

[Randy Bush]

> 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

[Randy Bush]

> 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 configured interface address.

randy

Re: End of Cogent-Sprint peering wars?

[Randy Bush]

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

[Randy Bush]

> 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.  amusing at best.

randy

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

[Randy Bush]

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

[Randy Bush]

new at eleven

Re: HE.net and BGP Communities

[Randy Bush]

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

[Randy Bush]

> 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

[Randy Bush]

> 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

[Randy Bush]

> 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