AS212271 C1V Cinzia Tocci trading as Lumanex Srl

AS overview

Test target: 2a05:4140:4::12 · ns1.root.cheap-vpn.uk · address space: unknown · prefixes announced: 15

prefix(es): 2a05:4140:3::/48, 2a05:4140:34::/48, 2a05:4140:55::/48, 2a05:4140:62::/48, 2a05:4140:4::/48, 2a05:4140:60::/48, 2a05:4140:58::/48, 2a05:4140:20::/48 (+7 more)

Targets & per-vantage-point probe results (6 target(s) across 3 vantage point(s))

Source codes (hover any badge for full description): CUR=curated · NS/SOA/MX=DNS records · SPF=SPF TXT · DRV=holder-derived (www, ns1, mail, gw, …) · ATL=RIPE Atlas · PDB=PeeringDB · WHOIS=RIPE whois · RDAP=RIPE RDAP · HIT=IPv6 Hitlist · RTR=in-prefix path hop (router) · PRB=static prefix probe · SYN=synthetic prefix::1 fallback

Target IP / hostname	Source	NL host (go6lab)					ITA host (Karsolink)					SLO host (6connect)
Target IP / hostname	Source	ping	1500B	:80	:443	reached	ping	1500B	:80	:443	reached	ping	1500B	:80	:443	reached
`2a05:4140:3::26a1` c1vhosting.it	SPF	✓	✓	open	open	✓	✓	✓	open	open	✓	✓	✓	open	open	✓
`2a05:4140:3::26a2` c1vhosting.it	SPF	✓	✓	open	open	✓	✓	✓	open	open	✓	✓	✓	open	open	✓
`2a05:4140:3::30` dns1.c1vhosting.it	whois	✓	✓	?	?	✓	✓	✓	refused	refused	✓	✓	✓	refused	refused	✓
`2a05:4140:3::500` smokeping.c1vhosting.it	whois	✓	✓	open	open	✓	✓	✓	open	open	✓	✓	✓	open	open	✓
`2a05:4140:4::12` ns1.root.cheap-vpn.uk	NS	✓	✓	open	open	-	✓	✓	open	open	-	✓	✓	open	open	-
`2a05:4140:4::13` ns2.root.cheap-vpn.uk	NS	✓	✓	open	open	-	✓	✓	open	open	-	✓	✓	open	open	-

RPKI & ASPA

15 of 15 prefix(es) covered by a valid ROA.

Prefix	RPKI state	Reason	Covering VRP(s)
`2a05:4140:3::/48`	✓ valid	matched VRP (correct origin, length within maxLength)	AS212271 /48 maxLen 48 (ripe); AS212271 /29 maxLen 48 (ripe)
`2a05:4140:34::/48`	✓ valid	matched VRP (correct origin, length within maxLength)	AS212271 /48 maxLen 48 (ripe); AS212271 /29 maxLen 48 (ripe)
`2a05:4140:55::/48`	✓ valid	matched VRP (correct origin, length within maxLength)	AS212271 /29 maxLen 48 (ripe)
`2a05:4140:62::/48`	✓ valid	matched VRP (correct origin, length within maxLength)	AS212271 /29 maxLen 48 (ripe)
`2a05:4140:4::/48`	✓ valid	matched VRP (correct origin, length within maxLength)	AS212271 /48 maxLen 48 (ripe); AS212271 /29 maxLen 48 (ripe)
`2a05:4140:60::/48`	✓ valid	matched VRP (correct origin, length within maxLength)	AS212271 /29 maxLen 48 (ripe)
`2a05:4140:58::/48`	✓ valid	matched VRP (correct origin, length within maxLength)	AS212271 /29 maxLen 48 (ripe)
`2a05:4140:20::/48`	✓ valid	matched VRP (correct origin, length within maxLength)	AS212271 /29 maxLen 48 (ripe)
`2a05:4140:2::/48`	✓ valid	matched VRP (correct origin, length within maxLength)	AS212271 /29 maxLen 48 (ripe)
`2a05:4140:54::/48`	✓ valid	matched VRP (correct origin, length within maxLength)	AS212271 /29 maxLen 48 (ripe)
`2a05:4140:59::/48`	✓ valid	matched VRP (correct origin, length within maxLength)	AS212271 /29 maxLen 48 (ripe)
`2a05:4140:63::/48`	✓ valid	matched VRP (correct origin, length within maxLength)	AS212271 /29 maxLen 48 (ripe)
`2a05:4140:1a::/48`	✓ valid	matched VRP (correct origin, length within maxLength)	AS212271 /29 maxLen 48 (ripe)
`2a05:4140:11::/48`	✓ valid	matched VRP (correct origin, length within maxLength)	AS212271 /29 maxLen 48 (ripe)
`2a05:4140:61::/48`	✓ valid	matched VRP (correct origin, length within maxLength)	AS216409 /48 maxLen 48 (ripe); AS212271 /29 maxLen 48 (ripe)

