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

Jan Zorz - Go6 <jan@go6.si> Sat, 23 February 2019 06:26 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 B41E112D84C for <ipv6@ietfa.amsl.com>; Fri, 22 Feb 2019 22:26:58 -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 TtkdJYOsJRNV for <ipv6@ietfa.amsl.com>; Fri, 22 Feb 2019 22:26:56 -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 7AC2F1271FF for <ipv6@ietf.org>; Fri, 22 Feb 2019 22:26:55 -0800 (PST)
Received: from localhost (localhost [IPv6:::1]) by mx.go6lab.si (Postfix) with ESMTP id 037CE660DC; Sat, 23 Feb 2019 07:26:51 +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 on7EU4CNcXFR; Sat, 23 Feb 2019 07:26:49 +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 C246565E78; Sat, 23 Feb 2019 07:26:49 +0100 (CET)
Received: from haktar.local (unknown [IPv6:2001:67c:27e4:5::2c]) (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 60DD180A50; Sat, 23 Feb 2019 07:26:49 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=go6.si; s=mail; t=1550903209; bh=pOYc+YvKzlbtPLV6nG1ebWAzx7JUDRKh7MZU75cmHt0=; h=Subject:To:References:From:Date:In-Reply-To:From; b=NPfuHuddrzAVVR9NPUHRibOIHmPlYzTtjsdykSuIE/O46QrpTqr/dVDZcuEzhIAKw e0tJjY5ijSW7+5awRBLhMRPrcuK9xhqqNMFCarEkqO1thainh4wsrlmlgqaM+VQtsZ OiXbjuGsjLDmUBxTokzpQ+luVza1fiom1gqv/wbQ=
Subject: Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios
To: Brian E Carpenter <brian.e.carpenter@gmail.com>, ipv6@ietf.org
References: <60fabe4b-fd76-4b35-08d3-09adce43dd71@si6networks.com> <d9503983-6524-a13a-2cb0-cdcb95f76ea6@si6networks.com> <CAFU7BAQfg712UfgW9wi9pd3eVeZP9cqJEXd6=FDmchuSdauv+g@mail.gmail.com> <82c00442-bbc4-581b-2054-2d02d50d20ad@si6networks.com> <CAFU7BASDgmSwY=SLiabSqyiTOphxU0COtFLQvT8drm0iTxM+-Q@mail.gmail.com> <76c488e0-5be7-3b81-d4c3-7af826f0dbef@si6networks.com> <CAAedzxq5d0fgOq5KZu7aCL9wxoDij6C-1Ad9+nQbYyhu2aMt-Q@mail.gmail.com> <da1c6391-5e69-f09b-dee5-83d25f1cd8cd@si6networks.com> <CAAedzxouCqcmW0rA6KwDZEO-n5yVZUYHc+GSetJ8O7=Liou4tA@mail.gmail.com> <0DDB4538-62F8-442A-A12C-D3C176540884@jisc.ac.uk> <a0a4246c-24cd-905c-4cde-0428b83ba5a3@si6networks.com> <CAOSSMjVtOXOOCHVvofsMQH5=bjV_tupqCKed6C4fXiS_ZnCSQg@mail.gmail.com> <eaea9418-cd5d-714f-9332-8b7de49d5d8b@si6networks.com> <90dd7fee-77cc-3411-7079-60a6edf488d9@gmail.com> <29b2f8fb-f75f-a9e6-b0a2-5651fa2a6427@go6.si> <fd358b7d-b219-5f74-b5c5-217260fae9f1@gmail.com>
From: Jan Zorz - Go6 <jan@go6.si>
Message-ID: <72210d51-cdfe-c4ea-9d13-21ea344be647@go6.si>
Date: Sat, 23 Feb 2019 07:26:48 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.5.1
MIME-Version: 1.0
In-Reply-To: <fd358b7d-b219-5f74-b5c5-217260fae9f1@gmail.com>
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/5gWDd9RLUUOzIFTApyPnqMuAoEM>
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: Sat, 23 Feb 2019 06:26:59 -0000

On 23/02/2019 01:25, Brian E Carpenter wrote:
> On 2019-02-23 09:36, Jan Zorz - Go6 wrote:
>> On 21/02/2019 22:14, Brian E Carpenter wrote:
>>> Of course, SHOULD means "that there
>>> may exist valid reasons in particular circumstances to ignore a
>>> particular item, but the full implications must be understood and
>>> carefully weighed...". In other words, do RFC8028 and Rule 5.5
>>> unless there's a good reason not to.
>>
>> Unfortunately not all vendors understand SHOULD in this way.
>> Implementing more options is expensive and lowers the profits, so it's
>> quite easy to fall into "implement all the MUSTS, declare compliancy
>> with RFCs and ship the product" trap.
> 
> Sure. I dealt with a lot of development managers during my years
> at a 3-letter company, so this error in thinking is quite familiar
> to me. But there is nothing the IETF can really do about that.

Actually, there is.

If we feel that something must be implemented in end product, than we 
should not be polite about it and use a MUST :) That's the quickest way 
to get things back on track.

Cheers, Jan