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

Ole Troan <otroan@employees.org> Sun, 03 February 2019 20:19 UTC

Return-Path: <otroan@employees.org>
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 675241277CC; Sun, 3 Feb 2019 12:19:20 -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 AQER2jFbGV13; Sun, 3 Feb 2019 12:19:18 -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 314801277D2; Sun, 3 Feb 2019 12:19:18 -0800 (PST)
Received: from [10.161.196.87] (77.18.52.87.tmi.telenormobil.no [77.18.52.87]) (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 6308CFECBEBC; Sun, 3 Feb 2019 20:19:17 +0000 (UTC)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (1.0)
Subject: Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios
From: Ole Troan <otroan@employees.org>
X-Mailer: iPhone Mail (16D39)
In-Reply-To: <749b121f-cac5-30e0-686c-9f7f29313d91@huitema.net>
Date: Sun, 03 Feb 2019 21:19:15 +0100
Cc: JORDI PALET MARTINEZ <jordi.palet=40consulintel.es@dmarc.ietf.org>, Brian E Carpenter <brian.e.carpenter@gmail.com>, "v6ops@ietf.org WG" <v6ops@ietf.org>, 6man WG <ipv6@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <2BAD7ADA-6940-45EA-B7DD-0D82B9E95A05@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>
To: Christian Huitema <huitema@huitema.net>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/VFdAnyh_2K9nb3mzS4LpP4pOStE>
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: Sun, 03 Feb 2019 20:19:20 -0000

Christian,

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. 

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