Re: [v6ops] SLAAC renum: Problem Statement & Operational workarounds

Fernando Gont <fgont@si6networks.com> Fri, 01 November 2019 03:31 UTC

Return-Path: <fgont@si6networks.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A771512089A for <v6ops@ietfa.amsl.com>; Thu, 31 Oct 2019 20:31:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 8eQHMZp1CSXQ for <v6ops@ietfa.amsl.com>; Thu, 31 Oct 2019 20:31:35 -0700 (PDT)
Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01E3B120827 for <v6ops@ietf.org>; Thu, 31 Oct 2019 20:31:34 -0700 (PDT)
Received: from [192.168.1.36] (unknown [177.27.208.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 2882686699; Fri, 1 Nov 2019 04:31:31 +0100 (CET)
To: Ole Troan <otroan@employees.org>, Philip Homburg <pch-v6ops-9@u-1.phicoh.com>
Cc: v6ops@ietf.org
References: <m1iOinq-0000J3C@stereo.hq.phicoh.net> <44F39DE2-E142-4ED0-853E-2F3AAC6F4ADE@employees.org> <m1iOnqN-0000EpC@stereo.hq.phicoh.net> <ADCF08FD-1366-4CCB-984E-695D8E2AC2F8@employees.org> <m1iP0kt-0000GkC@stereo.hq.phicoh.net> <21E28E8F-8E91-47D6-8337-9FF0359D67B8@employees.org> <m1iP1fa-0000GYC@stereo.hq.phicoh.net> <1E99599F-0A56-4A53-AD7C-499BC87AA7D3@employees.org>
From: Fernando Gont <fgont@si6networks.com>
Openpgp: preference=signencrypt
Message-ID: <74305ad0-282c-a7aa-5406-418c85c6f5b5@si6networks.com>
Date: Fri, 01 Nov 2019 00:28:30 -0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0
MIME-Version: 1.0
In-Reply-To: <1E99599F-0A56-4A53-AD7C-499BC87AA7D3@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/v6ops/0trUlszhdfP-xtX0TFwOtHP71MU>
Subject: Re: [v6ops] SLAAC renum: Problem Statement & Operational workarounds
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 01 Nov 2019 03:31:41 -0000

On 28/10/19 06:58, Ole Troan wrote:
> Philip,
> 
>>> I didn't see your answer to:  "I dont know of a single server which
>>> operates that way currently. Can you point to a working example?"
>>>
>>> I take it the answer is: "currently none"?
>>
>> Is the question whether people are running services on home networks where
>> the ISP uses flash renumbering?
>>
>> If so, the answer is yes. There are a number of 'dynamic DNS' providers.
>> People use those to keep DNS up-to-date when their public IPv4 address changes.
>>
>> All of this is small scale hobbyist usage (and most likely only IPv4) but
>> it does exist.
> 
> No, the question is if there is any host stack + server software that deals with flash renumbering deployed.
> And that is deployable without coding.
> 
> It's the same question Owen posed for the ISP side, when challenged with how DHCP behaves.
> The point here is that we as the IETF must also consider the end-user here. Not that I don't think ISPs do that too, but so far this debate has largely been on the premise of the opertor with little concern of the consequences for the user.

No, that's in correct. This document was, in fact, triggered by an
operator that does care.

And both here and on the ipv6-ops there have been statements noting that
they have these scenarios in their networks. And not because they don't
care about their users.

-- 
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492