Weekly Global IPv4 Routing Table Report

[Routing Table Analysis Role Account]

This is an automated weekly mailing describing the state of the Global
IPv4 Routing Table as seen from APNIC's router in Japan.

The posting is sent to APOPS, NANOG, AfNOG, SANOG, PacNOG, SAFNOG
TZNOG, MENOG, BJNOG, SDNOG, CMNOG, LACNOG and the RIPE Routing WG.

Daily listings are sent to bgp-st...@lists.apnic.net.

For historical data, please see https://thyme.apnic.net.

If you have any comments please contact Philip Smith .

IPv4 Routing Table Report   04:00 +10GMT Sat 04 Mar, 2023

  BGP Table (Global) as seen in Japan.

Report Website: https://thyme.apnic.net
Detailed Analysis:  https://thyme.apnic.net/current/

Analysis Summary


BGP routing table entries examined:  915877
Prefixes after maximum aggregation (per Origin AS):  346961
Deaggregation factor:  2.64
Unique aggregates announced (without unneeded subnets):  446240
Total ASes present in the Internet Routing Table: 74173
Prefixes per ASN: 12.35
Origin-only ASes present in the Internet Routing Table:   63640
Origin ASes announcing only one prefix:   26126
Transit ASes present in the Internet Routing Table:   10533
Transit-only ASes present in the Internet Routing Table:445
Average AS path length visible in the Internet Routing Table:   4.3
Max AS path length visible:  55
Max AS path prepend of ASN (265020)  50
Prefixes from unregistered ASNs in the Routing Table:  1039
Number of instances of unregistered ASNs:  1055
Number of 32-bit ASNs allocated by the RIRs:  41345
Number of 32-bit ASNs visible in the Routing Table:   34262
Prefixes from 32-bit ASNs in the Routing Table:  167731
Number of bogon 32-bit ASNs visible in the Routing Table:39
Special use prefixes present in the Routing Table:1
Prefixes being announced from unallocated address space:532
Number of addresses announced to Internet:   3063466752
Equivalent to 182 /8s, 152 /16s and 203 /24s
Percentage of available address space announced:   82.7
Percentage of allocated address space announced:   82.7
Percentage of available address space allocated:  100.0
Percentage of address space in use by end-sites:   99.6
Total number of prefixes smaller than registry allocations:  306375

APNIC Region Analysis Summary
-

Prefixes being announced by APNIC Region ASes:   242621
Total APNIC prefixes after maximum aggregation:   69112
APNIC Deaggregation factor:3.51
Prefixes being announced from the APNIC address blocks:  237131
Unique aggregates announced from the APNIC address blocks:97910
APNIC Region origin ASes present in the Internet Routing Table:   13342
APNIC Prefixes per ASN:   17.77
APNIC Region origin ASes announcing only one prefix:   3892
APNIC Region transit ASes present in the Internet Routing Table:   1801
Average APNIC Region AS path length visible:4.5
Max APNIC Region AS path length visible: 26
Number of APNIC region 32-bit ASNs visible in the Routing Table:   8617
Number of APNIC addresses announced to Internet:  773691776
Equivalent to 46 /8s, 29 /16s and 153 /24s
APNIC AS Blocks4608-4864, 7467-7722, 9216-10239, 17408-18431
(pre-ERX allocations)  23552-24575, 37888-38911, 45056-46079, 55296-56319,
   58368-59391, 63488-64098, 64297-64395, 131072-151865
APNIC Address Blocks 1/8,  14/8,  27/8,  36/8,  39/8,  42/8,  43/8,
49/8,  58/8,  59/8,  60/8,  61/8, 101/8, 103/8,
   106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8,
   116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8,
   123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8,
   163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8,
   203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8,
   222/8, 223/8,

ARIN Region Analysis Summary


Prefixes being announced by ARIN Region ASes:267916
Total ARIN prefixes after maximum aggregation:   121637
ARIN Deaggregation factor: 2.20
Prefixes being announced from the ARIN address blocks:   270075
Unique aggregates announced from the ARIN address blocks:130267
ARIN Region origin ASes present in the Internet Routing Table:19058
ARIN Prefixes per ASN:  

Re: Request for comments

[Etienne-Victor Depasquale via NANOG]

I've updated the graphic

with one other data point and increased the graphic's size (following
feedback).

In particular, I'd like to understand why there are so many operators who
consider Active Ethernet (p2p)
to be their largest and/or fastest growing access technology.

Would anyone care to give an opinion / interpretation / perspective / other
?

Cheers,

Etienne

On Wed, Mar 1, 2023 at 9:24 AM Etienne-Victor Depasquale 
wrote:

> Good people of NANOG,
>
> Please find here
> 
> a snapshot of two datasets concerning access technologies in the metro area.
>
> The bar chart on the right summarizes data I collected last year from
> *NOGs;
> the bar chart on the left summarizes data received last year from Tier 1
> and/or regional operators (incumbents).
> The y-axis shows cumulative responses for an option; the x-axis shows
> (hopefully unambiguous) monikers for the access technologies.
>
> Would anyone care to comment on how well this matches his/her perception
> of the current state of deployments?
>
> Cheers,
>
> Etienne
>
> --
> Ing. Etienne-Victor Depasquale
> Assistant Lecturer
> Department of Communications & Computer Engineering
> Faculty of Information & Communication Technology
> University of Malta
> Web. https://www.um.edu.mt/profile/etiennedepasquale
>


