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

Christian Huitema <huitema@huitema.net> Fri, 15 February 2019 09:38 UTC

Return-Path: <huitema@huitema.net>
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 A2074130F82 for <ipv6@ietfa.amsl.com>; Fri, 15 Feb 2019 01:38:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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 4V_5hTUpUOSK for <ipv6@ietfa.amsl.com>; Fri, 15 Feb 2019 01:38:04 -0800 (PST)
Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (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 A9DBA130F8E for <ipv6@ietf.org>; Fri, 15 Feb 2019 01:38:04 -0800 (PST)
Received: from xsmtp02.mail2web.com ([168.144.250.215]) by mx65.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from <huitema@huitema.net>) id 1guZwY-000Byp-2f for ipv6@ietf.org; Fri, 15 Feb 2019 10:38:02 +0100
Received: from [10.5.2.35] (helo=xmail10.myhosting.com) by xsmtp02.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from <huitema@huitema.net>) id 1guZwN-0003AD-7v for ipv6@ietf.org; Fri, 15 Feb 2019 04:37:58 -0500
Received: (qmail 23828 invoked from network); 15 Feb 2019 09:37:49 -0000
Received: from unknown (HELO [192.168.200.65]) (Authenticated-user:_huitema@huitema.net@[72.235.197.82]) (envelope-sender <huitema@huitema.net>) by xmail10.myhosting.com (qmail-ldap-1.03) with ESMTPA for <ipv6@ietf.org>; 15 Feb 2019 09:37:48 -0000
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (1.0)
From: Christian Huitema <huitema@huitema.net>
X-Mailer: iPhone Mail (16D57)
In-Reply-To: <463f15cf-2754-e2e8-609d-dc0f33448c6c@go6.si>
Date: Thu, 14 Feb 2019 23:37:47 -1000
Cc: ipv6@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <444A9043-0EDF-4F21-9DCE-BF019B81D078@huitema.net>
References: <60fabe4b-fd76-4b35-08d3-09adce43dd71@si6networks.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> <d38857c2-6e92-91d6-bb5d-d3eeeb61276a@gmail.com> <CAO42Z2yb47OyXk__Sz-kO00pfcBJgLAhff5DF=mpAddR0iCnAA@mail.gmail.com> <2612280f-195a-ae7a-b3b1-9022d9282fa7@foobar.org> <56F813F4-C512-40A9-8A68-1090C76A80F6@consulintel.es> <CAHL_VyCN8kU7qnLOphfGR25-xGBe_p6WeGTkKVXwU5uy5aJ8Dg@mail.gmail.com> <65DB4854-97D2-4C31-A691-2CD93812EF93@consulintel.es> <CAHL_VyCMpCcGkEQu+RV1GRf2QLB-HD0+AOOBV0YhfQ5sbydVzQ@mail.gmail.com> <8CE7A0CD-97D9-46A0-814D-CAF8788F9964@consulintel.es> <e3e0bf2273e04f15b792665d0f66dfe5@boeing.com> <4c5fab33-2bff-e5b5-fc1d-8f60a01a146d@go6.si> <b4525832-9151-20bf-7136-31d87ba6c88d@huitema.net> <463f 15cf-2754-e2e8-609d-dc0f33448c6c@go6.si>
To: Jan Zorz - Go6 <jan@go6.si>
Subject: Re: A common problem with SLAAC in "renumbering" scenarios
X-Originating-IP: 168.144.250.215
X-Spampanel-Domain: xsmtpout.mail2web.com
X-Spampanel-Username: 168.144.250.0/24
Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com
X-Spampanel-Outgoing-Class: ham
X-Spampanel-Outgoing-Evidence: Combined (0.03)
X-Recommended-Action: accept
X-Filter-ID: EX5BVjFpneJeBchSMxfU5pvAoeErgsoZQ1RY8uHsEsF602E9L7XzfQH6nu9C/Fh9KJzpNe6xgvOx q3u0UDjvO0+c5LB5+AaOnyUGHzplYThs1ujulqUFmMITHM77eiViV/H70zrPljHGuFdeAhMLjs7i TvJ2/ZGzVWB9scFAaCdIFaUvXN+CI+RGy3Me16pBuzDn5j2tUhjYPVPi3bwTCB/TBCf6oYXAWGet lavcAjAiREicRPMV5adYQyNOvKmgwJpy2yi2NB5qsi4dVukIa9cV2Hz37FuQUlYMDMlHwjIJ0464 etNXHOU+5Kb0QuG3bATPP9eeLWC5kDweN7crsXBXvrLBlKCVRjjdPbjQ4HmidG0pg2HLuLsP3mPp isElTs5Ex5aNZlcgVQFtAhrEij3dKxLhoxcmaInYbR5vlqETd+klAX+KFYkIxu6zxdn+1QmdZsu6 kxo/qWEj6Z1d7VIcMSgqtcKbU9La+AHiCFB9vuYMeDoXsMJDD9CZFW2DHXeua4usuyudZl7ZJWmg 5a0jiD6XqsJZtjQxlyCdsewzRmhoeKlCpofGlp99T8RpVvnI57oS/C7UZijoF9JMPWP2G3mIJzN4 0ppVKDJTDZFl7B1QQuoPmRqW5R/J2U16th3iHXgtR+Y1L+Zzkg9a2/EwurjXBahe19+jBD7VuIee yrhzWminYO4gRGXn3bDVvCoqfGflxbtjudA02/m3s9zJOHHkRt9OGYyf5Z4edLS4aeVKjbQuc4NX lvv7E2xu6qXJ7npE+O0SMc/3n5+aXvUNCaee1KCwZHITsuNxODNy2DNwOgV373pfDhBQ21OdM8gu ipSMnc4a1vOLkZpIf7zG4T/7wW5j1y/SF6LDdLr4YaYZ30wD+IYKdMuYOSaM8vAerBHKRzUHI5QD qE6Br8kPb2KLnZ2Xht3zA75VehhIcJfl9xjKxh+F8kIXLdZND3rjHB4Yc+TqdazcMI41sA2AfTJ2 5W/vzfaHf3wr2m4mbmeTgFKBgc4kmBS2brusOVZrHRzE6blhEo+mN1j1Fw==
X-Report-Abuse-To: spam@quarantine9.antispamcloud.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/gcPlBcw5dTGrCVyEz-ZG9TDZMaQ>
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: Fri, 15 Feb 2019 09:38:10 -0000

 

> On Feb 14, 2019, at 11:30 PM, Jan Zorz - Go6 <jan@go6.si> wrote:
> 
> /64 for each device is fine. What I'm questioning is if we really need to make underlying to be something that was never meant to be if L7 and above is broken? I think L7 and above needs to be fixed first and then changing of addresses in transport layer can have any effect. Until then - let's transport packets in a way that doesn't break often and make user grumpy.

We are pretty far from the original thread, but let me say that looking at layers as if they were isolated does not work. Tracking uses all the cues that it can, from MAC addresses to GPU model. It will of course use 64 bit prefixes when available. That a beautiful index for the surveillance operations. It is pretty clear that we need to somehow defend against that.

-- Christian Huitema