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

Michael Richardson <mcr+ietf@sandelman.ca> Sun, 03 February 2019 20:56 UTC

Return-Path: <mcr@sandelman.ca>
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 82522126C7E; Sun, 3 Feb 2019 12:56:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.4
X-Spam-Level:
X-Spam-Status: No, score=-0.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_SORBS_WEB=1.5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 zS47QylfxLhB; Sun, 3 Feb 2019 12:56:39 -0800 (PST)
Received: from relay.sandelman.ca (relay.cooperix.net [IPv6:2a01:7e00::f03c:91ff:feae:de77]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BA62127133; Sun, 3 Feb 2019 12:56:38 -0800 (PST)
Received: from dooku.sandelman.ca (unknown [209.226.201.241]) by relay.sandelman.ca (Postfix) with ESMTPS id D3D2F1F8BE; Sun, 3 Feb 2019 20:56:36 +0000 (UTC)
Received: by dooku.sandelman.ca (Postfix, from userid 179) id B094CB82; Sun, 3 Feb 2019 15:56:09 -0500 (EST)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Ole Troan <otroan@employees.org>
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>
Subject: Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios
In-reply-to: <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> <2BAD7ADA-6940-45EA-B7DD-0D82B9E95A05@employees.org>
Comments: In-reply-to Ole Troan <otroan@employees.org> message dated "Sun, 03 Feb 2019 21:19:15 +0100."
X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha256"; protocol="application/pgp-signature"
Date: Sun, 03 Feb 2019 15:56:09 -0500
Message-ID: <6440.1549227369@dooku.sandelman.ca>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/x3PXNaoG4bI7CI2O5k4K4vfeHDA>
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:56:40 -0000

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?)

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