- ripe-atlas - mailman.ripe.net

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

Measurement suggestions for new deployments.
by Gerardo Huerta Robles 18 May '23

18 May '23

Hello all, I'm a newbie with RIPE ATLAS Probes, We are currently working on deploying a new Probe network in Nicaragua as the first step for a measurement project. The second step will be to capture statistics of traffic to the internet, but we are not clear what kind of targets are the most relevant for internet statistics. I would like to ask you for suggestions of targets, what kind of public servers are relevant for user internet traffic? We are thinking of DNS servers like 8.8.8.8 or some public HTTP web pages like the government or social media like Facebook, youtube and so on. But what do you think? Do you have some advice? The project is intended to obtain the first statistics about internet traffic and make it public using RIPE Probes and schedule measurements. If you have some advice please let me know, Thank you. Regards

1 0

RIPE Anchor updates?
by John Howard 16 May '23

16 May '23

Hi folks, Proton hosts 3 RIPE Anchors (7120, 6847, 6854) and during routine vulnerability scanning we identified these appliances running nginx 1.20.1, which is potentially vulnerable to two CVEs (CVE-2022-41741 and CVE-2022-41742). Given the mp4 module pre-req, I doubt they are vulnerable in practice, but this highlighted that the nginx 1.20 train was deprecated 11 months ago, and 1.23/1.24 are the currently active releases. I note the last probe firmware update 5080 (which we run already) from Nov/22 disabled auto updates on the appliances, so I assume there will be regular updates coming from RIPE going forward instead? Thanks John -- John Howard Head of Network Infrastructure Proton AG Sent with Proton Mail secure email.

2 3

Request RIPE Atlas Credit for Research
by 卫蕴泽 28 Apr '23

28 Apr '23

Dear all, Greetings! I'm a senior student at Tsinghua University, China. Recently I'm working on my graduation project, which is a IP infrastructure mapping research that requires large-scale network measurement via RIPE Atlas to verify my method. However, a simple traceroute with 6 probes need 10K+ credits. As a new user I don't have any credit to proceed, and I've no time to earn them by myself. So I'm here to ask for help. Is it possible for anyone generous enough to offer me some RIPE Atlas credits (like, 10M)? My account at RIPE NCC is fenglan.chn(a)gmail.com, my education email is weiyz19(a)mails.tsinghua.edu.cn and my student ID is 2019011285. Many thanks for your help! Sincerely, Yunze Wei

6 6

a link for comparing DNS resolvers
by Michael Rabinovich 04 Apr '23

04 Apr '23

Folks, FYI, Nick Kernan, my Masters student, has deployed a web portal that facilitates the comparison between various DNS resolvers, including ISP-provided and some influential publicly available resolvers (Google’s public DNS, OpenDNS, Quad9, and Cloudflare). The comparison is based on two factors: the latency of DNS resolutions and the latency of TCP handshake with the CDN edge server selected through a given resolver. The results are based on recurrent monthly measurements from RIPE Atlas probes that have both IPv4 and v6 connectivity, have an ISP-provided resolver available for comparison, and which meet certain requirements regarding probe versions and reliability. You can specify the desired month of measurement, a region of interest, and the CDNs to analyze. You can access Nick’s portal through https://dns-web-portal.netlify.app/ <https://dns-web-portal.netlify.app/> The details of the methodology are in Nick’s thesis, which awaits some copyright permissions before being made publicly available. In the meantime, Nick (cc’ed) and I would be happy to answer any questions. Regards, —Misha Rabinovich

4 4

RIPE Atlas Quarterly Planning Q2 2023
by Robert Kisteleki 30 Mar '23

30 Mar '23

Dear colleagues, We’ve now published our quarterly planning for RIPE Atlas. These are available at: https://www.ripe.net/support/documentation/quarterly-planning/ripe-atlas This quarter, we'll continue the discussion on five proposals for changing RIPE Atlas behaviour and work on restructuring and renewing pages of the user interface. 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 RIPE NCC

1 0

Planned Maintenance: RIPE Atlas streaming API, 28-03-2023, 9.00am - 10.00am UTC
by Marco Giuliani 27 Mar '23

