March 2022 - ripe-atlas - mailman.ripe.net

Requesting Credits for Research
by Alex Gamero-Garrido 29 Jul '23

29 Jul '23

Hi folks, My name is Alexander Gamero-Garrido and I'm a 5th year PhD student at CAIDA, UC San Diego. We're soon launching a large traceroute campaign for research and could use your generous donation of credits. We'll need about 150 million credits, but any partial amount that gets us closer to that goal is welcome and greatly appreciated. My account is agamerog at eng.ucsd.edu Thank you, Alex -- *Alex Gamero-Garrido* *PhD Student, Computer Science* Web: cseweb.ucsd.edu/~agamerog Center for Applied Internet Data Analysis (CAIDA) San Diego Supercomputer Center UC San Diego Pronouns: He/Him/His <https://inboxwhenready.org/?utm_campaign=signature&utm_medium=email&utm_sou…> I'm using Inbox When Ready <https://inboxwhenready.org/?utm_campaign=signature&utm_medium=email&utm_sou…> to protect my focus.

13 15

Probe DHCPv6 support
by Aleksi Pirttimaa 19 May '23

19 May '23

Hi! I recently received my v4 probe and I'm very happy with it. But unfortunately it doesn't support DHCPv6. I present a practical reason for implementing a DHCPv6 client on the probe. You see, my ISP doesn't send router advertisements with the prefix for stateless autoconfiguration set, and instead DHCPv6 must be used. I believe their decision could have something to do with the fact that the regulating body here requires ISP's to prevent IP address spoofing in consumer plans. And to meet that requirement my ISP may be using a feature similar to Cisco's IP source guard, where switch ports and/or mac addresses are passively associated to leased ip's or prefixes, breaking SLAAC. Unfortunately they hate letting consumers talk with their engineers so it's difficult to speculate this further. For now, I've put a stateful firewall appliance in front of the probe which provides SLAAC, it works just fine. Do you think a DHCPv6 client should be implemented?

8 13

Overuse of software probes
by Ponikierski, Grzegorz 30 Jun '22

30 Jun '22

Hello all! Software probes is great improvement for Atlas environment and it made deployments so much easier and more scalable. One of my probes is also software probe on Raspberry Pi. However, me and my team noticed that sometimes software probes are overused and make measurements more cumbersome to interpret. For example we found that there 4 software probes in AWS Johannesburg [1] and 15 software probes in Hostinger Sao Paulo [2]. That's total overkill. These 15 probes in Hostinger Sao Paulo is 21% of all connected probes in Brazil. All of them delivers practically the same results so without additional data filtering (which is not easy) they can dramatically skew final results for Brazil. With this I would like to open discussion how to handle this situation. Please share your thoughts about these questions: * How can we standardize data filtering for such case? * How to proactively and automatically detect overuse of probes? * How can we encourage software probes hosts to avoid deployments in data centers which are already covered by Atlas? * How to give incentives to deploy probes in data centers without existing probes? [1] 4 software probes inside AWS Johannesburg: 1000707<https://atlas.ripe.net/frames/probes/1000707/> 1001397<https://atlas.ripe.net/frames/probes/1001397/> 1002066<https://atlas.ripe.net/frames/probes/1002066/> 1002632<https://atlas.ripe.net/frames/probes/1002632/> [2] 15 software probes inside Hostinger Sao Paulo 1003554<https://atlas.ripe.net/frames/probes/1003554/> 1003555<https://atlas.ripe.net/frames/probes/1003555/> 1003556<https://atlas.ripe.net/frames/probes/1003556/> 1003557<https://atlas.ripe.net/frames/probes/1003557/> 1003558<https://atlas.ripe.net/frames/probes/1003558/> 1003559<https://atlas.ripe.net/frames/probes/1003559/> 1003560<https://atlas.ripe.net/frames/probes/1003560/> 1003561<https://atlas.ripe.net/frames/probes/1003561/> 1003562<https://atlas.ripe.net/frames/probes/1003562/> 1003563<https://atlas.ripe.net/frames/probes/1003563/> 1003564<https://atlas.ripe.net/frames/probes/1003564/> 1003565<https://atlas.ripe.net/frames/probes/1003565/> 1003566<https://atlas.ripe.net/frames/probes/1003566/> 1003567<https://atlas.ripe.net/frames/probes/1003567/> 1003568<https://atlas.ripe.net/frames/probes/1003568/> Regards, Grzegorz Ponikierski

13 19

My probe's not doin' IPv6
by Edward Lewis 23 Apr '22

23 Apr '22

