findings: v6.broken claimed a cause it had no evidence for
A phone reported "IPv6 is configured but not working" while loading an IPv6-only site over TCP perfectly well. The finding fired on one signal - ICMPv6 echo getting no reply - at HIGH confidence. ICMPv6 echo is widely filtered on networks where IPv6 works, so the two cases are indistinguishable from where the app stands, and it was picking one. Same class of error as the multi-homed downstream-loss bug: a confident measurement of something that was not happening. Now v6.no_icmp_reply, low severity, medium confidence, naming both explanations. Still reported, because filtered ICMPv6 breaks Path MTU Discovery - large packets vanish instead of being reported as too big - which is a fault in its own right. Corroborating with a real IPv6 connection would separate the two properly, but needs a target, which runs into the hardcoded-deployment issue already open. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This commit is contained in:
co-authored by
Claude Fable 5
parent
b5c8dda9a2
commit
fec374abf5
@@ -479,11 +479,11 @@ class RunViewModel(app: Application) : AndroidViewModel(app) {
|
||||
if (ipv6Provisioned(networks)) {
|
||||
out.add(
|
||||
Finding(
|
||||
id = ids.uuid(), code = FindingRegistry.V6_BROKEN.code,
|
||||
category = FindingRegistry.V6_BROKEN.category,
|
||||
severity = FindingRegistry.V6_BROKEN.severity, confidence = Confidence.HIGH,
|
||||
title = "IPv6 is configured but not working",
|
||||
description = "This network advertises IPv6 (a global address and/or a default route), but ICMPv6 got no reply on any network. Half-configured IPv6 is worse than none: connections try IPv6 first and stall before falling back.",
|
||||
id = ids.uuid(), code = FindingRegistry.V6_NO_ICMP_REPLY.code,
|
||||
category = FindingRegistry.V6_NO_ICMP_REPLY.category,
|
||||
severity = FindingRegistry.V6_NO_ICMP_REPLY.severity, confidence = Confidence.MEDIUM,
|
||||
title = "IPv6 is configured, but ICMPv6 gets no reply",
|
||||
description = "This network advertises IPv6 (a global address and/or a default route), but ICMPv6 echo got no reply on any network. That has two explanations which look identical from here: IPv6 is broken, or ICMPv6 is filtered while IPv6 itself works. Filtering is common and is a fault in its own right — it breaks Path MTU Discovery, so large packets vanish rather than being reported as too big.",
|
||||
evidenceRefs = listOf(EvidenceRef(t.id)),
|
||||
)
|
||||
)
|
||||
|
||||
+17
-5
@@ -169,10 +169,22 @@ object FindingRegistry {
|
||||
// they silently rolled up under connectivity: the third instance of a prefix disagreeing with
|
||||
// its category and quietly moving a fault to a different verdict light.
|
||||
|
||||
val V6_BROKEN = FindingSpec(
|
||||
"v6.broken", Category.IPV6, Severity.MEDIUM,
|
||||
"IPv6 is configured on this network but does not work.",
|
||||
rulesOut = "Absence of IPv6: it is provisioned, it simply fails.",
|
||||
/**
|
||||
* Renamed from `v6.broken`, which claimed more than the evidence supports.
|
||||
*
|
||||
* The only signal behind it is ICMPv6 echo getting no reply — and ICMPv6 echo is widely
|
||||
* filtered on networks where IPv6 otherwise works perfectly. A phone that reported this while
|
||||
* happily loading an IPv6-only site over TCP is what caught it. From here the two cases look
|
||||
* identical, so the finding now says what was observed and names both explanations rather than
|
||||
* picking one.
|
||||
*
|
||||
* It is worth reporting either way: filtered ICMPv6 breaks Path MTU Discovery, which is its
|
||||
* own fault even when IPv6 works.
|
||||
*/
|
||||
val V6_NO_ICMP_REPLY = FindingSpec(
|
||||
"v6.no_icmp_reply", Category.IPV6, Severity.LOW,
|
||||
"IPv6 is configured but ICMPv6 echo gets no reply.",
|
||||
rulesOut = "Nothing on its own: IPv6 may work fine with ICMP filtered.",
|
||||
)
|
||||
|
||||
/**
|
||||
@@ -196,7 +208,7 @@ object FindingRegistry {
|
||||
NAT_UDP_REBINDING, NAT_SYMMETRIC,
|
||||
THROUGHPUT_NO_DELIVERY, THROUGHPUT_BELOW_OFFERED,
|
||||
DNS_ANSWER_REWRITTEN, DNS_AUTHORITATIVE_UNREACHABLE,
|
||||
V6_BROKEN, V6_NOT_OFFERED,
|
||||
V6_NO_ICMP_REPLY, V6_NOT_OFFERED,
|
||||
)
|
||||
|
||||
private val byCode: Map<String, FindingSpec> = all.associateBy { it.code }
|
||||
|
||||
Reference in New Issue
Block a user