IETF Logo Mail Archive

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

Ole Troan <otroan@employees.org> Mon, 04 February 2019 00:27 UTC

Return-Path: <otroan@employees.org>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 779FD130DF1; Sun, 3 Feb 2019 16:27:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 iduWvXrzonb4; Sun, 3 Feb 2019 16:27:00 -0800 (PST)
Received: from bugle.employees.org (accordion.employees.org [IPv6:2607:7c80:54:3::74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A1BC130DEF; Sun, 3 Feb 2019 16:27:00 -0800 (PST)
Received: from [192.168.10.191] (30.51-175-112.customer.lyse.net [51.175.112.30]) (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 A8209FECC093; Mon, 4 Feb 2019 00:26:59 +0000 (UTC)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (1.0)
From: Ole Troan <otroan@employees.org>
X-Mailer: iPhone Mail (16D39)
In-Reply-To: <391AE39D-F754-47A8-B20A-3AEC4C174B9F@huitema.net>
Date: Mon, 04 Feb 2019 01:26:57 +0100
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: <DFDEF631-B6EF-440E-A245-261FBC780BBB@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> <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> <391AE39D-F754-47A8-B20A-3AEC4C174B9F@huitema.net>
To: Christian Huitema <huitema@huitema.net>
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/OzPUnbRuyAfDKCnK9A1hCD3FlCk>
Subject: Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 04 Feb 2019 00:27:04 -0000


> On 4 Feb 2019, at 01:07, Christian Huitema <huitema@huitema.net> wrote:
> 
> 
> 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.

Well, this is caused by the ISP, so perhaps the call should be the recommended action. :-)

Ole

v2.23.0 | Report a Bug | By Email