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

Jan Zorz - Go6 <jan@go6.si> Tue, 12 February 2019 12:36 UTC

Return-Path: <jan@go6.si>
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 CCBBA12F18C for <ipv6@ietfa.amsl.com>; Tue, 12 Feb 2019 04:36:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=go6.si
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 OlWaV8CpU-kR for <ipv6@ietfa.amsl.com>; Tue, 12 Feb 2019 04:36:33 -0800 (PST)
Received: from mx.go6lab.si (mx.go6lab.si [IPv6:2001:67c:27e4::23]) (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 413CC12DF71 for <ipv6@ietf.org>; Tue, 12 Feb 2019 04:36:32 -0800 (PST)
Received: from localhost (localhost [IPv6:::1]) by mx.go6lab.si (Postfix) with ESMTP id 5DB06660CA; Tue, 12 Feb 2019 13:36:27 +0100 (CET)
X-Virus-Scanned: amavisd-new at go6.si
Received: from mx.go6lab.si ([IPv6:::1]) by localhost (mx.go6lab.si [IPv6:::1]) (amavisd-new, port 10024) with LMTP id oSvPOM6bJj2X; Tue, 12 Feb 2019 13:36:26 +0100 (CET)
Received: from mail.go6.si (mail.go6.si [IPv6:2001:67c:27e4::61]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.go6.si", Issuer "Let's Encrypt Authority X3" (not verified)) by mx.go6lab.si (Postfix) with ESMTPS id 5215360749; Tue, 12 Feb 2019 13:36:26 +0100 (CET)
Received: from haktar.local (unknown [IPv6:2001:67c:27e4:102:fc6a:a89c:a77f:716f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "Jan Zorz", Issuer "COMODO RSA Client Authentication and Secure Email CA" (not verified)) (Authenticated sender: jan) by mail.go6.si (Postfix) with ESMTPSA id 2CBD1807E4; Tue, 12 Feb 2019 13:36:26 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=go6.si; s=mail; t=1549974986; bh=DP3hL6RccNvif5AVSD2y1QLmvo4eQaK1zJzyJVKfBoQ=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=ISPnL4697rX/IXL/uYGLBm+2S23PMD+Q6sAkDqEY3Op0O6tBHTwYyo9pUop9bLV1M +oJjXUS4CGl+Vs8lNFxxX+JcD7KxHxc/BPC6k4ZeOYOptAth/I1pt+F+8pdBawYhKF avXldhilTUYG/76q9XoRLJQ+NfW7OgqyjvTMMALM=
Subject: Re: A common problem with SLAAC in "renumbering" scenarios
To: Mark Smith <markzzzsmith@gmail.com>, Michael Richardson <mcr@sandelman.ca>
Cc: 6man WG <ipv6@ietf.org>
References: <60fabe4b-fd76-4b35-08d3-09adce43dd71@si6networks.com> <alpine.DEB.2.20.1901311236320.5601@uplift.swm.pp.se> <m1gpCcz-0000FlC@stereo.hq.phicoh.net> <ddd28787-8905-bafd-3546-2ceef436c8b0@si6networks.com> <m1gptWx-0000G3C@stereo.hq.phicoh.net> <69609C58-7205-4519-B17A-4FBC8AE2EA16@employees.org> <d40b41c3-ff1b-cab4-a8de-16692a78e8fd@go6.si> <D1E45CAD-08D0-43D4-90F7-C4DD44CB32C0@employees.org> <alpine.DEB.2.20.1902041330531.23912@uplift.swm.pp.se> <46B8DB92-DC81-4242-9780-0D00FB6BDB7A@employees.org> <1c7ebabb-d6f6-d877-d4aa-d6c0fc7d5c60@go6.si> <6278.1549471453@dooku.sandelman.ca> <CAO42Z2xdKtLJV11KXELBKca6CWn=B6Avz6bO_94kFFXaKiZ-pQ@mail.gmail.com> <4602.1549908472@localhost> <CAO42Z2w1swQNuwnrOyTCEMXt0NSyrBx7Ww3kUN-7dfEV=fvk3A@mail.gmail.com>
From: Jan Zorz - Go6 <jan@go6.si>
Message-ID: <c16e0e1f-1ed2-ad88-80f1-070bdd8bccca@go6.si>
Date: Tue, 12 Feb 2019 13:36:25 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.5.0
MIME-Version: 1.0
In-Reply-To: <CAO42Z2w1swQNuwnrOyTCEMXt0NSyrBx7Ww3kUN-7dfEV=fvk3A@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/gmRUsa65EtdwyNgnB6T4XLGNBYk>
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: Tue, 12 Feb 2019 12:36:36 -0000

On 12/02/2019 01:42, Mark Smith wrote:
> I was thinking earlier today that dynamic /64s on the PPPoE virtual
> link would also suffer from the same issues that dynamic PD prefixes
> does, and therefore thinking that I'd do static /64s on the PPPoE link
> too (and aggregate them upstream of the group of BNGs).

Surprisingly, this is not causing major problems. Similar to IPv4, where 
changing the public IPv4 address on the CPE that is doing NAT to the 
internal LAN doesn't have considerable effect on the hosts inside (well, 
some sessions could drop on change, but that's the price you pay with 
NAT). In IPv6, if source and destination address is the same - if 
network in between changes and re-establishes quick enough - that should 
work (and it works in deployments out there ;) )

> 
> However, different prefixes across link disconnect/reconnect is
> probably less of an issue when the device is a host itself - the
> disconnect/reconnect is most likely going to be caused by the host
> being rebooted/powered off/powered on, so the all of the transport
> layer and application state that would be disrupted by a re-addressing
> is discarded anyway.

Indeed.

> 
> Still, if the link is flakey or interrupted somehow, then a dynamic
> /64 prefix on the host to BNG link would still be disruptive to the
> host and its applications. For the best customer/end-user experience
> it would be best to have stable/static /64 prefixes on the WAN link
> too.

That (in theory) would be ideal, but reality sometimes needs some 
compromises ;)

Cheers, Jan