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

Ole Troan <otroan@employees.org> Sun, 03 February 2019 21:43 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 B3A3C126C7E; Sun, 3 Feb 2019 13:43:54 -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=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 Z7j8n5BPteKz; Sun, 3 Feb 2019 13:43:51 -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 A687F128CF2; Sun, 3 Feb 2019 13:43:51 -0800 (PST)
Received: from astfgl.hanazo.no (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 F1013FECC10E; Sun, 3 Feb 2019 21:43:50 +0000 (UTC)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by astfgl.hanazo.no (Postfix) with ESMTP id 7B710DF5AE4; Sun, 3 Feb 2019 22:43:47 +0100 (CET)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
From: Ole Troan <otroan@employees.org>
In-Reply-To: <6440.1549227369@dooku.sandelman.ca>
Date: Sun, 03 Feb 2019 22:43:46 +0100
Cc: Christian Huitema <huitema@huitema.net>, "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: <85C3CE49-93CC-48E1-94FB-46A0203783A2@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>
To: Michael Richardson <mcr+ietf@sandelman.ca>
X-Mailer: Apple Mail (2.3445.102.3)
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/htAjMprpQMIipngWVL27S-KaSEg>
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: Sun, 03 Feb 2019 21:43:55 -0000

>> 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.

Cheers,
Ole

> 
>>> On 3 Feb 2019, at 21:10, Christian Huitema <huitema@huitema.net>
>>> wrote:
>>> 
>>> If the source address is allocated from a deprecated prefix, or an
>>> unknown prefix, the router cannot forward the packet. The router
>>> should send an ICMPv6 message, but from my quick reading of the RFC I
>>> could not find a code that said "the destination is unreachable
>>> because you are using a source address allocated from a deprecated
>>> prefix." The closest would be "Code = 5, source address failed
>>> ingress/egress policy", but that feels like an approximation.
>>> 
>>> An appropriate error code would help the source device might take some
>>> corrective action, like for example solicit an RA and configure an
>>> address with an up-to-date prefix. A specific connection might fail,
>>> but by the time little Johnny tries again a new source address would
>>> be available and the cat video will play fine. That seems a lot less
>>> frustrating than calling ISP support...
>>> 
>>> -- Christian Huitema
>>> 
>>>> On 2/3/2019 9:45 AM, JORDI PALET MARTINEZ wrote: Agree. Just wanted
>>>> to clarify that assertion, as I've heard it too many times.
>>>> 
>>>> AVM/Fritzbox, if I recall correctly is one of the very very very few
>>>> vendors that write the prefix in the flash ...
>>>> 
>>>> Regards, Jordi
>>>> 
>>>> 
>>>> 
>>>> -----Mensaje original----- De: Brian E Carpenter
>>>> <brian.e.carpenter@gmail.com> Fecha: domingo, 3 de febrero de 2019,
>>>> 20:41 Para: JORDI PALET MARTINEZ <jordi.palet@consulintel.es> CC:
>>>> "v6ops@ietf.org WG" <v6ops@ietf.org>, 6man WG <ipv6@ietf.org> Asunto:
>>>> Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios
>>>> 
>>>>> On 2019-02-04 06:46, JORDI PALET MARTINEZ wrote: The RIPE document
>>>>> does not recommend it. In Germany, that's the expected default.
>>>>> 
>    ----> This is not correct, in the context of another mailing list, a few
>    ----> day ago, some people (including people from Germany) confirmed that
>    ----> this is not true for Germany, neither there is any law or anything
>    ----> similar that requires dynamic prefixes.
>>>> 
>>>> It doesn't matter. The objective fact is that getting a new prefix
>>>> after a CPE reboot, or after a DSL disconnect/reconnect, or every 24
>>>> hours, is common, and not just in Germany.
>>>> 
>>>> Not that I've ever had any stale address problems as a result, even
>>>> at a time when I was getting multiple ADSL disconnects per day due to
>>>> a line fault. So with a FritzBox and Windows hosts, the "common
>>>> problem" simply wasn't a problem.
>>>> 
>>>> Brian
>>>> 
>>>> 
>>>> 
>>>> 
>>>> **********************************************
>>>> IPv4 is over Are you ready for the new Internet ?
>>>> http://www.theipv6company.com The IPv6 Company
>>>> 
>>>> This electronic message contains information which may be privileged
>>>> or confidential. The information is intended to be for the exclusive
>>>> use of the individual(s) named above and further non-explicilty
>>>> authorized disclosure, copying, distribution or use of the contents
>>>> of this information, even if partially, including attached files, is
>>>> strictly prohibited and will be considered a criminal offense. If you
>>>> are not the intended recipient be aware that any disclosure, copying,
>>>> distribution or use of the contents of this information, even if
>>>> partially, including attached files, is strictly prohibited, will be
>>>> considered a criminal offense, so you must reply to the original
>>>> sender to inform about this communication and delete it.
>>>> 
>>>> 
>>>> 
>>>> --------------------------------------------------------------------
>>>> IETF IPv6 working group mailing list ipv6@ietf.org Administrative
>>>> Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>>> --------------------------------------------------------------------
>>> 
>>> _______________________________________________ v6ops mailing list
>>> v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops
> 
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list ipv6@ietf.org Administrative
>> Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
> 
> --
> Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
> -= IPv6 IoT consulting =-
> 
> 
>