ASPA: this AS has published an ASPA record listing 5 upstream provider(s) that are authorized to propagate routes from it: AS174, AS39120, AS49245, AS57142, AS216309. Routes from this AS that arrive via any other upstream are considered ASPA-invalid by validators that enforce ASPA.

Random-IP probe (yarrp) into the AS' prefixes

At least one router inside AS212271's announced prefix replied during the random-target probe. Hop(s): 2a05:4140:2::2, 2a05:4140:3::720, 2a05:4140:63::1. These are candidate targets for direct testing.

ICMPv6 Type 2 (Packet Too Big) acceptance - active test

Vantage points disagree about Type 2 acceptance - transit ASes on one path may be filtering Type 2 even though the destination's stack accepts it on another path:

NL host (go6lab): Type 2 honored. Forged PTB accepted; next response shrunk. (ICMPv6 Echo + forged PTB)
ITA host (Karsolink): Type 2 partial. Some shrinkage but not down to 1280 bytes. (TLS handshake + forged PTB)
SLO host (6connect): Type 2 honored. Forged PTB accepted; next response shrunk. (ICMPv6 Echo + forged PTB)

Why they disagree - different probe methods: These vantages picked different probe methods, so their verdicts are not directly comparable. The active test tries methods in order (icmp6-echo → dns-tcp → tls → http) and stops at the first that produces a definitive verdict; if the chosen method differs, the underlying evidence differs too. Most often this is because the path PMTU on one vantage is below 1500 B, so the natural Echo Reply is already fragmented and the icmp6-echo method falls through to a TCP-based one. This is largely a measurement artifact, not a destination-behaviour difference.

Failure detail — what to grep in your logs

vantage	our source	your target	method	result	tested (UTC)
go6lab	`2a00:8642:42::75`	`2a05:4140:4::12`	`icmp6-echo`	honored	2026-05-30T12:45:24Z
karsolink	`2a12:d8c0:105a:9001::a154`	`2a05:4140:4::12`	`tls`	partial	2026-05-30T12:54:03Z
odin	`2607:fae0:a000::42`	`2a05:4140:4::12`	`icmp6-echo`	honored	2026-05-30T12:45:09Z

Attempt log (go6lab):

icmp6-echo → honored (size_before=1460, size_after=None)
dns-tcp → inconclusive (size_before=175, size_after=None): max DNS-over-TCP segment 175B; not big enough to test PMTU shrink
tls → not_honored (size_before=2403, size_after=2401)
http → inconclusive (size_before=394, size_after=None): natural max segment 394B already <= 1220B; nothing to shrink

Attempt log (karsolink):

icmp6-echo → no_echo: no Echo Reply to 1300-byte probe
dns-tcp → inconclusive (size_before=156, size_after=None): max DNS-over-TCP segment 156B; not big enough to test PMTU shrink
tls → partial (size_before=2401, size_after=1428)
http → inconclusive (size_before=394, size_after=None): natural max segment 394B already <= 1220B; nothing to shrink

Attempt log (odin):

icmp6-echo → honored (size_before=1460, size_after=None)
dns-tcp → inconclusive (size_before=156, size_after=None): max DNS-over-TCP segment 156B; not big enough to test PMTU shrink
tls → not_honored (size_before=2403, size_after=2401)
http → inconclusive (size_before=394, size_after=None): natural max segment 394B already <= 1220B; nothing to shrink

To match the corresponding ICMPv6 packet on your side (host firewall, AS edge, or transit tap), look for our PTBs around the timestamps above:

sudo tcpdump -i any -n -e 'icmp6 and ip6[40] = 2 and (src host 2607:fae0:a000::42 or src host 2a00:8642:42::75 or src host 2a12:d8c0:105a:9001::a154)'

If you see our PTBs arriving but the destination's TCP/Echo flow does not shrink, the drop is in the destination kernel (cause 3 below). If you don't see them at all, drop is upstream of you (cause 2). If you only see them from one of our two source IPs, the drop is path-asymmetric — one transit on the asymmetric route is filtering, the other is not.

Where the path divergence is

Mixed disagreement. At least one pair of vantages used the same probe method and disagreed (real Type 2 asymmetry); other pairs used different methods (probe-availability noise). The path-divergence summary below covers all pairs; the AI interpretation focuses on the real cases.

Per-vantage probe + verdict (headline):

