- mat-wg - mailman.ripe.net

Value of RIPEstat routing-history full-peers-seeing
by John Kristoff 04 May '21

04 May '21

The RIPEstat Data API for the Routing History call includes a key output field "full-peers-seeing". It is described this way: The number of RIS full-feed peers that saw this route. Often times the value is not a whole number. I'm wondering why that may be the case and how I should interpret it. Hopefully this is as good a place as any to ask the question and get an answer archived for posterity. Thanks in advance for any insight. John

2 1

New on RIPE Labs: An Eventful Ten Years in RIPEstat
by Alun Davies 19 Apr '21

19 Apr '21

Dear colleagues, RIPEstat turns 10 this May! To mark the occasion on RIPE Labs, we've taken a look back at how RIPEstat has helped us get a clearer picture of the way the Internet fared in the event of outages, blackouts, natural disasters, and Nyan Cat. You can read the full article on RIPE Labs now: https://labs.ripe.net/author/alun_davies/an-eventful-ten-years-in-ripestat/ Kind regards, Alun Davies RIPE Labs Editor RIPE NCC

1 0

New on RIPE Labs: Does The Internet Route Around Damage? - Edition 2021
by Alun Davies 14 Apr '21

14 Apr '21

Dear colleagues, In this new article on RIPE Labs, to investigate whether the Internet routes around damage in 2021, Emile Aben carries out an analysis of the impact of the recent LINX London outage. The full article is available now on the new and improved RIPE Labs: https://labs.ripe.net/author/emileaben/does-the-internet-route-around-damag… Kind regards, Alun Davies RIPE Labs Editor RIPE NCC

1 0

Call for Presentations MAT-WG RIPE 82, 19th of May 21
by Nina Bargisen 08 Apr '21

08 Apr '21

Dear Colleagues We are working on putting together the agenda for the virtual MAT-WG meeting at the RIPE 82 meeting. MAT-WG will take place Wednesday the 19th of May 2021 13:00-14:00. We still have a couple of 10 min slots in the agenda, so if you are interested in presenting some of your work please reach out to the chairs at mat-wg-chairs(a)ripe.net as soon as possible We are looking forward to meeting virtually again in May Thanks Brian & Nina MAT WG chairs

1 0

New on RIPE Labs: Measuring DNS over TLS from the Edge
by Alun Davies 29 Mar '21

29 Mar '21

Dear colleagues, In a study aimed at understanding the availability of DoT and how it performs for end users, Trinh Viet Doan and colleagues have been measuring DoT adoption, reliability, and response times with RIPE Atlas. Read the results on RIPE Labs: https://labs.ripe.net/Members/trinh_viet_doan/measuring-dns-over-tls-from-t… Kind regards, Alun Davies RIPE Labs Editor RIPE NCC

1 0

New on RIPE Labs: Splitting the Ping
by Alun Davies 24 Mar '21

24 Mar '21

Dear colleagues, Pings provide a simple measure of how long it takes to get there and back across the Internet. What's not so simple is working out how long the trip there took versus the trip back. In this guest post on RIPE Labs, Ben Cox introduces a method for splitting the ping: https://labs.ripe.net/Members/ben_cox/splitting-the-ping Kind regards, Alun Davies RIPE Labs Editor RIPE NCC

1 0

From Data Ethics to Data Justice: RIPE Labs article about Data Feminism
by Vesna Manojlovic 11 Mar '21

11 Mar '21

Dear all, On 8. March, for International Women’s Day, we published an article on RIPE Labs about data science from an intersectional feminism perspective: https://labs.ripe.net/Members/becha/data-feminism-from-data-ethics-to-data-… In the article, I explore how the RIPE community can benefit from involving users in the design processes for collecting, storing and visualising data. As network operators, we have the power to create systems that use data for good, or for harm - and I am pointing out the questions to be asked about challenging and changing those structures. For the MAT-WG specifically, there are other interesting links: open data sources for researchers; code available for developers to re-use, and there is potential for cooperation with the academic community. Regards, Vesna Manojlovic Community Builder RIPE NCC

1 0

RIPE Atlas measurements documentation wiki
by Emile Aben 15 Feb '21

15 Feb '21

Dear all, We're trying something new! We have a part of our public RIPE Atlas github pages dedicated to documenting RIPE Atlas measurements better. Read all about it, including an example around measuring RPKI repositories, of how this is useful here: https://labs.ripe.net/Members/emileaben/tracking-rpki-repository-performanc… or directly go to the 'RIPE Atlas measurements bundles' wiki: https://github.com/RIPE-Atlas-Community/ripe-atlas-tips-and-tricks/wiki/Mea… Kind regards, Emile Aben RIPE NCC

1 0

RIPE Atlas testing of reserved IPv4 addresses
by Seth David Schoen 26 Jan '21

26 Jan '21

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.

1 0

Address Assignment Practices in IPv4 and IPv6
by Stephen D. Strowes 21 Jan '21

21 Jan '21

Hi all, We've published a study on the stability of IPv4/IPv6 assignments in domestic ISPs, and the size of the IPv6 prefixes that networks typically assign to subscribers. We look at this from two different angles: what can we measure from RIPE Atlas, and what do operators state in the RIPE Database? In particular, understanding the size of IPv6 delegated prefixes is important for applications such as host reputation & blocklists, geolocation, and research on network measurement. The RIPE Database offers the community a way to share information on their prefix delegations, and deserves some attention! Read more here: https://labs.ripe.net/Members/stephen_strowes/address-assignment-practices-… Cheers, S.

1 0