IETF Logo Mail Archive

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

Philip Homburg <pch-v6ops-9@u-1.phicoh.com> Mon, 28 October 2019 14:04 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 757BE1200E9 for <v6ops@ietfa.amsl.com>; Mon, 28 Oct 2019 07:04:46 -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 nCBvAtkhATJY for <v6ops@ietfa.amsl.com>; Mon, 28 Oct 2019 07:04:45 -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 D215F12002F for <v6ops@ietf.org>; Mon, 28 Oct 2019 07:04:44 -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 m1iP5dN-0000GNC; Mon, 28 Oct 2019 15:04:37 +0100
Message-Id: <m1iP5dN-0000GNC@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: <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>
In-reply-to: Your message of "Mon, 28 Oct 2019 10:58:29 +0100 ." <1E99599F-0A56-4A53-AD7C-499BC87AA7D3@employees.org>
Date: Mon, 28 Oct 2019 15:04:36 +0100
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/IXrBepoXyof9Fdv3IF_8fYErlF8>
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: Mon, 28 Oct 2019 14:04:46 -0000

> No, the question is if there is any host stack + server software
> that deals with flash renumbering deployed.  And that is deployable
> without coding.

Flash renumbering is by and large not a server problem. If a request
reaches the server, then the server typically can reply. Any flow that
spans the renumbering event will be affected, but there are lots of 
other issues that also affect established flows.

If you renumber the network that contains mail servers, web servers,
xmpp servers, etc., then the servers don't really notice.

Of course, a renumbering event requires DNS to be updated, possibly changes
to firewalls, etc. But that is no different from a proper renumbering event.

v2.23.0 | Report a Bug | By Email