go6lab: probe icmp6-echo → verdict honored
karsolink: probe tls → verdict partial
odin: probe icmp6-echo → verdict honored

Full per-method matrix (all four methods run at each vantage):

vantage	icmp6-echo	dns-tcp	tls	http
go6lab	honored	inconclusive	not_honored	inconclusive
karsolink	no_echo	inconclusive	partial	inconclusive
odin	honored	inconclusive	not_honored	inconclusive

✓ All vantages agree on method(s): icmp6-echo — the headline-method spread above is dispatcher noise, not a real Type 2 disagreement.

These vantage-level disagreements are rooted somewhere in the forward paths. Joining each per-vantage traceroute against the IP→AS lookup from our global yarrp mesh, the first hop where the paths land in different ASes is the most likely site of the offending filter / unreachable AS / Type 2 drop.

Suspect transit ASes (ranked by how often they appear at the divergence point on the path of the worse-classifying vantage): AS212271, AS39120, AS203993.

From go6lab (open/Type-2=honored) the path enters AS212271 at hop 6; from karsolink (open/Type-2=partial) the same hop is in AS39120. Last common AS: AS212271. The disagreement is most likely rooted in one of those two transit ASes.
From go6lab (open/Type-2=honored) the path enters AS203993 at hop 3; from odin (open/Type-2=honored) the same hop is in AS5603. Last common AS: AS212271. The disagreement is most likely rooted in one of those two transit ASes.

Diagnosis is path-level, not packet-level: it tells you which transit AS is the prime suspect, not exactly which firewall rule is to blame. Use the tracepath6 output below (when available) for per-hop PMTU evidence on the same path.

✨ Diagnostic interpretation

An operator-targeted diagnostic interpretation can be generated for this AS on demand. The pipeline holds the raw verdicts and the per-hop walk; an AI pass synthesises where to start looking. Click the button below to run it.

Per-hop PTB acceptance walk

From the local vantage, we walk the forward path hop-by-hop, sending each hop a 1500-byte ICMPv6 Echo, then a forged PTB (MTU=1280) sourced from us, then another 1500-byte Echo. If the second reply arrives fragmented or smaller, that hop honoured the PTB. If unchanged, it didn't. The first ✗ in an otherwise-✓ path is the most likely filter location. Cross-country aggregation: see the global PTB filter atlas for transit ASes ranked by filter rate across all measurements.

First break at hop 3: AS5603 (SIOL-NET - Telekom Slovenije, d.d., SI) -- this is the most likely site of the offending PTB filter. Hop IP: 2a00:ee1:800:9::1.

#	hop IP	AS	Holder	PTB acceptance
1	2607:fae0:a000::2	AS8038	6CONNECT - 6connect, Inc., US	- skipped (CoPP)
2	*	-		- (no IP)
3	2a00:ee1:800:9::1	AS5603	SIOL-NET - Telekom Slovenije, d.d., SI	✗ not_honored
4	2a00:ee0:1:10::2	AS5603	SIOL-NET - Telekom Slovenije, d.d., SI	✗ not_honored
5	2001:7f8::98d0:0:1	-	NA	? no_response
6	2a01:9a80:0:2f::f	AS39120	CONVERGENZE-AS - Convergenze S.p.A., IT	? no_response
7	2a05:4140:2::2	AS212271	C1V - Cinzia Tocci trading as Lumanex Sr	✓ honored
8	*	-		- (no IP)
9	*	-		- (no IP)
10	*	-		- (no IP)
11	*	-		- (no IP)
12	*	-		- (no IP)
13	*	-		- (no IP)
14	*	-		- (no IP)
15	*	-		- (no IP)
16	*	-		- (no IP)
17	*	-		- (no IP)
18	*	-		- (no IP)
19	*	-		- (no IP)
20	*	-		- (no IP)
21	*	-		- (no IP)
22	*	-		- (no IP)
23	*	-		- (no IP)
24	*	-		- (no IP)

Tests host-mode PTB acceptance (PTBs aimed at the hop itself). A router that honours PTBs to itself can still be filtering PTBs transiting through it; this is one indicator, not proof of full PTB transparency. Hops in CoPP-rate-limit ranges are skipped to avoid false signals.

tracepath6 per-hop PMTU drilldown

For each target where Type 2 verdicts disagreed across vantages, tracepath -6 ran from every vantage to capture per-hop PMTU evolution along that vantage's actual forward path. A pmtu change entry on a hop means that hop's router generated a PTB and we observed the shrink; absence of any change combined with a not_honored verdict suggests a router somewhere downstream is silently dropping >MTU packets (an RFC 4890 violation) rather than sending a PTB.