Re: 64share v2

Lorenzo Colitti <> Wed, 11 November 2020 13:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5A1673A0D58 for <>; Wed, 11 Nov 2020 05:37:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -17.599
X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] 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 fcK4wKXa8qFQ for <>; Wed, 11 Nov 2020 05:37:37 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::d29]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D3AD83A0D4D for <>; Wed, 11 Nov 2020 05:37:37 -0800 (PST)
Received: by with SMTP id r9so2280555ioo.7 for <>; Wed, 11 Nov 2020 05:37:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=RqRx11QZX/hlYyzGUHoe9IxvDKntEcT/9gX16+quQqs=; b=sVR6Fe3qE7LjrvwWqwmdzbmmmzCmzELoaTIr1xjvv3LhtGnPzcnZllN33WgEAXmS23 SRxCUQarcoOE+BfHQylqLalpfDHwMYjJcFlywlhZM1clgmxUPc1QigxL7KQCFFl6+aYc BubsWcwmAwPLnVFQ9GvJta6xkG5z5bsgixJXFuMZFSPyLuVxoNQef9gtRUREX+mzktb8 ezhi8qGPr+6BXrxeekQUmgJz6ccZC8/w5oicyothUGzR+oVkM1MvW15CrS47W3upEAwV AVVkOd2ujsp40+e8iYKYUVx4ir3MweTlXPFGEicSN2IhY+C95/cGVq7Gidosp1xjV7oE EzHQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=RqRx11QZX/hlYyzGUHoe9IxvDKntEcT/9gX16+quQqs=; b=d8ltrCPnbSAeb1xTnf/Hxl9RsDcK5tmxQFX2+HrlugdxXvxKZD3bE0gFrNGmOzF19I x6SuSF4AWmaaNTxhYlyIORVy4/NbLG6xMBN3m7/5vOSU+ED7roEEsZWFtYkFt/AgTDpH nbAGQACG1AYAcd8XcuXAzO3h2+sRXkrAj6uWaiAw7WS+uBp1IdZ771dyhqnFRU6i2Z0S aG+d/Iqmn9MPp/VyBOQYqKaSrcKv6GOylb3+viqpb3ttOrAdSEZWPn9BNe/gstEdpY8E 1kr+QRXuxzl+qk99i4DPurMCw4JhiAKyhBb/lkv8U2mylTqwUEMjYcoXwHC1sVWwRsjb It5Q==
X-Gm-Message-State: AOAM5316uboh1bohLaBO6Ty65ekgX339Nf4Veb/OG2I59hvRnbKwRsi2 HHe2kRq2HpEOa2wnhGPdt6Fl/CLI58i/L2utu1N49hnDl/l3Tcp+
X-Google-Smtp-Source: ABdhPJwA2u4yCNToKyRn/twOu/oYBRTI0Odv+st2zF9GUcLaee/YTBp29jQBvJd3baIV2FCfW0LbGYHDa7uNNF6vCmY=
X-Received: by 2002:a5e:8f4c:: with SMTP id x12mr18928249iop.140.1605101856813; Wed, 11 Nov 2020 05:37:36 -0800 (PST)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Lorenzo Colitti <>
Date: Wed, 11 Nov 2020 22:37:25 +0900
Message-ID: <>
Subject: Re: 64share v2
To: Philip Homburg <>
Cc: IETF IPv6 Mailing List <>
Content-Type: multipart/alternative; boundary="000000000000016df305b3d4e6c5"
Archived-At: <>
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 11 Nov 2020 13:37:39 -0000

On Wed, Nov 11, 2020 at 10:19 PM Philip Homburg <> wrote:

> >Do we really need to solve this problem in order to solve the problem of
> >how to distribute the information? Or rather - do we need to solve the
> >problems together, in the same draft?
> We have a problem with DHCPv6 PD relays and soft state getting
> lost. We have quite a few drafts related to RAs and renumbering.

I don't think that can really happen here because the option we're defining
is explicitly for a point-to-point link. It's very unlikely that
point-to-point links won't have some sort of liveness detection already.
You know if your point-to-point link is up, right?

> Maybe we should first figure out how it should work, before we specify
> bits on the wire.

If you're talking about what should happen *downstream* of the device that
receives the option ("recipient"), then it seems to me that that problem is
almost completely independent of how the recipient gets the prefix, and is
basically entirely between the recipient and its downstream devices. I mean
- sure, we can decide that the option should or should not contain a timer,
and per the above, I think we can assume that there is a link-layer signal
that the recipient can use to determine that the option is no longer valid.
But... once we've done that, I think the recipient has all the information
we can possibly convey to it. The recipient will definitely know if its
prefix is no longer valid if the link goes down.

Obviously, we still have the problem that downstream devices don't know
what happened. But I don't see how we can fix that as part of defining the
option. The only things we can do when defining the option are a) add more
information to the option (but I don't see what we could add to make this
better), or b) to say that the devices implementing the option should
behave in some way. I don't think it's reasonable to mandate that behaviour
on the sender of the option, because the recipient already has all the
information it needs. So yes, in theory we could say that the recipient of
the option must have some way to notify its downstream devices when the
option is no longer valid. But I don't think that mechanism should be
specified in this draft.