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

Brian E Carpenter <brian.e.carpenter@gmail.com> Wed, 11 November 2020 21:18 UTC

Return-Path: <brian.e.carpenter@gmail.com>
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 DF6D03A1121 for <ipv6@ietfa.amsl.com>; Wed, 11 Nov 2020 13:18:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 fLixqrDxhhHk for <ipv6@ietfa.amsl.com>; Wed, 11 Nov 2020 13:18:20 -0800 (PST)
Received: from mail-pl1-x634.google.com (mail-pl1-x634.google.com [IPv6:2607:f8b0:4864:20::634]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 615CA3A1119 for <ipv6@ietf.org>; Wed, 11 Nov 2020 13:18:20 -0800 (PST)
Received: by mail-pl1-x634.google.com with SMTP id z1so1620103plo.12 for <ipv6@ietf.org>; Wed, 11 Nov 2020 13:18:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=8y1zhlix++H/5JPTpVxRAiWnqrMVPPUOdKIKSjHpv4w=; b=FlmHH3DmYcmbkTTCdiXorPfJt5uvEK48NI2E92PMxlLG8RWIgOtWh7Tm6lhgfyNa0R dNDftJofi4MSxihT98kkGq/iNV3whmjTK8B2ztsNy/FPNN6bkfoLq+H9LAFZJlxFFMFo 4KudQk1VQ4PEk0fRLO35OupzdhSkFPz3u+3mRyc42FsCLZBhhjwFoeHWhmLPKyGLLlsa HliWMpZXHZrlu2m4DSJwh7oTkSGSa7h6iXi6rUyXIZ7oqjpAg43e0aVhAfpHW3Gud3OO 54i+lPd2+gVRq4gpLGx7yqLfPCT4P+sE1cB0nxW7WqRGjBtcmt85u+r9mECtdUlQc9XD xkrQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=8y1zhlix++H/5JPTpVxRAiWnqrMVPPUOdKIKSjHpv4w=; b=o79cywwH/Xp8pzq5ntJvrw6G4o99uZ93qzXbLMZJn9y9U5/r/dJ7Z67ptzNW71Am+S T21ZbOfHwNRUEwEoQiZllYYwqcOQs8ZDLBXFsnn+qMfIw5s6TVNeycqjxy6TggwI8cct W4u+4BMKzKcdKiC9RSlFIINSQgyELS7D4G1X1uMX5DiZBEeCdWlLbI8VJ6VovcDBLst/ yor9tssmPlNEf7iqUAEfwSt36XKIf6ul97ZHjzc2lsrI6tqMXsIhEIFHXr3c5Mxt42hZ Z4VMUQYyBSqot1AthbKzmSZeKXh0V9ng36kdnu3TPVWshOzOWHN+67/N8yxR0qFk/Y0h Iyhw==
X-Gm-Message-State: AOAM530MgLHPPRVkMvgfmOM1WBgRid9kZygpPo7rR6ZuVV6cFsM1qH6q 8GP5xg51Qv4so1FSrOnAJvlmS4q9QR9JIA==
X-Google-Smtp-Source: ABdhPJzcVUbBCSWxFe7wxporQ9CqcwXDIaQ02H2J+temNsEu8pGdLIcpaFf2uXoB3Dqi6ZGnXVR/zw==
X-Received: by 2002:a17:902:70cb:b029:d7:e6da:9ad4 with SMTP id l11-20020a17090270cbb02900d7e6da9ad4mr13431681plt.48.1605129499197; Wed, 11 Nov 2020 13:18:19 -0800 (PST)
Received: from [192.168.178.20] ([151.210.130.0]) by smtp.gmail.com with ESMTPSA id v7sm3555136pfu.39.2020.11.11.13.18.16 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 11 Nov 2020 13:18:18 -0800 (PST)
Subject: Re: Ephemeral addressing [was Re: 64share v2]
To: otroan@employees.org, Philip Homburg <pch-ipv6-ietf-6@u-1.phicoh.com>
Cc: 6man WG <ipv6@ietf.org>
References: <CAD6AjGR-NE_sJ_jp7nAT6OvNkcdE9qoWuGEiiVW7r9YtsQvbbw@mail.gmail.com> <aabd41ad-1770-f2ac-77d6-62bfff1992c0@joelhalpern.com> <CC7C2B94-5A05-4682-8367-9072CC201C49@employees.org> <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> <038A830C-E024-42C6-917E-E6FF57829A1C@employees.org> <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> <267D8461-47EC-443A-98DF-4FE990138B5A@employees.org>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Message-ID: <43803767-47d4-1328-8562-b900a73855f9@gmail.com>
Date: Thu, 12 Nov 2020 10:18:16 +1300
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <267D8461-47EC-443A-98DF-4FE990138B5A@employees.org>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/xYeZIHMWUbNkNKdY-OTgTILBhAc>
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 21:18:23 -0000

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