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

Michael Richardson <mcr+ietf@sandelman.ca> Thu, 07 February 2019 07:33 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 A3D70130FD1 for <ipv6@ietfa.amsl.com>; Wed, 6 Feb 2019 23:33:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.851
X-Spam-Level:
X-Spam-Status: No, score=-0.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_12_24=1.049, 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 Qo1MGZoQHW6B for <ipv6@ietfa.amsl.com>; Wed, 6 Feb 2019 23:33:35 -0800 (PST)
Received: from relay.sandelman.ca (relay.cooperix.net [176.58.120.209]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33EA01288BD for <ipv6@ietf.org>; Wed, 6 Feb 2019 23:33:35 -0800 (PST)
Received: from dooku.sandelman.ca (unknown [IPv6:2607:f0b0:f:40::aef]) by relay.sandelman.ca (Postfix) with ESMTPS id 2B9AE1F961; Thu, 7 Feb 2019 07:33:33 +0000 (UTC)
Received: by dooku.sandelman.ca (Postfix, from userid 179) id E44EE1101; Wed, 6 Feb 2019 11:44:13 -0500 (EST)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Jan Zorz - Go6 <jan@go6.si>
cc: Ole Troan <otroan@employees.org>, Mikael Abrahamsson <swmike@swm.pp.se>, 6man WG <ipv6@ietf.org>
Subject: Re: A common problem with SLAAC in "renumbering" scenarios
In-reply-to: <1c7ebabb-d6f6-d877-d4aa-d6c0fc7d5c60@go6.si>
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> <d40b41c3-ff1b-cab4-a8de-16692a78e8fd@go6.si> <D1E45CAD-08D0-43D4-90F7-C4DD44CB32C0@employees.org> <alpine.DEB.2.20.1902041330531.23912@uplift.swm.pp.se> <46B8DB92-DC81-4242-9780-0D00FB6BDB7A@employees.org> <1c7ebabb-d6f6-d877-d4aa-d6c0fc7d5c60@go6.si>
Comments: In-reply-to Jan Zorz - Go6 <jan@go6.si> message dated "Mon, 04 Feb 2019 17:33:44 +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: Wed, 06 Feb 2019 17:44:13 +0100
Message-ID: <6278.1549471453@dooku.sandelman.ca>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/4x6qipvRraGdnIluBcCPk7Dm9i0>
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: Thu, 07 Feb 2019 07:33:37 -0000

Jan Zorz - Go6 <jan@go6.si> wrote:
    > However, I always advocated ISPs to put static IPv6 PDs in Radius (or
    > whichever AAA mechanism they use), so that the same user always gets
    > the same PD.

...

    > My suggestion is to have separate dynamic /64 prefixes to number the
    > WAN link (it works for multiple PPPoE sessions and also it gives IPv6
    > access to a very simple PPPoE client that doesn't do a PD request, like
    > end-host machine with Windows or something) and fixed PD that just the
    > first PPPoE session is able to get. This usually covers most of the
    > scenarios. For the corner cases then ISP needs to solve them case by
    > case, but at least for majority of clients that's the solution.

This creates two routes per customer.
That's why I advocate to use the prefix exclude option if you can,
or better, just don't number the WAN link.

I've had customers complain that they can't have so many routes, and why is
IPv6 not like IPv4, and I ask them how many ARP cache entries they have.
At that point, they look confused for a moment, but most figure out that IPv4
and IPv6 work exactly the same at that point.  They just didn't remember that
IPv4 was hiding the same state in what they think of as layer 2.

--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-