AS209076 vayu Vayu S.r.l

AS overview

Test target: 2a0e:cc00::1 · static prefix probe · address space: PA · prefixes announced: 1

prefix(es): 2a0e:cc00::/29

Targets & per-vantage-point probe results (1 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
`2a0e:cc00::1`	prb	✓	✓	?	?	✓	✓	✓	?	?	✓	✓	✓	?	?	✓

MIX-IT / NAMEX / MINAP / TOP-IX / VSIX / EQUINIX-MILAN / BGPX-ROME / NAMEX-BARI / PCIX / DECIX-PALERMO peering

Not an MIX-IT / NAMEX / MINAP / TOP-IX / VSIX / EQUINIX-MILAN / BGPX-ROME / NAMEX-BARI / PCIX / DECIX-PALERMO member, but our traceroute path crosses the MIX-IT / NAMEX / MINAP / TOP-IX / VSIX / EQUINIX-MILAN / BGPX-ROME / NAMEX-BARI / PCIX / DECIX-PALERMO LAN from ITA host (Karsolink) - reached via an MIX-IT / NAMEX / MINAP / TOP-IX / VSIX / EQUINIX-MILAN / BGPX-ROME / NAMEX-BARI / PCIX / DECIX-PALERMO-resident transit operator.

RPKI & ASPA

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

Prefix	RPKI state	Reason	Covering VRP(s)
`2a0e:cc00::/29`	✓ valid	matched VRP (correct origin, length within maxLength)	AS209076 /29 maxLen 32 (ripe)

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

We probed 15 arbitrary IPv6 address(es) inside AS209076's announced prefix(es). No router inside the prefix responded. The deepest visible hop was 2001:41a8:60:2::11a at hop 10 - that router answers ICMPv6 Echo. This is not in AS209076's announced prefix; operationally it's the AS-edge / peering interface (often on an IXP peering address or an upstream's /127 link). The traceroute boundary is the AS edge: ICMPv6 Time-Exceeded responses from anything inside this AS are filtered.

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 NOT honored. Forged PTB had no effect (filtered en route or stack ignored it). (TCP/53 DNS + forged PTB)
SLO host (6connect): Type 2 NOT honored. Forged PTB had no effect (filtered en route or stack ignored it). (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`	`2a0e:cc00::1`	`icmp6-echo`	honored	2026-05-30T12:47:46Z
karsolink	`2a12:d8c0:105a:9001::a154`	`2a0e:cc00::1`	`dns-tcp`	not_honored	2026-05-30T12:56:55Z
odin	`2607:fae0:a000::42`	`2a0e:cc00::1`	`icmp6-echo`	not_honored	2026-05-30T12:47:24Z

Attempt log (go6lab):

icmp6-echo → honored (size_before=1460, size_after=None)
dns-tcp → inconclusive (size_before=833, size_after=None): max DNS-over-TCP segment 833B; not big enough to test PMTU shrink
tls → no_tcp: TLS connect failed
http → no_tcp: tcp/80 not open

Attempt log (karsolink):

icmp6-echo → no_echo: no Echo Reply to 1300-byte probe
dns-tcp → not_honored (size_before=1139, size_after=1522)
tls → no_tcp: TLS connect failed
http → no_tcp: tcp/80 not open

Attempt log (odin):

icmp6-echo → not_honored (size_before=1460, size_after=1460)
dns-tcp → inconclusive (size_before=612, size_after=None): max DNS-over-TCP segment 612B; not big enough to test PMTU shrink
tls → no_tcp: TLS connect failed
http → no_tcp: tcp/80 not open

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.

What does "Type 2 not honored" actually mean? — click to expand

What this test does

Using the dns-tcp method, we open TCP/53 to your authoritative DNS server, observe its TCP segment size, forge an ICMPv6 PTB declaring path MTU=1280, and observe whether subsequent segments shrink. RFC 4890 requires hosts and intermediate networks not to filter ICMPv6 Type 2; the destination's TCP/UDP stack must act on a received PTB by lowering its Path MTU cache for that destination, which makes subsequent segments smaller.

What we measured

Three plausible causes

Your host firewall is dropping ICMPv6 Type 2 inbound. Many default firewall rule sets only allow Echo Request/Reply and Neighbor Discovery, silently dropping all other ICMPv6 types - including Packet Too Big.
An upstream / transit network is dropping ICMPv6 Type 2 before it reaches you. Some transit ASes filter ICMPv6 messages other than Echo at the edge. The forged PTB never arrives, so your stack never has a chance to act on it.
Your kernel is ignoring the PTB. Linux / BSD stacks normally accept ICMPv6 PTB and update the route cache, but a few sysctls (or a hardened kernel) can be configured to ignore PMTU updates - typically as part of an over-aggressive anti-spoofing or uRPF policy.

How to check & fix (Linux examples)

1. Confirm Type 2 is not blocked at the host firewall:

sudo ip6tables -L INPUT -nv | grep -iE 'icmpv6|packet-too-big'
sudo nft list ruleset 2>/dev/null | grep -A1 'icmpv6'

If you see rules dropping ICMPv6 unconditionally, change them to permit at least icmpv6 type packet-too-big (and destination-unreachable, time-exceeded, parameter-problem per RFC 4890).

2. Confirm the kernel accepts incoming PTB:

sudo sysctl net.ipv6.conf.all.accept_redirects net.ipv4.ip_no_pmtu_disc net.ipv6.route.mtu_expires

The defaults (accept_redirects=1, ip_no_pmtu_disc=0) are the right values for honoring PTB.

3. Live trace: while we have an open TCP flow with a small MSS (we run our test from 2607:fae0:a000::42 on odin, 2a00:8642:42::75 on go6lab and 2a12:d8c0:105a:9001::a154 on karsolink), watch for our forged Type 2 arriving on your interface:

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 TCP segments still stay big, the drop is in your kernel or NIC offload (cause 3). If you don't see them at all, the drop is upstream of you (cause 2) - ask your upstream(s) to permit ICMPv6 Type 2.

4. If your test target above (2026-05-30T12:56:55Z) is a host that you don't own (e.g. a third-party DNS / TLS server you happen to operate prefixes for), the verdict reflects that specific host's behaviour - try the test against a server you do own and we'll happily re-run.

RFC 4890 references: §4.3.1 (Packet Too Big - MUST NOT be dropped), and RFC 8201 for the broader PMTUD requirement.

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 dns-tcp → verdict not_honored
odin: probe icmp6-echo → verdict not_honored

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

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

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): AS209076, AS6939, AS50673.

From go6lab (open/Type-2=honored) the path enters AS209076 at hop 11; from karsolink (open/Type-2=not_honored) the same hop is in an opaque hop. Last common AS: AS209076. The disagreement is most likely rooted in one of those two transit ASes.
From go6lab (open/Type-2=honored) the path enters AS50673 at hop 4; from odin (open/Type-2=not_honored) the same hop is in AS6939. Last common AS: AS209076. The disagreement is most likely rooted in one of those two transit ASes.
From karsolink (open/Type-2=not_honored) the path enters AS209076 at hop 6; from odin (open/Type-2=not_honored) the same hop is in AS6939. Last common AS: AS209076. 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 10: AS209076 (vayu - Vayu S.r.l, IT) -- this is the most likely site of the offending PTB filter. Hop IP: 2a0e:cc00::1.

#	hop IP	AS	Holder	PTB acceptance
1	2607:fae0:a000::2	AS8038	6CONNECT - 6connect, Inc., US	- skipped (CoPP)
2	*	-		- (no IP)
3	*	-		- (no IP)
4	2001:470:1:5be::1	AS6939	HURRICANE - Hurricane Electric LLC, US	? no_response
5	*	-		- (no IP)
6	2001:470:0:2ea::2	AS6939	HURRICANE - Hurricane Electric LLC, US	? no_response
7	*	-		- (no IP)
8	*	-		- (no IP)
9	2a04:1d80::11	AS60989	Sinergia - Sinergia Telecomunication S.R	✓ honored
10	2a0e:cc00::1	AS209076	vayu - Vayu S.r.l, IT	✗ not_honored

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.

Target `2a0e:cc00::1`

go6lab — verdict honored

verdict = honored; final pmtu = 1500

#	hop IP	pmtu change
1	<span class='muted'>no reply</span>
2	2a00:8642:1000:f000::1
3	2a00:1ca8:1::194
4	2a03:3f40::10:41
5	2001:978:2:40::3:1
6	2001:550:0:1000::9a36:27b9
7	2001:550:0:1000::9a36:3c1a
8	2001:978:3::a6
9	2001:41a8:60::2
10	2001:41a8:60:2::11a
11	2a0e:cc00::1

karsolink — verdict not_honored

verdict = not_honored; final pmtu = 1500

#	hop IP	pmtu change
1	<span class='muted'>no reply</span>
2	2a12:d8c0:109f:121::a1
3	2a12:d8c0:101f:103::1
4	2001:7f8:b:100:1d1:a5d6:989:19
5	2a04:1d80::11
6	2a0e:cc00::1

odin — verdict not_honored

verdict = not_honored; final pmtu = 1500

#	hop IP	pmtu change
1	<span class='muted'>no reply</span>
2	2607:fae0:a000:2::2
3	2a03:a100:0:201:1::1
4	2001:470:1:5be::1
5	<span class='muted'>no reply</span>
6	2001:470:0:2ea::2
7	<span class='muted'>no reply</span>
8	<span class='muted'>no reply</span>
9	2a04:1d80::11
10	2a0e:cc00::1

From NL host (go6lab) openRFC 4890 ✓

filter likely at: (none) · min PMTU on path: 1500

4/4

Echo small (56B) 26.9ms

4/4

Echo 1500B (DF) 26.5ms

yes

Type 1 dest-unreach

TCP responds on

Path (traceroute + mtr + PTR)

#	IP / PTR	RTT	mtr loss	AS	AS holder
1	2a00:8642:42::3	1.4ms	0%	AS203993	STEFFANN-DC-AS - S.J.M. Steffann, NL
2	*	-	0%*	-
3	2a00:1ca8:1::194	2.8ms	0%	AS50673	Serverius-as - Serverius Holding B.V., NL
4	2a03:3f40::10:41	3.1ms	0%	AS50673	Serverius-as - Serverius Holding B.V., NL
5	*	-	30%	-
6	*	-	-	-
7	be3499.rcr22.ams05.atlas.cogentco.com 2001:550:0:1000::9a36:3c16	5.3ms	40%	AS174	COGENT-174 - Cogent Communications, LLC, US
8	2001:978:3::a6	9.9ms	0%	AS174	COGENT-174 - Cogent Communications, LLC, US
9	rom2-loop0-v6.rom.seabone.net 2001:41a8:60::2	28.3ms	0%	AS6762	SEABONE-NET - TELECOM ITALIA SPARKLE S.p.A., IT
10	2001:41a8:60:2::11a	30.5ms	0%	AS6762	SEABONE-NET - TELECOM ITALIA SPARKLE S.p.A., IT
11	2a0e:cc00::1	28.8ms	0%	AS209076	vayu - Vayu S.r.l, IT

Rate-limited ICMPv6: hop 5, hop 7 (loss between 5% and 95% across mtr cycles - the router replies but only sometimes).

tracepath -6

 1?: [LOCALHOST]                        0.047ms pmtu 1500
 1:  2a00:8642:42::3                                       1.783ms 
 1:  2a00:8642:42::3                                       1.894ms 
 2:  no reply
 3:  2a00:1ca8:1::194                                      3.847ms 
 4:  2a03:3f40::10:41                                      2.446ms 
 5:  2001:978:2:40::3:1                                    4.428ms 
 6:  no reply
 7:  be3499.rcr22.ams05.atlas.cogentco.com                27.349ms 
 8:  2001:978:3::a6                                        9.829ms asymm  9 
 9:  rom2-loop0-v6.rom.seabone.net                        28.891ms 
10:  2001:41a8:60:2::11a                                  28.230ms asymm  8 
11:  2a0e:cc00::1                                         30.577ms reached
     Resume: pmtu 1500 hops 11 back 9

From ITA host (Karsolink) openRFC 4890 ✗

filter likely at: (none) · min PMTU on path: 1500

4/4

Echo small (56B) 17.0ms

4/4

Echo 1500B (DF) 17.0ms

yes

Type 1 dest-unreach

TCP responds on

Path (traceroute + mtr + PTR)

#	IP / PTR	RTT	mtr loss	AS	AS holder
1	*	-	0%*	-
2	2a12:d8c0:109f:121::a1	0.3ms	0%*	AS204471	KARSOLINK - 2S Computers SRL, IT
3	2a12:d8c0:101f:103::1	8.4ms	0%	AS204471	KARSOLINK - 2S Computers SRL, IT
4	sinergiatelecomunication-AS60989-v6.mix-it.net @MIX-IT / NAMEX / MINAP / TOP-IX / VSIX / EQUINIX-MILAN / BGPX-ROME / NAMEX-BARI / PCIX / DECIX-PALERMO 2001:7f8:b:100:1d1:a5d6:989:19	9.1ms	0%	-	NA
5	2a04:1d80::11	17.3ms	0%	AS60989	Sinergia - Sinergia Telecomunication S.R.L., IT
6	2a0e:cc00::1	16.9ms	0%	AS209076	vayu - Vayu S.r.l, IT

tracepath -6

 1?: [LOCALHOST]                        0.031ms pmtu 1500
 1:  no reply
 2:  2a12:d8c0:109f:121::a1                                0.894ms 
 3:  2a12:d8c0:101f:103::1                                 8.979ms 
 4:  sinergiatelecomunication-AS60989-v6.mix-it.net        9.422ms 
 5:  2a04:1d80::11                                        17.628ms 
 6:  2a0e:cc00::1                                         17.981ms reached
     Resume: pmtu 1500 hops 6 back 6

From SLO host (6connect) openRFC 4890 ✗

filter likely at: (none) · min PMTU on path: 1500

4/4

Echo small (56B) 18.1ms

4/4

Echo 1500B (DF) 18.2ms

yes

Type 1 dest-unreach

TCP responds on

Path (traceroute + mtr + PTR)

#	IP / PTR	RTT	mtr loss	AS	AS holder
1	fw1-lju.6connect.com 2607:fae0:a000::2	0.3ms	0%*	AS8038	6CONNECT - 6connect, Inc., US
2	*	-	0%*	-
3	*	-	20%	-
4	e0-1.core1.lju1.he.net 2001:470:1:5be::1	2.0ms	0%	AS6939	HURRICANE - Hurricane Electric LLC, US
5	*	-	-	-
6	port-channel1.core1.zag2.he.net 2001:470:0:2ea::2	4.0ms	0%	AS6939	HURRICANE - Hurricane Electric LLC, US
7	*	-	-	-
8	*	-	-	-
9	2a04:1d80::11	18.5ms	0%	AS60989	Sinergia - Sinergia Telecomunication S.R.L., IT
10	2a0e:cc00::1	18.4ms	0%	AS209076	vayu - Vayu S.r.l, IT

Rate-limited ICMPv6: hop 3 (loss between 5% and 95% across mtr cycles - the router replies but only sometimes).

tracepath -6

 1?: [LOCALHOST]                        0.028ms pmtu 1500
 1:  fw1-lju.6connect.com                                  0.452ms 
 1:  fw1-lju.6connect.com                                  0.499ms 
 2:  ccr-to-fw-ccr1-gw-lju.6connect.com                    1.056ms 
 3:  no reply
 4:  e0-1.core1.lju1.he.net                                2.181ms 
 5:  no reply
 6:  no reply
 7:  no reply
 8:  no reply
 9:  2a04:1d80::11                                        18.489ms asymm  6 
10:  2a0e:cc00::1                                         18.335ms reached
     Resume: pmtu 1500 hops 10 back 7

AS overview

MIX-IT / NAMEX / MINAP / TOP-IX / VSIX / EQUINIX-MILAN / BGPX-ROME / NAMEX-BARI / PCIX / DECIX-PALERMO peering

RPKI & ASPA

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

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

What this test does

What we measured

Three plausible causes

How to check & fix (Linux examples)

Where the path divergence is

✨ Diagnostic interpretation

Per-hop PTB acceptance walk

tracepath6 per-hop PMTU drilldown

Target 2a0e:cc00::1

From NL host (go6lab) openRFC 4890 ✓

Path (traceroute + mtr + PTR)

tracepath -6

From ITA host (Karsolink) openRFC 4890 ✗

Path (traceroute + mtr + PTR)

tracepath -6

From SLO host (6connect) openRFC 4890 ✗

Path (traceroute + mtr + PTR)

tracepath -6

Target `2a0e:cc00::1`