IETF Logo Mail Archive

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

Brian E Carpenter <brian.e.carpenter@gmail.com> Wed, 13 February 2019 01:05 UTC

Return-Path: <brian.e.carpenter@gmail.com>
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 86CC4130EBA for <ipv6@ietfa.amsl.com>; Tue, 12 Feb 2019 17:05:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 QZrC6uV4buhQ for <ipv6@ietfa.amsl.com>; Tue, 12 Feb 2019 17:05:06 -0800 (PST)
Received: from mail-pf1-x42f.google.com (mail-pf1-x42f.google.com [IPv6:2607:f8b0:4864:20::42f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE0E0130EA7 for <ipv6@ietf.org>; Tue, 12 Feb 2019 17:05:05 -0800 (PST)
Received: by mail-pf1-x42f.google.com with SMTP id f132so314330pfa.6 for <ipv6@ietf.org>; Tue, 12 Feb 2019 17:05:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=gl8pF2GNdnvrFXuwdYOtY0VUEOjGte1jXcQWwU0nIPk=; b=MpRyRNn3ytZ7EIrAGY8N3wNAjm8LyLi5snT1i+GYlYClKXP9BwcakciqYCaGo0Jk7O 36Ma0Cj1kskpT53+k3/DlI62qOQ6Z74xuZtQXujxO11DexN+qGdmd6LXwWeOSWKT24KB 1meAMLWbIzWhxhVdgdf0SgvBQmMYEdfw/Xw96cq7MZcIfA3vBst7eIhlkQZG2UUXMHCp pIHt2iyer+uL0WXmXeyDcXcrFAEkV0xZD0wK11GDVSDoT1Z0YDi3oBG6cn334Eiu9bDz HrpSUdmHhqX/MJ2f8emaRA/dF0KjEfpRyAuEGxzrmXvFWvC1R2xd26plUmrFxxW486Tf iOCA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=gl8pF2GNdnvrFXuwdYOtY0VUEOjGte1jXcQWwU0nIPk=; b=RldVi2+Lj37SmDX8yFKXAq9EDj4oWwpSQk+dKukvv0R5CwKqXPEV+F/Kalzauu0vMm BooxnV0d16PZbQvE4l77Gpno718wohTcXdS64ErWM2JGh3QDK0tl5qAavB1aKzqLYjhR qTZN9vStSK9GzyA//AYACSGAKh07+0PzGJa/M6/DjSvozQvpOp8ZoTHcFf7DW7lcrSJi I4y6DjmbcNGbwbRWcWCP6m3VdQ54psCIzO8Vv2safQTxBA5l4XPv9R0Xfr8O4mhI3DQ+ LvF9ukZLOrsRRZq/vLWDGAsthZRgNzsRRjJnZoY385WPaPCc62khE0XZ7FjLqjIMw5jA vQjA==
X-Gm-Message-State: AHQUAuY0AH6iAho11/wmCBCa/xE7MX2dQWxQ2CzFlch9FVEocF555+OZ jqX9q90xYhejWZ+ZYeVtkuuB5OBD
X-Google-Smtp-Source: AHgI3IYJpj5sO0qpE5Jx9QBCTefMsRywrN6B69FsFNovTOZpyZz292t9Sera1EUjabUbqKmSLbbMQw==
X-Received: by 2002:a62:2781:: with SMTP id n123mr6862412pfn.138.1550019905096; Tue, 12 Feb 2019 17:05:05 -0800 (PST)
Received: from [192.168.88.29] ([103.29.31.113]) by smtp.gmail.com with ESMTPSA id v11sm22532499pfa.49.2019.02.12.17.05.02 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 12 Feb 2019 17:05:04 -0800 (PST)
Subject: Re: A common problem with SLAAC in "renumbering" scenarios
To: Mark Smith <markzzzsmith@gmail.com>, Lee Howard <lee@asgard.org>
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> <c16e0e1f-1ed2-ad88-80f1-070bdd8bccca@go6.si> <1F2C2AEE-1C7D-481C-BBA7-7E507312C53A@employees.org> <e56a6e5b-648d-200e-c35d-97f15a31fb2a@asgard.org> <CAO42Z2zh7fKAgQJq9aLCTiFoSSsTeGM=pK3gXitg+gcxH=9fhQ@mail.gmail.com>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Message-ID: <d38857c2-6e92-91d6-bb5d-d3eeeb61276a@gmail.com>
Date: Wed, 13 Feb 2019 14:04:58 +1300
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.0
MIME-Version: 1.0
In-Reply-To: <CAO42Z2zh7fKAgQJq9aLCTiFoSSsTeGM=pK3gXitg+gcxH=9fhQ@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/iL4tFq_S_DMQDhl-xUukeMKB9zk>
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, 13 Feb 2019 01:05:08 -0000

On 2019-02-13 13:43, Mark Smith wrote:
> On Wed, 13 Feb 2019 at 08:55, Lee Howard <lee@asgard.org> wrote:
>>
>> Seems like I may still disagree about the architecture of the Internet. . .
>>
>> On 2/12/19 9:53 AM, Ole Troan wrote:
>>> 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.
>>
>> This is packet switching, not circuit switching. Be resilient.
>>
> 
> The questions are where and where best to implement that resilience?
> 
> IP layer? Within transport layer protocols? Within the transport
> layer/application API? Within each application?

All of the above. Seriously. Resilience to "things that should never happen" is basic good software engineering. The trick is to make sure that the resilience costs nothing when things are normal, if possible.

    Brian

v2.23.0 | Report a Bug | By Email