April 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

TLSv1.3 Support
by Antonios Chariton 23 Apr '22

23 Apr '22

I’ve ran a measurement against a host that only support TLSv1.3 ( https://atlas.ripe.net/measurements/40393656/#probes ) and all probes came back with "Error: protocol_version”. Do they not support the latest version of TLS? I only seem to be able to get them to work with TLSv1.2 or lower. Thanks, Antonios

1 0

json with all probes
by Cristel Pelsser 23 Apr '22

23 Apr '22

Hi, Can someone point me to the location of the json file with all the probes and their properties? Cristel

2 2

Moving on
by Philip Homburg 06 Apr '22

06 Apr '22

Hi Atlas Users, After ten years at the RIPE NCC it is time for me to move on. Normally, that is not something that would be announced on a public mailing list. However, I get quite a bit of email that is directly sent to me. This is to let you know that I will not be able to read future email sent to this address. I have two new colleagues who will work on probe firmware development. They are Guy Meyer <gmeyer(a)ripe.net> and Michel Stam <mstam(a)ripe.net>. I'm sure they will be happy to help. As for me, I will be <philip(a)nlnetlabs.nl> from now on. Philip Homburg

3 2