Ephemeral addressing [was Re: 64share v2]

[[e-mail]]

Philip,

Let me rename this thread as this opens a much larger issue.
While being able to rapidly reconfigure an end-user network using the layer3 primitives in 6man, I don't think it's worth solving unless also the upper layer problems are solved.
- How do TCP connections survive a renumbering event?
- How do applications get notified to reconnect?
- Do all applications have to change as a result? Or use a different transport layer?
- What happens with DNS configuration? Are you assuming everyone has DNS-SD deployed and working?
- What about other configuration? Static addresses for example?

Good luck I say...
Until then I suggest that we continue (to pretend) that addresses must be long-lived.

Cheers,
Ole

> On 11 Nov 2020, at 12:43, Philip Homburg <[e-mail]> wrote:
> 
>> 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.