November 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

Is there a procedure to move a software probe to a new device
by Peter Garner (iPad) 01 Feb '22

01 Feb '22

Noob question. I set up my software probe on a Debian 10 box which has quite a few small servers on it. However, I intend to move it onto a Raspberry Pi, so I was wondering if there's a specific procedure to follow to preserve existing settings? Only the internal IP address will change; the external remains the same.

6 7

RIPE Atlas VM Anchors IPv6 only support?
by Chriztoffer Hansen 13 Dec '21

13 Dec '21

Hello, On Thu, 8 Nov 2018 at 15:35, Alun Davies <adavies(a)ripe.net> wrote: > We just this morning published an article announcing that, as of today, we are accepting applications for anyone interested in hosting RIPE Atlas VM anchors. The article points you to all the information you’ll need to apply for and install a virtual anchor: > > https://labs.ripe.net/Members/alun_davies/announcing-ripe-atlas-vm-anchors I was reading through the list of requirements for hosting RIPE Atlas VM Anchors as of Nov 2021. • https://atlas.ripe.net/docs/anchor-installation-vm/ • https://atlas.ripe.net/legal/anchors/memorandum/ > Network-wise, RIPE Atlas VM anchors have the following requirements: > • The anchor must have native IPv4 and IPv6 (if IPv6 is announced in the host ASN) > • Static IPv4 and IPv6 addresses need to be unfiltered (not firewalled) > • The VM anchor may require up to 10 Mbit bandwidth (it currently requires much less) >From the requirements, I glean if a network is not able to provide an unfiltered/non-firewalled IPv6 address to the VM. IPv6 is not a requirement if not used within the applying host ASN. Only an unfiltered public IPv4 address is. What about the reverse situation? ↪ I.e. the host ASN applying for hosting a VM Anchor is an IPv6-only ASN. Not utilizing IPv4 in the ASN. Therefore not able to provide an unfiltered IPv4 address to the VM? To my current understanding, the latter example is an instant disqualification if applying for hosting a RIPE Atlas VM Anchor? /Chriztoffer

2 3

Inconsistencies in anchor API and measurements
by Malte Appel 17 Nov '21

17 Nov '21

Hi everyone, sorry in advance for the long mail. tl;dr: Anchor API and UI give inconsistent results. Some anchor mesh measurements could be fixed, some might target non-anchors. Not sure what to do about it. I am currently working a lot with RIPE Atlas and recently wanted to use the anchors and their mesh measurements in particular. I wanted to answer two simple queries: 1. Get a list of all active anchors 2. Get a list of all active anchor mesh and probe measurements (traceroute, for my particular use case) However, while trying to answer these queries, I stumbled upon quite some inconsistencies, depending on which interface / API is used. As far as I can tell there are four ways in which one could technically answer query 1: 1. Look at the website: https://atlas.ripe.net/anchors/list/ -> 840 results 2. Query the /anchors API with attribute is_disabled = false: https://atlas.ripe.net/api/v2/anchors/?is_disabled=false -> 844 results 3. Query the /probes API with attributes is_anchor = true and status = 1 (Connected): https://atlas.ripe.net/api/v2/probes/?is_anchor=True&status=1 -> 729 results 4. Query the /probes API with attributes tags = system-anchor and status = 1 (Connected): https://atlas.ripe.net/api/v2/probes/?tags=system-anchor&status=1 -> 729 results Methods 3 and 4 are actually consistent! The main discrepancy is between the /anchors and /probes API: 116 anchors that are listed on the webpage and/or /anchors API as ‘active’ are inactive (97 abandoned; 19 disconnected at time of writing) according to their respective /probes entry. I understand that disconnects might be temporary, but some anchors seem to be inactive for years (at least according to their status) and are still listed as active. I have attached a text file with some notes that go deeper into the differences, but might be hard to read. For query 2, I faced a similar situation: 1. Look at the website: https://atlas.ripe.net/anchors/list/full/ Anchoring Mesh IPv4: 840 Anchoring Mesh IPv6: 739 Anchoring Probes IPv4: 840 Anchoring Probes IPv6: 705 Total: 3124 2. Query the /anchor-measurements API Anchoring Mesh IPv4: 849 Anchoring Mesh IPv6: 743 Anchoring Probes IPv4: 902 Anchoring Probes IPv6: 753 Total: 3247 3. Query the /measurements API with attributes status = 2 (Ongoing), type = traceroute and corresponding attributes: Anchoring Mesh IPv4: af = 4; tags=anchoring,mesh Anchoring Mesh IPv6: af = 6; tags=anchoring,mesh Anchoring Probes IPv4: af = 4; tags=anchoring,probes Anchoring Probes IPv6: af = 6; tags=anchoring,probes For example: https://atlas.ripe.net/api/v2/measurements/?status=2&type=traceroute&af=6&t… Anchoring Mesh IPv4: 1026 Anchoring Mesh IPv6: 902 Anchoring Probes IPv4: 668 Anchoring Probes IPv6: 619 Total: 3215 These results are even more mixed: - Tags can be inconsistent: Some measurements have none, some have the ‘probes’ or ’mesh’ tag, but miss the ’anchoring’ tag. - Some anchors have multiple measurements (especially probes measurements), of which most actually are run by the same set of probes, i.e., they are duplicates. - Which measurements are contained in which of the three result sets is very mixed, maybe I should draw a Venn diagram :) Finally, I looked at the consistency of the IP addresses of the /anchors API (ip_v4 and ip_v6), the /probes API (address_v4, address_v6), the DNS result for the FQDN of the anchors, and the target IP of the mesh/probes measurements. I noticed some problems, since our lab (IIJ) also operates an anchor (probe 6425 [0]) and we updated the IP address some time ago, but are actually not reached by the mesh measurement, because the measurement still targets the old IP. I attached a CSV that includes the raw data (of measurements with some form of problem), but basically there are 93 measurements from connected anchors that fail, and out of which 68 (from 29 anchors) could work, if the measurement would target the correct IP. These measurements have matching anchor/probe IPs and DNS records, so I do not know why the measurement target is stale. There are some additional measurements that could work, but it is unclear what the intended ‘correct’ IP is. On that note, there are 48 measurements that ‘work‘, i.e., they get a response from the target, but it is not clear if the target is the intended receiver: - 8 target abandoned anchors - 18 have different probe and anchor IPs and target one of them - 21 have the same probe and anchor IP but target something else Again, I am sorry for this long mail. I understand that RIPE Atlas is a huge project that has grown over time so it might be hard to keep some things synchronized, and some other things might not be easily decidable (e.g., when to mark an anchor is inactive). However, I think especially the IP address of an anchor in the /anchors and /probes APIs, in the DNS entry, and the target of the mesh/probes measurements need to be consistent. Currently some mesh measurements might target an entirely different machine. I wanted to bring some attention to this, but not sure what else I can do as a user. I don‘t want to complain too much :) For now I will just use all data sources as input and apply some sanity checks. Best, Malte P.S.: Some feedback on how we can bring the measurement of our anchor to target our anchor would be nice though. [0] https://atlas.ripe.net/probes/6425

