Re: 64share v2

otroan@employees.org Wed, 11 November 2020 13:43 UTC

Return-Path: <otroan@employees.org>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F35C53A121A for <ipv6@ietfa.amsl.com>; Wed, 11 Nov 2020 05:43:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZXk_HeiOfNFC for <ipv6@ietfa.amsl.com>; Wed, 11 Nov 2020 05:43:30 -0800 (PST)
Received: from clarinet.employees.org (clarinet.employees.org [IPv6:2607:7c80:54:3::74]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 543AD3A1134 for <ipv6@ietf.org>; Wed, 11 Nov 2020 05:43:30 -0800 (PST)
Received: from astfgl.hanazo.no (201.51-175-101.customer.lyse.net [51.175.101.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by clarinet.employees.org (Postfix) with ESMTPSA id DCF494E11B49; Wed, 11 Nov 2020 13:43:29 +0000 (UTC)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by astfgl.hanazo.no (Postfix) with ESMTP id DF23043CD527; Wed, 11 Nov 2020 14:43:27 +0100 (CET)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\))
Subject: Re: 64share v2
From: otroan@employees.org
In-Reply-To: <CAKD1Yr0CYODYCuC=GaFJ1wtCYjoKCKGGskWXD1s7HOjWuu+4EQ@mail.gmail.com>
Date: Wed, 11 Nov 2020 14:43:27 +0100
Cc: Philip Homburg <pch-ipv6-ietf-6@u-1.phicoh.com>, 6man WG <ipv6@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <935B887D-D512-4833-B41C-1573689F3DD3@employees.org>
References: <CAD6AjGR-NE_sJ_jp7nAT6OvNkcdE9qoWuGEiiVW7r9YtsQvbbw@mail.gmail.com> <80ed3a3b-6e2c-188f-4c1e-c2ededfbbe0d@joelhalpern.com> <0188AC41-60B0-4BC6-810D-DC59CF9E4FB3@employees.org> <1931a638-64ed-f40e-07a3-67cf1eafb941@joelhalpern.com> <376D6BB0-87E2-42E5-9BC4-F3A2F04FA005@employees.org> <CAD6AjGSr-TPcGo7f9EGgoAahYLQTL68CUSq58LGMgD0=6GmRRg@mail.gmail.com> <8DC674FB-9F90-4C41-A323-62BD62934A12@employees.org> <CAD6AjGTYBs8YbHgCJJG84vgwXK4ZSCm65z6KXvZP9F+LdT_atg@mail.gmail.com> <CAD6AjGTQVtJBJ3=aZBsF1WcdSK2k9b1hzeZXM6008w_2vpo6_w@mail.gmail.com> <948ACA2B-E45C-4289-A837-9F2536F20F8F@employees.org> <CAKD1Yr0tDTSH2F4=ZsdMJREy1k6equ9mZV0Au1bJPmKuzxeYVA@mail.gmail.com> <43C449AD-D116-4452-A4F2-79AE5A76539F@employees.org> <m1kcoXQ-0000G1C@stereo.hq.phicoh.net> <alpine.DEB.2.20.2011111248460.15604@uplift.swm.pp.se> <C979855B-894F-4BB8-8CE9-FDDD4C51AB68@employees.org> <alpine.DEB.2.20.2011111337570.15604@uplift.swm.pp.se> <CAKD1Yr1JJkCN=EJrYbffHQCBazT2Sky2wgWHsiKnztKWMKgJJg@mail.gmail.com> <m1kcq2A-0000FxC@stereo.hq.phicoh.net> <CAKD1Yr0CYODYCuC=GaFJ1wtCYjoKCKGGskWXD1s7HOjWuu+4EQ@mail.gmail.com>
To: Lorenzo Colitti <lorenzo=40google.com@dmarc.ietf.org>
X-Mailer: Apple Mail (2.3608.120.23.2.4)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/8WELHiHsVjIsZPu5GWhrTHD5hTg>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Nov 2020 13:43:35 -0000

> 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?

On the PE you need a route in the FIB for the user's prefix pointing at the interface towards the user.
The prefix has to be configured on the PE as part of provisioning that user. Will there not be any deployment of this option where configuring the interface is separate from delegating the prefix?

Ole