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

Jan Zorz - Go6 <jan@go6.si> Thu, 07 February 2019 11:42 UTC

Return-Path: <jan@go6.si>
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 B2F45131114 for <ipv6@ietfa.amsl.com>; Thu, 7 Feb 2019 03:42:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=go6.si
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 zTW-SqmSeAIA for <ipv6@ietfa.amsl.com>; Thu, 7 Feb 2019 03:42:51 -0800 (PST)
Received: from mx.go6lab.si (mx.go6lab.si [IPv6:2001:67c:27e4::23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D556F131145 for <ipv6@ietf.org>; Thu, 7 Feb 2019 03:42:50 -0800 (PST)
Received: from localhost (localhost [IPv6:::1]) by mx.go6lab.si (Postfix) with ESMTP id 5760D660D7; Thu, 7 Feb 2019 12:42:36 +0100 (CET)
X-Virus-Scanned: amavisd-new at go6.si
Received: from mx.go6lab.si ([IPv6:::1]) by localhost (mx.go6lab.si [IPv6:::1]) (amavisd-new, port 10024) with LMTP id e8dHeT8cFloQ; Thu, 7 Feb 2019 12:42:35 +0100 (CET)
Received: from mail.go6.si (mail.go6.si [IPv6:2001:67c:27e4::61]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.go6.si", Issuer "Let's Encrypt Authority X3" (not verified)) by mx.go6lab.si (Postfix) with ESMTPS id 3A7AD65FC3; Thu, 7 Feb 2019 12:42:35 +0100 (CET)
Received: from ISOC-BMDKQ4.local (unknown [91.239.97.208]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "Jan Zorz", Issuer "COMODO RSA Client Authentication and Secure Email CA" (not verified)) (Authenticated sender: jan) by mail.go6.si (Postfix) with ESMTPSA id D6F088072B; Thu, 7 Feb 2019 12:42:34 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=go6.si; s=mail; t=1549539755; bh=RmFv6qdTmm5yn9j1/se1Jw7Svhe6DZkIKijqaT383tA=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=ecPPbHn4swF6l98jK9P+YXOBChOFjNmPxXRhtIxNX50u8hJgras55kFRprxF8u9gn bUfoPDP/1FPtcNKG6L2sy8DXyHkyVm6/a1OEfmG9pRb+pWd64VdcstqVSq7VTPcGUk 5KmmBv+cE6Tw+bnJvxoDGhjYntf+O+um90rUNezA=
Subject: Re: A common problem with SLAAC in "renumbering" scenarios
To: Michael Richardson <mcr+ietf@sandelman.ca>
Cc: Ole Troan <otroan@employees.org>, Mikael Abrahamsson <swmike@swm.pp.se>, 6man WG <ipv6@ietf.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> <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> <6278.1549471453@dooku.sandelman.ca>
From: Jan Zorz - Go6 <jan@go6.si>
Message-ID: <d5200779-4ee7-52be-c0bc-017144e04369@go6.si>
Date: Thu, 07 Feb 2019 12:42:34 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.5.0
MIME-Version: 1.0
In-Reply-To: <6278.1549471453@dooku.sandelman.ca>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/sgdP8tJ0cWBDARKgmdMWq5a29o4>
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 11:43:04 -0000

On 06/02/2019 17:44, Michael Richardson wrote:
> 
> 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.

Ya, I know... Usually this has been handled with creating a pool of IPv6 
addresses per each BRAS/BNG where /64-s were allocated for each 
connecting CPE to number the WAN link. Experience shows that dynamic 
changing of the WAN addressing does not bring much pain, as does 
changing of addressing in the networks behind CPE. In this way you have 
just one route towards BRAS/BNG for that pool of "WAN link" addresses.

> That's why I advocate to use the prefix exclude option if you can,
> or better, just don't number the WAN link.

I was surprised to discover how many people still connects to the 
internet with one host that does the PPPoE connection (Windows, etc) and 
in this case - not numbering the WAN link would leave this hosts without 
any IPv6 addresses.

However, to be honest, I never tried what happens if you connect with a 
single host PPPoE client that can't do PD and the system on the other 
end does just prefix exclude option. Would that host still remain 
without any IPv6 addresses? Hmm...

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

<giggle>

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

Good point ;)

Cheers, Jan

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