2 2

RIPE measurement Credits required
by Mccherry, Paul (Student) 02 Nov '21

02 Nov '21

Dear All I have applied and been granted to install an Anchor at my University to generate credits to make measurements, this is taking some time to prepare the equipment etc. In the meantime I need to carry out some measurement tests for a paper I am working on. Would anybody be able to kindly send me some RIPE credits which I will hopefully pay back once I have the anchor up and running ? Regards Paul McCherry Phd Student From: ripe-atlas-request(a)ripe.net<mailto:ripe-atlas-request@ripe.net> Sent: 25 October 2021 23:07 To: ripe-atlas(a)ripe.net<mailto:ripe-atlas@ripe.net> Subject: [External] ripe-atlas Digest, Vol 122, Issue 6 This email originated outside the University. Check before clicking links or attachments. Send ripe-atlas mailing list submissions to ripe-atlas(a)ripe.net To subscribe or unsubscribe via the World Wide Web, visit https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.rip… or, via email, send a message with subject or body 'help' to ripe-atlas-request(a)ripe.net You can reach the person managing the list at ripe-atlas-owner(a)ripe.net When replying, please edit your Subject line so it is more specific than "Re: Contents of ripe-atlas digest..." Today's Topics: 1. RIPE Atlas Virtual Anchor Application (TNaumann(a)telekom.de) ---------------------------------------------------------------------- Message: 1 Date: Mon, 25 Oct 2021 22:06:40 +0000 From: <TNaumann(a)telekom.de> To: <ripe-atlas(a)ripe.net> Subject: [atlas] RIPE Atlas Virtual Anchor Application Message-ID: <FR2P281MB0775F27CBE4C9FAC283EC010A6839(a)FR2P281MB0775.DEUP281.PROD.OUTLOOK.COM> Content-Type: text/plain; charset="iso-8859-1" Dear Ripe Atlas Team, Could we have any estimation about our application for the first virtual anchor in New York? We would like to have a physical and virtual probe at the same time and recycle/reuse the physical later this Year somewhere else in U.S. [cid:image001.png@01D7C9FD.22665680] Kind Regards Thomas Naumann Deutsche Telekom Technik GmbH Network Infrastructure (T-NWI) Thomas Naumann Ginnheimer Stadtweg 88, 60431 Frankfurt am Main +49 69 20060 4042 (Phone) +49 170 3374602 (Mobil) E-Mail: TNaumann(a)telekom.de<mailto:TNaumann@telekom.de> https://eur02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.teleko…<https://eur02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.teleko…><https://eur02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.teleko…> Erleben, was verbindet. Die gesetzlichen Pflichtangaben finden Sie unter: https://eur02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.teleko…<https://eur02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.teleko…><https://eur02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.teleko…> Gro?e Ver?nderungen fangen klein an - Ressourcen schonen und nicht jede E-Mail drucken.

10 15