Re: A common problem with SLAAC in "renumbering" scenarios

Mikael Abrahamsson <swmike@swm.pp.se> Wed, 20 February 2019 09:04 UTC

Return-Path: <swmike@swm.pp.se>
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 3893B12D827 for <ipv6@ietfa.amsl.com>; Wed, 20 Feb 2019 01:04:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Level:
X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se
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 qs4m0YWSF9xv for <ipv6@ietfa.amsl.com>; Wed, 20 Feb 2019 01:03:58 -0800 (PST)
Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (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 F0E6C129619 for <ipv6@ietf.org>; Wed, 20 Feb 2019 01:03:57 -0800 (PST)
Received: by uplift.swm.pp.se (Postfix, from userid 501) id F215BBB; Wed, 20 Feb 2019 10:03:55 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1550653435; bh=iNdgWrT/SAheHKFA3IMoskU/RG+a6teQZKc/wGa9sAI=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=lnFBqWc+eyGFboNqrYepzJmUkwp5Kimt44ojPPRcO12F1bplrWOsaIJHxj0mjrI+L rWBf/sjyTBzgYgS564QIIUctpJOr+Ea/q/xMh1tjD89HPULJLQTMwTlukQyzLfNwn9 QR1vSA+/K3x9SmUd+uHYBJhL4PZ2LvtdJ2Y9pyMw=
Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id EF5ACBA; Wed, 20 Feb 2019 10:03:55 +0100 (CET)
Date: Wed, 20 Feb 2019 10:03:55 +0100
From: Mikael Abrahamsson <swmike@swm.pp.se>
To: Lorenzo Colitti <lorenzo@google.com>
cc: 6man WG <ipv6@ietf.org>
Subject: Re: A common problem with SLAAC in "renumbering" scenarios
In-Reply-To: <CAKD1Yr0t8MEg-SRukTKM9VjLSaJB4tc-uhxJkX2U-3gQX2PvWQ@mail.gmail.com>
Message-ID: <alpine.DEB.2.20.1902200952530.24327@uplift.swm.pp.se>
References: <60fabe4b-fd76-4b35-08d3-09adce43dd71@si6networks.com> <4c5fab33-2bff-e5b5-fc1d-8f60a01a146d@go6.si> <b4525832-9151-20bf-7136-31d87ba6c88d@huitema.net> <463f15cf-2754-e2e8-609d-dc0f33448c6c@go6.si> <ff649810-7242-7bc2-d36f-3f998f7bdd71@asgard.org> <9CDF41CA-83B4-4FC4-B995-EF79727C5458@steffann.nl> <CAO42Z2wA+vLmU7+sU6xLK7TO6pWfNQA5shs9zp=PqANCihLmBQ@mail.gmail.com> <BAB3061A-1808-4C0E-AA1B-2D7DD5BA63FC@employees.org> <bbd8b761-403a-5b3f-3f04-dc3bfdea116e@foobar.org> <6F3036C6-50A1-43C6-B554-31293B69E59D@employees.org> <433607c1-dbc6-a42e-cb17-dc209e33bdaa@si6networks.com> <12EA4FAE-BE3D-4CFE-9837-DF052F79A998@employees.org> <5bc3eaf0-3ef0-d954-b228-00a7faac7f4c@si6networks.com> <CAO42Z2wa9gWoB_bWrYt79urHF8ihmMAbjDSZCBoZa8dn8SCNFw@mail.gmail.com> <alpine.DEB.2.20.1902200735480.24327@uplift.swm.pp.se> <CAO42Z2xwyes97LAy1duXpJMeknJhmkA6yV-tWCPLmw6QvOuKbQ@mail.gmail.com> <CAKD1Yr0t8MEg-SRukTKM9VjLSaJB4tc-uhxJkX2U-3gQX2PvWQ@mail.gmail.com>
User-Agent: Alpine 2.20 (DEB 67 2015-01-07)
Organization: People's Front Against WWW
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"; format="flowed"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/n6UYwvQVs4kgJqI97YAIsr9vtXM>
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, 20 Feb 2019 09:04:00 -0000

On Wed, 20 Feb 2019, Lorenzo Colitti wrote:

> That doesn't really make sense on a mobile platform. When you switch 
> from wifi to cell data, you probably don't want to keep that connection 
> alive until that specific wifi network comes back. Instead you want to 
> give the app an error as soon as possible so it can retry the failed 
> connection on the new network. On Android, TCP connections are closed 
> the instant their IP address goes away. I don't know what iOS does.

I contacted linux-netdev about this, and I got no sympathy to close down 
the sessions if the addresses were gone. "Oh, the addresses might come 
back". Even when I said I'd like to be able to have this as a setting to 
close down the sessions, that I knew it won't come back I kept getting 
""how do you know?"

How do you close them in Android? Did you write your own userspace code to 
find sockets bound to addresses that were no longer available and close 
them down?

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se