General question… My probe was doing IPv6 until 15 July 2021 but not it is not. Is there any way to discover why it is no longer IPv6’ing? I did change my ISP connection equipment about that time, so something did change on my end. But IPv6 works for other devices. When I go to www.ripe.net <http://www.ripe.net/> it tells me I came from an IPv6 address. The device has been pretty steady - 99.71% the last week, 99.91% for the last month (30days). It was off-line 29 minutes earlier today (the notice made me think to look), but never off line more than 10 minutes since mid-July. There’s one stretch of 34d+ of continuous uptime. Run-of-the-mill home connection via a cableTV company. Is there anyway to ask a probe why it doesn’t have an IPv6 address (via DHCP)? Ed

5 7

RIPE Atlas Quarterly Planning Q2 2022
by Robert Kisteleki 31 Mar '22

31 Mar '22

Dear colleagues, We are now publishing our quarterly planning for RIPE Atlas. This is available at: https://www.ripe.net/support/documentation/quarterly-planning/ripe-atlas The goals of publishing our planning are to be transparent about the work we will be carrying out in the coming months, to get your input on those plans, and hear what you would like to see the RIPE NCC work on going forward. We will provide status updates as the work progresses and add input from the community to the pages. We will also archive previous plans so you can track how we progress with our work. If you have any input on our plans or want to let us know what you would like to see us work on, please let us know. Kind regards, Robert Kisteleki Research and Development Manager RIPE NCC

1 0

New on RIPE Labs: Bias in Internet Measurement Infrastructure
by Alun Davies 28 Mar '22

28 Mar '22

Dear colleagues, In this new article on RIPE Labs, Pavlos Sermpezis talks about analysing bias in the Internet measurement infrastructures like RIPE Atlas and RIPE RIS. Are these infrastructures biased? How much of a problem is it if they are? What does bias even look like here? Find out more: https://labs.ripe.net/author/pavlos_sermpezis/bias-in-internet-measurement-… Kind regards, Alun Davies RIPE Labs Editor RIPE NCC

1 0

RIPE NCC Open House: Feedback on our Unified User Interface
by Michela Galante 28 Mar '22

28 Mar '22

Dear colleagues, On Wednesday 6 April from 10:00 to 11:30 UTC, we invite users of RIPE Atlas, RIPE Database, RIPE Labs, RIPE NCC Academy, LIR Portal, RPKI and RIPEstat to give us feedback on our unified user interface. This Open House session will focus on the user interface that was launched in 2020. Our goal is to unify the user experience across all platforms to make it easier and faster for users to navigate our services. You can register for the event at: https://meeting-registration.ripe.net/meeting-pub/registration?0&meetingId=… More information is available on our website: https://www.ripe.net/participate/meetings/open-house/ripe-ncc-open-house-fe… Best regards, Michela Galante RIPE NCC

1 0

problem reusing probes
by Cristel Pelsser 28 Mar '22

28 Mar '22

Hi, I have a problem reusing probes from previous measurements. I’m launching experiments in pairs from the web interface. I would like to retrieve the probes selected randomly in one experiment for another measurement that takes place at the same time. My problem is that it takes time to show the measurement I created in the list of "my measurements". Even when all measurements are shown in the list of all "my measurements", the creation interface does not find all these measurement ids. So I cannot retrieve the probes I need. Is there an access problem to the measurement DB or am I doing something wrong? Cristel

1 0

Problem with DoT measurements?
by Stephane Bortzmeyer 24 Mar '22

24 Mar '22

DoT measurements seem partially broken, only 10 % of the probes do report. (See for instance #39675721.)

2 1

Facebook in Russia and a diagnostic problem
by Stephane Bortzmeyer 14 Mar '22

14 Mar '22

Around half of the RIPE Atlas probes in Russia cannot complete a TLS session with facebook.com <https://atlas.ripe.net/measurements/39387725/>. (All the remaining tests have been done with the same set of probes, 'type': 'msm', 'value': '39387725'.) They have no problem with YouTube <https://atlas.ripe.net/measurements/39387839>. I also did TLS tests with IP addresses instead of names, same result <https://atlas.ripe.net/measurements/39387985> <https://atlas.ripe.net/measurements/39388031>. There is no lying DNS resolver <https://atlas.ripe.net/measurements/39387902>. But traceroute show no connectivity problem either, we can go to the Facebook AS from Russia <https://atlas.ripe.net/measurements/39388122> <https://atlas.ripe.net/measurements/39388176>. So, I'm a bit lost: what do we observe? It does not look like censorship but not like a connectivy issue (because of depeering by Cogent and Lumen) either.

6 7