Re: A common problem with SLAAC in "renumbering" scenarios

Mark Smith <markzzzsmith@gmail.com> Mon, 04 February 2019 00:52 UTC

Return-Path: <markzzzsmith@gmail.com>
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 E647E130E00; Sun, 3 Feb 2019 16:52:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.5
X-Spam-Level:
X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 QKiRU7jHlozt; Sun, 3 Feb 2019 16:52:11 -0800 (PST)
Received: from mail-oi1-x22f.google.com (mail-oi1-x22f.google.com [IPv6:2607:f8b0:4864:20::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC2D512008A; Sun, 3 Feb 2019 16:52:10 -0800 (PST)
Received: by mail-oi1-x22f.google.com with SMTP id t204so10210500oie.7; Sun, 03 Feb 2019 16:52:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=+344JPRjp84QU4/cZxE/sL/u7b/oCoY5sgRzoZ4Nw60=; b=A0kdSYely+8dxfNI2gVuWz9LxXADscbIDhfIiapcI2gWxlb2KkMGx86AOED7yTyJqB TcX4/kXca7uqUznOsFW8TziwDKoWHa/uszB/6WuqxNXYKj4OaKojObvx9vx2Ql3vFfFK i41sVlGtSgGigOWZZpvK3DjnWYbylZf31QdLdSiFXT17Q8CxkkLcJgYwUFCHMWgA8eIv LNkxSGzZnzQXlW8NhCBznx5E+h0rlyD2FLKOHQH1No/OPkopolv0Ug5hdRcGGoPN5g4t NewpshUYaUKWOSnVyIkkcaIZjxncyaXVqp9+gr3boqa1q7ZVF3iHMWZTOUM4hBB+Uzlk cZgw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=+344JPRjp84QU4/cZxE/sL/u7b/oCoY5sgRzoZ4Nw60=; b=k1GFJfKVCruj53XEkvzc4+n3fza5UQVbtJq+mzu88oLuXU9W39nu8UFXUldfxSOZl2 EN4/R5GphP/uhyS72YKLLqX4e0CY46qol+KhcFnLhBqKBaIqvKo7paLFW5AIgfk3YKmI Rypx6ln9lkqaYFgOiK5flDG3CEpg/tx8gf5owUFZQnayQ2Q++gUO3eXjOZPMR1GZSb9g /fOwEqBBIzAT04LQcjkhu5QrsDcyxqZgaj/jsOpeRh9c4QgRZJbIXcaypEfWzUNKDy9W ydx8pLgkSV7ksqSZFDTJUYEnDPJKN+alJDR1fpJUcIFzX3JdMfqJ20GTqOMTqaOUpv83 tzuA==
X-Gm-Message-State: AJcUukee4Oid15uIiIBw0jj5M1LY/woTUTBqcKqAb4cxEhvDzKAeViF1 C5/BqHxlNOd8XnKE/NIy/flIuqIRCA7C95i6VeM=
X-Google-Smtp-Source: ALg8bN6XK6lI2ry/zKsgGve4VcO9NbNK9R0+4tz0T+p4qXStzxJyVWFOeCJVrHel9ikZjUdHlfXwYbSgMb6ZIGxen2Y=
X-Received: by 2002:aca:f5ce:: with SMTP id t197mr23799748oih.311.1549241529467; Sun, 03 Feb 2019 16:52:09 -0800 (PST)
MIME-Version: 1.0
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> <CAO42Z2xzYQESqqsz4AEE89vx=AhvBEf8Yzyae9o7z1U1XYyarw@mail.gmail.com> <af53b388-2985-9e45-a41c-18fc588f88b8@si6networks.com>
In-Reply-To: <af53b388-2985-9e45-a41c-18fc588f88b8@si6networks.com>
From: Mark Smith <markzzzsmith@gmail.com>
Date: Mon, 04 Feb 2019 11:51:42 +1100
Message-ID: <CAO42Z2w=mJfhN5vws37d8Qg2rJg5yhqSH0y+3-MvHsusVemE+Q@mail.gmail.com>
Subject: Re: A common problem with SLAAC in "renumbering" scenarios
To: Fernando Gont <fgont@si6networks.com>
Cc: Ole Troan <otroan@employees.org>, v6ops list <v6ops@ietf.org>, 6man WG <ipv6@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/ScWqXePB7dKdc6LMhOue2Bk1x8g>
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:52:13 -0000

On Mon, 4 Feb 2019 at 04:40, Fernando Gont <fgont@si6networks.com> wrote:
>
> On 3/2/19 13:49, Mark Smith wrote:
> [....]
> >>> So a bug.
> >>> What you are talking about is the case where the ISP breaks the contract. While it previously promised to delegate you a prefix until 20200301, all trace of that has gone.
> >>
> >> The CPE is the middle-man between the ISP and the LAN. No matter what
> >> you may *expect* the CPE to do, the CPE is currently not actually
> >> required to e.g. clean after the contract that the ISP broke (if you
> >> assume/think there's such a thing), or even adjust prefix timers
> >> according to the DHCPv6 lease times -- talk about under-specification of
> >> the glue between e.g. DHCPv6-PD and SLAAC.
> >>
> >> Besides, the layer-8 contract between the user and the ISP may be that
> >> you get dynamic prefixes. This means that whenever you request a lease,
> >> you get a different prefix. You might say that if you don't do another
> >> DHCPv6-PD request, you should be able to use the same prefix. But if you
> >> do ask a new prefix, you might indeed get a new one -- and this is what
> >> normally happens after reboots.
> >
> > That's against the architecture and design of the Internet protocols.
> >
> > A router reboot, anywhere along the path between communicating
> > end-points, is supposed to have no more effect than a transient period
> > of packet loss. Recovery is supposed to be via transport layer
> > retransmission within the existing established connections.
>
> If you change the addresses, all bets are off. Getting a different
> prefix might mean, in theory, that you¡re attached to a different point
> of the network topology.
>
> In any case, the debate here is how to improve things when such
> scenarios do happen.
>
>

So I think it is worth finding out exactly why ISPs are doing this, to
then work out what the best solution or solutions are.

Are they doing it

1. because they're used to giving residential IPv4 customers dynamic
addresses by default, so they've carried that practice over to IPv6
without realising there are different and avoidable consequences?

2. their employer charges a premium for static address assignment in
IPv4, and their employer assumes or expects, possibly implicitly, to
do the same with IPv6?

3. because PD privacy e.g. German example?

4. to suit occasional flash renumbering?

5. ???

In some of these cases, education may be a better, easier and quicker
solution in comparison to the years it'd take to deploy CPE behaviour
changes.

I put options in radvd that tried to mitigate this nearly 10 years ago
(DeprecatePrefix, DecrementLifetimes), as radvd was popular in IPv6
CPE I was working with at the time. Assuming radvd is still popularly
used, if those options haven't been widely enabled and are not well
known, then that might indicate an education and expectations problem.

Ultimately though, the residential ISP I worked for decided to give up
the specialness and price premium of static addresses and gives all
customers their own persistent stable PD prefix tied to PPPoE
username. I've had the same one at home for 7 years.

>
> >> The CPE should -- if possible -- be faithful to its LAN hosts, and
> >> advertise if previous contracts between the CPE and the LAN hosts are
> >> void. i.e., if the CPE does  not get leased the same prefix as before,
> >> it shoudl notifiy its "clients". However, possibly for simplicity sake,
> >> CPEs don't record what
> >> information was previously advertised on the LAN -- they are not
> >> required, so.... when they reboot, they may not not be in a position to
> >> notify hosts accordingly.
> >>
> >> That's the environment hosts operate in -- no matter whether you or me
> >> like it.
> >>
> >> In that environment, hosts can and should be smarter.
> >
> >
> > Multipath transport layer protocols for the win. They're splitting
> > identifier semantics off from IP addresses.
>
> That's mostly irrelevant -- because the thing here is to get rid of the
> invalid addresses which tends to be benefical for anything running on IP.
>
>

I don't think it is. Invalid addresses become far less of an issue
when a transport layer connection doesn't depend on a single address
at each end and that it is valid all of the time.

Regards,
Mark.