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

Ted Lemon <> Tue, 21 November 2023 15:16 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 51F7CC15154D for <>; Tue, 21 Nov 2023 07:16:24 -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 U87U8fcbYQhd for <>; Tue, 21 Nov 2023 07:16:23 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::112c]) (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 80A17C14E515 for <>; Tue, 21 Nov 2023 07:16:23 -0800 (PST)
Received: by with SMTP id 00721157ae682-5cb4ee00da1so10314187b3.0 for <>; Tue, 21 Nov 2023 07:16:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20230601; t=1700579782; x=1701184582;; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=Fboum3qy3i3npaD4GzuB2Mcwfe9aW026au2dwC97EJQ=; b=js5T/NMFO1pvlZnAe34zj7mDM1WQ7erTPXX+gZ4X7CkJEehIwvlFW5XhVVBFR8zJcy DUyD5AQEJ+rbOAvM60KSBr+v9/8jgpr+S0Po5MFs/FGKeJruzpcskNwrp04Thw9nAehq BfJA4imXVoY/UmZQHztnrsp8NWu9ResMeEqPttHsFlznn6u/9r3dh4RQeibyLEdpDuEH /dec9h8CXtLv7EglN7BxNOqYEX2P22NznDl6LiaNVqCJDHmX2rfC/foIzRGXcnQ56h03 cUL5p5JXjHU3vA4khISor7WC+H77xNMycdvFePRo1C66UTgxSYvl39CBK4V0+042hn2p uXoQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20230601; t=1700579782; x=1701184582; 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=Fboum3qy3i3npaD4GzuB2Mcwfe9aW026au2dwC97EJQ=; b=MZcI10Tnl7PWTQiPB5lSbeuSMdMgoGVf1kFVFjUhT36f69MeZPVSKibzVn1SToupcf 3LgQUU0Ie1W9aZC4s8BSMhJABtZpTwJdBYOQKLDmlq6XAYbxtYHOtRMTKKOWoYctO/gb cnzTkuW+IxjabHHBWWfqiG9iLdLmDZpZYnUFF/paSfGEKP/+u1ytxh54UALmL+aWaUct P9j/sI++EhQiS34zxPfhZRXBDMrj4tZAFiMjMPbHuCUDptpJUCzpdGGrxfsFfgr3bUHa WxirjUL02RsTMP+nrU9JOUTyHZIcJsBoSjwRsKh9B7Pph9SguWtY4dfO5qO/4i0ck5bT PWhA==
X-Gm-Message-State: AOJu0Yxc/4A7eD6jDmzsPZB0pFfnAVi14Y8LhzJrd/2QtSg2hftqLL91 poNqaQa8eIuTmBBaM3U/qflAu5xVeD+M2GTWDG91fw==
X-Google-Smtp-Source: AGHT+IFxo7Wg9F2YaOiuYHRjcy1YCgn2z6W8TYrWsPYlmMN8G+G4Ui1nJHPoFjRxKvJXzPDSHGzweR2/E2mvTh3Miec=
X-Received: by 2002:a0d:e613:0:b0:5a7:fcaf:c1c0 with SMTP id p19-20020a0de613000000b005a7fcafc1c0mr2341265ywe.8.1700579782528; Tue, 21 Nov 2023 07:16:22 -0800 (PST)
MIME-Version: 1.0
References: <> <> <> <> <> <>
In-Reply-To: <>
From: Ted Lemon <>
Date: Tue, 21 Nov 2023 10:16:11 -0500
Message-ID: <>
To: Ole Troan <>
Cc: 6man WG <>, Lorenzo Colitti <>, Michael Richardson <>, Nick Buraglio <>
Content-Type: multipart/alternative; boundary="000000000000d9a5b8060aab1572"
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 15:16:24 -0000

Honestly, it feels to me like we are converging on something that works,
and you are tired of it and are therefore proposing to snatch defeat from
the jaws of victory.

It’s taken a long time to do this because the market pressure isn’t there,
not because it’s impossible to do.

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

> Ted,
> > 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.
> The problem here is that for this to work you need to make it work for
> _all_ hosts in the network.
> I don’t doubt that you can make it work for a single host stack.
> I do doubt that you will make it work well even for that host (well being
> defined by the multihoming requirements RFC), since most applications do
> not deal with failing over to different SA,DA pairs well.
> You are basically putting a burden on every host and application
> implementation for the relatively small return of sub-par multihoming.
> Compare that to something as simple to deploy as NPTv6. Or PI
> multi-homing. Or provider assisted multi-homing…
> The best approach I can think of is to deploy MHMP as a completely
> separate network for each provider. Separate SSID and separate
> interfaces/VLANs. That leaves you with an equally awkward interface as
> mobile phones typically have, where you manually switch between the
> providers. Can’t quite see how we can get my light switch to deal with that.
> We have tried this for a couple of decades. Time to admit failure.
> O.