IETF Logo Mail Archive

Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios

Christian Huitema <huitema@huitema.net> Mon, 04 February 2019 00:08 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 AAA7A12F19D for <ipv6@ietfa.amsl.com>; Sun, 3 Feb 2019 16:08:08 -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=unavailable 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 m0sgu0WJPKPE for <ipv6@ietfa.amsl.com>; Sun, 3 Feb 2019 16:08:07 -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 769F7126F72 for <ipv6@ietf.org>; Sun, 3 Feb 2019 16:08:07 -0800 (PST)
Received: from xsmtp02.mail2web.com ([168.144.250.215]) by mx36.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from <huitema@huitema.net>) id 1gqRnv-0007XE-BT for ipv6@ietf.org; Mon, 04 Feb 2019 01:08:04 +0100
Received: from [10.5.2.49] (helo=xmail11.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 1gqRnp-00010K-Fj for ipv6@ietf.org; Sun, 03 Feb 2019 19:08:01 -0500
Received: (qmail 29438 invoked from network); 4 Feb 2019 00:07:52 -0000
Received: from unknown (HELO [192.168.200.65]) (Authenticated-user:_huitema@huitema.net@[72.235.197.82]) (envelope-sender <huitema@huitema.net>) by xmail11.myhosting.com (qmail-ldap-1.03) with ESMTPA for <v6ops@ietf.org>; 4 Feb 2019 00:07:52 -0000
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (1.0)
From: Christian Huitema <huitema@huitema.net>
X-Mailer: iPhone Mail (16C101)
In-Reply-To: <85C3CE49-93CC-48E1-94FB-46A0203783A2@employees.org>
Date: Sun, 03 Feb 2019 14:07:50 -1000
Cc: Michael Richardson <mcr+ietf@sandelman.ca>, "v6ops@ietf.org WG" <v6ops@ietf.org>, 6man WG <ipv6@ietf.org>, JORDI PALET MARTINEZ <jordi.palet=40consulintel.es@dmarc.ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <391AE39D-F754-47A8-B20A-3AEC4C174B9F@huitema.net>
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> <ac773bb5-0da8-064b-d46b-3a218b8c9e7a@si6networks.com> <CFAEACC4-BA78-4DF9-AD8A-3EB0790B8000@employees.org> <a4f6742e-f18e-3384-d4cc-06bfab49101f@si6networks.com> <FEFA99C2-4F09-4D8F-8D51-C9D9D7090637@employees.org> <a484d5de-0dce-a41a-928e-785d8d80d05d@si6networks.com> <A40C5116-9474-4F2B-BD94-F57D155ECD4C@employees.org> <b05e3872-d63b-108c-6c00-21b951dad263@si6networks.com> <A9FBBED3-A858-4BB1-A02A-2A06CBEB7662@consulintel.es> <010b2c6d-9c79-9309-aad8-32530c9dab94@gmail.com> <A0201A4B-77BB-40F4-A35F-F1491732D537@consulintel.es> <749b121f-cac5-30e0-686c-9f7f29313d91@huitema.net> <2BAD7ADA-6940-45EA-B7DD-0D82B9E95A05@employees.org> <6440.1549227369@dooku.sandelman.ca> <85C3CE49-93CC -48E1-94FB-46A0203783A2@employees.org>
To: Ole Troan <otroan@employees.org>
Subject: Re: [v6ops] 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.04)
X-Recommended-Action: accept
X-Filter-ID: EX5BVjFpneJeBchSMxfU5oBhQfmFSfycR+1XThqEkQp602E9L7XzfQH6nu9C/Fh9KJzpNe6xgvOx q3u0UDjvO0+c5LB5+AaOnyUGHzplYThs1ujulqUFmMITHM77eiViwMa/1a/P0NpzrEhs7/NuLc7i TvJ2/ZGzVWB9scFAaCdIFaUvXN+CI+RGy3Me16pBpxvnk7PJGygctl3LC86inx/TBCf6oYXAWGet lavcAjAiREicRPMV5adYQyNOvKmgwJpy2yi2NB5qsi4dVukIa9cV2Hz37FuQUlYMDMlHwjIJ0464 etNXHOU+5Kb0QuG3bATPP9eeLWC5kDweN7crsXBXvrLBlKCVRjjdPbjQ4HmidG0pg2HLuLsP3mPp isElTs5Ex5aNZlcgVQFtAhrEij3dKxLhoxcmaInYbR5vlqETd+klAX+KFYkIxu6zxdn+1QmdZsu6 kxo/qWEj6Z1d7VIcMSgqtcKbU9La+AHiCFB9vuYMeDoXsMJDD9CZFW2DHXeua4usuyudZl7ZJWmg 5a0jiD6XqsJZtjQxlyCdsezipi5yDiig4uL/e3hw9DLyIIhNd1CXx7oT7o95oVlwxkVyhWkW1DSw WWsururZ6fPFVfV8YwbQTud2ndj194c9/49qryIYbFFBOkVCXXzvNuW3bv1nPfn3AWXq7M22DtZ0 Dg9K+vwGh2YhLXUzLTJYs7W549ydvqZDiFMXDyPJeJtfWUfKlmRxQlLE/MsS4KDozswVgmo2tH4W 8yU3FuMqsjQyQl5BLbVDtpxmW72FkxJVk+yNmu+y29tmc4Nvsm48CVsONrMJuGzuoGnKTKcyyDl+ Iey4xwZiQVVdRpyDl2jeRXywq1EjZ4XBR1ffqAuf3MLbn7l3g+Lh7r9C5nLMRGxQZAxG+4f1XAVN zQl2yky2ZS50wJ+lQ+LaxBNJUp6t2ykfuEOAy+YBuZa3mFPXkVWClPVvbW5lVyQanRxw5p2JYH/6 BohvTRmOq56pXi2xVeaE7wHMAOKzNxZH1vP9C0T1BLTNamueI0y1oJZKcQ==
X-Report-Abuse-To: spam@quarantine9.antispamcloud.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/OaBA5lOX9-vAIF2GH0Yo2IzIW94>
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: Mon, 04 Feb 2019 00:08:09 -0000

On Feb 3, 2019, at 11:43 AM, Ole Troan <otroan@employees.org> wrote:

>>> The router cannot in its RPF check determine the reason for the wrong
>>> source address. If its spoofed or a previously valid address. Therefore
>>> code 5.
>> 
>> Right... if the router knew it was the previously valid address, then it
>> would know what it was, and could have sent a lifetime=0 deprecate out...
>> 
>> (did I follow you correctly?)
> 
> Yes. Of course it might do both.

OK. But then the host knows that it is not engaged in address spoofing, so it could decide to do something about it. That still would be better than calling support.

-- Christian Huitema

v2.23.0 | Report a Bug | By Email