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

Fernando Gont <fgont@si6networks.com> Thu, 31 October 2019 19:58 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 99278120973 for <v6ops@ietfa.amsl.com>; Thu, 31 Oct 2019 12:58:47 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 Vt8YDE6g996N for <v6ops@ietfa.amsl.com>; Thu, 31 Oct 2019 12:58:45 -0700 (PDT)
Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60F7212006A for <v6ops@ietf.org>; Thu, 31 Oct 2019 12:58:45 -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 B8426866A6; Thu, 31 Oct 2019 20:58:42 +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>
From: Fernando Gont <fgont@si6networks.com>
Openpgp: preference=signencrypt
Message-ID: <657422af-5243-ce32-e72c-72197cde866f@si6networks.com>
Date: Thu, 31 Oct 2019 16:58:32 -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: <ADCF08FD-1366-4CCB-984E-695D8E2AC2F8@employees.org>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/qmUE7Y4Rl-dxGZsiGCZwpmgK4bk>
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: Thu, 31 Oct 2019 19:58:51 -0000

On 27/10/19 19:52, Ole Troan wrote:
>>>> Note that we could change SLAAC to allow the lifetime of a
>>>> prefix to be set to zero, instead of having to wait for 2
>>>> hours. That might be an improvement but requires careful
>>>> analsysis.
>>> 
>>> Can you explain how operating a public service should work on
>>> this type of network?
>> 
>> Could you be more specific what you consider a 'public service' and
>> what you expect to break?
> 
> The (only) value (sic) of IPv6 to end-users is retoration of end to
> end connectivity at the network layer.

That's know how IPv6 is being deployed in many places. It's quite common
that the CPE implements a Diode firewall. And what's worse, the CPE
doesn't have the appropriate support in UPnP for punching holes in it.



> I challenge you to find in the "real world" of end-users many with
> much trust in the ad-based "you are the product" centralised services
> in the current Internet.

Isn't that how/why Google, Facebook, and others make money?



> IPv6 was meant to allow end-users to run
> decentralized services.
> 
> - hidden primary DNS - mail - web - home-automation - video
> conferencing - jabber
> 
> All of those have great open source software. To use Owen's
> paragraph: "I don’t know of a single server which operates that way
> currently. Can you point to a working example?"
> 
> Assuming all the moving parts required were updated to support flash
> renumbering (I have little proof they even support graceful
> renumbering), if the end-user cannot trust the lifetimes in the
> delegated prefix, DNS with TTL=1s is presumably the only choice?

I'm not saying you don't raise a valid question. However, in the context
of this discussion there's a difference between being able to graceully
handle the scenario when it happens, vs planning for it to happen
deterministically.

(FWIW, I have a bunch of services running behind NATs, where the
addresses get rotated. Yes, I do use small lifetimes (< 1 minute).
That's not uncommon nowadays, anyway)




>> What I described is basically what happens on IPv4 when a CPE uses
>> NAT and gets a new IPv4 address from the ISP.
> 
> If making IPv6 no better than IPv4 + NAT, then stick with IPv4 +
> NAT. IPv4 NAT scales very well as it turns out.

IPv6 could allow you to host services in a better way.

(In my example above, I just *can't* leverage IPv6 because of the
firewall and CPEs with no UPnP support for IPv6)




>> Flash renumbering is far from ideal, but a reality on the current
>> internet. Any application that is suitable for home use is expected
>> to deal with that scenario.
> 
> We don't need IPv6 to maintain the status quo.

We need IPv6 to actually work. There are networks nowadays in which it
is breaking badly. IN some cases it's preventing deployment. In others,
users are falling back to IPv4.


> 
>> Note that with automatic DNS updates, you can probably run a mail
>> server (or your personal 'cloud') on such a link. But that is not a
>> common use case at the moment.
> 
> And don't get me wrong, I'm all for making IPv6 addressing / onlink
> behaviour more robust. But not justified in this way that can be seen
> to allow for practices that removes any benefit of IPv6 over
> IPv4/NAT.

The benefits are in global addressing. As noted abouve, there are many
scenarios where "global connectivity" is worse for IPv6. Not that I like
it (but that doesn't change facts).

P.S.: I reiterate that the home network/cpe case is only *one* of the
scenarios where this problem may be faced.

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