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

Jan Zorz - Go6 <jan@go6.si> Tue, 05 February 2019 23:28 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 82C0E131337 for <ipv6@ietfa.amsl.com>; Tue, 5 Feb 2019 15:28:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 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] 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 7Jsud-dFYuG1 for <ipv6@ietfa.amsl.com>; Tue, 5 Feb 2019 15:28:53 -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 B3C85131333 for <ipv6@ietf.org>; Tue, 5 Feb 2019 15:28:52 -0800 (PST)
Received: from localhost (localhost [IPv6:::1]) by mx.go6lab.si (Postfix) with ESMTP id 0FDB3660D5 for <ipv6@ietf.org>; Wed, 6 Feb 2019 00:28:49 +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 tNvgGabwgcaU for <ipv6@ietf.org>; Wed, 6 Feb 2019 00:28:47 +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 CA65E660D4 for <ipv6@ietf.org>; Wed, 6 Feb 2019 00:28:47 +0100 (CET)
Received: from ISOC-BMDKQ4.local (unknown [IPv6:2001:67c:27e4:102:182a:e622:682:93c]) (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 8FEEE80A01 for <ipv6@ietf.org>; Wed, 6 Feb 2019 00:28:47 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=go6.si; s=mail; t=1549409327; bh=ewxVNStsBwEUT0b7amoZVsEN94FfbXfIjWJL03AM8Dk=; h=Subject:To:References:From:Date:In-Reply-To:From; b=lQsTWao1nsjvb9xCZvk0hCqe6YKltcria9n2P1gwBJSz8f0Km9MkIPr7+8CuT+M3y 5NshUq/6BEnDB05YCQaw57S216yHskNE+bpiEKhEwMztzH8oZo1Ap04d1+UsHpIy2t AmctA4U/JrVkETQFNzwDgT9/N5PAFmw1swkkHh6Q=
Subject: Re: A common problem with SLAAC in "renumbering" scenarios
To: 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> <77ecf321-b46e-4f25-7f68-05b15714a99e@si6networks.com> <CAHL_VyDdHuEAc9UdeiRp9f+c0tdzyoLwPY1rJbZmbWAuq96Uuw@mail.gmail.com> <alpine.DEB.2.20.1902051127510.23912@uplift.swm.pp.se> <m1gqyJC-0000FkC@stereo.hq.phicoh.net> <CAO42Z2wKh-vXmv=dNmr6oEmGnw09ajrr2geYJ=H1DbSYSm=VuQ@mail.gmail.com> <m1gqzYT-0000F5C@stereo.hq.phicoh.net> <e8eabf0f-191a-a293-8051-35268a62a2bd@go6.si> <37ae87fb-93f5-4ec4-6e55-e35ce308f91c@asgard.org> <2aa19534-4856-f01d-8184-6c7ed125ca1b@go6.si> <9cdf8405-e777-6769-4d4f-f123c13a9456@asgard.org>
From: Jan Zorz - Go6 <jan@go6.si>
Message-ID: <e3e899ca-436f-1927-75d5-b1d8ad7c0686@go6.si>
Date: Wed, 06 Feb 2019 00:28:46 +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: <9cdf8405-e777-6769-4d4f-f123c13a9456@asgard.org>
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/tXpDRgj-v1vpZ0Pi3ATVF76-zcQ>
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: Tue, 05 Feb 2019 23:28:55 -0000

On 05/02/2019 22:46, Lee Howard wrote:> And yet when somebody says "I 
built my network for reasons that were
>  compelling to me at the time" you tell them they did it wrong. It's
>  tiresome.

I'm not sure I said that. My network - my rules. Your network - your rules.

However, it seems not very useful to me if networks are built in a way 
that breaks and people attributes that to "broken IPv6".

> 
> Even when someone does engage in conversation and begin explaining 
> reasons, it always becomes a rathole of all of the unique
> considerations of that network with those vendors and this budget and
> some other requirements at the time in question. Rebuilding a
> functioning network is costly and breaks things.

Agreed.

> 
> If you were a network operator reading the latter part of this
> thread, would you be inclined to participate in this working group or
> in the IETF?

I hope so. We finally started a discussion how networks are built and 
how to improve them and I find this valuable.

You and I know each other for quite some years now and you know that I 
spent considerable amount of time around the world talking to many 
operators (from small to large ones) that thought about implementing 
IPv6 and some of them did that. I even helped some of them doing so in 
many ways, but too many times hit the same issue - or burden - if you 
wish... the one that at the end of the day resulted in RIPE-690 BCOP 
document. I've seen that around the world countless times and that's the 
reason why I would like to see that confusion sorted out once for all. 
We did some "damage control" in RIPE-690, but that advice there is just 
a response to a situation that we found ourself in due to lack of very 
precise instructions how to do access part, how to do CPE and how to put 
all this stuff together that it works. There are exceptions that fixed 
this stuff for them, but mostly they are quiet and don't share their 
solutions.

So, what can we do to make this better?

> 
>> 
>> He said "Ideally". I agree with that :)
> 
> Static? That was fine when there were few enough nodes that you could
>  manually configure changes. Addressing is dynamic, which is why we
> have dynamic routing protocols.

<shrug>

It still would be ideal :) People running servers at home, etc, etc... a 
bit utopia, but still ideal :)

> 
> Jan, I'm replying to you because we're friends and I know we will
> remain so. When I say "you" here, I don't just mean you.

I know, and that's why I got engaged in this discussion. This is a topic 
that is very close to my heart, I've been working on it for many years 
now and I would really like it to be improved and give some right 
guidance to people that are deploying IPv6 around the world - not just 
people on this mailing list.

Cheers, Jan