Re: [IPv6] RFC 6724 shouldn't prefer partial reachability over reachability

Ted Lemon <> Tue, 21 November 2023 14:39 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8A6EAC15154F for <>; Tue, 21 Nov 2023 06:39:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.908
X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id i830etZuwnmW for <>; Tue, 21 Nov 2023 06:39:34 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::f2f]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by (Postfix) with ESMTPS id 75E7BC151097 for <>; Tue, 21 Nov 2023 06:39:03 -0800 (PST)
Received: by with SMTP id 6a1803df08f44-679e7d2d7c4so7082926d6.0 for <>; Tue, 21 Nov 2023 06:39:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20230601; t=1700577542; x=1701182342;; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=hcdtTLQ+OhOyH6HjiQrrnulJg1N0TtbEMVVOTh4yUzE=; b=BRYCuNdh0XabLHxX+wZ1d455y18yI4OY86feIDPMtA0UBH8i091FXSOV0mMqOLcTHf F8C+bbORGEzB37SZuHbyFirF+HMJSg55iReZcOHCuqcEt3vovZQb1QFFYrNwbmXXnSLV 26dc6WMIo1YPPtMPerlaZ9k/dxCYI0c4gI+9qr6CDLallAokzR2+/oIrhngugR3Y3Yig Jp5F3FytnVltFeb9lrtqSlG27B97EVDXXxVzYvVwNKg6rzCNBdNJqPPtRy64cGGr3MN0 KKxwAzlzUZcLSnkcHAm55KcOE0qyEcRR9a+cqq42nKkoiJ6iRLA7ZMVr13BfMqucfkDB vMPw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20230601; t=1700577542; x=1701182342; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=hcdtTLQ+OhOyH6HjiQrrnulJg1N0TtbEMVVOTh4yUzE=; b=uzWOfhnMBD90kMQ4xpDKEviJmOEPxC+jPdYFUeWP3rfSE6fnJY2RyPR0ugpNLsynk4 Y4go5mGjyq1JxtFzR58R2emlLUsxYQ/wuZ1zY1kKmmMc5jRvk4pgSiLDrvsiOhnNichu 95NsyR7P6ZbROeT3Jkwh1Yl0QVR03prv3ivfdkHMtNYD0fGUXVOO/x12RyeNgpsTyd9Y 76PrD1NQtEW1UTiODySa2VtQHlQFhE/DQeeLJ00UhPWhzWaQyxKWxyWDYjJoY/tsdPjc eFtEzQ6MITFkFaAkE5SqbR77WkqR7wCAXymIhTHJRl7w3oLUvwnUeDaZlFeE4AZIf/4t i7Uw==
X-Gm-Message-State: AOJu0YzXGnqLvKyscCz13b7WAei74+/MQZ2+nOKhteuRvogkddSyCveD 0KrNnTyo96VM2OLfX2PXRRu0LHd1XHSG2jsB2mweynYcxZsx9LsHTxY=
X-Google-Smtp-Source: AGHT+IEbrDzmBf2OZyN8G1Ns3G7lpnSQ+KhgGnZvDlW56VLs6psStbQkHBth3/UY86gmBKjSMEQ1vLQzrsCq2+PSQoI=
X-Received: by 2002:a05:6214:1c8e:b0:66d:59a3:f9e with SMTP id ib14-20020a0562141c8e00b0066d59a30f9emr11904015qvb.63.1700577542127; Tue, 21 Nov 2023 06:39:02 -0800 (PST)
MIME-Version: 1.0
References: <> <> <> <>
In-Reply-To: <>
From: Ted Lemon <>
Date: Tue, 21 Nov 2023 09:38:50 -0500
Message-ID: <>
To: Ole Troan <>
Cc: 6man WG <>, Lorenzo Colitti <>, Michael Richardson <>, Nick Buraglio <>
Content-Type: multipart/alternative; boundary="0000000000004fdadd060aaa90e8"
Archived-At: <>
Subject: Re: [IPv6] RFC 6724 shouldn't prefer partial reachability over reachability
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 21 Nov 2023 14:39:36 -0000

Well, e.g. in a stub network with DHCPv6 PD, if the customer site is
multi-homed for resiliency, it would be nice if that worked. This would
require the device on the stub network to try both source prefixes, so it
probably doesn’t work at the moment, but we are talking about what remains
to do to make it work.
It’s not clear to me that this is the killer app, or even the right
approach, but I don’t see the problem that you do with exploring this: my
motivation certainly isn’t to avoid paying for enterprise-grade routers
other than in the sense that clearly they wouldn’t make economic sense in
this application.

I do realize that if we made this work in the home, it would have
implications for the enterprise market in the long run, but that’s a path
we’ve all trod many times before, and I don’t think we should factor that
concern into our evaluation of what the right approach to the problem is.

Op di 21 nov 2023 om 09:23 schreef Ole Troan <>

> > Remember that my target market is end users, not enterprise. What sort
> of routers can an end user buy that will automatically do what you suggest?
> What sort of host and applications can an end user buy that supports MPMH?
> O.