tl;dr: the survey is at https://pch.net/survey
Background:
Every five years, beginning in 2011, PCH has conducted a comprehensive
global survey characterizing Internet peering agreements. They are the only
ones of their kind, and are relied upon not only by network operators, but
also by legislators and regulators throughout the world to understand the
Internet interconnection landscape.
Our write-ups of the prior surveys can be found here:
https://www.pch.net/resources/Papers/peering-survey/PCH-Peering-Survey-2011…https://www.pch.net/resources/Papers/peering-survey/PCH-Peering-Survey-2016…https://www.pch.net/resources/Papers/peering-survey/PCH-Peering-Survey-2021…
…and video of the NANOG presentation of the 2016 results is here:
https://www.youtube.com/watch?v=lPuoBmxyXMc
At the time of the 2011 survey, we committed to repeating the survey every
five years, to provide time-series data about the direction peering trends
take. We’re now conducting the fourth iteration of the survey.
Among other things, the surveys have helped establish a better understanding
of trends in:
• The increasingly uniform global norms of interconnection
• National preferences within the network operator community for country
of governing law
• The long tail of small networks which don’t yet support IPv6 routing
• The significance of multilateral peering agreements in the density of
the interconnection mesh
These findings, particularly the first, have been invaluable in giving
regulators in the vast majority of the world’s countries a data-driven basis
for refraining from prescriptively regulating Internet interconnection. They
have demonstrated in objective terms that the Internet self-regulates in a
way that’s more globally uniform and closely harmonized than any
coordination of national regulatory bodies could accomplish.
Participation:
The survey is global in scope, and our goal is to reflect the diversity of
peering agreements in the world. Your participation ensures that your norms
and ways of doing business are represented accurately and proportionately in
the dataset. If you don’t participate, the way you do business will be less
well-represented in the data, and will seem less normal to regulators and
policy-makers. We’re interested in large ISPs and small ISPs, ISPs in
Afghanistan and in Zimbabwe, bilateral agreements and multilateral, private
and public. Our intent is to be as comprehensive as possible. In 2011, the
responses we received represented 41% of the world’s ISPs, across 96
countries; in 2016, 65% of the world’s ISPs, across 148 countries; in 2021,
76% of the world’s ISPs across 192 countries. Our aim is to be equally
inclusive this year.
Since our principal method of soliciting participation is via NOG mailing
lists, I’m afraid many of you will see this message several times, on
different lists, for which we apologize in advance.
Privacy:
In 2011, 2016, and 2021, we promised to collect the smallest set of data
necessary to answer the questions, to perform the analysis immediately, and
not to retain the data after the analysis was accomplished. In that way, we
ensured that the privacy of respondents was fully protected. We did as we
said, no data was leaked, and the whole community benefited from the trust
that was extended to us. We ask for your trust again now as we make the same
commitment to protect the privacy of all respondents, using the same process
as was successfully employed the last three times. We are asking for no more
data than is absolutely necessary. We will perform the analysis immediately
upon receiving all of the data. We will delete the data once the analysis
has been performed.
The Survey:
We would like to know your Autonomous System Number, and the following five
pieces of information relative to each other AS you peer with:
• Your peer’s ASN (peers only, not upstream transit providers or
downstream customers)
• Whether a written and signed peering agreement exists (the alternative
being a less formal arrangement, such as a "handshake agreement")
• Whether the terms are roughly symmetric (the alternative being that they
describe an agreement with different terms for each of the two parties,
such as one compensating the other, or one receiving more or fewer than
full customer routes)
• What jurisdiction of governing law is defined, if any
• Whether IPv6 routes are being exchanged (this year, we’ll still assume
that IPv4 are)
The easiest way for us to receive the information is as a tab-text or CSV
file or an Excel spreadsheet, consisting of rows with the following columns:
Your ASN: Integer
Peer ASN: Integer
Written agreement: Boolean [true,1,yes,y] or [false,0,no,n]
Symmetric: Boolean [true,1,yes,y] or [false,0,no,n]
Governing Law: ISO 3166 two-letter country-code, or empty
IPv6 Routes: Boolean [true,1,yes,y] or [false,0,no,n]
For instance:
42 <tab> 715 <tab> false <tab> true <tab> us <tab> true <cr>
42 <tab> 3856 <tab> true <tab> true <tab> us <tab> true <cr>
We need the ASNs so we can avoid double-counting a single pair of peers when
we hear from both of them, and so that when we hear about a relationship in
responses from both peers we can see how closely the two responses match, an
important check on the quality of the survey. As soon as we've collated the
data, we'll strip the ASNs to protect privacy, and only the final aggregate
statistics will be published. We will never disclose any ASN or any
information about any ASN. We'd like to finish collecting data in the first
week of October, about two weeks from now.
If you’re peering with an MLPA route-server, you’re welcome to include just
the route-server’s ASN, if that’s easiest, rather than trying to include
each of the peer ASNs on the other side of the route-server. Either way is
fine.
If all of your sessions have the same characteristics, you can just tell us
what those characteristics are once, your own ASN once, and give us a simple
list of your peer ASNs.
If your number of peers is small enough to be pasted or typed into an email,
rather than attached as a file, and that’s simpler, just go ahead and do
that.
If you have written peering agreements that are covered by non-disclosure
agreements, or if your organizational policy precludes disclosing your
peers, but you’d still like to participate in the survey, please let us
know, and we’ll work with whatever information you’re able to give us and
try to ensure that your practices are statistically represented in our
results.
If you're able to help us, please email me the data in whatever form you
can. If you need a non-disclosure, we're happy to sign one.
Finally, if there are questions you’d like us to try to answer when we
analyze the data, please suggest them, and if there are any additional
questions you’d like us to include in future iterations of the survey,
please let us know so that we can consider including them in the 2031
survey.
Please respond by submitting your survey at https://pch.net/survey or
emailing it to me directly (woody(a)pch.net, not replying to the NOG mailing
list), by the second week of October.
Thank you for considering participating. We very much appreciate it, and we
look forward to returning the results to the community.
-Bill Woodcock
Secretary General
Packet Clearing House
#### Dutch (English below) ####
Mogelijk weten de meeste het al, maar op 11.10.2026 wordt routinematig het sleutelpaar van de DNS root vervangen (een zogenaamde "rollover").
Dat betekent dat vanaf dit moment DNS resolvers die DNSSEC handtekeningen valideren, de nieuwe publieke sleutel moeten vertrouwen. Zo niet, kunnen binnen 48 uur na de rollover validatiefouten bij de resolver optreden. Uiteindelijk zal de resolver geen enkele DNS query meer succesvol resolven.
SIDN vindt DNSSEC nogal belangrijk en we raden daarom iedereen die een resolver beheert en DNSSEC validatie aan heeft staan, om te controleren of zijn/haar resolver de nieuwe sleutel ondersteunt.
De meeste resolver software zal de nieuwe sleutel al vertrouwen (bijvoorbeeld door een software update of omdat de software RFC 5011 ondersteunt).
Resolver software heeft verschillende manieren om te controleren welke sleutel ze vertrouwen.
De nieuwe sleutel heeft het ID 38696, de oude sleutel 20326.
Beneden wat voorbeelden:
unbound:
Gebruik de tool 'dig':
` dig @jouw.resolver.ip trustanchor.unbound -c CH -t TXT `
powerdns:
Gebruik rec_control om de sleutel IDs op te vragen:
`rec_control get-tas`
bind:
In veel gevallen configureert bind een `bind.keys` bestand.
Daarin zou de nieuwe sleutel opgevoerd moeten zijn.
Op de website van ICANN staat nog meer informatie hierover:
https://www.icann.org/resources/pages/ksk-rollover-en
Groet,
Moritz
Research Engineer SIDN Labs
#### English ####
Most of you may already be aware, but on October 11, 2026, the DNS root key pair will undergo a routine replacement (a so-called "rollover").
This means that from that moment on, DNS resolvers that validate DNSSEC signatures must trust the new public key. If they do not, validation errors may occur at the resolver within 48 hours of the rollover. Eventually, the resolver will fail to successfully resolve any DNS queries.
SIDN considers DNSSEC very important; we therefore recommend that anyone managing a resolver with DNSSEC validation enabled checks whether their resolver supports the new key.
Most resolver software will already trust the new key (for example, due to a software update or because the software supports RFC 5011).
Resolver software uses various methods to check which keys are trusted.
The new key has ID 38696; the old key ID is 20326.
Some examples are provided below:
unbound:
Use the 'dig' tool:
` dig @your.resolver.ip trustanchor.unbound -c CH -t TXT `
powerdns:
Use rec_control to query the key IDs:
`rec_control get-tas`
bind:
In many cases, BIND uses a `bind.keys` configuration file.
The new key should be listed there.
Further information is available on the ICANN website:
https://www.icann.org/resources/pages/ksk-rollover-en
Regards,
Moritz
Research Engineer SIDN Labs
In response to feedback from operational security communities,
CAIDA's source address validation measurement project
(https://spoofer.caida.org) is automatically generating monthly
reports of ASes originating prefixes in BGP for systems from which
we received packets with a spoofed source address.
We are publishing these reports to network and security operations
lists in order to ensure this information reaches operational
contacts in these ASes.
This report summarises tests conducted within nld.
Inferred improvements during Aug 2026:
none inferred
Source Address Validation issues inferred during Aug 2026:
ASN Name First-Spoofed Last-Spoofed
3920 PUSHPKT 2023-10-06 2026-08-29
35316 PRODACOM 2025-12-17 2026-08-24
60781 LEASEWEB-NL-AMS-01 2026-02-08 2026-08-28
906 DMIT 2026-03-14 2026-08-02
6206 NETROUTING 2026-04-30 2026-08-28
Further information for these tests where we received spoofed
packets is available at:
https://spoofer.caida.org/recent_tests.php?country_include=nld&no_block=1
Please send any feedback or suggestions to spoofer-info(a)caida.org
Hi all,
My employer (Leaseweb) is organizing https://techsummit.io/agenda-and-speakers-2026/ this year in Pakhuis de Zwijger in Amsterdam, on the 30th of September.
It's less network focused but goes into infrastructure/development/operations, talks are selected via a cfp / technical committee, and there is no marketing involved in selecting content.
We sell tickets to make sure people show up (and donate proceeds to Bits of Freedom), but I'd like to give out a bunch of tickets to the community / interested people. If you want to come (or you have coworkers/etc who are interested), ping me off-list with the amount of tickets you'd like to have, and i'll send you a voucher so you and yours can get in for free. As with all events, be reasonably certain you'll come if you register as to not waste catering and goodies :)
Cheers,
Robert
--
Robert van der Meulen
nlnog(a)wiretrip.org
