Re: Ephemeral addressing [was Re: 64share v2]

On 12-Nov-20 01:03, otroan@employees.org wrote:
> Philip,
> 
> Let me rename this thread as this opens a much larger issue.

Not exactly a new issue. (Veteran of 6renum here.)

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

Why we did SHIM6. The arguments haven't changed.

> - How do applications get notified to reconnect?

Not needed in the SHIM6 model, but in the real world, a TCP disconnect or a missing UDP response is what they get. And then they need to repeat whatever discovery or rendez-vous mechanism they use, e.g. DNS lookup.

> - Do all applications have to change as a result? Or use a different transport layer?

No. There's nothing new here. Well written apps have always done this. Badly written apps just fail. (I have no idea whether QUIC will change this. SCTP hasn't really made it into the mainstream.)

> - What happens with DNS configuration? Are you assuming everyone has DNS-SD deployed and working?

You can't safely assume that. But see above: "whatever discovery or rendez-vous mechanism they use".

> - What about other configuration? Static addresses for example?

Yeah, well, anything that uses static config has been broken for 25 years.

> Good luck I say...

Yes. There's nothing new about ephemeral addresses.

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

Which is why ULAs should be used whenever possible. Like RFC1918 addresses, they have a better chance of being long-lived.

    Brian

> Cheers,
> Ole
> 
>> On 11 Nov 2020, at 12:43, Philip Homburg <pch-ipv6-ietf-6@u-1.phicoh.com> 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.
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
> 