ICMPv6 measurements for Serbian operators (ASNs)

What was measured. From NL host (go6lab) we tested AS6700 (BEOTEL-AS TELEKOM SRBIJA a.d.) using (probe) (2a02:e40::25). Probes: small ICMPv6 Echo (56-byte payload), 1500-byte Echo with DF set, a 24-hop traceroute6, an mtr cycle (10×1s) for per-hop loss, tracepath -6 for path-MTU, a UDP probe to a high closed port, and TCP SYN to ports 443 and 80.

Echo behavior. Both small and 1500-byte Echo Requests received replies (4/4 small, 4/4 1500 B; avg RTT 30.2/30.3 ms). Inbound ICMPv6 Echo Reply is permitted and the path can carry full-MTU packets without needing a Packet-Too-Big signal - consistent with a properly open ICMPv6 stance.

ICMPv6 Type 2 (Packet Too Big) / PMTUD. Path-MTU is 1500 end-to-end (4/4 1500-byte echoes pass), so no router needed to emit a Packet-Too-Big on this run - we cannot directly confirm Type 2 handling, but nothing on the path required it. Type 2 acceptance by the destination would only be exercised over a smaller-MTU path. Active test (ICMPv6 Echo + forged PTB): the next 1500-byte Echo Reply still arrived whole (1460 B, no Fragment Header) after our forged Type 2 - Type 2 was not honored (either filtered en route, the destination ignored / failed to validate our PTB, or its PMTU cache key didn't match the test flow). PMTUD does not work toward this address from us.

Path observations. Traceroute saw 10 responsive hop(s) and reached the target itself. The deepest hop that returned a Time-Exceeded was 2a02:e40::25 in AS6700 (BEOTEL-AS). The path completed cleanly to the destination.

Other signals.

• A UDP probe to a closed high port elicited an ICMPv6 Type 1 (Destination Unreachable) response - the destination is alive and its host firewall returns Type 1 normally.

Likely problem: none. AS6700 accepts ICMPv6 Echo and the path between us is fully usable for Echo and 1500-byte traffic.

For more information click the ASN number on the far left or follow this direct link: AS6700 details →

What was measured. From ITA host (Karsolink) we tested AS6700 (BEOTEL-AS TELEKOM SRBIJA a.d.) using (probe) (2a02:e40::25). Probes: small ICMPv6 Echo (56-byte payload), 1500-byte Echo with DF set, a 24-hop traceroute6, an mtr cycle (10×1s) for per-hop loss, tracepath -6 for path-MTU, a UDP probe to a high closed port, and TCP SYN to ports 443 and 80.

Echo behavior. Both small and 1500-byte Echo Requests received replies (4/4 small, 4/4 1500 B; avg RTT 50.7/50.7 ms). Inbound ICMPv6 Echo Reply is permitted and the path can carry full-MTU packets without needing a Packet-Too-Big signal - consistent with a properly open ICMPv6 stance.

ICMPv6 Type 2 (Packet Too Big) / PMTUD. Path-MTU is 1500 end-to-end (4/4 1500-byte echoes pass), so no router needed to emit a Packet-Too-Big on this run - we cannot directly confirm Type 2 handling, but nothing on the path required it. Type 2 acceptance by the destination would only be exercised over a smaller-MTU path. Active test attempted but no Echo Reply to 1300-byte probe; cannot decide Type 2 acceptance from this run.

Path observations. Traceroute saw 9 responsive hop(s) and reached the target itself. The deepest hop that returned a Time-Exceeded was 2a02:e40::25 in AS6700 (BEOTEL-AS). The path completed cleanly to the destination.

Other signals.

• Per-hop loss between 5% and 95% on hop 3 (90%, AS204471, KARSOLINK), hop 7 (90%, AS8400, TELEKOM-AS) - that router replies sometimes but not always, which is characteristic of ICMPv6 rate-limiting, not an outright filter.
• A UDP probe to a closed high port elicited an ICMPv6 Type 1 (Destination Unreachable) response - the destination is alive and its host firewall returns Type 1 normally.
• TCP SYN was refused (RST) on tcp/443, tcp/80 - the host is reachable on TCP, so any ICMPv6 silence above is firewalling, not the host being down.

Likely problem: none. AS6700 accepts ICMPv6 Echo and the path between us is fully usable for Echo and 1500-byte traffic.

For more information click the ASN number on the far left or follow this direct link: AS6700 details →

What was measured. From SLO host (6connect) we tested AS6700 (BEOTEL-AS TELEKOM SRBIJA a.d.) using (probe) (2a02:e40::25). Probes: small ICMPv6 Echo (56-byte payload), 1500-byte Echo with DF set, a 24-hop traceroute6, an mtr cycle (10×1s) for per-hop loss, tracepath -6 for path-MTU, a UDP probe to a high closed port, and TCP SYN to ports 443 and 80.

Echo behavior. Small echo works (4/4 replies, avg 30.8 ms), but every 1500-byte Echo Request was lost (0/4). Some link on the path has an MTU below 1500 and the required ICMPv6 Type 2 (Packet Too Big) message is not getting back to us - that is a classic broken-PMTUD signature, frequently caused by a firewall on the destination side that drops ICMPv6 Type 2 along with Echo.

ICMPv6 Type 2 (Packet Too Big) / PMTUD. Ping is open but the 1500-byte Echo failed. Small Echo gets through (4/4), 1500-byte Echo with DF is silently lost (0/4). Some link on the path has MTU < 1500. Without a per-hop PMTUD diagnostic we cannot yet tell whether the constraint router generates Type 2 properly or whether Type 2 is being filtered en route. (Run 11_pmtud_diagnose.py to localize.) Active test (ICMPv6 Echo + forged PTB): the next 1500-byte Echo Reply still arrived whole (1460 B, no Fragment Header) after our forged Type 2 - Type 2 was not honored (either filtered en route, the destination ignored / failed to validate our PTB, or its PMTU cache key didn't match the test flow). PMTUD does not work toward this address from us.

Path observations. Traceroute saw 12 responsive hop(s) and reached the target itself. The deepest hop that returned a Time-Exceeded was 2a02:e40::25 in AS6700 (BEOTEL-AS). The path completed cleanly to the destination.

Other signals.

• Per-hop loss between 5% and 95% on hop 5 (10%, AS6939, HURRICANE), hop 10 (40%, AS8400, TELEKOM-AS), hop 11 (50%, AS6700, BEOTEL-AS) - that router replies sometimes but not always, which is characteristic of ICMPv6 rate-limiting, not an outright filter.
• A UDP probe to a closed high port elicited an ICMPv6 Type 1 (Destination Unreachable) response - the destination is alive and its host firewall returns Type 1 normally.
• TCP SYN was refused (RST) on tcp/443, tcp/80 - the host is reachable on TCP, so any ICMPv6 silence above is firewalling, not the host being down.

Likely problem: AS6700 (or a router on the path) drops ICMPv6 Type 2 / oversize traffic; PMTUD will misbehave for hosts that try to send large packets to this destination. Filter is most likely at destination AS6700 (BEOTEL-AS).

For more information click the ASN number on the far left or follow this direct link: AS6700 details →

What was measured. From NL host (go6lab) we tested AS8400 (TELEKOM-AS TELEKOM SRBIJA a.d.) using (probe) (2a06:63c0::1). Probes: small ICMPv6 Echo (56-byte payload), 1500-byte Echo with DF set, a 24-hop traceroute6, an mtr cycle (10×1s) for per-hop loss, tracepath -6 for path-MTU, a UDP probe to a high closed port, and TCP SYN to ports 443 and 80.

Echo behavior. Both small and 1500-byte Echo Requests received replies (4/4 small, 4/4 1500 B; avg RTT 31.1/31.3 ms). Inbound ICMPv6 Echo Reply is permitted and the path can carry full-MTU packets without needing a Packet-Too-Big signal - consistent with a properly open ICMPv6 stance.

ICMPv6 Type 2 (Packet Too Big) / PMTUD. Path-MTU is 1500 end-to-end (4/4 1500-byte echoes pass), so no router needed to emit a Packet-Too-Big on this run - we cannot directly confirm Type 2 handling, but nothing on the path required it. Type 2 acceptance by the destination would only be exercised over a smaller-MTU path. Active test (ICMPv6 Echo + forged PTB): we forged an ICMPv6 Type 2 (MTU=1280) toward this destination - the destination then split its 1500-byte Echo Reply into 2 fragments via the IPv6 Fragment Header. Type 2 is accepted and honored by this destination's stack.

Path observations. Traceroute saw 7 responsive hop(s). The deepest hop that returned a Time-Exceeded was 2a06:63c7::ffff:ffff:ffff:47 in AS8400 (TELEKOM-AS). The path entered the destination AS - intermediate hops inside that AS replied - but every probed host inside its prefix was silent. The filter is at the destination AS edge (or applied to all hosts within).

Other signals.

• A UDP probe to a closed high port elicited an ICMPv6 Type 1 (Destination Unreachable) response - the destination is alive and its host firewall returns Type 1 normally.

Likely problem: none. AS8400 accepts ICMPv6 Echo and the path between us is fully usable for Echo and 1500-byte traffic.

For more information click the ASN number on the far left or follow this direct link: AS8400 details →

What was measured. From ITA host (Karsolink) we tested AS8400 (TELEKOM-AS TELEKOM SRBIJA a.d.) using (probe) (2a06:63c0::1). Probes: small ICMPv6 Echo (56-byte payload), 1500-byte Echo with DF set, a 24-hop traceroute6, an mtr cycle (10×1s) for per-hop loss, tracepath -6 for path-MTU, a UDP probe to a high closed port, and TCP SYN to ports 443 and 80.

Echo behavior. Both small and 1500-byte Echo Requests received replies (4/4 small, 4/4 1500 B; avg RTT 35.9/35.6 ms). Inbound ICMPv6 Echo Reply is permitted and the path can carry full-MTU packets without needing a Packet-Too-Big signal - consistent with a properly open ICMPv6 stance.

ICMPv6 Type 2 (Packet Too Big) / PMTUD. Path-MTU is 1500 end-to-end (4/4 1500-byte echoes pass), so no router needed to emit a Packet-Too-Big on this run - we cannot directly confirm Type 2 handling, but nothing on the path required it. Type 2 acceptance by the destination would only be exercised over a smaller-MTU path. Active test attempted but no Echo Reply to 1300-byte probe; cannot decide Type 2 acceptance from this run.

Path observations. Traceroute saw 9 responsive hop(s). The deepest hop that returned a Time-Exceeded was 2a06:63c7::ffff:ffff:ffff:47 in AS8400 (TELEKOM-AS). The path entered the destination AS - intermediate hops inside that AS replied - but every probed host inside its prefix was silent. The filter is at the destination AS edge (or applied to all hosts within).

Other signals.

• Per-hop loss between 5% and 95% on hop 3 (20%, AS204471, KARSOLINK) - that router replies sometimes but not always, which is characteristic of ICMPv6 rate-limiting, not an outright filter.
• A UDP probe to a closed high port elicited an ICMPv6 Type 1 (Destination Unreachable) response - the destination is alive and its host firewall returns Type 1 normally.
• TCP SYN was refused (RST) on tcp/443, tcp/80 - the host is reachable on TCP, so any ICMPv6 silence above is firewalling, not the host being down.

Likely problem: none. AS8400 accepts ICMPv6 Echo and the path between us is fully usable for Echo and 1500-byte traffic.

For more information click the ASN number on the far left or follow this direct link: AS8400 details →

What was measured. From SLO host (6connect) we tested AS8400 (TELEKOM-AS TELEKOM SRBIJA a.d.) using (probe) (2a06:63c0::1). Probes: small ICMPv6 Echo (56-byte payload), 1500-byte Echo with DF set, a 24-hop traceroute6, an mtr cycle (10×1s) for per-hop loss, tracepath -6 for path-MTU, a UDP probe to a high closed port, and TCP SYN to ports 443 and 80.

Echo behavior. Both small and 1500-byte Echo Requests received replies (4/4 small, 4/4 1500 B; avg RTT 46.6/45.9 ms). Inbound ICMPv6 Echo Reply is permitted and the path can carry full-MTU packets without needing a Packet-Too-Big signal - consistent with a properly open ICMPv6 stance.

ICMPv6 Type 2 (Packet Too Big) / PMTUD. Path-MTU is 1500 end-to-end (4/4 1500-byte echoes pass), so no router needed to emit a Packet-Too-Big on this run - we cannot directly confirm Type 2 handling, but nothing on the path required it. Type 2 acceptance by the destination would only be exercised over a smaller-MTU path. Active test (ICMPv6 Echo + forged PTB): we forged an ICMPv6 Type 2 (MTU=1280) toward this destination - the destination then split its 1500-byte Echo Reply into 2 fragments via the IPv6 Fragment Header. Type 2 is accepted and honored by this destination's stack.

Path observations. Traceroute saw 9 responsive hop(s). The deepest hop that returned a Time-Exceeded was 2a06:63c7::ffff:ffff:ffff:47 in AS8400 (TELEKOM-AS). The path entered the destination AS - intermediate hops inside that AS replied - but every probed host inside its prefix was silent. The filter is at the destination AS edge (or applied to all hosts within).

Other signals.

• Per-hop loss between 5% and 95% on hop 4 (30%, AS6939, HURRICANE), hop 5 (20%, AS6939, HURRICANE) - that router replies sometimes but not always, which is characteristic of ICMPv6 rate-limiting, not an outright filter.
• A UDP probe to a closed high port elicited an ICMPv6 Type 1 (Destination Unreachable) response - the destination is alive and its host firewall returns Type 1 normally.
• TCP SYN was refused (RST) on tcp/443, tcp/80 - the host is reachable on TCP, so any ICMPv6 silence above is firewalling, not the host being down.

Likely problem: none. AS8400 accepts ICMPv6 Echo and the path between us is fully usable for Echo and 1500-byte traffic.

For more information click the ASN number on the far left or follow this direct link: AS8400 details →

What was measured. From NL host (go6lab) we tested AS13004 (SOX Serbian Open Exchange DOO) using ns3.sox.rs (2001:7f8:1e:3::166). Probes: small ICMPv6 Echo (56-byte payload), 1500-byte Echo with DF set, a 24-hop traceroute6, an mtr cycle (10×1s) for per-hop loss, tracepath -6 for path-MTU, a UDP probe to a high closed port, and TCP SYN to ports 443 and 80.

Echo behavior. Both small and 1500-byte Echo Requests received replies (4/4 small, 4/4 1500 B; avg RTT 49.3/49.4 ms). Inbound ICMPv6 Echo Reply is permitted and the path can carry full-MTU packets without needing a Packet-Too-Big signal - consistent with a properly open ICMPv6 stance.

ICMPv6 Type 2 (Packet Too Big) / PMTUD. Path-MTU is 1500 end-to-end (4/4 1500-byte echoes pass), so no router needed to emit a Packet-Too-Big on this run - we cannot directly confirm Type 2 handling, but nothing on the path required it. Type 2 acceptance by the destination would only be exercised over a smaller-MTU path. Active test (ICMPv6 Echo + forged PTB): we forged an ICMPv6 Type 2 (MTU=1280) toward this destination - the destination then split its 1500-byte Echo Reply into 2 fragments via the IPv6 Fragment Header. Type 2 is accepted and honored by this destination's stack.

Path observations. Traceroute saw 13 responsive hop(s) and reached the target itself. The deepest hop that returned a Time-Exceeded was 2001:7f8:1e:3::166 in AS13004 (SOX). The path completed cleanly to the destination.

Other signals.

• Per-hop loss between 5% and 95% on hop 5 (10%, AS31500, GNM-AS), hop 7 (50%, AS6939, HURRICANE), hop 8 (10%, AS6939, HURRICANE) - that router replies sometimes but not always, which is characteristic of ICMPv6 rate-limiting, not an outright filter.
• A UDP probe to a closed high port elicited an ICMPv6 Type 1 (Destination Unreachable) response - the destination is alive and its host firewall returns Type 1 normally.

Likely problem: none. AS13004 accepts ICMPv6 Echo and the path between us is fully usable for Echo and 1500-byte traffic.

For more information click the ASN number on the far left or follow this direct link: AS13004 details →

What was measured. From ITA host (Karsolink) we tested AS13004 (SOX Serbian Open Exchange DOO) using ns3.sox.rs (2001:7f8:1e:3::166). Probes: small ICMPv6 Echo (56-byte payload), 1500-byte Echo with DF set, a 24-hop traceroute6, an mtr cycle (10×1s) for per-hop loss, tracepath -6 for path-MTU, a UDP probe to a high closed port, and TCP SYN to ports 443 and 80.

Echo behavior. Both small and 1500-byte Echo Requests received replies (4/4 small, 4/4 1500 B; avg RTT 31.7/31.7 ms). Inbound ICMPv6 Echo Reply is permitted and the path can carry full-MTU packets without needing a Packet-Too-Big signal - consistent with a properly open ICMPv6 stance.

ICMPv6 Type 2 (Packet Too Big) / PMTUD. Path-MTU is 1500 end-to-end (4/4 1500-byte echoes pass), so no router needed to emit a Packet-Too-Big on this run - we cannot directly confirm Type 2 handling, but nothing on the path required it. Type 2 acceptance by the destination would only be exercised over a smaller-MTU path. Active test attempted but no Echo Reply to 1300-byte probe; cannot decide Type 2 acceptance from this run.

Path observations. Traceroute saw 9 responsive hop(s) and reached the target itself. The deepest hop that returned a Time-Exceeded was 2001:7f8:1e:3::166 in AS13004 (SOX). The path completed cleanly to the destination.

Other signals.

• A UDP probe to a closed high port elicited an ICMPv6 Type 1 (Destination Unreachable) response - the destination is alive and its host firewall returns Type 1 normally.

Likely problem: none. AS13004 accepts ICMPv6 Echo and the path between us is fully usable for Echo and 1500-byte traffic.

For more information click the ASN number on the far left or follow this direct link: AS13004 details →

What was measured. From SLO host (6connect) we tested AS13004 (SOX Serbian Open Exchange DOO) using ns3.sox.rs (2001:7f8:1e:3::166). Probes: small ICMPv6 Echo (56-byte payload), 1500-byte Echo with DF set, a 24-hop traceroute6, an mtr cycle (10×1s) for per-hop loss, tracepath -6 for path-MTU, a UDP probe to a high closed port, and TCP SYN to ports 443 and 80.

Echo behavior. Both small and 1500-byte Echo Requests received replies (4/4 small, 4/4 1500 B; avg RTT 21.9/22.0 ms). Inbound ICMPv6 Echo Reply is permitted and the path can carry full-MTU packets without needing a Packet-Too-Big signal - consistent with a properly open ICMPv6 stance.

ICMPv6 Type 2 (Packet Too Big) / PMTUD. Path-MTU is 1500 end-to-end (4/4 1500-byte echoes pass), so no router needed to emit a Packet-Too-Big on this run - we cannot directly confirm Type 2 handling, but nothing on the path required it. Type 2 acceptance by the destination would only be exercised over a smaller-MTU path. Active test (ICMPv6 Echo + forged PTB): we forged an ICMPv6 Type 2 (MTU=1280) toward this destination - the destination then split its 1500-byte Echo Reply into 2 fragments via the IPv6 Fragment Header. Type 2 is accepted and honored by this destination's stack.

Path observations. Traceroute saw 12 responsive hop(s) and reached the target itself. The deepest hop that returned a Time-Exceeded was 2001:7f8:1e:3::166 in AS13004 (SOX). The path completed cleanly to the destination.

Other signals.

• Per-hop loss between 5% and 95% on hop 3 (10%, AS5603, SIOL-NET) - that router replies sometimes but not always, which is characteristic of ICMPv6 rate-limiting, not an outright filter.
• A UDP probe to a closed high port elicited an ICMPv6 Type 1 (Destination Unreachable) response - the destination is alive and its host firewall returns Type 1 normally.

Likely problem: none. AS13004 accepts ICMPv6 Echo and the path between us is fully usable for Echo and 1500-byte traffic.

For more information click the ASN number on the far left or follow this direct link: AS13004 details →

What was measured. From NL host (go6lab) we tested AS13092 (UB-AS Akademska mreza Republike Srbije - AMRES) using ban.junis.ni.ac.rs (2001:4170:2801::1). Probes: small ICMPv6 Echo (56-byte payload), 1500-byte Echo with DF set, a 24-hop traceroute6, an mtr cycle (10×1s) for per-hop loss, tracepath -6 for path-MTU, a UDP probe to a high closed port, and TCP SYN to ports 443 and 80.

Echo behavior. Both small and 1500-byte Echo Requests received replies (4/4 small, 4/4 1500 B; avg RTT 37.3/37.5 ms). Inbound ICMPv6 Echo Reply is permitted and the path can carry full-MTU packets without needing a Packet-Too-Big signal - consistent with a properly open ICMPv6 stance.

ICMPv6 Type 2 (Packet Too Big) / PMTUD. Path-MTU is 1500 end-to-end (4/4 1500-byte echoes pass), so no router needed to emit a Packet-Too-Big on this run - we cannot directly confirm Type 2 handling, but nothing on the path required it. Type 2 acceptance by the destination would only be exercised over a smaller-MTU path. Active test (ICMPv6 Echo + forged PTB): we forged an ICMPv6 Type 2 (MTU=1280) toward this destination - the destination then split its 1500-byte Echo Reply into 2 fragments via the IPv6 Fragment Header. Type 2 is accepted and honored by this destination's stack.

Path observations. Traceroute saw 21 responsive hop(s) and reached the target itself. The deepest hop that returned a Time-Exceeded was ban.junis.ni.ac.rs [2001:4170:2801::1] in AS13092 (UB-AS). The path completed cleanly to the destination.

Other signals.

• Per-hop loss between 5% and 95% on hop 3 (20%, AS50673, Serverius-as), hop 5 (20%, AS174, COGENT-174), hop 12 (70%, AS174, COGENT-174), hop 14 (90%, AS20965, GEANT) - that router replies sometimes but not always, which is characteristic of ICMPv6 rate-limiting, not an outright filter.
• A UDP probe to a closed high port elicited an ICMPv6 Type 1 (Destination Unreachable) response - the destination is alive and its host firewall returns Type 1 normally.

Likely problem: none. AS13092 accepts ICMPv6 Echo and the path between us is fully usable for Echo and 1500-byte traffic.

For more information click the ASN number on the far left or follow this direct link: AS13092 details →

What was measured. From ITA host (Karsolink) we tested AS13092 (UB-AS Akademska mreza Republike Srbije - AMRES) using ban.junis.ni.ac.rs (2001:4170:2801::1). Probes: small ICMPv6 Echo (56-byte payload), 1500-byte Echo with DF set, a 24-hop traceroute6, an mtr cycle (10×1s) for per-hop loss, tracepath -6 for path-MTU, a UDP probe to a high closed port, and TCP SYN to ports 443 and 80.

Echo behavior. Both small and 1500-byte Echo Requests received replies (4/4 small, 4/4 1500 B; avg RTT 26.8/26.9 ms). Inbound ICMPv6 Echo Reply is permitted and the path can carry full-MTU packets without needing a Packet-Too-Big signal - consistent with a properly open ICMPv6 stance.

ICMPv6 Type 2 (Packet Too Big) / PMTUD. Path-MTU is 1500 end-to-end (4/4 1500-byte echoes pass), so no router needed to emit a Packet-Too-Big on this run - we cannot directly confirm Type 2 handling, but nothing on the path required it. Type 2 acceptance by the destination would only be exercised over a smaller-MTU path. Active test attempted but no Echo Reply to 1300-byte probe; cannot decide Type 2 acceptance from this run.

Path observations. Traceroute saw 14 responsive hop(s) and reached the target itself. The deepest hop that returned a Time-Exceeded was ban.junis.ni.ac.rs [2001:4170:2801::1] in AS13092 (UB-AS). The path completed cleanly to the destination.

Other signals.

• Per-hop loss between 5% and 95% on hop 7 (10%, AS20965, GEANT), hop 13 (10%, AS13092, UB-AS) - that router replies sometimes but not always, which is characteristic of ICMPv6 rate-limiting, not an outright filter.
• A UDP probe to a closed high port elicited an ICMPv6 Type 1 (Destination Unreachable) response - the destination is alive and its host firewall returns Type 1 normally.

Likely problem: none. AS13092 accepts ICMPv6 Echo and the path between us is fully usable for Echo and 1500-byte traffic.

For more information click the ASN number on the far left or follow this direct link: AS13092 details →

What was measured. From SLO host (6connect) we tested AS13092 (UB-AS Akademska mreza Republike Srbije - AMRES) using ban.junis.ni.ac.rs (2001:4170:2801::1). Probes: small ICMPv6 Echo (56-byte payload), 1500-byte Echo with DF set, a 24-hop traceroute6, an mtr cycle (10×1s) for per-hop loss, tracepath -6 for path-MTU, a UDP probe to a high closed port, and TCP SYN to ports 443 and 80.

Echo behavior. Both small and 1500-byte Echo Requests received replies (4/4 small, 3/4 1500 B; avg RTT 22.8/22.8 ms). Inbound ICMPv6 Echo Reply is permitted and the path can carry full-MTU packets without needing a Packet-Too-Big signal - consistent with a properly open ICMPv6 stance.

ICMPv6 Type 2 (Packet Too Big) / PMTUD. Path-MTU is 1500 end-to-end (3/4 1500-byte echoes pass), so no router needed to emit a Packet-Too-Big on this run - we cannot directly confirm Type 2 handling, but nothing on the path required it. Type 2 acceptance by the destination would only be exercised over a smaller-MTU path. Active test (ICMPv6 Echo + forged PTB): we forged an ICMPv6 Type 2 (MTU=1280) toward this destination - the destination then split its 1500-byte Echo Reply into 2 fragments via the IPv6 Fragment Header. Type 2 is accepted and honored by this destination's stack.

Path observations. Traceroute saw 14 responsive hop(s) and reached the target itself. The deepest hop that returned a Time-Exceeded was ban.junis.ni.ac.rs [2001:4170:2801::1] in AS13092 (UB-AS). The path completed cleanly to the destination.

Other signals.

• Per-hop loss between 5% and 95% on hop 4 (10%, AS6939, HURRICANE), hop 7 (90%, AS20965, GEANT), hop 8 (10%, AS20965, GEANT), hop 13 (10%, AS13092, UB-AS) - that router replies sometimes but not always, which is characteristic of ICMPv6 rate-limiting, not an outright filter.
• A UDP probe to a closed high port elicited an ICMPv6 Type 1 (Destination Unreachable) response - the destination is alive and its host firewall returns Type 1 normally.

Likely problem: none. AS13092 accepts ICMPv6 Echo and the path between us is fully usable for Echo and 1500-byte traffic.

For more information click the ASN number on the far left or follow this direct link: AS13092 details →

What was measured. From NL host (go6lab) we tested AS15958 (CETIN_doo_AS CETIN Ltd. Belgrade) using (probe) (2a01:ac80::1). Probes: small ICMPv6 Echo (56-byte payload), 1500-byte Echo with DF set, a 24-hop traceroute6, an mtr cycle (10×1s) for per-hop loss, tracepath -6 for path-MTU, a UDP probe to a high closed port, and TCP SYN to ports 443 and 80.

Echo behavior. Both small and 1500-byte Echo Requests received replies (4/4 small, 4/4 1500 B; avg RTT 30.2/30.0 ms). Inbound ICMPv6 Echo Reply is permitted and the path can carry full-MTU packets without needing a Packet-Too-Big signal - consistent with a properly open ICMPv6 stance.

ICMPv6 Type 2 (Packet Too Big) / PMTUD. Path-MTU is 1500 end-to-end (4/4 1500-byte echoes pass), so no router needed to emit a Packet-Too-Big on this run - we cannot directly confirm Type 2 handling, but nothing on the path required it. Type 2 acceptance by the destination would only be exercised over a smaller-MTU path. Active test (ICMPv6 Echo + forged PTB): the next 1500-byte Echo Reply still arrived whole (1460 B, no Fragment Header) after our forged Type 2 - Type 2 was not honored (either filtered en route, the destination ignored / failed to validate our PTB, or its PMTU cache key didn't match the test flow). PMTUD does not work toward this address from us.

Path observations. Traceroute saw 4 responsive hop(s) and reached the target itself. The deepest hop that returned a Time-Exceeded was 2a01:ac80::1 in AS15958 (CETIN_doo_AS). The path completed cleanly to the destination.

Other signals.

• A UDP probe to a closed high port elicited an ICMPv6 Type 1 (Destination Unreachable) response - the destination is alive and its host firewall returns Type 1 normally.

Likely problem: none. AS15958 accepts ICMPv6 Echo and the path between us is fully usable for Echo and 1500-byte traffic.

For more information click the ASN number on the far left or follow this direct link: AS15958 details →

What was measured. From ITA host (Karsolink) we tested AS15958 (CETIN_doo_AS CETIN Ltd. Belgrade) using (probe) (2a01:ac80::1). Probes: small ICMPv6 Echo (56-byte payload), 1500-byte Echo with DF set, a 24-hop traceroute6, an mtr cycle (10×1s) for per-hop loss, tracepath -6 for path-MTU, a UDP probe to a high closed port, and TCP SYN to ports 443 and 80.

Echo behavior. Both small and 1500-byte Echo Requests received replies (4/4 small, 4/4 1500 B; avg RTT 50.0/50.1 ms). Inbound ICMPv6 Echo Reply is permitted and the path can carry full-MTU packets without needing a Packet-Too-Big signal - consistent with a properly open ICMPv6 stance.

ICMPv6 Type 2 (Packet Too Big) / PMTUD. Path-MTU is 1500 end-to-end (4/4 1500-byte echoes pass), so no router needed to emit a Packet-Too-Big on this run - we cannot directly confirm Type 2 handling, but nothing on the path required it. Type 2 acceptance by the destination would only be exercised over a smaller-MTU path. Active test attempted but no Echo Reply to 1300-byte probe; cannot decide Type 2 acceptance from this run.

Path observations. Traceroute saw 6 responsive hop(s) and reached the target itself. The deepest hop that returned a Time-Exceeded was 2a01:ac80::1 in AS15958 (CETIN_doo_AS). The path completed cleanly to the destination.

Other signals.

• Per-hop loss between 5% and 95% on hop 3 (10%, AS204471, KARSOLINK) - that router replies sometimes but not always, which is characteristic of ICMPv6 rate-limiting, not an outright filter.
• A UDP probe to a closed high port elicited an ICMPv6 Type 1 (Destination Unreachable) response - the destination is alive and its host firewall returns Type 1 normally.

Likely problem: none. AS15958 accepts ICMPv6 Echo and the path between us is fully usable for Echo and 1500-byte traffic.

For more information click the ASN number on the far left or follow this direct link: AS15958 details →

What was measured. From SLO host (6connect) we tested AS15958 (CETIN_doo_AS CETIN Ltd. Belgrade) using (probe) (2a01:ac80::1). Probes: small ICMPv6 Echo (56-byte payload), 1500-byte Echo with DF set, a 24-hop traceroute6, an mtr cycle (10×1s) for per-hop loss, tracepath -6 for path-MTU, a UDP probe to a high closed port, and TCP SYN to ports 443 and 80.

Echo behavior. Small echo works (4/4 replies, avg 31.8 ms), but every 1500-byte Echo Request was lost (0/4). Some link on the path has an MTU below 1500 and the required ICMPv6 Type 2 (Packet Too Big) message is not getting back to us - that is a classic broken-PMTUD signature, frequently caused by a firewall on the destination side that drops ICMPv6 Type 2 along with Echo.

ICMPv6 Type 2 (Packet Too Big) / PMTUD. Ping is open but the 1500-byte Echo failed. Small Echo gets through (4/4), 1500-byte Echo with DF is silently lost (0/4). Some link on the path has MTU < 1500. Without a per-hop PMTUD diagnostic we cannot yet tell whether the constraint router generates Type 2 properly or whether Type 2 is being filtered en route. (Run 11_pmtud_diagnose.py to localize.) Active test (ICMPv6 Echo + forged PTB): the next 1500-byte Echo Reply still arrived whole (1460 B, no Fragment Header) after our forged Type 2 - Type 2 was not honored (either filtered en route, the destination ignored / failed to validate our PTB, or its PMTU cache key didn't match the test flow). PMTUD does not work toward this address from us.

Path observations. Traceroute saw 8 responsive hop(s) and reached the target itself. The deepest hop that returned a Time-Exceeded was 2a01:ac80::1 in AS15958 (CETIN_doo_AS). The path completed cleanly to the destination.

Other signals.

• Per-hop loss between 5% and 95% on hop 3 (10%, AS56635, XENYA), hop 5 (10%, AS6939, HURRICANE) - that router replies sometimes but not always, which is characteristic of ICMPv6 rate-limiting, not an outright filter.
• A UDP probe to a closed high port elicited an ICMPv6 Type 1 (Destination Unreachable) response - the destination is alive and its host firewall returns Type 1 normally.

Likely problem: AS15958 (or a router on the path) drops ICMPv6 Type 2 / oversize traffic; PMTUD will misbehave for hosts that try to send large packets to this destination. Filter is most likely at destination AS15958 (CETIN_doo_AS).

For more information click the ASN number on the far left or follow this direct link: AS15958 details →

What was measured. From NL host (go6lab) we tested AS31042 (SERBIA-BROADBAND-AS Serbia BroadBand-Srpske Kablovske mreze d.o.o.) using (probe) (2a03:87c0::1). Probes: small ICMPv6 Echo (56-byte payload), 1500-byte Echo with DF set, a 24-hop traceroute6, an mtr cycle (10×1s) for per-hop loss, tracepath -6 for path-MTU, a UDP probe to a high closed port, and TCP SYN to ports 443 and 80.

Echo behavior. Both small and 1500-byte Echo Requests received replies (4/4 small, 4/4 1500 B; avg RTT 31.1/36.4 ms). Inbound ICMPv6 Echo Reply is permitted and the path can carry full-MTU packets without needing a Packet-Too-Big signal - consistent with a properly open ICMPv6 stance.

ICMPv6 Type 2 (Packet Too Big) / PMTUD. Path-MTU is 1500 end-to-end (4/4 1500-byte echoes pass), so no router needed to emit a Packet-Too-Big on this run - we cannot directly confirm Type 2 handling, but nothing on the path required it. Type 2 acceptance by the destination would only be exercised over a smaller-MTU path. Active test (ICMPv6 Echo + forged PTB): we forged an ICMPv6 Type 2 (MTU=1280) toward this destination - the destination then split its 1500-byte Echo Reply into 2 fragments via the IPv6 Fragment Header. Type 2 is accepted and honored by this destination's stack.

Path observations. Traceroute saw 10 responsive hop(s). The deepest hop that returned a Time-Exceeded was bg-tp-c-1-po2.sbb.rs [2a00:1dd8:2:c001::1] in AS31042 (SERBIA-BROADBAND-AS). The path entered the destination AS - intermediate hops inside that AS replied - but every probed host inside its prefix was silent. The filter is at the destination AS edge (or applied to all hosts within).

Other signals.

• Per-hop loss between 5% and 95% on hop 6 (20%, AS9002, RETN-AS) - that router replies sometimes but not always, which is characteristic of ICMPv6 rate-limiting, not an outright filter.
• A UDP probe to a closed high port elicited an ICMPv6 Type 1 (Destination Unreachable) response - the destination is alive and its host firewall returns Type 1 normally.

Likely problem: none. AS31042 accepts ICMPv6 Echo and the path between us is fully usable for Echo and 1500-byte traffic.

For more information click the ASN number on the far left or follow this direct link: AS31042 details →

What was measured. From ITA host (Karsolink) we tested AS31042 (SERBIA-BROADBAND-AS Serbia BroadBand-Srpske Kablovske mreze d.o.o.) using (probe) (2a03:87c0::1). Probes: small ICMPv6 Echo (56-byte payload), 1500-byte Echo with DF set, a 24-hop traceroute6, an mtr cycle (10×1s) for per-hop loss, tracepath -6 for path-MTU, a UDP probe to a high closed port, and TCP SYN to ports 443 and 80.

Echo behavior. Both small and 1500-byte Echo Requests received replies (4/4 small, 4/4 1500 B; avg RTT 41.4/40.9 ms). Inbound ICMPv6 Echo Reply is permitted and the path can carry full-MTU packets without needing a Packet-Too-Big signal - consistent with a properly open ICMPv6 stance.

ICMPv6 Type 2 (Packet Too Big) / PMTUD. Path-MTU is 1500 end-to-end (4/4 1500-byte echoes pass), so no router needed to emit a Packet-Too-Big on this run - we cannot directly confirm Type 2 handling, but nothing on the path required it. Type 2 acceptance by the destination would only be exercised over a smaller-MTU path. Active test attempted but no Echo Reply to 1300-byte probe; cannot decide Type 2 acceptance from this run.

Path observations. Traceroute saw 9 responsive hop(s). The deepest hop that returned a Time-Exceeded was bg-tp-c-1-po1.sbb.rs [2a00:1dd8:2:c000::1] in AS31042 (SERBIA-BROADBAND-AS). The path entered the destination AS - intermediate hops inside that AS replied - but every probed host inside its prefix was silent. The filter is at the destination AS edge (or applied to all hosts within).

Other signals.

• Per-hop loss between 5% and 95% on hop 5 (10%, AS9002, RETN-AS), hop 9 (10%, AS31042, SERBIA-BROADBAND-AS) - that router replies sometimes but not always, which is characteristic of ICMPv6 rate-limiting, not an outright filter.
• A UDP probe to a closed high port elicited an ICMPv6 Type 1 (Destination Unreachable) response - the destination is alive and its host firewall returns Type 1 normally.
• TCP SYN was refused (RST) on tcp/443, tcp/80 - the host is reachable on TCP, so any ICMPv6 silence above is firewalling, not the host being down.

Likely problem: none. AS31042 accepts ICMPv6 Echo and the path between us is fully usable for Echo and 1500-byte traffic.

For more information click the ASN number on the far left or follow this direct link: AS31042 details →

What was measured. From SLO host (6connect) we tested AS31042 (SERBIA-BROADBAND-AS Serbia BroadBand-Srpske Kablovske mreze d.o.o.) using (probe) (2a03:87c0::1). Probes: small ICMPv6 Echo (56-byte payload), 1500-byte Echo with DF set, a 24-hop traceroute6, an mtr cycle (10×1s) for per-hop loss, tracepath -6 for path-MTU, a UDP probe to a high closed port, and TCP SYN to ports 443 and 80.

Echo behavior. Both small and 1500-byte Echo Requests received replies (4/4 small, 3/4 1500 B; avg RTT 19.9/21.8 ms). Inbound ICMPv6 Echo Reply is permitted and the path can carry full-MTU packets without needing a Packet-Too-Big signal - consistent with a properly open ICMPv6 stance.

ICMPv6 Type 2 (Packet Too Big) / PMTUD. Path-MTU is 1500 end-to-end (3/4 1500-byte echoes pass), so no router needed to emit a Packet-Too-Big on this run - we cannot directly confirm Type 2 handling, but nothing on the path required it. Type 2 acceptance by the destination would only be exercised over a smaller-MTU path. Active test (ICMPv6 Echo + forged PTB): we forged an ICMPv6 Type 2 (MTU=1280) toward this destination - the destination then split its 1500-byte Echo Reply into 2 fragments via the IPv6 Fragment Header. Type 2 is accepted and honored by this destination's stack.

Path observations. Traceroute saw 12 responsive hop(s). The deepest hop that returned a Time-Exceeded was bg-tp-c-1-po1.sbb.rs [2a00:1dd8:2:c000::1] in AS31042 (SERBIA-BROADBAND-AS). The path entered the destination AS - intermediate hops inside that AS replied - but every probed host inside its prefix was silent. The filter is at the destination AS edge (or applied to all hosts within).

Other signals.

• Per-hop loss between 5% and 95% on hop 3 (90%, AS56635, XENYA) - that router replies sometimes but not always, which is characteristic of ICMPv6 rate-limiting, not an outright filter.
• A UDP probe to a closed high port elicited an ICMPv6 Type 1 (Destination Unreachable) response - the destination is alive and its host firewall returns Type 1 normally.
• TCP SYN was refused (RST) on tcp/443, tcp/80 - the host is reachable on TCP, so any ICMPv6 silence above is firewalling, not the host being down.

Likely problem: none. AS31042 accepts ICMPv6 Echo and the path between us is fully usable for Echo and 1500-byte traffic.

For more information click the ASN number on the far left or follow this direct link: AS31042 details →

What was measured. From NL host (go6lab) we tested AS35779 (MCLOUD-AS mCloud doo) using (probe) (2a07:de80::1). Probes: small ICMPv6 Echo (56-byte payload), 1500-byte Echo with DF set, a 24-hop traceroute6, an mtr cycle (10×1s) for per-hop loss, tracepath -6 for path-MTU, a UDP probe to a high closed port, and TCP SYN to ports 443 and 80.

Echo behavior. Both small and 1500-byte Echo Requests received replies (4/4 small, 4/4 1500 B; avg RTT 49.7/50.0 ms). Inbound ICMPv6 Echo Reply is permitted and the path can carry full-MTU packets without needing a Packet-Too-Big signal - consistent with a properly open ICMPv6 stance.

ICMPv6 Type 2 (Packet Too Big) / PMTUD. Path-MTU is 1500 end-to-end (4/4 1500-byte echoes pass), so no router needed to emit a Packet-Too-Big on this run - we cannot directly confirm Type 2 handling, but nothing on the path required it. Type 2 acceptance by the destination would only be exercised over a smaller-MTU path. Active test (ICMPv6 Echo + forged PTB): we forged an ICMPv6 Type 2 (MTU=1280) toward this destination - the destination then split its 1500-byte Echo Reply into 2 fragments via the IPv6 Fragment Header. Type 2 is accepted and honored by this destination's stack.

Path observations. Traceroute saw 14 responsive hop(s) and reached the target itself. The deepest hop that returned a Time-Exceeded was 2a07:de80::1 in AS35779 (MCLOUD-AS). The path completed cleanly to the destination.

Other signals.

• Per-hop loss between 5% and 95% on hop 5 (10%, AS31500, GNM-AS), hop 8 (20%, AS6939, HURRICANE), hop 9 (40%, AS6939, HURRICANE) - that router replies sometimes but not always, which is characteristic of ICMPv6 rate-limiting, not an outright filter.
• A UDP probe to a closed high port elicited an ICMPv6 Type 1 (Destination Unreachable) response - the destination is alive and its host firewall returns Type 1 normally.

Likely problem: none. AS35779 accepts ICMPv6 Echo and the path between us is fully usable for Echo and 1500-byte traffic.

For more information click the ASN number on the far left or follow this direct link: AS35779 details →

What was measured. From ITA host (Karsolink) we tested AS35779 (MCLOUD-AS mCloud doo) using (probe) (2a07:de80::1). Probes: small ICMPv6 Echo (56-byte payload), 1500-byte Echo with DF set, a 24-hop traceroute6, an mtr cycle (10×1s) for per-hop loss, tracepath -6 for path-MTU, a UDP probe to a high closed port, and TCP SYN to ports 443 and 80.

Echo behavior. Both small and 1500-byte Echo Requests received replies (4/4 small, 4/4 1500 B; avg RTT 31.5/31.7 ms). Inbound ICMPv6 Echo Reply is permitted and the path can carry full-MTU packets without needing a Packet-Too-Big signal - consistent with a properly open ICMPv6 stance.

ICMPv6 Type 2 (Packet Too Big) / PMTUD. Path-MTU is 1500 end-to-end (4/4 1500-byte echoes pass), so no router needed to emit a Packet-Too-Big on this run - we cannot directly confirm Type 2 handling, but nothing on the path required it. Type 2 acceptance by the destination would only be exercised over a smaller-MTU path. Active test attempted but no Echo Reply to 1300-byte probe; cannot decide Type 2 acceptance from this run.

Path observations. Traceroute saw 10 responsive hop(s) and reached the target itself. The deepest hop that returned a Time-Exceeded was 2a07:de80::1 in AS35779 (MCLOUD-AS). The path completed cleanly to the destination.

Other signals.

• Per-hop loss between 5% and 95% on hop 3 (80%, AS204471, KARSOLINK) - that router replies sometimes but not always, which is characteristic of ICMPv6 rate-limiting, not an outright filter.
• A UDP probe to a closed high port elicited an ICMPv6 Type 1 (Destination Unreachable) response - the destination is alive and its host firewall returns Type 1 normally.
• TCP SYN was refused (RST) on tcp/443, tcp/80 - the host is reachable on TCP, so any ICMPv6 silence above is firewalling, not the host being down.

Likely problem: none. AS35779 accepts ICMPv6 Echo and the path between us is fully usable for Echo and 1500-byte traffic.

For more information click the ASN number on the far left or follow this direct link: AS35779 details →

What was measured. From SLO host (6connect) we tested AS35779 (MCLOUD-AS mCloud doo) using (probe) (2a07:de80::1). Probes: small ICMPv6 Echo (56-byte payload), 1500-byte Echo with DF set, a 24-hop traceroute6, an mtr cycle (10×1s) for per-hop loss, tracepath -6 for path-MTU, a UDP probe to a high closed port, and TCP SYN to ports 443 and 80.

Echo behavior. Both small and 1500-byte Echo Requests received replies (4/4 small, 4/4 1500 B; avg RTT 15.0/24.1 ms). Inbound ICMPv6 Echo Reply is permitted and the path can carry full-MTU packets without needing a Packet-Too-Big signal - consistent with a properly open ICMPv6 stance.

ICMPv6 Type 2 (Packet Too Big) / PMTUD. Path-MTU is 1500 end-to-end (4/4 1500-byte echoes pass), so no router needed to emit a Packet-Too-Big on this run - we cannot directly confirm Type 2 handling, but nothing on the path required it. Type 2 acceptance by the destination would only be exercised over a smaller-MTU path. Active test (ICMPv6 Echo + forged PTB): we forged an ICMPv6 Type 2 (MTU=1280) toward this destination - the destination then split its 1500-byte Echo Reply into 2 fragments via the IPv6 Fragment Header. Type 2 is accepted and honored by this destination's stack.

Path observations. Traceroute saw 10 responsive hop(s) and reached the target itself. The deepest hop that returned a Time-Exceeded was 2a07:de80::1 in AS35779 (MCLOUD-AS). The path completed cleanly to the destination.

Other signals.

• Per-hop loss between 5% and 95% on hop 3 (80%, AS56635, XENYA), hop 5 (20%, AS6939, HURRICANE) - that router replies sometimes but not always, which is characteristic of ICMPv6 rate-limiting, not an outright filter.
• A UDP probe to a closed high port elicited an ICMPv6 Type 1 (Destination Unreachable) response - the destination is alive and its host firewall returns Type 1 normally.
• TCP SYN was refused (RST) on tcp/443, tcp/80 - the host is reachable on TCP, so any ICMPv6 silence above is firewalling, not the host being down.

Likely problem: none. AS35779 accepts ICMPv6 Echo and the path between us is fully usable for Echo and 1500-byte traffic.

For more information click the ASN number on the far left or follow this direct link: AS35779 details →

What was measured. From NL host (go6lab) we tested AS41897 (SAT-TRAKT-AS Sat-Trakt D.O.O.) using (probe) (2a0c:6300::1). Probes: small ICMPv6 Echo (56-byte payload), 1500-byte Echo with DF set, a 24-hop traceroute6, an mtr cycle (10×1s) for per-hop loss, tracepath -6 for path-MTU, a UDP probe to a high closed port, and TCP SYN to ports 443 and 80.

Echo behavior. Both small and 1500-byte Echo Requests received replies (4/4 small, 4/4 1500 B; avg RTT 37.7/37.6 ms). Inbound ICMPv6 Echo Reply is permitted and the path can carry full-MTU packets without needing a Packet-Too-Big signal - consistent with a properly open ICMPv6 stance.

ICMPv6 Type 2 (Packet Too Big) / PMTUD. Path-MTU is 1500 end-to-end (4/4 1500-byte echoes pass), so no router needed to emit a Packet-Too-Big on this run - we cannot directly confirm Type 2 handling, but nothing on the path required it. Type 2 acceptance by the destination would only be exercised over a smaller-MTU path. Active test (ICMPv6 Echo + forged PTB): we forged an ICMPv6 Type 2 (MTU=1280) toward this destination - the destination then split its 1500-byte Echo Reply into 2 fragments via the IPv6 Fragment Header. Type 2 is accepted and honored by this destination's stack.

Path observations. Traceroute saw 7 responsive hop(s) and reached the target itself. The deepest hop that returned a Time-Exceeded was 2a0c:6300::1 in AS41897 (SAT-TRAKT-AS). The path completed cleanly to the destination.

Other signals.

• A UDP probe to a closed high port elicited an ICMPv6 Type 1 (Destination Unreachable) response - the destination is alive and its host firewall returns Type 1 normally.

Likely problem: none. AS41897 accepts ICMPv6 Echo and the path between us is fully usable for Echo and 1500-byte traffic.

For more information click the ASN number on the far left or follow this direct link: AS41897 details →

What was measured. From ITA host (Karsolink) we tested AS41897 (SAT-TRAKT-AS Sat-Trakt D.O.O.) using (probe) (2a0c:6300::1). Probes: small ICMPv6 Echo (56-byte payload), 1500-byte Echo with DF set, a 24-hop traceroute6, an mtr cycle (10×1s) for per-hop loss, tracepath -6 for path-MTU, a UDP probe to a high closed port, and TCP SYN to ports 443 and 80.

Echo behavior. Both small and 1500-byte Echo Requests received replies (4/4 small, 4/4 1500 B; avg RTT 25.5/25.6 ms). Inbound ICMPv6 Echo Reply is permitted and the path can carry full-MTU packets without needing a Packet-Too-Big signal - consistent with a properly open ICMPv6 stance.

ICMPv6 Type 2 (Packet Too Big) / PMTUD. Path-MTU is 1500 end-to-end (4/4 1500-byte echoes pass), so no router needed to emit a Packet-Too-Big on this run - we cannot directly confirm Type 2 handling, but nothing on the path required it. Type 2 acceptance by the destination would only be exercised over a smaller-MTU path. Active test attempted but no Echo Reply to 1300-byte probe; cannot decide Type 2 acceptance from this run.

Path observations. Traceroute saw 8 responsive hop(s) and reached the target itself. The deepest hop that returned a Time-Exceeded was 2a0c:6300::1 in AS41897 (SAT-TRAKT-AS). The path completed cleanly to the destination.

Other signals.

• A UDP probe to a closed high port elicited an ICMPv6 Type 1 (Destination Unreachable) response - the destination is alive and its host firewall returns Type 1 normally.
• TCP SYN was refused (RST) on tcp/443, tcp/80 - the host is reachable on TCP, so any ICMPv6 silence above is firewalling, not the host being down.

Likely problem: none. AS41897 accepts ICMPv6 Echo and the path between us is fully usable for Echo and 1500-byte traffic.

For more information click the ASN number on the far left or follow this direct link: AS41897 details →

What was measured. From SLO host (6connect) we tested AS41897 (SAT-TRAKT-AS Sat-Trakt D.O.O.) using (probe) (2a0c:6300::1). Probes: small ICMPv6 Echo (56-byte payload), 1500-byte Echo with DF set, a 24-hop traceroute6, an mtr cycle (10×1s) for per-hop loss, tracepath -6 for path-MTU, a UDP probe to a high closed port, and TCP SYN to ports 443 and 80.

Echo behavior. Both small and 1500-byte Echo Requests received replies (4/4 small, 3/4 1500 B; avg RTT 15.6/16.6 ms). Inbound ICMPv6 Echo Reply is permitted and the path can carry full-MTU packets without needing a Packet-Too-Big signal - consistent with a properly open ICMPv6 stance.

ICMPv6 Type 2 (Packet Too Big) / PMTUD. Path-MTU is 1500 end-to-end (3/4 1500-byte echoes pass), so no router needed to emit a Packet-Too-Big on this run - we cannot directly confirm Type 2 handling, but nothing on the path required it. Type 2 acceptance by the destination would only be exercised over a smaller-MTU path. Active test (ICMPv6 Echo + forged PTB): we forged an ICMPv6 Type 2 (MTU=1280) toward this destination - the destination then split its 1500-byte Echo Reply into 2 fragments via the IPv6 Fragment Header. Type 2 is accepted and honored by this destination's stack.

Path observations. Traceroute saw 10 responsive hop(s) and reached the target itself. The deepest hop that returned a Time-Exceeded was 2a0c:6300::1 in AS41897 (SAT-TRAKT-AS). The path completed cleanly to the destination.

Other signals.

• Per-hop loss between 5% and 95% on hop 3 (70%, AS56635, XENYA) - that router replies sometimes but not always, which is characteristic of ICMPv6 rate-limiting, not an outright filter.
• A UDP probe to a closed high port elicited an ICMPv6 Type 1 (Destination Unreachable) response - the destination is alive and its host firewall returns Type 1 normally.
• TCP SYN was refused (RST) on tcp/443, tcp/80 - the host is reachable on TCP, so any ICMPv6 silence above is firewalling, not the host being down.

Likely problem: none. AS41897 accepts ICMPv6 Echo and the path between us is fully usable for Echo and 1500-byte traffic.

For more information click the ASN number on the far left or follow this direct link: AS41897 details →

What was measured. From NL host (go6lab) we tested AS43191 (providus-as Providus d.o.o.) using monitor.providus.rs (2a03:5fe0:2::55). Probes: small ICMPv6 Echo (56-byte payload), 1500-byte Echo with DF set, a 24-hop traceroute6, an mtr cycle (10×1s) for per-hop loss, tracepath -6 for path-MTU, a UDP probe to a high closed port, and TCP SYN to ports 443 and 80.

Echo behavior. Both small and 1500-byte Echo Requests received replies (4/4 small, 4/4 1500 B; avg RTT 28.1/28.2 ms). Inbound ICMPv6 Echo Reply is permitted and the path can carry full-MTU packets without needing a Packet-Too-Big signal - consistent with a properly open ICMPv6 stance.

ICMPv6 Type 2 (Packet Too Big) / PMTUD. Path-MTU is 1500 end-to-end (4/4 1500-byte echoes pass), so no router needed to emit a Packet-Too-Big on this run - we cannot directly confirm Type 2 handling, but nothing on the path required it. Type 2 acceptance by the destination would only be exercised over a smaller-MTU path. Active test (ICMPv6 Echo + forged PTB): we forged an ICMPv6 Type 2 (MTU=1280) toward this destination - the destination then split its 1500-byte Echo Reply into 2 fragments via the IPv6 Fragment Header. Type 2 is accepted and honored by this destination's stack.

Path observations. Traceroute saw 13 responsive hop(s) and reached the target itself. The deepest hop that returned a Time-Exceeded was srv68-55.itplatforma.com [2a03:5fe0:2::55] in AS43191 (providus-as). The path completed cleanly to the destination.

Other signals.

• Per-hop loss between 5% and 95% on hop 7 (50%, AS6939, HURRICANE) - that router replies sometimes but not always, which is characteristic of ICMPv6 rate-limiting, not an outright filter.
• A UDP probe to a closed high port elicited an ICMPv6 Type 1 (Destination Unreachable) response - the destination is alive and its host firewall returns Type 1 normally.
• TCP SYN was accepted (open) on tcp/443, tcp/80 - the host is reachable on TCP, so any ICMPv6 silence above is firewalling, not the host being down.

Likely problem: none. AS43191 accepts ICMPv6 Echo and the path between us is fully usable for Echo and 1500-byte traffic.

For more information click the ASN number on the far left or follow this direct link: AS43191 details →

What was measured. From ITA host (Karsolink) we tested AS43191 (providus-as Providus d.o.o.) using monitor.providus.rs (2a03:5fe0:2::55). Probes: small ICMPv6 Echo (56-byte payload), 1500-byte Echo with DF set, a 24-hop traceroute6, an mtr cycle (10×1s) for per-hop loss, tracepath -6 for path-MTU, a UDP probe to a high closed port, and TCP SYN to ports 443 and 80.

Echo behavior. Both small and 1500-byte Echo Requests received replies (4/4 small, 4/4 1500 B; avg RTT 29.6/29.6 ms). Inbound ICMPv6 Echo Reply is permitted and the path can carry full-MTU packets without needing a Packet-Too-Big signal - consistent with a properly open ICMPv6 stance.

ICMPv6 Type 2 (Packet Too Big) / PMTUD. Path-MTU is 1500 end-to-end (4/4 1500-byte echoes pass), so no router needed to emit a Packet-Too-Big on this run - we cannot directly confirm Type 2 handling, but nothing on the path required it. Type 2 acceptance by the destination would only be exercised over a smaller-MTU path. Active test (TLS handshake + forged PTB): segment size stayed at 4284 B (no shrinkage) after our forged Type 2 - Type 2 was not honored (either filtered en route, the destination ignored / failed to validate our PTB, or its PMTU cache key didn't match the test flow). PMTUD does not work toward this address from us.

Path observations. Traceroute saw 10 responsive hop(s) and reached the target itself. The deepest hop that returned a Time-Exceeded was srv68-55.itplatforma.com [2a03:5fe0:2::55] in AS43191 (providus-as). The path completed cleanly to the destination.

Other signals.

• Per-hop loss between 5% and 95% on hop 3 (80%, AS204471, KARSOLINK) - that router replies sometimes but not always, which is characteristic of ICMPv6 rate-limiting, not an outright filter.
• A UDP probe to a closed high port elicited an ICMPv6 Type 1 (Destination Unreachable) response - the destination is alive and its host firewall returns Type 1 normally.
• TCP SYN was accepted (open) on tcp/443, tcp/80 - the host is reachable on TCP, so any ICMPv6 silence above is firewalling, not the host being down.

Likely problem: none. AS43191 accepts ICMPv6 Echo and the path between us is fully usable for Echo and 1500-byte traffic.

For more information click the ASN number on the far left or follow this direct link: AS43191 details →

What was measured. From SLO host (6connect) we tested AS43191 (providus-as Providus d.o.o.) using monitor.providus.rs (2a03:5fe0:2::55). Probes: small ICMPv6 Echo (56-byte payload), 1500-byte Echo with DF set, a 24-hop traceroute6, an mtr cycle (10×1s) for per-hop loss, tracepath -6 for path-MTU, a UDP probe to a high closed port, and TCP SYN to ports 443 and 80.

Echo behavior. Both small and 1500-byte Echo Requests received replies (4/4 small, 3/4 1500 B; avg RTT 14.2/14.7 ms). Inbound ICMPv6 Echo Reply is permitted and the path can carry full-MTU packets without needing a Packet-Too-Big signal - consistent with a properly open ICMPv6 stance.

ICMPv6 Type 2 (Packet Too Big) / PMTUD. Path-MTU is 1500 end-to-end (3/4 1500-byte echoes pass), so no router needed to emit a Packet-Too-Big on this run - we cannot directly confirm Type 2 handling, but nothing on the path required it. Type 2 acceptance by the destination would only be exercised over a smaller-MTU path. Active test (ICMPv6 Echo + forged PTB): we forged an ICMPv6 Type 2 (MTU=1280) toward this destination - the destination then split its 1500-byte Echo Reply into 2 fragments via the IPv6 Fragment Header. Type 2 is accepted and honored by this destination's stack.

Path observations. Traceroute saw 10 responsive hop(s) and reached the target itself. The deepest hop that returned a Time-Exceeded was srv68-55.itplatforma.com [2a03:5fe0:2::55] in AS43191 (providus-as). The path completed cleanly to the destination.

Other signals.

• Per-hop loss between 5% and 95% on hop 3 (80%, AS56635, XENYA), hop 4 (10%, AS6939, HURRICANE), hop 5 (10%, AS6939, HURRICANE) - that router replies sometimes but not always, which is characteristic of ICMPv6 rate-limiting, not an outright filter.
• A UDP probe to a closed high port elicited an ICMPv6 Type 1 (Destination Unreachable) response - the destination is alive and its host firewall returns Type 1 normally.
• TCP SYN was accepted (open) on tcp/443, tcp/80 - the host is reachable on TCP, so any ICMPv6 silence above is firewalling, not the host being down.

Likely problem: none. AS43191 accepts ICMPv6 Echo and the path between us is fully usable for Echo and 1500-byte traffic.

For more information click the ASN number on the far left or follow this direct link: AS43191 details →

What was measured. From NL host (go6lab) we tested AS44143 (A1SERBIA-AS A1 Srbija d.o.o. Beograd) using (probe) (2a00:61c0::1). Probes: small ICMPv6 Echo (56-byte payload), 1500-byte Echo with DF set, a 24-hop traceroute6, an mtr cycle (10×1s) for per-hop loss, tracepath -6 for path-MTU, a UDP probe to a high closed port, and TCP SYN to ports 443 and 80.

Echo behavior. Both small and 1500-byte Echo Requests received replies (4/4 small, 4/4 1500 B; avg RTT 33.7/33.5 ms). Inbound ICMPv6 Echo Reply is permitted and the path can carry full-MTU packets without needing a Packet-Too-Big signal - consistent with a properly open ICMPv6 stance.

ICMPv6 Type 2 (Packet Too Big) / PMTUD. Path-MTU is 1500 end-to-end (4/4 1500-byte echoes pass), so no router needed to emit a Packet-Too-Big on this run - we cannot directly confirm Type 2 handling, but nothing on the path required it. Type 2 acceptance by the destination would only be exercised over a smaller-MTU path. Active test (ICMPv6 Echo + forged PTB): the next 1500-byte Echo Reply still arrived whole (1460 B, no Fragment Header) after our forged Type 2 - Type 2 was not honored (either filtered en route, the destination ignored / failed to validate our PTB, or its PMTU cache key didn't match the test flow). PMTUD does not work toward this address from us.

Path observations. Traceroute saw 8 responsive hop(s) and reached the target itself. The deepest hop that returned a Time-Exceeded was 2a00:61c0::1 in AS44143 (A1SERBIA-AS). The path completed cleanly to the destination.

Other signals.

• A UDP probe to a closed high port elicited an ICMPv6 Type 1 (Destination Unreachable) response - the destination is alive and its host firewall returns Type 1 normally.

Likely problem: none. AS44143 accepts ICMPv6 Echo and the path between us is fully usable for Echo and 1500-byte traffic.

For more information click the ASN number on the far left or follow this direct link: AS44143 details →

What was measured. From ITA host (Karsolink) we tested AS44143 (A1SERBIA-AS A1 Srbija d.o.o. Beograd) using (probe) (2a00:61c0::1). Probes: small ICMPv6 Echo (56-byte payload), 1500-byte Echo with DF set, a 24-hop traceroute6, an mtr cycle (10×1s) for per-hop loss, tracepath -6 for path-MTU, a UDP probe to a high closed port, and TCP SYN to ports 443 and 80.

Echo behavior. Both small and 1500-byte Echo Requests received replies (4/4 small, 4/4 1500 B; avg RTT 36.5/36.4 ms). Inbound ICMPv6 Echo Reply is permitted and the path can carry full-MTU packets without needing a Packet-Too-Big signal - consistent with a properly open ICMPv6 stance.

ICMPv6 Type 2 (Packet Too Big) / PMTUD. Path-MTU is 1500 end-to-end (4/4 1500-byte echoes pass), so no router needed to emit a Packet-Too-Big on this run - we cannot directly confirm Type 2 handling, but nothing on the path required it. Type 2 acceptance by the destination would only be exercised over a smaller-MTU path. Active test attempted but no Echo Reply to 1300-byte probe; cannot decide Type 2 acceptance from this run.

Path observations. Traceroute saw 10 responsive hop(s) and reached the target itself. The deepest hop that returned a Time-Exceeded was 2a00:61c0::1 in AS44143 (A1SERBIA-AS). The path completed cleanly to the destination.

Other signals.

• Per-hop loss between 5% and 95% on hop 3 (80%, AS204471, KARSOLINK) - that router replies sometimes but not always, which is characteristic of ICMPv6 rate-limiting, not an outright filter.
• A UDP probe to a closed high port elicited an ICMPv6 Type 1 (Destination Unreachable) response - the destination is alive and its host firewall returns Type 1 normally.

Likely problem: none. AS44143 accepts ICMPv6 Echo and the path between us is fully usable for Echo and 1500-byte traffic.

For more information click the ASN number on the far left or follow this direct link: AS44143 details →

What was measured. From SLO host (6connect) we tested AS44143 (A1SERBIA-AS A1 Srbija d.o.o. Beograd) using (probe) (2a00:61c0::1). Probes: small ICMPv6 Echo (56-byte payload), 1500-byte Echo with DF set, a 24-hop traceroute6, an mtr cycle (10×1s) for per-hop loss, tracepath -6 for path-MTU, a UDP probe to a high closed port, and TCP SYN to ports 443 and 80.

Echo behavior. Both small and 1500-byte Echo Requests received replies (4/4 small, 4/4 1500 B; avg RTT 53.6/53.7 ms). Inbound ICMPv6 Echo Reply is permitted and the path can carry full-MTU packets without needing a Packet-Too-Big signal - consistent with a properly open ICMPv6 stance.

ICMPv6 Type 2 (Packet Too Big) / PMTUD. Path-MTU is 1500 end-to-end (4/4 1500-byte echoes pass), so no router needed to emit a Packet-Too-Big on this run - we cannot directly confirm Type 2 handling, but nothing on the path required it. Type 2 acceptance by the destination would only be exercised over a smaller-MTU path. Active test (ICMPv6 Echo + forged PTB): the next 1500-byte Echo Reply still arrived whole (1460 B, no Fragment Header) after our forged Type 2 - Type 2 was not honored (either filtered en route, the destination ignored / failed to validate our PTB, or its PMTU cache key didn't match the test flow). PMTUD does not work toward this address from us.

Path observations. Traceroute saw 8 responsive hop(s) and reached the target itself. The deepest hop that returned a Time-Exceeded was 2a00:61c0::1 in AS44143 (A1SERBIA-AS). The path completed cleanly to the destination.

Other signals.

• Per-hop loss between 5% and 95% on hop 3 (10%, AS5603, SIOL-NET) - that router replies sometimes but not always, which is characteristic of ICMPv6 rate-limiting, not an outright filter.
• A UDP probe to a closed high port elicited an ICMPv6 Type 1 (Destination Unreachable) response - the destination is alive and its host firewall returns Type 1 normally.

Likely problem: none. AS44143 accepts ICMPv6 Echo and the path between us is fully usable for Echo and 1500-byte traffic.

For more information click the ASN number on the far left or follow this direct link: AS44143 details →

What was measured. From NL host (go6lab) we tested AS47267 (RNIDS-AS Serbian National Internet Domain Registry Foundation) using ns1.rnids.rs (2001:67c:69c::59). Probes: small ICMPv6 Echo (56-byte payload), 1500-byte Echo with DF set, a 24-hop traceroute6, an mtr cycle (10×1s) for per-hop loss, tracepath -6 for path-MTU, a UDP probe to a high closed port, and TCP SYN to ports 443 and 80.

Echo behavior. Both small and 1500-byte Echo Requests received replies (4/4 small, 4/4 1500 B; avg RTT 35.5/35.5 ms). Inbound ICMPv6 Echo Reply is permitted and the path can carry full-MTU packets without needing a Packet-Too-Big signal - consistent with a properly open ICMPv6 stance.

ICMPv6 Type 2 (Packet Too Big) / PMTUD. Path-MTU is 1500 end-to-end (4/4 1500-byte echoes pass), so no router needed to emit a Packet-Too-Big on this run - we cannot directly confirm Type 2 handling, but nothing on the path required it. Type 2 acceptance by the destination would only be exercised over a smaller-MTU path. Active test (ICMPv6 Echo + forged PTB): the next 1500-byte Echo Reply still arrived whole (1460 B, no Fragment Header) after our forged Type 2 - Type 2 was not honored (either filtered en route, the destination ignored / failed to validate our PTB, or its PMTU cache key didn't match the test flow). PMTUD does not work toward this address from us.

Path observations. Traceroute saw 10 responsive hop(s). The deepest hop that returned a Time-Exceeded was e0-36.core2.beg1.he.net [2001:470:0:33f::1] in AS6939 (HURRICANE). The path never entered the destination network (AS47267 RNIDS-AS). Responses kept coming through and including AS6939 HURRICANE; after that hop the next routers stopped returning ICMPv6 Time-Exceeded (either filtering it themselves, or the responses are being dropped on the way back). Be careful: the silence starts past (AS6939 HURRICANE), not at it - AS6939 did reply.

Other signals.

• Per-hop loss between 5% and 95% on hop 7 (40%, AS6939, HURRICANE), hop 11 (90%, AS47267, RNIDS-AS) - that router replies sometimes but not always, which is characteristic of ICMPv6 rate-limiting, not an outright filter.

Likely problem: none. AS47267 accepts ICMPv6 Echo and the path between us is fully usable for Echo and 1500-byte traffic.

For more information click the ASN number on the far left or follow this direct link: AS47267 details →

What was measured. From ITA host (Karsolink) we tested AS47267 (RNIDS-AS Serbian National Internet Domain Registry Foundation) using ns1.rnids.rs (2001:67c:69c::59). Probes: small ICMPv6 Echo (56-byte payload), 1500-byte Echo with DF set, a 24-hop traceroute6, an mtr cycle (10×1s) for per-hop loss, tracepath -6 for path-MTU, a UDP probe to a high closed port, and TCP SYN to ports 443 and 80.

Echo behavior. Both small and 1500-byte Echo Requests received replies (4/4 small, 4/4 1500 B; avg RTT 36.4/36.3 ms). Inbound ICMPv6 Echo Reply is permitted and the path can carry full-MTU packets without needing a Packet-Too-Big signal - consistent with a properly open ICMPv6 stance.

ICMPv6 Type 2 (Packet Too Big) / PMTUD. Path-MTU is 1500 end-to-end (4/4 1500-byte echoes pass), so no router needed to emit a Packet-Too-Big on this run - we cannot directly confirm Type 2 handling, but nothing on the path required it. Type 2 acceptance by the destination would only be exercised over a smaller-MTU path. Active test attempted but no Echo Reply to 1300-byte probe; cannot decide Type 2 acceptance from this run.

Path observations. Traceroute saw 8 responsive hop(s). The deepest hop that returned a Time-Exceeded was rnids.sox.rs [2001:7f8:1e::27] in AS13004 (Serbian Open eXchange). The path never entered the destination network (AS47267 RNIDS-AS). Responses kept coming through and including AS13004 Serbian Open eXchange; after that hop the next routers stopped returning ICMPv6 Time-Exceeded (either filtering it themselves, or the responses are being dropped on the way back). Be careful: the silence starts past (AS13004 Serbian Open eXchange), not at it - AS13004 did reply.

Other signals.

• Per-hop loss between 5% and 95% on hop 3 (70%, AS204471, KARSOLINK), hop 9 (30%, AS47267, RNIDS-AS), hop 10 (10%, AS47267, RNIDS-AS) - that router replies sometimes but not always, which is characteristic of ICMPv6 rate-limiting, not an outright filter.

Likely problem: none. AS47267 accepts ICMPv6 Echo and the path between us is fully usable for Echo and 1500-byte traffic.

For more information click the ASN number on the far left or follow this direct link: AS47267 details →

What was measured. From SLO host (6connect) we tested AS47267 (RNIDS-AS Serbian National Internet Domain Registry Foundation) using ns1.rnids.rs (2001:67c:69c::59). Probes: small ICMPv6 Echo (56-byte payload), 1500-byte Echo with DF set, a 24-hop traceroute6, an mtr cycle (10×1s) for per-hop loss, tracepath -6 for path-MTU, a UDP probe to a high closed port, and TCP SYN to ports 443 and 80.

Echo behavior. Both small and 1500-byte Echo Requests received replies (4/4 small, 3/4 1500 B; avg RTT 14.4/14.5 ms). Inbound ICMPv6 Echo Reply is permitted and the path can carry full-MTU packets without needing a Packet-Too-Big signal - consistent with a properly open ICMPv6 stance.

ICMPv6 Type 2 (Packet Too Big) / PMTUD. Path-MTU is 1500 end-to-end (3/4 1500-byte echoes pass), so no router needed to emit a Packet-Too-Big on this run - we cannot directly confirm Type 2 handling, but nothing on the path required it. Type 2 acceptance by the destination would only be exercised over a smaller-MTU path. Active test (ICMPv6 Echo + forged PTB): the next 1500-byte Echo Reply still arrived whole (1460 B, no Fragment Header) after our forged Type 2 - Type 2 was not honored (either filtered en route, the destination ignored / failed to validate our PTB, or its PMTU cache key didn't match the test flow). PMTUD does not work toward this address from us.

Path observations. Traceroute saw 8 responsive hop(s). The deepest hop that returned a Time-Exceeded was rnids.sox.rs [2001:7f8:1e::27] in AS13004 (Serbian Open eXchange). The path never entered the destination network (AS47267 RNIDS-AS). Responses kept coming through and including AS13004 Serbian Open eXchange; after that hop the next routers stopped returning ICMPv6 Time-Exceeded (either filtering it themselves, or the responses are being dropped on the way back). Be careful: the silence starts past (AS13004 Serbian Open eXchange), not at it - AS13004 did reply.

Other signals.

• Per-hop loss between 5% and 95% on hop 3 (40%, AS56635, XENYA), hop 5 (30%, AS6939, HURRICANE), hop 9 (90%, AS47267, RNIDS-AS) - that router replies sometimes but not always, which is characteristic of ICMPv6 rate-limiting, not an outright filter.

Likely problem: none. AS47267 accepts ICMPv6 Echo and the path between us is fully usable for Echo and 1500-byte traffic.

For more information click the ASN number on the far left or follow this direct link: AS47267 details →

What was measured. From NL host (go6lab) we tested AS49167 (COMUTEL-AS COMUTEL d.o.o.) using (probe) (2001:67c:2210::1). Probes: small ICMPv6 Echo (56-byte payload), 1500-byte Echo with DF set, a 24-hop traceroute6, an mtr cycle (10×1s) for per-hop loss, tracepath -6 for path-MTU, a UDP probe to a high closed port, and TCP SYN to ports 443 and 80.

Echo behavior. Small echo works (4/4 replies, avg 37.6 ms), but every 1500-byte Echo Request was lost (0/4). Some link on the path has an MTU below 1500 and the required ICMPv6 Type 2 (Packet Too Big) message is not getting back to us - that is a classic broken-PMTUD signature, frequently caused by a firewall on the destination side that drops ICMPv6 Type 2 along with Echo.

ICMPv6 Type 2 (Packet Too Big) / PMTUD. Path PMTU is below 1500 (MTU=1480) but PMTUD is actually functional. Per-hop diagnostic: a 1500-byte Echo Request elicited an ICMPv6 Packet-Too-Big from 2001:470:0:3b2::2 at hop 11 with announced MTU 1480. That router is generating Type 2 and it reaches us, so PMTUD on this path works. The 1500-byte Echo failure here is a measurement artifact: once our local kernel caches the lower PMTU, ping6 -M do refuses to send 1500-byte packets at all and reports failure. Real TCP / UDP traffic toward this destination would just use the smaller MTU and work normally. Active test (ICMPv6 Echo + forged PTB): we forged an ICMPv6 Type 2 (MTU=1280) toward this destination - the destination then split its 1500-byte Echo Reply into 2 fragments via the IPv6 Fragment Header. Type 2 is accepted and honored by this destination's stack.

Path observations. Traceroute saw 7 responsive hop(s). The deepest hop that returned a Time-Exceeded was tunnel110879-pt.tunnel.tserv18.dus1.ipv6.he.net [2001:470:12:10::2] in AS6939 (HURRICANE). The path never entered the destination network (AS49167 COMUTEL-AS). Responses kept coming through and including AS6939 HURRICANE; after that hop the next routers stopped returning ICMPv6 Time-Exceeded (either filtering it themselves, or the responses are being dropped on the way back). Be careful: the silence starts past (AS6939 HURRICANE), not at it - AS6939 did reply.

Other signals.

• A UDP probe to a closed high port elicited an ICMPv6 Type 1 (Destination Unreachable) response - the destination is alive and its host firewall returns Type 1 normally.

Likely problem: AS49167 (or a router on the path) drops ICMPv6 Type 2 / oversize traffic; PMTUD will misbehave for hosts that try to send large packets to this destination. Filter is most likely at past AS6939 (HURRICANE).

For more information click the ASN number on the far left or follow this direct link: AS49167 details →

What was measured. From ITA host (Karsolink) we tested AS49167 (COMUTEL-AS COMUTEL d.o.o.) using (probe) (2001:67c:2210::1). Probes: small ICMPv6 Echo (56-byte payload), 1500-byte Echo with DF set, a 24-hop traceroute6, an mtr cycle (10×1s) for per-hop loss, tracepath -6 for path-MTU, a UDP probe to a high closed port, and TCP SYN to ports 443 and 80.

Echo behavior. Small echo works (4/4 replies, avg 47.3 ms), but every 1500-byte Echo Request was lost (0/4). Some link on the path has an MTU below 1500 and the required ICMPv6 Type 2 (Packet Too Big) message is not getting back to us - that is a classic broken-PMTUD signature, frequently caused by a firewall on the destination side that drops ICMPv6 Type 2 along with Echo.

ICMPv6 Type 2 (Packet Too Big) / PMTUD. Ping is open but the 1500-byte Echo failed. Small Echo gets through (4/4), 1500-byte Echo with DF is silently lost (0/4). Some link on the path has MTU < 1500. Without a per-hop PMTUD diagnostic we cannot yet tell whether the constraint router generates Type 2 properly or whether Type 2 is being filtered en route. (Run 11_pmtud_diagnose.py to localize.) tracepath learned PMTU=1480, so PTB is at least partially delivered from somewhere on the path. Active test attempted but no Echo Reply to 1300-byte probe; cannot decide Type 2 acceptance from this run.

Path observations. Traceroute saw 9 responsive hop(s). The deepest hop that returned a Time-Exceeded was tunnel110879-pt.tunnel.tserv18.dus1.ipv6.he.net [2001:470:12:10::2] in AS6939 (HURRICANE). The path never entered the destination network (AS49167 COMUTEL-AS). Responses kept coming through and including AS6939 HURRICANE; after that hop the next routers stopped returning ICMPv6 Time-Exceeded (either filtering it themselves, or the responses are being dropped on the way back). Be careful: the silence starts past (AS6939 HURRICANE), not at it - AS6939 did reply.

Other signals.

• Per-hop loss between 5% and 95% on hop 3 (90%, AS204471, KARSOLINK) - that router replies sometimes but not always, which is characteristic of ICMPv6 rate-limiting, not an outright filter.
• A UDP probe to a closed high port elicited an ICMPv6 Type 1 (Destination Unreachable) response - the destination is alive and its host firewall returns Type 1 normally.
• TCP SYN was refused (RST) on tcp/443, tcp/80 - the host is reachable on TCP, so any ICMPv6 silence above is firewalling, not the host being down.

Likely problem: AS49167 (or a router on the path) drops ICMPv6 Type 2 / oversize traffic; PMTUD will misbehave for hosts that try to send large packets to this destination. Filter is most likely at past AS6939 (HURRICANE).

For more information click the ASN number on the far left or follow this direct link: AS49167 details →

What was measured. From SLO host (6connect) we tested AS49167 (COMUTEL-AS COMUTEL d.o.o.) using (probe) (2001:67c:2210::1). Probes: small ICMPv6 Echo (56-byte payload), 1500-byte Echo with DF set, a 24-hop traceroute6, an mtr cycle (10×1s) for per-hop loss, tracepath -6 for path-MTU, a UDP probe to a high closed port, and TCP SYN to ports 443 and 80.

Echo behavior. Small echo works (4/4 replies, avg 49.9 ms), but every 1500-byte Echo Request was lost (0/4). Some link on the path has an MTU below 1500 and the required ICMPv6 Type 2 (Packet Too Big) message is not getting back to us - that is a classic broken-PMTUD signature, frequently caused by a firewall on the destination side that drops ICMPv6 Type 2 along with Echo.

ICMPv6 Type 2 (Packet Too Big) / PMTUD. Path PMTU is below 1500 (MTU=1480) but PMTUD is actually functional. Per-hop diagnostic: a 1500-byte Echo Request elicited an ICMPv6 Packet-Too-Big from 2001:470:0:3b2::2 at hop 15 with announced MTU 1480. That router is generating Type 2 and it reaches us, so PMTUD on this path works. The 1500-byte Echo failure here is a measurement artifact: once our local kernel caches the lower PMTU, ping6 -M do refuses to send 1500-byte packets at all and reports failure. Real TCP / UDP traffic toward this destination would just use the smaller MTU and work normally. Active test (ICMPv6 Echo + forged PTB): we forged an ICMPv6 Type 2 (MTU=1280) toward this destination - the destination then split its 1500-byte Echo Reply into 2 fragments via the IPv6 Fragment Header. Type 2 is accepted and honored by this destination's stack.

Path observations. Traceroute saw 11 responsive hop(s). The deepest hop that returned a Time-Exceeded was tunnel110879-pt.tunnel.tserv18.dus1.ipv6.he.net [2001:470:12:10::2] in AS6939 (HURRICANE). The path never entered the destination network (AS49167 COMUTEL-AS). Responses kept coming through and including AS6939 HURRICANE; after that hop the next routers stopped returning ICMPv6 Time-Exceeded (either filtering it themselves, or the responses are being dropped on the way back). Be careful: the silence starts past (AS6939 HURRICANE), not at it - AS6939 did reply.

Other signals.

• Per-hop loss between 5% and 95% on hop 3 (90%, AS56635, XENYA), hop 4 (20%, AS6939, HURRICANE), hop 5 (20%, AS6939, HURRICANE) - that router replies sometimes but not always, which is characteristic of ICMPv6 rate-limiting, not an outright filter.
• A UDP probe to a closed high port elicited an ICMPv6 Type 1 (Destination Unreachable) response - the destination is alive and its host firewall returns Type 1 normally.
• TCP SYN was refused (RST) on tcp/443, tcp/80 - the host is reachable on TCP, so any ICMPv6 silence above is firewalling, not the host being down.

Likely problem: AS49167 (or a router on the path) drops ICMPv6 Type 2 / oversize traffic; PMTUD will misbehave for hosts that try to send large packets to this destination. Filter is most likely at past AS6939 (HURRICANE).

For more information click the ASN number on the far left or follow this direct link: AS49167 details →

What was measured. From NL host (go6lab) we tested AS56843 (CNT-ISP-AS Centar Novih Tehnologija DOO) using (probe) (2a02:2951::1). Probes: small ICMPv6 Echo (56-byte payload), 1500-byte Echo with DF set, a 24-hop traceroute6, an mtr cycle (10×1s) for per-hop loss, tracepath -6 for path-MTU, a UDP probe to a high closed port, and TCP SYN to ports 443 and 80.

Echo behavior. Both small and 1500-byte Echo Requests received replies (4/4 small, 4/4 1500 B; avg RTT 33.2/33.6 ms). Inbound ICMPv6 Echo Reply is permitted and the path can carry full-MTU packets without needing a Packet-Too-Big signal - consistent with a properly open ICMPv6 stance.

ICMPv6 Type 2 (Packet Too Big) / PMTUD. Path-MTU is 1500 end-to-end (4/4 1500-byte echoes pass), so no router needed to emit a Packet-Too-Big on this run - we cannot directly confirm Type 2 handling, but nothing on the path required it. Type 2 acceptance by the destination would only be exercised over a smaller-MTU path. Active test (ICMPv6 Echo + forged PTB): we forged an ICMPv6 Type 2 (MTU=1280) toward this destination - the destination then split its 1500-byte Echo Reply into 2 fragments via the IPv6 Fragment Header. Type 2 is accepted and honored by this destination's stack.

Path observations. Traceroute saw 11 responsive hop(s) and reached the target itself. The deepest hop that returned a Time-Exceeded was 2a02:2951::1 in AS56843 (CNT-ISP-AS). The path completed cleanly to the destination.

Other signals.

• Per-hop loss between 5% and 95% on hop 8 (50%, ASNone, NA), hop 9 (50%, AS9125, ORIONTELEKOM-AS) - that router replies sometimes but not always, which is characteristic of ICMPv6 rate-limiting, not an outright filter.
• A UDP probe to a closed high port elicited an ICMPv6 Type 1 (Destination Unreachable) response - the destination is alive and its host firewall returns Type 1 normally.

Likely problem: none. AS56843 accepts ICMPv6 Echo and the path between us is fully usable for Echo and 1500-byte traffic.

For more information click the ASN number on the far left or follow this direct link: AS56843 details →

What was measured. From ITA host (Karsolink) we tested AS56843 (CNT-ISP-AS Centar Novih Tehnologija DOO) using (probe) (2a02:2951::1). Probes: small ICMPv6 Echo (56-byte payload), 1500-byte Echo with DF set, a 24-hop traceroute6, an mtr cycle (10×1s) for per-hop loss, tracepath -6 for path-MTU, a UDP probe to a high closed port, and TCP SYN to ports 443 and 80.

Echo behavior. Both small and 1500-byte Echo Requests received replies (4/4 small, 4/4 1500 B; avg RTT 42.7/42.9 ms). Inbound ICMPv6 Echo Reply is permitted and the path can carry full-MTU packets without needing a Packet-Too-Big signal - consistent with a properly open ICMPv6 stance.

ICMPv6 Type 2 (Packet Too Big) / PMTUD. Path-MTU is 1500 end-to-end (4/4 1500-byte echoes pass), so no router needed to emit a Packet-Too-Big on this run - we cannot directly confirm Type 2 handling, but nothing on the path required it. Type 2 acceptance by the destination would only be exercised over a smaller-MTU path. Active test attempted but no Echo Reply to 1300-byte probe; cannot decide Type 2 acceptance from this run.

Path observations. Traceroute saw 9 responsive hop(s) and reached the target itself. The deepest hop that returned a Time-Exceeded was 2a02:2951::1 in AS56843 (CNT-ISP-AS). The path completed cleanly to the destination.

Other signals.

• Per-hop loss between 5% and 95% on hop 3 (70%, AS204471, KARSOLINK) - that router replies sometimes but not always, which is characteristic of ICMPv6 rate-limiting, not an outright filter.
• A UDP probe to a closed high port elicited an ICMPv6 Type 1 (Destination Unreachable) response - the destination is alive and its host firewall returns Type 1 normally.

Likely problem: none. AS56843 accepts ICMPv6 Echo and the path between us is fully usable for Echo and 1500-byte traffic.

For more information click the ASN number on the far left or follow this direct link: AS56843 details →

What was measured. From SLO host (6connect) we tested AS56843 (CNT-ISP-AS Centar Novih Tehnologija DOO) using (probe) (2a02:2951::1). Probes: small ICMPv6 Echo (56-byte payload), 1500-byte Echo with DF set, a 24-hop traceroute6, an mtr cycle (10×1s) for per-hop loss, tracepath -6 for path-MTU, a UDP probe to a high closed port, and TCP SYN to ports 443 and 80.

Echo behavior. Both small and 1500-byte Echo Requests received replies (4/4 small, 3/4 1500 B; avg RTT 36.6/37.5 ms). Inbound ICMPv6 Echo Reply is permitted and the path can carry full-MTU packets without needing a Packet-Too-Big signal - consistent with a properly open ICMPv6 stance.

ICMPv6 Type 2 (Packet Too Big) / PMTUD. Path-MTU is 1500 end-to-end (3/4 1500-byte echoes pass), so no router needed to emit a Packet-Too-Big on this run - we cannot directly confirm Type 2 handling, but nothing on the path required it. Type 2 acceptance by the destination would only be exercised over a smaller-MTU path. Active test (ICMPv6 Echo + forged PTB): we forged an ICMPv6 Type 2 (MTU=1280) toward this destination - the destination then split its 1500-byte Echo Reply into 2 fragments via the IPv6 Fragment Header. Type 2 is accepted and honored by this destination's stack.

Path observations. Traceroute saw 8 responsive hop(s) and reached the target itself. The deepest hop that returned a Time-Exceeded was 2a02:2951::1 in AS56843 (CNT-ISP-AS). The path completed cleanly to the destination.

Other signals.

• Per-hop loss between 5% and 95% on hop 5 (70%, ASNone, NA), hop 6 (60%, AS9125, ORIONTELEKOM-AS) - that router replies sometimes but not always, which is characteristic of ICMPv6 rate-limiting, not an outright filter.
• A UDP probe to a closed high port elicited an ICMPv6 Type 1 (Destination Unreachable) response - the destination is alive and its host firewall returns Type 1 normally.

Likely problem: none. AS56843 accepts ICMPv6 Echo and the path between us is fully usable for Echo and 1500-byte traffic.

For more information click the ASN number on the far left or follow this direct link: AS56843 details →

What was measured. From NL host (go6lab) we tested AS60733 (PERKE-NET ZORAN PEROVIC trading as Agencija Perke.NET) using (probe) (2a09:ab80::1). Probes: small ICMPv6 Echo (56-byte payload), 1500-byte Echo with DF set, a 24-hop traceroute6, an mtr cycle (10×1s) for per-hop loss, tracepath -6 for path-MTU, a UDP probe to a high closed port, and TCP SYN to ports 443 and 80.

Echo behavior. Both small and 1500-byte Echo Requests received replies (4/4 small, 4/4 1500 B; avg RTT 49.8/50.1 ms). Inbound ICMPv6 Echo Reply is permitted and the path can carry full-MTU packets without needing a Packet-Too-Big signal - consistent with a properly open ICMPv6 stance.

ICMPv6 Type 2 (Packet Too Big) / PMTUD. Path-MTU is 1500 end-to-end (4/4 1500-byte echoes pass), so no router needed to emit a Packet-Too-Big on this run - we cannot directly confirm Type 2 handling, but nothing on the path required it. Type 2 acceptance by the destination would only be exercised over a smaller-MTU path. Active test (ICMPv6 Echo + forged PTB): we forged an ICMPv6 Type 2 (MTU=1280) toward this destination - the destination then split its 1500-byte Echo Reply into 2 fragments via the IPv6 Fragment Header. Type 2 is accepted and honored by this destination's stack.

Path observations. Traceroute saw 8 responsive hop(s) and reached the target itself. The deepest hop that returned a Time-Exceeded was demo2.sox.rs [2a09:ab80::1] in AS60733 (PERKE-NET). The path completed cleanly to the destination.

Other signals.

• A UDP probe to a closed high port elicited an ICMPv6 Type 1 (Destination Unreachable) response - the destination is alive and its host firewall returns Type 1 normally.

Likely problem: none. AS60733 accepts ICMPv6 Echo and the path between us is fully usable for Echo and 1500-byte traffic.

For more information click the ASN number on the far left or follow this direct link: AS60733 details →

What was measured. From ITA host (Karsolink) we tested AS60733 (PERKE-NET ZORAN PEROVIC trading as Agencija Perke.NET) using (probe) (2a09:ab80::1). Probes: small ICMPv6 Echo (56-byte payload), 1500-byte Echo with DF set, a 24-hop traceroute6, an mtr cycle (10×1s) for per-hop loss, tracepath -6 for path-MTU, a UDP probe to a high closed port, and TCP SYN to ports 443 and 80.

Echo behavior. Both small and 1500-byte Echo Requests received replies (4/4 small, 4/4 1500 B; avg RTT 70.3/70.3 ms). Inbound ICMPv6 Echo Reply is permitted and the path can carry full-MTU packets without needing a Packet-Too-Big signal - consistent with a properly open ICMPv6 stance.

ICMPv6 Type 2 (Packet Too Big) / PMTUD. Path-MTU is 1500 end-to-end (4/4 1500-byte echoes pass), so no router needed to emit a Packet-Too-Big on this run - we cannot directly confirm Type 2 handling, but nothing on the path required it. Type 2 acceptance by the destination would only be exercised over a smaller-MTU path. Active test attempted but no Echo Reply to 1300-byte probe; cannot decide Type 2 acceptance from this run.

Path observations. Traceroute saw 9 responsive hop(s) and reached the target itself. The deepest hop that returned a Time-Exceeded was demo2.sox.rs [2a09:ab80::1] in AS60733 (PERKE-NET). The path completed cleanly to the destination.

Other signals.

• Per-hop loss between 5% and 95% on hop 3 (50%, AS204471, KARSOLINK) - that router replies sometimes but not always, which is characteristic of ICMPv6 rate-limiting, not an outright filter.
• A UDP probe to a closed high port elicited an ICMPv6 Type 1 (Destination Unreachable) response - the destination is alive and its host firewall returns Type 1 normally.

Likely problem: none. AS60733 accepts ICMPv6 Echo and the path between us is fully usable for Echo and 1500-byte traffic.

For more information click the ASN number on the far left or follow this direct link: AS60733 details →

What was measured. From SLO host (6connect) we tested AS60733 (PERKE-NET ZORAN PEROVIC trading as Agencija Perke.NET) using (probe) (2a09:ab80::1). Probes: small ICMPv6 Echo (56-byte payload), 1500-byte Echo with DF set, a 24-hop traceroute6, an mtr cycle (10×1s) for per-hop loss, tracepath -6 for path-MTU, a UDP probe to a high closed port, and TCP SYN to ports 443 and 80.

Echo behavior. Both small and 1500-byte Echo Requests received replies (4/4 small, 4/4 1500 B; avg RTT 35.1/35.1 ms). Inbound ICMPv6 Echo Reply is permitted and the path can carry full-MTU packets without needing a Packet-Too-Big signal - consistent with a properly open ICMPv6 stance.

ICMPv6 Type 2 (Packet Too Big) / PMTUD. Path-MTU is 1500 end-to-end (4/4 1500-byte echoes pass), so no router needed to emit a Packet-Too-Big on this run - we cannot directly confirm Type 2 handling, but nothing on the path required it. Type 2 acceptance by the destination would only be exercised over a smaller-MTU path. Active test (ICMPv6 Echo + forged PTB): we forged an ICMPv6 Type 2 (MTU=1280) toward this destination - the destination then split its 1500-byte Echo Reply into 2 fragments via the IPv6 Fragment Header. Type 2 is accepted and honored by this destination's stack.

Path observations. Traceroute saw 8 responsive hop(s) and reached the target itself. The deepest hop that returned a Time-Exceeded was demo2.sox.rs [2a09:ab80::1] in AS60733 (PERKE-NET). The path completed cleanly to the destination.

Other signals.

• A UDP probe to a closed high port elicited an ICMPv6 Type 1 (Destination Unreachable) response - the destination is alive and its host firewall returns Type 1 normally.

Likely problem: none. AS60733 accepts ICMPv6 Echo and the path between us is fully usable for Echo and 1500-byte traffic.

For more information click the ASN number on the far left or follow this direct link: AS60733 details →

What was measured. From NL host (go6lab) we tested AS202676 (BRZNET BIZNET DOO) using (probe) (2a0b:4040::1). Probes: small ICMPv6 Echo (56-byte payload), 1500-byte Echo with DF set, a 24-hop traceroute6, an mtr cycle (10×1s) for per-hop loss, tracepath -6 for path-MTU, a UDP probe to a high closed port, and TCP SYN to ports 443 and 80.

Echo behavior. Both small and 1500-byte Echo Requests received replies (4/4 small, 4/4 1500 B; avg RTT 43.6/43.2 ms). Inbound ICMPv6 Echo Reply is permitted and the path can carry full-MTU packets without needing a Packet-Too-Big signal - consistent with a properly open ICMPv6 stance.

ICMPv6 Type 2 (Packet Too Big) / PMTUD. Path-MTU is 1500 end-to-end (4/4 1500-byte echoes pass), so no router needed to emit a Packet-Too-Big on this run - we cannot directly confirm Type 2 handling, but nothing on the path required it. Type 2 acceptance by the destination would only be exercised over a smaller-MTU path. Active test (ICMPv6 Echo + forged PTB): we forged an ICMPv6 Type 2 (MTU=1280) toward this destination - the destination then split its 1500-byte Echo Reply into 2 fragments via the IPv6 Fragment Header. Type 2 is accepted and honored by this destination's stack.

Path observations. Traceroute saw 9 responsive hop(s). The deepest hop that returned a Time-Exceeded was 2a02:2608:ffff:ffff::2c in AS44306 (Omonia). The path never entered the destination network (AS202676 BRZNET). Responses kept coming through and including AS44306 Omonia; after that hop the next routers stopped returning ICMPv6 Time-Exceeded (either filtering it themselves, or the responses are being dropped on the way back). Be careful: the silence starts past (AS44306 Omonia), not at it - AS44306 did reply.

Other signals.

• Per-hop loss between 5% and 95% on hop 3 (10%, AS50673, Serverius-as) - that router replies sometimes but not always, which is characteristic of ICMPv6 rate-limiting, not an outright filter.

Likely problem: none. AS202676 accepts ICMPv6 Echo and the path between us is fully usable for Echo and 1500-byte traffic.

For more information click the ASN number on the far left or follow this direct link: AS202676 details →

What was measured. From ITA host (Karsolink) we tested AS202676 (BRZNET BIZNET DOO) using (probe) (2a0b:4040::1). Probes: small ICMPv6 Echo (56-byte payload), 1500-byte Echo with DF set, a 24-hop traceroute6, an mtr cycle (10×1s) for per-hop loss, tracepath -6 for path-MTU, a UDP probe to a high closed port, and TCP SYN to ports 443 and 80.

Echo behavior. Both small and 1500-byte Echo Requests received replies (4/4 small, 4/4 1500 B; avg RTT 34.6/34.6 ms). Inbound ICMPv6 Echo Reply is permitted and the path can carry full-MTU packets without needing a Packet-Too-Big signal - consistent with a properly open ICMPv6 stance.

ICMPv6 Type 2 (Packet Too Big) / PMTUD. Path-MTU is 1500 end-to-end (4/4 1500-byte echoes pass), so no router needed to emit a Packet-Too-Big on this run - we cannot directly confirm Type 2 handling, but nothing on the path required it. Type 2 acceptance by the destination would only be exercised over a smaller-MTU path. Active test attempted but no Echo Reply to 1300-byte probe; cannot decide Type 2 acceptance from this run.

Path observations. Traceroute saw 7 responsive hop(s). The deepest hop that returned a Time-Exceeded was 2a02:2608:ffff:ffff::2c in AS44306 (Omonia). The path never entered the destination network (AS202676 BRZNET). Responses kept coming through and including AS44306 Omonia; after that hop the next routers stopped returning ICMPv6 Time-Exceeded (either filtering it themselves, or the responses are being dropped on the way back). Be careful: the silence starts past (AS44306 Omonia), not at it - AS44306 did reply.

Other signals.

• Per-hop loss between 5% and 95% on hop 3 (10%, AS204471, KARSOLINK), hop 5 (10%, AS9002, RETN-AS) - that router replies sometimes but not always, which is characteristic of ICMPv6 rate-limiting, not an outright filter.

Likely problem: none. AS202676 accepts ICMPv6 Echo and the path between us is fully usable for Echo and 1500-byte traffic.

For more information click the ASN number on the far left or follow this direct link: AS202676 details →

What was measured. From SLO host (6connect) we tested AS202676 (BRZNET BIZNET DOO) using (probe) (2a0b:4040::1). Probes: small ICMPv6 Echo (56-byte payload), 1500-byte Echo with DF set, a 24-hop traceroute6, an mtr cycle (10×1s) for per-hop loss, tracepath -6 for path-MTU, a UDP probe to a high closed port, and TCP SYN to ports 443 and 80.

Echo behavior. Both small and 1500-byte Echo Requests received replies (4/4 small, 4/4 1500 B; avg RTT 68.8/68.9 ms). Inbound ICMPv6 Echo Reply is permitted and the path can carry full-MTU packets without needing a Packet-Too-Big signal - consistent with a properly open ICMPv6 stance.

ICMPv6 Type 2 (Packet Too Big) / PMTUD. Path-MTU is 1500 end-to-end (4/4 1500-byte echoes pass), so no router needed to emit a Packet-Too-Big on this run - we cannot directly confirm Type 2 handling, but nothing on the path required it. Type 2 acceptance by the destination would only be exercised over a smaller-MTU path. Active test (ICMPv6 Echo + forged PTB): we forged an ICMPv6 Type 2 (MTU=1280) toward this destination - the destination then split its 1500-byte Echo Reply into 2 fragments via the IPv6 Fragment Header. Type 2 is accepted and honored by this destination's stack.

Path observations. Traceroute saw 6 responsive hop(s). The deepest hop that returned a Time-Exceeded was 2a02:2608:ffff:ffff::2c in AS44306 (Omonia). The path never entered the destination network (AS202676 BRZNET). Responses kept coming through and including AS44306 Omonia; after that hop the next routers stopped returning ICMPv6 Time-Exceeded (either filtering it themselves, or the responses are being dropped on the way back). Be careful: the silence starts past (AS44306 Omonia), not at it - AS44306 did reply.

Other signals.

• Per-hop loss between 5% and 95% on hop 3 (10%, AS5603, SIOL-NET) - that router replies sometimes but not always, which is characteristic of ICMPv6 rate-limiting, not an outright filter.

Likely problem: none. AS202676 accepts ICMPv6 Echo and the path between us is fully usable for Echo and 1500-byte traffic.

For more information click the ASN number on the far left or follow this direct link: AS202676 details →

What was measured. From NL host (go6lab) we tested AS205007 (ESERVER-RS Maxim Azarov trading as eServer) using (SPF ip6: literal) (2a04:b540:3000:2::3). Probes: small ICMPv6 Echo (56-byte payload), 1500-byte Echo with DF set, a 24-hop traceroute6, an mtr cycle (10×1s) for per-hop loss, tracepath -6 for path-MTU, a UDP probe to a high closed port, and TCP SYN to ports 443 and 80.

Echo behavior. Both small and 1500-byte Echo Requests received replies (4/4 small, 4/4 1500 B; avg RTT 31.4/30.8 ms). Inbound ICMPv6 Echo Reply is permitted and the path can carry full-MTU packets without needing a Packet-Too-Big signal - consistent with a properly open ICMPv6 stance.

ICMPv6 Type 2 (Packet Too Big) / PMTUD. Path-MTU is 1500 end-to-end (4/4 1500-byte echoes pass), so no router needed to emit a Packet-Too-Big on this run - we cannot directly confirm Type 2 handling, but nothing on the path required it. Type 2 acceptance by the destination would only be exercised over a smaller-MTU path. Active test (ICMPv6 Echo + forged PTB): we forged an ICMPv6 Type 2 (MTU=1280) toward this destination - the destination then split its 1500-byte Echo Reply into 2 fragments via the IPv6 Fragment Header. Type 2 is accepted and honored by this destination's stack.

Path observations. Traceroute saw 12 responsive hop(s) and reached the target itself. The deepest hop that returned a Time-Exceeded was service-1.rs.eserver.net [2a04:b540:3000:2::3] in AS205007 (ESERVER-RS). The path completed cleanly to the destination.

Other signals.

• Per-hop loss between 5% and 95% on hop 9 (40%, AS8400, TELEKOM-AS), hop 10 (20%, AS6700, BEOTEL-AS) - that router replies sometimes but not always, which is characteristic of ICMPv6 rate-limiting, not an outright filter.
• A UDP probe to a closed high port elicited an ICMPv6 Type 1 (Destination Unreachable) response - the destination is alive and its host firewall returns Type 1 normally.
• TCP SYN was accepted (open) on tcp/443, tcp/80 - the host is reachable on TCP, so any ICMPv6 silence above is firewalling, not the host being down.

Likely problem: none. AS205007 accepts ICMPv6 Echo and the path between us is fully usable for Echo and 1500-byte traffic.

For more information click the ASN number on the far left or follow this direct link: AS205007 details →

What was measured. From ITA host (Karsolink) we tested AS205007 (ESERVER-RS Maxim Azarov trading as eServer) using (SPF ip6: literal) (2a04:b540:3000:2::3). Probes: small ICMPv6 Echo (56-byte payload), 1500-byte Echo with DF set, a 24-hop traceroute6, an mtr cycle (10×1s) for per-hop loss, tracepath -6 for path-MTU, a UDP probe to a high closed port, and TCP SYN to ports 443 and 80.

Echo behavior. Both small and 1500-byte Echo Requests received replies (4/4 small, 4/4 1500 B; avg RTT 50.7/50.5 ms). Inbound ICMPv6 Echo Reply is permitted and the path can carry full-MTU packets without needing a Packet-Too-Big signal - consistent with a properly open ICMPv6 stance.

ICMPv6 Type 2 (Packet Too Big) / PMTUD. Path-MTU is 1500 end-to-end (4/4 1500-byte echoes pass), so no router needed to emit a Packet-Too-Big on this run - we cannot directly confirm Type 2 handling, but nothing on the path required it. Type 2 acceptance by the destination would only be exercised over a smaller-MTU path. Active test (TLS handshake + forged PTB): segment size stayed at 1428 B (no shrinkage) after our forged Type 2 - Type 2 was not honored (either filtered en route, the destination ignored / failed to validate our PTB, or its PMTU cache key didn't match the test flow). PMTUD does not work toward this address from us.

Path observations. Traceroute saw 10 responsive hop(s) and reached the target itself. The deepest hop that returned a Time-Exceeded was service-1.rs.eserver.net [2a04:b540:3000:2::3] in AS205007 (ESERVER-RS). The path completed cleanly to the destination.

Other signals.

• Per-hop loss between 5% and 95% on hop 8 (10%, AS6700, BEOTEL-AS) - that router replies sometimes but not always, which is characteristic of ICMPv6 rate-limiting, not an outright filter.
• A UDP probe to a closed high port elicited an ICMPv6 Type 1 (Destination Unreachable) response - the destination is alive and its host firewall returns Type 1 normally.
• TCP SYN was accepted (open) on tcp/443, tcp/80 - the host is reachable on TCP, so any ICMPv6 silence above is firewalling, not the host being down.

Likely problem: none. AS205007 accepts ICMPv6 Echo and the path between us is fully usable for Echo and 1500-byte traffic.

For more information click the ASN number on the far left or follow this direct link: AS205007 details →

What was measured. From SLO host (6connect) we tested AS205007 (ESERVER-RS Maxim Azarov trading as eServer) using (SPF ip6: literal) (2a04:b540:3000:2::3). Probes: small ICMPv6 Echo (56-byte payload), 1500-byte Echo with DF set, a 24-hop traceroute6, an mtr cycle (10×1s) for per-hop loss, tracepath -6 for path-MTU, a UDP probe to a high closed port, and TCP SYN to ports 443 and 80.

Echo behavior. Both small and 1500-byte Echo Requests received replies (4/4 small, 3/4 1500 B; avg RTT 31.1/31.9 ms). Inbound ICMPv6 Echo Reply is permitted and the path can carry full-MTU packets without needing a Packet-Too-Big signal - consistent with a properly open ICMPv6 stance.

ICMPv6 Type 2 (Packet Too Big) / PMTUD. Path-MTU is 1500 end-to-end (3/4 1500-byte echoes pass), so no router needed to emit a Packet-Too-Big on this run - we cannot directly confirm Type 2 handling, but nothing on the path required it. Type 2 acceptance by the destination would only be exercised over a smaller-MTU path. Active test (ICMPv6 Echo + forged PTB): we forged an ICMPv6 Type 2 (MTU=1280) toward this destination - the destination then split its 1500-byte Echo Reply into 2 fragments via the IPv6 Fragment Header. Type 2 is accepted and honored by this destination's stack.

Path observations. Traceroute saw 13 responsive hop(s) and reached the target itself. The deepest hop that returned a Time-Exceeded was service-1.rs.eserver.net [2a04:b540:3000:2::3] in AS205007 (ESERVER-RS). The path completed cleanly to the destination.

Other signals.

• Per-hop loss between 5% and 95% on hop 3 (90%, AS56635, XENYA), hop 4 (70%, AS6939, HURRICANE), hop 5 (30%, AS6939, HURRICANE), hop 10 (50%, AS8400, TELEKOM-AS), hop 11 (30%, AS6700, BEOTEL-AS) - that router replies sometimes but not always, which is characteristic of ICMPv6 rate-limiting, not an outright filter.
• A UDP probe to a closed high port elicited an ICMPv6 Type 1 (Destination Unreachable) response - the destination is alive and its host firewall returns Type 1 normally.
• TCP SYN was accepted (open) on tcp/443, tcp/80 - the host is reachable on TCP, so any ICMPv6 silence above is firewalling, not the host being down.

Likely problem: none. AS205007 accepts ICMPv6 Echo and the path between us is fully usable for Echo and 1500-byte traffic.

For more information click the ASN number on the far left or follow this direct link: AS205007 details →