ICMPv6 measurements for Slovenian operators (ASNs)

What was measured. From NL host (go6lab) we tested AS2107 (ARNES-NET - ARNES) using aa.arnes.si (2001:1470:8000::87). 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 28.7/28.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 17 responsive hop(s) and reached the target itself. The deepest hop that returned a Time-Exceeded was kanin.arnes.si [2001:1470:8000::87] in AS2107 (ARNES-NET). The path completed cleanly to the destination.

Other signals.

• Per-hop loss between 5% and 95% on hop 5 (90%, AS174, COGENT-174), hop 6 (60%, AS174, COGENT-174), hop 8 (30%, AS174, COGENT-174) - 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. AS2107 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: AS2107 details →

What was measured. From ITA host (Karsolink) we tested AS2107 (ARNES-NET - ARNES) using aa.arnes.si (2001:1470:8000::87). 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.0/30.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 18 responsive hop(s) and reached the target itself. The deepest hop that returned a Time-Exceeded was kanin.arnes.si [2001:1470:8000::87] in AS2107 (ARNES-NET). The path completed cleanly to the destination.

Other signals.

• Per-hop loss between 5% and 95% on hop 3 (60%, AS204471, KARSOLINK), hop 9 (60%, AS174, COGENT-174) - 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. AS2107 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: AS2107 details →

What was measured. From SLO host (6connect) we tested AS2107 (ARNES-NET - ARNES) using aa.arnes.si (2001:1470:8000::87). 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 1.4/3.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 8 responsive hop(s) and reached the target itself. The deepest hop that returned a Time-Exceeded was kanin.arnes.si [2001:1470:8000::87] in AS2107 (ARNES-NET). The path completed cleanly to the destination.

Other signals.

• Per-hop loss between 5% and 95% on hop 3 (60%, 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.

Likely problem: none. AS2107 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: AS2107 details →

What was measured. From NL host (go6lab) we tested AS3212 (TELEMACH - Telemach Slovenija d.o.o.) using ns1.telemach.net (2a00:13db:0:6::11). 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.1/26.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 11 responsive hop(s) and reached the target itself. The deepest hop that returned a Time-Exceeded was ns1.telemach.net [2a00:13db:0:6::11] in AS3212 (TELEMACH). The path completed cleanly to the destination.

Other signals.

• Per-hop loss between 5% and 95% on hop 10 (70%, AS3212, TELEMACH) - 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. AS3212 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: AS3212 details →

What was measured. From ITA host (Karsolink) we tested AS3212 (TELEMACH - Telemach Slovenija d.o.o.) using ns1.telemach.net (2a00:13db:0:6::11). 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 23.1/23.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 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 ns1.telemach.net [2a00:13db:0:6::11] in AS3212 (TELEMACH). The path completed cleanly to the destination.

Other signals.

• Per-hop loss between 5% and 95% on hop 3 (30%, AS204471, KARSOLINK), hop 7 (80%, AS3212, TELEMACH) - 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. AS3212 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: AS3212 details →

What was measured. From SLO host (6connect) we tested AS3212 (TELEMACH - Telemach Slovenija d.o.o.) using ns1.telemach.net (2a00:13db:0:6::11). 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 1.3/2.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): 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) and reached the target itself. The deepest hop that returned a Time-Exceeded was ns1.telemach.net [2a00:13db:0:6::11] in AS3212 (TELEMACH). The path completed cleanly to the destination.

Other signals.