-- 
Ing. Etienne-Victor Depasquale
Assistant Lecturer
Department of Communications & Computer Engineering
Faculty of Information & Communication Technology
University of Malta
Web. https://www.um.edu.mt/profile/etiennedepasquale

Mail Sending Self-Test Platform

[Tobias Fiebig]

Heho,

after our paper on mail sending configurations some time ago [1], we
now glued that together into a self-service site: 

https://email-security-scans.org/

Even though some of you might have already seen this at the APNIC blog
or on other lists, i though i'd still drop it here as well, especially
given that it includes a full IPv6 readiness test for mail infra
(recursive DNS, authoritative DNS, and v6 mail delivery ;-)).

I'd be happy to hear your feedback, especially if things do not work as
expected (then, your test ID and ideally stored emails would be really
helpful, so i can double check what went wrong). More details below
(also see [2] for an overview of the tests we run). 

Please note that setting up the tests (as we have to configure vhosts
for some MTA-STS cases etc.) takes some time on our site. The test-site
should periodically reload and provide the status. As we use JS for
that part, please reload it manually every few minutes if you block JS.

I would also be interested to hear what you think should be included in
addition to the current tests; Some of our plans for the future below
as well.

We already found some interesting bits, like Vultr having lame v6
delegation for their AuthNS servers' domain, making their domain and
rDNS non v6-resolvable [3], or mail-in-a-box using relaxed/simple for
DKIM, which breaks signature validity on long To: headers [4].

If you want me to block certain domains/IPv(4|6) ranges or ASes for the
service to keep your users from using it, please let me know and i will
implement it asap.

# Overview

The site tests a variety of parameters about mail sending (details:
[2]), by evaluating mails a user sends us in reply to a message that
can be requested on the site. Simply requesting a message on the site
does not start any evaluation or measurements, i.e., you have to send a
reply-all to a requested message to start the evaluation. After the
test, you can also delete the test or download a copy of your data, and
if you opted to do so, a copy of the emails as we received them.

# Method

Users send emails to us (in reply-all to a message we sent, for easier
usability).Target MXes on our site are either configured in a fully RFC
compliant way, or intentionally misconfigured in a common way (broken
DNSSEC for the domain, for example, or a broken DANE record, again, see
[2] for an overview). Thereby, we can determine the
configuration/support of features by the senders' MXes.

# Possible Harm

The worst thing that should happen to mail operators is finding
specific undeliverable mails (broken DNSSEC if DNSSEC is validated, v6
only DNS if no IPv6 DNS resolution is supported) in their mail queue,
or users receiving bounces (see FAQ on the page). So far the system has
been tested with several hundred mail-setups, without encountering
issues. If you encounter other unintended side-effects, please reach
out to ab...@email-security-scans.org or me directly off-list.

# Test details

Specifically, we are testing:
- v4 Mail sending
- v6 Mail sending
- Greylisting support

- Transport encryption (Plaintext/TLS cipher strength and version
support, opportunistic encryption)
- DANE support outbound, i.e., if you honor DANE
- MTA-STS support outbound, i.e., if you honor MTA-STS (incl. whether
you prefer DANE over MTA-STS, as it should be)
- Sending of TLS reports and whether these are standard compliant, also
providing a copy of the received report (Even though so far only three
operators delivered TLS-RPT).

- DNS resolvers used by the mailserver
- Whether the mailers' DNS servers resolve via IPv6
- Whether the mailers' DNS servers validate DNSSEC

- If all names relevant for email delivery resolve via IPv6
- If all names relevant for email delivery are DNSSEC signed

- Mailer-basics (ehlo=rdns=fcrdns), SPF (from/envelope)
- SPF policy size (by retrieving your policy, up to 20 referrals deep)
- DKIM (also checking key-sizes, algorithm mismatches and
canonicalization issues; These are surprisingly common, i.e., simple
being set breaking only in cases not caught by standard dkim testers)
- DMARC (policy validity, conformance of sent mails, displaying
implicit defaults)
- DMARC report deliverability by sending one(1) valid DMARC report for
a received email, including authorization of out-of-domain RUA/RUF
(also providing a copy of any bounces received)

- Full IPv6 readiness (join over three previous IPv6 tests)

- Whether any headers that should not be duplicated are duplicated
- Whether any mandatory headers are missing
- If From/Envelope match

# Planned tests

- ARC
- evaluate outbound spam filtering
- evaluate received_from stripping
- test for inbound-link parsers
- cluster by provider (via MTA sets), not domain
- Add DANE checks for senders' MXes
- test for host-addresses in SPF prefixes
- add MTA-STS check for senders' domains
- add test for handling more than 5 MX with only the lowest-prio one(s)
being reachable
- requesting-domains' MX aspects (null MX, IPv4/6