Re: 64share v2

Philip Homburg <> Wed, 11 November 2020 11:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7DA8C3A10AD for <>; Wed, 11 Nov 2020 03:43:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.622
X-Spam-Status: No, score=-1.622 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.276, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id c4x3Ft7dDIX5 for <>; Wed, 11 Nov 2020 03:43:54 -0800 (PST)
Received: from ( [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6DFF23A0317 for <>; Wed, 11 Nov 2020 03:43:52 -0800 (PST)
Received: from (localhost [::ffff:]) by with esmtp (TLS version=TLSv1.2 cipher=ECDHE-RSA-CHACHA20-POLY1305) (Smail #157) id m1kcoXQ-0000G1C; Wed, 11 Nov 2020 12:43:44 +0100
Message-Id: <>
Subject: Re: 64share v2
From: Philip Homburg <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <038A830C-E024-42C6-917E-E6FF57829A1C@employees.or g> <> <> <> <>
In-reply-to: Your message of "Wed, 11 Nov 2020 09:53:11 +0100 ." <>
Date: Wed, 11 Nov 2020 12:43:43 +0100
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 11:43:57 -0000

> Right, you do get a very clear L2 event on mobile networks.  If we
> want to make this general it might be needed in other networks.
> I thought it might be something to consider, given how many problems
> we've seen in broadband deployments, where the PE does DHCPv6 PD
> snooping as a relay, and seems to forget state. And unless the CE
> actively probes there's no way to recover.

It seems to me that we need to rethink how we distribute prefixes and other
address information. At the moment the primary mechanism to control the
lifetime of a prefix or an address is a timer. But we know that doesn't
really work.

If my laptop connects to a wifi, gets a SLAAC prefix and configures an
address and then later connects to a different wifi, then the valid time
of the SLAAC prefix is irrelevant, the laptop needs to stop using the
prefix. At the same time the router can invalidate the prefix at any moment.

So the lifetime is nice for garbage collection, but doesn't have much real
world value.

In many DHCPv6 PD installations we have the issue that the lifetime of the
prefix is completely detached from the forwarding state.

If we define a new option to do prefix delegation using RA, then maybe we
can try to get rid of lifetimes are the primary mechnism and switch to 
something more explicit.

For example, a downstream device receives a prefix using RA. At some point
the downstream device either sees an RA from a new router or see an RA from
the same router without the prefix. That should trigger a link attachment
procedure where the downstream device verifies that it still connected to
the same link and that the upstream router still offers the same prefix.

If verification fails then the device removes derived prefixes from any
downstream interfaces and tries to inform downstream devices.

Ideally we can set all prefix lifetimes to infinity and they will still
get cleaned up in time through other mechanisms.

I'm not in favor of duplicating DHCP features in RA. However, in the case
of prefix delegating, we may be able to fix the semantic gap between what
DHCP PD offers and what we really need.