• Per-hop loss between 5% and 95% on hop 3 (30%, 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.

Likely problem: none. AS3212 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: AS3212 details →

What was measured. From NL host (go6lab) we tested AS5435 (VELCOM-AS - Velcom d.o.o) using (external source) (2a02:23d0:0:1:0:1:1: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.9/27.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 15 responsive hop(s). The deepest hop that returned a Time-Exceeded was 2a02:d68:c:1002::2 in AS12778 (SGN). The path never entered the destination network (AS5435 VELCOM-AS). Responses kept coming through and including AS12778 SGN; 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 (AS12778 SGN), not at it - AS12778 did reply.

Other signals.

• Per-hop loss between 5% and 95% on hop 5 (80%, AS174, COGENT-174), hop 6 (70%, AS174, COGENT-174) - 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. AS5435 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: AS5435 details →

What was measured. From ITA host (Karsolink) we tested AS5435 (VELCOM-AS - Velcom d.o.o) using (external source) (2a02:23d0:0:1:0:1:1: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 29.1/29.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 16 responsive hop(s). The deepest hop that returned a Time-Exceeded was 2a02:d68:c:1002::2 in AS12778 (SGN). The path never entered the destination network (AS5435 VELCOM-AS). Responses kept coming through and including AS12778 SGN; 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 (AS12778 SGN), not at it - AS12778 did reply.

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. AS5435 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: AS5435 details →

What was measured. From SLO host (6connect) we tested AS5435 (VELCOM-AS - Velcom d.o.o) using (external source) (2a02:23d0:0:1:0:1:1: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 1.6/1.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): 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:d68:c:1002::2 in AS12778 (SGN). The path never entered the destination network (AS5435 VELCOM-AS). Responses kept coming through and including AS12778 SGN; 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 (AS12778 SGN), not at it - AS12778 did reply.

Other signals.

• Per-hop loss between 5% and 95% on hop 3 (30%, 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. AS5435 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: AS5435 details →

What was measured. From NL host (go6lab) we tested AS5603 (SIOL-NET - Telekom Slovenije, d.d.) using ns3.siol.net (2a00:ee0:d::13). 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.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 attempted but no Echo Reply after PTB (probe 1500B); cannot decide Type 2 acceptance from this run.

Path observations. Traceroute saw 11 responsive hop(s) and reached the target itself. The deepest hop that returned a Time-Exceeded was taurus-3.siol.net [2a00:ee0:d::13] in AS5603 (SIOL-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. AS5603 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: AS5603 details →

What was measured. From ITA host (Karsolink) we tested AS5603 (SIOL-NET - Telekom Slovenije, d.d.) using ns3.siol.net (2a00:ee0:d::13). 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 16.0/16.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 7 responsive hop(s) and reached the target itself. The deepest hop that returned a Time-Exceeded was taurus-3.siol.net [2a00:ee0:d::13] in AS5603 (SIOL-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. AS5603 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: AS5603 details →

What was measured. From SLO host (6connect) we tested AS5603 (SIOL-NET - Telekom Slovenije, d.d.) using ns3.siol.net (2a00:ee0:d::13). 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 1.4/1.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 after PTB (probe 1500B); cannot decide Type 2 acceptance from this run.

Path observations. Traceroute saw 4 responsive hop(s) and reached the target itself. The deepest hop that returned a Time-Exceeded was taurus-3.siol.net [2a00:ee0:d::13] in AS5603 (SIOL-NET). The path completed cleanly to the destination.

Other signals.

• Per-hop loss between 5% and 95% on hop 3 (70%, 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. AS5603 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: AS5603 details →

What was measured. From NL host (go6lab) we tested AS9119 (SOFTNET-AS - SOFTNET d.o.o.) using trixie.softnet.si (2a02:800:73:2::58). 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 24.8/25.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) and reached the target itself. The deepest hop that returned a Time-Exceeded was trixie.softnet.si [2a02:800:73:2::58] in AS9119 (SOFTNET-AS). The path completed cleanly to the destination.

Other signals.

• Per-hop loss between 5% and 95% on hop 4 (20%, ASNone, NA), hop 5 (20%, AS9119, SOFTNET-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. AS9119 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: AS9119 details →

What was measured. From ITA host (Karsolink) we tested AS9119 (SOFTNET-AS - SOFTNET d.o.o.) using trixie.softnet.si (2a02:800:73:2::58). 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 27.2/27.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 10 responsive hop(s) and reached the target itself. The deepest hop that returned a Time-Exceeded was trixie.softnet.si [2a02:800:73:2::58] in AS9119 (SOFTNET-AS). The path completed cleanly to the destination.

Other signals.

• Per-hop loss between 5% and 95% on hop 3 (80%, AS204471, KARSOLINK), hop 8 (70%, AS9119, SOFTNET-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. AS9119 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: AS9119 details →

What was measured. From SLO host (6connect) we tested AS9119 (SOFTNET-AS - SOFTNET d.o.o.) using trixie.softnet.si (2a02:800:73:2::58). 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 2.6/3.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 6 responsive hop(s) and reached the target itself. The deepest hop that returned a Time-Exceeded was trixie.softnet.si [2a02:800:73:2::58] in AS9119 (SOFTNET-AS). The path completed cleanly to the destination.

Other signals.

• Per-hop loss between 5% and 95% on hop 3 (80%, 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.

Likely problem: none. AS9119 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: AS9119 details →

What was measured. From NL host (go6lab) we tested AS12778 (SGN - MEGA M, d.o.o.) using (external source) (2a02:d68:2:10::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 27.1/29.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). The deepest hop that returned a Time-Exceeded was be9462.nr61.b021176-0.lju01.atlas.cogentco.com [2001:550:0:1000::9a19:11a5] in AS174 (COGENT-174). The path never entered the destination network (AS12778 SGN). Responses kept coming through and including AS174 COGENT-174; 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 (AS174 COGENT-174), not at it - AS174 did reply.

Other signals.

• Per-hop loss between 5% and 95% on hop 5 (20%, AS174, COGENT-174), hop 8 (80%, AS174, COGENT-174) - that router replies sometimes but not always, which is characteristic of ICMPv6 rate-limiting, not an outright filter.

Likely problem: none. AS12778 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: AS12778 details →

What was measured. From ITA host (Karsolink) we tested AS12778 (SGN - MEGA M, d.o.o.) using (external source) (2a02:d68:2:10::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.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 attempted but no Echo Reply to 1300-byte probe; cannot decide Type 2 acceptance from this run.

Path observations. Traceroute saw 13 responsive hop(s). The deepest hop that returned a Time-Exceeded was be9462.nr61.b021176-0.lju01.atlas.cogentco.com [2001:550:0:1000::9a19:11a5] in AS174 (COGENT-174). The path never entered the destination network (AS12778 SGN). Responses kept coming through and including AS174 COGENT-174; 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 (AS174 COGENT-174), not at it - AS174 did reply.

Likely problem: none. AS12778 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: AS12778 details →

What was measured. From SLO host (6connect) we tested AS12778 (SGN - MEGA M, d.o.o.) using (external source) (2a02:d68:2:10::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 14.1/3.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 3 responsive hop(s). The deepest hop that returned a Time-Exceeded was 2a03:a100:0:201:1::1 in AS56635 (XENYA). The path never entered the destination network (AS12778 SGN). Responses kept coming through and including AS56635 XENYA; 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 (AS56635 XENYA), not at it - AS56635 did reply.

Likely problem: none. AS12778 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: AS12778 details →

What was measured. From NL host (go6lab) we tested AS21283 (A1SI-AS - A1 Slovenija telekomunikacijske storitve,d.d.) using (external source) (2001:15c0:1000:1001::2). 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.3/26.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 9 responsive hop(s). The deepest hop that returned a Time-Exceeded was 2001:15c0:1000:1001::1 in AS21283 (A1SI-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 (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. AS21283 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: AS21283 details →

What was measured. From ITA host (Karsolink) we tested AS21283 (A1SI-AS - A1 Slovenija telekomunikacijske storitve,d.d.) using (external source) (2001:15c0:1000:1001::2). 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.8/29.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 attempted but no Echo Reply to 1300-byte probe; cannot decide Type 2 acceptance from this run.

Path observations. Traceroute saw 11 responsive hop(s). The deepest hop that returned a Time-Exceeded was 2001:15c0:1000:1001::1 in AS21283 (A1SI-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).

Likely problem: none. AS21283 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: AS21283 details →

What was measured. From SLO host (6connect) we tested AS21283 (A1SI-AS - A1 Slovenija telekomunikacijske storitve,d.d.) using (external source) (2001:15c0:1000:1001::2). 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 2.2/4.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 5 responsive hop(s). The deepest hop that returned a Time-Exceeded was 2001:15c0:1000:1001::1 in AS21283 (A1SI-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 (30%, AS56635, XENYA) - that router replies sometimes but not always, which is characteristic of ICMPv6 rate-limiting, not an outright filter.

Likely problem: none. AS21283 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: AS21283 details →

What was measured. From NL host (go6lab) we tested AS24629 (NIL-AS - NIL Data Communications Ltd.) using www.nil.si (2001:67c:58:d04::13). 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. No Echo Reply was received for either size (small 0/4, 1500 B 0/4). ICMPv6 Echo to this address is fully suppressed.

ICMPv6 Type 2 (Packet Too Big) / PMTUD. We have no Echo Reply for either size and tracepath never observed a Path-MTU drop, so this run cannot say anything definitive about ICMPv6 Type 2 / PMTUD handling toward this destination. Echo being blocked does not by itself mean PMTUD is broken - RFC 4890 recommends operators drop Echo Request inbound (or rate-limit it) while keeping Type 2 permitted, and a network that did exactly that would look identical from this kind of probe. To know for certain we would need an active TCP flow into the destination plus a forged-PTB injection test, which is outside the current measurement battery. Active test attempted but no Echo Reply to 1300-byte probe; cannot decide Type 2 acceptance from this run.

Path observations. Traceroute saw 12 responsive hop(s). The deepest hop that returned a Time-Exceeded was 2a11:4142:2002::1 in AS5405 (INTERDOTLINK). The path never entered the destination network (AS24629 NIL-AS). Responses kept coming through and including AS5405 INTERDOTLINK; 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 (AS5405 INTERDOTLINK), not at it - AS5405 did reply.

Likely problem: the probed address is silent on every protocol - this could be a cold address (no service) or a network that drops everything inbound. Whether ICMPv6 specifically is blocked cannot be isolated from this host alone. Filter is most likely at past AS5405 (INTERDOTLINK).

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

What was measured. From ITA host (Karsolink) we tested AS24629 (NIL-AS - NIL Data Communications Ltd.) using www.nil.si (2001:67c:58:d04::13). 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. No Echo Reply was received for either size (small 0/4, 1500 B 0/4). ICMPv6 Echo to this address is fully suppressed.

ICMPv6 Type 2 (Packet Too Big) / PMTUD. We have no Echo Reply for either size and tracepath never observed a Path-MTU drop, so this run cannot say anything definitive about ICMPv6 Type 2 / PMTUD handling toward this destination. Echo being blocked does not by itself mean PMTUD is broken - RFC 4890 recommends operators drop Echo Request inbound (or rate-limit it) while keeping Type 2 permitted, and a network that did exactly that would look identical from this kind of probe. To know for certain we would need an active TCP flow into the destination plus a forged-PTB injection test, which is outside the current measurement battery. 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). The deepest hop that returned a Time-Exceeded was 2a11:4142:2002::1 in AS5405 (INTERDOTLINK). The path never entered the destination network (AS24629 NIL-AS). Responses kept coming through and including AS5405 INTERDOTLINK; 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 (AS5405 INTERDOTLINK), not at it - AS5405 did reply.

Likely problem: the probed address is silent on every protocol - this could be a cold address (no service) or a network that drops everything inbound. Whether ICMPv6 specifically is blocked cannot be isolated from this host alone. Filter is most likely at past AS5405 (INTERDOTLINK).

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

What was measured. From SLO host (6connect) we tested AS24629 (NIL-AS - NIL Data Communications Ltd.) using www.nil.si (2001:67c:58:d04::13). 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 4.1/4.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): 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). The deepest hop that returned a Time-Exceeded was 2a00:ee1:c00::2 in AS5603 (SIOL-NET). The path never entered the destination network (AS24629 NIL-AS). Responses kept coming through and including AS5603 SIOL-NET; 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 (AS5603 SIOL-NET), not at it - AS5603 did reply.

Other signals.

• Per-hop loss between 5% and 95% on hop 3 (90%, AS5603, SIOL-NET) - that router replies sometimes but not always, which is characteristic of ICMPv6 rate-limiting, not an outright filter.
• 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. AS24629 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: AS24629 details →

What was measured. From NL host (go6lab) we tested AS25173 (ISKRATR-AS - ISKRA, d.o.o.) using (external source) (2001:67c:2004:1::2). 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.5/27.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). The deepest hop that returned a Time-Exceeded was 2a00:ee0:5:7::2 in AS5603 (SIOL-NET). The path never entered the destination network (AS25173 ISKRATR-AS). Responses kept coming through and including AS5603 SIOL-NET; 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 (AS5603 SIOL-NET), not at it - AS5603 did reply.

Likely problem: none. AS25173 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: AS25173 details →

What was measured. From ITA host (Karsolink) we tested AS25173 (ISKRATR-AS - ISKRA, d.o.o.) using (external source) (2001:67c:2004:1::2). 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 16.0/16.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 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 2a00:ee0:5:7::2 in AS5603 (SIOL-NET). The path never entered the destination network (AS25173 ISKRATR-AS). Responses kept coming through and including AS5603 SIOL-NET; 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 (AS5603 SIOL-NET), not at it - AS5603 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.

Likely problem: none. AS25173 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: AS25173 details →

What was measured. From SLO host (6connect) we tested AS25173 (ISKRATR-AS - ISKRA, d.o.o.) using (external source) (2001:67c:2004:1::2). 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 1.5/3.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 5 responsive hop(s). The deepest hop that returned a Time-Exceeded was 2a01-260-4117--1e.link6.t-2.net [2a01:260:4117::1e] in AS34779 (T-2-AS). The path never entered the destination network (AS25173 ISKRATR-AS). Responses kept coming through and including AS34779 T-2-AS; 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 (AS34779 T-2-AS), not at it - AS34779 did reply.

Other signals.

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

Likely problem: none. AS25173 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: AS25173 details →

What was measured. From NL host (go6lab) we tested AS25303 (KDD - KDD d.d.) using (external source) (2001:67c:20b8:1::10). 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.1/43.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): 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 7 responsive hop(s). The deepest hop that returned a Time-Exceeded was 2a01-260-4107--2.link6.t-2.net [2a01:260:4107::2] in AS34779 (T-2-AS). The path never entered the destination network (AS25303 KDD). Responses kept coming through and including AS34779 T-2-AS; 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 (AS34779 T-2-AS), not at it - AS34779 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. AS25303 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: AS25303 details →

What was measured. From ITA host (Karsolink) we tested AS25303 (KDD - KDD d.d.) using (external source) (2001:67c:20b8:1::10). 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.2/46.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). The deepest hop that returned a Time-Exceeded was 2a01-260-4107--2.link6.t-2.net [2a01:260:4107::2] in AS34779 (T-2-AS). The path never entered the destination network (AS25303 KDD). Responses kept coming through and including AS34779 T-2-AS; 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 (AS34779 T-2-AS), not at it - AS34779 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.

Likely problem: none. AS25303 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: AS25303 details →

What was measured. From SLO host (6connect) we tested AS25303 (KDD - KDD d.d.) using (external source) (2001:67c:20b8:1::10). 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 3.5/4.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): 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 6 responsive hop(s). The deepest hop that returned a Time-Exceeded was 2a01-260-4107--2.link6.t-2.net [2a01:260:4107::2] in AS34779 (T-2-AS). The path never entered the destination network (AS25303 KDD). Responses kept coming through and including AS34779 T-2-AS; 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 (AS34779 T-2-AS), not at it - AS34779 did reply.

Likely problem: none. AS25303 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: AS25303 details →

What was measured. From NL host (go6lab) we tested AS25467 (AKTON-AS - Akton d.o.o.) using www.akton.si (2a02:2230:101::53). 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 27.0/27.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). The deepest hop that returned a Time-Exceeded was 2001:7f8:30:0:2:1:2:5467. The path never entered the destination network (AS25467 AKTON-AS). Responses kept coming through and including AS?; 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, not at it - ASNone did reply.

Other signals.

• Per-hop loss between 5% and 95% on hop 3 (10%, AS50673, Serverius-as), hop 6 (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. AS25467 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: AS25467 details →

What was measured. From ITA host (Karsolink) we tested AS25467 (AKTON-AS - Akton d.o.o.) using www.akton.si (2a02:2230:101::53). 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 22.6/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 (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). The deepest hop that returned a Time-Exceeded was 2001:7f8:30:0:2:1:2:5467. The path never entered the destination network (AS25467 AKTON-AS). Responses kept coming through and including AS?; 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, not at it - ASNone did reply.

Likely problem: none. AS25467 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: AS25467 details →

What was measured. From SLO host (6connect) we tested AS25467 (AKTON-AS - Akton d.o.o.) using www.akton.si (2a02:2230:101::53). 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.5/15.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 2001:7f8:30:0:2:1:2:5467. The path never entered the destination network (AS25467 AKTON-AS). Responses kept coming through and including AS?; 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, not at it - ASNone did reply.

Other signals.

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