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

Request for credits for research
by Mohan, Nitinder 20 Apr '21

20 Apr '21

Dear RIPE community, I hope you are all safe and sound. I am a Postdoctoral fellow at the Technical University of Munich, Germany. We are currently working on an ongoing research project which aims to analyze the availability and reachability of cloud data centers globally. The first work of our work will appear in ACM HotNets 2020 titled "Pruning Edge Research with Latency Shears" (http://conferences.sigcomm.org/hotnets/2020/program.html). We are currently preparing the camera-ready version of the paper and will share it with the community by hosting it (and the associated dataset) publicly soon. We are currently planing to submit the second leg of our work to a conference with submission deadline a month. In order to complete all set of measurements for required analysis, we are scheduling very large-scale measurements over the platform which has burned through almost all our credits and left us in need. I have always found the RIPE Atlas community to be helpful and generous towards research and I am hoping that you could support our research by donating us some of your spare credits. Your help will be highly appreciated. My RIPE account is nitinder.mohan(a)helsinki.fi Thanks and Regards Nitinder Mohan Postdoctoral Fellow Technical University of Munich, Germany <http://www.cs.helsinki.fi/u/nmohan/>https://www.nitindermohan.com/

15 18

Join the RIPE NCC Open House: Internet in Turkey: 24 February 2021, 11:00 UTC
by Vesna Manojlovic 26 Feb '21

26 Feb '21

Dar all, You're invited for an open discussion with the RIPE NCC about the Internet in Turkey! We are hosting a RIPE NCC Open House for our members and other Internet stakeholders in Turkey on Wednesday, 24 February at 11:00 - 12:30 UTC and invite you to join the discussion. The RIPE NCC Open House is a ninety minute remote session where RIPE NCC staff, community members and industry experts can meet up and share insights, feedback and support. https://www.ripe.net/participate/meetings/open-house This session is focusing on the Turkish Internet community. We will be discussing various topics including: * The state of the Internet in Turkey and across our service region * How RIPE NCC tools and measurements can help operators (RIPE Atlas, RIPEstat, RIPEIPmap, etc.) * Improvements that the RIPE NCC can make to help operators in Turkey * IPv6 deployment * Local community development and the support available from the RIPE NCC Want to join in? Register for the RIPE NCC Open House https://meeting-registration.ripe.net/meeting-pub/registration?0&meetingId=… Looking forward to seeing you online! Regards, Vesna Manojlovic Community Builder RIPE NCC

2 3

New on RIPE Labs: RIPE Atlas Big Data is Back
by Alun Davies 23 Feb '21

23 Feb '21

Dear colleagues, At the beginning of the year, RIPE Atlas users started encountering delays in data retrieval and an overall drop in the responsiveness of the system. With service having gone back to normal earlier this month, we take a look at what caused the problem and what we're doing prevent it from happening again: https://labs.ripe.net/Members/paul_de_weerd/ripe-atlas-big-data-is-back Kind regards, Alun Davies RIPE Labs Editor RIPE NCC

1 0

Re: [atlas] [mat-wg] RIPE Atlas testing of reserved IPv4 addresses
by Robert Kisteleki 18 Feb '21

18 Feb '21

Dear All, A little bit of poking since there were no reactions to this question on the MAT mailing list. Before embarking on evaluating what it takes for RIPE Atlas to contribute to this, I'd like to ask for some input from the community; is this something we should spend energy on? More specifically, would it be worthwhile for us to spend time on evaluating the cost of / implementing such measurements in RIPE Atlas? Regards, Robert Kisteleki On 2021-01-26 08:28, Seth David Schoen wrote: > Hi mat-wg, > > I'm Seth, formerly a staff technologist at EFF and one of the > co-developers of Let's Encrypt and Certbot. > > Recently, I've been working with John Gilmore on the IPv4 Unicast > Extensions Project, which aims to make some of the IPv4 address blocks > that were reserved in the 1980s and 1990s (and that continue to be unused, > or nearly so) available for addressing and routing on the Internet. > > This project involves many different kinds of work, including writing > software patches to make various OSes and devices willing to generate > and accept packets to reserved addresses, writing Internet-Drafts to > describe addressing policy changes with IETF, testing devices to see how > they actually treat such packets, talking to various constituencies > about these proposals, and working with the Internet measurement > community to understand how the Internet as a whole treats packets to or > from currently-reserved address ranges, and how that treatment evolves > over time. > > Two prominent examples that are already supported by Linux hosts are the > netblocks 0/8 ("this network") and 240/4 ("experimental"/"future use"). > According to Internet standards created in the 1980s and still in > effect, these address ranges cannot be allocated and should not be > assigned to hosts or used on the public Internet. However, several key > implementations started allowing 240/4 addresses about 11 years ago > during an earlier IETF attempt to open up that netblock, including > Linux, Android, macOS, iOS, and Solaris. In 2019, Linux kernel version > 5.3 allowed ordinary unicast use of 0/8. Today, there are rumors that > various organizations are currently using such reserved addresses as > unofficial RFC 1918-like private address space, without formal policy > coordination with anyone. (There is even some public documentation from > Google suggesting making private use of 240/4.) > > I participated in the Atlas probe deployathon in November and > successfully got a probe up and running. I have also been talking to > a few RIPE people about our interests and managed to confirm that > (regardless of their underlying OS or network treatment) the Atlas > software probes will reject probing any reserved address space, while > the backend infrastructure will refuse to ask probes to connect to it. > > So, I'm here to introduce our project and ask the community's view about > removing these restrictions so that such addresses can actually be > probed and measured. We understand and hope that the majority of such > tests would currently result in errors. Even the errors themselves > could be interesting: for example, we would like to know how often > routing to reserved address ranges fails on a probe host, versus on the > probe host's first-hop router, versus inside of ISP infrastructure. We > would also like to see how this changes over time as a result of OS > software changes that roll out into the field. We would also like to > see whether we can detect unofficial use of particular reserved address > ranges as private address space. Our medium-term goal is to advertise > global routes to portions of these reserved address spaces, and use the > probes to assess how well those routes propagate through the Internet, > and find where blockages occur. Clearly, we can't do this until both > the probe firmware, and the central dispatcher, allow tests to these > addresses. Our long-term goal is to have these addresses treated as > ordinary unicast addresses by all nodes, including Atlas probes, so the > Atlas changes to remove the restrictions would be useful permanent > changes. > >

12 16

RIPE Atlas Measurements packets sent number not always 16
by Debora Marettek 17 Feb '21

17 Feb '21

Dear RIPE NCC, for my ping measurements, I incremented the number of sent packets to 16. Now I noticed that in the measurement with the ID 28779821, the probes didn't always send 16 packets, sometimes, albeit rarely, only 7 or 3. Below you see an extract of the packets_sent data of Probe 52673. Now I wanted to ask what could possibly be the reason for that phenomena. Kind regards, Debora Probe: 52673 16, 16, 16, 16, 16, 16, 16, 16, 16, 16, 16, 16, 16, 16, 16, 16, 16, 5, 1, 9, 16, 16, 16, 14, 16, 16, 16, 16, 8, 13, 6, 7, 6, 6, 16, 16, 12, 16, 16, 16, 16, 16, 10, 11, 10, 7, 6, 16, 4, 16, 16, 16, 16, 4, 7, 15, 6, 9, 12, 11, 7, 8, 11, 6, 5, 13, 13, 13, 5, 10, 16, 16, 7, 7, 9, 7, 7, 7, 9, 16, 16, 11, 4, 7, 16, 7, 2, 8, 16, 4, 6, 8, 16, 7, 8, 6, 5, 8, 8, 9, 8, 7, 4, 3, 10, 1, 2, 11, 6, 16, 8, 12, 6, 11, 10, 11, 8, 12, 12, 12, 11, 8, 16, 6, 5, 5, 9, 10, 6, 10, 7, 9, 10, 9, 11, 8, 8, 11, 7, 12, 7, 11, 9, 13, 2, 10, 12, 10, 7, 9, 16, 13, 5, 4, 7, 8, 6, 5, 7, 6, 7, 9, 9, 9, 16, 16, 16, 16, 16, 16, 16, 16, 16, 16, 16, 16, 16, 16, 16, 16, 16, 16, 16, 16, 16, 16, 16, 16, 16, 16, 16, 16, 16, 16, 16, 16, 16, 16, 16, 16, 16, 16, 4, 9, 4, 6, 8, 6, 11, 16, 16, 16, 16, 16, 16, 16, 16, 16, 16, 16, 16, 16, 16, 16, 16, 16, 16, 16, 16, 16, 16, 16, 16, 16, <https://atlas.ripe.net/measurements/28931367/>

1 0

Re: [atlas] Updating probe ssh pub keys via API PUT/PATCH requests
by Chriztoffer Hansen 15 Feb '21

15 Feb '21

Hi RIPE Atlas, Was reading through the documentation yesterday... Is there a specific reason why it is NOT possible to update probe (ssh) pub keys via authenticated API PUT/PATCH requests? https://beta-docs.atlas.ripe.net/apis/metadata-reference/ -- Best regards, Chriztoffer Hansen

3 3

Measurement Result Broken
by r.sommese＠utwente.nl 10 Feb '21

10 Feb '21

Hi everyone, I am getting trouble getting results for ping measurements. Looking at the web portal and JSON results, they are both empty. Measurement ID: 29049476 I also checked from the account of a colleague, same story. There is something broken in the pipeline? Best, Raffaele Sommese

5 5

Is there a way to de-register a long dead probe?
by Kyriacos Sakkas 09 Feb '21

09 Feb '21

Hi All, Can't seem to find a way to just mark a long dead probe as such. Thanks, Kyriacos

3 6