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

Philip Homburg <pch-v6ops-9@u-1.phicoh.com> Fri, 25 October 2019 08:37 UTC

Return-Path: <pch-b9D3CB0F5@u-1.phicoh.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 98AA2120233 for <v6ops@ietfa.amsl.com>; Fri, 25 Oct 2019 01:37:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.499
X-Spam-Level:
X-Spam-Status: No, score=-1.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.399, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=no 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 9p9eMDCQ-o0I for <v6ops@ietfa.amsl.com>; Fri, 25 Oct 2019 01:37:01 -0700 (PDT)
Received: from stereo.hq.phicoh.net (stereo6-tun.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A09012001E for <v6ops@ietf.org>; Fri, 25 Oct 2019 01:37:00 -0700 (PDT)
Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384) (Smail #157) id m1iNv5U-0000KUC; Fri, 25 Oct 2019 10:36:48 +0200
Message-Id: <m1iNv5U-0000KUC@stereo.hq.phicoh.net>
To: v6ops@ietf.org
From: Philip Homburg <pch-v6ops-9@u-1.phicoh.com>
Sender: pch-b9D3CB0F5@u-1.phicoh.com
References: <m1iNIFE-0000IwC@stereo.hq.phicoh.net> <d1b6855d-bde9-7b53-4809-0846bb9772e4@si6networks.com> <CAO42Z2x7vudujw5t++obry56g=VNjQXXTHFK8pBPk0jmk78Bcg@mail.gmail.com> <CAJoHkZ8pTjszP0vw4BjX0HUhmPa6wJONzdy2JEm5iqAfBUvjRg@mail.gmail.com> <CAO42Z2wCYi4KWTEz1hUSPVr9+hu8GaHRkPuvQQ2P00knvnPaaQ@mail.gmail.com> <848BA3B3-36B4-4C42-86D0-88759BC45D5A@employees.org> <A61279DA-4678-4A10-9117-6CA227AE2FA5@cisco.com> <A90AD47E-00E2-4EAB-8BD8-142CC10A6B6F@employees.org>
In-reply-to: Your message of "Thu, 24 Oct 2019 15:38:36 +0200 ." <A90AD47E-00E2-4EAB-8BD8-142CC10A6B6F@employees.org>
Date: Fri, 25 Oct 2019 10:36:44 +0200
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/2f76XnMTt4HRaaMg5AwnrRX01jg>
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, 25 Oct 2019 08:37:03 -0000

>I'm skeptical that playing with prefix timers and protocol mechanisms will do m
>ore than put lipstick on the pig. Iff we wanted to solve ephemeral addressing /
> connectivity, that's would require something else.

A typical home situation today has almost exclusively outbound connections.
People also accept that if you reboot a home router, a video stream may
be interrupted.

Where general problem of renumbering is hard to solve, the more limited 
home use case is not. For IPv4 all of this is hidden by NAT in the CPE.

After the previous discussion, I updated my IPv6 stack to do detect prefixes
that are no longer announced in RAs. This does solve the problem at hand.

Previously, AVM CPEs (Fritz!Box) would actively kill weird prefixes used
by hosts. That was quite effective, though has some weird side effects.
So a CPE solution is likely to solve this problem as well.

This is problem that can be solved both in the host and in the CPE.

Of course, we can also wait for ISPs to start shipping CPEs with NAT66.

Reality is that ISPs do flash renumbering for IPv4 customers. We can tell them 
that they cannot do that for IPv6, but that will result either in a delay
of IPv6 deployment, or they will find a hack (such as NAT66) to make it 'work'.