27 Mar '23

Hello, We will carry out planned maintenance on the RIPE Atlas streaming API. During this time, existing HTTP sessions will be briefly interrupted. Start: March, 28th, 2023 - 9.00am UTC End: March, 28th, 2023 - 10.00am UTC Kind regards, Marco Giuliani RIPE NCC

1 0

Join the DNS Hackathon on 20 and 21 May in Rotterdam (weekend before RIPE 86)
by Vesna Manojlovic 21 Mar '23

21 Mar '23

Dear colleagues, I am pleased to invite you to participate in the DNS hackathon that will take place the weekend before RIPE 86 at Ahoy in Rotterdam, on Saturday 20 May and Sunday 21 May 2023. The hackathon is organised by DNS-OARC, Netnod and the RIPE NCC and offers projects based on three challenges: DNS &... Sustainability Security (and privacy) Sovereignty You can also bring your own idea or project. To participate, apply here: https://www.ripe.net/participate/forms/apply/dns-hackathon-2023/ (first deadline is on Thursday, 23 March 2023) Read more at: https://www.netnod.se/join-the-dns-hackathon-2023 Feel free to share this invitation with your communities. Regards, Vesna Manojlovic -- Senior Community Builder, RIPE NCC https://labs.ripe.net/author/becha/

1 0

HTTP measurement proposals [CDN-HTTP] [GENERIC-HTTP] [PEERING-HTTP]
by Ethan Katz-Bassett 06 Mar '23

06 Mar '23

Hi Robert, all: I was considering emailing about the possibility of HTTP measurements to our PEERING <https://peering.ee.columbia.edu/> testbed when I stumbled on the five proposals that Robert posted in December. I want to express my strong support for the two HTTP proposals. Hourly [CDN-HTTP] would be great (eventually with HTTPS support). ([STARTTLS] also sounds good, but I haven't thought deeply about it, and [ONLY-PUBLIC] sounds good unless it costs RIPE Atlas support / probe hosts) I was wondering about the feasibility of allowing HTTP measurements towards PEERING experiments (meaning, towards our address space announced from an experiment via our routers). Is that something that you might be open to supporting? This came to mind because we are in the process of onboarding PEERING to some bring-your-own-prefix services offered by CDNs and cloud providers, and so an increasing number of PEERING experiments are about content delivery/cloud hosting, and it would be great if RIPE Atlas could act as measurement clients to provide widespread vantage points. One hands-off option that comes to mind is to set them up similar to the proposal for CDN-HTTP, where probes will regularly fetch an object at a fixed URL, say http://ripeatlas.ee.columbia.edu/testobject. Normally, that could resolve to our project webserver, which is hosted in AWS. When an experiment needs this HTTP capability (all experiments undergo review by at least 2 people for safety, and we enable only the capabilities they request and need, following the principle of least privilege), we could instead redirect it to a PEERING address allocated to the project that would host the same test object but that would be announced from cloud/CDN/PEERING sites however the experiment had configured. Alternatively, it could be a measurement available to approved accounts, and we could pass on which experiments are approved, or perhaps available to all accounts. We have fixed address space, if you have a way to whitelist. We maintain our list of prefixes as RS-PEERING-TESTBED on RIPE's IRR. I believe Johan recently contacted Kevin Vermeulen about talking to us about RIPE Atlas in the context of another one of our projects, so possibly we can have a discussion covering both topics. Thanks for all your work providing the platform -- it's great! Ethan -- http://www.columbia.edu/~ebk2141/

1 0

Errors on Measurement web interface
by ripe＠brite.cz 01 Mar '23

01 Mar '23

Hi team, I see issues with Latencymon, such as https://atlas.ripe.net/measurements/48750273/#latencymon Upon opening it displays message "Server is responding slowly", after a while it displays the default view. But when I expand the time range a bit, or make any change to the view, it will show nothing and after a while displays message "It is not possible to download data from the API" Tried Firefox and Chrome, same result. The same result when I open only the frame, such as https://atlas.ripe.net/frames/measurements/48750273#latencymon

2 1