IETF Logo Mail Archive

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

Ole Troan <otroan@employees.org> Tue, 12 February 2019 14:53 UTC

Return-Path: <otroan@employees.org>
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 299761200B3 for <ipv6@ietfa.amsl.com>; Tue, 12 Feb 2019 06:53:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 mp4IXXwo8EYD for <ipv6@ietfa.amsl.com>; Tue, 12 Feb 2019 06:53:05 -0800 (PST)
Received: from bugle.employees.org (accordion.employees.org [198.137.202.74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 673BB1200ED for <ipv6@ietf.org>; Tue, 12 Feb 2019 06:53:05 -0800 (PST)
Received: from [172.20.1.175] (unknown [12.1.75.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by bugle.employees.org (Postfix) with ESMTPSA id 3FE5DFECC129; Tue, 12 Feb 2019 14:53:04 +0000 (UTC)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (1.0)
Subject: Re: A common problem with SLAAC in "renumbering" scenarios
From: Ole Troan <otroan@employees.org>
X-Mailer: iPhone Mail (16D39)
In-Reply-To: <c16e0e1f-1ed2-ad88-80f1-070bdd8bccca@go6.si>
Date: Tue, 12 Feb 2019 06:53:03 -0800
Cc: Mark Smith <markzzzsmith@gmail.com>, Michael Richardson <mcr@sandelman.ca>, 6man WG <ipv6@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <1F2C2AEE-1C7D-481C-BBA7-7E507312C53A@employees.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> <c16e0e1f-1ed2-ad88-80f1-070bdd8bccca@go6.si>
To: Jan Zorz - Go6 <jan@go6.si>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/-M0k6zHM2IY0iSI1Tb51YM8EVKM>
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 14:53:07 -0000

Jan,

> On 12 Feb 2019, at 04:36, Jan Zorz - Go6 <jan@go6.si> wrote:
> 
> 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 ;) )

“Not considerable effect”?
It breaks all existing connections. 
It requires updating DNS for services. 
It might require updating static NAT entries and filtering rules. 
...

If we accept that IPv6 will work no better than IPv4 behind a NAT. I challenge you to give me one good reason to do IPv6 at all. 

Ole

v2.23.0 | Report a Bug | By Email